Bug#980609: missing i386-cpuinfo.h

[Simon Ruderich]

Hello,

the attached patch works for me as workaround for Bullseye. It adds the
missing file and updates the #include path to it. Apply it with

cd / && patch -p1 < /path/to/patch

With the patch I can successfully build kernels which use GCC
plugins on Bullseye.

Is it possible to apply a similar patch to the official gcc
package distributed in Bullseye? Having to patch the systems
manually isn't optimal.

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
Workaround for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980609, based
on pr95842.diff

Apply with cd / && patch -p1 < /path/to/patch

--- a/usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/config/i386/i386.h.orig	2021-01-10 12:35:39.0 +0100
+++ b/usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/config/i386/i386.h	2022-01-23 10:22:59.579197064 +0100
@@ -2497,7 +2497,7 @@
 
 #include "insn-attr-common.h"
 
-#include "common/config/i386/i386-cpuinfo.h"
+#include "config/i386/i386-cpuinfo.h"
 
 class pta
 {
--- /dev/null
+++ b/usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/config/i386/i386-cpuinfo.h
@@ -0,0 +1,134 @@
+/* Get CPU type and Features for x86 processors.
+   Copyright (C) 2012-2020 Free Software Foundation, Inc.
+   Contributed by Sriraman Tallam (tmsri...@google.com)
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+/* Processor Vendor and Models. */
+
+enum processor_vendor
+{
+  VENDOR_INTEL = 1,
+  VENDOR_AMD,
+  VENDOR_OTHER,
+  BUILTIN_VENDOR_MAX = VENDOR_OTHER,
+  VENDOR_MAX
+};
+
+/* Any new types or subtypes have to be inserted at the end. */
+
+enum processor_types
+{
+  INTEL_BONNELL = 1,
+  INTEL_CORE2,
+  INTEL_COREI7,
+  AMDFAM10H,
+  AMDFAM15H,
+  INTEL_SILVERMONT,
+  INTEL_KNL,
+  AMD_BTVER1,
+  AMD_BTVER2,
+  AMDFAM17H,
+  INTEL_KNM,
+  INTEL_GOLDMONT,
+  INTEL_GOLDMONT_PLUS,
+  INTEL_TREMONT,
+  CPU_TYPE_MAX,
+  BUILTIN_CPU_TYPE_MAX = CPU_TYPE_MAX
+};
+
+enum processor_subtypes
+{
+  INTEL_COREI7_NEHALEM = 1,
+  INTEL_COREI7_WESTMERE,
+  INTEL_COREI7_SANDYBRIDGE,
+  AMDFAM10H_BARCELONA,
+  AMDFAM10H_SHANGHAI,
+  AMDFAM10H_ISTANBUL,
+  AMDFAM15H_BDVER1,
+  AMDFAM15H_BDVER2,
+  AMDFAM15H_BDVER3,
+  AMDFAM15H_BDVER4,
+  AMDFAM17H_ZNVER1,
+  INTEL_COREI7_IVYBRIDGE,
+  INTEL_COREI7_HASWELL,
+  INTEL_COREI7_BROADWELL,
+  INTEL_COREI7_SKYLAKE,
+  INTEL_COREI7_SKYLAKE_AVX512,
+  INTEL_COREI7_CANNONLAKE,
+  INTEL_COREI7_ICELAKE_CLIENT,
+  INTEL_COREI7_ICELAKE_SERVER,
+  AMDFAM17H_ZNVER2,
+  INTEL_COREI7_CASCADELAKE,
+  INTEL_COREI7_TIGERLAKE,
+  INTEL_COREI7_COOPERLAKE,
+  CPU_SUBTYPE_MAX
+};
+
+/* Priority of i386 features, greater value is higher priority.   This is
+   used to decide the order in which function dispatch must happen.  For
+   instance, a version specialized for SSE4.2 should be checked for dispatch
+   before a version for SSE3, as SSE4.2 implies SSE3.  */
+enum feature_priority
+{
+  P_NONE = 0,
+  P_MMX,
+  P_SSE,
+  P_SSE2,
+  P_SSE3,
+  P_SSSE3,
+  P_PROC_SSSE3,
+  P_SSE4_A,
+  P_PROC_SSE4_A,
+  P_SSE4_1,
+  P_SSE4_2,
+  P_PROC_SSE4_2,
+  P_POPCNT,
+  P_AES,
+  P_PCLMUL,
+  P_AVX,
+  P_PROC_AVX,
+  P_BMI,
+  P_PROC_BMI,
+  P_FMA4,
+  P_XOP,
+  P_PROC_XOP,
+  P_FMA,
+  P_PROC_FMA,
+  P_BMI2,
+  P_AVX2,
+  P_PROC_AVX2,
+  P_AVX512F,
+  P_PROC_AVX512F,
+  P_PROC_DYNAMIC
+};
+
+/* These are the values for vendor types, cpu types and subtypes.  Cpu
+   types and subtypes should be subtracted by the corresponding start
+   value.  */
+
+#define M_CPU_TYPE_START (BUILTIN_VENDOR_MAX)
+#define M_CPU_SUBTYPE_START \
+  (M_CPU_TYPE_START + BUILTIN_CPU_TYPE_MAX)
+#define M_VENDOR(a) (a)
+#define M_CPU_TYPE(a) (M_CPU_TYPE_START + a)
+#define M_CPU_SUBTYPE(a) (M_CPU_SUBTYPE_START + a)



signature.asc
Description: PGP signature

Bug#1004281: --locale LOCALE don't support Debian 11 bullseye in d-i preseed

[肖盛文]

Package: simple-cdd
Version: 0.6.8
Severity: normal
X-Debbugs-Cc: atzli...@sina.com

Hi,
   The Debian 11 d-i LOCALE use localechooser:

d-i localechooser/languagelist  select

to set LOCALE.
Tho old way debian-installer/locale={locale} in the KERNEL_PARAMS  is useless.

The Debian 11 d-i localechooser has some debconf choices, I hope them can
support by simple-cdd.

Thanks!

diff --git a/build-simple-cdd b/build-simple-cdd
index 2310b2d..04f1451 100755
--- a/build-simple-cdd
+++ b/build-simple-cdd
@@ -338,7 +338,7 @@ class SimpleCDD:
 self.env.append("KERNEL_PARAMS", arg)

 if self.env.get("locale"):
-arg = self.env.format("debian-installer/locale={locale}")
+arg = self.env.format("localechooser/languagelist={locale}")
 log.debug("setting default locale (KERNEL_PARAMS += %s)", arg)
 self.env.append("KERNEL_PARAMS", arg)



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

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

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-3+b1
ii  debian-cd   3.1.35
ii  lsb-release 11.1.0
ii  python3 3.9.2-3
ii  python3-simple-cdd  0.6.8
ii  reprepro5.3.0-1.2
ii  rsync   3.2.3-4+deb11u1
ii  wget1.21-1+deb11u1

Versions of packages simple-cdd recommends:
ii  dose-distcheck  6.0.1-2

Versions of packages simple-cdd suggests:
pn  qemu-system | qemu-kvm  

-- no debconf information

Bug#1004067: closed by Debian FTP Masters (reply to Mathieu Malaterre ) (Bug#1004067: fixed in imath 3.1.3-10)

[Mathieu Malaterre]

Hi all,

On Sun, Jan 23, 2022 at 10:45 PM Matteo F. Vescovi  wrote:
>
> Version: 3.1.3-10
>
> On 2022-01-23 at 18:42 (+01), Matteo F. Vescovi wrote:
> > The build still ftbfs.
>
> Gosh, at the time of writing was still using -9 revision and it failed.
> Now, I've tested -10 revision of imath and openexr builds just fine with
> it.

My fix is rather a crude hack. I do not believe the python ecosystem
(AFAIK) is ever using cmake export files for package dependencies. So
I believe the right fix would be to "undeclare" the python module from
the list of exported cmake module. Maybe we'll need to forward the
issue upstream.

Bug#1004276: Installing libglvnd0/buster-backports would remove 197 packages including xserver and mate

[roottoorfieuorg]

tags 1004276 + moreinfo
thanks

В Пн, 24/01/2022 в 02:33 +0200, Pekka Sarnila пишет:


> # apt-get -s install libglvnd0/buster-backports
> 
> ...
> 119 upgraded, 7 newly installed, 197 to remove and 1431 not upgraded
> ...
> Remv xserver-xorg [1:7.7+19]
> ...

Apparently the apt resolver made an unsolicited and ugly decision.

But it's difficult to guess without knowing exactly what's the apt
state and configuration, where's the issue. Try to provide more info.

> libglvnd0/buster-backports should depend on libc6 only.

I'm not sure if this is your suggestion, because that's exactly how it
is.

> And there is no 
> xserver-xorg/buster-backports available.

That's correct. But why did you mention it?

Bug#1002681: transition: ocaml

[Stéphane Glondu]

Le 19/01/2022 à 09:34, Sebastian Ramacher a écrit :
> The libguestfs build for the php8.1 transition migrated, so this
> transition can proceed. Please go ahead.

5 days later, most of packages have been rebuilt with the new OCaml. The
remaining outliers are:

- hol-light (#1002983): the fix is not trivial and upstream doesn't seem
interested in supporting a modern toolchain, should be removed from
testing for the time being
- otags (#1002940): seems dead upstream, should be removed from testing
for the time being
- ppx-tools-versioned (#1002941), ppxfind (#1002942): they seem
deprecated, should be removed from testing
- sks (#1002657): a patch is available
- llvm-toolchain-11 (#1002607), llvm-toolchain-12 (#1002608): the fix is
trivial
- eliom: a new upstream release is available, but it needs ocsipersist
which is sitting in NEW... can be removed temporarily from testing if needed
- nurpawiki: depends on eliom, can be removed temporarily from testing
if needed
- llvm-toolchain-9: not in testing... as far as I understand, should be
removed from Debian altogether
- why3, frama-c: not in testing... FTBFS at the moment, but should be
fixed in the future


Cheers,

-- 
Stéphane

Bug#1004280: raspi-firmware: Autogenerated-file warning fixes and clarification for config.txt

[Jean-Paul Larocque]

Package: raspi-firmware
Version: 1.20210303+ds-2
Severity: normal
File: /etc/kernel/postinst.d/z50-raspi-firmware
Tags: patch

Hi Debian Raspberry Pi Maintainers,

I noticed that /etc/kernel/postinst.d/z50-raspi-firmware is meant to
include a comment with a warning when generating
/boot/firmware/config.txt:

---
# Truncate the config.txt file so that we start with a blank slate
echo  instead of >>:

---
if [ "$arch" = "arm64" ]; then
  cat >/boot/firmware/config.txt <--- /etc/kernel/postinst.d/z50-raspi-firmware.dpkg-dist	2021-04-20 22:52:21.0 -0700
+++ /etc/kernel/postinst.d/z50-raspi-firmware	2022-01-23 21:31:53.178811042 -0800
@@ -94,20 +94,20 @@
 
 
 # Truncate the config.txt file so that we start with a blank slate
-echo /boot/firmware/config.txt /boot/firmware/config.txt <

Bug#1002657: FTBFS with OCaml 4.13.1

[Stéphane Glondu]

Control: tags -1 + patch

Le 26/12/2021 à 21:04, Stéphane Glondu a écrit :
> Your package FTBFS with OCaml 4.13.1 with the following error:
>> File "mList.ml", line 203, characters 14-23:
>> 203 |   let slist = List.sort compare list in
>> ^
>> Error (warning 6 [labels-omitted]): label cmp was omitted in the application 
>> of this function.
>> File "mList.ml", line 211, characters 14-23:
>> 211 |   let slist = List.sort compare list in
>> ^
>> Error (warning 6 [labels-omitted]): label cmp was omitted in the application 
>> of this function.

Patch attached.


Cheers,

-- 
StéphaneFrom fd51784c6ecd09a06812fa50a6c8add72bb63ce3 Mon Sep 17 00:00:00 2001
From: Stephane Glondu 
Date: Sat, 22 Jan 2022 09:24:17 +0100
Subject: [PATCH] Do not error on warning 6 [labels-omitted]

---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 491190e..45514b7 100644
--- a/Makefile
+++ b/Makefile
@@ -49,7 +49,7 @@ SKSVS=$(shell grep 'version_suffix = "+"' common.ml)
 ifeq ($(strip $(SKSVS)),)
 WARNERR=
 else
-WARNERR=-warn-error A
+WARNERR=-warn-error A-6
 endif
 
 CAMLINCLUDE= -package cryptokit,unix,str,bigarray,num -I bdb
-- 
2.34.1

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Sean Whitton]

Hello Christoph,

On Sun 23 Jan 2022 at 10:27PM +01, Christoph Berg wrote:

> Re: Sean Whitton
>> Hello,
>>
>> On Sun 23 Jan 2022 at 10:04PM +01, Chris Hofstaedtler wrote:
>>
>> > I guess the best thing would be to introduce a new binary package,
>> > but I am out of ideas on naming it. Open for ideas here.
>>
>> util-linux-extra?
>
> If it's about rename only, "rename-ul" or even "rename.ul"?
>
> I guess it should also contain the historical name as a symlink.
>
> Christoph

Well, Chris mentioned wanting to transition some other things out of the
essential package in addition to this one.  Also, the ftp team would not
love the idea of a single-script package.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1004279: rust-rand - update to 0.8

[Peter Green]

Package: rust-rand

An increasing number of packages in Debian are using rand 0.8
upstream, while it's generally possible to patch them to use
0.7 I think we should prefer patching stuff to use newer versions
over packaging stuff to use older versions where possible. So
I started investigating an upgrade to rand 0.8. I have been working
through the involved packages, checking that they can be updated
easilly

I've worked through most of the reverse-dependencies, I still
have some left to do and some outstanding issues I have discovered,
the main outstanding issues are.

proptest gets two additional test failures when updated for the
new rand, I have opened a bug report about this upstream.

We need to figure out what to do about rust-petgraph, I tried to port it to the
new version of rust-quickcheck but failed, i'm leaning towards simply removing
the quickcheck feature from petgraph.

newsboat is maintained outside the rust team, coordination with it's maintainer
or a NMU will be needed.

I have posted a text file with details of my investigations at
https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/rand-0.8-progress.txt

Bug#1004278: rust-petgraph - update or remove quickcheck feature for quickcheck 1.0

[peter green]

package: rust-petgraph

kcrypd has requested an update for quickcheck to 1.0 in bug 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001656

I am also looking at moving rand to 0.8. quickcheck previously had rand as part 
of it's public API,
so it makes sense to update quickcheck at the same time as rand. I made an 
attempt at porting the quickcheck
feature in petgraph for quickcheck 1.0 but while I got it to compile, all the 
relavent tests failed,
so i'm not uploading it in it's current state.

I've uploaded the new version of rust-quickcheck to experimental and attatched 
the patch I attempted to
prepares for rust-petgraph in case anyone else wants to take a crack at porting 
it. Otherwise unless
someone raises an objetion I intend to drop the quickcheck feature from this 
package when I update
rand/quickcheck in unstable.



Index: petgraph/Cargo.toml
===
--- petgraph.orig/Cargo.toml
+++ petgraph/Cargo.toml
@@ -42,7 +42,7 @@ default-features = false
 version = "1.0.2"
 
 [dependencies.quickcheck]
-version = "0.8"
+version = "1"
 optional = true
 default-features = false
 
Index: petgraph/tests/quickcheck.rs
===
--- petgraph.orig/tests/quickcheck.rs
+++ petgraph/tests/quickcheck.rs
@@ -11,7 +11,7 @@ extern crate odds;
 
 mod utils;
 
-use utils::Small;
+//use utils::Small;
 
 use odds::prelude::*;
 use std::collections::HashSet;
@@ -34,6 +34,8 @@ use petgraph::visit::{EdgeRef, IntoEdgeR
 use petgraph::visit::{Reversed, Topo};
 use petgraph::EdgeType;
 
+use quickcheck::Gen;
+
 fn mst_graph(g: ) -> Graph
 where
 Ty: EdgeType,
@@ -46,7 +48,7 @@ where
 
 use std::fmt;
 
-quickcheck! {
+/*quickcheck! {
 fn mst_directed(g: Small>) -> bool {
 // filter out isolated nodes
 let no_singles = g.filter_map(
@@ -60,7 +62,7 @@ quickcheck! {
 assert!(!is_cyclic_undirected());
 true
 }
-}
+}*/
 
 quickcheck! {
 fn mst_undirected(g: Graph<(), u32, Undirected>) -> bool {
@@ -78,13 +80,13 @@ quickcheck! {
 }
 }
 
-quickcheck! {
+/*quickcheck! {
 fn reverse_undirected(g: Small>) -> bool {
 let mut h = (*g).clone();
 h.reverse();
 is_isomorphic(, )
 }
-}
+}*/
 
 fn assert_graph_consistent(g: )
 where
@@ -248,7 +250,7 @@ fn stable_graph_retain_edges() {
 quickcheck::quickcheck(prop as fn(StableGraph<_, _, Undirected>) -> bool);
 }
 
-#[test]
+/*#[test]
 fn isomorphism_1() {
 // using small weights so that duplicates are likely
 fn prop(g: Small>) -> bool {
@@ -287,9 +289,9 @@ fn isomorphism_1() {
 }
 quickcheck::quickcheck(prop:: as fn(_) -> bool);
 quickcheck::quickcheck(prop:: as fn(_) -> bool);
-}
+}*/
 
-#[test]
+/*#[test]
 fn isomorphism_modify() {
 // using small weights so that duplicates are likely
 fn prop(g: Small>, node: u8, edge: u8) -> bool {
@@ -322,7 +324,7 @@ fn isomorphism_modify() {
 }
 quickcheck::quickcheck(prop:: as fn(_, _, _) -> bool);
 quickcheck::quickcheck(prop:: as fn(_, _, _) -> bool);
-}
+}*/
 
 #[test]
 fn graph_remove_edge() {
@@ -564,29 +566,52 @@ fn graph_condensation_acyclic() {
 #[derive(Debug, Clone)]
 struct DAG(Graph);
 
+// unfortunately quickcheck doesn't let us access the rng directly anymore
+fn u64_from_gen(g:  Gen) -> u64 {
+let mut arr: [u8; 256] = [0; 256];
+for (val, elem) in arr.iter_mut().enumerate() {
+*elem = val as u8;
+}
+let mut result : u64 = 0;
+for _ in 0..8 {
+result *= 256;
+result += *g.choose().unwrap() as u64;
+}
+return result;
+}
+
+/// Return a random float in the range [0, 1.)
+fn random_01(g:  Gen) -> f64 {
+// from rand
+let bits = 53;
+let scale = 1. / ((1u64 << bits) as f64);
+let x = u64_from_gen(g);
+(x >> (64 - bits)) as f64 * scale
+}
+
 impl quickcheck::Arbitrary for DAG {
-fn arbitrary(g:  G) -> Self {
+fn arbitrary(g:  Gen) -> Self {
 let nodes = usize::arbitrary(g);
 if nodes == 0 {
 return DAG(Graph::with_capacity(0, 0));
 }
-let split = g.gen_range(0., 1.);
+let split = random_01(g);
 let max_width = f64::sqrt(nodes as f64) as usize;
 let tall = (max_width as f64 * split) as usize;
 let fat = max_width - tall;
 
-let edge_prob = 1. - (1. - g.gen_range(0., 1.)) * (1. - g.gen_range(0., 1.));
+let edge_prob = 1. - (1. - random_01(g)) * (1. - random_01(g));
 let edges = ((nodes as f64).powi(2) * edge_prob) as usize;
 let mut gr = Graph::with_capacity(nodes, edges);
 let mut nodes = 0;
 for _ in 0..tall {
-let cur_nodes = g.gen_range(0, fat);
+let cur_nodes = ((u64_from_gen(g) as u128) * (fat as u128) / 18446744073709551616) as usize;
 for _ in 0..cur_nodes {
 gr.add_node(N::default());
 }
 for j in 0..nodes {
  

Bug#1004118: closed by James McCoy (Re: Bug#1004118: E1187: Failed to source defaults.vim)

[Robert Siemer]

I’m pretty sure that it was a vim alternative at the time I installed it. –
Might have been 10+ years ago, though.

Anyway... good to know which way to go now.

Regards,
Robert

On Fri, Jan 21, 2022 at 2:39 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the vim-tiny package:
>
> #1004118: E1187: Failed to source defaults.vim
>
> It has been closed by James McCoy .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact James McCoy <
> james...@debian.org> by
> replying to this email.
>
>
> --
> 1004118: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004118
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: James McCoy 
> To: Robert Siemer ,
> 1004118-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 21 Jan 2022 08:37:52 -0500
> Subject: Re: Bug#1004118: E1187: Failed to source defaults.vim
> On Fri, Jan 21, 2022 at 03:58:58AM +0100, Robert Siemer wrote:
> > vim-tiny should come with defaults.vim, I believe.
>
> No, vim-tiny exists purely to provide a vi binary in the base system and
> therefore is geared towards a vi-like experience more so than a vim-like
> experience.
>
> This is why vim-tiny does not register itself as an option for the vim
> alternative.
>
> If you want it to be more vim-like, then installing vim-runtime is a
> reasonable step to take.
>
> Cheers,
> --
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
>
>
> -- Forwarded message --
> From: Robert Siemer 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 21 Jan 2022 03:58:58 +0100
> Subject: E1187: Failed to source defaults.vim
> Package: vim-tiny
> Version: 2:8.2.3995-1
> Severity: normal
> X-Debbugs-Cc: robert.siemer-report...@backsla.sh
>
> vim-tiny should come with defaults.vim, I believe. Which way I’m not sure,
> but it seems vim-common does not deliver it and vim-tiny does not depend
> on vim-runtime, which has it.
>
>
> -- Package-specific info:
>
> --- real paths of main Vim binaries ---
> /usr/bin/vi is /usr/bin/vim.tiny
> /usr/bin/vim is /usr/bin/vim.tiny
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'unstable')
> Architecture: i386 (i686)
>
> Kernel: Linux 5.10.0-8-686-pae (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages vim-tiny depends on:
> ii  libacl1  2.3.1-1
> ii  libc62.33-3
> ii  libselinux1  3.3-1+b1
> ii  libtinfo66.3-2
> ii  vim-common   2:8.2.3995-1
>
> vim-tiny recommends no packages.
>
> Versions of packages vim-tiny suggests:
> pn  indent  
>
> -- no debconf information
>

Bug#1003089: man-db has become prohibitively slow

[Colin Watson]

Control: tag -1 fixed-upstream

On Sun, Jan 23, 2022 at 06:11:19PM +0100, Steinar H. Gunderson wrote:
> On Sat, Jan 22, 2022 at 12:41:56AM +, Colin Watson wrote:
> >> Technically, UTF-8 validation can be done at a few gigabytes per second
> >> per core:
> >> 
> >>   
> >> https://lemire.me/blog/2018/05/16/validating-utf-8-strings-using-as-little-as-0-7-cycles-per-byte/
> >> 
> >> but that is probably overkill. :-)
> > Quite :-)
> 
> It struck me that it can probably be folded for free into the lexer.
> If you add symbols for all invalid UTF-8 sequences, I believe it should just
> go into the state machine. But I'm fine with those 20%; the perfect need not
> be the enemy of the good here.

Mm.  I'd somewhat prefer not to put it in the lexer though, because in
general the next stage after encoding conversion can be something other
than the lexer, and I don't want to store up too much confusion for my
future self.

I grabbed glib's UTF-8 validator on the basis that it was a simple,
portable, and compatibly-licensed one that I could verify by eye and
dropped it in, replacing the trial conversion pass if source_encoding !=
UTF-8 and target_encoding == UTF-8.  This saves about 8% on my test
system on top of the previous optimizations (10.589s → 9.791s, median of
nine runs), so it might be possible to do better with a faster
validator, but this seems likely to be good enough and we're probably
approaching diminishing returns.

> In general, I don't think I need to look at it again now, unless there are
> any special questions. Thanks for taking care of this! Looking forward to
> bookworm being faster (and of course sid before that), and then I'll happily
> live with this on bullseye, knowing that it's transient.

Thanks a lot for the initial prod and the review comments - they've
definitely improved things.  I've gone ahead and merged all this.  I'll
need to do a call for translations before releasing since there are some
other changes that will necessitate that, but I expect to produce a new
upstream release in a couple of weeks.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#873578: xserver-xorg-video-all: The suggestion is ridiculous, please do not do it!

[Nils Dagsson Moskopp]

Package: xserver-xorg-video-all
Followup-For: Bug #873578
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,


Itai Shaked  wrote:

> I think it is safe to assume that in 2017, the vast majority of Debian 
> users will have hardware meeting this criteria, so having 
> `xserver-xorg-video-all` Recommend `xserver-xorg-video-intel` seems 
> wrong.

It is 2022 and I had to install xserver-xorg-video-intel manually to get 
a usable graphical desktop – on a computer which runs Debian just fine …

It seems to me the person suggesting this has no empathy for people who 
do not own the latest and greatest hardware. Not everyone can figure it 
out that a package that is supposed to install all drivers is not doing 
that actually.

Therefore I kindly ask you to please not listen to this person who owns 
newer hardware than I do.


Greetings,
Nils Moskopp

-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-10-686 (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xserver-xorg-video-all depends on:
ii  xserver-xorg-video-amdgpu   19.1.0-2
ii  xserver-xorg-video-ati  1:19.1.0-2
ii  xserver-xorg-video-fbdev1:0.5.0-1
ii  xserver-xorg-video-nouveau  1:1.0.17-1
ii  xserver-xorg-video-vesa 1:2.5.0-1
ii  xserver-xorg-video-vmware   1:13.3.0-3

Versions of packages xserver-xorg-video-all recommends:
ii  xserver-xorg-video-intel  2:2.99.917+git20200714-1+b1
pn  xserver-xorg-video-qxl

xserver-xorg-video-all suggests no packages.

-- no debconf information

Bug#1004277: xserver-xorg-video-all does not depend on xserver-xorg-video-intel

[Nils Dagsson Moskopp]

Package: xserver-xorg-video-all
Version: 1:7.7+22
Severity: important
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

on my computer (Thinkpad T60) X11 would not start, throwing an error 
about OpenGL 2.1 being required. I was very concerned, since the GPU 
does not support OpenGL 2.1.

I had already installed xserver-xorg-video-all and was very confused. 
Only as I noticed that xserver-xorg-video-intel was not a dependency, 
but merely recommended, I figured out that I could try to install it.

I suspect that someone assumed that some fallback driver would be able 
to handle the situation. Clearly, this is not the case. I therefore ask 
for xserver-xorg-video-all to please depend on xserver-xorg-video-intel.

--- snib ---

; glxinfo |grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 945GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 20.3.5
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 20.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:

--- snab ---

Greetings,
Nils Moskopp

-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-10-686 (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xserver-xorg-video-all depends on:
ii  xserver-xorg-video-amdgpu   19.1.0-2
ii  xserver-xorg-video-ati  1:19.1.0-2
ii  xserver-xorg-video-fbdev1:0.5.0-1
ii  xserver-xorg-video-nouveau  1:1.0.17-1
ii  xserver-xorg-video-vesa 1:2.5.0-1
ii  xserver-xorg-video-vmware   1:13.3.0-3

Versions of packages xserver-xorg-video-all recommends:
ii  xserver-xorg-video-intel  2:2.99.917+git20200714-1+b1
pn  xserver-xorg-video-qxl

xserver-xorg-video-all suggests no packages.

-- no debconf information


Xorg.0.log.old
Description: application/json

Bug#1003952: chromium: Can't attach tab to window or move tab window horizontaly

[Andres Salomon]

On Tue, 18 Jan 2022 15:43:48 +0100 Florian Goth wrote:
> Package: chromium
> Version: 97.0.4692.71-0.1~deb11u1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: t...@security.debian.org
>
> Dear Maintainer,
>
> chromium-97 contains a bug with moving the tabs. It is fixed upstream 
with version chromium-99:

> https://bugs.chromium.org/p/chromium/issues/detail?id=1279532
>
>


Thanks for linking to the upstream bug report. It looks like this fix 
was also backported to the 97 branch, and it appears to be in chromium 
97.0.4692.99-1. Can you please verify if it's fixed for you?

Bug#1004274: debian-installer: graphical installer breaks debconf in rescue shell

[Cyril Brulebois]

Hi Pascal,

Pascal Hambourg  (2022-01-24):
> Steps to reproduce:
> - Boot the Debian installer
> - At the boot menu, select "Graphical rescue mode"
> - follow steps until "Enter rescue mode"
> - Select a Debian root device
> - Select "Execute a shell in "
> - in the shell, execute "dpkg-reconfigure keyboard-configuration"
> (any other installed package than keyboard-configuration which has
> configuration questions will do too)
> 
> Output:
> debconf: unable to initialize frontend: Newt
> debconf: (Can't locate Debconf/FrontEnd/Newt.pm in @INC...)
> debconf: falling to frontend: Noninteractive
> 
> Forcing --frontend=dialog or readline does not help.
> 
> This seems to be caused by the DEBIAN_FRONTEND=newt environment variable
> leaked from the graphical installer. It does not happen in the text
> installer nor in tty2/tty3 shells.
> 
> Not sure if this bug should be assigned to debian-installer,
> rescue-mode or debconf which should ignore DEBIAN_FRONTEND if invalid
> or superseded with --frontend. The issue also happens when selecting
> "Execute a shell" from the main menu and executing chroot manually, so
> it is not specific to rescue-mode.

Maybe it would make sense to just unset that variable when entering a
shell in such conditions… but then I don't know anything about that code
path. A quick search suggests start-shell in debian-installer-utils,
which incidently has specific handling based on $DEBIAN_FRONTEND…


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


signature.asc
Description: PGP signature

Bug#1004276: Installing libglvnd0/buster-backports would remove 197 packages including xserver and mate

[Pekka Sarnila]

Package: libglvnd0
Version: 1.3.2-1

My current libglvnd0 is newest buster-version 1.1.0-1.
xserver-xorg newest (1:7.7+19)
xserver-common newest (2:1.20.4-1+deb10u4)
etc

apt is already the newest version (1.8.2.3)

# apt-get -s install libglvnd0/buster-backports

...
119 upgraded, 7 newly installed, 197 to remove and 1431 not upgraded
...
Remv xserver-xorg [1:7.7+19]
...


libglvnd0/buster-backports should depend on libc6 only. And there is no 
xserver-xorg/buster-backports available.


libgl1/buster-backports, libegl0/buster-backports etc depend on 
libglvnd0/buster-backports


# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux buster/sid
Release:10.11
Codename:   buster


Pekka Sarnila

Bug#1004275: php upgrade apache2: After upgrade php install apache2 and i have intalled lighttpd

[After apt upgrade thet php update install apache2 but it's installed lighttpd]

Package: php apache2
Severity: important
X-Debbugs-Cc: eumesmame...@riseup.net

Dear Maintainer,

After apt update & upgrade a new php update appear but the upgrade also 
installed apache2. 
I am running lighttpd server and apache2 it's not neccesary on my system.
I think in some circunstances this could be a problem.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 5.15.0-2-armmp (SMP w/1 CPU thread)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apache2 depends on:
ii  apache2-bin  2.4.52-1
ii  apache2-data 2.4.52-1
ii  apache2-utils2.4.52-1
ii  init-system-helpers  1.61
ii  lsb-base 11.1.0
ii  mime-support 3.66
ii  perl 5.32.1-6
ii  procps   2:3.3.17-6

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.2

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  links [www-browser]  2.25-1
ii  lynx [www-browser]   2.9.0dev.10-1

Bug#1003798: Acknowledgement (fluxbox: replace FbRootWindow::depth with maxDepth)

[Phil Dibowitz]

Oops, the link to the patch was a copy-paste error. Here's the patch:

http://git.fluxbox.org/fluxbox.git/commit/?id=dcdde4d32c93d01df205bc06d7dfcbd356be031f

--
Phil Dibowitz p...@ipom.com
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't
 matter and those who matter don't mind."
 - Dr. Seuss

Bug#1004274: debian-installer: graphical installer breaks debconf in rescue shell

[Pascal Hambourg]

Package: debian-installer
Version: 20210731+deb11u2
Tags: d-i

Hello,

Steps to reproduce:
- Boot the Debian installer
- At the boot menu, select "Graphical rescue mode"
- follow steps until "Enter rescue mode"
- Select a Debian root device
- Select "Execute a shell in "
- in the shell, execute "dpkg-reconfigure keyboard-configuration"
(any other installed package than keyboard-configuration which has 
configuration questions will do too)


Output:
debconf: unable to initialize frontend: Newt
debconf: (Can't locate Debconf/FrontEnd/Newt.pm in @INC...)
debconf: falling to frontend: Noninteractive

Forcing --frontend=dialog or readline does not help.

This seems to be caused by the DEBIAN_FRONTEND=newt environment variable 
leaked from the graphical installer. It does not happen in the text 
installer nor in tty2/tty3 shells.


Not sure if this bug should be assigned to debian-installer, rescue-mode 
or debconf which should ignore DEBIAN_FRONTEND if invalid or superseded 
with --frontend. The issue also happens when selecting "Execute a shell" 
from the main menu and executing chroot manually, so it is not specific 
to rescue-mode.

Bug#1002961: [Pkg-pascal-devel] Bug#1002961: Bug#1002961: src:castle-game-engine: fails to migrate to testing for too long: FTBFS on armel

[Abou Al Montacir]

Hi Paul,

On Sun, 2022-01-02 at 16:30 +0100, Paul Gevers wrote:
> > ..
> > Moreover CGE upstream think we should abandon armel (and other non 
> > widely used architectures) as a target for CGE, but I think myself it is 
> > a good test for the compiler and tend to think we should  keep it.
> 
> I agree with you. However, as a Release Team member, I also want to 
> prevent packages from being out-of-sync for too long. So, what I suggest 
> in this case is to temporarily disable the test on armel until we have 
> figured out how to fix the situation. That way the package can migrate 
> to testing, without making the situation much worse there.
Can you please review [1] before upload?

[1] 
https://salsa.debian.org/pascal-team/castle-game-engine/-/commit/d9b628c179bb53868e3d0bf9adc0b271969a613b
-- 
Cheers,
Abou Al Montacir



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

Bug#1004273: cdimage.debian.org: Translation-en(.bz2) missing from 'testing' DVD images

[Carsten Mueller]

Package: cdimage.debian.org
Severity: normal

Dear Maintainer,

This issue possibly involves package 'debian-cd' or the package repository.
It appears similar issues have been reported in relation to apt/mirroring,
but I didn't find an existing bug record specific to .iso images.

The jigdo-dvd images of the current (bookworm) testing distribution don't
contain files dists/.../i18n/Translation-en.bz2. This also affects other
media types. Translation-??.bz2 files for other languages are present.

This file contains the full English package descriptions used by the
package system, and Packages.gz only contains single-line summary
descriptions. This obviously impacts usability and package discovery.

On snapshot.debian.org/archive/debian/..., the respective dists/.../i18n
directories for sid and prior releases do contain this file; bookworm
contains Translation-en.xz but .bz2 for other languages.

According to the 'debian-cd' description, this package is used to create
these image files, presumably from the main repository. In its file
'tools/make_disc_trees.pl', only Translation-*.bz2 appears to be handled.
I conjecture that because of this, other language files stored as .bz2
are copied, but English is not because its format is .xz.

Possible fixes (depending on how this is supposed to work):
(1) Make Translation-en.bz2 available in the repository, or
(2) Change debian-cd tools to use Translation-*.[gx]z if .bz2 not present
- Use .xz if package tools support it and .xz decompression is deemed
  to have acceptable CPU/memory cost, or
- Recompress Translation-* files to another format (e.g. .bz2)

Thanks,
Carsten

Bug#984144: fwbuilder: ftbfs with GCC-11

[Sylvestre Ledru]

Hello

Thanks for your patch

it is building for you? It is failing now with:

autoheader: warning: missing template: LIBFWBUILDER_TEMPLATE_DIR
autoheader: warning: missing template: NET_SNMP
autoheader: warning: missing template: UCD_SNMP
autoheader: warning: missing template: WORDS_LITTLEENDIAN
autoreconf: error: /usr/bin/autoheader failed with exit status: 1
dh_autoreconf: error: autoreconf -f -i returned exit code 1
make: *** [debian/rules:13: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2

Build finished at 2022-01-23T22:38:54Z

Thanks

S


Le 20/01/2022 à 16:16, Lukas Märdian a écrit :
> Package: fwbuilder
> Version: 5.3.7-4.1
> Followup-For: Bug #984144
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu jammy ubuntu-patch
> X-Debbugs-Cc: sl...@ubuntu.com
> Control: tags -1 patch
>
> Dear Sylvestre,
>
> fwbuilder fails to build from source due to using dynamic exception specs,
> which are deprecated as of C++17/GCC-11.
>
> In Ubuntu, the attached upstream patch was applied to achieve the following:
>
>   * d/p/ed4db20ec6cabfaea9c36187b7ce40d9d93c6c79.patch: Cherry-pick upstream
> commit to fix FTBFS with C++17/GCC-11
>
> https://github.com/fwbuilder/fwbuilder/commit/ed4db20ec6cabfaea9c36187b7ce40d9d93c6c79
>
> Thanks for considering the patch.
>
> Cheers,
>   Lukas
>
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers impish-updates
>   APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500, 
> 'impish'), (100, 'impish-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.13.0-23-generic (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=de_DE:en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Bug#1004229: [debian-mysql] Bug#1004229: default-mysql-server-core and mariadb-server don't agree on default

[Otto Kekäläinen]

> With mariadb-10.6 migrated to testing, I was expecting to see it
> installed on my bookworm system today. However, it turns out that the
> version of mariadb on my system is determined by
> default-mysql-server-core. I think both packages should agree on what
> the default mariadb version is.

Thanks for reminding us about this.

I've committed the fix in
https://salsa.debian.org/mariadb-team/mysql/-/commits/mysql-defaults/debian/master
and will wait for a few days for review or additional improvements to
mysql-defaults before uploading a new version.

Bug#1004271: os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed

[Ondřej Surý]

Control: forwarded -1 https://gitlab.isc.org/isc-projects/bind9/-/issues/3108

Yeah, there was wrong assumption on our side that the call would either not 
exist or always return valid value. There’s already MR for it which needs to be 
reviewed as I prepared it over the weekend.

Ondrej
--
Ondřej Surý  (He/Him)

> On 23. 1. 2022, at 23:18, Chris Hofstaedtler  wrote:
> 
> Package: bind9-dnsutils
> Version: 1:9.17.22-1
> Severity: serious
> X-Debbugs-Cc: p...@packages.debian.org
> 
> Dear ISC BIND Maintainers,
> Hello Ondřej,
> 
> src:pdns uses dig in its build to test pdns_server. On ppc64el this
> apparently now crashes:
> 
>  + dig -p 5301 @127.0.0.1 smoke.bind.example.org
>  + tee /tmp/tmp.RRMQ1Z4fs4
>  os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
> 
> Full pdns build log here:
>  
> https://buildd.debian.org/status/fetch.php?pkg=pdns=ppc64el=4.5.3-1=1642956562=0
> 
> It feels like, if this crashes on an arch, it would crash regardless of
> the supplied parameters, etc.
> 
> The RUNTIME_CHECK was introduced in upstream commit
>  
> https://gitlab.isc.org/isc-projects/bind9/-/commit/4f78f9d72a5dc3f6a596251e662d00cb80cd5e6d
> as I am sure you know :-)
> 
> Thanks,
> Chris

Bug#1004271: os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed

[Chris Hofstaedtler]

Control: affects -1 src:pdns

* Chris Hofstaedtler  [220123 23:18]:
> It feels like, if this crashes on an arch, it would crash regardless of
> the supplied parameters, etc.

Indeed, on the ppc64el porterbox:

...
Unpacking bind9-dnsutils (1:9.17.22-1) ...
...

(sid_ppc64-dchroot)zeha@perotto:~$ dig
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
(sid_ppc64-dchroot)zeha@perotto:~$

Chris

Bug#1004271: os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed

[Chris Hofstaedtler]

Package: bind9-dnsutils
Version: 1:9.17.22-1
Severity: serious
X-Debbugs-Cc: p...@packages.debian.org

Dear ISC BIND Maintainers,
Hello Ondřej,

src:pdns uses dig in its build to test pdns_server. On ppc64el this
apparently now crashes:

  + dig -p 5301 @127.0.0.1 smoke.bind.example.org
  + tee /tmp/tmp.RRMQ1Z4fs4
  os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed

Full pdns build log here:
  
https://buildd.debian.org/status/fetch.php?pkg=pdns=ppc64el=4.5.3-1=1642956562=0

It feels like, if this crashes on an arch, it would crash regardless of
the supplied parameters, etc.

The RUNTIME_CHECK was introduced in upstream commit
  
https://gitlab.isc.org/isc-projects/bind9/-/commit/4f78f9d72a5dc3f6a596251e662d00cb80cd5e6d
as I am sure you know :-)

Thanks,
Chris

Bug#1004217: /bin/systemctl: Cannot enable units where the Install section is in a truncated override file

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/systemd/issues/22230

Am 23.01.22 um 22:31 schrieb Adam Dinwoodie:

Now reported at https://github.com/systemd/systemd/issues/22230.  Thank
you!


Thanks, marking accordingly.

Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004217: /bin/systemctl: Cannot enable units where the Install section is in a truncated override file

[Adam Dinwoodie]

On Sun, Jan 23, 2022 at 09:38:17AM +0100, Michael Biebl wrote:
> 
> Control: tags -1 + upstream
> 
> Am 23.01.22 um 00:04 schrieb Adam Dinwoodie:
> > Package: systemd
> > Version: 249.7-1+rpi1
> > Severity: normal
> > File: /bin/systemctl
> > 
> > Dear Maintainer,
> > 
> > If one creates a unit with a name like `test-test.service`, one can put
> > override files in the drop-in directory with the truncated name
> > `test-.service.d`, and have them be picked up by systemd, at least for
> > the most part.  However, it appears that `systemctl enable` does not
> > respect these files.
> 
> Seems like a valid issue.
> As we do not ship any Debian specific modifications in that regard, it would
> be great if you can file this issue upstream at
> https://github.com/systemd/systemd/issues
> as it should be handled there.

Now reported at https://github.com/systemd/systemd/issues/22230.  Thank
you!

Bug#1004269: Debian Bug#1004269: Linker segfault while building src:xen

[Hans van Kranenburg]

(To both the Debian bug # and xen-devel list, reply-all is fine)
Hi Xen people,

I just filed a bug at Debian on the binutils package, because since the 
latest binutils package update (Debian 2.37.50.20220106-2), Xen (both 
4.14 and 4.16) fails to build with a segfault at the following point:


x86_64-linux-gnu-ld -mi386pep --subsystem=10 
--image-base=0x82d04000 --stack=0,0 --heap=0,0 
--section-alignment=0x20 --file-alignment=0x20 
--major-image-version=4 --minor-image-version=16 --major-os-version=2 
--minor-os-version=0 --major-subsystem-version=2 
--minor-subsystem-version=0 --no-insert-timestamp --build-id=sha1 -T 
efi.lds -N prelink.o 
/builds/xen-team/debian-xen/debian/output/source_dir/xen/common/symbols-dummy.o 
-b pe-x86-64 efi/buildid.o -o 
/builds/xen-team/debian-xen/debian/output/source_dir/xen/.xen.efi.0x82d04000.0 
&& :

Segmentation fault (core dumped)

Full message and links to build logs etc are in the initial bug message, 
to be seen at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004269


We (Debian Xen Team) are awaiting response, but I thought to also let 
you know already.


* Does the above error 'ring a bell'?
* Can you maybe also reproduce this in a development environment with 
very latest binutils?
* Maybe someone has a useful comment for the Debian binutils maintainer 
about what's happening in this step of the build?

* Any suggestions about what we can do to help figure this out?
* We'll try to help debug, but will surely appreciate upstream help if 
things get too technical. It's simply the case that I did not have to 
look into a very similar issue before, so it's new.


Thanks!
Hans

Bug#1004228: qpdfview: can not print password protected PDF file

[Louis-Philippe Véronneau]

forwarded 1004228 https://bugs.launchpad.net/qpdfview/+bug/1476693
found 1004228 0.4.18-6
thanks

Hi,

Thanks for reporting this bug. It has been tracked upstream in the
following launchpad bug for some time already and won't be fixed until
upstream does so.

https://bugs.launchpad.net/qpdfview/+bug/1476693

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004270: O: esnacc -- ASN.1 to C or C++ or IDL compiler

[Bálint Réczey]

Package: wnpp
Severity: normal

Orphaning the package.

Thanks,
Balint

Bug#1004262: [debian-mysql] Bug#1004262: Acknowledgement (mariadb-server: Instead of being upgraded, mariadb-server gets removed after apt update)

[Otto Kekäläinen]

Thanks for the bug report.

Highlighting lines:

>The following packages will be REMOVED:
>   mariadb-client-10.5 mariadb-client-core-10.5 mariadb-server
>mariadb-server-10.5 python-pip-whl

The package 'mariadb-server' should not be here but instead
'mariadb-server-core-10.5'.

Bug#1003753: Acknowledgement (chromium: chromium --temp-profile window displays only as a white box)

[Karl O. Pinc]

Thanks for the help.

FWIW, if you didn't notice, in the original bug report
I note that I'm using X over the network -- with
client and server on different boxes.
Video playback stopped working (meaning: I get
maybe a frame a second-ish (with avplay/vlc ?)) somewhere around
Stretch.  It worked for years before that.
(But I never tried to play video in a browser,
except perhaps by accident, and can't speak
to what chromium did.)


On Sun, 23 Jan 2022 15:57:38 -0500
Andres Salomon  wrote:

> Karl, the remaining error messages are either benign (like the "stack 
> smashing detected" ones, which are due to the older version of clang
> in bullseye and don't show up in newer versions of clang), or seem to
> be related to lack of hardware support from libgl1-mesa-dri. The next
> steps to dealing with the mesa issues are trying out a backport of 
> libgl1-mesa-dri to see if it works better for you, and also going 
> through mesa's bug list to see if your specific radeonsi issues have 
> already been reported and/or solved. Your specific gpu hardware would
> be listed in the output of chrome://gpu, if that's helpful for
> reporting a mesa bug or following up on an existing one.

I will dig into it.  (I'm never sure what/how video acceleration
is supposed to work with the client and server on different boxes.)

It may take a while for me to look around.  As you may guess,
I don't care much about video.

> For the record, I don't know why the new release fixed your issue
> with the --temp-profile window. Seems like an upstream chromium bug
> that got fixed, as the debian side of things (for X11 at least)
> remained the same. ¯\_(ツ)_/¯
> 
> At some point I hope to start including swiftshader with chromium,
> which would provide an admittedly slow but functional software
> fallback for folks whose GL hardware implementations are lacking or
> broken.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#1004269: Linker segfault while building src:xen

[Hans van Kranenburg]

Package: src:binutils
Version: 2.37.50.20220106-2
X-Debbugs-CC: pkg-xen-de...@lists.alioth.debian.org

Hi,

With the last binutils version src:xen starts to FTBFS.

 >8  Xen 4.16 for experimental  >8 

* Last passed build, using binutils 2.37-10.
Job overview:
 https://salsa.debian.org/xen-team/debian-xen/-/pipelines/329021
Full log:
 https://salsa.debian.org/xen-team/debian-xen/-/jobs/2290845/raw

* First failed build, using the same source code, and using binutils 
2.37.50.20220106-2:

Job overview:
 https://salsa.debian.org/xen-team/debian-xen/-/pipelines/338409
Full log:
 https://salsa.debian.org/xen-team/debian-xen/-/jobs/2375744/raw

At the end of the full log, the failure can be observed:

x86_64-linux-gnu-ld -mi386pep --subsystem=10 
--image-base=0x82d04000 --stack=0,0 --heap=0,0 
--section-alignment=0x20 --file-alignment=0x20 
--major-image-version=4 --minor-image-version=16 --major-os-version=2 
--minor-os-version=0 --major-subsystem-version=2 
--minor-subsystem-version=0 --no-insert-timestamp --build-id=sha1 -T 
efi.lds -N prelink.o 
/builds/xen-team/debian-xen/debian/output/source_dir/xen/common/symbols-dummy.o 
-b pe-x86-64 efi/buildid.o -o 
/builds/xen-team/debian-xen/debian/output/source_dir/xen/.xen.efi.0x82d04000.0 
&& :

Segmentation fault (core dumped)

The above logs are for src:xen 4.16.0-1~exp1 which we were about to 
upload to experimental.


 >8  Xen 4.14 currently in unstable  >8 

I also triggered a CI run again for the current src:xen 
4.14.3+32-g9de3671772-1. The same segfault happens there, and both for 
the amd64 and i386 build test (i386 is no longer included for Xen 4.16).


Job overview:
 https://salsa.debian.org/xen-team/debian-xen/-/pipelines/340556
Full logs:
 https://salsa.debian.org/xen-team/debian-xen/-/jobs/2394079/raw
 https://salsa.debian.org/xen-team/debian-xen/-/jobs/2394080/raw

 >8 

So, this is what we observe. In the Debian Xen team, there's not a great 
amount of knowledge about the exact internals of what happens here.


* At least, we can let you know there's a regression.
* Currently progress on our Xen 4.16 upload is blocked, and we also 
can't do updates of the current Xen 4.14 packages (e.g. because of 
security fixes).
* We're available to help debugging this issue if needed. We'll need 
guidance, so it will mean that we'll work based on your instructions.
* After sending this report and getting the confirmation from the BTS, 
I'll send a reply with the upstream Xen development mailing list in Cc.


Thanks in advance,
Hans van Kranenburg

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Christoph Berg]

Re: Sean Whitton
> Hello,
> 
> On Sun 23 Jan 2022 at 10:04PM +01, Chris Hofstaedtler wrote:
> 
> > I guess the best thing would be to introduce a new binary package,
> > but I am out of ideas on naming it. Open for ideas here.
> 
> util-linux-extra?

If it's about rename only, "rename-ul" or even "rename.ul"?

I guess it should also contain the historical name as a symlink.

Christoph

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Sean Whitton]

Hello,

On Sun 23 Jan 2022 at 10:04PM +01, Chris Hofstaedtler wrote:

> I guess the best thing would be to introduce a new binary package,
> but I am out of ideas on naming it. Open for ideas here.

util-linux-extra?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1002532: pygments breaks ruby-pygments.rb autopkgtest: UTF-8 != ASCII-8BIT

[Mattia Rizzolo]

On Fri, Jan 21, 2022 at 03:51:02PM +0100, Alexandre Ghiti wrote:
> I can't find how to create a MR in salsa, can you pull directly from here:
> 
> https://salsa.debian.org/alexghiti/ruby-pygments.rb/-/tree/int/alex/2.3.0
> 
> It successfully built in my PPA, if you need any more modification, do
> not hesitate.

Ah, another thing.  Please be careful with the version you pick.

You used 2.3.0+ds-1ubuntu1, which is *higher* than what I'll be
uploading, namely 2.3.0+ds-1.
Furthermore, in your PPA you used 2.3.0+ds-1ubuntu2, which would also
conflict with an eventual -1ubuntu done in the offical ubuntu archive.

I'd recommend you used something like -0ppa1 or -0ubuntu1~ppa1 or
somesuch.

(in this case this is of no consequence, but just something to note).



Lastly, I noticed that you haven't even touched the changelog.  In this
case there was even a new copyright holder, so it really should have
been updated.
I didn't add you to the paragraph of d/copyright, as I assume you are
doing this under your paid time, and I don't know what's Canonical's
rules regarding copyright here.  If needed/wanted, just send me a note
and I'll update the copy in git.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1004268: buster-pu: package libextractor/1:1.8-2+deb10u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Daniel Baumann , 
t...@security.debian.org

  * CVE-2019-15531: Invalid read for malformed DVI files.
(Closes: #935553)
diff -Nru libextractor-1.8/debian/changelog libextractor-1.8/debian/changelog
--- libextractor-1.8/debian/changelog   2018-12-27 20:45:49.0 +0200
+++ libextractor-1.8/debian/changelog   2022-01-23 23:10:06.0 +0200
@@ -1,3 +1,11 @@
+libextractor (1:1.8-2+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2019-15531: Invalid read for malformed DVI files.
+(Closes: #935553)
+
+ -- Adrian Bunk   Sun, 23 Jan 2022 23:10:06 +0200
+
 libextractor (1:1.8-2) unstable; urgency=high
 
   * Fix out-of-bounds read vulnerability in common/convert.c (Closes: #917214,
diff -Nru libextractor-1.8/debian/patches/0001-fix-5846.patch 
libextractor-1.8/debian/patches/0001-fix-5846.patch
--- libextractor-1.8/debian/patches/0001-fix-5846.patch 1970-01-01 
02:00:00.0 +0200
+++ libextractor-1.8/debian/patches/0001-fix-5846.patch 2022-01-23 
23:09:09.0 +0200
@@ -0,0 +1,181 @@
+From aad7a7857b815175e70e2270115a3c8cb0445765 Mon Sep 17 00:00:00 2001
+From: Christian Grothoff 
+Date: Fri, 23 Aug 2019 09:35:53 +0200
+Subject: fix #5846
+
+---
+ src/plugins/dvi_extractor.c | 88 +++--
+ 1 file changed, 45 insertions(+), 43 deletions(-)
+
+diff --git a/src/plugins/dvi_extractor.c b/src/plugins/dvi_extractor.c
+index 268b48c..e3aa450 100644
+--- a/src/plugins/dvi_extractor.c
 b/src/plugins/dvi_extractor.c
+@@ -1,6 +1,6 @@
+ /*
+  This file is part of libextractor.
+- Copyright (C) 2002, 2003, 2004, 2012, 2017 Vidyut Samanta and Christian 
Grothoff
++ Copyright (C) 2002, 2003, 2004, 2012, 2017, 2019 Vidyut Samanta and 
Christian Grothoff
+ 
+  libextractor is free software; you can redistribute it and/or modify
+  it under the terms of the GNU General Public License as published
+@@ -182,6 +182,8 @@ EXTRACTOR_dvi_extract_method (struct 
EXTRACTOR_ExtractContext *ec)
+   size = ec->get_size (ec->cls);
+   if (size > 16 * 1024 * 1024)
+ return; /* too large */
++  if (klen + 15 > size)
++return; /* malformed klen */
+   if (NULL == (data = malloc ((size_t) size)))
+ return; /* out of memory */
+   memcpy (data, buf, iret);
+@@ -189,16 +191,16 @@ EXTRACTOR_dvi_extract_method (struct 
EXTRACTOR_ExtractContext *ec)
+   while (off < size)
+ {
+   if (0 >= (iret = ec->read (ec->cls, , 16 * 1024)))
+-  {
+-free (data);
+-return;
+-  }
++{
++  free (data);
++  return;
++}
+   memcpy ([off], buf, iret);
+   off += iret;
+ }
+   pos = size - 1;
+   while ( (223 == data[pos]) &&
+-(pos > 0) )
++  (pos > 0) )
+ pos--;
+   if ( (2 != data[pos]) ||
+(pos < 40) )
+@@ -225,9 +227,9 @@ EXTRACTOR_dvi_extract_method (struct 
EXTRACTOR_ExtractContext *ec)
+ break;
+   if ( (pos + 45 > size) ||
+  (pos + 45 < pos) )
+-  goto CLEANUP;
++goto CLEANUP;
+   if (data[pos] != 139) /* expect 'bop' */
+-  goto CLEANUP;
++goto CLEANUP;
+   pageCount++;
+   opos = pos;
+   pos = getIntAt ([opos + 41]);
+@@ -238,24 +240,24 @@ EXTRACTOR_dvi_extract_method (struct 
EXTRACTOR_ExtractContext *ec)
+ }
+   /* ok, now we believe it's a dvi... */
+   snprintf (pages,
+-  sizeof (pages),
+-  "%u", 
+-  pageCount);
++sizeof (pages),
++"%u", 
++pageCount);
+   if (0 != ec->proc (ec->cls, 
+-   "dvi",
+-   EXTRACTOR_METATYPE_PAGE_COUNT,
+-   EXTRACTOR_METAFORMAT_UTF8,
+-   "text/plain",
+-   pages,
+-   strlen (pages) + 1))
++ "dvi",
++ EXTRACTOR_METATYPE_PAGE_COUNT,
++ EXTRACTOR_METAFORMAT_UTF8,
++ "text/plain",
++ pages,
++ strlen (pages) + 1))
+ goto CLEANUP;
+   if (0 != ec->proc (ec->cls, 
+-   "dvi",
+-   EXTRACTOR_METATYPE_MIMETYPE,
+-   EXTRACTOR_METAFORMAT_UTF8,
+-   "text/plain",
+-   "application/x-dvi",
+-   strlen ("application/x-dvi") + 1))
++ "dvi",
++ EXTRACTOR_METATYPE_MIMETYPE,
++ EXTRACTOR_METAFORMAT_UTF8,
++ "text/plain",
++ "application/x-dvi",
++ strlen ("application/x-dvi") + 1))
+ goto CLEANUP;
+   {
+ char comment[klen + 1];
+@@ -263,18 +265,18 @@ EXTRACTOR_dvi_extract_method (struct 
EXTRACTOR_ExtractContext *ec)
+ comment[klen] = '\0';
+ memcpy (comment, [15], klen);
+ if (0 != ec->proc (ec->cls, 
+-

Bug#944729: closed by Debian FTP Masters (reply to Hilko Bengen ) (Bug#944729: fixed in libguestfs 1:1.46.2-6)

[Johannes Schauer Marin Rodrigues]

Hi Hilko,

Quoting Debian Bug Tracking System (2022-01-23 12:51:08)
> This is an automatic notification regarding your Bug report
> which was filed against the src:libguestfs package:
> 
> #944729: libguestfs: Please add an autopkgtest
> 
> It has been closed by Debian FTP Masters  
> (reply to Hilko Bengen ).

thanks for applying my patch!

It seems the autopkgtest fails on debci:

https://ci.debian.net/data/autopkgtest/testing/amd64/libg/libguestfs/18606297/log.gz

Try removing --mode=root from the mmdebstrap call.

You can also remove the comment above the mmdebstrap call. The first two points
were valid in 2019 but are not true anymore.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1004266:

[Maksim Dmitrichenko]

It wasn't mentioned in previous bug reports but packages also
missing GeoTrust RSA CA 2018 certificate which actually triggered me into
investigation of issues with missing certificates in ca-certificates
package.

-- 
With best regards
  Maksim Dmitrichenko

Bug#1004262: Acknowledgement (mariadb-server: Instead of being upgraded, mariadb-server gets removed after apt update)

[Rutger van Sleen]

I've been digging around with some help from folks over at #debian-nl 
and came eventually to this. Not sure if it really helps, but it might 
give a clue of what is going on. I aborted the command, so if I can 
provide anything else, I'm happy to do so.



$ apt -oDebug::pkgDepCache::Marker=yes full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
  Hold prevents MarkInstall of php-common:amd64 < 2:76 | 2:92 @hi umH >
  MarkInstall hdparm:amd64 < 9.60+ds-1 @ii mK NPb IPb > FU=0
  MarkInstall easy-rsa:amd64 < 3.0.8-1 @ii mK NPb IPb > FU=0
  MarkInstall mariadb-server:amd64 < 1:10.5.12-1 -> 1:10.6.5-2 @ii umU 
Ib > FU=0
MarkInstall mariadb-server-10.6:amd64 < none -> 1:10.6.5-2 @un uN 
Ib > FU=0
  MarkInstall mariadb-client-10.6:amd64 < none -> 1:10.6.5-2 @un uN 
Ib > FU=0
MarkInstall mariadb-client-core-10.6:amd64 < none -> 1:10.6.5-2 
@un uN Ib > FU=0
MarkDelete mariadb-client-core-10.5:amd64 < 1:10.5.12-1 @ii mK 
Ib > FU=0

  MarkDelete mariadb-client-10.5:amd64 < 1:10.5.12-1 @ii mK Ib > FU=0
  MarkInstall mariadb-server-core-10.6:amd64 < none -> 1:10.6.5-2 
@un uN Ib > FU=0

MarkInstall libpmem1:amd64 < none -> 1.11.1-3 @un uN Ib > FU=0
  MarkInstall libdaxctl1:amd64 < none -> 71.1-1 @un uN > FU=0
  MarkInstall libndctl6:amd64 < none -> 71.1-1 @un uN > FU=0
  MarkDelete mariadb-server-core-10.5:amd64 < 1:10.5.12-1 @ii mK Ib 
> FU=0
  MarkInstall libhtml-template-perl:amd64 < none -> 2.97-1.1 @un 
umN Ib > FU=0

MarkInstall libcgi-pm-perl:amd64 < none -> 4.53-1 @un uN Ib > FU=0
  MarkInstall libhtml-parser-perl:amd64 < none -> 3.76-1 @un uN 
Ib > FU=0
MarkInstall libhtml-tagset-perl:amd64 < none -> 3.20-4 @un 
uN > FU=0

MarkInstall liburi-perl:amd64 < none -> 5.10-1 @un umN > FU=0
MarkInstall libhttp-message-perl:amd64 < none -> 6.36-1 @un 
uN Ib > FU=0
  MarkInstall libencode-locale-perl:amd64 < none -> 
1.05-1.1 @un uN > FU=0
  MarkInstall libhttp-date-perl:amd64 < none -> 6.05-1 @un 
uN Ib > FU=0
MarkInstall libtimedate-perl:amd64 < none -> 2.3300-2 
@un uN > FU=0
  MarkInstall libio-html-perl:amd64 < none -> 1.004-2 @un 
uN > FU=0
  MarkInstall libclone-perl:amd64 < none -> 0.45-1+b1 @un 
umN > FU=0
  MarkInstall libcgi-fast-perl:amd64 < none -> 1:2.15-1 @un uN 
Ib > FU=0
MarkInstall libfcgi-perl:amd64 < none -> 0.82+ds-1 @un uN 
Ib > FU=0
  MarkInstall libfcgi0ldbl:amd64 < none -> 2.4.2-2 @un uN 
IPb > FU=0
MarkInstall libfcgi-bin:amd64 < none -> 2.4.2-2 @un uN 
> FU=0

MarkDelete mariadb-server-10.5:amd64 < 1:10.5.12-1 @ii mK NPb Ib > FU=0
  MarkInstall samba-vfs-modules:amd64 < 2:4.13.14+dfsg-1+b1 @ii mK NPb 
IPb > FU=0

  MarkInstall php:amd64 < 2:7.4+76 -> 2:8.1+92 @ii umU Ib > FU=0
MarkInstall php8.1:amd64 < none -> 8.1.1-4 @un uN Ib > FU=0
  MarkInstall libapache2-mod-php8.1:amd64 < none -> 8.1.1-4 @un uN 
> FU=0

  MarkInstall libqt5core5a:amd64 < 5.15.2+dfsg-14 @ii mK NPb IPb > FU=0
  MarkInstall python3-virtualenv:amd64 < 20.12.1+ds-1 -> 20.13.0+ds-1 
@ii umU Ib > FU=0
MarkInstall python3-pip-whl:amd64 < none -> 21.3.1+dfsg-3 @un uN Ib 
> FU=0

MarkDelete python-pip-whl:amd64 < 20.3.4-4 @ii mK > FU=0
MarkInstall python3-setuptools-whl:amd64 < none -> 59.6.0-1.2 @un 
uN > FU=0

MarkInstall python3-wheel-whl:amd64 < none -> 0.37.1-2 @un uN > FU=0
MarkKeep python-pip-whl:amd64 < 20.3.4-4 @ii mR > FU=0
  MarkInstall php-gd:amd64 < 2:7.4+76 -> 2:8.1+92 @ii umU Ib > FU=0
MarkInstall php8.1-gd:amd64 < none -> 8.1.1-4 @un uN > FU=0
  Hold prevents MarkInstall of php-common:amd64 < 2:76 | 2:92 @hi umH >
  MarkInstall php8.1-imagick:amd64 < 3.6.0-4 @ii mK NPb IPb > FU=0
  MarkInstall php-imagick:amd64 < 3.6.0-4 @ii mK NPb IPb > FU=0
  MarkInstall po-debconf:amd64 < 1.0.21+nmu1 @ii mK NPb IPb > FU=0
  MarkInstall libjson-perl:amd64 < 4.04000-1 @ii mK NPb IPb > FU=0
  MarkInstall libwmf0.2-7:amd64 < 0.2.8.4-17+b1 @ii mK NPb IPb > FU=0
  MarkInstall libgs9-common:amd64 < 9.55.0~dfsg-3 @ii mK NPb IPb > FU=0
  MarkInstall php-curl:amd64 < 2:7.4+76 -> 2:8.1+92 @ii umU Ib > FU=0
MarkInstall php8.1-curl:amd64 < none -> 8.1.1-4 @un uN > FU=0
  MarkInstall libvdpau1:amd64 < 1.4-3 @ii mK NPb IPb > FU=0
MarkKeep mariadb-server-core-10.5:amd64 < 1:10.5.12-1 @ii mR > FU=0
  MarkInstall libmoo-perl:amd64 < 2.005004-3 @ii mK NPb IPb > FU=0
  MarkInstall php-intl:amd64 < 2:7.4+76 -> 2:8.1+92 @ii umU Ib > FU=0
MarkInstall php8.1-intl:amd64 < none -> 8.1.1-4 @un uN > FU=0
  MarkInstall dpkg-dev:amd64 < 1.21.1 @ii mK NPb IPb > FU=0
  MarkInstall libkrb5-3:amd64 < 1.18.3-7 @ii mK NPb IPb > FU=0
  MarkInstall vim-latexsuite:amd64 < 1:1.10.0-1 @ii mK NPb IPb > FU=0
  MarkInstall libuuid1:amd64 < 2.37.2-6 @ii mK NPb IPb > FU=0
  MarkInstall php-mbstring:amd64 < 2:7.4+76 -> 2:8.1+92 @ii umU Ib 

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Chris Hofstaedtler]

* Christoph Berg  [220123 21:51]:
> Re: Don Armstrong
[..]
> > Not impossible to change, of course, but an ideal transition would avoid
> > breaking currently working scripts and installs.
> 
> We were discussing the bug in last week's tech-ctte meeting, and the
> gist of the discussion was that, in a ideal world, Debian would be
> shipping the util-linux version as /usr/bin/rename to match what other
> distributions are shipping, but that since we have been shipping the
> Perl rename for the past 20 years, a proper transition would be very
> hard. Especially in the light that this is an end-user tool and not
> something we can control by a MBF and a lot of patches.

Yeah. I was thinking we could ship *one* release without a
/usr/bin/rename at all. Not sure if that is a good idea.

> Unfortunately the current defaults seem to be that we have neither,
> none of my systems has any "rename" command. OTOH that might indicate
> there's a head-start on a transition introducing u-l's rename as
> /usr/bin/rename.
> 
> Chris, would u-l be willing to reintroduce rename, or do you rather
> want to reduce the number of commands?
> 
> Maybe if alternatives are not the correct tool, moving the u-l rename
> to a separate package, and conflicting with the perl rename is better?
> (Still ugly, but the situation isn't ideal.)

I believe using alternatives would introduce an RC bug.

I was hoping we could put util-linux' rename into the
"bsdextrautils" binary package, which has utilities like write, col,
etc; to avoid putting it into an Essentials: yes package, and to
avoid a new binary package. However, picking bsdextrautils seems
... maybe not ideal if it should Conflict with rename.

I guess the best thing would be to introduce a new binary package,
but I am out of ideas on naming it. Open for ideas here.

Chris

Bug#1004267: buster-pu: package libpcap/1.8.1-6+deb10u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Romain Francoise , t...@security.debian.org

  * CVE-2019-15165: Improper PHB header length validation.
(Closes: #941697)
diff -Nru libpcap-1.8.1/debian/changelog libpcap-1.8.1/debian/changelog
--- libpcap-1.8.1/debian/changelog  2017-12-31 17:56:33.0 +0200
+++ libpcap-1.8.1/debian/changelog  2022-01-23 23:00:19.0 +0200
@@ -1,3 +1,11 @@
+libpcap (1.8.1-6+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2019-15165: Improper PHB header length validation.
+(Closes: #941697)
+
+ -- Adrian Bunk   Sun, 23 Jan 2022 23:00:19 +0200
+
 libpcap (1.8.1-6) unstable; urgency=medium
 
   * debian/watch: add pgpsigurlmangle option.
diff -Nru 
libpcap-1.8.1/debian/patches/0001-do-sanity-checks-on-PHB-header-length-before-allocat.patch
 
libpcap-1.8.1/debian/patches/0001-do-sanity-checks-on-PHB-header-length-before-allocat.patch
--- 
libpcap-1.8.1/debian/patches/0001-do-sanity-checks-on-PHB-header-length-before-allocat.patch
1970-01-01 02:00:00.0 +0200
+++ 
libpcap-1.8.1/debian/patches/0001-do-sanity-checks-on-PHB-header-length-before-allocat.patch
2022-01-23 23:00:07.0 +0200
@@ -0,0 +1,53 @@
+From 7ef51510ab5b337cb8b34e1dbe9c9a64fc2c20b9 Mon Sep 17 00:00:00 2001
+From: Michael Richardson 
+Date: Fri, 20 Sep 2019 11:02:00 -0400
+Subject: do sanity checks on PHB header length before allocating memory. There
+ was no fault; but doing the check results in a more consistent error
+
+---
+ sf-pcap-ng.c | 13 -
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+diff --git a/sf-pcap-ng.c b/sf-pcap-ng.c
+index 0c02829e..860487b7 100644
+--- a/sf-pcap-ng.c
 b/sf-pcap-ng.c
+@@ -102,7 +102,7 @@ struct option_header {
+  * Section Header Block.
+  */
+ #define BT_SHB0x0A0D0D0A
+-
++#define BT_SHB_INSANE_MAX   1024U*1024U*1U  /* 1MB should be enough */
+ struct section_header_block {
+   bpf_u_int32 byte_order_magic;
+   u_short major_version;
+@@ -247,7 +247,7 @@ read_bytes(FILE *fp, void *buf, size_t bytes_to_read, int 
fail_on_eof,
+   if (amt_read == 0 && !fail_on_eof)
+   return (0); /* EOF */
+   pcap_snprintf(errbuf, PCAP_ERRBUF_SIZE,
+-  "truncated dump file; tried to read %lu bytes, only 
got %lu",
++  "truncated pcap-ng dump file; tried to read %lu 
bytes, only got %lu",
+   (unsigned long)bytes_to_read,
+   (unsigned long)amt_read);
+   }
+@@ -798,11 +798,14 @@ pcap_ng_check_header(bpf_u_int32 magic, FILE *fp, u_int 
precision, char *errbuf,
+   /*
+* Check the sanity of the total length.
+*/
+-  if (total_length < sizeof(*bhdrp) + sizeof(*shbp) + sizeof(struct 
block_trailer)) {
++  if (total_length < sizeof(*bhdrp) + sizeof(*shbp) + sizeof(struct 
block_trailer) ||
++(total_length > BT_SHB_INSANE_MAX)) {
+   pcap_snprintf(errbuf, PCAP_ERRBUF_SIZE,
+-  "Section Header Block in pcap-ng dump file has a length of 
%u < %lu",
++  "Section Header Block in pcap-ng dump file has invalid 
length %lu < _%u_ < %u (BT_SHB_INSANE_MAX)",
++  (unsigned long)(sizeof(*bhdrp) + sizeof(*shbp) + 
sizeof(struct block_trailer)),
+   total_length,
+-  (unsigned long)(sizeof(*bhdrp) + sizeof(*shbp) + 
sizeof(struct block_trailer)));
++  BT_SHB_INSANE_MAX);
++
+   *err = 1;
+   return (NULL);
+   }
+-- 
+2.20.1
+
diff -Nru libpcap-1.8.1/debian/patches/series 
libpcap-1.8.1/debian/patches/series
--- libpcap-1.8.1/debian/patches/series 2017-12-31 17:31:01.0 +0200
+++ libpcap-1.8.1/debian/patches/series 2022-01-23 23:00:17.0 +0200
@@ -8,3 +8,4 @@
 disable-remote.diff
 man-errors.diff
 pcap-config.diff
+0001-do-sanity-checks-on-PHB-header-length-before-allocat.patch

Bug#1002532: pygments breaks ruby-pygments.rb autopkgtest: UTF-8 != ASCII-8BIT

[Mattia Rizzolo]

Hi Alex!

Please take note that the Debian BTS doesn't subscribe automatically
posters to a bug report, so you need to explicitly CC people that you
want to message!
(Grahm pointed me to your reply ^^)

Also, I'm happy to have pointed out to tools and things you weren't
aware of!  :)

On Fri, Jan 21, 2022 at 03:51:02PM +0100, Alexandre Ghiti wrote:
> On Fri, 21 Jan 2022 12:08:27 +0100 Alexandre Ghiti
>  wrote:
> > On Thu, 20 Jan 2022 18:50:33 +0100 Mattia Rizzolo  wrote:
> > > * You did a ton of patch wrangling, including deletion, renaming,
> > > rebasing, etc. which is all fine, except that the way you did it
> > > obscures quite a bit what you did. Why did you drop the numbers from
> > > the patches? Do you have --no-patch-numbers as you gbp-pq default or
> > > something?
> >
> > I changed the patches names since they were different: I fixed that in
> > my coming MR. Thanks for gbp that I did not know neither.

Indeed, those patches from before were handled by gbp-pq, which
basically uses `git format-patch` instead of plain dep-3 headers.

I must admit that I prefer the original DEP-3, however that makes the
gbp-pq import/export more noisy.  But well, that's fine.

> > > * why requiring gem2deb >=1 ? that's already in bullseye as well in
> > > focal, so why did you feel the need to add the version? (that's also
> > > not in the changelog)
> >
> > I simply copied the debian/ directory from the previous version that I
> > got from pull-lp-source, I did not use git...I'll use git in the
> > future, thanks.

Ah, I see indeed that the current package has that thing.  mh.  Sorry I
didn't notice that.


Normally it's fine to base some work in the released package, however
especially for team-maintained packages, it might be more useful and
helpful to do the work in git nowadays, even if that exposes the
submitter to the mess that is git maintenance in debian (where different
teams have different workflows and different tools).

> > > Could I ask you to submit a MR on top of it, with at least commits
> > > separating the deletion, refresh and rebasing of patches (and eventual
> > > new ones, I can't tell at a glance if any new patch appeared…) also
> > > separated.
> > > https://salsa.debian.org/ruby-team/ruby-pygments.rb
> >
> 
> > It's on its way :)
> 
> I can't find how to create a MR in salsa,

That's because you create a new repo instead of clicking the "fork"
button on the original project.  GitLab allows for MR to be created only
in forks.

> can you pull directly from here:
> 
> https://salsa.debian.org/alexghiti/ruby-pygments.rb/-/tree/int/alex/2.3.0
> 
> It successfully built in my PPA, if you need any more modification, do
> not hesitate.

That looks fine!

I'm going to massage the changelog a bit, but besides that it looks
cool!


Thank you!

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1004265: buster-pu: package rsyslog/8.1901.0-1+deb10u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Michael Biebl , t...@security.debian.org

  * CVE-2019-17041: Heap overflow in the AIX message parser.
(Closes: #942067)
  * CVE-2019-17042: Heap overflow in the Cisco log message parser.
(Closes: #942065)
diff -Nru rsyslog-8.1901.0/debian/changelog rsyslog-8.1901.0/debian/changelog
--- rsyslog-8.1901.0/debian/changelog   2019-02-26 19:43:39.0 +0200
+++ rsyslog-8.1901.0/debian/changelog   2022-01-23 20:27:01.0 +0200
@@ -1,3 +1,13 @@
+rsyslog (8.1901.0-1+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2019-17041: Heap overflow in the AIX message parser.
+(Closes: #942067)
+  * CVE-2019-17042: Heap overflow in the Cisco log message parser.
+(Closes: #942065)
+
+ -- Adrian Bunk   Sun, 23 Jan 2022 20:27:01 +0200
+
 rsyslog (8.1901.0-1) unstable; urgency=medium
 
   * New upstream version 8.1901.0
diff -Nru 
rsyslog-8.1901.0/debian/patches/0001-pmaixforwardedfrom-bugfix-potential-misadressing.patch
 
rsyslog-8.1901.0/debian/patches/0001-pmaixforwardedfrom-bugfix-potential-misadressing.patch
--- 
rsyslog-8.1901.0/debian/patches/0001-pmaixforwardedfrom-bugfix-potential-misadressing.patch
 1970-01-01 02:00:00.0 +0200
+++ 
rsyslog-8.1901.0/debian/patches/0001-pmaixforwardedfrom-bugfix-potential-misadressing.patch
 2022-01-23 20:26:28.0 +0200
@@ -0,0 +1,39 @@
+From de51d602532835caafa401401424b61354f404fc Mon Sep 17 00:00:00 2001
+From: Rainer Gerhards 
+Date: Fri, 27 Sep 2019 13:36:02 +0200
+Subject: pmaixforwardedfrom bugfix: potential misadressing
+
+---
+ contrib/pmaixforwardedfrom/pmaixforwardedfrom.c | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/contrib/pmaixforwardedfrom/pmaixforwardedfrom.c 
b/contrib/pmaixforwardedfrom/pmaixforwardedfrom.c
+index 37157c7d4..ebf12ebbe 100644
+--- a/contrib/pmaixforwardedfrom/pmaixforwardedfrom.c
 b/contrib/pmaixforwardedfrom/pmaixforwardedfrom.c
+@@ -109,6 +109,10 @@ CODESTARTparse
+   /* bump the message portion up by skipLen(23 or 5) characters to 
overwrite the "Message forwarded from
+ " or "From " with the hostname */
+   lenMsg -=skipLen;
++  if(lenMsg < 2) {
++  dbgprintf("not a AIX message forwarded from message has nothing 
after header\n");
++  ABORT_FINALIZE(RS_RET_COULD_NOT_PARSE);
++  }
+   memmove(p2parse, p2parse + skipLen, lenMsg);
+   *(p2parse + lenMsg) = '\n';
+   *(p2parse + lenMsg + 1)  = '\0';
+@@ -120,6 +124,11 @@ really an AIX log, but has a similar preamble */
+   --lenMsg;
+   ++p2parse;
+   }
++  if (lenMsg < 1) {
++  dbgprintf("not a AIX message forwarded from message has nothing 
after colon "
++  "or no colon at all\n");
++  ABORT_FINALIZE(RS_RET_COULD_NOT_PARSE);
++  }
+   if (lenMsg && *p2parse != ':') {
+   DBGPRINTF("not a AIX message forwarded from mangled log but similar 
enough that the preamble has "
+   "been removed\n");
+-- 
+2.20.1
+
diff -Nru 
rsyslog-8.1901.0/debian/patches/0002-pmcisconames-bugfix-potential-misadressing.patch
 
rsyslog-8.1901.0/debian/patches/0002-pmcisconames-bugfix-potential-misadressing.patch
--- 
rsyslog-8.1901.0/debian/patches/0002-pmcisconames-bugfix-potential-misadressing.patch
   1970-01-01 02:00:00.0 +0200
+++ 
rsyslog-8.1901.0/debian/patches/0002-pmcisconames-bugfix-potential-misadressing.patch
   2022-01-23 20:26:28.0 +0200
@@ -0,0 +1,37 @@
+From d53b97e5dc3cc1e7464967f7ace2c2bcda6bc938 Mon Sep 17 00:00:00 2001
+From: Rainer Gerhards 
+Date: Fri, 27 Sep 2019 15:02:52 +0200
+Subject: pmcisconames bugfix: potential misadressing
+
+---
+ contrib/pmcisconames/pmcisconames.c | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/contrib/pmcisconames/pmcisconames.c 
b/contrib/pmcisconames/pmcisconames.c
+index 7f376ad17..39506ce59 100644
+--- a/contrib/pmcisconames/pmcisconames.c
 b/contrib/pmcisconames/pmcisconames.c
+@@ -119,6 +119,11 @@ CODESTARTparse
+   --lenMsg;
+   ++p2parse;
+   }
++  /* Note: we deliberately count the 0-byte below because we need to go 
chars+1! */
++  if(lenMsg < (int) sizeof(OpeningText)) {
++  dbgprintf("pmcisconames: too short for being cisco messages\n");
++  ABORT_FINALIZE(RS_RET_COULD_NOT_PARSE);
++  }
+   /* skip the space after the hostname */
+   lenMsg -=1;
+   p2parse +=1;
+@@ -126,7 +131,7 @@ CODESTARTparse
+   log and fix it */
+   if(strncasecmp((char*) p2parse, OpeningText, sizeof(OpeningText)-1) != 
0) {
+   /* wrong opening text */
+-  DBGPRINTF("not a cisco name mangled log!\n");
++  DBGPRINTF("not a cisco name mangled log!\n");
+   ABORT_FINALIZE(RS_RET_COULD_NOT_PARSE);
+   }
+   /* bump the message portion up by 

Bug#1004266: ca-certificates: GeoTrust Global CA certificate is again missing

[Max Dmitrichenko]

Package: ca-certificates
Version: 20210119
Severity: important
X-Debbugs-Cc: dmitr...@gmail.com

This case was once reported in #962596. Though it is marked done current 
package's changelog doesn't reflect any of changes reported in #962596.

Broken behavior is still the same: everything works in any browser but when 
using CLI tool like curl verification fails.


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

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

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  openssl1.1.1k-1+deb11u1

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information:
  ca-certificates/enable_crts: mozilla/ACCVRAIZ1.crt, 
mozilla/AC_RAIZ_FNMT-RCM.crt, mozilla/Actalis_Authentication_Root_CA.crt, 
mozilla/AffirmTrust_Commercial.crt, mozilla/AffirmTrust_Networking.crt, 
mozilla/AffirmTrust_Premium.crt, mozilla/AffirmTrust_Premium_ECC.crt, 
mozilla/Amazon_Root_CA_1.crt, mozilla/Amazon_Root_CA_2.crt, 
mozilla/Amazon_Root_CA_3.crt, mozilla/Amazon_Root_CA_4.crt, 
mozilla/Atos_TrustedRoot_2011.crt, 
mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt, 
mozilla/Baltimore_CyberTrust_Root.crt, mozilla/Buypass_Class_2_Root_CA.crt, 
mozilla/Buypass_Class_3_Root_CA.crt, mozilla/CA_Disig_Root_R2.crt, 
mozilla/Certigna.crt, mozilla/Certigna_Root_CA.crt, 
mozilla/certSIGN_ROOT_CA.crt, mozilla/certSIGN_Root_CA_G2.crt, 
mozilla/Certum_Trusted_Network_CA_2.crt, mozilla/Certum_Trusted_Network_CA.crt, 
mozilla/CFCA_EV_ROOT.crt, mozilla/Chambers_of_Commerce_Root_-_2008.crt, 
mozilla/Comodo_AAA_Services_root.crt, 
mozilla/COMODO_Certification_Authority.crt, 
mozilla/COMODO_ECC_Certification_Authority.crt, 
mozilla/COMODO_RSA_Certification_Authority.crt, 
mozilla/Cybertrust_Global_Root.crt, mozilla/DigiCert_Assured_ID_Root_CA.crt, 
mozilla/DigiCert_Assured_ID_Root_G2.crt, 
mozilla/DigiCert_Assured_ID_Root_G3.crt, mozilla/DigiCert_Global_Root_CA.crt, 
mozilla/DigiCert_Global_Root_G2.crt, mozilla/DigiCert_Global_Root_G3.crt, 
mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, 
mozilla/DigiCert_Trusted_Root_G4.crt, mozilla/DST_Root_CA_X3.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_2009.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_EV_2009.crt, mozilla/EC-ACC.crt, 
mozilla/emSign_ECC_Root_CA_-_C3.crt, mozilla/emSign_ECC_Root_CA_-_G3.crt, 
mozilla/emSign_Root_CA_-_C1.crt, mozilla/emSign_Root_CA_-_G1.crt, 
mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt, 
mozilla/Entrust_Root_Certification_Authority.crt, 
mozilla/Entrust_Root_Certification_Authority_-_EC1.crt, 
mozilla/Entrust_Root_Certification_Authority_-_G2.crt, 
mozilla/Entrust_Root_Certification_Authority_-_G4.crt, 
mozilla/ePKI_Root_Certification_Authority.crt, 
mozilla/e-Szigno_Root_CA_2017.crt, mozilla/E-Tugra_Certification_Authority.crt, 
mozilla/GDCA_TrustAUTH_R5_ROOT.crt, 
mozilla/GeoTrust_Primary_Certification_Authority_-_G2.crt, 
mozilla/Global_Chambersign_Root_-_2008.crt, 
mozilla/GlobalSign_ECC_Root_CA_-_R4.crt, 
mozilla/GlobalSign_ECC_Root_CA_-_R5.crt, mozilla/GlobalSign_Root_CA.crt, 
mozilla/GlobalSign_Root_CA_-_R2.crt, mozilla/GlobalSign_Root_CA_-_R3.crt, 
mozilla/GlobalSign_Root_CA_-_R6.crt, mozilla/Go_Daddy_Class_2_CA.crt, 
mozilla/Go_Daddy_Root_Certificate_Authority_-_G2.crt, mozilla/GTS_Root_R1.crt, 
mozilla/GTS_Root_R2.crt, mozilla/GTS_Root_R3.crt, mozilla/GTS_Root_R4.crt, 
mozilla/Hellenic_Academic_and_Research_Institutions_ECC_RootCA_2015.crt, 
mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt, 
mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2015.crt, 
mozilla/Hongkong_Post_Root_CA_1.crt, mozilla/Hongkong_Post_Root_CA_3.crt, 
mozilla/IdenTrust_Commercial_Root_CA_1.crt, 
mozilla/IdenTrust_Public_Sector_Root_CA_1.crt, mozilla/ISRG_Root_X1.crt, 
mozilla/Izenpe.com.crt, mozilla/Microsec_e-Szigno_Root_CA_2009.crt, 
mozilla/Microsoft_ECC_Root_Certificate_Authority_2017.crt, 
mozilla/Microsoft_RSA_Root_Certificate_Authority_2017.crt, 
mozilla/NAVER_Global_Root_Certification_Authority.crt, 
mozilla/NetLock_Arany_=Class_Gold=_Főtanúsítvány.crt, 
mozilla/Network_Solutions_Certificate_Authority.crt, 
mozilla/OISTE_WISeKey_Global_Root_GB_CA.crt, 
mozilla/OISTE_WISeKey_Global_Root_GC_CA.crt, mozilla/QuoVadis_Root_CA_1_G3.crt, 
mozilla/QuoVadis_Root_CA_2.crt, mozilla/QuoVadis_Root_CA_2_G3.crt, 
mozilla/QuoVadis_Root_CA_3.crt, mozilla/QuoVadis_Root_CA_3_G3.crt, 
mozilla/QuoVadis_Root_CA.crt, mozilla/Secure_Global_CA.crt, 
mozilla/SecureSign_RootCA11.crt, 

Bug#1003753: Acknowledgement (chromium: chromium --temp-profile window displays only as a white box)

[Andres Salomon]

On 1/23/22 14:52, Salvatore Bonaccorso wrote:

Source: chromium
Source-Version: 97.0.4692.99-1~deb11u1

On Sun, Jan 23, 2022 at 01:30:04PM -0600, Karl O. Pinc wrote:

Hello,

Upgrading to the latest chromium seems to have fixed the
problem of the window being displayed as a white box
without any controls.


Upgrade: chromium-sandbox:amd64 (97.0.4692.71-0.1~deb11u1, 
97.0.4692.99-1~deb11u2), chromium:amd64 (97.0.4692.71-0.1~deb11u1, 
97.0.4692.99-1~deb11u2), chromium-common:amd64 (97.0.4692.71-0.1~deb11u1, 
97.0.4692.99-1~deb11u2)


Note that I am still getting plenty of error messages
on stdout/stderr when invoking chromium --temp-profile
from the command line.  See below.

You may want to close this bug.  I would be happy to file
a separate bug report(s) for any of the error messages
below, however you would advise.

Doing so now, but leaving it to the maintainers if they want separate
bugs on it for the remaining issues, okay? Andres?



Thanks!

Karl, the remaining error messages are either benign (like the "stack 
smashing detected" ones, which are due to the older version of clang in 
bullseye and don't show up in newer versions of clang), or seem to be 
related to lack of hardware support from libgl1-mesa-dri. The next steps 
to dealing with the mesa issues are trying out a backport of 
libgl1-mesa-dri to see if it works better for you, and also going 
through mesa's bug list to see if your specific radeonsi issues have 
already been reported and/or solved. Your specific gpu hardware would be 
listed in the output of chrome://gpu, if that's helpful for reporting a 
mesa bug or following up on an existing one.



For the record, I don't know why the new release fixed your issue with 
the --temp-profile window. Seems like an upstream chromium bug that got 
fixed, as the debian side of things (for X11 at least) remained the 
same. ¯\_(ツ)_/¯


At some point I hope to start including swiftshader with chromium, which 
would provide an admittedly slow but functional software fallback for 
folks whose GL hardware implementations are lacking or broken.

Bug#984063: [Debian-med-packaging] Bug#984063: Closing bug (Was: Bug#984063: itk libtiff test issues (Was: Bug#984063))

[Steven Robbins]

On Saturday, January 22, 2022 12:15:25 P.M. CST Étienne Mollier wrote:
> Hi Andreas,
> 
> Andreas Tille, on 2022-01-16:
> > I think the roadmap that ITK4 will be deleted as soon as possible
> > is clear.  However, if it might serve as an intermediate means
> > to support some remaining dependencies temporarily I think it
> > is OK to do some tricks that would not be acceptable as long
> > term means.
> 
> I have been working on a rewrap of insighttoolkit4 to include
> the embedded tiff library, and with all the previous patching to
> address the initial issue described in this bug, the build went
> through.  The package should be in shape for upload tomorrow.

Neat!   I'm  sure that those using ITK 4 will appreciate your work.

As far as the existing Salsa repository is concerned: I would encourage you to 
consider using a v4 branch to maintain it.  If you prefer to do something 
else, that is also fine with me.  Just want to be clear that I haven't any 
objection to keeping v4 and v5 in a single repository.

-Steve


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

Bug#1003653: Revision of removal of rename.ul from package util-linux

[Christoph Berg]

Re: Don Armstrong
> > I understand the perl group maintainer scripts switched to using the
> > /usr/bin/file-rename name. We could investigate rdeps of rename and
> > see what they use, and/or change them.
> 
> This problem goes beyond reverse dependencies; there are also a
> not-insignificant number of user scripts which on Debian expect
> /usr/bin/rename to be the perl version (and probably a similar number on
> other distributions which expect the opposite).
> 
> Not impossible to change, of course, but an ideal transition would avoid
> breaking currently working scripts and installs.

We were discussing the bug in last week's tech-ctte meeting, and the
gist of the discussion was that, in a ideal world, Debian would be
shipping the util-linux version as /usr/bin/rename to match what other
distributions are shipping, but that since we have been shipping the
Perl rename for the past 20 years, a proper transition would be very
hard. Especially in the light that this is an end-user tool and not
something we can control by a MBF and a lot of patches.

Unfortunately the current defaults seem to be that we have neither,
none of my systems has any "rename" command. OTOH that might indicate
there's a head-start on a transition introducing u-l's rename as
/usr/bin/rename.

Chris, would u-l be willing to reintroduce rename, or do you rather
want to reduce the number of commands?

Maybe if alternatives are not the correct tool, moving the u-l rename
to a separate package, and conflicting with the perl rename is better?
(Still ugly, but the situation isn't ideal.)

Christoph

Bug#1004264: music: Please package new upstream version (1.1.17)

[Boyuan Yang]

Source: music
Version: 1.1.16-1.1
Tags: sid bookworm

Dear Debian music package maintainer,

A new version of package music is available at
https://github.com/INCF/MUSIC/releases/tag/1.1.17 . Please consider packaging
it in Debian.

Thanks,
Boyuan Yang


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

Bug#999575: elan: error: failed to select a version for the requirement `itertools = "^0.9.0"`

[Christopher Hoskin]

Source: elan
Version: 1.0.6-1
Followup-For: Bug #999575

Dear Peter,

Thank you very much for the debdiff patch. I'm embarrassed to say, I'm not sure 
what to do with a debdiff patch. Can I import it into the salsa repo in some 
way?

Thank you for your help,

Christopher

Bug#1004263: Gwyddion's application/x-stmprg-spm mime type pattern is too broad (breaks fwupd)

[Oliver Freyermuth]

Package: gwyddion
Version: 2.57-1
Tags: fixed-upstream

Installing Gwyddion breaks other programs, such as fwupd on Debian.

For example, the file:

 /usr/share/fwupd/quirks.d/tpm.quirk

shipped by fwupd is labelled as application/x-stmprg-spm type, and starting the 
fwupd daemon causes device detection to break with:

 failed to build silo: failed to compile 
/usr/share/fwupd/quirks.d/tpm.quirk:ctime=1640972058.748411: cannot process 
content type application/x-stmprg-spm

There's also a Lanchpad bug created by affected Ubuntu users:
 https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1899036

I have sent a patch to upstream:
 
https://sourceforge.net/p/gwyddion/mailman/gwyddion-devel/thread/9e1f6694-c39b-6131-796b-667f6e25f7e9%40googlemail.com/#msg37595049
which was merged via:
 https://sourceforge.net/p/gwyddion/code/24576/

After applying this patch to the sources, and recreating autoconf, the issue is 
resolved. Alternatively, the following patch can be applied to the generated 
gwyddion.xml:

--- a/data/gwyddion.xml
+++ b/data/gwyddion.xml
@@ -1071,8 +1071,6 @@
   
 
   
-  
-  
 
 
 



Cheers,
Oliver

Bug#952596:

[Jarl Gullberg]

Is there a chance this fix would be backported to Buster?

Bug#1004214: Info received (Bug#1004214: Acknowledgement (kodi: Segfaults on menu selection))

[Vasyl Gello]

Hi!

As I expected it is a Python sub-interpreter issue. To discover the offending 
add-on, run Kodi under GDB directly:

gdb /usr/lib/x86_64-linux-gnu/kodi/kodi.bin

reproduce the crash and issue "py-bt-full" command, then save and attach the 
log.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1003796: ITP: ifupdown-ng -- network device manager compatible with ifupdown

[dxld]

Hi Thomas,

I've been working on the ifupdown-ng packaging today. I had a look at your
existing git repo and did incorporate most of the debian/ files from that
but decided to start the repo from scratch. The main reason being that I
don't feel the gbp-import-ref workflow is quite ready yet so while I would
prefer basing Debian packaging on the upstream git repo as you've done it
just causes more friction right now in my experience.

Could you add me to the debian/ifupdown-ng repo so I can push my work
there? In the meantime the repo is here:

https://salsa.debian.org/dxld-guest/ifupdown-ng/

One significant thing I noticed is that you seem to have Depends
specifically for kfreebsd and hurd which I haven't dealt with yet. Did you
test this stuff on those systems?

Hurd still seems to be available as d-i/bootable images at[1] but I'm
having trouble finding any way to even install a Debian/kFreeBSD system for
bullseye. I suspect I should at least lightly test this stuff there if
we're going to have (seemingly) explicit support for those systems.

[1]: https://cdimage.debian.org/cdimage/ports/

Ordinarily I would think we could just go and get access porterbox for
these arches but since I need to play with networking stuff for testing the
porterboxes are likely not going to be much help.

--Daniel


signature.asc
Description: PGP signature

Bug#1004176: qbrz not working on Debian 11

[Stefano Rosellini]

Il 23/01/22 15:38, Jelmer Vernooij ha scritto:

On Sat, Jan 22, 2022 at 09:52:04AM +0100, Stefano Rosellini wrote:

Package: qbzr

Do you mean qbrz rather than qbzr?

Yes. Sorry. These names are terrible...

Version: 0.23.2+bzr1640-1

I installed brz 3.1.0-8, bzr 2.7.0+bzr6622+brz and qbzr 0.23.2+bzr1640-1.
Executing "bzr qlog" or "brz qlog" or other command with "q*" I get an unknown 
command.

Example:

$ bzr qlog brz: ERROR: unknown command "qlog". Perhaps you meant "log" $ brz
qlog
brz: ERROR: unknown command "qlog". Perhaps you meant "log" $ I'm using
Debian 11.2, Kernel 5.10.92-1, libc6 2.31-13+deb11u2.

What version of Breezy and Bazaar do you have installed?


What version do you mean? As I wrote above "brz" package is version 
"3.1.0-8" and  "bzr" package is version "2.7.0+bzr6622+brz".

Bug#1003753: Acknowledgement (chromium: chromium --temp-profile window displays only as a white box)

[Karl O. Pinc]

Hello,

Upgrading to the latest chromium seems to have fixed the
problem of the window being displayed as a white box
without any controls.


Upgrade: chromium-sandbox:amd64 (97.0.4692.71-0.1~deb11u1, 
97.0.4692.99-1~deb11u2), chromium:amd64 (97.0.4692.71-0.1~deb11u1, 
97.0.4692.99-1~deb11u2), chromium-common:amd64 (97.0.4692.71-0.1~deb11u1, 
97.0.4692.99-1~deb11u2)


Note that I am still getting plenty of error messages
on stdout/stderr when invoking chromium --temp-profile
from the command line.  See below.

You may want to close this bug.  I would be happy to file
a separate bug report(s) for any of the error messages
below, however you would advise.



$ chromium --temp-profile
Using temporary profile: /tmp/tmp.60BqxExgbm
libGL error: failed to authenticate magic 1
libGL error: failed to load driver: radeonsi
[32220:32307:0123/132117.954017:ERROR:chrome_browser_main_extra_parts_metrics.cc(227)]
 START: ReportBluetoothAvailability(). If you don't see the END: message, this 
is crbug.com/1216328.
[32220:32307:0123/132117.954095:ERROR:chrome_browser_main_extra_parts_metrics.cc(230)]
 END: ReportBluetoothAvailability()
[32251:32251:0123/132119.862602:ERROR:angle_platform_impl.cc(44)] 
Display.cpp:894 (initialize): ANGLE Display::initialize error 12289: Could not 
create a backing OpenGL context.
[32251:32251:0123/132119.862797:ERROR:gl_surface_egl.cc(783)] EGL Driver 
message (Critical) eglInitialize: Could not create a backing OpenGL context.
[32251:32251:0123/132119.862878:ERROR:gl_surface_egl.cc(1391)] eglInitialize 
OpenGL failed with error EGL_NOT_INITIALIZED, trying next display type
[32251:32251:0123/132119.865704:ERROR:angle_platform_impl.cc(44)] 
Display.cpp:894 (initialize): ANGLE Display::initialize error 12289: Could not 
create a backing OpenGL context.
[32251:32251:0123/132119.865808:ERROR:gl_surface_egl.cc(783)] EGL Driver 
message (Critical) eglInitialize: Could not create a backing OpenGL context.
[32251:32251:0123/132119.866036:ERROR:gl_surface_egl.cc(1391)] eglInitialize 
OpenGLES failed with error EGL_NOT_INITIALIZED
[32251:32251:0123/132119.866206:ERROR:gl_ozone_egl.cc(20)] 
GLSurfaceEGL::InitializeOneOff failed.
[32251:32251:0123/132119.870342:ERROR:viz_main_impl.cc(161)] Exiting GPU 
process due to errors during initialization
[32343:32343:0123/132119.961357:ERROR:gpu_init.cc(457)] Passthrough is not 
supported, GL is disabled, ANGLE is 
Fontconfig error: Cannot load default config file
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated
*** stack smashing detected ***: terminated



Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#1004262: mariadb-server: Instead of being upgraded, mariadb-server gets removed after apt update

[Rutger van Sleen]

Package: mariadb-server
Version: 1:10.5.12-1
Severity: important

Dear Maintainer,

mariadb-server-10.6 has hit testing, after `apt update` I found that
`apt full-upgrade` want to remove mariadb-server package, along with the
10.5 packages

I have mariadb-server manually installed, to keep my system up to date
when a new version of mariadb-server-?? hits the repository. I expected
that mariadb-server-10.6 would be installed, but that didn't happen.

What puzzles me, is that I don't see any reason why the metapackage 
mariadb-server gets removed, there is clearly a new candidate for it.

-- Policy

$ apt-cache policy mariadb-server
mariadb-server:
  Installed: 1:10.5.12-1
  Candidate: 1:10.6.5-2
  Version table:
 1:10.6.5-2 500
500 http://ftp.nl.debian.org/debian testing/main amd64 Packages
100 http://ftp.nl.debian.org/debian unstable/main amd64 Packages
 *** 1:10.5.12-1 100
100 http://ftp.nl.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status


-- installed mariadb/mysql packages:

$ aptitude search -F%p '~imariadb|~imysql' 
libdbd-mysql-perl
libmariadb3
mariadb-client-10.5
mariadb-client-core-10.5
mariadb-common
mariadb-server
mariadb-server-10.5
mariadb-server-core-10.5
mysql-common
php-mysql
php7.4-mysql
zabbix-server-mysql


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

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

Versions of packages mariadb-server depends on:
ii  mariadb-server-10.5  1:10.5.12-1

mariadb-server recommends no packages.

mariadb-server suggests no packages.

-- no debconf information

Bug#994888: chromium: chrome://extensions/ broken

[Stefano Callegari]

Il Sun, Jan 23, 2022 at 07:41:35PM +0100, To Andres Salomon scrisse:

I'm sorry,

I see now there is an update...

Version 97.0.4692.99 (Official Build) built on Debian bookworm/sid, running on 
Debian bookworm/sid (64-bit)

However asks update.



> Il Fri, Jan 21, 2022 at 06:19:14PM -0500, Andres Salomon scrisse:
> > On Wed, 12 Jan 2022 16:51:02 +0100 Stefano Callegari wrote:
> > > Package: chromium
> > > Followup-For: Bug #994888
> > >
> > > Dear Maintainer,
> > >
> > > the last version seems back to work all th chrome:// listed above.
> > >
> > > But Amazon Music still to ask me to update...
> > >
> > 
> > 
> > Thank you for the update. I'm going to close this bug since
> > chrome://extensions works again, but just for the record - does Amazon Music
> > ask you to upgrade with either chromium 97.0.4692.99-1 (currently in sid) or
> > chromium 99.0.4818.0-0.1 (currently in experimental)?
> 
> Version 97.0.4692.71 (Official Build) built on Debian bookworm/sid, running 
> on Debian bookworm/sid (64-bit)
> 
> I can open https://music.amazon.it/.
> 
> I can search or manage my profile.
> 
> I can play a song but after few seconds a warn ask me to update Chrome (the
> song play on background) and nothing else I can do.
> 
> I've also downloaded 
> 
> chromium_99.0.4818.0-0.1_amd64.deb
> chromium-common_99.0.4818.0-0.1_amd64.deb
> 
> and installed with dpkg.
> 
> But again:
> - Amazon asks for update (before and after clean cookies)
> - chrome://extensions/ chrome://history/ chrome://downloads/
>   chrome://bookmarks/ are broken
> - all chrome://settings are broken
> 
> Thanks

Thanks
-- 
Stefano Callegari

Bug#1004255: linux-image-5.14.0-1-sparc64-smp: Debian kernels > 5.14.3-1~exp1 fail to boot on SPARC T4-1 with Fast Data Access MMU Miss

[Rich]

At least on my old Netra T1, SILO has never believed in booting vmlinuz,
only vmlinux, and faults similarly if you try.

So if it just recently started faulting that way for you, perhaps any glue
that knew to unpack vmlinuz into vmlinux isn't working?

- Rich

On Sun, Jan 23, 2022 at 1:30 PM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hello Tom!
>
> On 1/23/22 17:39, Tom Turelinckx wrote:
> > Boot device: disk0  File and args:
> > SILO Version 1.4.14
> > boot:
> > Allocated 64 Megs of memory at 0x4000 for kernel
> > Uncompressing image...
> > Loaded kernel version 5.14.6
> > Loading initial ramdisk (25723814 bytes at 0x2480 phys, 0x40C0
> virt)...
> > ERROR: Last Trap: Fast Data Access MMU Miss
>
> This looks more like an issue with your bootloader. I haven't used SILO
> for a
> long time, so I don't have a track what currently works and what not.
>
> Can you try booting the current ISO snapshot image? [1]
>
> Adrian
>
> > [1]
> https://cdimage.debian.org/cdimage/ports/snapshots/2021-10-20/debian-11.0.0-sparc64-NETINST-1.iso
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
>

Bug#994888: chromium: chrome://extensions/ broken

[Stefano Callegari]

Il Fri, Jan 21, 2022 at 06:19:14PM -0500, Andres Salomon scrisse:
> On Wed, 12 Jan 2022 16:51:02 +0100 Stefano Callegari wrote:
> > Package: chromium
> > Followup-For: Bug #994888
> >
> > Dear Maintainer,
> >
> > the last version seems back to work all th chrome:// listed above.
> >
> > But Amazon Music still to ask me to update...
> >
> 
> 
> Thank you for the update. I'm going to close this bug since
> chrome://extensions works again, but just for the record - does Amazon Music
> ask you to upgrade with either chromium 97.0.4692.99-1 (currently in sid) or
> chromium 99.0.4818.0-0.1 (currently in experimental)?

Version 97.0.4692.71 (Official Build) built on Debian bookworm/sid, running on 
Debian bookworm/sid (64-bit)

I can open https://music.amazon.it/.

I can search or manage my profile.

I can play a song but after few seconds a warn ask me to update Chrome (the
song play on background) and nothing else I can do.

I've also downloaded 

chromium_99.0.4818.0-0.1_amd64.deb
chromium-common_99.0.4818.0-0.1_amd64.deb

and installed with dpkg.

But again:
- Amazon asks for update (before and after clean cookies)
- chrome://extensions/ chrome://history/ chrome://downloads/
  chrome://bookmarks/ are broken
- all chrome://settings are broken

Thanks
-- 
Stefano Callegari

Bug#904572: move x11-utils to Suggests

[Thomas Dickey]

On Sun, Jan 23, 2022 at 05:55:37PM +, Ivan Shmakov wrote:
> > Harald Dunkel  writes:
> 
>  > Package: xterm
>  > Version: 333-1
> 
>  > xterm recommends x11-utils.  Assuming the default configuration, this
>  > brings in a huge list of packages unrelated to xterm's main purpose:
>  > Running a shell or another cli program.  Sample:

xterm actually should recommend luit, which is not yet a separate package
see #1003130 and #1003770:

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

once that's completed, the xterm package should be changed to recommend luit
(about 130kb for that package, no dependencies except that it might suggest
the xfonts-encodings package).
 
>   There’re several ways to resolve the issue, one of which is
>   indeed to move luit into a package of its own, though I can’t
>   say I’m particularly fond of practices that lead to the
>   expansion of the Packages files, as well as /var/lib/dpkg/.

that's unclear (there's only ~66 thousand packages so far)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1004255: linux-image-5.14.0-1-sparc64-smp: Debian kernels > 5.14.3-1~exp1 fail to boot on SPARC T4-1 with Fast Data Access MMU Miss

[John Paul Adrian Glaubitz]

Hello Tom!

On 1/23/22 17:39, Tom Turelinckx wrote:
> Boot device: disk0  File and args: 
> SILO Version 1.4.14
> boot: 
> Allocated 64 Megs of memory at 0x4000 for kernel
> Uncompressing image...
> Loaded kernel version 5.14.6
> Loading initial ramdisk (25723814 bytes at 0x2480 phys, 0x40C0 
> virt)...
> ERROR: Last Trap: Fast Data Access MMU Miss

This looks more like an issue with your bootloader. I haven't used SILO for a
long time, so I don't have a track what currently works and what not.

Can you try booting the current ISO snapshot image? [1]

Adrian

> [1] 
> https://cdimage.debian.org/cdimage/ports/snapshots/2021-10-20/debian-11.0.0-sparc64-NETINST-1.iso

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1004261: buster-pu: package opensc/0.19.0-1+deb10u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Debian OpenSC Maintainers 
, t...@security.debian.org

  * CVE-2019-15945: Out-of-bounds access of an ASN.1 Bitstring.
(Closes: #939668)
  * CVE-2019-15946: Out-of-bounds access of an ASN.1 Octet string.
(Closes: #939669)
  * CVE-2019-19479: Incorrect read operation in the Setec driver.
(Closes: #947383)
  * CVE-2019-20792: Double free in the Coolkey driver.
  * CVE-2020-26570: Heap-based buffer overflow in the Oberthur driver.
(Closes: #972037)
  * CVE-2020-26571: Stack-based buffer overflow in the GPK driver.
(Closes: #972036)
  * CVE-2020-26572: Stack-based buffer overflow in the TCOS driver.
(Closes: #972035)
diff -Nru opensc-0.19.0/debian/changelog opensc-0.19.0/debian/changelog
--- opensc-0.19.0/debian/changelog  2018-09-30 23:26:03.0 +0300
+++ opensc-0.19.0/debian/changelog  2022-01-23 19:32:38.0 +0200
@@ -1,3 +1,22 @@
+opensc (0.19.0-1+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2019-15945: Out-of-bounds access of an ASN.1 Bitstring.
+(Closes: #939668)
+  * CVE-2019-15946: Out-of-bounds access of an ASN.1 Octet string.
+(Closes: #939669)
+  * CVE-2019-19479: Incorrect read operation in the Setec driver.
+(Closes: #947383)
+  * CVE-2019-20792: Double free in the Coolkey driver.
+  * CVE-2020-26570: Heap-based buffer overflow in the Oberthur driver.
+(Closes: #972037)
+  * CVE-2020-26571: Stack-based buffer overflow in the GPK driver.
+(Closes: #972036)
+  * CVE-2020-26572: Stack-based buffer overflow in the TCOS driver.
+(Closes: #972035)
+
+ -- Adrian Bunk   Sun, 23 Jan 2022 19:32:38 +0200
+
 opensc (0.19.0-1) unstable; urgency=medium
 
   * New upstream release (Closes: 908363, 909444)
diff -Nru 
opensc-0.19.0/debian/patches/0001-fixed-out-of-bounds-access-of-ASN.1-Bitstring.patch
 
opensc-0.19.0/debian/patches/0001-fixed-out-of-bounds-access-of-ASN.1-Bitstring.patch
--- 
opensc-0.19.0/debian/patches/0001-fixed-out-of-bounds-access-of-ASN.1-Bitstring.patch
   1970-01-01 02:00:00.0 +0200
+++ 
opensc-0.19.0/debian/patches/0001-fixed-out-of-bounds-access-of-ASN.1-Bitstring.patch
   2022-01-23 19:32:38.0 +0200
@@ -0,0 +1,42 @@
+From 0509b2f61ca948312a15d18712a130f7bffd512e Mon Sep 17 00:00:00 2001
+From: Frank Morgner 
+Date: Tue, 27 Aug 2019 15:17:17 +0200
+Subject: fixed out of bounds access of ASN.1 Bitstring
+
+Credit to OSS-Fuzz
+---
+ src/libopensc/asn1.c | 12 
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/src/libopensc/asn1.c b/src/libopensc/asn1.c
+index 3262ed80..fd972238 100644
+--- a/src/libopensc/asn1.c
 b/src/libopensc/asn1.c
+@@ -570,16 +570,20 @@ static int decode_bit_string(const u8 * inbuf, size_t 
inlen, void *outbuf,
+ {
+   const u8 *in = inbuf;
+   u8 *out = (u8 *) outbuf;
+-  int zero_bits = *in & 0x07;
+-  size_t octets_left = inlen - 1;
+   int i, count = 0;
++  int zero_bits;
++  size_t octets_left;
+ 
+-  memset(outbuf, 0, outlen);
+-  in++;
+   if (outlen < octets_left)
+   return SC_ERROR_BUFFER_TOO_SMALL;
+   if (inlen < 1)
+   return SC_ERROR_INVALID_ASN1_OBJECT;
++
++  zero_bits = *in & 0x07;
++  octets_left = inlen - 1;
++  in++;
++  memset(outbuf, 0, outlen);
++
+   while (octets_left) {
+   /* 1st octet of input:  ABCDEFGH, where A is the MSB */
+   /* 1st octet of output: HGFEDCBA, where A is the LSB */
+-- 
+2.20.1
+
diff -Nru opensc-0.19.0/debian/patches/0002-fixed-compiler-warning.patch 
opensc-0.19.0/debian/patches/0002-fixed-compiler-warning.patch
--- opensc-0.19.0/debian/patches/0002-fixed-compiler-warning.patch  
1970-01-01 02:00:00.0 +0200
+++ opensc-0.19.0/debian/patches/0002-fixed-compiler-warning.patch  
2022-01-23 19:32:38.0 +0200
@@ -0,0 +1,36 @@
+From 28869a7bd4fd928b498638fff27b76b56e58f4d6 Mon Sep 17 00:00:00 2001
+From: Frank Morgner 
+Date: Tue, 27 Aug 2019 15:27:15 +0200
+Subject: fixed compiler warning
+
+---
+ src/libopensc/asn1.c | 9 -
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+diff --git a/src/libopensc/asn1.c b/src/libopensc/asn1.c
+index fd972238..10572292 100644
+--- a/src/libopensc/asn1.c
 b/src/libopensc/asn1.c
+@@ -574,15 +574,14 @@ static int decode_bit_string(const u8 * inbuf, size_t 
inlen, void *outbuf,
+   int zero_bits;
+   size_t octets_left;
+ 
+-  if (outlen < octets_left)
+-  return SC_ERROR_BUFFER_TOO_SMALL;
+   if (inlen < 1)
+   return SC_ERROR_INVALID_ASN1_OBJECT;
+-
++  memset(outbuf, 0, outlen);
+   zero_bits = *in & 0x07;
+-  octets_left = inlen - 1;
+   in++;
+-  memset(outbuf, 0, outlen);
++  octets_left = inlen - 1;
++  if (outlen < octets_left)
++  return SC_ERROR_BUFFER_TOO_SMALL;
+ 
+   while 

Bug#904572: move x11-utils to Suggests

[Ivan Shmakov]

> On 2018-07-25 10:27:15 +0200, Harald Dunkel wrote:

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.]

> Harald Dunkel  writes:

 > Package: xterm
 > Version: 333-1

 > xterm recommends x11-utils.  Assuming the default configuration, this
 > brings in a huge list of packages unrelated to xterm's main purpose:
 > Running a shell or another cli program.  Sample:

[…]

 > The following additional packages will be installed:
 >libdrm-amdgpu1 libdrm-intel1 libdrm-nouveau2 libdrm-radeon1
 >libfontenc1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa
 >libllvm3.9 libpciaccess0 libtxc-dxtn-s2tc libxcb-glx0
 >libxcb-shape0 libxtst6 libxv1 libxxf86dga1 libxxf86vm1 x11-utils
 >xbitmaps

[…]

 > If I manually omit x11-utils, then installing xterm uses just about
 > 2 MByte.

Note that it’s also possible to configure apt_preferences(5)
to avoid installation of unwanted packages (regardless of them
being recommended.)  E. g. (though in this case it’s likely
libgl1-mesa-dri that rather should be avoided, see below):

$ cat < /etc/apt/preferences.d/55-no-x11-utils.pref 
Explanation: The x11-utils package is not welcome on this system.
Package:
 x11-utils
Pin: release c=main
Pin-Priority: -42

$ 

[…]

What’s going on here is that x11-utils contains, among others,
the /usr/bin/xdriinfo program, which is linked against libGL.
As such, the binary package automatically gets Depends: libgl1,
which is in turn dependent on libglx0 ← libglx-mesa0 ←
libgl1-mesa-dri, the last of which is itself large enough, and
also brings in a whole world of dependencies, as I’ve noted
in http://bugs.debian.org/960133 .

There’re several ways to resolve the issue, one of which is
indeed to move luit into a package of its own, though I can’t
say I’m particularly fond of practices that lead to the
expansion of the Packages files, as well as /var/lib/dpkg/.

FWIW, I haven’t noticed any ill effects due to the workaround
described in #960133 on Buster, but haven’t yet tested it
on Bullseye.  Given that DRI modules are more often than not
useless without appropriate proprietary GPU software,
downgrading dependency on libgl1-mesa-dri to Recommends:
makes every sense to me.

Perhaps we should try to find and merge all such bugs together
and record ‘affects’ accordingly, to give the issue a tad more
attention and better cooperation / coordination?  Thoughts?

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1004121: nmu: libgsf_1.14.47-1+b1

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2022-01-21 10:33:22 +0100, Laurent Bigonville wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Hello,
> 
> Apparently libgsf-1-dev in the archive is not co-installable due to the
> documentation (see #814502)

Are you sue that this bug is still present? The binaries from the last
binNMU (1.14.47-1+) only differ in /usr/lib/${DEB_HOST_MULTIARCH} which
is to be expected.

Cheers

> 
> I quickly tried to rebuild the package in amd64 and i386 and it seems
> that the documentation in the -dev package is now identical, so
> something has been fixed somewhere else.
> 
> Could you please schedule a binNMU so the package is co-installable?
> 
> Kind regards,
> Laurent Bigonville
> 
> nmu libgsf_1.14.47-1+b1 . ANY . unstable . -m "Rebuild to fix multi-arch 
> co-installation"

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1004260: pybuild-plugin-pyproject: Uninstallable

[David Steele]

Package: pybuild-plugin-pyproject
Version: 5.20220119
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: ste...@debian.org


Dear Maintainer,

The dh-python-pep517 meta package, required for poetry builds, and 
satisfied solely by this package, fails to install.


$ sudo apt-get install dh-python dh-python-pep517
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
dh-python is already the newest version (5.20220119).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 dh-python-pep517 : Depends: dh-python (= 5.20211225) but 5.20220119 is 
to be installed

E: Unable to correct problems, you have held broken packages.

Corroborated by the current debcheck report - 
https://qa.debian.org/debcheck.php?dist=unstable=dh-python


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

Kernel: Linux 5.14.0-2-amd64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8), LANGUAGE not set

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pybuild-plugin-pyproject depends on:
ii  dh-python  5.20220119
ii  python3-build  0.7.0-2
ii  python3-installer  0.4.0+dfsg1-2
ii  python3-tomli  1.2.2-2

pybuild-plugin-pyproject recommends no packages.

pybuild-plugin-pyproject suggests no packages.

-- no debconf information



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004067: closed by Debian FTP Masters (reply to Mathieu Malaterre ) (Bug#1004067: fixed in imath 3.1.3-10)

[Matteo F. Vescovi]

Control: reopen -1

On 2022-01-23 at 16:51 (GMT), Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:imath package:
>
> #1004067: imath: causes openexr to FTBFS

The build still ftbfs.

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#1004259: newboat - upcoming rust-rand update.

[Peter Michael Green]

Package: newsboat
Tags: bookworm, sid

An increasing number of packages in Debian are using rand 0.8
upstream, while it's generally possible to patch them to use
0.7 I think we should prefer patching stuff to use newer versions
over packaging stuff to use older versions where possible. So
I started investigating an upgrade to rand 0.8.

Most of the packages involved are maintained by the rust team
and I will upload them after I upload rand 0.8 to unstable
newsboat however is maintained outside the rust team.

The only changes needed to make the package build were
changing the dependencies (both in the Debian packaging and
in Cargo.toml).

A debdiff is attatched, do you want to handle the upload after
rand is updated in unstable or would you like me to NMU it?

rand 0.8 and sufficient related packages to build newsboat
have been uploaded to experimental if you want to test things
in advance of the update in unstable.

diff -Nru newsboat-2.21/debian/changelog newsboat-2.21/debian/changelog
--- newsboat-2.21/debian/changelog  2020-10-15 13:45:56.0 +
+++ newsboat-2.21/debian/changelog  2022-01-23 14:28:08.0 +
@@ -1,3 +1,10 @@
+newsboat (2.21-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to rand 0.8.
+
+ -- Peter Michael Green   Sun, 23 Jan 2022 14:28:08 +
+
 newsboat (2.21-1) unstable; urgency=medium
 
   * New upstream version 2.21
diff -Nru newsboat-2.21/debian/control newsboat-2.21/debian/control
--- newsboat-2.21/debian/control2020-10-15 13:39:30.0 +
+++ newsboat-2.21/debian/control2022-01-23 14:28:04.0 +
@@ -15,7 +15,7 @@
cargo,
librust-chrono-0.4-dev,
librust-time-0.1-dev,
-   librust-rand-0.7-dev,
+   librust-rand-0.8-dev,
librust-once-cell-1+parking-lot-dev,
librust-regex-1-dev,
librust-url-2-dev,
diff -Nru newsboat-2.21/debian/patches/relax-deps.diff 
newsboat-2.21/debian/patches/relax-deps.diff
--- newsboat-2.21/debian/patches/relax-deps.diff2020-10-15 
13:34:07.0 +
+++ newsboat-2.21/debian/patches/relax-deps.diff2022-01-23 
14:28:08.0 +
@@ -1,15 +1,19 @@
 a/rust/libnewsboat/Cargo.toml
-+++ b/rust/libnewsboat/Cargo.toml
-@@ -10,7 +10,7 @@
+Index: newsboat-2.21/rust/libnewsboat/Cargo.toml
+===
+--- newsboat-2.21.orig/rust/libnewsboat/Cargo.toml
 newsboat-2.21/rust/libnewsboat/Cargo.toml
+@@ -9,8 +9,8 @@ strprintf = { path="../strprintf" }
+ regex-rs = { path="../regex-rs" }
  
  chrono = "0.4"
- rand = "0.7"
+-rand = "0.7"
 -once_cell = "1.4.1"
++rand = "0.8"
 +once_cell = "1.3.1"
  url = "2.0.0"
  percent-encoding = "2.0.0"
  xdg = "2.2.0"
-@@ -19,7 +19,7 @@
+@@ -19,7 +19,7 @@ unicode-width = "0.1.8"
  nom = "5"
  curl-sys = "0.4.5"
  libc = "0.2"
@@ -18,7 +22,7 @@
  natord = "1.0.9"
  lazy_static = "1.4.0"
  
-@@ -35,13 +35,12 @@
+@@ -35,13 +35,12 @@ version = "2.33"
  default-features = false
  
  [dependencies.gettext-sys]
@@ -34,9 +38,11 @@
 -proptest = ">=0.9.6"
 +proptest = "0.9"
  section_testing = "0.0.4"
 a/rust/regex-rs/Cargo.toml
-+++ b/rust/regex-rs/Cargo.toml
-@@ -12,4 +12,4 @@
+Index: newsboat-2.21/rust/regex-rs/Cargo.toml
+===
+--- newsboat-2.21.orig/rust/regex-rs/Cargo.toml
 newsboat-2.21/rust/regex-rs/Cargo.toml
+@@ -12,4 +12,4 @@ strprintf = { path="../strprintf" }
  
  bitflags = "1.2"
  libc = ">=0.2.69"

Bug#1003663: marked as done (golang-github-containers-image: FTBFS: tests fail with 'key has been revoked')

[Reinhard Tartler]

>
>
> Hi Andreas, thank you for your report,
>
> I've tried rebuilding the package on my laptop in a clean sid chroot,
> and for some reason, it works just fine.
>
> Can you please have a look at my build log and help me understand why
> the build is failing for you but not for me?
>
>
I looked a bit more at the code, and it appears to me that the code that is
failing is accessing the kernel "session" keyring using the kernel API here:

https://man7.org/linux/man-pages/man3/keyctl_get_keyring_ID.3.html

It seems to me that on your system, someone or something has revoked the
keys using "keyctl revoke" or some equivalent system call. As said, this
does not appear to be happening on my system, and it also doesn't appear to
be happening on the debian buildd machines.

Have a great weekend,
-rt


-- 
regards,
Reinhard

Bug#1004258: modem-manager-gui: segfaults on launch

[Matteo F. Vescovi]

Package: modem-manager-gui
Version: 0.0.20-2+b1
Severity: important

Dear Maintainer,

since a few days m-m-g doesn't start anymore and when launched on a
terminal it segfaults with the following output:

= = = = = >8 = = = = =
$ modem-manager-gui
Connection manager: Network Manager >= 0.9.0
Modem manager: Modem Manager >= 0.7.0

(modem-manager-gui:13971): GLib-CRITICAL **: 18:19:45.790: 
g_variant_lookup_value: assertion 'g_variant_is_of_type (dictionary, 
G_VARIANT_TYPE ("a{s*}")) || g_variant_is_of_type (dictionary, G_VARIANT_TYPE 
("a{o*}"))' failed

(modem-manager-gui:13971): GLib-CRITICAL **: 18:19:45.790: 
g_variant_lookup_value: assertion 'g_variant_is_of_type (dictionary, 
G_VARIANT_TYPE ("a{s*}")) || g_variant_is_of_type (dictionary, G_VARIANT_TYPE 
("a{o*}"))' failed

(modem-manager-gui:13971): GLib-CRITICAL **: 18:19:45.790: 
g_variant_lookup_value: assertion 'g_variant_is_of_type (dictionary, 
G_VARIANT_TYPE ("a{s*}")) || g_variant_is_of_type (dictionary, G_VARIANT_TYPE 
("a{o*}"))' failed

(modem-manager-gui:13971): GLib-CRITICAL **: 18:19:45.790: 
g_variant_lookup_value: assertion 'g_variant_is_of_type (dictionary, 
G_VARIANT_TYPE ("a{s*}")) || g_variant_is_of_type (dictionary, G_VARIANT_TYPE 
("a{o*}"))' failed

(modem-manager-gui:13971): GLib-CRITICAL **: 18:19:45.790: g_variant_unref: 
assertion 'value != NULL' failed

** (modem-manager-gui:13971): WARNING **: 18:19:45.799: Network Manager >= 
0.9.0: No such file or directory
Segmentation fault at address: 0x20
Stack trace:
1. /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_bit_lock+0x50) [0x7f0662106310]
2. /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_bit_lock+0x50) [0x7f0662106310]
3. /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_variant_n_children+0x19) 
[0x7f066217ae29]
4. 
/usr/lib/x86_64-linux-gnu/modem-manager-gui/modules/libmodcm_nm09.so(mmgui_module_connection_enum+0x490)
 [0x7f065d77fa50]
5. modem-manager-gui(mmguicore_connections_enum+0x69) [0x5610b6d889a9]
6. modem-manager-gui(+0x49664) [0x5610b6da8664]
7. modem-manager-gui(mmguicore_devices_open+0x1b8) [0x5610b6d88f98]
8. modem-manager-gui(+0x3b0e6) [0x5610b6d9a0e6]
9. modem-manager-gui(+0x4920e) [0x5610b6da820e]
= = = = = >8 = = = = =

I'm really thinking at the possibility that the culprit could be N-M
since it's actually installed but not detected by m-m-g.
Probably, newer releases in N-M changed something that m-m-g doesn't
like that much ;)

In case, feel free to ping me for more info.

Cheers.

mfv


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

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

Versions of packages modem-manager-gui depends on:
ii  libayatana-appindicator3-1  0.5.90-5
ii  libc6   2.33-3
ii  libcairo2   1.16.0-5
ii  libgdbm61.22-1
ii  libgdk-pixbuf-2.0-0 2.42.6+dfsg-2
ii  libglib2.0-02.70.2-1
ii  libgtk-3-0  3.24.31-1
ii  libgtkspell3-3-03.0.10-1
ii  mobile-broadband-provider-info  20210805-1
ii  modemmanager1.18.4-1
ii  network-manager 1.34.0-2
ii  policykit-1 0.105-31
ii  ppp 2.4.9-1+1

Versions of packages modem-manager-gui recommends:
ii  modem-manager-gui-help  0.0.20-2
ii  yelp41.2-1

Versions of packages modem-manager-gui suggests:
ii  evolution-data-server  3.42.3-1
pn  libindicate5 | libmessaging-menu0  
ii  libnotify4 0.7.9-3

-- no debconf information


signature.asc
Description: PGP signature

Bug#1003089: man-db has become prohibitively slow

[Steinar H. Gunderson]

On Sat, Jan 22, 2022 at 12:41:56AM +, Colin Watson wrote:
>> Technically, UTF-8 validation can be done at a few gigabytes per second
>> per core:
>> 
>>   
>> https://lemire.me/blog/2018/05/16/validating-utf-8-strings-using-as-little-as-0-7-cycles-per-byte/
>> 
>> but that is probably overkill. :-)
> Quite :-)

It struck me that it can probably be folded for free into the lexer.
If you add symbols for all invalid UTF-8 sequences, I believe it should just
go into the state machine. But I'm fine with those 20%; the perfect need not
be the enemy of the good here.

In general, I don't think I need to look at it again now, unless there are
any special questions. Thanks for taking care of this! Looking forward to
bookworm being faster (and of course sid before that), and then I'll happily
live with this on bullseye, knowing that it's transient.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1004206: libconfig-model-dpkg-perl: update-my-copyright-year duplicates single year

[gregor herrmann]

On Sun, 23 Jan 2022 17:29:04 +0100, Dominique Dumont wrote:

> On Saturday, 22 January 2022 19:30:05 CET you wrote:
> > -Copyright: 2022, gregor herrmann 
> > +Copyright: 2022, 2022, gregor herrmann 
> 
> I can't believe I missed this simple test case ...

No worries, and thanks for this nice script!


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Steppenwolf: Draft Resister


signature.asc
Description: Digital Signature

Bug#1004056: buster-pu: package libsdl1.2/1.2.15+dfsg2-4+deb10u1

[Adrian Bunk]

On Wed, Jan 19, 2022 at 10:53:23PM +, Thorsten Alteholz wrote:
>...
> +libsdl1.2 (1.2.15+dfsg2-4+deb10u1) buster; urgency=medium
> +
> +  * Non-maintainer upload by the LTS Team.
> +  * CVE-2019-7572: Buffer over-read in IMA_ADPCM_nibble
> +in audio/SDL_wave.c.
> +  * CVE-2019-7573: Heap-based buffer over-read in InitMS_ADPCM
> +in audio/SDL_wave.c.
> +  * CVE-2019-7574: Heap-based buffer over-read in IMA_ADPCM_decode
> +in audio/SDL_wave.c.
> +  * CVE-2019-7575: Heap-based buffer overflow in MS_ADPCM_decode
> +in audio/SDL_wave.c.
> +  * CVE-2019-7576: Heap-based buffer over-read in InitMS_ADPCM
> +in audio/SDL_wave.c.
> +  * CVE-2019-7577: Buffer over-read in SDL_LoadWAV_RW
> +in audio/SDL_wave.c.
> +  * CVE-2019-7578: Heap-based buffer over-read in InitIMA_ADPCM
> +in audio/SDL_wave.c.
> +  * CVE-2019-7635: Heap-based buffer over-read in Blit1to4
> +in video/SDL_blit_1.c.
> +  * CVE-2019-7636: Heap-based buffer over-read in SDL_GetRGB
> +in video/SDL_pixels.c.
> +  * CVE-2019-7637: Heap-based buffer overflow in SDL_FillRect
> +in video/SDL_surface.c.
> +  * CVE-2019-7638: Heap-based buffer over-read in Map1toN
> +in video/SDL_pixels.c.
> +  * CVE-2019-13616: Heap-based buffer over-read in BlitNtoN
> +in video/SDL_blit_N.c.
> +(patches prepared for LTS by Adrian Bunk)
> +
> + -- Thorsten Alteholz   Wed, 19 Jan 2022 23:03:02 +0100
>...

I'd suggest backporting the bullseye/bookworm/sid version instead.

Additional changes are:
   * One patch has a different name.
   [ Debian Janitor ]
   * Trim trailing whitespace.
   * Re-export upstream signing key without extra signatures.
   [ Maximilian Engelhardt ]
   * SDL_x11events.c: properly handle input focus events (Closes: #980253)

#980253 is a regression due to a change in the X server in buster,
so desirable to include.

Everything else is just harmless noise.

The only open bug in the BTS against a post-buster version is #981204
("drop unused Build-Depends").

diffstat compared to buster:
 changelog  |   26 ++
 control|2 
 patches/CVE-2019-13616.patch   |   22 ++
 patches/CVE-2019-7572_CVE-2019-7574.patch  |  105 ++
 patches/CVE-2019-7573.patch|   66 ++
 patches/CVE-2019-7575_7577.patch   |   78 +++
 patches/CVE-2019-7577-1_2.patch|   32 +++
 patches/CVE-2019-7578.patch|   53 +
 patches/CVE-2019-7635_636_638.patch|   81 
 patches/CVE-2019-7637-2.patch  |   46 
 patches/CVE-2019-7637.patch|  207 +
 patches/properly_handle_focus_events.patch |   44 
 patches/series |   10 +
 upstream/signing-key.asc   |   57 +
 14 files changed, 781 insertions(+), 48 deletions(-)

diffstat compared to your proposed update:
 changelog  |   51 --
 control|2 
 patches/CVE-2019-7637-2.patch  |   46 
 patches/CVE-2019-7637-followup.patch   |   37 -
 patches/properly_handle_focus_events.patch |   44 
 patches/series |5 -
 upstream/signing-key.asc   |   57 +++--
 7 files changed, 126 insertions(+), 116 deletions(-)

Both debdiffs are attached.

cu
Adrian
diff -Nru libsdl1.2-1.2.15+dfsg2/debian/changelog 
libsdl1.2-1.2.15+dfsg2/debian/changelog
--- libsdl1.2-1.2.15+dfsg2/debian/changelog 2022-01-20 00:03:02.0 
+0200
+++ libsdl1.2-1.2.15+dfsg2/debian/changelog 2021-02-18 09:52:57.0 
+0200
@@ -1,33 +1,28 @@
-libsdl1.2 (1.2.15+dfsg2-4+deb10u1) buster; urgency=medium
+libsdl1.2 (1.2.15+dfsg2-6) unstable; urgency=medium
 
-  * Non-maintainer upload by the LTS Team.
-  * CVE-2019-7572: Buffer over-read in IMA_ADPCM_nibble
-in audio/SDL_wave.c.
-  * CVE-2019-7573: Heap-based buffer over-read in InitMS_ADPCM
-in audio/SDL_wave.c.
-  * CVE-2019-7574: Heap-based buffer over-read in IMA_ADPCM_decode
-in audio/SDL_wave.c.
-  * CVE-2019-7575: Heap-based buffer overflow in MS_ADPCM_decode
-in audio/SDL_wave.c.
-  * CVE-2019-7576: Heap-based buffer over-read in InitMS_ADPCM
-in audio/SDL_wave.c.
-  * CVE-2019-7577: Buffer over-read in SDL_LoadWAV_RW
-in audio/SDL_wave.c.
-  * CVE-2019-7578: Heap-based buffer over-read in InitIMA_ADPCM
-in audio/SDL_wave.c.
-  * CVE-2019-7635: Heap-based buffer over-read in Blit1to4
-in video/SDL_blit_1.c.
-  * CVE-2019-7636: Heap-based buffer over-read in SDL_GetRGB
-in video/SDL_pixels.c.
-  * CVE-2019-7637: Heap-based buffer overflow in SDL_FillRect
-in video/SDL_surface.c.
-  * CVE-2019-7638: Heap-based buffer over-read in Map1toN
-in video/SDL_pixels.c.
-  * CVE-2019-13616: Heap-based buffer over-read in BlitNtoN
-in video/SDL_blit_N.c.
-(patches 

Bug#1003837: Acknowledgement (client gets stuck with high CPU load)

[Harald Dunkel]

Apparently this has bee triggered by the upgrade of libsd2-2.0-0. If I downgrade
this package to the version in stable, the bzflag works again.

```
Aptitude 0.8.13: log report
Sun, Jan 23 2022 17:40:07 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 1 packages, and remove 2 packages.
211 kB of disk space will be freed

[REMOVE, NOT USED] libdecor-0-0:amd64 0.1.0-3
[REMOVE, NOT USED] libdecor-0-plugin-1-cairo:amd64 0.1.0-3
[DOWNGRADE] libsdl2-2.0-0:amd64 2.0.20+dfsg-2 -> 2.0.14+dfsg2-3


Log complete.
```

Bug#1004256: messages to dispatch+aide_cont...@tracker.debian.org get multiplied

[Marc Haber]

Package: tracker.debian.org
Severity: important

Hi,

I regularly use pack...@packages.debian.org as Maintainer address for my
packages. Having an implicit mailing list for package maintenance issues
is extremele helpful and I appreciate that features.

Since a few weeks, messages to those addresses get multiplied inside the
tracker, namely ticharich.debian.org, between five and ten times. I see
this, and other members of the teams I am on see it as well.

For example, I received seven copies this morning of the message
, telling me that aide 0.17.4-1
MIGRATED to testing.

The message part common to all copies of the message is:
| Received: from mailly.debian.org 
([2001:41b8:202:deb:6564:a62:52c3:4b72]:32910)
|   from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP 
CA,CN=mailly.debian.org,EMAIL=hostmas...@mailly.debian.org (verified)
|   by ticharich.debian.org with esmtps 
(TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
|   (Exim 4.94.2)
|   (envelope-from )
|   id 1nBUel-002T0p-VE
|   for dispatch+aide_cont...@tracker.debian.org; Sun, 23 Jan 2022 04:39:10 
+
| Received: from picconi.debian.org ([2a02:16a8:dc41:100::132]:44350)
|   from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP 
CA,CN=picconi.debian.org,EMAIL=hostmas...@picconi.debian.org (verified)
|   by mailly.debian.org with esmtps 
(TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
|   (Exim 4.92)
|   (envelope-from )
|   id 1nBUei-00036v-5n
|   for dispatch+aide_cont...@tracker.debian.org; Sun, 23 Jan 2022 04:39:08 
+
| Received: from mailly.debian.org 
([2001:41b8:202:deb:6564:a62:52c3:4b72]:49366)
|   from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP 
CA,CN=mailly.debian.org,EMAIL=hostmas...@mailly.debian.org (verified)
|   by picconi.debian.org with esmtps 
(TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
|   (Exim 4.92)
|   (envelope-from )
|   id 1nBUeh-0001Ct-M3
|   for a...@packages.debian.org; Sun, 23 Jan 2022 04:39:07 +
| Received: from respighi.debian.org ([2a02:16a8:dc41:100::131]:40010)
|   from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP 
CA,CN=respighi.debian.org,EMAIL=hostmas...@respighi.debian.org (verified)
|   by mailly.debian.org with esmtps 
(TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
|   (Exim 4.92)
|   (envelope-from )
|   id 1nBUeg-00035W-7S; Sun, 23 Jan 2022 04:39:06 +
| Received: from release by respighi.debian.org with local (Exim 4.92)
|   (envelope-from )
|   id 1nBUef-fX-Nu; Sun, 23 Jan 2022 04:39:05 +
| From: Debian testing watch 
| Precedence: bulk
| X-Trille: 0.180412.1742
| Subject: aide 0.17.4-1 MIGRATED to testing
| X-Testing-Watch-Package: aide
| X-Testing-Watch-Version: 0.17.4-1
| To: a...@packages.debian.org
| Message-Id: 
| Date: Sun, 23 Jan 2022 04:39:05 +
| Delivered-To: a...@packages.debian.org
| Delivered-To: dispatch+aide_cont...@tracker.debian.org
| X-Loop: dispa...@tracker.debian.org
| X-Distro-Tracker-Keyword: summary
| X-Distro-Tracker-Package: aide
| List-Id: 
| X-Debian: tracker.debian.org
| X-Debian-Package: aide
| X-PTS-Package: aide
| X-PTS-Keyword: summary
| Precedence: list
| List-Unsubscribe: 
| X-Spam-Score: (---) -7.4
| X-Spam-Report: torres.zugschlus.de
|  
|  Content analysis details:   (-7.4 points, 5.0 required)
|  
|   pts  rule name  description
|    -- ---
|  -1.9 BAYES_00   BODY: Bayes spam probability is 0 to 1%
|  [score: 0.]
|   0.0 SPF_HELO_NONE  SPF: HELO does not publish an SPF Record
|   0.0 SPF_NONE   SPF: sender does not publish an SPF Record
|  -5.0 RCVD_IN_DNSWL_HI   RBL: Sender listed at https://www.dnswl.org/,
|  high trust
|  [2a02:16a8:dc41:100:0:0:0:132 listed in]
|  [list.dnswl.org]
|  -0.5 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
|  manager
| Content-Length: 398
| 
| FYI: The status of the aide source package
| in Debian's testing distribution has changed.
| 
|   Previous version: 0.17.3-5
|   Current version:  0.17.4-1
| 
| -- 
| This email is automatically generated once a day.  As the installation of
| new packages into testing happens multiple times a day you will receive
| later changes on the next day.
| See https://release.debian.org/testing-watch/ for more information.

After that, the messages turn around between ticharich and mailly before
they eventuell get delivered. Here two sets of headers from two
incarnations of the message:
| Return-path: 

| Envelope-to: mh+debian-trac...@zugschlus.de
| Delivery-date: Sun, 23 Jan 2022 05:39:20 +0100
| Received: from mailly.debian.org ([2001:41b8:202:deb:6564:a62:52c3:4b72])
|   by torres.zugschlus.de with 

Bug#775490: incomplete RFP

[Gürkan Myczko]

So here's the missing parts:

Homepage: https://github.com/NatronGitHub/Natron
Developer: see CONTRIBUTORS.txt
 2018-2021 The Natron developers
 2013-2018 INRIA and Alexandre Gauthier-Foichat
License: GPL-2-or-later
Description: video compositing software
 Open-source video compositing software. Node-graph based. Similar in 
functionalities

 to Adobe After Effects and Nuke by The Foundry.

Bug#1004255: linux-image-5.14.0-1-sparc64-smp: Debian kernels > 5.14.3-1~exp1 fail to boot on SPARC T4-1 with Fast Data Access MMU Miss

[Tom Turelinckx]

Package: src:linux
Version: 5.14.6-2
Severity: important
X-Debbugs-Cc: debian-sp...@lists.debian.org

Dear Maintainer,

Debian kernels > 5.14.3-1~exp1 consistently fail to boot on SPARC T4-1:

SPARC T4-1, No Keyboard
Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved.
OpenBoot 4.36.2, 31.5000 GB memory available, Serial #108045182.
Ethernet address 0:10:e0:70:a3:7e, Host ID: 8670a37e.



Boot device: disk0  File and args: 
SILO Version 1.4.14
boot: 
Allocated 64 Megs of memory at 0x4000 for kernel
Uncompressing image...
Loaded kernel version 5.14.6
Loading initial ramdisk (25723814 bytes at 0x2480 phys, 0x40C0 virt)...
ERROR: Last Trap: Fast Data Access MMU Miss

Debian kernels 5.14.3-1~exp1 and earlier boot and run successfully on this 
system.

I have tried the sparc64-smp packages built by buildd landau for these versions:
5.14.6-2, 5.14.6-3, 5.14.9-2, 5.15.5-2, 5.15.15-1, 5.16~rc8-1~exp1
They all consistently fail to boot with the same error.

I have built the Debian src pkg version 5.14.6-1 using pbuilder with a sid 
basetgz.
It consistently fails to boot with the same error.

I've then tried to bisect using the DebianKernel/GitBisect instructions on the 
Debian wiki,
but it turns out that kernels built from git (tag v5.14.3, tag v5.14.6, and ~9 
bisects in between)
using make bindeb-pkg all do boot successfully on this system.

I've tried checking out tag v5.14.6 from git, then applying all the patches 
from debian/patches
in the 5.14.6-1 src pkg and building using make bindeb-pkg. The resulting 
kernel boots successfully.

I've tried extracting the 5.14.6-1 src pkg using dpkg-source -x, then building 
using make bindeb-pkg
and the resulting kernel boots succesfully. But if I build using 
dpkg-buildpackage like pbuilder does,
then the resulting -sparc64-smp package fails to boot with the above error.

When building, I have used each time a clean sid changeroot. When using make 
bindeb-pkg I have copied
the config installed in /boot by the (non-booting) 5.14.6-1 Debian package then 
done make olddefconfig.
When using make bindeb-pkg I had to manually disable stringop-overread warnings 
in Makefile to avoid
build failure on arch/sparc/kernel/mdesc.c with v5.14.6 (fixed in later 
versions by [1]). 

When building using bindeb-pkg the resulting kernel is compressed; when using 
dpkg-buildpackage the
resulting kernel is uncompressed. I have tried both uncompressing the 
compressed kernel and compressing
the uncompressed kernel, as silo supports both. It doesn't affect the results. 
Uncompressed, the Debian
kernel is ~17MB while the standard kernel is ~13MB. I'm not sure why this 
difference is there.

On Debian salsa's kernel-team/linux I have combed through all the commits 
between tags debian/5.14.3-1_exp1
and debian/5.14.6-1, but none of them seem relevant to this issue. I have 
checked the upstream changelog
between v5.14.3 and v5.14.6, but nothing sparc-specific has changed. 

According to the buildd logs, landau is running kernel 5.15.5-2. But I think 
this is a SPARC-T5 so not
a T4, and I think it's running inside an LDOM which is not the case on my T4, 
so it may not be comparable.

I've also tried to get more information about the failure, but I don't know how 
to do that. I've tried
to get into the initramfs environment by using break=premount/modules/top, but 
the failure happens before
those stages. Measuring the elapsed time after Loading initial ramdisk it would 
seem the error message
ERROR: Last Trap: Fast Data Access MMU Miss appears when normally the first 
kernel output would appear.

I've tried to look into what the Debian src pkg's debian/* scripts do, exactly, 
but this is rather
complicated and I have limited experience with it.

Any suggestions what else I could try?

[1]: 
https://github.com/gregkh/linux/commit/fc7c028dcdbfe981bca75d2a7b95f363eb691ef3

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
cpu : UltraSparc T4 (Niagara4)
fpu : UltraSparc T4 integrated FPU
pmu : niagara4
prom: OBP 4.36.2 2014/10/24 08:13
type: sun4v

** Network interface configuration:
*** /etc/network/interfaces:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
bridge_ports enp15s0f0
bridge_fd 0
address x.x.x.x
netmask x.x.x.x
gateway x.x.x.x
iface enp15s0f0 inet manual


** PCI devices:
00:01.0 PCI bridge [0604]: Oracle/SUN Device [108e:8186] (rev 01) (prog-if 00 
[Normal decode])
Device tree node: /sys/firmware/devicetree/base/pci@400/pci@1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 

00:02.0 PCI bridge [0604]: Oracle/SUN Device 

Bug#1004206: libconfig-model-dpkg-perl: update-my-copyright-year duplicates single year

[Dominique Dumont]

On Saturday, 22 January 2022 19:30:05 CET you wrote:
> -Copyright: 2022, gregor herrmann 
> +Copyright: 2022, 2022, gregor herrmann 

I can't believe I missed this simple test case ...

Thanks for the report.

Dod

Bug#1004254: RFA: mpdscribble -- Last.fm reporting client for mpd

[Andrey Rahmatullin]

Package: wnpp
Severity: normal
Control: affects -1 src:mpdscribble

I request an adopter for the mpdscribble package.

The package description is:
 Music Player Daemon client which collects information about played tracks and
 submits them to the Last.fm social music network (formerly known as
 Audioscrobbler). If submission servers are not reachable, submissions are
 enqueued and stored on disk cache.
 .
 The client can be also configured to use other scrobbling services like
 Libre.fm.
 .
 This package contains daemon which can be optionally installed system wide.

I'm currently not using mpd so I'm not going to use or maintain this package.
It should be in a good shape for now.

Bug#1004253: broken for BIND in stable

[Marco d'Itri]

Package: prometheus-bind-exporter
Version: 0.4.0+ds-1+b5
Severity: grave

It just does not work due to 
https://github.com/prometheus-community/bind_exporter/issues/96:

Jan 23 16:31:43 dns2 prometheus-bind-exporter[14800]: level=error 
ts=2022-01-23T15:31:43.292Z caller=bind_exporter.go:427 msg="Couldn't retrieve 
BIND stats" err="failed to unmarshal XML response: strconv.ParseUint: parsing 
\"-\": invalid syntax"

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#964654:

[Akbar Emamy]

On Tue, 21 Sep 2021 04:56:47 +1200 Kaily Salmon <74pacervail...@gmail.com>
wrote:
>

Bug#834724:

[Akbar Emamy]

Bug#951598: restore the tmpfs(5) manpage

[наб]

Control: tag -1 + patch

#951596 landed in sid in September of 2021;
d/check-conflicts also restored man3/pthread_atfork.3 and friends
(provided in pthread_atfork.3posix  now in manpages-posix-dev),
cf. resultant scissor-patch below.

There's still a few elided manuals that would be nice to have restored
(list.3, for example), but that's for a different bug.

наб
-- >8 --
Subject: Re-run d/check-conflicts (Closes: #951598)

diff --git manpages-5.10.orig/debian/rules manpages-5.10/debian/rules
index e9c79c2..30b062f 100755
--- manpages-5.10.orig/debian/rules
+++ manpages-5.10/debian/rules
@@ -25,14 +25,10 @@ override_dh_installman:
rm -f debian/manpages-dev/usr/share/man/man3/crypt.3
rm -f debian/manpages-dev/usr/share/man/man3/crypt_r.3
rm -f debian/manpages-dev/usr/share/man/man3/list.3
-   rm -f debian/manpages-dev/usr/share/man/man3/pthread_atfork.3
-   rm -f debian/manpages-dev/usr/share/man/man3/pthread_mutexattr_destroy.3
-   rm -f debian/manpages-dev/usr/share/man/man3/pthread_mutexattr_init.3
rm -f debian/manpages/usr/share/man/man4/fd.4
rm -f debian/manpages/usr/share/man/man5/ftpusers.5
rm -f debian/manpages/usr/share/man/man5/nscd.conf.5
rm -f debian/manpages/usr/share/man/man5/passwd.5
-   rm -f debian/manpages/usr/share/man/man5/tmpfs.5
rm -f debian/manpages/usr/share/man/man8/nscd.8
# End of automatically added files by debian/check-conflicts


signature.asc
Description: PGP signature

Bug#1003159: dh-raku: please make the contents of "$pkg.dh-raku.list" files reproducible

[Dominique Dumont]

On Wed, 05 Jan 2022 11:52:06 + "Chris Lamb"  wrote:
> However, we can easily fix the dh-raku.list files. For that, please
> see and apply the attached patch.

Applied.

This fix will be part of next dh-raku release.

Thanks for the patch.

Dod

Bug#1004250: contents of syslinux binary package don't match syslinux-common

[Vangelis Koukis]

Package: syslinux
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
Severity: normal
X-Debbugs-Cc: vkou...@gmail.com

Hello,

I'm using latest SYSLINUX from bullseye.

After installing syslinux on a FAT32 fs:

   # syslinux --directory syslinux --install /dev/sdb1

I see the md5sum of ldlinux.c32 doesn't match the md5sum of
/usr/lib/syslinux/modules/bios/ldlinux.c32:

   # md5sum syslinux/ldlinux.c32 /usr/lib/syslinux/modules/bios/syslinux.c32
   a9b49d9dd73d9789484255881d3622d1  syslinux/ldlinux.c32
   324de4a4f9c66b2727ef8a757c21  /usr/lib/syslinux/modules/bios/syslinux.c32

I don't know where syslinux/ldlinux.c32 comes from, I assume it's
embedded in /usr/bin/syslinux, but
/usr/lib/syslinux/modules/bios/syslinux.c32 comes from the
syslinux-common binary package.

I understand there was a recent binary-only upload, which means the
contents of the syslinux package no longer match the contents of
the syslinux-common package. From changelog.Debian.amd64.gz:

syslinux (3:6.04~git20190206.bf6db5b4+dfsg1-3+b1) sid; urgency=low, 
binary-only=yes

  * Binary-only non-maintainer upload for amd64; no source changes.
  * Rebuild for outdated Built-Using

 -- all / amd64 / i386 Build Daemon (x86-conova-01) 
  Sun, 13 Jun 2021 13:52:15 +

The problem is that syslinux-common *also* contains binaries [the
syslinux modules], and they no longer match.

I think it makes sense to upload all syslinux binary packages from the
same build to the repository, so everything aligns.

Looking forward to your comments,
Vangelis.


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

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

Versions of packages syslinux depends on:
ii  libc6   2.31-13+deb11u2
ii  mtools  4.0.26-1

Versions of packages syslinux recommends:
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

Versions of packages syslinux suggests:
ii  dosfstools  4.2-1

-- no debconf information

Bug#1004249: buster-pu: package weechat/2.3-1+deb10u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Emmanuel Bouthenot , t...@security.debian.org

  * CVE-2020-8955: A crafted irc message 324 (channel mode) could
result in a crash. (Closes: #951289)
  * CVE-2020-9759: A crafted irc message 352 (who) could result
in a crash.
  * CVE-2020-9760: A crafted irc message 005 (setting a new mode
for a nick) could result in a crash.
  * CVE-2021-40516: A crafted WebSocket frame could result in a crash
in the Relay plugin. (Closes: #993803)
diff -Nru weechat-2.3/debian/changelog weechat-2.3/debian/changelog
--- weechat-2.3/debian/changelog2019-01-04 18:06:44.0 +0200
+++ weechat-2.3/debian/changelog2022-01-23 16:02:29.0 +0200
@@ -1,3 +1,17 @@
+weechat (2.3-1+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2020-8955: A crafted irc message 324 (channel mode) could
+result in a crash. (Closes: #951289)
+  * CVE-2020-9759: A crafted irc message 352 (who) could result
+in a crash.
+  * CVE-2020-9760: A crafted irc message 005 (setting a new mode
+for a nick) could result in a crash.
+  * CVE-2021-40516: A crafted WebSocket frame could result in a crash
+in the Relay plugin. (Closes: #993803)
+
+ -- Adrian Bunk   Sun, 23 Jan 2022 16:02:29 +0200
+
 weechat (2.3-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
weechat-2.3/debian/patches/0001-irc-fix-crash-when-receiving-a-malformed-message-324.patch
 
weechat-2.3/debian/patches/0001-irc-fix-crash-when-receiving-a-malformed-message-324.patch
--- 
weechat-2.3/debian/patches/0001-irc-fix-crash-when-receiving-a-malformed-message-324.patch
  1970-01-01 02:00:00.0 +0200
+++ 
weechat-2.3/debian/patches/0001-irc-fix-crash-when-receiving-a-malformed-message-324.patch
  2022-01-23 16:00:54.0 +0200
@@ -0,0 +1,47 @@
+From db4ffe7ccf4b0654cca6993ecaecd5b86070c658 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?S=C3=A9bastien=20Helleu?= 
+Date: Sat, 8 Feb 2020 20:24:50 +0100
+Subject: irc: fix crash when receiving a malformed message 324 (channel mode)
+
+Thanks to Stuart Nevans Locke for reporting the issue.
+---
+ src/plugins/irc/irc-mode.c | 21 -
+ 1 file changed, 12 insertions(+), 9 deletions(-)
+
+diff --git a/src/plugins/irc/irc-mode.c b/src/plugins/irc/irc-mode.c
+index b5d525c6c..5381bfda6 100644
+--- a/src/plugins/irc/irc-mode.c
 b/src/plugins/irc/irc-mode.c
+@@ -177,17 +177,20 @@ irc_mode_channel_update (struct t_irc_server *server,
+ current_arg++;
+ if (pos[0] == chanmode)
+ {
+-chanmode_found = 1;
+-if (set_flag == '+')
++if (!chanmode_found)
+ {
+-str_mode[0] = pos[0];
+-str_mode[1] = '\0';
+-strcat (new_modes, str_mode);
+-if (argument)
++chanmode_found = 1;
++if (set_flag == '+')
+ {
+-if (new_args[0])
+-strcat (new_args, " ");
+-strcat (new_args, argument);
++str_mode[0] = pos[0];
++str_mode[1] = '\0';
++strcat (new_modes, str_mode);
++if (argument)
++{
++if (new_args[0])
++strcat (new_args, " ");
++strcat (new_args, argument);
++}
+ }
+ }
+ }
+-- 
+2.20.1
+
diff -Nru 
weechat-2.3/debian/patches/0002-irc-fix-crash-when-receiving-a-malformed-message-352.patch
 
weechat-2.3/debian/patches/0002-irc-fix-crash-when-receiving-a-malformed-message-352.patch
--- 
weechat-2.3/debian/patches/0002-irc-fix-crash-when-receiving-a-malformed-message-352.patch
  1970-01-01 02:00:00.0 +0200
+++ 
weechat-2.3/debian/patches/0002-irc-fix-crash-when-receiving-a-malformed-message-352.patch
  2022-01-23 16:00:54.0 +0200
@@ -0,0 +1,26 @@
+From 43a8cb9a3b9d8202465fc2b91ff36e7fe51f0a74 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?S=C3=A9bastien=20Helleu?= 
+Date: Fri, 14 Feb 2020 08:14:31 +0100
+Subject: irc: fix crash when receiving a malformed message 352 (who)
+
+Thanks to Stuart Nevans Locke for reporting the issue.
+---
+ src/plugins/irc/irc-protocol.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/plugins/irc/irc-protocol.c b/src/plugins/irc/irc-protocol.c
+index fb7ba870a..6bfbd5240 100644
+--- a/src/plugins/irc/irc-protocol.c
 b/src/plugins/irc/irc-protocol.c
+@@ -4521,7 +4521,7 @@ IRC_PROTOCOL_CALLBACK(352)
+ 
+ if (argc > 8)
+ {
+-arg_start = (strcmp (argv[8], 

Bug#1004248: /etc/manpath.config: Section 0 (man0) is ignored

[Alejandro Colomar]

Package: man-db
Version: 2.9.4-4
Severity: normal
X-Debbugs-Cc: colomar.6@gmail.com

Dear Maintainer,

I have some manual pages for header files, and use section 0 for
them, as the man-pages-posix upstream pages do.  It seems to me to
be more organized than adding stuff to man7, and since the
upstream man-db seems to understand section 0, I think it makes
sense to at least allow it in Debian.

The fix is easy: just adding '0' to 'SECTION' in .

Thanks,

Alex


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

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

Versions of packages man-db depends on:
ii  bsdextrautils  2.37.2-6
ii  bsdmainutils   12.1.7+nmu3
ii  debconf [debconf-2.0]  1.5.79
ii  groff-base 1.22.4-8
ii  libc6  2.33-2
ii  libgdbm6   1.22-1
ii  libpipeline1   1.5.5-1
ii  libseccomp22.5.3-2
ii  zlib1g 1:1.2.11.dfsg-2

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor3.0.3-6
ii  chromium [www-browser]  97.0.4692.71-0.1
ii  firefox-esr [www-browser]   91.5.0esr-1
ii  google-chrome-stable [www-browser]  97.0.4692.71-1
ii  groff   1.22.4-8
ii  less590-1
ii  links [www-browser] 2.25-1
ii  w3m [www-browser]   0.5.3+git20210102-6

-- Configuration Files:
/etc/manpath.config changed:
MANDATORY_MANPATH   /usr/man
MANDATORY_MANPATH   /usr/share/man
MANDATORY_MANPATH   /usr/local/share/man
MANPATH_MAP /bin/usr/share/man
MANPATH_MAP /usr/bin/usr/share/man
MANPATH_MAP /sbin   /usr/share/man
MANPATH_MAP /usr/sbin   /usr/share/man
MANPATH_MAP /usr/local/bin  /usr/local/man
MANPATH_MAP /usr/local/bin  /usr/local/share/man
MANPATH_MAP /usr/local/sbin /usr/local/man
MANPATH_MAP /usr/local/sbin /usr/local/share/man
MANPATH_MAP /usr/X11R6/bin  /usr/X11R6/man
MANPATH_MAP /usr/bin/X11/usr/X11R6/man
MANPATH_MAP /usr/games  /usr/share/man
MANPATH_MAP /opt/bin/opt/man
MANPATH_MAP /opt/sbin   /opt/man
MANDB_MAP   /usr/man/var/cache/man/fsstnd
MANDB_MAP   /usr/share/man  /var/cache/man
MANDB_MAP   /usr/local/man  /var/cache/man/oldlocal
MANDB_MAP   /usr/local/share/man/var/cache/man/local
MANDB_MAP   /usr/X11R6/man  /var/cache/man/X11R6
MANDB_MAP   /opt/man/var/cache/man/opt
MANDB_MAP   /snap/man   /var/cache/man/snap
SECTION 1 n l 8 3 0 2 3posix 3pm 3perl 3am 5 4 9 6 7


-- debconf information:
  man-db/install-setuid: false
  man-db/auto-update: true

Bug#1004247: bullseye-pu: package weechat/3.0-1+deb11u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Emmanuel Bouthenot , t...@security.debian.org

  * CVE-2021-40516: A crafted WebSocket frame could result in a crash
in the Relay plugin. (Closes: #993803)
diff -Nru weechat-3.0/debian/changelog weechat-3.0/debian/changelog
--- weechat-3.0/debian/changelog2020-11-21 09:34:12.0 +0200
+++ weechat-3.0/debian/changelog2022-01-23 16:29:14.0 +0200
@@ -1,3 +1,11 @@
+weechat (3.0-1+deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2021-40516: A crafted WebSocket frame could result in a crash
+in the Relay plugin. (Closes: #993803)
+
+ -- Adrian Bunk   Sun, 23 Jan 2022 16:29:14 +0200
+
 weechat (3.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
weechat-3.0/debian/patches/0001-relay-fix-crash-when-decoding-a-malformed-websocket-.patch
 
weechat-3.0/debian/patches/0001-relay-fix-crash-when-decoding-a-malformed-websocket-.patch
--- 
weechat-3.0/debian/patches/0001-relay-fix-crash-when-decoding-a-malformed-websocket-.patch
  1970-01-01 02:00:00.0 +0200
+++ 
weechat-3.0/debian/patches/0001-relay-fix-crash-when-decoding-a-malformed-websocket-.patch
  2022-01-23 16:29:14.0 +0200
@@ -0,0 +1,64 @@
+From ede4582879f31cc29be54fdcdf8bc168dc7ea6e3 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?S=C3=A9bastien=20Helleu?= 
+Date: Sat, 4 Sep 2021 23:09:19 +0200
+Subject: relay: fix crash when decoding a malformed websocket frame
+
+---
+ src/plugins/relay/relay-websocket.c | 16 +++-
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+diff --git a/src/plugins/relay/relay-websocket.c 
b/src/plugins/relay/relay-websocket.c
+index e3b768d0a..789f67e20 100644
+--- a/src/plugins/relay/relay-websocket.c
 b/src/plugins/relay/relay-websocket.c
+@@ -278,7 +278,7 @@ relay_websocket_decode_frame (const unsigned char *buffer,
+ index_buffer = 0;
+ 
+ /* loop to decode all frames in message */
+-while (index_buffer + 2 <= buffer_length)
++while (index_buffer + 1 < buffer_length)
+ {
+ opcode = buffer[index_buffer] & 15;
+ 
+@@ -293,10 +293,12 @@ relay_websocket_decode_frame (const unsigned char 
*buffer,
+ length_frame_size = 1;
+ length_frame = buffer[index_buffer + 1] & 127;
+ index_buffer += 2;
++if (index_buffer >= buffer_length)
++return 0;
+ if ((length_frame == 126) || (length_frame == 127))
+ {
+ length_frame_size = (length_frame == 126) ? 2 : 8;
+-if (buffer_length < 1 + length_frame_size)
++if (index_buffer + length_frame_size > buffer_length)
+ return 0;
+ length_frame = 0;
+ for (i = 0; i < length_frame_size; i++)
+@@ -306,10 +308,9 @@ relay_websocket_decode_frame (const unsigned char *buffer,
+ index_buffer += length_frame_size;
+ }
+ 
+-if (buffer_length < 1 + length_frame_size + 4 + length_frame)
+-return 0;
+-
+ /* read masks (4 bytes) */
++if (index_buffer + 4 > buffer_length)
++return 0;
+ int masks[4];
+ for (i = 0; i < 4; i++)
+ {
+@@ -333,6 +334,11 @@ relay_websocket_decode_frame (const unsigned char *buffer,
+ *decoded_length += 1;
+ 
+ /* decode data using masks */
++if ((length_frame > buffer_length)
++|| (index_buffer + length_frame > buffer_length))
++{
++return 0;
++}
+ for (i = 0; i < length_frame; i++)
+ {
+ decoded[*decoded_length + i] = (int)((unsigned 
char)buffer[index_buffer + i]) ^ masks[i % 4];
+-- 
+2.20.1
+
diff -Nru weechat-3.0/debian/patches/series weechat-3.0/debian/patches/series
--- weechat-3.0/debian/patches/series   2020-04-04 12:31:17.0 +0300
+++ weechat-3.0/debian/patches/series   2022-01-23 16:29:14.0 +0200
@@ -1 +1,2 @@
 01_fix_asciidoctor_options.patch
+0001-relay-fix-crash-when-decoding-a-malformed-websocket-.patch

Bug#995026: Update

[Jeremy Hendricks]

This is definitely a misconfiguration on my part. I’m trying to track down
why it works for me in one case and not another (on the same hardware).
Maybe that’ll save others some frustration if it’s just a missing package
or similar.

Bug#965172: RFP: ripeatlasprobe -- RIPE Atlas Software Probe

[Daniel Gröber]

Hi Marc,

I just had a look at the ripe atlas repo to see if this can be packaged in
Debian.

It looks to me like they have 1) a 12+ year old forked and very, very
patched version of busybox that they somehow grafted their measurment code
onto, 2) an embedded copy of libevent though at least close to the version
in unstable and 3) a custom monolithic build script that spits out their
debs without a normale Makefile in sight.

I think this mess would be pretty hard to package without pushing for
significant changes upstream. Which is over my threshold for spinning a
quick package ;)

--Daniel


signature.asc
Description: PGP signature

Bug#1004176: qbrz not working on Debian 11

[Jelmer Vernooij]

On Sat, Jan 22, 2022 at 09:52:04AM +0100, Stefano Rosellini wrote:
> Package: qbzr
Do you mean qbrz rather than qbzr?

> Version: 0.23.2+bzr1640-1
> 
> I installed brz 3.1.0-8, bzr 2.7.0+bzr6622+brz and qbzr 0.23.2+bzr1640-1.
> Executing "bzr qlog" or "brz qlog" or other command with "q*" I get an 
> unknown command.
> 
> Example:
> 
> $ bzr qlog brz: ERROR: unknown command "qlog". Perhaps you meant "log" $ brz
> qlog
> brz: ERROR: unknown command "qlog". Perhaps you meant "log" $ I'm using
> Debian 11.2, Kernel 5.10.92-1, libc6 2.31-13+deb11u2.

What version of Breezy and Bazaar do you have installed?

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc

Bug#1004246: cephfs-top: Short description cut short and continues on long description

[Beatrice Torracca]

Package: cephfs-top
Severity: normal

Hi,

the short package description of cephfs-top is truncated and continues
in the long package. This is against what Debian Policy says regarding package 
description in secion 3.4 
(https://www.debian.org/doc/debian-policy/ch-binary.html#the-description-of-a-package).

Thanks,

beatrice

Bug#995356: python-parameterized: autopkgtest regression: AssertionError in tearDownModule

[Paul Gevers]

Source: python-parameterized
Followup-For: Bug #995356

Hi,

As announced yesterday, I have uploaded an NMU to DELAYED/5 dropping
the autopkgtest. Please let me know if I should cancel that, but then
I expect a solution reasonably soon.

Paul
diff --git a/debian/changelog b/debian/changelog
index fdfb630..dbc842f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+python-parameterized (0.8.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop autopkgtest for now as it fails and this is blocking migration
+(See: #995356)
+
+ -- Paul Gevers   Sun, 23 Jan 2022 15:08:44 +0100
+
 python-parameterized (0.8.1-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --git a/debian/tests/control b/debian/tests/control
deleted file mode 100644
index 0c55f37..000
--- a/debian/tests/control
+++ /dev/null
@@ -1,19 +0,0 @@
-Test-Command: set -e
- ; for py in $(py3versions -r 2>/dev/null)
- ; do cd "$AUTOPKGTEST_TMP"
- ; echo "Testing with $py (unittest):"
- ; $py -m unittest -v parameterized.test
- ; echo "Testing with $py (nose):"
- ; $py -m nose -v parameterized.test
- ; echo "Testing with $py (nose2):"
- ; $py -m nose2 -v parameterized.test
- ; echo "Testing with $py (pytest):"
- ; $py -m pytest -v --pyargs parameterized.test
- ; done
-Depends: python3-all,
- python3-mock,
- python3-nose,
- python3-nose2,
- python3-parameterized,
- python3-pytest
-Restrictions: allow-stderr

Bug#1000637: generating debian/control is *NOT* policy compliant

[Ondřej Surý]

That’s exactly how it’s done in the PHP packages. If you see a different 
content in the debian/control, it means the packages were not generated in the 
clean build environment.

Ondřej
--
Ondřej Surý  (He/Him)

> On 23. 1. 2022, at 15:09, Thomas Goirand  wrote:
> 
> Hi,
> 
> Looks like the php-* PECL packages are getting their debian/control generated 
> at build time from a debian/control.in.
> 
> If you didn't know, this is *NOT* policy compliant. The policy clearly says 
> source packages must have a not-generated debian/control in good shape 
> (though I haven't taken the time to find where this is written in the policy, 
> I just know it's forbidden...). Please stop doing this.
> 
> If you still need to generate it, then you can have a look how the Linux 
> kernel package does it. They generate the debian/control from control.in 
> thanks to some internal tooling, but save the debian/control in the generated 
> form in their source package. That may be a nice workaround, and the better 
> way to go for you.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 

Bug#1004244: [Pkg-javascript-devel] Bug#1001364: eslint: Please update at least to version ≥ 7

[Jonas Smedegaard]

Quoting Yadd (2021-12-09 09:38:56)
> to update node-eslint-plugin-flowtype, I need 
> eslint/lib/rules/no-unused-expressions which is provided by eslint 7

Whoops - I missed that this was an older bug to track different needs.

@Yadd: Can you try pinpoint which features are needed for the flowtype 
plugin - perhaps support can be cherry-picked...

Also, do you mind that "your" bugreport now got renumbered?


 - Jonas

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

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

signature.asc
Description: signature

Bug#1000637: generating debian/control is *NOT* policy compliant

[Thomas Goirand]

Hi,

Looks like the php-* PECL packages are getting their debian/control 
generated at build time from a debian/control.in.


If you didn't know, this is *NOT* policy compliant. The policy clearly 
says source packages must have a not-generated debian/control in good 
shape (though I haven't taken the time to find where this is written in 
the policy, I just know it's forbidden...). Please stop doing this.


If you still need to generate it, then you can have a look how the Linux 
kernel package does it. They generate the debian/control from control.in 
thanks to some internal tooling, but save the debian/control in the 
generated form in their source package. That may be a nice workaround, 
and the better way to go for you.


Cheers,

Thomas Goirand (zigo)

Bug#1004245: ITP: ocsipersist -- Persistent key/value storage for Ocsigen using multiple backends

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocsipersist
  Version : 1.0.5
  Upstream Author : Vincent Balat
* URL : https://ocsigen.org/ocsipersist
* License : LGPL-2.1
  Programming Lang: OCaml
  Description : persistent key/value storage for Ocsigen using multiple 
backends

 Ocsipersist is used pervasively in Eliom/Ocsigen to handle sessions
 and references. It can be used as an extension for ocsigenserver or
 as a library. Implementations of the following backends currently
 exist: PostgreSQL, SQLite.

This used to be part of ocsigenserver, and has been split out to its
own package upstream. It is a dependency of eliom. It will be
maintained in the OCaml team.

Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator

[Thomas Dickey]

On Sun, Jan 23, 2022 at 02:08:00PM +0100, Andreas Metzler wrote:
> On 2022-01-16 Andreas Metzler  wrote:
> [...]
> > I will probably followup with further wishes/comments later, not today
> > but hopefully in next week.
> [...]
> 
> Hello Thomas,
> 
> I think there are just two thing left pre upload:
> 
> 1. The upload introduces an epoch because the upstream version went from
> mmdd to 2.0.mmdd. Given that the new version scheme seems to
> have found acceptance in e.g. Fedora /I/ do not see a better way. Could
> you ask about the epoch on debian-devel (as per policy
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly
> ) - TIA.

thanks - I will do this.
 
> 2. It would be nice to merge the changelog entries for 1:2.0.20220109-1
> and 1:2.0.20220114-1, listing only the changes relative to what was yet
> uploaded to Debian. (I would not consider this a must for sponsorship.)

okay - a single upload comment would be simpler

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature