Bug#1033090: unblock: dhcpdump/1.8-6

[Boian Bonev]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: dhcpd...@packages.debian.org, kilob...@debian.org
Control: affects -1 + src:dhcpdump

Please unblock package dhcpdump

[ Reason ]
Patches in 1.8-6 fix:
 - a severe bug (OOB access) that is triggered by network data
 - a bug in protocol decode that make it non-working on big-endian
and improve/fix behavior for:
 - DHCP flags display
 - option 82 data display

[ Impact ]
Users will have a buggy tool.

[ Tests ]
Fully tested on different types of DHCP traffic.

[ Risks ]
Very low - the package is leaf and fixes are trivial to verify.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
N/A

unblock dhcpdump/1.8-6
diff -Nru dhcpdump-1.8/debian/changelog dhcpdump-1.8/debian/changelog
--- dhcpdump-1.8/debian/changelog   2022-12-05 15:08:35.0 +
+++ dhcpdump-1.8/debian/changelog   2023-03-08 16:43:02.0 +
@@ -1,3 +1,45 @@
+dhcpdump (1.8-6) unstable; urgency=medium
+
+  * QA upload.
+  * Upload 1.8-5 fixes to unstable.
+
+ -- Adam Borowski   Wed, 08 Mar 2023 17:43:02 +0100
+
+dhcpdump (1.8-5) experimental; urgency=medium
+
+  [ Boian Bonev ]
+  * QA upload.
+  * Install binary and man page.
+  * Add patches that fix:
+- build options in Makefile (hardening and cross)
+- ethertype handling (Closes: #873635)
+- flags calculation
+- opt82 processing
+- counts in string arrays (OOB access)
+- spelling errors
+- wrong description in man page (Closes: #647228)
+  * Do not depend on tcpdump.
+  * Bump standards to 4.6.2, no changes.
+  * Remove unrelated key and override source not signed.
+  * wrap-and-sort
+
+  [ Joao Paulo Lima de Oliveira ]
+  * debian/control:
+- Set Rules-Requires-Root:no.
+- Set homepage-field.
+- Bumped Standards-Version to 4.6.1.
+- Set debhelper-compat version in Build-Depends.
+- Added Depends ${shlibs:Depends} in Depends fields.
+  * debian/rules:
+- Rewrite to use dh-sequencer.
+  * debian/metadata:
+- Added missing upstream metadata.
+- Added upstream's key.
+  * debian/watch:
+- Add watch file.
+
+ -- Boian Bonev   Thu, 23 Feb 2023 08:31:03 +
+
 dhcpdump (1.8-4) unstable; urgency=medium
 
   * QA upload.
diff -Nru dhcpdump-1.8/debian/control dhcpdump-1.8/debian/control
--- dhcpdump-1.8/debian/control 2022-12-05 15:08:35.0 +
+++ dhcpdump-1.8/debian/control 2023-02-23 06:56:52.0 +
@@ -2,12 +2,19 @@
 Section: admin
 Priority: optional
 Maintainer: Debian QA Group 
-Build-Depends: libpcap0.8-dev
-Standards-Version: 3.8.0.1
+Build-Depends:
+ debhelper-compat (= 13),
+ libpcap-dev,
+Standards-Version: 4.6.2
+Rules-Requires-Root: no
+Homepage: http://www.mavetju.org/download/
 
 Package: dhcpdump
 Architecture: any
-Depends: ${shlibs:Depends}, tcpdump
-Description: Parse DHCP packets from tcpdump
- This package provides a tool for visualization of DHCP packets as
- recorded and output by tcpdump to analyze DHCP server responses.
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Description: Parse DHCP packets from interface
+ This package provides a tool for visualization of DHCP packets
+ on a network interface to analyze DHCP client requests and
+ server responses.
diff -Nru dhcpdump-1.8/debian/copyright dhcpdump-1.8/debian/copyright
--- dhcpdump-1.8/debian/copyright   2022-12-05 15:08:35.0 +
+++ dhcpdump-1.8/debian/copyright   2023-02-23 06:59:21.0 +
@@ -3,8 +3,23 @@
 Source: http://www.mavetju.org/download/
 
 Files: *
-Copyright: 2001, 2002 by Edwin Groothuis, ed...@mavetju.org
- All rights reserved.
+Copyright: 2001-2002 Edwin Groothuis 
+License: BSD-2-clause
+
+Files: debian/*
+Copyright:
+ 2001-2008 Martin Schulze 
+ 2017  Manuel A. Fernandez Montecelo 
+ 2017  Svante Signell 
+ 2017  Chris Lamb 
+ 2017  Helmut Grohne 
+ 2022  Marcos Talau 
+ 2022  Bastian Germann 
+ 2022  Olivier Chirossel 
+ 2023  Joao Paulo Lima de Oliveira 
+ 2023  Boian Bonev 
+License: BSD-2-clause
+
 License: BSD-2-clause
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
diff -Nru dhcpdump-1.8/debian/patches/dhcpdump-bugfix_ethertype.patch 
dhcpdump-1.8/debian/patches/dhcpdump-bugfix_ethertype.patch
--- dhcpdump-1.8/debian/patches/dhcpdump-bugfix_ethertype.patch 1970-01-01 
00:00:00.0 +
+++ dhcpdump-1.8/debian/patches/dhcpdump-bugfix_ethertype.patch 2023-02-23 
06:29:29.0 +
@@ -0,0 +1,22 @@
+Description: Fix network order 16bit value
+ Get the packet's ethertype in a way that works on any
+ kind of endian machine
+ .
+Author: Ben Hildred <426...@gmail.com>
+Origin: vendor
+Forwarded: BTS #873635
+Last-Update: 2017-08-29
+
+--- a/dhcpdump.c
 b/dhcpdump.c
+@@ -132,8 +

Processed: unblock: dhcpdump/1.8-6

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:dhcpdump
Bug #1033090 [release.debian.org] unblock: dhcpdump/1.8-6
Added indication that 1033090 affects src:dhcpdump

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

Bug#1033034: marked as done (unblock: libmemcached/1.1.4-1)

[Debian Bug Tracking System]

Your message dated Thu, 16 Mar 2023 14:50:35 +
with message-id 
and subject line unblock libmemcached
has caused the Debian Bug report #1033034,
regarding unblock: libmemcached/1.1.4-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1033034: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033034
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Please unblock package libmemcached 1.1.4-1, it contains fix for #1032479
(CVE-2023-27478).  Removing libmemcached from testing would pull a hell lot of
packages with it.  The upstream changes between 1.1.3 and 1.1.4 are minimal and
the code changes are limited to fixing the CVE; It also fixes the underlinking
problem that we had to patch.

Thanks,
Ondrej

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock libmemcached/1.1.4-1


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmQSouNfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcK6XxAAp5XHOJE5RV6adouX85kXtGR9Yj7L9LcRH/n77IReorLZa/JpxtKceha9
JufAm0CK8fWuvJ5HqYcqo2BClpIiyjLSz8WtuwJw8lQMoblOikpC36P2Cw362UO7
/9guIyuyEaMOY25f6N0P7+w3Xpd6eJXksCvpAYUnSCitBz9Ce0MLiRvQaXtBFT0r
WBQnKd63kF6t/ZG75Et8pJJgUoIxarlrBPe7EwwIepvoQO5RcNt3TqUFzy9uOF2C
74GOMOn8RLLYFlQyhUfVds18m53i5pxXa2B+leYfvVvZhkTrZuJCrDPUUlAxtkfP
WDfUPCKzegYcUfwSiIPDqjihPiMD+OasuUPfDKPG39e2iQts9wUeCMkRnBOVHUVw
Pp/zt5KGPXwvgz9xeKBIVRbquVt+l3lmGI/qUU3vCezVi4nhOlnrwXoPyC5QoWG3
ZGe1DY0nzcSLq1yviUWmUTVQwHfp9dxoJPIvsAi7sh5saTnnquxEC/xUjTWn1wQ3
uKHUw3uFnZ5q8VYqdsAFjTbCogz8MZsyZlsYcxspDCEkW8JoKpdSl9zZiZ9ouoap
Gy4IqQBmQCU9u2oBiwf9CWLywxkzmmHYuCdNGwzspOZbqfOB4iY4tsq9n5uM/KsR
zlT3OO/DQdiEOztBZJQIhWuZ6VFMDpqMrVdDQIXjecvpknAr+MU=
=JrGZ
-END PGP SIGNATURE-
diff -Nru libmemcached-1.1.3/.builds/freebsd.yml 
libmemcached-1.1.4/.builds/freebsd.yml
--- libmemcached-1.1.3/.builds/freebsd.yml  2023-02-03 11:59:40.0 
+0100
+++ libmemcached-1.1.4/.builds/freebsd.yml  2023-03-06 19:36:56.0 
+0100
@@ -45,11 +45,5 @@
   maybe cmake --build debug -j2 --target test
   - install: |
   maybe cmake --install debug --prefix /tmp
-  - package: |
-  maybe cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_DOCS_MANGZ=ON -S 
libmemcached -B release
-  maybe cmake --build release -j2 --target package -- VERBOSE=
-  maybe cmake -DCPACK_COMPONENT_INSTALL=ON release
-  maybe cmake --build release -j2 --target package -- VERBOSE=
-  maybe cmake --build release -j2 --target push-artifacts -- VERBOSE=
   - success: |
   notify-gitter success
diff -Nru libmemcached-1.1.3/.builds/openbsd.yml 
libmemcached-1.1.4/.builds/openbsd.yml
--- libmemcached-1.1.3/.builds/openbsd.yml  2023-02-03 11:59:40.0 
+0100
+++ libmemcached-1.1.4/.builds/openbsd.yml  2023-03-06 19:36:56.0 
+0100
@@ -33,11 +33,5 @@
   maybe cmake --build debug -j2 --target test
   - install: |
   maybe cmake --install debug --prefix /tmp
-  - package: |
-  maybe cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_DOCS_MANGZ=ON -S 
libmemcached -B release
-  maybe cmake --build release -j2 --target package -- VERBOSE=
-  maybe cmake -DCPACK_COMPONENT_INSTALL=ON release
-  maybe cmake --build release -j2 --target package -- VERBOSE=
-  maybe cmake --build release -j2 --target push-artifacts -- VERBOSE=
   - success:
   notify-gitter success
diff -Nru libmemcached-1.1.3/.builds/scripts/notify-gitter 
libmemcached-1.1.4/.builds/scripts/notify-gitter
--- libmemcached-1.1.3/.builds/scripts/notify-gitter2023-02-03 
11:59:40.0 +0100
+++ libmemcached-1.1.4/.builds/scripts/notify-gitter2023-03-06 
19:36:56.0 +0100
@@ -1,6 +1,8 @@
 #!/usr/bin/env bash
 set -eu
 
+test -f ~/.gitter || exit 0
+
 GITTER=$(cat ~/.gitter)
 STATUS=$1
 
diff -Nru libmemcached-1.1.3/ChangeLog libmemcached-1.1.4/ChangeLog
--- libmemcached-1.1.3/ChangeLog2023-02-03 11:59:40.0 +0100
+++ libmemcached-1.1.4/ChangeLog2023-03-06 19:36:56.0 +0100
@@ -1,5 +1,22 @@
 # ChangeLog v1.1
 
+## v 1.1.4
+
+> released 2022-03-06
+
+* Fix [gh #107](https://github.com/awesomized/libmemcached/issues/107):
+  macOS: deprecated sasl API (improve detection of `libsasl2`).
+* Fix [gh #131](https://github.com/awesomized/libmemca

Bug#1033033: marked as done (unblock: mozjs78/78.15.0-7)

[Debian Bug Tracking System]

Your message dated Thu, 16 Mar 2023 13:51:59 +
with message-id 
and subject line unblock mozjs78
has caused the Debian Bug report #1033033,
regarding unblock: mozjs78/78.15.0-7
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1033033: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033033
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Control: affects -1 + src:mozjs78
X-Debbugs-Cc: mozj...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mozjs78

[ Reason ]
This update adds 2 patches to fix 2 FTBFS issues (python3.11 & gcc12)

[ Impact ]
mozjs78 can be built from source

[ Tests ]
mozjs78 in Unstable has built on all release architectures.
mozjs78 does not have autopkgtests itself yet, but all the cjs
autopkgtests triggered by this update have passed.

[ Risks ]

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]
mozjs78 is the SpiderMonkey JavaScript engine from the obsolete
Firefox ESR 78 branch. It is only used by cjs (a fork of gjs), a
critical element of the Cinnamon desktop. The Cinnamon developers will
eventually switch to newer versions of mozjs but this won't happen for
Bookworm.

https://wiki.mozilla.org/Release_Management/Calendar

unblock mozjs78/78.15.0-7

Thank you,
Jeremy Bicha


mozjs78_78.15.0-7.debdiff
Description: Binary data
--- End Message ---
--- Begin Message ---
Unblocked.--- End Message ---

Processed: c-ares 1.17.1-1+deb11u2 flagged for acceptance

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> package release.debian.org
Limiting to bugs with field 'package' containing at least one of 
'release.debian.org'
Limit currently set to 'package':'release.debian.org'

> tags 1031652 = bullseye pending
Bug #1031652 [release.debian.org] bullseye-pu: package c-ares/1.17.1-1+deb11u1 
CVE-2022-4904
Added tag(s) pending; removed tag(s) confirmed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1031652: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031652
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1031652: c-ares 1.17.1-1+deb11u2 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1031652 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: c-ares
Version: 1.17.1-1+deb11u2

Explanation: prevent stack overflow and denial of service

Bug#1033025: unblock: socklog/2.1.0+repack-5

[Mathieu Mirmont]

On Thu, Mar 16, 2023 at 02:57:52PM +0100, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
> 
> Hi Mathieu
> 
> On 2023-03-15 23:05:39 +0100, Mathieu Mirmont wrote:
> > diff -Nru socklog-2.1.0+repack/debian/changelog 
> > socklog-2.1.0+repack/debian/changelog
> > --- socklog-2.1.0+repack/debian/changelog   2020-12-22 22:40:42.0 
> > +0100
> > +++ socklog-2.1.0+repack/debian/changelog   2023-03-06 22:01:18.0 
> > +0100
> > @@ -1,3 +1,15 @@
> > +socklog (2.1.0+repack-5) unstable; urgency=medium
> > +
> > +  * Various uninteresting changes
> 
> What are these uninteresting changes?

Sorry that's not the greatest description indeed. Looking at the git
commit this is:

- Use spaces instead of tabs to align columns in d/socklog.install and
  d/socklog-run.runit.
- Add set -eu at the top of the d/repack.sh script.
- Update the copyright date in d/copyright.
- Include /usr/share/dpkg/buildflags.mk in d/rules.
- Remove Breaks/Replaces: socklog (<= 2.1.0+repack-3) in d/control
  (see below for the rationale).

> > diff -Nru socklog-2.1.0+repack/debian/control 
> > socklog-2.1.0+repack/debian/control
> > --- socklog-2.1.0+repack/debian/control 2020-12-22 22:40:42.0 
> > +0100
> > +++ socklog-2.1.0+repack/debian/control 2023-03-06 21:52:36.0 
> > +0100
> > @@ -37,9 +37,8 @@
> >   ${misc:Depends}, ${shlibs:Depends}
> >  Recommends: ipsvd, mailx
> >  Provides: system-log-daemon, linux-kernel-log-daemon
> > -Conflicts: system-log-daemon, linux-kernel-log-daemon, ${runit:Conflicts}
> > -Breaks: socklog (<= 2.1.0+repack-3), ${runit:Breaks}
> > -Replaces: socklog (<= 2.1.0+repack-3)
> > +Conflicts: system-log-daemon, linux-kernel-log-daemon
> > +Breaks: ${runit:Breaks}
> 
> What's the rationale behind those changes?

Until socklog 2.1.0+repack-3 the two binary packages were merged into
one. That version was never released and bullseye shipped with
2.1.0+repack-4 so this Breaks/Replaces is now obsolete.

Then there's ${runit:Conflicts} and ${runit:Breaks} that expand to the
same value. Using both seems redundant and Breaks is sufficient since
the packages can be unpacked at the same time.

Cheers,

-- 
Mathieu Mirmont 

Bug#1033080: marked as done (unblock: base-files/12.4)

[Debian Bug Tracking System]

Your message dated Fri, 17 Mar 2023 00:28:56 +0100
with message-id <338bf7f4-6519-6a23-b059-aa7dcbb7a...@debian.org>
and subject line Re: Bug#1033080: unblock: base-files/12.4
has caused the Debian Bug report #1033080,
regarding unblock: base-files/12.4
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


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

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:base-files

Please unblock package base-files

[ Reason ]
It contains the changes everybody expects for bookworm as stable.

[ Tests ]
I've done my best double-checking that everything is correct.

[ Risks ]
The upload contains also other minor changes, but all of them are small,
all of them are low risk, and none of them should affect the end user.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]

Note 1: I'm actually using a diff in "git show" format,
because the old "copyright.in" is now simply "copyright"
and a debdiff would show this as a spurious big difference.

Note 2: All the changes in the licenses/* directory are really the
result of refreshing the licenses. I do not decide about those changes
nor I have a way to control them.

Thanks.

unblock base-files/12.4diff --git a/debian/README b/debian/README
index 01570a9..9ced2ea 100644
--- a/debian/README
+++ b/debian/README
@@ -4,10 +4,10 @@ Frequently Asked Questions about base-files
 * Questions about /etc/issue and /etc/debian_version:
 
 Q. I upgraded my system to the testing distribution and now my /etc/issue
-says "bookworm/sid". Should it not read "bookworm" or "testing"?
+says "trixie/sid". Should it not read "trixie" or "testing"?
 
 Q. I upgraded my system to the unstable distribution and now my /etc/issue
-says "bookworm/sid". Should it not read "sid" or "unstable"?
+says "trixie/sid". Should it not read "sid" or "unstable"?
 
 A. That would be nice, but it is not possible because of the way the
 testing distribution works. Packages uploaded for unstable reach
@@ -17,9 +17,9 @@ testing. You should consider the testing and unstable 
distributions as
 two sides of the same coin. Since the base-files package in testing
 was initially uploaded for unstable, the only sensible /etc/issue to
 have is one that is both valid for testing and unstable, hence
-"bookworm/sid" (or whatever is appropriate).
+"trixie/sid" (or whatever is appropriate).
 
-Q. Why "bookworm/sid" and not "testing/unstable" as it used to be?
+Q. Why "trixie/sid" and not "testing/unstable" as it used to be?
 
 A. The codename is a little bit more informative, as the meaning of
 "testing" changes over time.
diff --git a/debian/base-files.lintian-overrides 
b/debian/base-files.lintian-overrides
index d57f3a3..691e9e6 100644
--- a/debian/base-files.lintian-overrides
+++ b/debian/base-files.lintian-overrides
@@ -2,21 +2,21 @@
 # Permissions 0700 on /root are intentional as people expect
 # the /root directory to be more private than /home/* directories.
 #
-base-files: non-standard-dir-perm root/ 0700 != 0755
+base-files: non-standard-dir-perm 0700 != 0755 [root/]
 #
 # The /etc/os-release symlink is relative on purpose to avoid breaking dracut.
 # See Bug #755394 for details.
 #
-base-files: symlink-should-be-absolute etc/os-release ../usr/lib/os-release
+base-files: relative-symlink ../usr/lib/os-release [etc/os-release]
 #
 # The purpose of having licenses here is precisely to allow
 # other packages to reference them.
 #
-base-files: extra-license-file usr/share/common-licenses/Artistic
-base-files: extra-license-file usr/share/common-licenses/BSD
-base-files: extra-license-file usr/share/common-licenses/GPL-1
-base-files: extra-license-file usr/share/common-licenses/GPL-2
-base-files: extra-license-file usr/share/common-licenses/GPL-3
-base-files: extra-license-file usr/share/common-licenses/LGPL-2
-base-files: extra-license-file usr/share/common-licenses/LGPL-2.1
-base-files: extra-license-file usr/share/common-licenses/LGPL-3
+base-files: extra-license-file [usr/share/common-licenses/Artistic]
+base-files: extra-license-file [usr/share/common-licenses/BSD]
+base-files: extra-license-file [usr/share/common-licenses/GPL-1]
+base-files: extra-license-file [usr/share/common-licenses/GPL-2]
+base-files: extra-license-file [usr/share/common-licenses/GPL-3]
+base-files: extra-license-fil

Bug#1033080: unblock: base-files/12.4

[Santiago Vila]

Closing as duplicate the one which has a greater bug number.

Sorry for the noise.

Bug#1033082: bullseye-pu: package xapian-core/1.4.18-3+deb11u1

[Olly Betts]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: xapian-c...@packages.debian.org
Control: affects -1 + src:xapian-core

[ Reason ]
This is a targetted fix for a potential database corruption if switching
the new revision live fails with ENOSPC but the recovery process does
NOT get ENOSPC:

https://bugs.debian.org/1032398

It looks like all previous 1.4.x releases are affected.  This is a
regression compared to Xapian 1.2.x (which was in jessie).

The fix here is taken from upstream's 1.4.22 release and is the simplest
way to address the problem: simply reread the current version file
from disk which means the in memory state will match the previously
committed state.

[ Impact ]
This can result in corrupted databases for users if their partition
fills up while indexing.  It doesn't happen every time, but it's
definitely been hit by one notmuch user on Debian, and likely explains
a smattering of reports of database corruption over the years.

[ Tests ]
There's a pretty thorough upstream testsuite for xapian-core.  The
specific scenario of ENOSPC isn't currently tested by that, but we've
exercised it by hand by injecting an ENOSPC failure using strace, which
reliably triggers corruption without the patch and no corruption with
it.

The fix was include in the upstream 1.4.22 release which was released
2023-02-02 (6 weeks ago) and uploaded to unstable the same day - there
haven't been any reports of issue with it.

[ Risks ]
This is a really low risk change.  It only touches the code path taken
when a commit operation fails to write to disk, and does a more complete
reset of state in that case.

The rollback being done here is actually more complicated than necessary
(the multiple tables are now committed together atomically, but used to
be committed one-by-one which required extra care to roll-back).  That's
been cleaned up on upstream git master, but I've gone for the simpler
and less invasive fix from upstream 1.4.x.

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in stable
  [*] the issue is verified as fixed in unstable

[ Changes ]
The change switches from calling a function which attempts to roll-back
the in-memory state directly (but gets it wrong in this situation) to
one which resets the in-memory state to what it would be if the database
was opened afresh.

Cheers,
Olly
diff -Nru xapian-core-1.4.18/debian/changelog 
xapian-core-1.4.18/debian/changelog
--- xapian-core-1.4.18/debian/changelog 2021-02-24 07:33:41.0 +1300
+++ xapian-core-1.4.18/debian/changelog 2023-03-17 11:20:07.0 +1300
@@ -1,3 +1,15 @@
+xapian-core (1.4.18-3+deb11u1) bullseye; urgency=medium
+
+  * debian/patches/fix-db-corruption-on-ENOSPC.patch: New patch to
+fix potential database corruption if switching the new revision
+live fails with ENOSPC but the recovery process does NOT get ENOSPC.
+The fix here is taken from upstream's 1.4.22 release and is the simplest
+way to address the problem: simply reread the current version file
+from disk which means the in memory state will match the previously
+committed state.  Closes: #1032398
+
+ -- Olly Betts   Fri, 17 Mar 2023 11:20:07 +1300
+
 xapian-core (1.4.18-3) unstable; urgency=medium
 
   * debian/rules: Workaround testcase sensitivity to excess precision by
diff -Nru xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch 
xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch
--- xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch 
1970-01-01 12:00:00.0 +1200
+++ xapian-core-1.4.18/debian/patches/fix-db-corruption-on-ENOSPC.patch 
2023-03-17 11:20:07.0 +1300
@@ -0,0 +1,40 @@
+commit 90f7a35483b4cf7dd848c34634803bf28f95081d
+Author: Olly Betts 
+Date:   Wed Jan 25 11:40:44 2023 +1300
+
+Fix recovery from failed commit
+
+If renaming to switch the new version file live fails (e.g. due to
+ENOSPC) we discard the changes, try to write and switch to a different
+new version file with an increased revision (on failure of this too we
+close the database), and throw DatabaseError.
+
+Unfortunately the roll-back of state is not complete, and if switching
+to the different new version file succeeds that bad state persists on
+disk.
+
+Thanks to Uwe Kleine-König for reporting and coming up with the idea
+to reproduce using strace to inject a rename() failure - this is a
+simple reproducer:
+
+rm -rf enospc.db
+strace -e inject=rename:error=ENOSPC:when=2 examples/simpleindex enospc.db 
< INSTALL
+xapian-check enospc.db
+
+No automated regression test for this yet as this doesn't trivially
+fit into the existing testsuite framework, but we ought to have
+tests using fault injection.
+
+(cherry picked from comm

Processed: bullseye-pu: package xapian-core/1.4.18-3+deb11u1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:xapian-core
Bug #1033082 [release.debian.org] bullseye-pu: package 
xapian-core/1.4.18-3+deb11u1
Added indication that 1033082 affects src:xapian-core

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

Bug#1033046: marked as done (unblock: arm-compute-library/20.08+dfsg-7)

[Debian Bug Tracking System]

Your message dated Thu, 16 Mar 2023 22:40:52 +
with message-id 
and subject line Re: Bug#1033046: unblock: arm-compute-library/20.08+dfsg-7
has caused the Debian Bug report #1033046,
regarding unblock: arm-compute-library/20.08+dfsg-7
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1033046: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033046
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package arm-compute-library.

[ Reason ]
Fix RC bug in bookworm, the package fails to build from source due to
missing include directives: https://bugs.debian.org/1032041

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock arm-compute-library/20.08+dfsg-7

Thanks,
  Emanuele

diff -Nru arm-compute-library-20.08+dfsg/debian/changelog arm-compute-library-20.08+dfsg/debian/changelog
--- arm-compute-library-20.08+dfsg/debian/changelog	2020-11-06 01:30:42.0 +0100
+++ arm-compute-library-20.08+dfsg/debian/changelog	2023-03-03 14:31:21.0 +0100
@@ -1,3 +1,17 @@
+arm-compute-library (20.08+dfsg-7) unstable; urgency=medium
+
+  * Actually include d/patches/missing-includes.patch, all changes to d/patches
+got removed by dgit.
+
+ -- Emanuele Rocca   Fri, 03 Mar 2023 14:31:21 +0100
+
+arm-compute-library (20.08+dfsg-6) unstable; urgency=medium
+
+  * Add d/patches/missing-includes.patch to fix FTBFS (Closes: #1032041)
+  * Add myself to Uploaders with Wookey's permission.
+
+ -- Emanuele Rocca   Fri, 03 Mar 2023 14:12:26 +0100
+
 arm-compute-library (20.08+dfsg-5) unstable; urgency=medium
 
   * Re-release as source-only upload
diff -Nru arm-compute-library-20.08+dfsg/debian/control arm-compute-library-20.08+dfsg/debian/control
--- arm-compute-library-20.08+dfsg/debian/control	2020-11-06 01:30:42.0 +0100
+++ arm-compute-library-20.08+dfsg/debian/control	2023-03-03 14:16:04.0 +0100
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Compute Library Team 
-Uploaders: Georgios Pinitas ,
+Uploaders: Georgios Pinitas , Emanuele Rocca 
 Standards-Version: 4.5.0
 Homepage: https://github.com/ARM-software/ComputeLibrary
 Vcs-git: https://salsa.debian.org/wookey/arm-compute-library
diff -Nru arm-compute-library-20.08+dfsg/debian/patches/missing-includes.patch arm-compute-library-20.08+dfsg/debian/patches/missing-includes.patch
--- arm-compute-library-20.08+dfsg/debian/patches/missing-includes.patch	1970-01-01 01:00:00.0 +0100
+++ arm-compute-library-20.08+dfsg/debian/patches/missing-includes.patch	2023-03-03 14:30:48.0 +0100
@@ -0,0 +1,136 @@
+From: Emanuele Rocca 
+Date: Fri, 03 Mar 2023 14:14:18 +0100
+Subject: add missing includes to fix https://bugs.debian.org/1032041
+
+Index: arm-compute-library-20.08+dfsg/arm_compute/core/ITensorPack.h
+===
+--- arm-compute-library-20.08+dfsg.orig/arm_compute/core/ITensorPack.h
 arm-compute-library-20.08+dfsg/arm_compute/core/ITensorPack.h
+@@ -25,6 +25,7 @@
+ #define ARM_COMPUTE_ITENSORPACK_H
+ 
+ #include 
++#include 
+ #include 
+ 
+ namespace arm_compute
+Index: arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/mergeresults.cpp
+===
+--- arm-compute-library-20.08+dfsg.orig/src/core/NEON/kernels/arm_gemm/mergeresults.cpp
 arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/mergeresults.cpp
+@@ -25,6 +25,7 @@
+ /* As some of the merges need these headers, but are all included in the
+  * arm_gemm namespace, put these headers here.  */
+ #include 
++#include 
+ 
+ #include 
+ 
+Index: arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/generic.cpp
+===
+--- arm-compute-library-20.08+dfsg.orig/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/generic.cpp
 arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/generic.cpp
+@@ -24,6 +24,7 @@
+ #ifdef __aarch64__
+ 
+ #include 
++#include 
+ 
+ #include "arm_gemm.hpp"
+ 
+Index: arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/a55.cpp
+===
+--- arm-compute-library-20.08+dfsg.orig/src/core/NEON

Bug#1033043: marked as done (unblock: octave/7.3.0-2)

[Debian Bug Tracking System]

Your message dated Thu, 16 Mar 2023 22:41:28 +
with message-id 
and subject line Re: Bug#1033043: unblock: octave/7.3.0-2
has caused the Debian Bug report #1033043,
regarding unblock: octave/7.3.0-2
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1033043: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033043
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: oct...@packages.debian.org
Control: affects -1 + src:octave

Please unblock package octave.

Version 7.3.0-2 fixes an issue that may arise during upgrades from Bullseye to
Bookworm, namely a missing Breaks+Replaces with files moved from one package to
another (see #1033011).

The debdiff is attached.

unblock octave/7.3.0-2

Thanks for your work,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org
diff -Nru octave-7.3.0/debian/changelog octave-7.3.0/debian/changelog
--- octave-7.3.0/debian/changelog   2022-11-05 09:29:53.0 +0100
+++ octave-7.3.0/debian/changelog   2023-03-15 17:55:33.0 +0100
@@ -1,3 +1,10 @@
+octave (7.3.0-2) unstable; urgency=medium
+
+  * d/control: add missing Breaks+Replaces of octave-dev on old liboctave-dev
+(Closes: #1033011)
+
+ -- Sébastien Villemot   Wed, 15 Mar 2023 17:55:33 +0100
+
 octave (7.3.0-1) unstable; urgency=medium
 
   * New upstream version 7.3.0
diff -Nru octave-7.3.0/debian/control octave-7.3.0/debian/control
--- octave-7.3.0/debian/control 2022-11-05 09:29:48.0 +0100
+++ octave-7.3.0/debian/control 2023-03-15 17:54:42.0 +0100
@@ -144,6 +144,8 @@
  gcc,
  g++
 Enhances: octave
+Breaks: liboctave-dev (<< 6.3.0-1)
+Replaces: liboctave-dev (<< 6.3.0-1)
 Description: development files for the GNU Octave language
  Octave is a (mostly MATLAB® compatible) high-level language, primarily
  intended for numerical computations. It provides a convenient command-line
--- End Message ---
--- Begin Message ---
On Thu, Mar 16, 2023 at 10:33:26AM +0100, Sébastien Villemot wrote:
> Please unblock package octave.
> 
> Version 7.3.0-2 fixes an issue that may arise during upgrades from Bullseye to
> Bookworm, namely a missing Breaks+Replaces with files moved from one package 
> to
> another (see #1033011).

I already unblocked it and set an age of 5.

Thanks,



-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1--- End Message ---

Bug#1032847: marked as done (unblock: intel-microcode/3.20230214.1)

[Debian Bug Tracking System]

Your message dated Thu, 16 Mar 2023 16:36:24 +0100
with message-id <19c1f9e1-a1c7-d285-aba0-2bcce31d3...@debian.org>
and subject line Re: Bug#1032847: unblock: intel-microcode/3.20230214.1
has caused the Debian Bug report #1032847,
regarding unblock: intel-microcode/3.20230214.1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1032847: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032847
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: intel-microc...@packages.debian.org, t...@security.debian.org
Control: affects -1 + src:intel-microcode

I've uploaded intel-microcode to DELAYED/5, ETA will be Mar 17 ~18:00 CET
Please unblock package intel-microcode once it hits unstable.

The upload updates intel microcodes to target (See #1031334)
   - INTEL-SA-00700: CVE-2022-21216
   - INTEL-SA-00730: CVE-2022-33972
   - INTEL-SA-00738: CVE-2022-33196
   - INTEL-SA-00767: CVE-2022-38090

the CVEs are information disclosure via local access vulnerbilities and
potential privilege escalations.

I plan to provide updated packages for bullseye (security team in CC).
As well as LTS (buster) and ELTS (stretch an jessie) as part of the freexian 
LTS/ELTS project)

To keep the fixes consistent, I'd like to let them flow from sid -> jessie…

[ Tests ]
I've tested that the package works on Intel hardware that I have access to.


[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock intel-microcode/3.20230214.1

-- 
tobi
diff -Nru intel-microcode-3.20221108.2/debian/changelog 
intel-microcode-3.20230214.1/debian/changelog
--- intel-microcode-3.20221108.2/debian/changelog   2023-02-17 
01:12:52.0 +0100
+++ intel-microcode-3.20230214.1/debian/changelog   2023-03-12 
18:16:50.0 +0100
@@ -1,3 +1,52 @@
+intel-microcode (3.20230214.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream microcode datafile 20230214
+- Includes Fixes for: (Closes: #1031334)
+   - INTEL-SA-00700: CVE-2022-21216
+   - INTEL-SA-00730: CVE-2022-33972
+   - INTEL-SA-00738: CVE-2022-33196
+   - INTEL-SA-00767: CVE-2022-38090
+  * New Microcodes:
+sig 0x000806f4, pf_mask 0x10, 2022-12-19, rev 0x2c000170
+sig 0x000806f4, pf_mask 0x87, 2022-12-27, rev 0x2b000181
+sig 0x000806f5, pf_mask 0x10, 2022-12-19, rev 0x2c000170
+sig 0x000806f5, pf_mask 0x87, 2022-12-27, rev 0x2b000181
+sig 0x000806f6, pf_mask 0x10, 2022-12-19, rev 0x2c000170
+sig 0x000806f6, pf_mask 0x87, 2022-12-27, rev 0x2b000181
+sig 0x000806f7, pf_mask 0x87, 2022-12-27, rev 0x2b000181
+sig 0x000806f8, pf_mask 0x10, 2022-12-19, rev 0x2c000170
+sig 0x000806f8, pf_mask 0x10, 2022-12-19, rev 0x2c000170, size 600064
+sig 0x000806f8, pf_mask 0x87, 2022-12-27, rev 0x2b000181
+sig 0x000806f8, pf_mask 0x87, 2022-12-27, rev 0x2b000181, size 561152
+sig 0x000b06a2, pf_mask 0xc0, 2022-12-08, rev 0x410e
+sig 0x000b06a2, pf_mask 0xc0, 2022-12-08, rev 0x410e, size 212992
+sig 0x000b06a3, pf_mask 0xc0, 2022-12-08, rev 0x410e
+  * Updated Microcodes:
+sig 0x00050653, pf_mask 0x97, 2022-08-30, rev 0x1000161, size 36864
+sig 0x00050656, pf_mask 0xbf, 2022-08-26, rev 0x4003303, size 37888
+sig 0x00050657, pf_mask 0xbf, 2022-08-26, rev 0x5003303, size 37888
+sig 0x0005065b, pf_mask 0xbf, 2022-08-26, rev 0x7002503, size 29696
+sig 0x000606a6, pf_mask 0x87, 2022-10-09, rev 0xd000389, size 296960
+sig 0x000606c1, pf_mask 0x10, 2022-09-23, rev 0x1000211, size 289792
+sig 0x000706a1, pf_mask 0x01, 2022-09-16, rev 0x003e, size 75776
+sig 0x000706a8, pf_mask 0x01, 2022-09-20, rev 0x0022, size 76800
+sig 0x000706e5, pf_mask 0x80, 2022-08-31, rev 0x00b8, size 113664
+sig 0x000806a1, pf_mask 0x10, 2022-09-07, rev 0x0032, size 34816
+sig 0x00090672, pf_mask 0x07, 2023-01-04, rev 0x002c
+sig 0x00090672, pf_mask 0x07, 2023-01-04, rev 0x002c, size 219136
+sig 0x00090675, pf_mask 0x07, 2023-01-04, rev 0x002c
+sig 0x000906a3, pf_mask 0x80, 2023-01-11, rev 0x0429
+sig 0x000906a3, pf_mask 0x80, 2023-01-11, rev 0x0429, size 218112
+sig 0x000906a4, pf_mask 0x80, 2023-01-11, rev 0x0429
+sig 0x000906c0, pf_mask 0x01, 2022-09-02, rev 0x2424, size 20480
+sig 0x000a0671, pf_mask 0x02, 2022-08-31, rev 0x0057, size 103424
+sig 0x000b0671, pf_mask 0x32, 2022-12-19, rev 0x0112

Bug#1032910: marked as done (unblock: apt/2.6.0)

[Debian Bug Tracking System]

Your message dated Thu, 16 Mar 2023 17:07:18 +0100
with message-id 
and subject line Re: Bug#1032910: unblock: apt/2.6.0
has caused the Debian Bug report #1032910,
regarding unblock: apt/2.6.0
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1032910: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032910
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: a...@packages.debian.org, j...@debian.org
Control: affects -1 + src:apt

Please unblock package apt

[ Reason ]

APT 2.6.0 contains the final fixes for bookworm, adding non-free-firmware
support, making the `changelog` command query the online servers for the
truncated changelogs that are the default now, fixes a bug where Release
files were stored that should have been rejected, translation updates,
and licensing clarifications (which is an RC bug).

I am sorry, Unfortunately due to various comment changes mostly, the diff
is a bit unwieldly to look at, but the individual code changes are rather
small, it might be easier to look at the commit diffs:

https://salsa.debian.org/apt-team/apt/-/compare/2.5.6...2.6.0?from_project_id=228&straight=false

or grouped by the merges for code changes:

non-free-firmware:
  https://salsa.debian.org/apt-team/apt/-/merge_requests/282 (updated ubuntu 
codename to lunar in followup)
   + https://salsa.debian.org/apt-team/apt/-/merge_requests/286 followup (minor 
tweaks to those changes)
changelog:
  https://salsa.debian.org/apt-team/apt/-/merge_requests/288
do not store trusted Release file unconditionally:
  https://salsa.debian.org/apt-team/apt/-/merge_requests/289
copyright rework:
https://salsa.debian.org/apt-team/apt/-/merge_requests/287

Unfortunately we lost a week or so because I was sick after FOSDEM :(

Full Changelog:

   [ Cyril Brulebois ]
   * Teach apt-cdrom's scoring system about non-free-firmware (Closes: #1029751)
 .
   [ David Kalnischkies ]
   * More support for non-free-firmware
 - Have values in Section config trees refer to them in all components
 - Add non-free-firmware component in documentation
 - Suggest using non-free-firmware in update for Debian
   * other bookworm regressions:
 - Bump codenames in docs in preparation for Debian 12
 - Detect trimmed changelogs and pick online instead (Closes: #1024457)
   * Do not store trusted=yes Release file unconditionally
 .
   [ Miroslav Kure ]
   * Czech program translation update (Closes: #1031008)
 .
   [ Bastian Germann ]
   * machine-readable version of COPYING (Closes: #1019273), initial version
 .
   [ Julian Andres Klode ]
   * Update lintian override info format in d/apt.lintian-overrides
   * Further work on machine-readable COPYING file and the source code comments
 to address licensing inadequacies:
 - Address statements of public domain
 - po/nb.po: Relicensing GPL-2.0 -> GPL-2.0+. Thanks Petter for chasing
   down the copyright holders and getting agreement.
 - COPYING: Group by license
 - Address translation licensing concerns
 - COPYING: Address RunScripts()
 - We do not believe rsh was supposed to exclude GPL-3
 This unfortunately creates a bit of churn, but updating the COPYING file
 without addressing the actual licensing issues would not have solved the
 bug.

[ Impact ]
* `changelog` command only shows incomplete changelogs
* non-free-firmware is not treated correctly
* documentation references old codenames
* czech translation incomplete
* `debian/copyright` file and licensing is unreliable

[ Tests ]
(What automated or manual tests cover the affected code?)

All changes have been accompanied by regression tests to the best of my
knowledge.

[ Risks ]
The code changes are reasonably small and well tested.

[ Checklist ]
  [!] all changes are documented in the d/changelog

 Sigh, two editorial changes were marked ignore in the git commits
 which I did not notice when merging:


https://salsa.debian.org/apt-team/apt/-/commit/e90ba0afa2a27ecea792e8039b2917ec55647548

https://salsa.debian.org/apt-team/apt/-/commit/edcdc251c527141bddb502e799d9a3911a73841b

They do not affect the binaries produced. 

Some changes were squashed together in the changelog editing as they were 
redundant (e.g.
two Ubuntu codename update commits are squashed into "update codenames").

  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
(Anything else the release team 

Bug#1033025: unblock: socklog/2.1.0+repack-5

[Sebastian Ramacher]

Control: tags -1 moreinfo

Hi Mathieu

On 2023-03-15 23:05:39 +0100, Mathieu Mirmont wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: sock...@packages.debian.org
> Control: affects -1 + src:socklog
> 
> Please unblock package socklog
> 
> [ Reason ]
> Fix RC bug #1031794.
> 
> [ Impact ]
> No change of behaviour.
> 
> [ Tests ]
> After a manual package install and update the services socklog-klog
> and socklog-unix run fine. Also dpkg-source -x does not complain
> anymore.
> 
> [ Risks ]
> Low, the changes are trivial.
> 
> [ Checklist ]
>   [X] all changes are documented in the d/changelog
>   [X] I reviewed all changes and I approve them
>   [X] attach debdiff against the package in testing
> 
> [ Other info ]
> I was hoping to get this pushed before the hard freeze but I wasn't
> lucky finding an uploader on time. The changes are therefore a bit
> more than what I would want at this point but they are all trivial.
> 
> unblock socklog/2.1.0+repack-5
> 
> -- 
> Mathieu Mirmont 

> diff -Nru socklog-2.1.0+repack/debian/changelog 
> socklog-2.1.0+repack/debian/changelog
> --- socklog-2.1.0+repack/debian/changelog 2020-12-22 22:40:42.0 
> +0100
> +++ socklog-2.1.0+repack/debian/changelog 2023-03-06 22:01:18.0 
> +0100
> @@ -1,3 +1,15 @@
> +socklog (2.1.0+repack-5) unstable; urgency=medium
> +
> +  * Various uninteresting changes

What are these uninteresting changes?

> +  * watch, repack.sh: append +repack to tarball filename
> +  * Refresh lintian overrides
> +  * service/socklog-unix: remove supervise symlink (Closes: #1031794)
> +  * control: bump debian policy to 4.6.2, no change required
> +  * gitlab-ci.yml: disable unnecessary jobs
> +  * gbp.conf: add configuration file
> +
> + -- Mathieu Mirmont   Mon, 06 Mar 2023 22:01:18 +0100
> +
>  socklog (2.1.0+repack-4) unstable; urgency=medium
>  
>* copyright: bump the year
> diff -Nru socklog-2.1.0+repack/debian/control 
> socklog-2.1.0+repack/debian/control
> --- socklog-2.1.0+repack/debian/control   2020-12-22 22:40:42.0 
> +0100
> +++ socklog-2.1.0+repack/debian/control   2023-03-06 21:52:36.0 
> +0100
> @@ -5,7 +5,7 @@
>  Uploaders: Gerrit Pape 
>  Vcs-Browser: https://salsa.debian.org/debian/socklog
>  Vcs-Git: https://salsa.debian.org/debian/socklog.git
> -Standards-Version: 4.5.1
> +Standards-Version: 4.6.2
>  Homepage: http://smarden.org/socklog
>  Build-Depends: debhelper-compat (= 13),
> dh-runit,
> @@ -37,9 +37,8 @@
>   ${misc:Depends}, ${shlibs:Depends}
>  Recommends: ipsvd, mailx
>  Provides: system-log-daemon, linux-kernel-log-daemon
> -Conflicts: system-log-daemon, linux-kernel-log-daemon, ${runit:Conflicts}
> -Breaks: socklog (<= 2.1.0+repack-3), ${runit:Breaks}
> -Replaces: socklog (<= 2.1.0+repack-3)
> +Conflicts: system-log-daemon, linux-kernel-log-daemon
> +Breaks: ${runit:Breaks}

What's the rationale behind those changes?

Cheers

>  Description: system and kernel logging services - runit services
>   socklog cooperates with the runit package to create a small and
>   secure replacement for rsyslog. socklog supports system logging
> diff -Nru socklog-2.1.0+repack/debian/copyright 
> socklog-2.1.0+repack/debian/copyright
> --- socklog-2.1.0+repack/debian/copyright 2020-11-23 16:13:31.0 
> +0100
> +++ socklog-2.1.0+repack/debian/copyright 2023-03-06 21:52:36.0 
> +0100
> @@ -9,7 +9,7 @@
>  
>  Files: debian/*
>  Copyright: Copyright 2001-2008, Gerrit Pape 
> - 2019-2020, Mathieu Mirmont 
> + 2019-2023, Mathieu Mirmont 
>  License: BSD-3-clause
>  
>  License: BSD-3-clause
> diff -Nru socklog-2.1.0+repack/debian/gbp.conf 
> socklog-2.1.0+repack/debian/gbp.conf
> --- socklog-2.1.0+repack/debian/gbp.conf  1970-01-01 01:00:00.0 
> +0100
> +++ socklog-2.1.0+repack/debian/gbp.conf  2023-03-06 22:01:10.0 
> +0100
> @@ -0,0 +1,3 @@
> +[DEFAULT]
> +pristine-tar = True
> +sign-tags = True
> diff -Nru socklog-2.1.0+repack/debian/gitlab-ci.yml 
> socklog-2.1.0+repack/debian/gitlab-ci.yml
> --- socklog-2.1.0+repack/debian/gitlab-ci.yml 2020-11-02 03:12:15.0 
> +0100
> +++ socklog-2.1.0+repack/debian/gitlab-ci.yml 2023-03-06 21:52:36.0 
> +0100
> @@ -1,3 +1,7 @@
>  include:
>- https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
>- 
> https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
> +
> +variables:
> +  SALSA_CI_DISABLE_BUILD_PACKAGE_ALL: 1
> +  SALSA_CI_DISABLE_AUTOPKGTEST: 1
> diff -Nru socklog-2.1.0+repack/debian/repack.sh 
> socklog-2.1.0+repack/debian/repack.sh
> --- socklog-2.1.0+repack/debian/repack.sh 2020-11-02 01:53:45.0 
> +0100
> +++ socklog-2.1.0+repack/debian/repack.sh 2023-03-06 21:52:36.0 
> +0100
> @@ -1,12 +1,13 @@
>  #!/bin/sh
> +set -eu
>  
>  # Command line check.
> -if [ $# -ne 3 ] 

Processed: Re: Bug#1033025: unblock: socklog/2.1.0+repack-5

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo
Bug #1033025 [release.debian.org] unblock: socklog/2.1.0+repack-5
Added tag(s) moreinfo.

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

Processed: Re: Bug#1032993: release.debian.org: key packages: mksh should not be a key package

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 Build-Depends for tests should not be key packages
Bug #1032993 [release.debian.org] release.debian.org: key packages: mksh should 
not be a key package
Changed Bug title to 'Build-Depends for tests should not be key packages' from 
'release.debian.org: key packages: mksh should not be a key package'.
> tags -1 confirmed
Bug #1032993 [release.debian.org] Build-Depends for tests should not be key 
packages
Added tag(s) confirmed.

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

Bug#1032993: release.debian.org: key packages: mksh should not be a key package

[Paul Gevers]

Control: retitle -1 Build-Depends for tests should not be key packages
Control: tags -1 confirmed

Hi Thorsten,

On 15-03-2023 12:55, Thorsten Glaser wrote:

mksh is only a key package because shunit2 build-depends on it.


Ack.


(Would be nice if the key package status is shown in tracker or so…
I was surprised by its presence in the list.)


That would need somebody to work on a patch for the tracker. :)


However, shunit2 only uses it at build time to run its tests
against and its testsuite runner only fails if the last shell,
which is zsh, fails.


Which is a bug in shunit2. Has that been reported?

Anyways, to come back to your request, we already communicated [1] that 
we intend to change the key package situation, but that will be after 
the bookworm release.


Paul

[1] https://lists.debian.org/debian-devel-announce/2022/10/msg4.html 
section "nocheck and nodoc build profiles"


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032968: unblock: passt/0.0~git20230309.7c7625d-1

[Paul Gevers]

Hi Stefano,

On 14-03-2023 22:44, Stefano Brivio wrote:

- full slirp4netns(1) compatibility not granted


I've never heard of this before, what does that mean for the user?


[ Tests ]
I ran the upstream test suite against the packaged version on a
Debian testing (Bookworm) x86_64 system.


If you can do this manually, you can probably also do it automatically. 
If you turn this into an autopkgtest [1] your package could migrate 
without our intervention (providing that it passes on all architectures 
where the binary builds and that it tests a substantial part of the 
as-installed binaries). See 
https://release.debian.org/testing/freeze_policy.html#hard section "Soft 
freeze for non-key packages with autopkgtests"


Apart from the migration benefits, adding an autopkgtest will also 
prevent dependencies from breaking your package unnoticed (in testing) 
in the future because they will be prevented from migration.


Paul

[1] 
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032899: unblock: rocm-hipamd/5.2.3-6

[Étienne Mollier]

Hi all,

I feel responsible for several of the issues listed by Paul, as
my earlier activity matches the time frame of some of the
changes and problems.

Christian Kastner, on 2023-03-16:
> On 2023-03-16 10:31, Paul Gevers wrote:
> > Control: tags -1 moreinfo On 16-03-2023 00:16, Christian Kastner 
> > wrote: For next time, can you please contact us earlier? We could 
> > have solved the earlier problems in testing-proposed-updates (in 
> > January), then we would now be in a better position.
> 
> I didn't think of that solution as the RC-blocked dependency was only
> available in unstable, and admittedly because I thought this would
> resolve itself in time.
> 
> But in any case: yes, earlier contact would have been helpful, and I'll
> do so in future.

Acknowledged, I must admit I had a similar perception of the
situation when I sloppily checked migration status two months
ago, and it didn't occur immediately to me that it would become
an entangled migration problem during hard freeze.  I'm sorry
about that.

> > By the way, I checked, but none of the ci.d.n host will run any of 
> > your tests, as none of them has an amdgpu (is that a thing you could 
> > expect on non-amd architectures by the way?).
> 
> Correct! Tests will be skipped on official infra.
> 
> It's not just a matter of the missing hardware (we have it, but DSA has
> understandable concerns), it's also about how to even express that a
> package needs a GPU to run its tests (build-time or autopkgtest).

Some kernel and hardware combinations may cause a host hangup,
e.g. the rocm-hipamd package version in testing doesn't
serialize properly tests and this causes a number of bus
contention errors when running the test suite, eventually
leading to a hangup.  I also have a more concerning case of a
test item running into a potential kernel bug on rx6800, which
I'm long overdue to investigate in depth with competent kernel
people (actually I'm unable to tell whether the hardware or the
kernel is at fault thus far, as the crash occurs in amdgpu ecc
functions).

There are other technical concerns regarding maintenance of
virtual machines and binding them to physical hardware due to
having to pass the GPU through the hardware.  The third issue
was it is almost always mandatory to run using non-free-firmware
that cannot be freely audited for passing tests.

The current combination of skippable tests with check on the
availability of kfd device is the best we managed achieve thus
far.

> I recently initiated a discussion about this [3]. For now, the idea to
> run parallel debci infra with guaranteed GPU presence, gather
> experience, and to eventually share proposals on how a GPU dependency
> could be expressed in d/control and d/tests/control.

(I'm overdue to answer to [3], but overall I was mostly fine
with the ideas and haven't spotted anything of concern yet.)

> > One thing I spotted along the way; the (Build-)Depends on llvm 
> > related packages use the *versioned* ones. Is there a reason not to 
> > use the unversioned ones from src:llvm-defaults? That would make llvm
> > transitions a bit easier.
> 
> I'd have to check with the co-maintainers who added it, but from what I
> gather so far, the ROCm stack needs a very recent llvm because of many
> changes being upstreamed there.

The ROCm stack is actually developed against a fork of llvm (the
rocm-llvm).  To avoid having to package more or less a code copy
of the native llvm, we target instead the next llvm-toolchain
version which contains upstreamed changes from rocm-llvm.  Even
that requires extensive patching, thankfully we have benefited
from the substantial help of people from AMD this far on that
front.

> > [1] https://lists.debian.org/debian-devel/2022/09/msg00105.html and 
> > follow-up 
> 
> [2] 
> https://github.com/torvalds/linux/blob/v6.2/drivers/gpu/drm/amd/amdkfd/Kconfig#L6-L8
> [3] https://lists.debian.org/debian-ai/2023/03/msg00038.html

Thank you for your work on putting together Debian 12 bookworm!

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/tty1, please excuse my verbosity
   `-on air: Status Minor - Feel My Hunger


signature.asc
Description: PGP signature

Processed: unblock: base-files/12.4

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:base-files
Bug #1033080 [release.debian.org] unblock: base-files/12.4
Added indication that 1033080 affects src:base-files

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

Bug#1033080: unblock: base-files/12.4

[Santiago Vila]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:base-files

Please unblock package base-files

[ Reason ]
It contains the changes everybody expects for bookworm as stable.

[ Tests ]
I've done my best double-checking that everything is correct.

[ Risks ]
The upload contains also other minor changes, but all of them are small,
all of them are low risk, and none of them should affect the end user.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]

Note 1: I'm actually using a diff in "git show" format,
because the old "copyright.in" is now simply "copyright"
and a debdiff would show this as a spurious big difference.

Note 2: All the changes in the licenses/* directory are really the
result of refreshing the licenses. I do not decide about those changes
nor I have a way to control them.

Thanks.

unblock base-files/12.4diff --git a/debian/README b/debian/README
index 01570a9..9ced2ea 100644
--- a/debian/README
+++ b/debian/README
@@ -4,10 +4,10 @@ Frequently Asked Questions about base-files
 * Questions about /etc/issue and /etc/debian_version:
 
 Q. I upgraded my system to the testing distribution and now my /etc/issue
-says "bookworm/sid". Should it not read "bookworm" or "testing"?
+says "trixie/sid". Should it not read "trixie" or "testing"?
 
 Q. I upgraded my system to the unstable distribution and now my /etc/issue
-says "bookworm/sid". Should it not read "sid" or "unstable"?
+says "trixie/sid". Should it not read "sid" or "unstable"?
 
 A. That would be nice, but it is not possible because of the way the
 testing distribution works. Packages uploaded for unstable reach
@@ -17,9 +17,9 @@ testing. You should consider the testing and unstable 
distributions as
 two sides of the same coin. Since the base-files package in testing
 was initially uploaded for unstable, the only sensible /etc/issue to
 have is one that is both valid for testing and unstable, hence
-"bookworm/sid" (or whatever is appropriate).
+"trixie/sid" (or whatever is appropriate).
 
-Q. Why "bookworm/sid" and not "testing/unstable" as it used to be?
+Q. Why "trixie/sid" and not "testing/unstable" as it used to be?
 
 A. The codename is a little bit more informative, as the meaning of
 "testing" changes over time.
diff --git a/debian/base-files.lintian-overrides 
b/debian/base-files.lintian-overrides
index d57f3a3..691e9e6 100644
--- a/debian/base-files.lintian-overrides
+++ b/debian/base-files.lintian-overrides
@@ -2,21 +2,21 @@
 # Permissions 0700 on /root are intentional as people expect
 # the /root directory to be more private than /home/* directories.
 #
-base-files: non-standard-dir-perm root/ 0700 != 0755
+base-files: non-standard-dir-perm 0700 != 0755 [root/]
 #
 # The /etc/os-release symlink is relative on purpose to avoid breaking dracut.
 # See Bug #755394 for details.
 #
-base-files: symlink-should-be-absolute etc/os-release ../usr/lib/os-release
+base-files: relative-symlink ../usr/lib/os-release [etc/os-release]
 #
 # The purpose of having licenses here is precisely to allow
 # other packages to reference them.
 #
-base-files: extra-license-file usr/share/common-licenses/Artistic
-base-files: extra-license-file usr/share/common-licenses/BSD
-base-files: extra-license-file usr/share/common-licenses/GPL-1
-base-files: extra-license-file usr/share/common-licenses/GPL-2
-base-files: extra-license-file usr/share/common-licenses/GPL-3
-base-files: extra-license-file usr/share/common-licenses/LGPL-2
-base-files: extra-license-file usr/share/common-licenses/LGPL-2.1
-base-files: extra-license-file usr/share/common-licenses/LGPL-3
+base-files: extra-license-file [usr/share/common-licenses/Artistic]
+base-files: extra-license-file [usr/share/common-licenses/BSD]
+base-files: extra-license-file [usr/share/common-licenses/GPL-1]
+base-files: extra-license-file [usr/share/common-licenses/GPL-2]
+base-files: extra-license-file [usr/share/common-licenses/GPL-3]
+base-files: extra-license-file [usr/share/common-licenses/LGPL-2]
+base-files: extra-license-file [usr/share/common-licenses/LGPL-2.1]
+base-files: extra-license-file [usr/share/common-licenses/LGPL-3]
diff --git a/debian/changelog b/debian/changelog
index 3259901..c9b9f12 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,29 @@
+base-files (12.4) unstable; urgency=medium
+
+  * Release candidate for bookworm as stable:
+  - Use "12" as version in /etc/issue and /etc/issue.net.
+(never expected to change after release)
+  - Use 12.0 as version in /etc/debian_version.
+(expected to change at every point release)
+  - Change PRETTY_NAME in /usr/lib/os-release, adding 12 as version number
+and "(bookworm)" as codename. Add also VERSION_ID and VERSION.
+(never expected to change)
+  - Variable VERSION_CODENAME was already defined as "book

Bug#1033079: bullseye-pu: package intel-microcode/3.20230214.1~deb11u1

[Tobias Frost]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: intel-microc...@packages.debian.org, Salvatore Bonaccorso 

Control: affects -1 + src:intel-microcode

(Please refer to #1032847#12 for security team's feedback
that this should go through SPU.)

The upload updates intel microcodes to target (See #1031334)
   - INTEL-SA-00700: CVE-2022-21216
   - INTEL-SA-00730: CVE-2022-33972
   - INTEL-SA-00738: CVE-2022-33196
   - INTEL-SA-00767: CVE-2022-38090

the CVEs are information disclosure via local access vulnerbilities and
potential privilege escalations.

I've updated the package in sid already (unblock request #1032847) and the
update of bookworm is the next step to get the CVEs fixed for LTS/ELTS.
I'm working on LTS (buster) and ELTS (stretch an jessie) as part of the
Freexian LTS/ELTS project)

This package is identical to the unstable version, with the exception that
unstable used the new firmware section and this package for bullseye is using
non-free.

To keep the fixes consistent, I'd like to let them flow from sid -> jessie…


[ Tests ]
I've tested that the package works on Intel hardware that I have access to.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


(I've already uploaded to bullseye-spu as I am confident that this upload will 
be accepted.
To avoid further delays for LTS/ELTS, I'd appreciate feedback whether this will 
be accepted,
so that I can proceed with uploading to buster, stretch and jessie without the 
need to have
weird version numbers :)

Thanks in advance,

-- 
tobi
diff -Nru intel-microcode-3.20220510.1~deb11u1/changelog 
intel-microcode-3.20230214.1~deb11u1/changelog
--- intel-microcode-3.20220510.1~deb11u1/changelog  2022-07-04 
20:10:32.0 +0200
+++ intel-microcode-3.20230214.1~deb11u1/changelog  2023-03-14 
19:17:02.0 +0100
@@ -1,3 +1,84 @@
+2023-02-14:
+  * New Microcodes:
+sig 0x000806f4, pf_mask 0x10, 2022-12-19, rev 0x2c000170, size 600064
+sig 0x000806f4, pf_mask 0x87, 2022-12-27, rev 0x2b000181, size 561152
+sig 0x000806f5, pf_mask 0x10, 2022-12-19, rev 0x2c000170, size 600064
+sig 0x000806f5, pf_mask 0x87, 2022-12-27, rev 0x2b000181, size 561152
+sig 0x000806f6, pf_mask 0x10, 2022-12-19, rev 0x2c000170, size 600064
+sig 0x000806f6, pf_mask 0x87, 2022-12-27, rev 0x2b000181, size 561152
+sig 0x000806f7, pf_mask 0x87, 2022-12-27, rev 0x2b000181, size 561152
+sig 0x000806f8, pf_mask 0x10, 2022-12-19, rev 0x2c000170, size 600064
+sig 0x000806f8, pf_mask 0x87, 2022-12-27, rev 0x2b000181, size 561152
+sig 0x000b06a2, pf_mask 0xc0, 2022-12-08, rev 0x410e, size 212992
+sig 0x000b06a3, pf_mask 0xc0, 2022-12-08, rev 0x410e, size 212992
+
+  * Updated Microcodes:
+sig 0x00050653, pf_mask 0x97, 2022-08-30, rev 0x1000161, size 36864
+sig 0x00050656, pf_mask 0xbf, 2022-08-26, rev 0x4003303, size 37888
+sig 0x00050657, pf_mask 0xbf, 2022-08-26, rev 0x5003303, size 37888
+sig 0x0005065b, pf_mask 0xbf, 2022-08-26, rev 0x7002503, size 29696
+sig 0x000606a6, pf_mask 0x87, 2022-10-09, rev 0xd000389, size 296960
+sig 0x000606c1, pf_mask 0x10, 2022-09-23, rev 0x1000211, size 289792
+sig 0x000706a1, pf_mask 0x01, 2022-09-16, rev 0x003e, size 75776
+sig 0x000706a8, pf_mask 0x01, 2022-09-20, rev 0x0022, size 76800
+sig 0x000706e5, pf_mask 0x80, 2022-08-31, rev 0x00b8, size 113664
+sig 0x000806a1, pf_mask 0x10, 2022-09-07, rev 0x0032, size 34816
+sig 0x00090672, pf_mask 0x07, 2023-01-04, rev 0x002c, size 219136
+sig 0x00090675, pf_mask 0x07, 2023-01-04, rev 0x002c, size 219136
+sig 0x000906a3, pf_mask 0x80, 2023-01-11, rev 0x0429, size 218112
+sig 0x000906a4, pf_mask 0x80, 2023-01-11, rev 0x0429, size 218112
+sig 0x000906c0, pf_mask 0x01, 2022-09-02, rev 0x2424, size 20480
+sig 0x000a0671, pf_mask 0x02, 2022-08-31, rev 0x0057, size 103424
+sig 0x000b0671, pf_mask 0x32, 2022-12-19, rev 0x0112, size 207872
+sig 0x000b06f2, pf_mask 0x07, 2023-01-04, rev 0x002c, size 219136
+sig 0x000b06f5, pf_mask 0x07, 2023-01-04, rev 0x002c, size 219136
+
+2022-11-08:
+  * New Microcodes:
+sig 0x000606c1, pf_mask 0x10, 2022-08-07, rev 0x1000201, size 286720
+sig 0x000b0671, pf_mask 0x32, 2022-09-07, rev 0x010e, size 204800
+
+  * Updated Microcodes:
+sig 0x000706e5, pf_mask 0x80, 2022-08-02, rev 0x00b6, size 113664
+sig 0x000806c1, pf_mask 0x80, 2022-06-28, rev 0x00a6, size 110592
+sig 0x000806d1, pf_mask 0xc2, 2022-06-28, rev 0x0042, size 102400
+sig 0x000806ec, pf_mask 0x94, 2022-07-31, rev 0x00f4, size 105472
+sig 0x00090661, pf_mask 0x01, 2022-07-15, rev 0x0017, size 20480
+sig 0x00090672, pf_mask 0x07, 2022-09-19, rev 0x0026, size 218112
+sig 0x00090675, pf_mask 0x07, 2022-09-19, rev 0x0026
+sig 0x000b06f2, pf_

Bug#1033078: unblock: flatpak/1.14.4-1

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: flat...@packages.debian.org, secur...@debian.org
Control: affects -1 + src:flatpak

Please unblock package flatpak

[ Reason ]
New upstream stable release fixing a security issue.

[ Impact ]
CVE-2023-28101: A malicious Flatpak app could prevent the flatpak(1) CLI
from displaying its permissions as intended, by having crafted permissions
or other metadata containing terminal escape sequences or other special
characters.

CVE-2023-28100: A malicious Flatpak app could execute code outside the
sandbox if run from a Linux virtual console. (Mitigation: I'm fairly
sure nobody actually does this, because Flatpak is intended to be used
in a Wayland or X11 environment; running it from an xterm or equivalent
is not vulnerable.)

[ Tests ]
The automated test suite is run at build-time and by autopkgtest, and
still passes. It includes tests for the two CVE issues. Coverage on buildds
and lxc is not great, because we're unable to actually run Flatpak apps in
that environment, but I ran the autopkgtest in qemu before upload and that
also passes.

[ Risks ]
Low risk, targeted fixes only. The only non-security change is a
translation update.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
As with bullseye, I'm involved in upstream release management, and I'd
like to make use of upstream stable releases for stable/security updates
in preference to forking the upstream codebase for Debian.

unblock flatpak/1.14.4-1
debdiff *.dsc | filterdiff -p1 -x'po/*.po' -x 'po/*.pot' -xconfigure

diffstat for flatpak-1.14.3 flatpak-1.14.4

 NEWS|   20 +
 app/flatpak-builtins-info.c |8 
 app/flatpak-builtins-remote-info.c  |5 
 app/flatpak-cli-transaction.c   |   17 -
 common/flatpak-context.c|   36 ++
 common/flatpak-run.c|4 
 common/flatpak-utils-private.h  |   14 +
 common/flatpak-utils.c  |  121 +
 common/flatpak-version-macros.h |2 
 configure   |   26 +-
 configure.ac|2 
 debian/changelog|   15 +
 doc/reference/html/flatpak-Version-information.html |2 
 doc/reference/html/index.html   |2 
 po/cs.po|  204 
 po/da.po|  204 
 po/de.po|  204 
 po/en_GB.po |  204 
 po/es.po|  204 
 po/flatpak.pot  |  206 
 po/fr.po|  204 
 po/gl.po|  204 
 po/hi.po|  204 
 po/hr.po|  204 
 po/hu.po|  204 
 po/id.po|  204 
 po/oc.po|  204 
 po/pl.gmo   |binary
 po/pl.po|  250 ++--
 po/pt.po|  204 
 po/pt_BR.po |  204 
 po/ro.po|  204 
 po/ru.po|  204 
 po/sk.po|  204 
 po/sv.po|  204 
 po/tr.po|  204 
 po/uk.po|  204 
 po/zh_CN.po |  204 
 po/zh_TW.po |  204 
 tests/make-test-app.sh  |8 
 tests/package_version.txt   |2 
 tests/test-context.c|   84 ++
 tests/test-info.sh  |   14 -
 tests/test-seccomp.sh   |8 
 tests/testcommon.c  |   74 +
 tests/try-syscall.c 

Processed: bullseye-pu: package intel-microcode/3.20230214.1~deb11u1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:intel-microcode
Bug #1033079 [release.debian.org] bullseye-pu: package 
intel-microcode/3.20230214.1~deb11u1
Added indication that 1033079 affects src:intel-microcode

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

Bug#1033076: unblock: python-motor/2.3.0-3

[Étienne Mollier]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: python-mo...@packages.debian.org
Control: affects -1 + src:python-motor

Please unblock package python-motor

[ Reason ]
python-motor in testing is affected by the grave RC bug #1031763
reported by an end user.

[ Impact ]
If python-motor doesn't migrate, the RC bug will cause a removal
of the package from bookworm, but it won't pull reverse
dependencies in the process on first sight.  Overall impact
looks thus somewhat low.

[ Tests ]
I didn't run the test suite as I discovered the registered
autopkgtest needed a package mongodb-server, which is not
available in any section of the archive currently.  Build time
tests also require a running mongodb server to be actually
executed, which I don't have at hand, nor I have the energy to
deploy.  Best I could do was to mimick autodep8 in unstable and
testing context:

(sid-amd64-sbuild)$ python3
Python 3.11.2 (main, Mar  5 2023, 08:28:49) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import motor
>>> motor


(testing-amd64-sbuild)$ python3
Python 3.11.2 (main, Feb 12 2023, 00:48:52) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import motor
>>> motor


[ Risks ]
As I didn't extensively test the package, it is quite possible
issues are hidden, but I didn't get any (negative) feedback from
the bug submitter so far, so maybe things are okay after all.

The package does not have reverse dependencies so risks of
affecting other packages look low.

[ Checklist ]
  [*] all changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in testing

[ Other info ]
There was a standards version bump from 4.5.1 to 4.6.2 by the
Janitor lingering in the repository.  Said bump didn't seem to
require changes from packaging perspective, so I kept the
modification as is.  This change may be reverted if deemed not
appropriate.

unblock python-motor/2.3.0-3

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.
On air: Pendragon - Indigo
diff -Nru python-motor-2.3.0/debian/changelog 
python-motor-2.3.0/debian/changelog
--- python-motor-2.3.0/debian/changelog 2022-05-26 20:39:58.0 +0200
+++ python-motor-2.3.0/debian/changelog 2023-03-03 14:29:00.0 +0100
@@ -1,3 +1,17 @@
+python-motor (2.3.0-3) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Debian Janitor ]
+  * Update standards version to 4.6.2, no changes needed.
+
+  [ Étienne Mollier ]
+  * python-3.11.patch: add patch from upstream.
+This fixes an import error of motor.motor_asyncio.
+Thanks to Andrey Rakhmatullin for the hint!  (Closes: #1031763)
+
+ -- Étienne Mollier   Fri, 03 Mar 2023 14:29:00 +0100
+
 python-motor (2.3.0-2) unstable; urgency=medium
 
   * Remove obsolete field Name from debian/upstream/metadata (already present 
in
diff -Nru python-motor-2.3.0/debian/control python-motor-2.3.0/debian/control
--- python-motor-2.3.0/debian/control   2022-05-26 20:39:58.0 +0200
+++ python-motor-2.3.0/debian/control   2023-03-03 14:29:00.0 +0100
@@ -7,7 +7,7 @@
dh-python,
python3-all,
python3-setuptools,
-Standards-Version: 4.5.1
+Standards-Version: 4.6.2
 Homepage: https://github.com/mongodb/motor
 Vcs-Browser: https://salsa.debian.org/python-team/packages/python-motor
 Vcs-Git: https://salsa.debian.org/python-team/packages/python-motor.git
diff -Nru python-motor-2.3.0/debian/patches/python-3.11.patch 
python-motor-2.3.0/debian/patches/python-3.11.patch
--- python-motor-2.3.0/debian/patches/python-3.11.patch 1970-01-01 
01:00:00.0 +0100
+++ python-motor-2.3.0/debian/patches/python-3.11.patch 2023-03-03 
14:29:00.0 +0100
@@ -0,0 +1,34 @@
+Description: fix asyncio.coroutine import error with python3.11
+Author: Steven Silvester
+Bug: https://github.com/mongodb/motor/pull/185
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031763
+Reviewed-By: Étienne Mollier 
+Last-Update: 2023-03-03
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- python-motor.orig/motor/frameworks/asyncio/__init__.py
 python-motor/motor/frameworks/asyncio/__init__.py
+@@ -25,7 +25,6 @@
+ import os
+ import warnings
+ 
+-from asyncio import coroutine  # For framework interface.
+ from concurrent.futures import ThreadPoolExecutor
+ 
+ 
+@@ -34,6 +33,15 @@
+ except ImportError:
+ contextvars = None
+ 
++try:
++from asyncio import coroutine
++except ImportError:
++
++def coroutine():
++raise RuntimeError(
++"The coroutine decorator was removed in Python 3.11.  Use 'async 
def' instead"
++)

Processed: unblock: strongswan/5.9.8-5

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:strongswan
Bug #1033075 [release.debian.org] unblock: strongswan/5.9.8-5
Added indication that 1033075 affects src:strongswan

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

Processed: unblock: flatpak/1.14.4-1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:flatpak
Bug #1033078 [release.debian.org] unblock: flatpak/1.14.4-1
Added indication that 1033078 affects src:flatpak

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

Bug#1033075: unblock: strongswan/5.9.8-5

[Yves-Alexis Perez]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: strongs...@packages.debian.org
Control: affects -1 + src:strongswan

Hi release team,

I've updated the strongSwan package in sid few days ago to fix a
security issue (only present in testing/sid, not stable). The timing
(with the freeze) wasn't perfect, and I actually lost a couple of days
by uploading the binary instead of the sources.

I'm unsure why it didn't migrate with the new freeze policy (it had 10
days) but could you let it migrate now? The changes are minimal and
actually fix a security issue.

unblock strongswan/5.9.8-5

Processed: unblock: python-motor/2.3.0-3

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:python-motor
Bug #1033076 [release.debian.org] unblock: python-motor/2.3.0-3
Added indication that 1033076 affects src:python-motor

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

Bug#1033074: unblock: base-files/12.4

[Santiago Vila]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:base-files

Please unblock package base-files

[ Reason ]
It contains the changes everybody expects for bookworm as stable.

[ Tests ]
I've done my best double-checking that everything is correct.

[ Risks ]
The upload contains also other minor changes, but all of them are small,
all of them are low risk, and none of them should affect the end user.

[ Checklist ]
   [X] all changes are documented in the d/changelog
   [X] I reviewed all changes and I approve them
   [X] attach debdiff against the package in testing

[ Other info ]

Note 1: I'm actually using a diff in "git show" format,
because the old "copyright.in" is now simply "copyright"
and a debdiff would show this as a spurious big difference.

Note 2: All the changes in the licenses/* directory are really the
result of refreshing the licenses. I do not decide about those changes
nor I have a way to control them.

Thanks.

unblock base-files/12.4diff --git a/debian/README b/debian/README
index 01570a9..9ced2ea 100644
--- a/debian/README
+++ b/debian/README
@@ -4,10 +4,10 @@ Frequently Asked Questions about base-files
 * Questions about /etc/issue and /etc/debian_version:
 
 Q. I upgraded my system to the testing distribution and now my /etc/issue
-says "bookworm/sid". Should it not read "bookworm" or "testing"?
+says "trixie/sid". Should it not read "trixie" or "testing"?
 
 Q. I upgraded my system to the unstable distribution and now my /etc/issue
-says "bookworm/sid". Should it not read "sid" or "unstable"?
+says "trixie/sid". Should it not read "sid" or "unstable"?
 
 A. That would be nice, but it is not possible because of the way the
 testing distribution works. Packages uploaded for unstable reach
@@ -17,9 +17,9 @@ testing. You should consider the testing and unstable 
distributions as
 two sides of the same coin. Since the base-files package in testing
 was initially uploaded for unstable, the only sensible /etc/issue to
 have is one that is both valid for testing and unstable, hence
-"bookworm/sid" (or whatever is appropriate).
+"trixie/sid" (or whatever is appropriate).
 
-Q. Why "bookworm/sid" and not "testing/unstable" as it used to be?
+Q. Why "trixie/sid" and not "testing/unstable" as it used to be?
 
 A. The codename is a little bit more informative, as the meaning of
 "testing" changes over time.
diff --git a/debian/base-files.lintian-overrides 
b/debian/base-files.lintian-overrides
index d57f3a3..691e9e6 100644
--- a/debian/base-files.lintian-overrides
+++ b/debian/base-files.lintian-overrides
@@ -2,21 +2,21 @@
 # Permissions 0700 on /root are intentional as people expect
 # the /root directory to be more private than /home/* directories.
 #
-base-files: non-standard-dir-perm root/ 0700 != 0755
+base-files: non-standard-dir-perm 0700 != 0755 [root/]
 #
 # The /etc/os-release symlink is relative on purpose to avoid breaking dracut.
 # See Bug #755394 for details.
 #
-base-files: symlink-should-be-absolute etc/os-release ../usr/lib/os-release
+base-files: relative-symlink ../usr/lib/os-release [etc/os-release]
 #
 # The purpose of having licenses here is precisely to allow
 # other packages to reference them.
 #
-base-files: extra-license-file usr/share/common-licenses/Artistic
-base-files: extra-license-file usr/share/common-licenses/BSD
-base-files: extra-license-file usr/share/common-licenses/GPL-1
-base-files: extra-license-file usr/share/common-licenses/GPL-2
-base-files: extra-license-file usr/share/common-licenses/GPL-3
-base-files: extra-license-file usr/share/common-licenses/LGPL-2
-base-files: extra-license-file usr/share/common-licenses/LGPL-2.1
-base-files: extra-license-file usr/share/common-licenses/LGPL-3
+base-files: extra-license-file [usr/share/common-licenses/Artistic]
+base-files: extra-license-file [usr/share/common-licenses/BSD]
+base-files: extra-license-file [usr/share/common-licenses/GPL-1]
+base-files: extra-license-file [usr/share/common-licenses/GPL-2]
+base-files: extra-license-file [usr/share/common-licenses/GPL-3]
+base-files: extra-license-file [usr/share/common-licenses/LGPL-2]
+base-files: extra-license-file [usr/share/common-licenses/LGPL-2.1]
+base-files: extra-license-file [usr/share/common-licenses/LGPL-3]
diff --git a/debian/changelog b/debian/changelog
index 3259901..c9b9f12 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,29 @@
+base-files (12.4) unstable; urgency=medium
+
+  * Release candidate for bookworm as stable:
+  - Use "12" as version in /etc/issue and /etc/issue.net.
+(never expected to change after release)
+  - Use 12.0 as version in /etc/debian_version.
+(expected to change at every point release)
+  - Change PRETTY_NAME in /usr/lib/os-release, adding 12 as version number
+and "(bookworm)" as codename. Add also VERSION_ID and VERSION.
+(never expected to change)
+  - Variable VERSION_CODENAME was already defined as "b

Processed: unblock: base-files/12.4

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:base-files
Bug #1033074 [release.debian.org] unblock: base-files/12.4
Added indication that 1033074 affects src:base-files

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

Bug#1032968: unblock: passt/0.0~git20230309.7c7625d-1

[Stefano Brivio]

On Thu, 16 Mar 2023 16:22:33 +0100
Paul Gevers  wrote:

> Hi Stefano,
> 
> On 14-03-2023 22:44, Stefano Brivio wrote:
> > - full slirp4netns(1) compatibility not granted  
> 
> I've never heard of this before, what does that mean for the user?

pasta(1) is supposed to provide a drop-in replacement for
slirp4netns(1): you create a network namespace, as a regular user, and
it can give that namespace network connectivity without creating any
interface outside it.

The main distinction is that it's written with performance, IPv6, and
security in mind, but functionally it's supposed to be a superset of it.

It has other functionalities (such as full IPv6 support), so it's not
useless otherwise, but it's probably unexpected for users (and I see
it as a source of potential bugs) that they can't set an outbound
address as they could do it on slirp4netns.

> > [ Tests ]
> > I ran the upstream test suite against the packaged version on a
> > Debian testing (Bookworm) x86_64 system.  
> 
> If you can do this manually, you can probably also do it automatically. 
> If you turn this into an autopkgtest [1] your package could migrate 
> without our intervention (providing that it passes on all architectures 
> where the binary builds and that it tests a substantial part of the 
> as-installed binaries).

Salsa seems to be inaccessible at the moment (and I can't fetch that
link from archive.org), but yes, I started reading about it just after
I realised the migration was blocked, so I know a bit already.

The current problem with the upstream test suite is that it takes a
long time to complete, and has a lot of dependencies, including things
that are not packaged in Debian (e.g. https://github.com/google/neper/).

But most of those dependencies (and time) are only needed for
performance tests, and we're working to refactor the test framework to
make it reasonably modular. It's not exactly trivial as we spawn virtual
machines and there are context dependencies between test cases, so it
will probably take a while. Just to give an idea, screen capture of
latest run:

  https://passt.top/#continuous-integration

Once that is done, it should be trivial (from what I remember of the
document you linked) to create autopkgtests for it.

We also have optional tests (which I run from time to time) to check
build and basic functionality on several distributions, including a few
flavours of Debian:

  https://passt.top/passt/tree/test/distro/debian

but that makes little sense now that it's packaged (and that we'll be
able to have distribution tests... in distributions, eventually).

-- 
Stefano

Bug#1033070: unblock: node-babel7/7.20.15+ds1+~cs214.269.168-2

[Pirate Praveen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: node-bab...@packages.debian.org
Control: affects -1 + src:node-babel7

Please unblock package node-babel7

[ Reason ]
This prevents breaking partial upgrades by updating minimum version of 
node-regexpu-core


[ Impact ]
gitlab partial upgrade from bullseye to bookworm is found to break when 
node-regexpu-core is not upgraded.

https://git.fosscommunity.in/debian-ruby/TaskTracker/-/issues/192

[ Tests ]
No upstream code changed, only minimum version of dependency is updated.

[ Risks ]
No upstream code changed, only minimum version of dependency is updated.

[ Checklist ]
 [x] all changes are documented in the d/changelog
 [x] I reviewed all changes and I approve them
 [x] attach debdiff against the package in testing

[ Other info ]

unblock node-babel7/7.20.15+ds1+~cs214.269.168-2


diff -Nru node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog
--- node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog	2023-02-17 13:35:54.0 +0530
+++ node-babel7-7.20.15+ds1+~cs214.269.168/debian/changelog	2023-03-16 17:52:46.0 +0530
@@ -1,3 +1,11 @@
+node-babel7 (7.20.15+ds1+~cs214.269.168-2) unstable; urgency=medium
+
+  * Update minimum version of node-regexpu-core to 5.2.1~.
+packages/babel-helper-create-regexp-features-plugin/package.json has
+"regexpu-core": "^5.2.1" and not adding it breaks partial upgrades.
+
+ -- Pirate Praveen   Thu, 16 Mar 2023 17:52:46 +0530
+
 node-babel7 (7.20.15+ds1+~cs214.269.168-1) unstable; urgency=medium
 
   * Team upload
diff -Nru node-babel7-7.20.15+ds1+~cs214.269.168/debian/control node-babel7-7.20.15+ds1+~cs214.269.168/debian/control
--- node-babel7-7.20.15+ds1+~cs214.269.168/debian/control	2023-02-17 13:35:54.0 +0530
+++ node-babel7-7.20.15+ds1+~cs214.269.168/debian/control	2023-03-16 17:52:20.0 +0530
@@ -108,7 +108,7 @@
  , node-make-dir
  , node-quick-lru
  , node-regenerator-transform (>= 0.14~)
- , node-regexpu-core
+ , node-regexpu-core (>= 5.2.1~)
  , node-resolve
  , node-semver (>= 7.0~)
  , node-slash

Processed: unblock: node-babel7/7.20.15+ds1+~cs214.269.168-2

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:node-babel7
Bug #1033070 [release.debian.org] unblock: 
node-babel7/7.20.15+ds1+~cs214.269.168-2
Added indication that 1033070 affects src:node-babel7

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

Bug#1033067: unblock: glide/2002.04.10ds1-21

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: gl...@packages.debian.org
Control: affects -1 + src:glide

Please unblock package glide

[ Reason ]

This non-key package does not currently contain autopkgtests.

These two releases include a couple of changes to make the package
finally reproducible, as the generated shared libraries would change
the optimized objects being linked to depending on the build system
(for host=i386 build=amd64).

[ Impact ]

Same generated objects regardless of the build system being used.

[ Tests ]

The tests were performed locally in an amd64 host and an i386 chroot,
before and after the fixes, and the reproducible builds are now green
for i386 for this package.

[ Risks ]

The risks seem minimal, as this is just making sure the build always
behaves in the same way.

[ Checklist ]

  [√] all changes are documented in the d/changelog
(There is the grammar fix in the changelog itself, which I do not
 tend to mention explicitly as it seems unnecessary verbiage.)
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in testing

[ Other info ]

(nothing)


unblock glide/2002.04.10ds1-21

Thanks,
Guillem
diff -Nru glide-2002.04.10ds1/debian/changelog 
glide-2002.04.10ds1/debian/changelog
--- glide-2002.04.10ds1/debian/changelog2023-02-26 23:15:35.0 
+0100
+++ glide-2002.04.10ds1/debian/changelog2023-03-10 02:37:51.0 
+0100
@@ -1,6 +1,20 @@
+glide (2002.04.10ds1-21) unstable; urgency=medium
+
+  * Pass --build and --host to configure via chores.3dfx.
+
+ -- Guillem Jover   Fri, 10 Mar 2023 02:37:51 +0100
+
+glide (2002.04.10ds1-20) unstable; urgency=medium
+
+  * Use autoconf $host_cpu instead of «uname -m» to decide how to optimize
+and what to compile into the resulting objects, which was making the
+build unreproducible on i386 when built on an amd64 build system.
+
+ -- Guillem Jover   Sat, 04 Mar 2023 13:24:56 +0100
+
 glide (2002.04.10ds1-19) unstable; urgency=medium
 
-  * Enable LFS build options. This should ABI safe as the shared library
+  * Enable LFS build options. This should be ABI safe as the shared library
 does not expose any problematic type.
   * Actually show the debconf error when the target is not a symlink.
 
diff -Nru glide-2002.04.10ds1/debian/patches/no-uname.patch 
glide-2002.04.10ds1/debian/patches/no-uname.patch
--- glide-2002.04.10ds1/debian/patches/no-uname.patch   1970-01-01 
01:00:00.0 +0100
+++ glide-2002.04.10ds1/debian/patches/no-uname.patch   2023-03-04 
13:38:57.0 +0100
@@ -0,0 +1,30 @@
+Description: Use autoconf $host_cpu instead of «uname -m»
+ This was making the build unreproducible as the uname will return the build
+ system CPU and not the host one.
+Author: Guillem Jover 
+Origin: vendor
+Forwarded: no
+
+---
+ glide3x/configure.in |3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/glide3x/configure.in
 b/glide3x/configure.in
+@@ -142,6 +142,7 @@ AM_CONDITIONAL(FX_GLIDE_CVG, test x$FX_G
+ #
+ # Architecture
+ #
++AC_CANONICAL_HOST
+ AC_ARG_ENABLE([build-architecture],
+   [dnl
+   --enable-build-architecture Enable AMD 3DNow instructions 
[default=current]],
+@@ -152,7 +153,7 @@ AC_ARG_ENABLE([build-architecture],
+*)
+AC_MSG_ERROR([Illegal value (${enableval}) for 
--enable-build-architecture])
+;;
+-   esac],[FX_GLIDE_BUILD_ARCHITECTURE=`uname -m`])
++   esac],[FX_GLIDE_BUILD_ARCHITECTURE=$host_cpu])
+ AC_SUBST(FX_GLIDE_BUILD_ARCHITECTURE)
+ #
+ # Various tests needed at points in the build
diff -Nru glide-2002.04.10ds1/debian/patches/series 
glide-2002.04.10ds1/debian/patches/series
--- glide-2002.04.10ds1/debian/patches/series   2022-07-17 18:28:36.0 
+0200
+++ glide-2002.04.10ds1/debian/patches/series   2023-03-04 13:16:21.0 
+0100
@@ -36,3 +36,4 @@
 z12-local-libtool
 z13-install-perms
 no-x11.patch
+no-uname.patch
diff -Nru glide-2002.04.10ds1/debian/rules glide-2002.04.10ds1/debian/rules
--- glide-2002.04.10ds1/debian/rules2023-02-25 15:42:22.0 +0100
+++ glide-2002.04.10ds1/debian/rules2023-03-10 01:34:56.0 +0100
@@ -10,6 +10,12 @@
 
 include /usr/share/dpkg/default.mk
 
+ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
+  confflags += --build=$(DEB_HOST_GNU_TYPE)
+else
+  confflags += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
+endif
+
 ifeq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
 ifeq ($(DEB_HOST_ARCH),alpha)
   CFLAGS += -mcpu=ev5 -fomit-frame-pointer \
@@ -32,6 +38,7 @@
   cd $(CURDIR)/glide3x; \
   mkdir $(CURDIR)/debian/tmp.$(1); \
   ./chores.3dfx --generate "--configure=--enable-fx-glide-hw=$(1) \
+$(confflags) \
 --prefix=/usr" --build-dir=build.$(1); \
   cd build.$(1); \
   ./build.3dfx --no-x DESTDIR="$(CURDIR)/debian/tmp.$(1)/" \

Processed: unblock: glide/2002.04.10ds1-21

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:glide
Bug #1033067 [release.debian.org] unblock: glide/2002.04.10ds1-21
Added indication that 1033067 affects src:glide

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

Bug#1032999: unblock: mesa/22.3.6-1

[Timo Aaltonen]

Paul Gevers kirjoitti 15.3.2023 klo 21.46:

Hi Timo,

On 15-03-2023 19:15, Timo Aaltonen wrote:
There's actually 22.3.7 out, which I was thinking of uploading to sid, 


Is that following the freeze policy [1]? I.e. targeted fixes? (It might 
be, I don't know the release policy of mesa).


Mesa does quarterly feature releases, and then bugfix releases on top of 
those. 22.3 was the feature release, 22.3.x are for bugfixes only. So 
yes, it does follow the policy. 23.0 is the latest release and will stay 
in experimental until bookworm is out.


since it's the last release of the 22.3.x series. Maybe that should be 
requested to be unblocked instead once it's available?


Well, it's blocked by something else, having *this* version tested in 
unstable is worth quite a bit for us. So, please only upload that 
version if it meets the freeze policy.


Paul


I think it makes sense to let 22.3.6 migrate first, and not risk that by 
another upload at this time. Once it has migrated, I'll see if 22.3.7-1 
could make it to the release or not.



--
t

Bug#1033062: unblock: dhcpcd5/9.4.1-21

[Martin-Éric Racine]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: dhcp...@packages.debian.org
Control: affects -1 + src:dhcpcd5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package dhcpcd5

[ Reason ]
This and the previous upload contain important documentation changes to 
facilitate migration from Stable.

[ Impact ]
Missing an important piece of information that might save them some guesswork 
when updating config files.

[ Tests ]
No code change. It's purely a debian/control and debian/NEWS change.

[ Risks ]
None. It's purely a debian/control and debian/NEWS change.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock dhcpcd5/9.4.1-21

[ Debdiff ]
- --- dhcpcd5-9.4.1/debian/changelog2023-02-19 15:13:44.0 +0200
+++ dhcpcd5-9.4.1/debian/changelog  2023-03-14 13:00:16.0 +0200
@@ -1,3 +1,18 @@
+dhcpcd5 (9.4.1-21) unstable; urgency=medium
+
+  * Document migration to Predictable Network Interface Names in NEWS.Debian.
+Specify Debian 12 (Bookworm) as the release where this got implemented.
+
+ -- Martin-Éric Racine   Tue, 14 Mar 2023 13:00:16 
+0200
+
+dhcpcd5 (9.4.1-20) unstable; urgency=medium
+
+  * Finalize debian/control dependencies and phrasing.
++ Specify that Linux ports utilize Predictable Network Interface Names.
+= Move Suggests on resolvconf to dhcpcd-base.
+
+ -- Martin-Éric Racine   Fri, 03 Mar 2023 09:21:00 
+0200
+
 dhcpcd5 (9.4.1-19) unstable; urgency=medium
 
   [ lintian-brush ]
diff -Nru dhcpcd5-9.4.1/debian/control dhcpcd5-9.4.1/debian/control
- --- dhcpcd5-9.4.1/debian/control  2023-02-18 07:15:24.0 +0200
+++ dhcpcd5-9.4.1/debian/control2023-03-12 09:57:19.0 +0200
@@ -11,26 +11,6 @@
 Vcs-Browser: https://salsa.debian.org/debian/dhcpcd5
 Vcs-Git: https://salsa.debian.org/debian/dhcpcd5.git
 
- -Package: dhcpcd
- -Architecture: all
- -Depends: dhcpcd-base,
- - sysvinit-utils (>= 3.05-4~) | lsb-base (>= 3.0-6),
- - ${misc:Depends},
- - ${shlibs:Depends}
- -Provides: dhcpcd
- -Replaces: dhcpcd5 (<< 9.4.1-12)
- -Breaks: dhcpcd5 (<< 9.4.1-12)
- -Suggests: dhcpcd-gtk,
- -  openresolv | resolvconf
- -Description: DHCPv4 and DHCPv6 dual-stack client (init.d script and systemd 
unit)
- - dhcpcd provides seamless IPv4 and IPv6 auto-configuration.
- - .
- - This package provides the optional init.d script and systemd units.
- - .
- - It can be safely purged on systems where interfaces are configured
- - by ifupdown via  using the DHCP method with
- - binaries provided by dhcpcd-base.
- -
 Package: dhcpcd-base
 Architecture: any
 Conflicts: dhcp-client
@@ -42,6 +22,7 @@
  ${misc:Depends},
  ${shlibs:Depends}
 Recommends: wpasupplicant
+Suggests: resolvconf | openresolv | systemd-resolved
 Description: DHCPv4 and DHCPv6 dual-stack client (binaries and exit hooks)
  dhcpcd provides seamless IPv4 and IPv6 auto-configuration:
   * DHCPv4 client
@@ -58,8 +39,29 @@
  where interfaces are configured by ifupdown via 
  using the DHCP method.
  .
- - The init.d script and systemd unit required for systems without ifupdown are
- - packaged separately as dhcpcd.
+ The init.d script and systemd service required for systems without ifupdown
+ are packaged separately as dhcpcd.
+ .
+ Since Debian 12 (Bookworm), dhcpcd uses Predictable Network Interface Names
+ on Linux ports. See NEWS.Debian for more details.
+
+Package: dhcpcd
+Architecture: all
+Depends: dhcpcd-base,
+ sysvinit-utils (>= 3.05-4~) | lsb-base (>= 3.0-6),
+ ${misc:Depends},
+ ${shlibs:Depends}
+Provides: dhcpcd
+Replaces: dhcpcd5 (<< 9.4.1-12)
+Breaks: dhcpcd5 (<< 9.4.1-12)
+Suggests: dhcpcd-gtk
+Description: DHCPv4 and DHCPv6 dual-stack client (init.d script and systemd 
unit)
+ dhcpcd provides seamless IPv4 and IPv6 auto-configuration.
+ .
+ This package provides the optional init.d script and systemd service.
+ .
+ It should not be installed on systems where interfaces are configured
+ by ifupdown via  using the DHCP method.
 
 Package: dhcpcd5
 Section: oldlibs
diff -Nru dhcpcd5-9.4.1/debian/NEWS dhcpcd5-9.4.1/debian/NEWS
- --- dhcpcd5-9.4.1/debian/NEWS 1970-01-01 02:00:00.0 +0200
+++ dhcpcd5-9.4.1/debian/NEWS   2023-03-14 10:27:50.0 +0200
@@ -0,0 +1,21 @@
+dhcpcd5 (9.4.1-21) unstable; urgency=medium
+
+   Since Debian 12 (Bookworm), dhcpcd uses Predictable Network Interface Names
+   on Linux ports. This brings dhcpcd in line with other networking tools.
+
+   This change is only noticeable on hosts where networking is controlled by
+   ifupdown via . For example:
+
+   Before:
+
+   iface eth0 inet dhcp
+   iface eth0 inet6 auto
+
+   After:
+
+   iface enp4s0 inet dhcp
+   iface enp4s0 inet6 auto
+
+   'sudo dmesg | grep -i renamed' shows available Predictable Interface Names.
+
+ -- Martin-Éri

Processed: unblock: dhcpcd5/9.4.1-21

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:dhcpcd5
Bug #1033062 [release.debian.org] unblock: dhcpcd5/9.4.1-21
Added indication that 1033062 affects src:dhcpcd5

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

Re: 11.7 planning

[Laura Arjona Reina]

Hello

El 16 de marzo de 2023 13:21:52 CET, Donald Norwood  
escribió:
>29th is workable.
>

I can the 15th and 22nd of April.
For now I cannot say anything about my availability for May (bookworm release).

Kind regards

>On 3/15/23 18:36, Andy wrote:
>> On 15 March 2023 20:33:47 GMT, Jonathan Wiltshire  wrote:
>>> Hi,
>>> 
>>> We're overdue for 11.7 and need it done with a keyring update included
>>> before bookworm can be released. The wheels are turning on the keyring so
>>> how do dates in April look for everybody? Saturdays are 1st (probably too
>>> soon), 8th, 15th, 22nd and 29th.
>>> 
>>> Thanks,
>>> 
>> 
>> 
>> I can do 15th, 22nd or 29th
>> Isy is only available from the 29th (mocks)
>> 
>> Best wishes
>> /Andy
>

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: c-ares_1.17.1-1+deb11u2_amd64-buildd.changes
  ACCEPT
Processing changes file: c-ares_1.17.1-1+deb11u2_arm64-buildd.changes
  ACCEPT
Processing changes file: c-ares_1.17.1-1+deb11u2_armel-buildd.changes
  ACCEPT
Processing changes file: c-ares_1.17.1-1+deb11u2_armhf-buildd.changes
  ACCEPT
Processing changes file: c-ares_1.17.1-1+deb11u2_i386-buildd.changes
  ACCEPT
Processing changes file: c-ares_1.17.1-1+deb11u2_mips64el-buildd.changes
  ACCEPT
Processing changes file: c-ares_1.17.1-1+deb11u2_mipsel-buildd.changes
  ACCEPT
Processing changes file: c-ares_1.17.1-1+deb11u2_ppc64el-buildd.changes
  ACCEPT
Processing changes file: c-ares_1.17.1-1+deb11u2_s390x-buildd.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: c-ares_1.17.1-1+deb11u2_source.changes
  ACCEPT

Re: 11.7 planning

[Donald Norwood]

29th is workable.

On 3/15/23 18:36, Andy wrote:

On 15 March 2023 20:33:47 GMT, Jonathan Wiltshire  wrote:

Hi,

We're overdue for 11.7 and need it done with a keyring update included
before bookworm can be released. The wheels are turning on the keyring so
how do dates in April look for everybody? Saturdays are 1st (probably too
soon), 8th, 15th, 22nd and 29th.

Thanks,




I can do 15th, 22nd or 29th
Isy is only available from the 29th (mocks)

Best wishes
/Andy


--



Be well,

-Donald

--
-
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Donald Norwood
⢿⡄⠘⠷⠚⠋⠀ B7A1 5F45 5B28 7F38 4174
⠈⠳⣄ D5E9 E5EC 4AC9 BD62 7B05

Re: 11.7 planning + bookworm planning

[Mark Hymers]

On Thu, 16, Mar, 2023 at 11:26:00AM +0100, Paul Gevers spoke thus..
> Dear all,
> 
> On 15-03-2023 21:33, Jonathan Wiltshire wrote:
> > We're overdue for 11.7 and need it done with a keyring update included
> > before bookworm can be released. The wheels are turning on the keyring so
> > how do dates in April look for everybody? Saturdays are 1st (probably too
> > soon), 8th, 15th, 22nd and 29th.
> 
> I know some people will call me crazy, but can and should we combine this
> with finding a release date for bookworm?
> 
> From where I'm looking, bookworm is looking pretty good. Obviously we'll
> have to follow through on the flurry of unblock requests that came in after
> the hard freeze, but that should be manageable in a couple of weeks. kibi
> just told me on IRC that asking this question now is not crazy from a d-i
> point of view. That hopefully means that around the end of April, also the
> bookworm d-i should™ be ready for release (kibi, I'm sure you'll comment on
> this if I got you wrong or if you want to provide more details).
> 
> So, shall we add availability for May too? 6th, 13th, 20th (Ascension
> weekend), and 27th (coincides with DebianReunionHamburg)?



Currently, for 11.7 I can do

 * 15th April
 * 22nd April
 * 29th April

For Bookworm, all of those dates look fine for me but if one of the
other ftp-masters wants to do the bookworm release, fine by me too.

Mark

-- 
Mark Hymers 


signature.asc
Description: PGP signature

Re: 11.7 planning + bookworm planning

[Cyril Brulebois]

Hi,

Paul Gevers  (2023-03-16):
> From where I'm looking, bookworm is looking pretty good. Obviously
> we'll have to follow through on the flurry of unblock requests that
> came in after the hard freeze, but that should be manageable in a
> couple of weeks. kibi just told me on IRC that asking this question
> now is not crazy from a d-i point of view.

Asking questions is never crazy. :)

> That hopefully means that around the end of April, also the bookworm
> d-i should™ be ready for release (kibi, I'm sure you'll comment on
> this if I got you wrong or if you want to provide more details).

At this stage, I'd still like to have at least two releases out. The
first few weeks after the Alpha 2 release were awfully quiet
feedback-wise, that's much better now, and we've got a few fixes and
improvements queued up. There's also a brand new set of shim* packages,
which should definitely end up in some release at some point.

Without having checked with Steve yet, I certainly expect us to be able
to publish at least a release in March and another before say mid-April…
 
> So, shall we add availability for May too? 6th, 13th, 20th (Ascension
> weekend), and 27th (coincides with DebianReunionHamburg)?

… which should be all good for a tentative release in May, we would
still have time for a few extra tweaks with a final debian-installer
upload, should they be needed at that stage (rather than wait until
12.1).


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


signature.asc
Description: PGP signature

Re: 11.7 planning + bookworm planning

[Luna Jernberg]

Can the 6th and 20th in May

On Thu, Mar 16, 2023 at 11:26 AM Paul Gevers  wrote:
>
> Dear all,
>
> On 15-03-2023 21:33, Jonathan Wiltshire wrote:
> > We're overdue for 11.7 and need it done with a keyring update included
> > before bookworm can be released. The wheels are turning on the keyring so
> > how do dates in April look for everybody? Saturdays are 1st (probably too
> > soon), 8th, 15th, 22nd and 29th.
>
> I know some people will call me crazy, but can and should we combine
> this with finding a release date for bookworm?
>
>  From where I'm looking, bookworm is looking pretty good. Obviously
> we'll have to follow through on the flurry of unblock requests that came
> in after the hard freeze, but that should be manageable in a couple of
> weeks. kibi just told me on IRC that asking this question now is not
> crazy from a d-i point of view. That hopefully means that around the end
> of April, also the bookworm d-i should™ be ready for release (kibi, I'm
> sure you'll comment on this if I got you wrong or if you want to provide
> more details).
>
> So, shall we add availability for May too? 6th, 13th, 20th (Ascension
> weekend), and 27th (coincides with DebianReunionHamburg)?
>
> Paul

Bug#1033046: unblock: arm-compute-library/20.08+dfsg-7

[Emanuele Rocca]

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

Please unblock package arm-compute-library.

[ Reason ]
Fix RC bug in bookworm, the package fails to build from source due to
missing include directives: https://bugs.debian.org/1032041

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock arm-compute-library/20.08+dfsg-7

Thanks,
  Emanuele

diff -Nru arm-compute-library-20.08+dfsg/debian/changelog arm-compute-library-20.08+dfsg/debian/changelog
--- arm-compute-library-20.08+dfsg/debian/changelog	2020-11-06 01:30:42.0 +0100
+++ arm-compute-library-20.08+dfsg/debian/changelog	2023-03-03 14:31:21.0 +0100
@@ -1,3 +1,17 @@
+arm-compute-library (20.08+dfsg-7) unstable; urgency=medium
+
+  * Actually include d/patches/missing-includes.patch, all changes to d/patches
+got removed by dgit.
+
+ -- Emanuele Rocca   Fri, 03 Mar 2023 14:31:21 +0100
+
+arm-compute-library (20.08+dfsg-6) unstable; urgency=medium
+
+  * Add d/patches/missing-includes.patch to fix FTBFS (Closes: #1032041)
+  * Add myself to Uploaders with Wookey's permission.
+
+ -- Emanuele Rocca   Fri, 03 Mar 2023 14:12:26 +0100
+
 arm-compute-library (20.08+dfsg-5) unstable; urgency=medium
 
   * Re-release as source-only upload
diff -Nru arm-compute-library-20.08+dfsg/debian/control arm-compute-library-20.08+dfsg/debian/control
--- arm-compute-library-20.08+dfsg/debian/control	2020-11-06 01:30:42.0 +0100
+++ arm-compute-library-20.08+dfsg/debian/control	2023-03-03 14:16:04.0 +0100
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Compute Library Team 
-Uploaders: Georgios Pinitas ,
+Uploaders: Georgios Pinitas , Emanuele Rocca 
 Standards-Version: 4.5.0
 Homepage: https://github.com/ARM-software/ComputeLibrary
 Vcs-git: https://salsa.debian.org/wookey/arm-compute-library
diff -Nru arm-compute-library-20.08+dfsg/debian/patches/missing-includes.patch arm-compute-library-20.08+dfsg/debian/patches/missing-includes.patch
--- arm-compute-library-20.08+dfsg/debian/patches/missing-includes.patch	1970-01-01 01:00:00.0 +0100
+++ arm-compute-library-20.08+dfsg/debian/patches/missing-includes.patch	2023-03-03 14:30:48.0 +0100
@@ -0,0 +1,136 @@
+From: Emanuele Rocca 
+Date: Fri, 03 Mar 2023 14:14:18 +0100
+Subject: add missing includes to fix https://bugs.debian.org/1032041
+
+Index: arm-compute-library-20.08+dfsg/arm_compute/core/ITensorPack.h
+===
+--- arm-compute-library-20.08+dfsg.orig/arm_compute/core/ITensorPack.h
 arm-compute-library-20.08+dfsg/arm_compute/core/ITensorPack.h
+@@ -25,6 +25,7 @@
+ #define ARM_COMPUTE_ITENSORPACK_H
+ 
+ #include 
++#include 
+ #include 
+ 
+ namespace arm_compute
+Index: arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/mergeresults.cpp
+===
+--- arm-compute-library-20.08+dfsg.orig/src/core/NEON/kernels/arm_gemm/mergeresults.cpp
 arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/mergeresults.cpp
+@@ -25,6 +25,7 @@
+ /* As some of the merges need these headers, but are all included in the
+  * arm_gemm namespace, put these headers here.  */
+ #include 
++#include 
+ 
+ #include 
+ 
+Index: arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/generic.cpp
+===
+--- arm-compute-library-20.08+dfsg.orig/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/generic.cpp
 arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/generic.cpp
+@@ -24,6 +24,7 @@
+ #ifdef __aarch64__
+ 
+ #include 
++#include 
+ 
+ #include "arm_gemm.hpp"
+ 
+Index: arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/a55.cpp
+===
+--- arm-compute-library-20.08+dfsg.orig/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/a55.cpp
 arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/a55.cpp
+@@ -24,6 +24,7 @@
+ #ifdef __aarch64__
+ 
+ #include 
++#include 
+ 
+ #include "arm_gemm.hpp"
+ 
+Index: arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/x1.cpp
+===
+--- arm-compute-library-20.08+dfsg.orig/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/x1.cpp
 arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gemm/kernels/a64_hybrid_fp32_mla_16x4/x1.cpp
+@@ -24,6 +24,7 @@
+ #ifdef __aarch64__
+ 
+ #include 
++#include 
+ 
+ #include "arm_gemm.hpp"
+ 
+Index: arm-compute-library-20.08+dfsg/src/core/NEON/kernels/arm_gem

Bug#1032899: unblock: rocm-hipamd/5.2.3-6

[Christian Kastner]

Hi Paul,

On 2023-03-16 10:31, Paul Gevers wrote:
> Control: tags -1 moreinfo On 16-03-2023 00:16, Christian Kastner 
> wrote: For next time, can you please contact us earlier? We could 
> have solved the earlier problems in testing-proposed-updates (in 
> January), then we would now be in a better position.

I didn't think of that solution as the RC-blocked dependency was only
available in unstable, and admittedly because I thought this would
resolve itself in time.

But in any case: yes, earlier contact would have been helpful, and I'll
do so in future.

> + * Reduce arch to amd64, arm64, ppc64el
> 
> But it fails on ppc64el; so why this selection?

Because those are the only architectures for which the required amdgpu
kernel driver is available [2].

> Also, as the other architectures FTBFS, we prefer in Debian to *not*
>  limit the architectures, but just let them fail [1]. This eases 
> porter efforts.

Thanks for pointing this out, I thought it was the other way around
(prefer *to* limit to avoid failures). Well, with ppc64el, we followed
that strategy.

> If the packages really don't make sense on some architectures, 
> consider using some of the "properties" provided by 
> bin:architecture-properties in your Build-Depends.

I wasn't aware of this package and I don't think it'll help us here
because we're specifically tracking [2]. But it'll be very useful to
some of my other packages, thanks!

> By the way, I checked, but none of the ci.d.n host will run any of 
> your tests, as none of them has an amdgpu (is that a thing you could 
> expect on non-amd architectures by the way?).

Correct! Tests will be skipped on official infra.

It's not just a matter of the missing hardware (we have it, but DSA has
understandable concerns), it's also about how to even express that a
package needs a GPU to run its tests (build-time or autopkgtest).

I recently initiated a discussion about this [3]. For now, the idea to
run parallel debci infra with guaranteed GPU presence, gather
experience, and to eventually share proposals on how a GPU dependency
could be expressed in d/control and d/tests/control.

> One thing I spotted along the way; the (Build-)Depends on llvm 
> related packages use the *versioned* ones. Is there a reason not to 
> use the unversioned ones from src:llvm-defaults? That would make llvm
> transitions a bit easier.

I'd have to check with the co-maintainers who added it, but from what I
gather so far, the ROCm stack needs a very recent llvm because of many
changes being upstreamed there.

> Overall, the diff is a bit long (and has some irrelevant stuff), so 
> I'm hesitant to offer t-p-u now (to avoid waiting for 
> llvm-toolchain-15).

Understood. Yeah, the diff is long, unfortunately, as the packaging
fixes accumulated over time.

Is this something that you could consider at a later point in time, if I
also break down the diff into more reviewable fragments (dependencies,
build, metadata, ...)? Because I do think that most changes are just
fixes of one sort or another - no features added.

Best,
Christian


> [1] https://lists.debian.org/debian-devel/2022/09/msg00105.html and follow-up 

[2] 
https://github.com/torvalds/linux/blob/v6.2/drivers/gpu/drm/amd/amdkfd/Kconfig#L6-L8
[3] https://lists.debian.org/debian-ai/2023/03/msg00038.html

Re: 11.7 planning + bookworm planning

[Paul Gevers]

Dear all,

On 15-03-2023 21:33, Jonathan Wiltshire wrote:

We're overdue for 11.7 and need it done with a keyring update included
before bookworm can be released. The wheels are turning on the keyring so
how do dates in April look for everybody? Saturdays are 1st (probably too
soon), 8th, 15th, 22nd and 29th.


I know some people will call me crazy, but can and should we combine 
this with finding a release date for bookworm?


From where I'm looking, bookworm is looking pretty good. Obviously 
we'll have to follow through on the flurry of unblock requests that came 
in after the hard freeze, but that should be manageable in a couple of 
weeks. kibi just told me on IRC that asking this question now is not 
crazy from a d-i point of view. That hopefully means that around the end 
of April, also the bookworm d-i should™ be ready for release (kibi, I'm 
sure you'll comment on this if I got you wrong or if you want to provide 
more details).


So, shall we add availability for May too? 6th, 13th, 20th (Ascension 
weekend), and 27th (coincides with DebianReunionHamburg)?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Processed: improving udd view

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> user release.debian@packages.debian.org
Setting user to release.debian@packages.debian.org (was elb...@debian.org).
> usertags 1029206 - moreinfo
Usertags were: transition unblock moreinfo.
Usertags are now: transition unblock.
> tags 1029206 moreinfo
Bug #1029206 [release.debian.org] [pre-approval] unblock: webkit2gtk 2.40.0-2
Added tag(s) moreinfo.
> retitle 1029206 unblock: webkit2gtk 2.40.0-2 [pre-approval]
Bug #1029206 [release.debian.org] [pre-approval] unblock: webkit2gtk 2.40.0-2
Changed Bug title to 'unblock: webkit2gtk 2.40.0-2 [pre-approval]' from 
'[pre-approval] unblock: webkit2gtk 2.40.0-2'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1029206: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029206
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: unblock: octave/7.3.0-2

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:octave
Bug #1033043 [release.debian.org] unblock: octave/7.3.0-2
Added indication that 1033043 affects src:octave

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

Bug#1033043: unblock: octave/7.3.0-2

[Sébastien Villemot]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: oct...@packages.debian.org
Control: affects -1 + src:octave

Please unblock package octave.

Version 7.3.0-2 fixes an issue that may arise during upgrades from Bullseye to
Bookworm, namely a missing Breaks+Replaces with files moved from one package to
another (see #1033011).

The debdiff is attached.

unblock octave/7.3.0-2

Thanks for your work,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org
diff -Nru octave-7.3.0/debian/changelog octave-7.3.0/debian/changelog
--- octave-7.3.0/debian/changelog   2022-11-05 09:29:53.0 +0100
+++ octave-7.3.0/debian/changelog   2023-03-15 17:55:33.0 +0100
@@ -1,3 +1,10 @@
+octave (7.3.0-2) unstable; urgency=medium
+
+  * d/control: add missing Breaks+Replaces of octave-dev on old liboctave-dev
+(Closes: #1033011)
+
+ -- Sébastien Villemot   Wed, 15 Mar 2023 17:55:33 +0100
+
 octave (7.3.0-1) unstable; urgency=medium
 
   * New upstream version 7.3.0
diff -Nru octave-7.3.0/debian/control octave-7.3.0/debian/control
--- octave-7.3.0/debian/control 2022-11-05 09:29:48.0 +0100
+++ octave-7.3.0/debian/control 2023-03-15 17:54:42.0 +0100
@@ -144,6 +144,8 @@
  gcc,
  g++
 Enhances: octave
+Breaks: liboctave-dev (<< 6.3.0-1)
+Replaces: liboctave-dev (<< 6.3.0-1)
 Description: development files for the GNU Octave language
  Octave is a (mostly MATLAB® compatible) high-level language, primarily
  intended for numerical computations. It provides a convenient command-line

Processed: Re: Bug#1032899: unblock: rocm-hipamd/5.2.3-6

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo
Bug #1032899 [release.debian.org] unblock: rocm-hipamd/5.2.3-6
Added tag(s) moreinfo.

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

Bug#1032899: unblock: rocm-hipamd/5.2.3-6

[Paul Gevers]

Control: tags -1 moreinfo

Hi,

On 16-03-2023 00:16, Christian Kastner wrote:

On 2023-03-13 18:28, Christian Kastner wrote:

[ Impact ]
The new versions are in far better shape: they've catched missing
dependencies, added patches, improved the build process, etc.


Apologies, I was only thinking of the more recent releases.

Revision -2 fixed an RC bug in January, but never got the chance to
migrate because of an RC bug in a dependency. Revision -6 fixed another
RC bug.

All releases after -2 were incremental improvements that basically never
got the chance to migrate because of a dependency not migrating.


For next time, can you please contact us earlier? We could have solved 
the earlier problems in testing-proposed-updates (in January), then we 
would now be in a better position.


+ * Reduce arch to amd64, arm64, ppc64el

But it fails on ppc64el; so why this selection? Also, as the other 
architectures FTBFS, we prefer in Debian to *not* limit the 
architectures, but just let them fail [1]. This eases porter efforts. If 
the packages really don't make sense on some architectures, consider 
using some of the "properties" provided by bin:architecture-properties 
in your Build-Depends.


By the way, I checked, but none of the ci.d.n host will run any of your 
tests, as none of them has an amdgpu (is that a thing you could expect 
on non-amd architectures by the way?).


One thing I spotted along the way; the (Build-)Depends on llvm related 
packages use the *versioned* ones. Is there a reason not to use the 
unversioned ones from src:llvm-defaults? That would make llvm 
transitions a bit easier.


Overall, the diff is a bit long (and has some irrelevant stuff), so I'm 
hesitant to offer t-p-u now (to avoid waiting for llvm-toolchain-15).


Paul

[1] https://lists.debian.org/debian-devel/2022/09/msg00105.html and 
follow-up


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032862: marked as done (unblock: golang-github-tidwall-gjson/1.14.4-2 (pre-approval))

[Debian Bug Tracking System]

Your message dated Thu, 16 Mar 2023 09:45:55 +0100
with message-id 
and subject line Re: Bug#1032862: unblock: golang-github-tidwall-gjson/1.14.4-2 
(pre-approval)
has caused the Debian Bug report #1032862,
regarding unblock: golang-github-tidwall-gjson/1.14.4-2 (pre-approval)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1032862: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032862
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian...@lists.debian.org

Hi,

Please consider ACKing a golang-github-tidwall-gjson upload catching up
with newer upstream releases.

[ Reason ]
The golang-github-tidwall-gjson package currently in testing and
unstable suffers from at least two CVEs (#1000225, #1011616).

Currently, we have a 1.6.7 version, those bugs are supposed to be fixed
in 1.9.x, and upstream is at 1.14.4…

This library is about parsing JSON, is basically one big Go file (along
with another one for the tests).

Since that's about parsing things, I suppose it wouldn't be trivial to
backport the security fixes from 1.9.2 and 1.9.3 without understanding
how parsing works, and why it was buggy in 1.6.7. Shipping the latest
1.9.x would probably be safer. But then, if we're going to have a bump
in upstream releases, it seemed (at least to Thorsten Alteholz on the
debian-go@ list and to me) that considering the latest would make most
sense. We would get those fixes, possible other ones, and that would
minimize the delta whenever other security fixes come up.

The reverse dependencies are somewhat limited:
 - dak lists 3 packages via Depends;
 - dak lists 5 packages via Build-Depends;
 - ratt finds 14 packages when it's time to rebuild all the things.

[ Impact ]
I'm not sure I would be able to backport security fixes (at all, or
properly), and failing to get a fixed package into testing might get a
bunch of packages kicked out. This includes crowdsec, which is my
primary concern when it comes to Go packages.

[ Tests ]
ratt has been used to check that all 14 identified packages still build
fine. Those are Go packages, so they usually come with a test suite (but
I must admit I didn't check each one individually).

Additionally, I've uploaded 1.14.4-1 to experimental to benefit from the
automated autopkgtest runs (for Go packages that means building/testing
on the considered arch), and those haven't uncovered any issues on any
of the ci.debian.net archs, which is an extra reassurance compared to my
initial build tests via ratt, only on amd64.

[ Risks ]
No regressions have been spotted thus far, either in the package or its
reverse dependencies, and I'm signing up for investigating anything that
might come up as a side effect of this update.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
This is a Go package, so reverse dependencies will need to be rebuilt
against the updated code. That being said, with the binNMU rounds
happening to avoid keeping too many `Extra-Source-Only: yes` packages
in testing, that might just happen automatically without requiring
manual scheduling.

unblock golang-github-tidwall-gjson/1.14.4-2


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
diff --git a/README.md b/README.md
index 8553273..c8db11f 100644
--- a/README.md
+++ b/README.md
@@ -4,7 +4,9 @@
 width="240" height="78" border="0" alt="GJSON">
 
 https://godoc.org/github.com/tidwall/gjson";>https://img.shields.io/badge/api-reference-blue.svg?style=flat-square"; 
alt="GoDoc">
-http://tidwall.com/gjson-play";>https://img.shields.io/badge/%F0%9F%8F%90-playground-9900cc.svg?style=flat-square";
 alt="GJSON Playground">
+https://tidwall.com/gjson-play";>https://img.shields.io/badge/%F0%9F%8F%90-playground-9900cc.svg?style=flat-square";
 alt="GJSON Playground">
+https://img.shields.io/badge/{}-syntax-33aa33.svg?style=flat-square"; 
alt="GJSON Syntax">
+   
 
 
 get json values quickly
@@ -14,6 +16,10 @@ It has features such as [one line retrieval](#get-a-value), 
[dot notation paths]
 
 Also check out [SJSON](https://github.com/tidwall/sjson) for modifying json, 
and the [JJ](https://github.com/tidwall/jj) command line tool.
 
+This README is a quick overview of how to use GJSON, for more information 
check out [GJSON Syntax](SYNTAX.md).
+
+GJSON is also available for [Python](https://github.com/volans-/gjson-py) an

Re: 11.7 planning

[Luna Jernberg]

If you want my help with testing i can do the later April dates 15th,
22nd and 29th

On 3/15/23, Jonathan Wiltshire  wrote:
> Hi,
>
> We're overdue for 11.7 and need it done with a keyring update included
> before bookworm can be released. The wheels are turning on the keyring so
> how do dates in April look for everybody? Saturdays are 1st (probably too
> soon), 8th, 15th, 22nd and 29th.
>
> Thanks,
>
> --
> Jonathan Wiltshire  j...@debian.org
> Debian Developer http://people.debian.org/~jmw
>
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
>
>