Bug#1010422: transition: r-api-bioc-3.15

[Nilesh Patra]

On 2 May 2022 11:54:34 am IST, Andreas Tille  wrote:
>Am Mon, May 02, 2022 at 09:39:25AM +0530 schrieb Nilesh Patra:
>> On Sun, 1 May 2022 11:42:07 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?= 
>>  wrote:
>> > Hi,
>> > Bioconductor 3.15 has been released [1].
>> 
>> Please hold this off until r-base migrates (which should be soon)
>
>As far as I can see the testing migration is blocked by
>
>Isn't this the just discussed Graphics API issue?

There were many more of 'em blocking the transition. I cleaned that up 
yesterday and reduced it to the one remaining.

>I guess your recent upload of 0.1.2.1-3 is supposed to fix this and
>is intended to enable the migration, right?
>

Yes, let's wait until r-base migrates, I guess it'd take a day or two maybe.
Anyway we need to wait for bioc transition until we get a thumbs up from 
release team.

Migrating the graphics packages are also a mess now due to no-binNMUs. Need to 
propagate hacks to get these in testing. All of it could have been avoided if 
it was properly coordinated, but anyway.

>[1] 
>https://ci.debian.net/data/autopkgtest/testing/arm64/r/r-cran-thematic/21293099/log.gz
>

--
Best,
Nilesh

Bug#1010004: RFS: odr-dabmod/2.6.0-1 [ITP] -- DAB modulator compliant to ETSI EN 300 401

[Robin ALEXANDER]

Hi Bastian,

I just realized that I need to make a slight change to file
debian/rules by calling dh_auto_configure with an additional argument
in order to avoid compiling odr-dabmod with the option "-march=native".

Since the odr-dabmod package was not moved to the NEW queue yet, can I
just reload the package with the updated debian/rules file or do I also
need to modify file debian/changelog indicating the change on
debian/rules? In the latter case, do I need to change the package
version (ie. moving to 2.6.0-2 from 2.6.0-1)?

Have a nice week.

-- 
Robin 

Le vendredi 29 avril 2022 à 11:14 +0200, Bastian Germann a écrit :
> Am 29.04.22 um 11:07 schrieb Robin ALEXANDER:
> > As I wrote to you, I:
> >    1. Uploaded on Wednesday (April 27) the corrected versions of
> > odr-
> > dabmux (https://mentors.debian.net/package/odr-dabmux/) and odr-
> > dabmod
> > (https://mentors.debian.net/package/odr-dabmod/)
> > 
> >    2. Removed the moreinfo tag on odr-dabmux
> > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009867) and
> > odr-
> > dabmod (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010004)
> > 
> > Assuming I did everything correctly, is there anything else I must
> > do
> > to have these 2 packages pushed to the NEW queue (like what was
> > done
> > with odr-padenc)? Or is it the sponsor/you who pushes the packages
> > to
> > the NEW queue by closing the above 2 bugs (1009867 and  1010004) ?
> 
> You just have to wait until someone will review the packages.
> My comments were just to help getting the packages to a state where a
> DD would have a look at it.


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

Bug#1010422: transition: r-api-bioc-3.15

[Andreas Tille]

Am Mon, May 02, 2022 at 09:39:25AM +0530 schrieb Nilesh Patra:
> On Sun, 1 May 2022 11:42:07 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?= 
>  wrote:
> > Hi,
> > Bioconductor 3.15 has been released [1].
> 
> Please hold this off until r-base migrates (which should be soon)

As far as I can see the testing migration is blocked by

  ∙ autopkgtest for r-cran-thematic/0.1.2.1-2: amd64: Pass, arm64: Regression ♻ 
(reference ♻), armhf: Pass, i386: Pass, ppc64el: Pass, s390x: Pass

where the autopkgtest log[1] says:

...
══ Failed tests 
── Error (test-base.R:9:3): base baselines ─
Error in `svglite_(filename, bg, width, height, pointsize, standalone, 
always_valid)`: Graphics API version mismatch
Backtrace:
▆
 1. └─thematic:::expect_doppelganger(...) at test-base.R:9:2
 2.   └─vdiffr::expect_doppelganger(name, p, ...) at 
tests/testthat/helper-vdiffr.R:12:2
 3. └─vdiffr writer(fig, testcase, title)
 4.   └─vdiffr:::svglite(file)
 5. └─vdiffr:::svglite_(...)
── Error (test-ggplot.R:31:3): ggplot baselines 
Error in `svglite_(filename, bg, width, height, pointsize, standalone, 
always_valid)`: Graphics API version mismatch
Backtrace:
▆
 1. └─thematic:::expect_doppelganger(...) at test-ggplot.R:31:2
 2.   └─vdiffr::expect_doppelganger(name, p, ...) at 
tests/testthat/helper-vdiffr.R:12:2
 3. └─vdiffr writer(fig, testcase, title)
 4.   └─vdiffr:::svglite(file)
 5. └─vdiffr:::svglite_(...)
── Error (test-ggplot.R:149:3): Scale defaults can be overridden ───
Error in `svglite_(filename, bg, width, height, pointsize, standalone, 
always_valid)`: Graphics API version mismatch
...

Isn't this the just discussed Graphics API issue?

I guess your recent upload of 0.1.2.1-3 is supposed to fix this and
is intended to enable the migration, right?

Kind regards

  Andreas.


[1] 
https://ci.debian.net/data/autopkgtest/testing/arm64/r/r-cran-thematic/21293099/log.gz

-- 
http://fam-tille.de

Bug#1010468: transition: gnat-11

[Nicolas Boulenguez]

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

Hello.

The gcc-V source package builds the Ada compiler (gnat-V) and
companion library (libgnat-V).
The default Ada compiler is selected by the gnat package.
In unstable and testing, gnat Depends: gnat-10.
In experimental, gnat Depends: gnat-11.

Ada libraries have specific requirements.
* They must Build-Depend: gnat-V (in addition to gnat).
* Each -dev package name carries a version, similar to the shared
  object version for lib packages.  Most changes in the source require
  a renaming of the -dev package, and a source upload of all reverse
  dependencies.
  In order to reduce the number of such transitions, many unrelated
  changes, like new upstream releases, are introduced with a libgnat
  transition and tested in experimental.
* Each -dev package depends on both gnat and gnat-V.

GCC builds no libgnat-V-dev package. The sources for the Ada standard
library are distributed with the compiler in the gnat-V package.  So
it is convenient to track the transition with the libgnat-V package
instead (even when the ABI is unchanged).

Ben file:

title = "gnat-11";
is_affected = .depends ~ "libgnat-8" | .depends ~ "libgnat-9" | .depends ~ 
"libgnat-10" | .depends ~ "libgnat-11";
is_good = .depends ~ "libgnat-11";
is_bad = .depends ~ "libgnat-8" | .depends ~ "libgnat-9" | .depends ~ 
"libgnat-10";

During last transition, Sebastian Ramacher has requested that the -dev
packages replace
  Depends: gnat, gnat-V
with
  Depends: gnat (>= V), gnat (<< V+1)
in order to help the migration from unstable to testing.
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975589#24)
Only a few key packages have been updated and tested in experimental,
but it seems safe to update the remaining packages during the reupload
to unstable.

dh-ada-library libxmlada gprbuild
  are ready in experimental (including a correct gnat dependency)

gprconfig-kb
  is tightly connected with gprbuild and must migrate with the other
  packages despite not depending on libgnat.
  It is ready in experimental too.

adasockets plplot
  are almost ready in experimental,
  but must manually change the -dev dependency when reuploaded to unstable
gnat, gnat-V  ->  gnat (>= V), gnat (<< V+1)

adacgi ahven anet dbusada gprbuild libalog libaunit libflorist
libgmpada libgnatcoll libgnatcoll-bindings libgnatcoll-db libgtkada
liblog4ada libncursesada libtemplates-parser libtexttools libxmlada
libxmlezout pcscada
  are almost ready in experimental, but must
  Build-Depend: dh-ada-library (>= 7.5)
  when reuploaded to unstable so that the gnat dependency is correctly
  generated during the rebuild.

These source packages produce no library and should only need a
bin-NMU in due time:
nmumusic123_16.6-2   . ANY . -m 'Rebuild with gnat-11'
nmu   topal_81-1 . ANY . -m 'Rebuild with gnat-11 for 
unstable'
nmu whitakers-words_0.2020.10.27-1.1 . ANY . -m 'Rebuild with gnat-11'

adabrowse adacontrol asis gnat-gps libaws
  are RC-buggy and have been removed from testing.
  They should not prevent the transition.
  Once the dust has settled, we will see if and when they can be
  reintroduced into Debian.

libgnatcoll-python
  was a temporary package only intended for python2 support in the
  unstable distribution.
  It should be removed after this transition.

ghdl
  should not be affected.
  It requires an explicit gnat-V, independently of the default gnat.

ada-reference-manual
  should not be affected.
  It needs gnat at build time only.

Bug#1010269: crashes immediately at start

[duck]

Control: severity -1 grave
Control: affects -1 src:dxvk


Quack,

Not sure why the severity was not raised but as it is this package is 
unusable.

It also breaks dxvk's autopkgtest which I needed before releasing fixes.

There were changes in the nls files packaging in 6.9~repack-1 but no 
problem was spotted at the time so I guess new files might be needed and 
not included but I did not have time to check this supposition.


Regards.
\_o<

--
Marc Dequènes

Bug#1009191: cctbx: please re-enable building on riscv64

[Andrius Merkys]

Hi,

On 2022-04-30 13:29, Neil Williams wrote:
>> Neil, is there a particular reason riscv64 support was disabled in
>> 2021.12+ds1-3? 
> I didn't see it as particularly likely that any real-world usage of
> cctbx was manageable on any current RISCV64 hardware. 

Thanks for explanation. I usually disable only the explicitly
unsupported architectures, or the ones that fail and would otherwise
block migration.

>> cctbx seems to build fine on riscv64 now. Can it be
>> re-enabled?
> Probably, yes. I won't have time to do an upload soon though. 
> 
> If someone else has time to do it as a team upload, go ahead. 

I will enable riscv64 and team upload.

Best,
Andrius

Bug#1010429: gddrescue: autopkgtest regression

[Michael Prokop]

* Paul Gevers [Sun May 01, 2022 at 02:39:15PM +0200]:

> With a recent upload of gddrescue the autopkgtest of gddrescue fails in
> testing when that autopkgtest is run with the binary packages of gddrescue
> from unstable. It passes when run with only packages from testing. In
> tabular form:
[...]

> Currently this regression is blocking the migration to testing [1]. Can you
> please investigate the situation and fix it?
[...]

Indeed, I could reproduce the issue and just uploaded a new version,
which is supposed to fix the issue. Thanks for reporting it, Paul,
appreciated!

regards
-mika-


signature.asc
Description: PGP signature

Bug#1004511: luajit SEGFAULTS on ppc64el

[Paul Gevers]

Hi,

On 24-04-2022 12:00, Paul Gevers wrote:

On Sat, 29 Jan 2022 19:32:53 +0100 Paul Gevers  wrote:
With a recent upload of luajit the autopkgtest of knot-resolver fails 
in testing when that autopkgtest is run with the binary packages of 
luajit from unstable. It passes when run with only packages from 
testing. In tabular form:


knot-resolver has been removed from testing due to this bug report, but 
can't migrate back because a newer version fails to build on ppc64el. 
Also other reverse dependencies of luajit show SEGFAULT in their 
autopkgtest on ppc64el, so this seems a problem in luajit. Unfortunately 
(Release Team member opinion) luajit is a key package so can't be 
trivially removed. Can you (maintainer and ppc64el porters) please have 
a look?


If this issue is difficult to fix, how about removing luajit from 
ppc64el? I noticed that the only reverse (build) dependent key package 
of luajit (src:efl) already switched to plain lua on ppc64el (probably 
because of this issue).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009079: mdtraj: autopkgtest timeout on arm64 (downloading pdb file?)

[Paul Gevers]

Control: severity -1 serious
Control: user debian...@lists.debian.org
Control: usertag -1 flaky needs-internet

Hi,

On Thu, 07 Apr 2022 10:46:43 +1000 Stuart Prescott  
wrote:

The autopkgtest tets for mdtraj attempts to download a pdb file and then use
that in calculations. This is failing (either all the time or intermittently)
with a timeout:


I looked at the results of the autopkgtest of you package because it was 
showing up as a regression for the upload of gcc-12.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure. Our arm64 workers are located in China, I 
wouldn't be surprised if the required connection isn't optimal, so I 
suspect increasing the timeout sufficiently is going to solve the issue, 
although making it more robust against connection issues would be smart 
too (e.g. retrying a small number of times in case of failure).


Also, as the autopkgtest spec says [1], please mark your test with the 
"needs-internet" restriction.


Paul

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


OpenPGP_signature
Description: OpenPGP digital signature

Bug#440253: Please package inform 7

[Ben Finney]

On 30-Apr-2022, Diane Trout wrote:

> As an update it appears that Inform7 was fully open sourced under
> the artistic public license with redistribution of derived works
> permission included.
> 
> From https://github.com/ganelson/inform
> "As from the first date of this repository becoming public, 28 April
> 2022, the Package is placed under the Artistic License 2.0."

That does seem clear; the full text at that URL (a couple of
paragraphs) seems at first read to grant the necessary permissions for
free software.

Great news, thank you!

-- 
 \  “Earth gets its price for what Earth gives us.” —James Russell |
  `\Lowell |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1010381: commons-daemon: FTBFS on riscv64: error: Unsupported CPU architecture "riscv64"

[tony mancill]

On Sun, May 01, 2022 at 12:59:27AM +0800, Bo YU wrote:
> On Sun, May 1, 2022 at 12:44 AM tony mancill  wrote:
> 
> > Thank you!  Note that the Debian package is quite a bit behind upstream,
> > so I wonder whether the patch is even necessary against upstream version
> > 1.3.0.  (I have not checked yet.)
> >
> If i am not wrong:
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=blob_plain;f=src/native/unix/support/apsupport.m4;hb=HEAD
> 
> It seems that commons-daemon
> 
> upstream
> did not support riscv64.

I think Thorsten pointed out the core issue over 9 years ago... :)

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

Bug#1010453: closed by Debian FTP Masters (reply to Doug Torrance ) (Bug#1010453: fixed in macaulay2 1.19.1+ds-9)

[Paul Gevers]

Hi,

On 02-05-2022 02:39, Debian Bug Tracking System wrote:

  macaulay2 (1.19.1+ds-9) unstable; urgency=medium
  .
* debian/tests/control
  - Mark package-tests as flaky since it regularly times out on armhf
(Closes: #1010453).


Hmmm. May I recommend something else?

Marking autopkgtests that regularly time out is a solution that has a 
relative high price on the infrastructure. These tests are still run 
(until they time out), while they don't influencing migration of any 
package if the package contain more than one autopkgtest. Marking tests 
flaky is nearly only useful if a human is regularly going to look at the 
results and does something with it. To be honest, I'm not expecting that 
here (but let me know if I'm making a wrong assumption here).


Instead, I recommend to not run the test at all on armhf if we're going 
to ignore the result there (successful runs also take long), but use it 
normally on all other architectures. There's the "Architecture" field 
available in debian/tests/control that can be used to achieve that in a 
correct way. It understands the regular syntax so "!armhf" should suffice.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010422: transition: r-api-bioc-3.15

[Nilesh Patra]

On Sun, 1 May 2022 11:42:07 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?= 
 wrote:
> Hi,
> Bioconductor 3.15 has been released [1].

Please hold this off until r-base migrates (which should be soon)

--
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1010467: clang: cannot use hip from /usr

[Cordell Bloor]

Package: clang
Version: 1:13.0-54
Severity: normal

Dear Maintainer,

The upstream versions of clang-13 and clang-14 fulfill the minimum
requirements to build HIP language programs, but contain a bug that
prevents them from functioning correctly when the HIP library is
installed in /usr.

This problem was fixed in upstream llvm, and the change is expected to
land in clang-15. The change is very minimal and only affects the HIP
language. It can be found here:
https://github.com/llvm/llvm-project/commit/6730b44480fcce18bfbbae0c46719250e9eae425

This problem is important to address to help the packaging of ROCm
proceed, as the Debian native package will install HIP into /usr.


To reproduce the problem:

# install HIP to /usr
https://gist.github.com/cgmb/edb7b790ab55681fb2ba5385ee02489b

# create a HIP language program
cat > example.cpp << 'EOF'
#include 

__global__ void square(int *array, int n) {
int tid = blockIdx.x;
if (tid < n)
array[tid] = array[tid] * array[tid];
}
EOF
# compile it
clang++ \
  -v \
  -std=c++11 \
  --offload-arch=gfx908 \
  -mllvm -amdgpu-early-inline-all=true \
  -mllvm -amdgpu-function-calls=false \
  --hip-device-lib-path="/usr/lib/x86_64-linux-gnu/amdgcn/bitcode" \
  --rocm-path="/usr" \
  -fhip-new-launch-api \
  -D__HIP_PLATFORM_AMD__=1 -D__HIP_PLATFORM_HCC__=1 \
  -mf16c \
  -O3 -DNDEBUG \
  -x hip \
  -o example.o \
  -c example.cpp

# see output
Debian clang version 13.0.1-3+b2
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/11
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/11
Candidate multilib: .;@m64
Selected multilib: .;@m64
Found HIP installation: /usr, version 3.5.0
 "/usr/lib/llvm-13/bin/clang" -cc1 -triple amdgcn-amd-amdhsa -aux-triple 
x86_64-pc-linux-gnu -emit-obj --mrelax-relocations -disable-free 
-disable-llvm-verifier -discard-value-names -main-file-name example.cpp 
-mrelocation-model pic -pic-level 1 -fhalf-no-semantic-interposition 
-mframe-pointer=none -fno-rounding-math -aux-target-cpu x86-64 
-aux-target-feature +f16c -fcuda-is-device -mllvm -amdgpu-internalize-symbols 
-fcuda-allow-variadic-functions -fvisibility hidden 
-fapply-global-visibility-to-externs -mlink-builtin-bitcode 
/usr/lib/x86_64-linux-gnu/amdgcn/bitcode/hip.bc -mlink-builtin-bitcode 
/usr/lib/x86_64-linux-gnu/amdgcn/bitcode/ocml.bc -mlink-builtin-bitcode 
/usr/lib/x86_64-linux-gnu/amdgcn/bitcode/ockl.bc -mlink-builtin-bitcode 
/usr/lib/x86_64-linux-gnu/amdgcn/bitcode/oclc_daz_opt_off.bc 
-mlink-builtin-bitcode 
/usr/lib/x86_64-linux-gnu/amdgcn/bitcode/oclc_unsafe_math_off.bc 
-mlink-builtin-bitcode 
/usr/lib/x86_64-linux-gnu/amdgcn/bitcode/oclc_finite_only_off.bc 
-mlink-builtin-bitcode 
/usr/lib/x86_64-linux-gnu/amdgcn/bitcode/oclc_correctly_rounded_sqrt_on.bc 
-mlink-builtin-bitcode 
/usr/lib/x86_64-linux-gnu/amdgcn/bitcode/oclc_wavefrontsize64_on.bc 
-mlink-builtin-bitcode 
/usr/lib/x86_64-linux-gnu/amdgcn/bitcode/oclc_isa_version_908.bc -target-cpu 
gfx908 -debugger-tuning=gdb -v -resource-dir /usr/lib/llvm-13/lib/clang/13.0.1 
-internal-isystem /usr/lib/llvm-13/lib/clang/13.0.1 -internal-isystem 
/usr/include -D __HIP_PLATFORM_AMD__=1 -D __HIP_PLATFORM_HCC__=1 -D NDEBUG 
-internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11 
-internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/x86_64-linux-gnu/c++/11
 -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/backward 
-internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11 
-internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/x86_64-linux-gnu/c++/11
 -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/backward 
-internal-isystem /usr/lib/llvm-13/lib/clang/13.0.1/include -internal-isystem 
/usr/local/include -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include 
-internal-externc-isystem /usr/include/x86_64-linux-gnu 
-internal-externc-isystem /include -internal-externc-isystem /usr/include 
-internal-isystem /usr/lib/llvm-13/lib/clang/13.0.1/include -internal-isystem 
/usr/local/include -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include 
-internal-externc-isystem /usr/include/x86_64-linux-gnu 
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 
-std=c++11 -fdeprecated-macro -fno-autolink -fdebug-compilation-dir=/home/cgmb 
-ferror-limit 19 -fhip-new-launch-api -fgnuc-version=4.2.1 -fcxx-exceptions 
-fexceptions -fcolor-diagnostics -vectorize-loops -vectorize-slp -mllvm 
-amdgpu-early-inline-all=true -mllvm -amdgpu-function-calls=false 
-cuid=9b98635caacf7494 -fcuda-allow-variadic-functions -faddrsig 
-D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/example-4e3c77.o -x hip example.cpp
clang -cc1 version 13.0.1 based upon LLVM 13.0.1 de

Bug#1008796: miniupnpd: compile miniupnpd also with IGD v1 only

[Yangfl]

This does not help a lot. Please, consider filling at least the
following information:
* The hardware type and software version of the clients;
* Network captures of IGD1 and IGD2 miniupnpds;
* miniupnpd log, if any.

Bug#1010466: glob2: reproducible builds: Timestamps embedded in /usr/games/glob2

[Vagrant Cascadian]

Source: glob2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded in /usr/games/glob2.

  ./usr/games/glob2

  -02:00:33
  vs.
  +02:10:15

This is because scons does not pass the SOURCE_DATE_EPOCH environment
variable by default. The attached patch fixes this by explicitly setting
this in the SConstruct file.


With this patch applied, glob2 should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining glob2!


live well,
  vagrant
From c0f9d36907677eeef270fab53ea0ce24db8b0a2e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 2 May 2022 03:15:19 +
Subject: [PATCH] SConstruct: Explicitly add SOURCE_DATE_EPOCH to the
 environment.

https://tests.reproducible-builds.org/debian/issues/scons_doesnt_pass_environment_to_build_tools_issue.html
---
 SConstruct | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/SConstruct b/SConstruct
index 37d03bb..1d17a80 100644
--- a/SConstruct
+++ b/SConstruct
@@ -241,6 +241,8 @@ def main():
 except AttributeError:
 env.Clone = env.Copy
 
+env.Append(ENV={'SOURCE_DATE_EPOCH': os.environ['SOURCE_DATE_EPOCH']})
+
 if not env['CC']:
 print("No compiler found in PATH. Please install gcc or another compiler.")
 Exit(1)
-- 
2.36.0



signature.asc
Description: PGP signature

Bug#1010465: aptly doesn't support zstd compressed packages

[Kentaro Hayashi]

Package: aptly
Version: 1.4.0+ds1-6+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: ken...@xdump.org


# Problem

aptly cannot handle Zstandard compressed control.tar.zst and data.tar.zst
within debian package.

# How to reproduce


Apply aptly repo add command which contains Zstd compressed package.


  Loading packages...
  [!] Unable to read file deb: unsupported tar compression in ...amd64.deb:
control.tar.zst
  [!] Some files were skipped due to errors:

For example, handle packages which is built on Ubuntu 22.04 causes this issue.


# Additional information

Upstream supports Zstd compression already, but not shipped yet.

  Add support for zst compression
  https://github.com/aptly-dev/aptly/pull/1050


As a workaround, use dh_builddeb -- -Zxz [1] when building package
if you can control package build process.

[1] https://raphaelhertzog.com/2010/09/17/how-to-create-debian-packages-with-
alternative-compression-methods/





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

Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (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 aptly depends on:
ii  bzip2 1.0.8-5
ii  gnupg 2.2.35-2
ii  gpgv  2.2.35-2
ii  libc6 2.33-7
ii  xz-utils  5.2.5-2.1

aptly recommends no packages.

Versions of packages aptly suggests:
ii  graphviz  2.42.2-6+b3

-- no debconf information

Bug#1010463: fceux: reproducible builds: Timestamps embedded in /usr/games/fceux

[Vagrant Cascadian]

Source: fceux
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded in /usr/games/fceux:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/fceux.html

  2021-11-21·13:43:00
  vs.
  2021-11-22·15:43:00

There is a already patch which adds support for SOURCE_DATE_EPOCH, but
the timestamps still vary dependent on timezone. The attached patch
updates the SOURCE_DATE_EPOCH patch to use the UTC timezone in the cmake
TIMESTAMP call.

With this patch applied, fceux should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining fceux!


live well,
  vagrant
From c6b223023940277a269eed92763d5a163dd09aba Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 2 May 2022 02:59:02 +
Subject: [PATCH] debian/patches: Update SOURCE_DATE_EPOCH patch to specify UTC
 timezone.

The cmake TIMESTAMP function defaults to the local timezone.

https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_cmake_issue.html
---
 debian/patches/support_SOURCE_DATE_EPOCH.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/patches/support_SOURCE_DATE_EPOCH.patch b/debian/patches/support_SOURCE_DATE_EPOCH.patch
index ee6e494..35a2939 100644
--- a/debian/patches/support_SOURCE_DATE_EPOCH.patch
+++ b/debian/patches/support_SOURCE_DATE_EPOCH.patch
@@ -8,7 +8,7 @@
 +# the FCEUX_BUILD_TIMESTAMP preprocessor definition.
 +# Note: with CMake >= 3.8.0, this will respect SOURCE_DATE_EPOCH. For more info,
 +#   see .
-+string(TIMESTAMP BUILD_TS "%Y-%m-%d %H:%M:%S")
++string(TIMESTAMP BUILD_TS "%Y-%m-%d %H:%M:%S" UTC)
 +add_definitions( -DFCEUX_BUILD_TIMESTAMP=\"${BUILD_TS}\" )
 +
  if (WIN32)
-- 
2.36.0



signature.asc
Description: PGP signature

Bug#995903:

[only drockjstone]

Bug#1010462: mtink: reproducible-builds: Embedded build path in /usr/bin/mtink

[Vagrant Cascadian]

Source: mtink
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in /usr/bin/mtink:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/mtink.html

  /build/1st/mtink-1.0.16/debian/mtink/usr/doc/mtink
  vs.
  /build/2/mtink-1.0.16/2nd/debian/mtink/usr/doc/mtink

The attached patch fixes this by passing a relative path to Configure's
prefix argument.


With this patch applied mtink should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining mtink!


live well,
  vagrant
From 7d4e9738d539925748d69861c9d25b57101a3b0f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 2 May 2022 02:23:23 +
Subject: [PATCH] debian/rules: Pass relative prefix to Configure avoid
 embedding the full build path in the binary.

https://reproducible-builds.org/docs/build-path/
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index f5c1422..6dc1e47 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,7 +34,7 @@ override_dh_auto_clean:
 	debconf-updatepo
 
 override_dh_auto_configure:
-	./Configure --no-strip --no-suid -p $(CURDIR)/debian/mtink/usr
+	./Configure --no-strip --no-suid -p debian/mtink/usr
 
 override_dh_auto_build: $(DOCBOOK_MANPAGE_SOURCES)
 	dh_auto_build
-- 
2.36.0



signature.asc
Description: PGP signature

Bug#939347: Still an issue in Debian 11 / flatpak 1.10.7

[Michael Werle]

Just installed flatpak to quickly try out an app and after purging I had
over 2GiB left in /var/lib/flatpak.

Anything which is system-installed and can be reinstalled should be purged
when a package is purged. Only user-generated content should be kept
(although there's an argument that the user should be prompted to remove
any personal settings files as well).

-- 
 - Micha

"The Glass is neither half-empty nor half-full; it is twice as big as it
needs to be!"

Bug#1010461: opensc: Workaround for build failure when using -O3

[Steve Langasek]

Package: opensc
Version: 0.22.0-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Eric,

In Ubuntu, opensc was failing to build on ppc64el because we build using -O3
by default and the compiler when running at a higher optimization level was
detecting an overflow:

[...]
/bin/bash ../../libtool  --tag=CC --tag CC  --mode=compile gcc -DHAVE_CONFIG_H 
-I. -I../..  -D'OPENSC_CONF_PATH="/etc/opensc/opensc.conf"' 
-D'DEFAULT_SM_MODULE_PATH="/usr/lib/powerpc64le-linux-gnu"' 
-D'DEFAULT_SM_MODULE="libsmm-local.so"' -I../../src -Wdate-time 
-D_FORTIFY_SOURCE=2-pthread -I/usr/include/PCSC  -Wall -Wextra 
-Wno-unused-parameter -Werror -Wstrict-aliasing=2 -g -O3 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-Wno-error=deprecated-declarations -Wno-error=maybe-uninitialized -c -o 
libopensc_la-card-starcos.lo `test -f 'card-starcos.c' || echo 
'./'`card-starcos.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. 
-DOPENSC_CONF_PATH=\"/etc/opensc/opensc.conf\" 
-DDEFAULT_SM_MODULE_PATH=\"/usr/lib/powerpc64le-linux-gnu\" 
-DDEFAULT_SM_MODULE=\"libsmm-local.so\" -I../../src -Wdate-time 
-D_FORTIFY_SOURCE=2 -pthread -I/usr/include/PCSC -Wall -Wextra 
-Wno-unused-parameter -Werror -Wstrict-aliasing=2 -g -O3 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-Wno-error=deprecated-declarations -Wno-error=maybe-uninitialized -c 
card-starcos.c  -fPIC -DPIC -o .libs/libopensc_la-card-starcos.o
[...]
In function ‘starcos_select_aid’,
inlined from ‘starcos_select_file’ at card-starcos.c:868:11:
card-starcos.c:674:39: error: writing 1 byte into a region of size 0 
[-Werror=stringop-overflow=]
  674 | file->name[i] = aid[i];
  | ~~^~~~
In file included from ../../src/libopensc/opensc.h:42,
 from asn1.h:28,
 from card-starcos.c:29:
card-starcos.c: In function ‘starcos_select_file’:
../../src/libopensc/types.h:251:23: note: at offset 16 into destination object 
‘name’ of size 16
  251 | unsigned char name[16]; /* DF name */
  |   ^~~~
[...]

  (https://launchpad.net/ubuntu/+source/opensc/0.22.0-1ubuntu1/+build/22603195)

As far as I can tell this is a spurious error because the 'len' argument
could in practice never be greater than 16, so I worked around this by
suppressing -Werror=stringop-overflow as in the attached patch.

Since Debian doesn't ever build with -O3 by default, this is definitely a
low-priority issue.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru opensc-0.22.0/debian/rules opensc-0.22.0/debian/rules
--- opensc-0.22.0/debian/rules  2022-01-31 07:02:55.0 +0100
+++ opensc-0.22.0/debian/rules  2022-05-02 03:49:53.0 +0200
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 export DEB_CFLAGS_MAINT_APPEND = -Wno-error=deprecated-declarations \
-   -Wno-error=maybe-uninitialized
+   -Wno-error=maybe-uninitialized -Wno-error=stringop-overflow
 
 %:
dh $@

Bug#1010447: ibus-typing-booster: broken shebang line in emoji-picker

[Boyuan Yang]

Hi,

在 2022-05-01星期日的 23:35 +0200，Gunnar Hjalmarsson写道：
> Thanks for your report!
> 
> I'm struggling to understand the nature of this issue.
> 
> On 2022-05-01 21:36, Frank Dietrich wrote:
> > Running `/usr/bin/emoji-picker` fails with `/usr/bin/sh: bad
> > interpreter: No such file or directory`
> 
> I can't reproduce that on my Debian testing, since I have the symlink 
> /usr/bin/sh (pointing to dash). Don't know how that symlink was created, 
> though.
> 
> Actually I noticed a Lintian complaint about wrong path for interpreter, 
> but since I had both /bin/sh and /usr/bin/sh symlinks, I boldly added 
> this override:
> 
> https://salsa.debian.org/input-method-team/ibus-typing-booster/-/commit/aeb751c3
> 
> Are you able to shed some more light on the topic?

Actually I don't understand upstream commit 40718d5. Traditionally all POSIX-
like distributions do support /bin/sh without any problem. However, given that
Debian's usrmerge problem hasn't settled yet, using /usr/bin/sh will be broken
on a non-usrmerge Debian system since /usr/bin/sh does not exist here.

On the other hand, the switch to /usr/bin/sh does not bring any benefit (If
you know _any_ benefit, please let me know), and I cannot understand why
upstream would make such destructive commit to deliberately break
compatibility. Anyway, this is now a real bug on Debian.

P.S. POSIX did not state that /bin/sh or /usr/bin/sh is guaranteed to exist.
[1] However, the traditional choice is to make sure that /bin/sh is always
available.

[1] https://pubs.opengroup.org/onlinepubs/009695399/utilities/sh.html

Thanks,
Boyuan Yang


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

Bug#1010256: ITP: rust-ahash -- non-cryptographic hash function

[James McCoy]

On Wed, Apr 27, 2022 at 04:07:43PM +0200, Jonas Smedegaard wrote:
> Quoting James McCoy (2022-04-27 15:55:34)
> > Communication is different from coordination. There was already in 
> > progress packaging.  Instead of working with us to get that accepted, 
> > you've announced that you're taking over the package and maintaining 
> > it elsewhere from the bulk of the rust packages.
> 
> Sorry for using the wrong word.
> 
> I do not recognize the picture you paint of what has happened here.
> 
> What I announced was so-called "intent to package" (not a takeover).
> 
> From my perspective, you failed to coordinate _your_ intent to package 
> which lead to this unfortunate situation of duplicate efforts.
> 
> Please in future consider filing ITPs to avoid such situations.

The Rust team files ITPs for binary crates, not the library crates, as
the binary crates are generally more relevant to the broader Debian
audience.

In terms of avoiding duplicate effort, the debcargo-conf repo _is_ that
mechansim for the Rust team. You're choosing to ignore that and package
things outside of the team's infrastructure.

The Rust team isn't unique in using a single repo for all their
packages.

It would be appreciated if you worked within the team, so the packages
can benefit from the same infrastructure, rather than going off in a
different direction and stepping on existing work.

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

Bug#1010460: transition: libavif

[Boyuan Yang]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: by...@debian.org
Severity: normal

I plan to start another libavif transition as shown in the following
transition tracker:

https://release.debian.org/transitions/html/auto-libavif.html

The new version of libavif library has bumped SONAME and needs a transition.
Reverse dependencies include kimageformats and swayimg, and I have verified
that the build would still pass with the new libavif currently in
experimental.

Example Ben file (the one currently on auto-libavif page should be ok):

title = "libavif";
is_affected = .depends ~ "libavif13" | .depends ~ "libavif14";
is_good = .depends ~ "libavif14";
is_bad = .depends ~ "libavif13";

This would be a really tiny transition, and I expect that we can finish it
very quickly with binNMUs.

Thanks,
Boyuan Yang


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

Bug#1010459: RFA: pyrlp

[Ben Finney]

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

The ‘pyrlp’ Debian package needs attention and maintenance from
someone who makes real use of the library.

-- 
 \   “To have the choice between proprietary software packages, is |
  `\  being able to choose your master. Freedom means not having a |
_o__)master.” —Richard M. Stallman, 2007-05-16 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1010458: linux/sysctl.h: unknown type name 'size_t'

[Alejandro Colomar]

Package: linux-libc-dev
Version: 5.17.3-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com


I was cleaning up the example programs in the man-pages by using
iwyu(1), when I found that  is using 'size_t'
without including any definition for it.

See the following example program:

$ cat tmp/src/man2/sysctl.2.d/sysctl.c

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 

int _sysctl(struct __sysctl_args *args );

#define OSNAMESZ 100

int
main(void)
{
struct __sysctl_args args;
char osname[OSNAMESZ];
size_t osnamelth;
int name[] = { CTL_KERN, KERN_OSTYPE };

memset(&args, 0, sizeof(args));
args.name = name;
args.nlen = sizeof(name)/sizeof(name[0]);
args.oldval = osname;
args.oldlenp = &osnamelth;

osnamelth = sizeof(osname);

if (syscall(SYS__sysctl, &args) == -1) {
perror("_sysctl");
exit(EXIT_FAILURE);
}
printf("This machine is running %*s\n", (int) osnamelth, osname);
exit(EXIT_SUCCESS);
}

for which I get the following errors:

$ cc -c -std=gnu17 -Wall -Wextra -Werror -Wno-error=unused-parameter \
 -Wno-error=sign-compare -Wno-error=format \
 -o tmp/src/man2/sysctl.2.d/sysctl.o \
 tmp/src/man2/sysctl.2.d/sysctl.c;
In file included from tmp/src/man2/sysctl.2.d/sysctl.c:3:
/usr/include/linux/sysctl.h:39:9: error: unknown type name 'size_t'
   39 | size_t *oldlenp;
  | ^~
/usr/include/linux/sysctl.h:41:9: error: unknown type name 'size_t'
   41 | size_t newlen;
  | ^~
tmp/src/man2/sysctl.2.d/sysctl.c: In function 'main':
tmp/src/man2/sysctl.2.d/sysctl.c:26:18: error: assignment to 'int *' 
from incompatible pointer type 'size_t *' {aka 'long unsigned int *'} 
[-Werror=incompatible-pointer-types]
   26 | args.oldlenp = &osnamelth;
  |  ^
cc1: all warnings being treated as errors


It seems that it's supposed to know some types, but for some reason
'size_t' is not defined by the included headers:

$ grep include 
#include 


Cheers,

Alex



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

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

-- no debconf information

Bug#1010457: ftbfs: test failure will prevent nodejs 16 migration

[Jérémy Lal]

Package: node-browserify-zlib
Version: 0.2.0+20170820git8b3f0a862f6b+dfsg-7
Severity: important
Tags: ftbfs

This module is old and uses internal nodejs api.
Also it still assumes old streams model:
it is a miracle it has not many more tests failures.

I attached a NON-working patch, to help anyone willing to give it a shot.


This is the failure:

AssertionError [ERR_ASSERTION]: after calling flush, writable stream should not 
need to drain
at process. 
(/<>/test/test-zlib-flush-drain.js:41:10)
at Object.onceWrapper (node:events:646:26)
at process.emit (node:events:526:28) {
  generatedMessage: false,
  code: 'ERR_ASSERTION',
  actual: true,
  expected: false,
  operator: '=='
}
test/test-zlib-flush-drain.js




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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 node-browserify-zlib depends on:
ii  node-pako  2.0.4+ds-1

node-browserify-zlib recommends no packages.

node-browserify-zlib suggests no packages.

-- no debconf information
--- a/src/index.js
+++ b/src/index.js
@@ -443,20 +443,19 @@
 };
 
 Zlib.prototype.flush = function(kind, callback) {
-  var ws = this._writableState;
 
   if (typeof kind === 'function' || (kind === undefined && !callback)) {
 callback = kind;
 kind = binding.Z_FULL_FLUSH;
   }
 
-  if (ws.ended) {
+  if (this.writableEnded) {
 if (callback)
   process.nextTick(callback);
-  } else if (ws.ending) {
+  } else if (this.writableFinished) {
 if (callback)
   this.once('end', callback);
-  } else if (ws.needDrain) {
+  } else if (this.writableNeedDrain) {
 if (callback) {
   this.once('drain', () => this.flush(kind, callback));
 }
@@ -489,9 +488,8 @@
 
 Zlib.prototype._transform = function(chunk, encoding, cb) {
   var flushFlag;
-  var ws = this._writableState;
-  var ending = ws.ending || ws.ended;
-  var last = ending && (!chunk || ws.length === chunk.length);
+  var ending = this.writableEnded;
+  var last = ending && (!chunk || this.writableLength === chunk.length);
 
   if (chunk !== null && !Buffer.isBuffer(chunk))
 return cb(new Error('invalid input'));
@@ -510,7 +508,7 @@
 flushFlag = this._flushFlag;
 // once we've flushed the last of the queue, stop flushing and
 // go back to the normal behavior.
-if (chunk.length >= ws.length) {
+if (chunk.length >= this.writableLength) {
   this._flushFlag = this._opts.flush || binding.Z_NO_FLUSH;
 }
   }
--- a/test/test-zlib-flush-drain.js
+++ b/test/test-zlib-flush-drain.js
@@ -3,7 +3,7 @@
 const assert = require('assert');
 const zlib = require('../');
 
-const bigData = Buffer.alloc(10240, 'x');
+const bigData = Buffer.alloc(100240, 'x');
 
 const opts = {
   level: 0,
@@ -24,12 +24,11 @@
 
 deflater.write(bigData);
 
-const ws = deflater._writableState;
-const beforeFlush = ws.needDrain;
-var afterFlush = ws.needDrain;
+const beforeFlush = deflater.writableNeedDrain;
+var afterFlush = deflater.writableNeedDrain;
 
 deflater.flush(function(err) {
-  afterFlush = ws.needDrain;
+  afterFlush = deflater.writableNeedDrain;
 });
 
 deflater.on('drain', function() {

Bug#1010441: upstream reports

[Celejar]

https://github.com/micahflee/torbrowser-launcher/pull/599
https://github.com/micahflee/torbrowser-launcher/issues/628
https://github.com/micahflee/torbrowser-launcher/issues/636

-- 
Celejar

Bug#1010447: ibus-typing-booster: broken shebang line in emoji-picker

[Gunnar Hjalmarsson]

Thanks for your report!

I'm struggling to understand the nature of this issue.

On 2022-05-01 21:36, Frank Dietrich wrote:

Running `/usr/bin/emoji-picker` fails with `/usr/bin/sh: bad
interpreter: No such file or directory`


I can't reproduce that on my Debian testing, since I have the symlink 
/usr/bin/sh (pointing to dash). Don't know how that symlink was created, 
though.


Actually I noticed a Lintian complaint about wrong path for interpreter, 
but since I had both /bin/sh and /usr/bin/sh symlinks, I boldly added 
this override:


https://salsa.debian.org/input-method-team/ibus-typing-booster/-/commit/aeb751c3

Are you able to shed some more light on the topic?

--
Cheers,
Gunnar Hjalmarsson

Bug#1010456: RM: node-buffer-shims -- ROM; useless leaf package, and abandonned upstream

[Jérémy Lal]

Package: ftp.debian.org
Severity: normal


Please remove this package.

dak rm -Rn node-buffer-shims
says it's ok.

Jérémy

Bug#1010455: Should apache2.README.Debian refer to apache-htcacheclean ?

[u34]

Source: apache2
Version: 2.4.53-2
Tags: patch
Severity: minor

Sort of a patch. Refering to 
https://salsa.debian.org/apache-team/apache2/-/blob/master/debian/apache2.README.Debian

Line 193 refers to '/etc/default/apache2'.
Shouldn't that be '/etc/default/apache-htcacheclean' ?

The context is the configuration file for using mod_cache_disk.

--
u34

Bug#1010454: docker.io: FTBFS on s390x: === FAIL: daemon/logger TestCopierWithSized (0.00s)

[Sebastian Ramacher]

Source: docker.io
Version: 20.10.14+dfsg1-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=docker.io&arch=s390x&ver=20.10.14%2Bdfsg1-1%2Bb1&stamp=1651435487&raw=0


=== SKIP: volume/local TestCreateWithOpts (0.00s)
local_test.go:182: os.Getuid() != 0: requires mounts


=== Failed
=== FAIL: daemon/logger TestCopierWithSized/With_RingLogger (0.00s)
copier_test.go:265: invalid character 'L' after object key:value pair
--- FAIL: TestCopierWithSized/With_RingLogger (0.00s)

=== FAIL: daemon/logger TestCopierWithSized (0.00s)


DONE 2203 tests, 120 skipped, 2 failures in 158.855s
make[1]: *** [debian/rules:128: override_dh_auto_test] Error 1


Cheers
-- 
Sebastian Ramacher

Bug#1010453: macaulay2: autopkgtest regularly times out on armhf

[Paul Gevers]

Source: macaulay2
Version: 1.19.1+ds-4
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky timeout

Dear maintainer(s),

I looked at the results of the autopkgtest of you package because it was 
showing up as a regression for the upload of gcc-12. I noticed that the 
test regularly fails on armhf due to a timeout (single tests time out 
after 2:47h).


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/packages/m/macaulay2/testing/armhf/

https://ci.debian.net/data/autopkgtest/testing/armhf/m/macaulay2/21279489/log.gz

Resultants
**
 -- capturing check(0, "Resultants") 
  -- 3.22647 seconds elapsed
 -- capturing check(1, "Resultants") 
  -- 0.404634 seconds elapsed
 -- capturing check(2, "Resultants") 
  -- 0.45 seconds elapsed
 -- capturing check(3, "Resultants") 
  -- 0.250109 seconds elapsed
 -- capturing check(4, "Resultants") 
  -- 1.8931 seconds elapsed
 -- capturing check(5, "Resultants") 
  -- 5.54243 seconds elapsed
 -- capturing check(6, "Resultants") 
  -- 1.13514 seconds elapsed
 -- capturing check(7, "Resultants") 
  -- 0.194144 seconds elapsed
 -- capturing check(8, "Resultants") 
  -- 1782.82 seconds elapsed
 -- capturing check(9, "Resultants") 
  -- 0.0857801 seconds elapsed
 -- capturing check(10, "Resultants") 
 autopkgtest [15:02:55]: ERROR: timed out on command "su -s 
/bin/bash debci -c set -e; export USER=`id -nu`; . /etc/profile 
>/dev/null 2>&1 || true;  . ~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest-lxc.lbtzbotc/downtmp/build.htM/src"; mkdir 
-p -m 1777 -- 
"/tmp/autopkgtest-lxc.lbtzbotc/downtmp/package-tests-artifacts"; export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.lbtzbotc/downtmp/package-tests-artifacts"; 
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest-lxc.lbtzbotc/downtmp/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.lbtzbotc/downtmp/autopkgtest_tmp"; 
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; 
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=160; unset 
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY 
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT 
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo 
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f 
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; touch 
/tmp/autopkgtest-lxc.lbtzbotc/downtmp/package-tests-stdout 
/tmp/autopkgtest-lxc.lbtzbotc/downtmp/package-tests-stderr; bash -ec 'M2 
--check 3' 2> >(tee -a 
/tmp/autopkgtest-lxc.lbtzbotc/downtmp/package-tests-stderr >&2) > >(tee 
-a /tmp/autopkgtest-lxc.lbtzbotc/downtmp/package-tests-stdout);" (kind: 
test)

autopkgtest [15:02:55]: test package-tests: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010452: gitlab-ci-multi-runner: FTBFS: test failure

[Sebastian Ramacher]

Source: gitlab-ci-multi-runner
Version: 13.3.1+dfsg-4
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

gitlab-ci-multi-runner FTBFS:

=== RUN   TestRmFile/pwsh
integration_tests.go:15: pwsh failed exec: "pwsh": executable file not 
found in $PATH
--- PASS: TestRmFile (0.01s)
--- PASS: TestRmFile/bash (0.01s)
--- SKIP: TestRmFile/cmd (0.00s)
--- SKIP: TestRmFile/powershell (0.00s)
--- SKIP: TestRmFile/pwsh (0.00s)
PASS
ok  gitlab.com/gitlab-org/gitlab-runner/shells  0.074s
?   gitlab.com/gitlab-org/gitlab-runner/shells/shellstest   [no test files]
FAIL
dh_auto_test: error: cd _build && go test -vet=off -v -p 4 -ldflags "-X 
gitlab.com/gitlab-org/gitlab-runner/common.VERSION=13.3.1 -X 
gitlab.com/gitlab-org/gitlab-runner/common.REVISION=13.3.1" 
gitlab.com/gitlab-org/gitlab-runner 
gitlab.com/gitlab-org/gitlab-runner/apps/gitlab-runner-helper 
gitlab.com/gitlab-org/gitlab-runner/cache 
gitlab.com/gitlab-org/gitlab-runner/cache/gcs 
gitlab.com/gitlab-org/gitlab-runner/cache/s3 
gitlab.com/gitlab-org/gitlab-runner/commands 
gitlab.com/gitlab-org/gitlab-runner/commands/helpers 
gitlab.com/gitlab-org/gitlab-runner/common 
gitlab.com/gitlab-org/gitlab-runner/common/buildtest 
gitlab.com/gitlab-org/gitlab-runner/executors 
gitlab.com/gitlab-org/gitlab-runner/executors/custom 
gitlab.com/gitlab-org/gitlab-runner/executors/custom/api 
gitlab.com/gitlab-org/gitlab-runner/executors/custom/command 
gitlab.com/gitlab-org/gitlab-runner/executors/docker 
gitlab.com/gitlab-org/gitlab-runner/executors/docker/internal/labels 
gitlab.com/gitlab-org/gitlab-runner/executors/docker/internal/networks 
gitlab.com/gitlab-org/gitlab-runner/executors/docker/internal/volumes 
gitlab.com/gitlab-org/gitlab-runner/executors/docker/internal/volumes/parser 
gitlab.com/gitlab-org/gitlab-runner/executors/docker/internal/volumes/permission
 gitlab.com/gitlab-org/gitlab-runner/executors/docker/internal/wait 
gitlab.com/gitlab-org/gitlab-runner/executors/docker/machine 
gitlab.com/gitlab-org/gitlab-runner/executors/parallels 
gitlab.com/gitlab-org/gitlab-runner/executors/shell 
gitlab.com/gitlab-org/gitlab-runner/executors/ssh 
gitlab.com/gitlab-org/gitlab-runner/executors/virtualbox 
gitlab.com/gitlab-org/gitlab-runner/helpers 
gitlab.com/gitlab-org/gitlab-runner/helpers/archives 
gitlab.com/gitlab-org/gitlab-runner/helpers/certificate 
gitlab.com/gitlab-org/gitlab-runner/helpers/cli 
gitlab.com/gitlab-org/gitlab-runner/helpers/container/helperimage 
gitlab.com/gitlab-org/gitlab-runner/helpers/container/services 
gitlab.com/gitlab-org/gitlab-runner/helpers/container/services/test 
gitlab.com/gitlab-org/gitlab-runner/helpers/container/windows 
gitlab.com/gitlab-org/gitlab-runner/helpers/dns 
gitlab.com/gitlab-org/gitlab-runner/helpers/dns/test 
gitlab.com/gitlab-org/gitlab-runner/helpers/docker 
gitlab.com/gitlab-org/gitlab-runner/helpers/docker/auth 
gitlab.com/gitlab-org/gitlab-runner/helpers/docker/errors 
gitlab.com/gitlab-org/gitlab-runner/helpers/docker/test 
gitlab.com/gitlab-org/gitlab-runner/helpers/featureflags 
gitlab.com/gitlab-org/gitlab-runner/helpers/gitlab_ci_yaml_parser 
gitlab.com/gitlab-org/gitlab-runner/helpers/parallels 
gitlab.com/gitlab-org/gitlab-runner/helpers/path 
gitlab.com/gitlab-org/gitlab-runner/helpers/process 
gitlab.com/gitlab-org/gitlab-runner/helpers/prometheus 
gitlab.com/gitlab-org/gitlab-runner/helpers/retry 
gitlab.com/gitlab-org/gitlab-runner/helpers/sentry 
gitlab.com/gitlab-org/gitlab-runner/helpers/service 
gitlab.com/gitlab-org/gitlab-runner/helpers/service/mocks 
gitlab.com/gitlab-org/gitlab-runner/helpers/ssh 
gitlab.com/gitlab-org/gitlab-runner/helpers/test 
gitlab.com/gitlab-org/gitlab-runner/helpers/timeperiod 
gitlab.com/gitlab-org/gitlab-runner/helpers/tls 
gitlab.com/gitlab-org/gitlab-runner/helpers/tls/ca_chain 
gitlab.com/gitlab-org/gitlab-runner/helpers/trace 
gitlab.com/gitlab-org/gitlab-runner/helpers/url 
gitlab.com/gitlab-org/gitlab-runner/helpers/virtualbox 
gitlab.com/gitlab-org/gitlab-runner/log 
gitlab.com/gitlab-org/gitlab-runner/log/test 
gitlab.com/gitlab-org/gitlab-runner/network 
gitlab.com/gitlab-org/gitlab-runner/referees 
gitlab.com/gitlab-org/gitlab-runner/session 
gitlab.com/gitlab-org/gitlab-runner/session/proxy 
gitlab.com/gitlab-org/gitlab-runner/session/terminal 
gitlab.com/gitlab-org/gitlab-runner/shells 
gitlab.com/gitlab-org/gitlab-runner/shells/shellstest returned exit code 1
make[1]: *** [debian/rules:54: override_dh_auto_test] Error 25


See
https://buildd.debian.org/status/fetch.php?pkg=gitlab-ci-multi-runner&arch=amd64&ver=13.3.1%2Bdfsg-4%2Bb7&stamp=1651436612&raw=0

Cheers
-- 
Sebastian Ramacher

Bug#1010451: gdb-avr: Missing build dependency on libgmp-dev

[Adrian Bunk]

Source: gdb-avr
Version: 7.7-5
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=gdb-avr&ver=7.7-5%2Bb1

...
checking for libgmp... no
configure: error: GMP is missing or unusable
make[1]: *** [Makefile:9783: configure-gdb] Error 1
make[1]: Leaving directory '/<>/build'
make: *** [debian/rules:46: configure-stamp] Error 2

Bug#1010450: Problems with theme HighContrast in Debian 11.2 и 11.3 64-bits Xfce 4.16 DoubleCmd 1.0.5

[Сергей Фёдоров]

Package: hicolor-icon-theme
Version: 0.17-2
Severity: normal
X-Debbugs-Cc: serfyo...@yandex.ru

Dear Maintainer,

In Debian 11.2 and 11.3 64-bits Xfce 4.16, under the login of a "regular user"
, I encountered a strange thing: when running DoubleCommander with
xfce4-settings selected ("Applications→Settings→Appearance") linux-theme
"HighContrast (hicolor)" in black letters on a black background (i.e. nothing
is visible), the "Disk button panel" areas are displayed (only disk labels,
icons are normal, the hint field is normal), the "Disk List" area (only
disk labels, icons are normal, the hint field is normal), the "Status bar"
at the bottom of the left or right frame, "Directory path of the active panel"
to the left of the command line, the bottom line is the "Function Key bar"
and in some windows (not all). I haven't noticed anything in other applications
yet.

Under login "root" everything is displayed normally.

Under the login of the "ordinary user" I chose the theme "Adwaita" and
everything began to be displayed in DC normally, only in the upper and lower
panels the background became dark in Desktop Xfce.

Installed Debian 10.12.0. Installed DoubleCommander. Launched it. Everything
is displayed normally.

There is clearly a problem with the HighContrast theme in Debian 11.2 and 11.3.

Platform: x86_64-Linux-gtk2
Widgetset library: GTK 2.24.33

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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

-- no debconf information

Bug#993370: RFP: rg-el -- elpa-rg

[Nicholas D Steeves]

Control: retitle -1 RFP: rg-el -- elpa-rg
Control: noowner -1

It doesn't look like #997974 is going to be solved anytime soon, so I'm
converting this bug to an RFP to signal that anyone who wants to work on
this bug, and to pursue resolution of #997974 is welcome to do so.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1010448: firmware-misc-nonfree: Please backport: nvidia: fix symlinks for tu104/tu106 acr unload firmware

[Brian Silverman]

Package: firmware-misc-nonfree
Version: 20210315-3
Severity: normal
Tags: patch

Dear Maintainer,

Could you please backport this upstream fix:
f8462923ed8 "nvidia: fix symlinks for tu104/tu106 acr unload firmware"

I'm using nouveau with a GPU that uses the tu106 firmware. Before this
fix, suspend does not work (computer restarts immediately). After
changing the symlinks like this patch, it suspends successfully.
Resuming still doesn't work due to a separate problem.

Bug#1005256: nvidia-settings-tesla-470 470.103.01-1~deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-settings-tesla-470
Version: 470.103.01-1~deb11u1

Explanation: new package, switching Tesla support to upstream 470 tree

Bug#1005252: nvidia-settings 470.103.01-1~deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-settings
Version: 470.103.01-1~deb11u1

Explanation: new upstream release; switch to upstream 470 tree

Bug#1005237: nvidia-persistenced 470.103.01-2~deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-persistenced
Version: 470.103.01-2~deb11u1

Explanation: new upstream release; switch to upstream 470 tree

Bug#1005231: nvidia-xconfig 470.103.01-1~deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-xconfig
Version: 470.103.01-1~deb11u1

Explanation: new upstream release

Bug#1005135: nvidia-graphics-drivers-tesla-470 470.103.01-2~deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers-tesla-470
Version: 470.103.01-2~deb11u1

Explanation: new package, switching Tesla support to upstream 470 tree

Bug#1005129: nvidia-graphics-drivers 470.103.01-3~deb11u2 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers
Version: 470.103.01-3~deb11u2

Explanation: new upstream release; switch to upstream 470 tree; fix denial of 
service issues [CVE-2022-21813 CVE-2022-21814]

Bug#1005129: nvidia-graphics-drivers 470.103.01-3~deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers
Version: 470.103.01-3~deb11u1

Explanation: new upstream release; switch to upstream 470 tree; fix denial of 
service issues [CVE-2022-21813 CVE-2022-21814]

Bug#1010276: parasail: compiles something extra (or less) depending on the CPU features available

[Andreas Tille]

Am Sun, May 01, 2022 at 01:27:39PM +0200 schrieb Étienne Mollier:
> Thank you for the clarification.  In any case, I believe the mv
> makes a random static library disappear, so I'll replace by cp.
> This is looking like a safe maneuver.

Uh, that's actually true and should for sure have been a cp. :-(
 
> I'm sorting all three issues then.

As always, thanks a lot

 Andreas.


-- 
http://fam-tille.de

Bug#1009219: Please import upstream version 2.5

[Nicholas D Steeves]

Hi David,

I suspect the failing test in markdown-mode 2.5
(test-markdown-ext/wiki-link-search-under-project) is failing for a
similar reasons to why 'ffip-test-relative-path-commands' was failing in
find-file-in-project from 6.0.7 to a minimum of 1d2f0b3.  The nature of
the problem appears to be an upstream bug, and in find-file-in-project's
case, the bug was fixed between 1d2f0b3 and 6.2.0.  My hypothesis is
that upstream makes a normally-valid assumption about path handling that
breaks on sbuild and buildds.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1010447: ibus-typing-booster: broken shebang line in emoji-picker

[Frank Dietrich]

Package: ibus-typing-booster
Version: 2.15.25-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: frank.dietr...@gmx.li

Dear Maintainer,

   * What led up to the situation?

The shebang line in emoji-picker refers to /usr/bin/sh which does not point to
a Shell in Debian.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

Running `/usr/bin/emoji-picker` fails with `/usr/bin/sh: bad interpreter: No
such file or directory`
Running it as `sh /usr/bin/emoji-picker` starts the emoji picker.

   * What outcome did you expect instead?

The emoji picker should start by calling the executable script.

In the upstream repository this commit lead to the in Debian broken executable.

https://github.com/mike-fabian/ibus-typing-
booster/commit/40718d53e02cd412940b1fd4086e4eb910baf6cb

The shebang was changed there from `/bin/sh` to `/usr/bin/sh`.

cheers
Frank



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

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

Versions of packages ibus-typing-booster depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  ibus 1.5.26-4
ii  libm17n-01.8.0-4
ii  m17n-db  1.8.0-3
ii  python3  3.10.4-1
ii  python3-dbus 1.2.18-3+b1
ii  python3-enchant  3.2.2-1
ii  python3-packaging21.3-1
ii  python3-xdg  0.27-2

ibus-typing-booster recommends no packages.

ibus-typing-booster suggests no packages.

-- no debconf information

Bug#1010446: nodejs 14.19 hangs on mipsel/mips64el when building qtwebengine frontend with rollup and terser plugin

[Dmitry Shachnev]

Package: nodejs
Version: 16.13.2+really14.19.1~dfsg-6
Severity: serious
Control: fixed -1 nodejs/16.14.2+dfsg-1
Affects: src:qtwebengine-opensource-src

Dear nodejs maintainers,

Currently qtwebengine-opensource-src FTBFS on mipsel and mips64el:
https://buildd.debian.org/status/logs.php?pkg=qtwebengine-opensource-src&ver=5.15.8%2Bdfsg-1%2Bb2&arch=mips64el

This started happening after nodejs was upgraded from 12.22 to 14.19, and it
does not happen with 16.14 from experimental.

Here are the steps to reproduce this bug (qtwebengine is huge, I tried to
make the test case smaller):

# apt install nodejs rollup node-rollup-plugin-terser
$ wget https://mitya57.me/nodejs/front_end.tar.xz
$ tar xJf front_end.tar.xz
$ cd front_end
$ nodejs /usr/bin/rollup --plugin terser --config rollup.config.js --input 
timeline_model/timeline_model.prebundle.js

On eller porter box, with nodejs 16.14 this command succeeds in ~11 seconds.
With nodejs 14.19, it hangs and does not finish in an hour. With 16.14 it
prints a warning about circular dependency, but it's just a warning, not an
error (the build still succeeds).

I see there is a transition to new nodejs planned (#1010438), but I am still
filing this bug for documentation purposes and with RC severity, as requested
by Sebastian Ramacher.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1009739: python3.10 breaks yade autopkgtest on i386: Segmentation fault

[Matthias Klose]

Control: reassign -1 src:yade

yade was removed from testing, and also is not installable on i386. Reassigning 
until we can investigate if that's a Python issue.

Bug#1009041: guile-git: FTBFS with libgit2 1.3.0

[Vagrant Cascadian]

Control: forwarded 1009041 https://gitlab.com/guile-git/guile-git/-/issues/23

On 2022-04-06, Mohammed Bilal wrote:
> guile-git was found to fail to build during a test rebuild with
> libgit2 1.3.0 in unstable. Attaching the build logs as well.
>
> Relevant part(hopefully) :
>
> FAIL: tests/proxy
> =
>
> test-name: clone with HTTPS proxy
> location: /<>/tests/proxy.scm:95
> source:
> + (test-equal
> +   "clone with HTTPS proxy"
> +   '(CONNECT "example.org:443")
> +   (clone-through-proxy
> + "https://example.org/example.git";))
> expected-value: (CONNECT "example.org:443")
> actual-value: #f
> actual-error:
> + (match-error "match" "no matching pattern" #f)
> result: FAIL

There is a bug report and merge request upstream that fixes this issue:

  https://gitlab.com/guile-git/guile-git/-/issues/23
  https://gitlab.com/guile-git/guile-git/-/merge_requests/32

And I can confirm they fix the issue in Debian's packaging as well.

Will upload a fix shortly.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1005807: smokeping: postrm complain about ucf and ucfr not found (piuparts)

[Gabriel Filion]

On Tue, 15 Feb 2022 14:56:22 +0100 Petter Reinholdtsen  
wrote:

I came across this in
https://piuparts.debian.org/sid/pass/smokeping_2.7.3-3.log >

  Purging configuration files for smokeping (2.7.3-3) ...
  /var/lib/dpkg/info/smokeping.postrm: 32: ucf: not found



Look like something should be made more robust in the postrm script.


Thanks for mentioning this!

It is apparently still happening in

https://piuparts.debian.org/sid/pass/smokeping_2.7.3-4.log

and I believe that it's caused by the fact that ucf is getting removed 
and purged before the purging of smokeping happens.


I'm not so sure why ucf is used directly like this.. I'll have to ask 
for help with this one.

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

[Helge Kreutzmann]

Hello Jesse,
On Wed, Apr 27, 2022 at 01:58:14PM -0300, Jesse Smith wrote:
> 
> > I'm not a makefile expert, but I have some experience with po4a and
> > firends (in makefiles). I'll contact Jesse and see what I (or maybe
> > Mario, who supported the transfer) can do.
> > 
> 
> 
> As the upstream person in this situation, I'm happy to accept patches or
> suggestions. A little while back I received the beginnings of the
> translation process (the framework) and dropped it into the upstream
> source tree sort of "as is". At the time it looked like there might be
> more pieces coming in the future, so I left it alone.
> 
> If anyone wants to improve upon the translation framework and/or send me
> patches, I'll be happy to receive them.

The attached Makefile for man/ does not yet work, but I think it's just my
limited man page knowledge.

For some reason I'm not seeing the solution for "make clean", probably
some typo.

I added a new target to actually create the translated man pages. For
testing, I inserted a dummy version, please remove.

What I'm not so sure is how to best call "translated", probably as a
dependency for "all install"? 

You can of course integrate it in the target "all install", that would
be the easiest solution.

I suggest you use this Makefile as an input and then we work from
there.

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
MANPAGES=bootlogd.8 fstab-decode.8 halt.8 init.8 initctl.5 initscript.5 
inittab.5 \
killall5.8 last.1 lastb.1 logsave.8 mesg.1 mountpoint.1 pidof.8 poweroff.8 \
readbootlog.1 reboot.8 runlevel.8 shutdown.8 sulogin.8 telinit.8 utmpdump.1 \
wall.1

LANGUAGES_DIST =`sed -ne 's/^.*\[po4a_langs\] \(.*\)$/\1/p' po/po4a.cfg`
#LANGUAGES_DIST = $(sed -ne 's/^.*\[po4a_langs\] \(.*\)$/\1/p' po/po4a.cfg)
LANGUAGES=$(LANGUAGES_DIST)
LANGUAGES="de es fi fr hu id pl"

VERSION=1.2.3

PO4A_OPTS = --previous --srcdir po/ --destdir po/ --no-backups \
--package-name sysvinit --package-version $(VERSION) \
--msgid-bugs-address "Your Bugmail "

translated:
po4a $(PO4A_OPTS) po/po4a.cfg

all install: 
sed --in-place=.orig --separate 's/\@VERSION\@/$(VERSION)/g' $(MANPAGES)

clean distclean:
for man in $(MANPAGES) ; do \
   if [ -f "$$man.orig" ] ; then mv "$$man.orig" "$$man" ; fi \
done  
echo $(LANGUAGES) 
for lang in $(LANGUAGES); do \
rm -rf "po/$$lang" \
done



signature.asc
Description: PGP signature

Bug#1010420: Acknowledgement (firefox: 100% CPU load on one core with some pipe activity)

[Sylvestre Ledru]

Le 01/05/2022 à 18:51, Eduard Bloch a écrit :

Hallo,

and it gets worse. Playing a YT video (720p) consumes about 300% CPU
power and laptop running hot.

Doing the same with Chromium causes about 30% load, that's an order of
magnitude!

NOTE: this cannot be attributed to Video HW accelleration, I have
enabled that in FF long time ago, following
https://askubuntu.com/questions/1291279/ubuntu-20-10-firefox-82-intel-hd-500-vaapi-hardware-acceleration
 and
https://ubuntuhandbook.org/index.php/2021/08/enable-hardware-video-acceleration-va-api-for-firefox-in-ubuntu-20-04-18-04-higher/
 .

And it has been working well for months. The obvious reason would be the
FF update.


Seems that you have a lot extensions, did you try to disable some of them?



Basically, this version is garbage.


Thanks for the nice and constructive message.

Cheers

S

Bug#1009888: [Pkg-rust-maintainers] Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package

[Peter Michael Green]

On 01/05/2022 14:00, Fabian Grünbichler wrote:

currently progress is blocked on
- itoa/serde_json transition (anybody working actively on that?)


I just uploaded the new itoa to experimental and took a quick look 
through the reverse dependencies.


rust-cssparser - already broken and not in testing.
rust-csv - built/tested fine after patching to use itoa 1, upstream also 
has an unreleased change switching to itoa1 with no code changes.
rust-http - fixed version in debcargo-conf (semver breaking, but all 
rdeps are broken right now anyway)

rust-hyper - already broken and not in testing.
rust-num-format - already broken and not in testing.
rust-serde-json - fixed version in debcargo-conf (not semver breaking)
rust-serde-urlencoded - fixed upstream (semver breaking, but all rdeps 
are broken right now anyway)

rust-time - fixed upstream (not semver breaking)

I'm not seeing any reason not to go ahead with pushing this to unstable, 
anyone have any comments before I go ahead?

Bug#1009033: python-pygit2: FTBFS with libgit2 1.3.0

[Timo Röhling]

* Mohd Bilal  [2022-05-01 22:33]:
We're driving this transition since gitlab wanted this version. If you 
require 1.4.x you're free to collaborate and work on the transition. 
I'll try working on updating to the latest version once we get 1.3 to 
testing. So it would be helpful if you could update pygit to 1.8.0 
since it supports the current version (1.3.0) . I know its extra work 
updating the package twice. This is my first time working on a 
transition (I intend to be a co-maintainer for this package and am 
currently learning the process of how a transition works ). So I 
intend to go through it step by step. I'll definitely do the task of 
updating libgit2 to 1.4.3 once this transition is done.

No problem, we can do it this way if it helps you learn the transition
process. I'll upload pygit2 1.8.0 to experimental first and wait for
your signal to upload to unstable once the transition is
greenlighted by the release team.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#989354: smokeping: Classical initscript (Sysvinit) fails to stop daemon

[Gabriel Filion]

On Thu, 3 Jun 2021 13:58:36 -0400 Gabriel Filion  
wrote:
I've committed your change to salsa and it should make it to the next 
upload.


woops! I apparently forgot to add a changelog entry about this fix with 
the Closes mention.


The fix was sent to unstable last week with 2.7.3-4. I'll wait for it to 
migrate to testing before checking if I can get that pushed to stable.


So I'll close the bug report manually now.

Bug#1010420: Acknowledgement (firefox: 100% CPU load on one core with some pipe activity)

[Eduard Bloch]

Hallo,

and it gets worse. Playing a YT video (720p) consumes about 300% CPU
power and laptop running hot.

Doing the same with Chromium causes about 30% load, that's an order of
magnitude!

NOTE: this cannot be attributed to Video HW accelleration, I have
enabled that in FF long time ago, following
https://askubuntu.com/questions/1291279/ubuntu-20-10-firefox-82-intel-hd-500-vaapi-hardware-acceleration
 and
https://ubuntuhandbook.org/index.php/2021/08/enable-hardware-video-acceleration-va-api-for-firefox-in-ubuntu-20-04-18-04-higher/
 .

And it has been working well for months. The obvious reason would be the
FF update. Basically, this version is garbage.

Best regards,
Eduard.

--
 formorer: Ein Editor, der das Tastenkürzel ctrl-alt-del als mögliche
Befehlskombination für wahrscheinlich erscheinen lässt, ist einfach nur
krank.

Bug#951232: smokeping: document apache setup

[Gabriel Filion]

Hello,

I'm sorry for the time it took for me to respond to your report. The 
start of the pandemic transformed me into a useless puddle of stress :S


On Wed, 12 Feb 2020 14:08:46 -0800 Matt Taggart  wrote:
> Maybe these things could be made into a README.apache that could be
> included. It could start with

That sounds like a good idea :)

And if you're up for it we could work out the document's wording via a 
merge request on:


https://salsa.debian.org/debian/smokeping



> In addition to that, here are some things I had to do:
>
> * install alias module so that ScriptAlias and Alias work
> * setup SSL with letsencrypt
>- install the ssl module, and also the mime module since ssl uses
>AddType and socache_shmcb module
>- if you are doing this and using the webserver itself to provide
> proof of controlling the host you might need to exclude the
> .well-known dir with something like:
>   RedirectMatch ^/(?!.well-known.*)$
> https://example.com/smokeping/smokeping.cgi
> * install authz_core module since "Require all granted" is used

things currently "just work" with the smokeping package on a fresh 
install, but I guess that's just because the alias, authz_core and ssl 
modules are enabled by default.
it would be good to document them as requirements for running smokeping 
with apache.


> * I also password protected mine which required: auth_basic,
> authn_core, authn_file

The redirect for .well-known above and the password protection sound 
more like peripheral additions. They could be mentioned in the document 
with fewer words, just to mention that one might want/need to think 
about those aspects


> The important thing is, to have a webserver which allows you to run
> CGI and preferably FastCGI scripts. If you are using Apache I
> strongly recommend using the suexec system for running CGI scripts as
> a particular user.
>
> It would be nice to document how to do this and maybe switch the
> conf-available to use that method.

The thing is I don't think this package should start imposing enabled 
modules, let alone an mpm on an apache setup.


Already, the fact that the package installs and enables a global apache 
configuration has the tendency to raise eyebrows with some other package 
maintainers -- it's not the currently agreed upon best practice for a 
package shipping a web application; usually the httpd configuration is 
left to the admin of that box since setups can vary widely.


So in that sense I don't think we can switch the default apache config 
file to using suexec since it would require to enable another apache module.


But it would be great to document how to achieve this!

* install mpm_prefork and cgi modules (is there a way to use event or 
worker?)


that's a pretty valid question since e.g. I believe mpm_event is 
required in order to enable http2.


There's a good amount of documentation out there about how to setup 
php-fpm with mpm_event and mod_fcgid -- our setup here should possibly 
look similar to those. I just wonder if we can keep the same kind of 
setup without an external fcgid wrapper.. we'll have to experiment a bit 
here.



https://oss.oetiker.ch/smokeping/doc/smokeping_install.en.html


we should probably include that URL in the document's preamble for 
context, but also to mention that upstream doesn't have much info about 
the apache setup for smokeping, thus the reason for the existance of the 
document.


"The smokeping package includes an apache config at 
/etc/apache2/conf-available/smokeping.conf that is enabled by default." 
and the talk about the needed modules and maybe how to a2disconf it and 
Include it in another conf instead, etc.


yes that's an interesting tidbit. not everyone will want the /smokeping 
URL to become visible on all of their vhosts (which is another 
eyebrow-raising point wrt enabling a global apache configuration for a 
webapp)



I've actually been wondering if the smokeping package should take a step 
back with regards to automatically enabling the apache configuration 
file. The current "just works" method is OK for sampling the webapp but 
it doesn't work in all environments.
It would make more sense in an httpd-agnostic package to let admin set 
things up by themselves maybe by copying a sample vhost from examples, 
but current users of the package are used to how things have been for 
many years.. So I don't think I'm ready to take it out just yet, but it 
might come at some point.


Cheers

Bug#1010444: py-moneyed: Please update package

[Andreas Noteng]

Source: py-moneyed
Version: 0.8.0-2
Severity: normal

Dear Maintainer,

A new upstream version 2.0 is available. Merge requests have been made 
in the packaging VCS. Please consider updating the package to the latest 
upstream source.


Sincerely,
Andreas Noteng



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010443: py-moneyed: Invalid maintainer email address

[Andreas Noteng]

Source: py-moneyed
Version: 0.8.0-2
Severity: normal

Dear Maintainer,

The maintainer email address stated in py-moneyed Maintainer: field
seems to be invalid and is beeing bounced with an account does not exist
message.

Sincerely,
Andreas Noteng



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010432: debian-edu-config: autopkgtest regression: update-mime: not found

[Wolfgang Schweer]

[ Paul Gevers, 2022-05-01 ]
> It seems that with the fix for bug #1010102 you either picked the 
> wrong Depends of two, or you forgot to update the postinst for the 
> change as update-mime lives in mailcap.

AFAICT calling update-mime in d-e-c.postinst is unneeded since the 
obsolete debian-edu-mailcap file has been removed, see commit 2aaa1adf:
https://salsa.debian.org/debian-edu/debian-edu-config/-/commit/2aaa1adfac0f1ea63520bd884c2c48c674b51e3c
and commit 24f26f25:
https://salsa.debian.org/debian-edu/debian-edu-config/-/commit/24f26f2552cdc62e5b580cac4d7e40a6f973c326

The update-mime call should be removed from the postinst script.

The Depends on mime-support had been added in 2004 due to moving the 
mailcap file and calling update-mime in d-e-c.postinst, see commit 
91550cf1:
https://salsa.debian.org/debian-edu/debian-edu-config/-/commit/91550cf1d35774f10cc9989f16038eeabf95e86b

IMO d-e-config neither needs media-types nor mailcap as dependencies, 
please check.

Wolfgang


signature.asc
Description: PGP signature

Bug#1009934: openssl: reproducible-builds: Embeded compiler flags contain build paths

[Vagrant Cascadian]

On 2022-05-01, Sebastian Andrzej Siewior wrote:
> control: forwarded -1 https://github.com/openssl/openssl/pull/11545
>
> On 2022-04-20 15:46:41 [-0700], Vagrant Cascadian wrote:
>> The compiler flags usually contain the build path on Debian package
>> builds, and openssl embeds the compiler flags used in various binaries:
> …
>> Unfortunately, there are other outstanding issues affecting the
>> reproducibility of openssl, but applying this patch should reduce the
>> differences, making it easier to debug the remaining issues.
>
> so this report looked awkwardly familiar. The pull request
>   https://github.com/openssl/openssl/pull/11545
>
> should work for you, right?

That looks great, glad it is in progress!

It should be updated to also handle -fmacro-prefix-map and
-ffile-prefix-map (basically combining both -fmacro-prefix-map and
-fdebug-prefix-map), which were more recently added to various
compilers.

Fairly recently -ffile-prefix-map became the default dpkg-buildflags.

I'll comment on the pull request...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1010442: ovn: ftbfs on riscv64

[Bo YU]

Source: ovn
Version: 21.06.0+ds1-2
Severity: normal
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

the ovn has a ftbfs issue on riscv64 arch:

```
===
## - ##
## Test results. ##
## - ##

ERROR: 554 tests were run,
5 failed unexpectedly.
410 tests were skipped.
## -- ##
## testsuite.log was created. ##
## -- ##

Please send `tests/testsuite.log' and all information you think might help:

To: 
Subject: [ovn 21.06.0] testsuite: 255 256 371 372 623 failed

You may investigate any problem if you feel able to do so, in which
case the test suite provides a good starting point.  Its output may
be found below `tests/testsuite.dir'.

make[4]: *** [Makefile:3436: check-local] Error 1
make[4]: Leaving directory '/<>'
make[3]: *** [Makefile:2732: check-am] Error 2
make[3]: Leaving directory '/<>'
make[2]: *** [Makefile:2734: check] Error 2
make[2]: Leaving directory '/<>'
make[2]: Entering directory '/<>'
/usr/bin/make  check-am
make[3]: Entering directory '/<>'
...
OVN end-to-end tests

255: ovn -- 1 LR with distributed router gateway port -- ovn-northd -- 
dp-groups=yes FAILED (ovn.at:10659)
256: ovn -- 1 LR with distributed router gateway port -- ovn-northd -- 
dp-groups=no FAILED (ovn.at:10659)
371: ovn -- router - check packet length - icmp defrag -- ovn-northd -- 
dp-groups=yes ok
ovn -- router - check packet length - icmp defrag -- ovn-northd -- 
dp-groups=yes FAILED (ovs-macros.at:255)
372: ovn -- router - check packet length - icmp defrag -- ovn-northd -- 
dp-groups=no ok
623: ovn -- ACL with Port Group conjunction flow efficiency -- ovn-northd -- 
dp-groups=yes ok
```

The full buildd log is:
https://buildd.debian.org/status/fetch.php?pkg=ovn&arch=riscv64&ver=21.06.0%2Bds1-2&stamp=1635347289&raw=0

The patch i have tested it on locally and it is ok. If you need me to do
more test on riscv64 real hardware please tell me.

BR,
Bo
fix ftbfs issue on riscv64

Bo YU 
--- a/debian/rules
+++ b/debian/rules
@@ -44,6 +44,16 @@
 TEST_LIST = 1-167 169-390 393-
 endif # arm64,armhf
 
+# riscv64:
+# 255: ovn -- 1 LR with distributed router gateway port -- ovn-northd -- 
dp-groups=yes FAILED (ovn.at:10659)
+# 256: ovn -- 1 LR with distributed router gateway port -- ovn-northd -- 
dp-groups=no FAILED (ovn.at:10659)
+# 371: ovn -- router - check packet length - icmp defrag -- ovn-northd -- 
dp-groups=yes FAILED (ovs-macros.at:255)
+# 372: ovn -- router - check packet length - icmp defrag -- ovn-northd -- 
dp-groups=no FAILED (ovs-macros.at:255)
+# 623: ovn -- ACL with Port Group conjunction flow efficiency -- ovn-northd -- 
dp-groups=yes FAILED (ovn.at:26583)
+ifneq (,$(filter riscv64, $(DEB_HOST_ARCH)))
+TEST_LIST = 1-254 257-370 373-622 624-
+endif # riscv64
+
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
if $(MAKE) check TESTSUITEFLAGS='$(PARALLEL) $(TEST_LIST)' || \

Bug#1010441: torbrowser-launcher fails to download browser bundle when launched for the first time

[Paul Garret]

Package: torbrowser-launcher
Version: 0.3.5-2
Severity: important
X-Debbugs-Cc: p...@cock.li

Dear Maintainer,

Current version of torbrowser-launcher in Sid fails to download tor browser 
when launched for the first time (ie when ~/.local/share/torbrowser/tbb/ does 
not exist) with the following error:

Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.3.5
https://github.com/micahflee/torbrowser-launcher
Downloading Tor Browser for the first time.
Downloading 
https://aus1.torproject.org/torbrowser/update_3/release/Linux_x86_64-gcc3/x/en-US
Traceback (most recent call last):
  File "/usr/bin/torbrowser-launcher", line 30, in 
torbrowser_launcher.main()
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/__init__.py", line 
98, in main
gui.move(
TypeError: arguments did not match any overloaded call:
  move(self, QPoint): argument 1 has unexpected type 'float'
  move(self, int, int): argument 1 has unexpected type 'float'


Changing both arguments to int works to the following workaround may be
used:

--- /usr/lib/python3/dist-packages/torbrowser_launcher/__init__.py.orig 
2022-05-01 17:44:35.369210869 +0200
+++ /usr/lib/python3/dist-packages/torbrowser_launcher/__init__.py  
2022-05-01 17:45:16.697352319 +0200
@@ -96,8 +96,8 @@
 desktop = app.desktop()
 window_size = gui.size()
 gui.move(
-(desktop.width() - window_size.width()) / 2,
-(desktop.height() - window_size.height()) / 2
+int((desktop.width() - window_size.width()) / 2),
+int((desktop.height() - window_size.height()) / 2)
 )
 gui.show()
 sys.exit(app.exec_())




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

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates20211016
ii  gnupg  2.2.35-2
ii  libdbus-glib-1-2   0.112-2
ii  python33.10.4-1
ii  python3-gpg1.16.0-1.2
ii  python3-packaging  21.3-1
ii  python3-pyqt5  5.15.6+dfsg-1+b2
ii  python3-requests   2.27.1+dfsg-1
ii  python3-socks  1.7.1+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.4.7.7-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  3.0.4-2

-- no debconf information

Bug#1010164: fails autopkgtest against Octave 7

[Uecker, Martin]

On Mon, 25 Apr 2022 17:23:25 +0200 =?utf-8?q?S=C3=A9bastien_Villemot?= 
 wrote:
> Package: octave-bart
> Version: 0.7.00-2
> Severity: serious
> Tags: patch
> Control: block 1009865 by -1
> 
> Dear Maintainer,
> 
> The autopkgtest for octave-bart fails against octave 7.1.0-2 recently uploaded
> to unstable. See:
> https://ci.debian.net/data/autopkgtest/testing/amd64/b/bart/21135046/log.gz
> 
> The problem comes from a message that is printed to stderr:
> 
>   error: ignoring const execution_exception& while preparing to exit
> 
> This message only appears when running the autopkgtest in a dedicated chroot 
> as
> done on the DebCI infrastructure. I wasn’t able to reproduce it in other
> contexts, and I could not figure out what causes it.
> 
> Since this message is essentially harmless, and given that the test passes
> otherwise, I would suggest to simply add the “allow-stderr” keyword to
> “Restrictions” in the octave-integration stanza of debian/tests/control.

I am happy to do this if this is necessary, but isn't this
obviously caused by a bug in octave?

Martin

Bug#1010439: bullseye-pu: package node-sqlite3/5.0.0+ds1-1+deb11u1

[Yadd]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
node-sqlite3 is vulnerable to denian of service (CVE-2022-21227)

[ Impact ]
Medium security issue

[ Tests ]
New test added, passed

[ Risks ]
Low risk, patch is trivial

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

[ Changes ]
Check bad arguments

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 32c6f70..88403c9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-sqlite3 (5.0.0+ds1-1+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+  * Fix denial-of-service (Closes: CVE-2022-21227)
+
+ -- Yadd   Sun, 01 May 2022 17:33:33 +0200
+
 node-sqlite3 (5.0.0+ds1-1) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2022-21227.patch 
b/debian/patches/CVE-2022-21227.patch
new file mode 100644
index 000..e95c94d
--- /dev/null
+++ b/debian/patches/CVE-2022-21227.patch
@@ -0,0 +1,41 @@
+Description: fix segfault of invalid toString() object
+Author: Kewde 
+Origin: upstream, https://github.com/TryGhost/node-sqlite3/commit/593c9d49
+Bug: https://github.com/advisories/GHSA-9qrh-qjmc-5w2p
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-05-01
+
+--- a/src/statement.cc
 b/src/statement.cc
+@@ -210,7 +210,13 @@
+ return new Values::Float(pos, source.ToNumber().DoubleValue());
+ }
+ else if (source.IsObject()) {
+-std::string val = source.ToString().Utf8Value();
++Napi::String napiVal = source.ToString();
++// Check whether toString returned a value that is not undefined.
++if(napiVal.Type() == 0) {
++return NULL;
++}
++
++std::string val = napiVal.Utf8Value();
+ return new Values::Text(pos, val.length(), val.c_str());
+ }
+ else {
+--- a/test/other_objects.test.js
 b/test/other_objects.test.js
+@@ -86,4 +86,13 @@
+ });
+ });
+ });
++
++it('should ignore faulty toString', function(done) {
++const faulty = { toString: 23 };
++db.run("INSERT INTO txt_table VALUES(?)", faulty, function (err) {
++assert.notEqual(err, undefined);
++done();
++});
++});
++
+ });
diff --git a/debian/patches/series b/debian/patches/series
index 327413f..8d03fa0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 disable-hard-test.patch
+CVE-2022-21227.patch

Bug#1010440: RM: node-fs-vacuum -- ROM; useless leaf package, and abandonned upstream.

[Jérémy Lal]

Package: ftp.debian.org
Severity: normal


Hi,

Please remove that package (acked by latest maintainer).

Nothing reported by
dak rm -Rn node-fs-vacuum

Jérémy

Bug#924667: qemu-user-static: setting up of binfmt_misc is slightly naive about cpu features

[Michael Tokarev]

Control: tag -1 + moreinfo

On Fri, 15 Mar 2019 15:52:44 + Alex Bennée  wrote:

Package: qemu-user-static
Version: 1:3.1+dfsg-4
Severity: normal

Dear Maintainer,

Trying to build gitlab-runner on an ThunderX arm64 box it tries to run a
docker image with armhf binaries which fails:

  standard_init_linux.go:207: exec user process caused "exec format error"

You can replicate by running:

  14:30:41 [root@qemu-test:/v/l/d/info] 1 # uname -a
  Linux qemu-test 4.20.0 #5 SMP Tue Jan 8 10:57:44 UTC 2019 aarch64 aarch64 
aarch64 GNU/Linux
  14:30:46 [root@qemu-test:/v/l/d/info] # arch-test -n armhf
  armhf: not supported on this machine/kernel

The underlying reason is because binfmt_misc isn't set up for armhf
binaries because qemu-user-static.postinst does:

  # find which fmts needs to be filtered out, which is arch-dependent.
  case "$DPKG_MAINTSCRIPT_ARCH" in

...

arm | armel | armhf | arm64) omit="arm|aarch64" ;;
  esac

Which is certainly not true for all aarch64 CPUs. Some do not support
aarch32. The following change makes it work but requires arch-test as a
dependency:


...

arm | armel | armhf) omit="arm" ;;
arm64 )
if arch-test -n armhf > /dev/null; then
omit="arm|aarch64"
else
omit="aarch64"
fi
;;

This logic is repeated in the prerm script so there is probably some
scope in cleaning up and sharing the logic.


Hi Alex!

This should be a runtime test on the installed system, I guess.
It is more: you might install the system on one hardware but but
later run it on a different hardware.

So this becomes, I guess, a startup script or a service which checks
things at boot and enables/disables this particular format according
to arch-test

How do you think if this is worth the effort to implement?

I understand the basics here (without any knowlege whatsoewer about
various arm hardware), but the solution seem to be a bit difficult.

FWIW, I'm enabling binfmt.d/ support for binfmt-misc format registration
(as an alternative to binfmt-support), - not that it makes it more difficult,
just one more condition to check.

Thank you for the bugreport!

/mjt

Bug#1010438: transition: nodejs

[Jérémy Lal]

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

Hi,

nodejs 16.14.2 is the current active version of nodejs:
https://nodejs.org/en/about/releases/
It also supports riscv64 architecture and has much better support of ppc64.

A rebuild of all (1600+) reverse-build-deps of libnode-dev/nodejs shows
very few regressions, alerady being dealt with.

Ben file:

title = "nodejs";
is_affected = .depends ~ "libnode83" | .depends ~ "libnode93";
is_good = .depends ~ "libnode93";
is_bad = .depends ~ "libnode83";

Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment

[Julian Gilbey]

Package: autopkgtest
Version: 5.21
Severity: normal

(I realise that posting this on debian-devel [1] was probably not the
most appropriate place, as it's actually a bug report.)

I am not sure whether this is a bug in autopkgtest-build-lxc, a bug in
lxc itself or a user error.  Please feel free to redirect as
appropriate!

This is what I did:

Step 1: I installed the lxc and autopkgtest packages
That went smoothly.  (lxc version 1:4.0.11-1, autopkgtest version
5.21; autopkgtest was already installed, and I installed lxc from 

Step 2: I ran the command "autopkgtest-build-lxc debian sid"
as root.  I got various warning messages to begin with:

>
lxc-create: autopkgtest-sid: storage/btrfs.c: btrfs_create: 938 Inappropriate 
ioctl for device - Failed to create btrfs subvolume 
"/var/lib/lxc/autopkgtest-sid/rootfs"
lxc-create: autopkgtest-sid: storage/zfs.c: zfs_create: 735 Failed to create 
zfs dataset "zfs:lxc/autopkgtest-sid": lxc-create: autopkgtest-sid: utils.c: 
run_command_internal: 1588
lxc-create: autopkgtest-sid: storage/lvm.c: do_lvm_create: 165 Failed to create 
logical volume "autopkgtest-sid":   Volume group "lxc" not found
  Cannot process volume group lxc
lxc-create: autopkgtest-sid: storage/lvm.c: lvm_create: 623 Error creating new 
logical volume "lvm:/dev/lxc/autopkgtest-sid" of size "1073741824 bytes"
<

after which things ran smoothly for a bit:

>
debootstrap is /usr/sbin/debootstrap
Checking cache download in /var/cache/lxc/debian/rootfs-sid-amd64 ... 
Downloading debian minimal ...
I: Target architecture can be executed
I: Retrieving InRelease 
[... downloading and installing base system ...]
I: Base system installed successfully.
Download complete.
<

but then there were lots of warning messages about libeatmydata.so
interspersed with information messages; I assume that these are mostly
harmless:

>
Copying rootfs to /var/lib/lxc/autopkgtest-sid/rootfs...ERROR: ld.so: object 
'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared 
object file): ignored.
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
Generating locales (this might take a while)...
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
  en_GB.UTF-8ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be 
preloaded (cannot open shared object file): ignored.
[... lots more similar warnings and messages ...]
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
<

But then I received several fatal error messages:

>
lxc-start: autopkgtest-sid: lxccontainer.c: wait_on_daemonized_start: 867 
Received container state "ABORTING" instead of "RUNNING"
lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 306 The container failed 
to start
lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 309 To get more details, 
run the container in foreground mode
lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 311 Additional information 
can be obtained by setting the --logfile and --logpriority options
<

Since autopkgtest-build-lxc doesn't allow a --logfile option, I
attempted to start the container manually, using the command
  lxc-start -n autopkgtest-sid --logfile /tmp/lxc.log --logpriority INFO
and got the following warnings and errors in the log file (I've
excluded the INFO entries):

>
lxc-start autopkgtest-sid 20220501145802.680 NOTICE   conf - 
conf.c:lxc_setup:4450 - The container "autopkgtest-sid" is set up
lxc-start autopkgtest-sid 20220501145802.681 WARN cgfsng - 
cgroups/cgfsng.c:get_hierarchy:142 - There is no useable devices controller
lxc-start autopkgtest-sid 20220501145802.681 ERRORcgfsng - 
cgroups/cgfsng.c:cg_legacy_set_data:2675 - No such file or directory - Failed 
to setup limits for the "devices" controller. The controller seems to be unused 
by "cgfsng" cgroup driver or not enabled on the cgroup hierarchy
lxc-start autopkgtest-sid 20220501145802.681 ERRORcgfsng - 
cgroups/cgfsng.c:cgfsng_setup_limits_legacy:2742 - No such file or directory - 
Failed to set "devices.deny" to "a"
lxc-start autopkgtest-sid 20220501145802.681 ERRORstart - 
start.c:lxc_spawn:1890 - Failed to setup legacy device cgroup controller limits
lxc-start autopkgtest-sid 20220501145802.681 ERRORlxccontainer - 
lxccontainer.c:wait_on_daemonized_start:867 - Received container state 
"ABORTING" instead of "RUNNING"
lxc-start autopkgtest-sid 20220501145802.681 ERRORlxc_start - 
tools/lxc_start.c:main:306 - The container failed to start
lxc-start autopkgtest-sid 20220501145802.681 ERRORlxc_start - 
tools/lxc_start.c:main:309 - To get more details, run the container in 
foreground mode
lxc-start autopkgtest-sid 20220501145802.681 ERRORlxc_start - 
tools/lxc_start.c:main:311 - Additional information can be obtained by setting 
the --logfile and --logpriori

Bug#1003463: Functionally broken with current PHP

[Sylvestre Ledru]

Le 01/05/2022 à 15:29, Christoph Biedl a écrit :

Control: tag 1003463 confirmed

Roman Lebedev wrote...


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

@Sylvestre,

as previously mentioned in IRC (possibly got lost), I am considering
rebasing the src:phabricator package to the latest git commit in the
respective upstream repositories. Please let me know what you think
about this - or feel free to do it on your own.

 Christoph


Sure, many thanks :)

S

Bug#1010435: harfbuzz: Several new upstream releases

[Florian Ernst]

Source: harfbuzz
Version: 2.7.4-1
Severity: wishlist

Dear maintainers,

as your are undoubtedly aware there are several new upstream releases
available, cf. .

Among other things those stabilize the subset API as required for
#988781, contain various build fixes that might help with #956646 and/or
#944212, provide Unicode 14.0 support, extend the public API, support
more than 65535 (the OpenType limit) glyph shapes and metrics, and much
much more.

Are there any reasons preventing to package any of those 19 new releases
since the currently-packaged 2.7.4? Posing this admittedly rather loaded
question here as I am wondering what is going on, and if there are
indeed any such reasons please document them here ...

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1003463: Functionally broken with current PHP

[Christoph Biedl]

Control: tag 1003463 confirmed

Roman Lebedev wrote...

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

@Sylvestre,

as previously mentioned in IRC (possibly got lost), I am considering
rebasing the src:phabricator package to the latest git commit in the
respective upstream repositories. Please let me know what you think
about this - or feel free to do it on your own.

Christoph


signature.asc
Description: PGP signature

Bug#1008112: Source is duplicated with golang-mvdan-sh

[Christoph Biedl]

Shengjing Zhu wrote...

> I planned to merge this when shfmt has a new upstream release.
> However it seems more urgent now since it was removed from testing the
> last few days.

Thanks for the swift response. I'm glad to see shfmt will return to a
good shape soon.

Christoph.





signature.asc
Description: PGP signature

Bug#987895: libyaml: 0.2.5 released upstream, not detected by watch file

[Florian Ernst]

Hello Anders,

On Wed, Mar 30, 2022 at 05:54:52PM +0200, Florian Ernst wrote:
> I saw that you had been active in Debian recently, which is a relief as
> I was wondering whether the libyaml package might be in need of
> salvaging, given the apparent lack of activity over the last years.

Could you please comment on ?

To me it feels like the libyaml package might be in need of salvaging as
per Developer's Reference (5.12) and the Debian Wiki
, so please speak up.

Kind regards,
Flo


signature.asc
Description: PGP signature

Bug#1010426: ldnsutils: Enable SVCB/HTTPS rrtypes

[Ondřej Surý]

As of these, only HTTPS and SVCB are in widespread use.

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

> On 1. 5. 2022, at 14:39, Michael Tokarev  wrote:
> 
> Control: tag -1 + moreinfo
> 
> 01.05.2022 14:59, John Shaft wrote:
>> Package: ldnsutils
>> Version: 1.8.1-1
>> Severity: wishlist
>> Dear Maintainer,
>> ldns 1.8.0 introduced support for SVCB & HTTPS resource records [1],[2]
>> It has to be compiled via a specific parameter --enable-rrtype-svcb-https
>> Could the debian package be shipped with this option enabled ?
> 
> From ldns's ./configure --help:
> 
>  --enable-rrtype-ninfo   Enable draft RR type ninfo.
>  --enable-rrtype-rkeyEnable draft RR type rkey.
>  --disable-rrtype-openpgpkey
>  Disable openpgpkey RR type.
>  --enable-rrtype-ta  Enable draft RR type ta.
>  --enable-rrtype-avc Enable draft RR type avc.
>  --enable-rrtype-doa Enable draft RR type DOA.
>  --enable-rrtype-amtrelay
>  Enable draft RR type AMTRELAY.
>  --enable-rrtype-svcb-https
>  Enable draft RR types SVCB and HTTPS.
> 
> Neither of these is enabled.
> 
> I wonder if we should enable them all.
> 
> I don't see any special dependencies for these, it just
> an ifdef in rr.c:
> 
> #ifdef RRTYPE_SVCB_HTTPS
> static const ldns_rdf_type type_svcb_wireformat[] = {
>LDNS_RDF_TYPE_INT16,
>LDNS_RDF_TYPE_DNAME,
>LDNS_RDF_TYPE_SVCPARAMS
> };
> #endif
> 
> #ifdef RRTYPE_SVCB_HTTPS
>/* 64 */
>{LDNS_RR_TYPE_SVCB, "SVCB", 2, 3, type_svcb_wireformat, 
> LDNS_RDF_TYPE_NONE, LDNS_RR_NO_COMPRESS, 0 },
>/* 65 */
>{LDNS_RR_TYPE_HTTPS, "HTTPS", 2, 3, type_svcb_wireformat, 
> LDNS_RDF_TYPE_NONE, LDNS_RR_NO_COMPRESS, 0 },
> 
> #else
> {LDNS_RR_TYPE_NULL, "TYPE64", 1, 1, type_0_wireformat, LDNS_RDF_TYPE_NONE, 
> LDNS_RR_NO_COMPRESS, 0 },
> {LDNS_RR_TYPE_NULL, "TYPE65", 1, 1, type_0_wireformat, LDNS_RDF_TYPE_NONE, 
> LDNS_RR_NO_COMPRESS, 0 },
> #endif
> 
> I wonder why they didn't enable them.  If the reason is that these
> are DRAFTs, - maybe it's okay to use DRAFT-HTTPS instead of HTTPS there?
> 
> Ondřej, do you have any comments about these?
> 
> Thanks,
> 
> /mjt
> 

Bug#1003063: RFS: su-exec/0.2-1 [ITP] -- switch user and group id, setgroups and exec

[Michael Tokarev]

03.01.2022 18:05, Matteo Chesi wrote:

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "su-exec":

  * Package name    : su-exec
    Version : 0.2-1
    Upstream Author : Natanael Copa 
  * URL : https://github.com/ncopa/su-exec
  * License : MIT
  * Vcs : [fill in URL of packaging vcs]
    Section : admin

It builds those binary packages:

   su-exec - switch user and group id, setgroups and exec


How it's different from, say, setpriv?

Thanks,

/mjt

Bug#1010276: parasail: compiles something extra (or less) depending on the CPU features available

[Andreas Tille]

Am Sun, May 01, 2022 at 02:09:21PM +0200 schrieb Étienne Mollier:
> > Note that `sort` is locale dependant, so if that's really the proper way
> > to do it (tbh doing find|head feels *very* brittle to me… it's probably
> > better if you can think of a better way to achieve whatever that piece
> > of code is doing), remember to prepend LC_ALL=C.UTF-8 to the sort call.
> 
> True, thanks for the reminder!

As I tried to express the lib*.a file is thrown away afterwards - may be
even some touch would do the trick. d-shlibmove simply needs some
libparasail.a - no other magic behind this.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1009888: [Pkg-rust-maintainers] Bug#1009888: rust-h2, existing version is badly broken, new upstream needs new package

[Fabian Grünbichler]

On April 20, 2022 11:39 am, Fabian Grünbichler wrote:
> On April 20, 2022 12:33 am, Peter Michael Green wrote:
>> Package: rust-h2
>> Version: 0.1.26-1
>> X-debbugs-cc: d...@jones.dk
>> 
>> I noticed that Jonas had set a number of bugs about broken rust packages as
>> blockers of 900928, so I decided to take a look at some of them. I fixed up
>> bytemuck, image and related packages.
>> 
>> I then started looking at reqwest which lead me to h2 (which has been broken
>> since the tokio 1.x transition but noone ever got around to filing a 
>> bug) which
>> lead me to http which jonas recently NMU'd.
>> 
>> I feel I need to comment on the technical details of the NMU, I should 
>> preface
>> this by saying that I don't think it's unreasonable to 0-day NMU a minimal
>> fix for a long term RC issue, even if (as was not the case here but was the
>> case for some of the other NMUs noone ever bothered to actually file the
>> RC bug).
>> 
>> However, this NMU did considerably more than just add a minimal fix for
>> the rc issue. Most painfullly, the "orig" tarball for the new upstream 
>> version
>> appears to have been derived from upstream git rather than from crates.io
>> and this breaks our workflow. If you are going to 0-day stuff please keep
>> your uploads minimal. If you want to do more invasive NMUs please give
>> the maintainers a chance to respond.
>> 
>> Fortunately it seems the answer is to move to an even newer upstream
>> version. The only reverse dependencies of rust-http seem to be the
>> h2/hyper stack which badly needs an update to move away from tokio
>> 0.x. I have already committed the http update to debcargo-conf and may
>> upload it at some point.
>> 
>> Unfortunately moving back up the stack I ran into another issue. h2 and
>> hyper have grown a new dependency on tracing. While I am I am happy to
>> help with fixing existing rust packages, I am reluctant to take 
>> responsibility
>> for a new package unless it's something I personally use.
>> 
>> So this is where I personally tap out on h2/hyper until/unless someone
>> packages tracing.
> 
> we use this stack (h2/hyper) downstream, I can take care of it over the 
> coming weeks. tracing is unfortunately still rather in-flux, so it will 
> likely see frequent upgrades.

okay, just pushed the following to debcargo-conf:
- update of hyper
- update of httparse
- update of http-body
- switch of http to iota 1.x

currently progress is blocked on
- itoa/serde_json transition (anybody working actively on that?)
- tracing being uploaded (capitol?)
- tower-service being uploaded (NEW, RFS, please upload!)

once all of the above is in the archive, the current version of h2 also 
builds fine ;)

Bug#1010433: ITS: liblognorm

[Florian Ernst]

Source: liblognorm
Version: 2.0.5-1.1
Severity: important
X-Debbugs-Cc: Pierre Chifflier , Michael Biebl 


Greetings,

hereby I declare my intention to salvage the "liblognorm" package using
the procedure described in the Developer's Reference (5.12) and the
Debian Wiki .

Criteria are met as follows:

* The package is in clear need of some love and care:
  * There is an upstream release missing, cf.
, filed 28 Apr 2020.
  * There is work needed from a quality-assurance perspective as the
packaging uses outdated / deprecated standards, cf.
, and it FTCBFS, cf.


AND

* An upload is needed to fix this.

AND

* At least one to the following applies (non-applicable omitted):
  * There is no visible activity regarding the package for six months.
Attempting to elicit a maintainer response failed, cf.
 ff.
  * The last upload was an NMU and there was no maintainer upload within
one year.
Last maintainer upload was on 2018-04-29, last NMU (and package
update) on 2020-03-15.

My objective is to have this package in Debian, and in good shape. So
if you (maintainer) want to resume taking care of it, please do. And in
case you object or already have other plans, just let me know.

As this package is a direct dependency of rsyslog and is also coming
from the same upstream I'm CC'ing the rsyslog maintainer who might have
something to say on this.

Kind regards,
Flo


signature.asc
Description: PGP signature

Bug#1010434: ITS: libestr

[Florian Ernst]

Source: libestr
Version: 0.1.10-2.1
Severity: important
X-Debbugs-Cc: Pierre Chifflier , Michael Biebl 


Greetings,

hereby I declare my intention to salvage the "libestr" package using the
procedure described in the Developer's Reference (5.12) and the Debian
Wiki .

Criteria are met as follows:

* The package is in clear need of some love and care:
  * There is a (recommended) upstream release missing, cf.
, filed 31 Oct 2018.
  * There is work needed from a quality-assurance perspective as the
packaging uses outdated / deprecated standards, cf.


AND

* An upload is needed to fix this.

AND

* At least one to the following applies (non-applicable omitted):
  * There is no visible activity regarding the package for six months.
Attempting to elicit a maintainer response failed, cf.
 ff.
  * The last upload was an NMU and there was no maintainer upload within
one year.
Last maintainer upload was on 2016-04-18, last NMU (and package
update) on 2017-10-09.

My objective is to have this package in Debian, and in good shape. So
if you (maintainer) want to resume taking care of it, please do. And in
case you object or already have other plans, just let me know.

As this package is a direct dependency of rsyslog and is also coming
from the same upstream I'm CC'ing the rsyslog maintainer who might have
something to say on this (and who, incidentally, had also filed the bug
mentioned above).

Kind regards,
Flo


signature.asc
Description: PGP signature

Bug#1010432: debian-edu-config: autopkgtest regression: update-mime: not found

[Paul Gevers]

Source: debian-edu-config
Version: 2.12.21
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of debian-edu-config the autopkgtest of 
debian-edu-config fails in testing when that autopkgtest is run with the 
binary packages of debian-edu-config from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
debian-edu-config  from testing2.12.21
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems that 
with the fix for bug #1010102 you either picked the wrong Depends of 
two, or you forgot to update the postinst for the change as update-mime 
lives in mailcap.


Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=debian-edu-config

https://ci.debian.net/data/autopkgtest/testing/amd64/d/debian-edu-config/21269049/log.gz

Setting up debian-edu-config (2.12.21) ...
On branch master
nothing to commit, working tree clean
/var/lib/dpkg/info/debian-edu-config.postinst: 55: update-mime: not found
dpkg: error processing package debian-edu-config (--configure):
 installed debian-edu-config package post-installation script 
subprocess returned error exit status 127

dpkg: dependency problems prevent configuration of debian-edu-install:
 debian-edu-install depends on debian-edu-config; however:
  Package debian-edu-config is not configured yet.

dpkg: error processing package debian-edu-install (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of autopkgtest-satdep:
 autopkgtest-satdep depends on debian-edu-install; however:
  Package debian-edu-install is not configured yet.

dpkg: error processing package autopkgtest-satdep (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 debian-edu-config
 debian-edu-install
 autopkgtest-satdep
E: Sub-process /usr/bin/dpkg returned an error code (1)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010431: ensmallen: autopkgtest regression on i386: 2.101206341 == Approx( 2.0 )

[Paul Gevers]

Source: ensmallen
Version: 2.19.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of ensmallen the autopkgtest of ensmallen fails in 
testing on i386 when that autopkgtest is run with the binary packages of 
ensmallen from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
ensmallen  from testing2.19.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=ensmallen

https://ci.debian.net/data/autopkgtest/testing/i386/e/ensmallen/21265784/log.gz


~~~
ensmallen-test-aFtbnG is a Catch v2.13.9 host application.
Run with -? for options

---
CNEHimmelblauFunctionTest
---
tests/cne_test.cpp:94
...

tests/cne_test.cpp:103: FAILED:
  REQUIRE( coordinates(1) == Approx(2.0).margin(0.1) )
with expansion:
  2.101206341 == Approx( 2.0 )

0.000 s: CNEHimmelblauFunctionTest


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007794: Close fixed stuff

[Nilesh Patra]

Control: fixed -1 1.3.0-2
Control: close -1

It has been fixed in the new release I didn't notice this filed bug.

Bug#1010430: tifffile breaks skimage autopkgtest: asarray() got an unexpected keyword argument 'multifile'

[Paul Gevers]

Source: tifffile, skimage
Control: found -1 tifffile/20220426-1
Control: found -1 skimage/0.18.3-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of tifffile the autopkgtest of skimage fails in 
testing when that autopkgtest is run with the binary packages of 
tifffile from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
tifffile   from testing20220426-1
skimagefrom testing0.18.3-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of tifffile to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=tifffile

https://ci.debian.net/data/autopkgtest/testing/amd64/s/skimage/21268058/log.gz

___ test_tifffile_kwarg_passthrough 



def test_tifffile_kwarg_passthrough ():

  img = imread(fetch('data/multipage.tif'), key=[1],

 multifile=False, multifile_close=True, fastij=True,
 is_ome=True)

/usr/lib/python3/dist-packages/skimage/io/tests/test_tifffile.py:41: _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ /usr/lib/python3/dist-packages/skimage/io/_io.py:48: in imread

img = call_plugin('imread', fname, plugin=plugin, **plugin_args)
/usr/lib/python3/dist-packages/skimage/io/manage_plugins.py:207: in 
call_plugin

return func(*args, **kwargs)
/usr/lib/python3/dist-packages/skimage/io/_plugins/tifffile_plugin.py:30: in 
imread

return tifffile_imread(fname, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

files = '/usr/lib/python3/dist-packages/skimage/data/../data/multipage.tif'
aszarr = False
kwargs = {'fastij': True, 'key': [1], 'multifile': False, 
'multifile_close': True}

kwargs_file = {'is_ome': True}, kwargs_seq = {}
tif = 

def imread(
files: str
| os.PathLike
| FileHandle
| BinaryIO
| Sequence[str | os.PathLike]
| None = None,
*,
aszarr: bool = False,
**kwargs,
) -> numpy.ndarray | ZarrTiffStore | ZarrFileSequenceStore:
"""Return image data from TIFF file(s) as numpy array or zarr 
storage.
Refer to the TiffFile and TiffSequence classes and their 
asarray

functions for documentation.
Parameters
--
files : path-like, binary stream, or sequence
File name, seekable binary stream, glob pattern, or sequence of
file names. May be None (default) if 'container' is specified.
aszarr : bool
If True, return file sequences, series, or single pages as
zarr storage instead of numpy array (experimental).
**kwargs
Optional extra arguments.
Parameters 'name', 'offset', 'size', and 'is_' flags are 
passed to

TiffFile or TiffSequence.imread.
Parameters 'imread', 'container', 'sort', 'pattern', 
'axesorder',

and 'categories' are passed to TiffSequence.
Other parameters are passed to the asarray or aszarr functions.
The first image series in the file is returned if no 
arguments are

provided.
Returns
---
numpy.ndarray or zarr storage
Image data from the specified pages.
Zarr storage instances must be closed after use.
See TiffPage.asarray for operations that are applied (or not)
to the raw data stored in the file.
"""
kwargs_file = parse_kwargs(
kwargs,
'name',
'offset',
'size',
# private
'_multifile',
'_useframes',
# is_flags
*(key for key in kwargs if key[:3] == 'is_'),
)
kwargs_seq = parse_kwargs(
kwargs,
'imread',
'container',
'sort',
'pattern',
'axesorder',
'categories',
)
if kwargs_seq.get('container', None) is None:
if isinstance(files, str) and ('*' in files or '?' in files):
files = glob.glob(files)
if not files:
raise ValueError('no files found')
if (
isinstance(files, collections.abc.Sequence)
and not isinstance(files, str)
and len(files) == 1

Bug#1009261: Evolution bwrap problem - may fail to print or hang in startup

[Domenico Cufalo]

Dear developers,

I have the same issue in my machine (Debian Bullseye Stable with Gnome 
3.38): Evolution doesn't start at all.


But I could add that this issue affects also Gnome Online Accounts. To 
have it working we have to launch


WEBKIT_FORCE_SANDBOX=0 gnome-control-center online-accounts


Thank you very much,
Domenico

Bug#1010429: gddrescue: autopkgtest regression

[Paul Gevers]

Source: gddrescue
Version: 1.26-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of gddrescue the autopkgtest of gddrescue fails in 
testing when that autopkgtest is run with the binary packages of 
gddrescue from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
gddrescue  from testing1.26-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
gddrescue/1.26-1. I.e. due to versioned dependencies or breaks/conflicts.

[1] https://qa.debian.org/excuses.php?package=gddrescue

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gddrescue/21266348/log.gz

1+0 records in
1+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0754896 s, 139 MB/s
GNU ddrescue 1.26
Press Ctrl-C to interrupt







 ipos:0 B, non-trimmed:0 B, 
current rate:   0 B/s

 opos:0 B, non-scraped:0 B,  average rate:   0 B/s
non-tried:   10485 kB,  bad-sector:0 B,error rate:   0 B/s
  rescued:0 B,   bad areas:0,run time:  0s
pct rescued:0.00%, read errors:0,  remaining time: n/a
  time since last successful read: n/a

Copying non-tried blocks... Pass 1 (forwards)
 ipos:   10420 kB, non-trimmed:0 B, 
current rate:   0 B/s

 opos:   10420 kB, non-scraped:0 B,  average rate:   0 B/s
non-tried:0 B,  bad-sector:0 B,error rate:   0 B/s
  rescued:   10485 kB,   bad areas:0,run time:  0s
pct rescued:  100.00%, read errors:0,  remaining time: n/a
  time since last successful read: n/a

Copying non-tried blocks... Pass 1 (forwards)
 ipos:   10420 kB, non-trimmed:0 B, 
current rate:  10485 kB/s

 opos:   10420 kB, non-scraped:0 B,  average rate:  10485 kB/s
non-tried:0 B,  bad-sector:0 B,error rate:   0 B/s
  rescued:   10485 kB,   bad areas:0,run time:  0s
pct rescued:  100.00%, read errors:0,  remaining time: n/a
  time since last successful read: n/a

Finishedautopkgtest [22:12:17]: test 
clone-file




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010426: ldnsutils: Enable SVCB/HTTPS rrtypes

[Michael Tokarev]

Control: tag -1 + moreinfo

01.05.2022 14:59, John Shaft wrote:

Package: ldnsutils
Version: 1.8.1-1
Severity: wishlist

Dear Maintainer,

ldns 1.8.0 introduced support for SVCB & HTTPS resource records [1],[2]

It has to be compiled via a specific parameter --enable-rrtype-svcb-https

Could the debian package be shipped with this option enabled ?


From ldns's ./configure --help:

  --enable-rrtype-ninfo   Enable draft RR type ninfo.
  --enable-rrtype-rkeyEnable draft RR type rkey.
  --disable-rrtype-openpgpkey
  Disable openpgpkey RR type.
  --enable-rrtype-ta  Enable draft RR type ta.
  --enable-rrtype-avc Enable draft RR type avc.
  --enable-rrtype-doa Enable draft RR type DOA.
  --enable-rrtype-amtrelay
  Enable draft RR type AMTRELAY.
  --enable-rrtype-svcb-https
  Enable draft RR types SVCB and HTTPS.

Neither of these is enabled.

I wonder if we should enable them all.

I don't see any special dependencies for these, it just
an ifdef in rr.c:

#ifdef RRTYPE_SVCB_HTTPS
static const ldns_rdf_type type_svcb_wireformat[] = {
LDNS_RDF_TYPE_INT16,
LDNS_RDF_TYPE_DNAME,
LDNS_RDF_TYPE_SVCPARAMS
};
#endif

#ifdef RRTYPE_SVCB_HTTPS
/* 64 */
{LDNS_RR_TYPE_SVCB, "SVCB", 2, 3, type_svcb_wireformat, 
LDNS_RDF_TYPE_NONE, LDNS_RR_NO_COMPRESS, 0 },
/* 65 */
{LDNS_RR_TYPE_HTTPS, "HTTPS", 2, 3, type_svcb_wireformat, 
LDNS_RDF_TYPE_NONE, LDNS_RR_NO_COMPRESS, 0 },

#else
{LDNS_RR_TYPE_NULL, "TYPE64", 1, 1, type_0_wireformat, LDNS_RDF_TYPE_NONE, 
LDNS_RR_NO_COMPRESS, 0 },
{LDNS_RR_TYPE_NULL, "TYPE65", 1, 1, type_0_wireformat, LDNS_RDF_TYPE_NONE, 
LDNS_RR_NO_COMPRESS, 0 },
#endif

I wonder why they didn't enable them.  If the reason is that these
are DRAFTs, - maybe it's okay to use DRAFT-HTTPS instead of HTTPS there?

Ondřej, do you have any comments about these?

Thanks,

/mjt

Bug#1010428: twine: autopkgtest needs update for new version of python-readme-renderer: error message changed

[Paul Gevers]

Source: twine
Version: 4.0.0-2
Severity: serious
X-Debbugs-CC: python-readme-rende...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python-readme-renderer

Dear maintainer(s),

With a recent upload of python-readme-renderer the autopkgtest of twine 
fails in testing when that autopkgtest is run with the binary packages 
of python-readme-renderer from unstable. It passes when run with only 
packages from testing. In tabular form:


   passfail
python-readme-renderer from testing35.0-1
twine  from testing4.0.0-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. After a very 
brief inspection, it seems the test captures an error message and 
expects it to remain unchanged.


Currently this regression is blocking the migration of 
python-readme-renderer to testing [1]. Of course, python-readme-renderer 
shouldn't just break your autopkgtest (or even worse, your package), but 
it seems to me that the change in python-readme-renderer was intended 
and your package needs to update to the new situation.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from python-readme-renderer 
should really add a versioned Breaks on the unfixed version of (one of 
your) package(s). Note: the Breaks is nice even if the issue is only in 
the autopkgtest as it helps the migration software to figure out the 
right versions to combine in the tests.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-readme-renderer

https://ci.debian.net/data/autopkgtest/testing/amd64/t/twine/21263820/log.gz

__ test_fails_rst_no_content 
___


tmp_path = 
PosixPath('/tmp/pytest-of-debci/pytest-0/test_fails_rst_no_content0')

capsys = <_pytest.capture.CaptureFixture object at 0x7fe0218f5210>
caplog = <_pytest.logging.LogCaptureFixture object at 0x7fe0218f7eb0>

def test_fails_rst_no_content(tmp_path, capsys, caplog):
sdist = build_sdist(
tmp_path,
{
"setup.cfg": (
"""
[metadata]
name = test-package
version = 0.0.1
long_description = file:README.rst
long_description_content_type = text/x-rst
"""
),
"README.rst": (
"""
test-package

"""
),
},
)
assert check.check([sdist])
assert capsys.readouterr().out == f"Checking {sdist}: FAILED\n"
>   assert caplog.record_tuples == [
(
"twine.commands.check",
logging.ERROR,
"`long_description` has syntax errors in markup "
"and would not be rendered on PyPI.\n",
),
]
E   AssertionError: assert [('twine.comm...RST source.')] == 
[('twine.comm... on PyPI.\n')]
E At index 0 diff: ('twine.commands.check', 40, 
'`long_description` has syntax errors in markup and would not be 
rendered on PyPI.\nNo content rendered from RST source.') != 
('twine.commands.check', 40, '`long_description` has syntax errors in 
markup and would not be rendered on PyPI.\n')

E Use -v to get the full diff



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010427: RM: typescript-types -- ROM; Deprecated

[Yadd]

Package: ftp.debian.org
Severity: normal

Hi,

node-typescript-types is a transitional package, useless now. Please
remove it.

Cheers,
Yadd

Bug#995430: qemu-user-static: creates /core dump spontaneously upon upgrade, even when not in use?

[Michael Tokarev]

Control: tag -1 + moreinfo

On Fri, 01 Oct 2021 17:30:16 +1000 Tim Connors  wrote:

Package: qemu-user-static
Version: 1:5.2+dfsg-11
Severity: normal

I noticed a /core file in the root directory, dated around about when
my machine was upgraded to bullseye.  I checked another machine, and
it too had the same core file, dated from the upgrade:

24606,4> ls -lA /core
-rw---   1 root root 11542528 Sep 15 00:41 core
0-0-16:27:43, Fri Oct 01 tconnors@fs:/snapshots/dirac/latest (bash)
24607,5> sudo file core
core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from 
'/usr/libexec/qemu-binfmt/s390x-binfmt-P /check /check', real uid: 0, effective 
uid: 0, real gid: 0, effective gid: 0, execfn: '/check', platform: 'x86_64'


Interesting. Do you by a chance also have /check binary?

This is apparently something checking for s390x availability,
so "not in use" is a bit interesting here in this context.
Neither binfmt-support nor systemd does that, and qemu-user-static
does not do this either.

It is interesting twice: the fact someone tried this s390x
abi, and the fact that qemu-s390-static (the binfmt-P is just
a symlink to it) crashed with a core dump.  It was run as root
too (well, or else it wouldn't be able to create /core).

It'd be interesting to see the core file and especially the
/check binary.

Did it happen again since that? Can you reinstall qemu-user-static,
or upgrade it again (installing the buster version first) and see
if it triggers the issue again?

I have no idea what is going on there...

Thanks!

/mjt

Bug#1010287: libnet-ssleay-perl: FTBFS: bad line in substvars file debian/libnet-ssleay-perl.substvars at line 2

[Niko Tyni]

Control: reassign -1 perl-openssl-defaults 5
Control: tag -1 sid bookworm
Control: retitle -1 perl-openssl-defaults: generated substvar should not end in 
a newline
Control: affects -1 src:libnet-ssleay-perl

On Wed, Apr 27, 2022 at 03:28:06PM -0700, Daniel Schepler wrote:
> Source: libnet-ssleay-perl
> Version: 1.92-1
> Severity: serious

> dpkg-shlibdeps: error: bad line in substvars file
> debian/libnet-ssleay-perl.substvars at line 2
> dh_shlibdeps: error: dpkg-shlibdeps
> -Tdebian/libnet-ssleay-perl.substvars
> debian/libnet-ssleay-perl/usr/lib/x86_64-linux-gnu/perl5/5.34/auto/Net/SSLeay/SSLeay.so
> returned exit code 255

> Looking at the file it's complaining about,
> debian/libnet-ssleay-perl.substvars contains:
> 
> perl:Depends=perl, perl-openssl-abi-1.1
> , perlapi-5.34.0
> 
> (My best guess would be that this is a bug in perl-openssl-defaults /
> dh_perl_openssl, but it's just a guess...)

Thanks.

Looks like Debian::Debhelper::Dh_Lib::addsubstvar no longer strips
newlines from substvar values. I think it regressed with debhelper 13.7,
probably

  
https://salsa.debian.org/debian/debhelper/-/commit/99892be481c1dd06d9866854a2c14e6a70ae12b7

That said, I think this should be fixed in perl-openssl-defaults by not
putting the newline there in the first place.

Copying Niels; you might want to restore the newline handling if there
are other affected addsubstvar users. If not, I wonder if debhelper
should Break perl-openssl-defaults (<= 5) once we have fixed this.
-- 
Niko Tyni   nt...@debian.org

Bug#1010425: opendkim-tools: opendkim-genkey ignores commandline options.

[Andreas Metzler]

Package: opendkim-tools
Version: 2.11.0~beta2-4
Severity: important

Hello,

opendkim-genkey seems to ignore all commandline options:

8X
ametzler@vsrv21575:~$ /usr/sbin/opendkim-genkey −−selector=be1  −b 1024 −D /tmp 
--verbose
opendkim-genkey: generating private key
opendkim-genkey: private key written to default.private
opendkim-genkey: extracting public key
opendkim-genkey: DNS TXT record written to default.txt
ametzler@vsrv21575:~$ ls -l /tmp/be1.* /tmp/default.* `pwd`/default.*
ls: cannot access '/tmp/be1.*': No such file or directory
ls: cannot access '/tmp/default.*': No such file or directory
-rw--- 1 ametzler ametzler 1679  1. Mai 11:39  
/home/ametzler/default.private
-rw--- 1 ametzler ametzler  505  1. Mai 11:39  /home/ametzler/default.txt
ametzler@vsrv21575:~$ head -n1 /home/ametzler/default.txt
default._domainkey  IN  TXT ( "v=DKIM1; h=sha256; k=rsa; "
ametzler@vsrv21575:~$ certtool --infile=default.private  --key-info | grep bits
Key Security Level: Medium (2048 bits)
8X

cu Andreas

Bug#1010276: [Debian-med-packaging] Bug#1010276: parasail: compiles something extra (or less) depending on the CPU features available

[Mattia Rizzolo]

On Sun, May 01, 2022 at 10:50:16AM +0200, Étienne Mollier wrote:
> Upstream implements run time
> CPU detection to avoid baseline violation on older CPU.

Great!  Thank you for confirming this bit.  I figured it might be the
case, but I didn't verify it myself (as I noted in my first email).

> So I identified three todo items:
>  1. address reproducibility issue likely caused by find|head;

Note that `sort` is locale dependant, so if that's really the proper way
to do it (tbh doing find|head feels *very* brittle to me… it's probably
better if you can think of a better way to achieve whatever that piece
of code is doing), remember to prepend LC_ALL=C.UTF-8 to the sort call.

>  2. fix avx512 support for amd64 architecture;
>  3. disable execessive build artifacts for i386 architecture.

-- 
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#999421: qemu-user-static: lli-13/arm64 causes segfault on amd64 host

[Michael Tokarev]

On Sun, 1 May 2022 13:05:35 +0300 Michael Tokarev  wrote:

Control: tag -1 + confirmed upstream
Control: found -1 1:7.0+dfsg-1

I was able to reproduce this one, including qemu 7.0 version.


But unfortunately I hardly can do anything with this bug report.
I'd say it is better to ask upstream about this one.

/mjt

Bug#1010424: broadcom-sta-dkms: Patch can solve this issue

[manel vallès]

Package: broadcom-sta-dkms
Version: 6.30.223.271-17
Severity: important

Dear Maintainer,

I've found this patch that solves the issue building module for kernel 5.17
Applied just running on folder /usr/src/broadcom-sta-6.30.223.271/src/wl/sys/
patch < file.patch
-

diff -u -r a/src/wl/sys/wl_linux.c b/src/wl/sys/wl_linux.c
--- a/src/wl/sys/wl_linux.c 2022-03-23 00:35:42.930416350 +
+++ b/src/wl/sys/wl_linux.c 2022-03-23 00:40:12.903771013 +
@@ -2980,7 +2980,11 @@
else
dev->type = ARPHRD_IEEE80211_RADIOTAP;

+#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 17, 0)
bcopy(wl->dev->dev_addr, dev->dev_addr, ETHER_ADDR_LEN);
+#else
+   eth_hw_addr_set(wl->dev, dev->dev_addr);
+#endif

 #if defined(WL_USE_NETDEV_OPS)
dev->netdev_ops = &wl_netdev_monitor_ops;
@@ -3261,7 +3265,11 @@
 static ssize_t
 wl_proc_read(struct file *filp, char __user *buffer, size_t length, loff_t
*offp)
 {
+#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 17, 0)
wl_info_t * wl = PDE_DATA(file_inode(filp));
+#else
+   wl_info_t * wl = pde_data(file_inode(filp));
+#endif
 #endif
int bcmerror, len;
int to_user = 0;
@@ -3318,7 +3326,11 @@
 static ssize_t
 wl_proc_write(struct file *filp, const char __user *buff, size_t length,
loff_t *offp)
 {
+#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 17, 0)
wl_info_t * wl = PDE_DATA(file_inode(filp));
+#else
+   wl_info_t * wl = pde_data(file_inode(filp));
+#endif
 #endif
int from_user = 0;
int bcmerror;



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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.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 broadcom-sta-dkms depends on:
ii  dkms  2.8.7-2

Versions of packages broadcom-sta-dkms recommends:
ii  wireless-tools  30~pre9-13.1

broadcom-sta-dkms suggests no packages.

-- no debconf information

Bug#1010423: gnome-core: remove caribou as dependency

[Christopher Bailey]

Package: gnome-core
Version: 1:42+3
I believe caribou is a genuine mistake in dependencies (remove one that is no 
longer part of them).

https://wiki.gnome.org/Projects/Caribou states "Caribou is not under active 
development anymore." and "The GNOME Shell onscreen keyboard does not use 
Caribou anymore.".

Performing "sudo dpkg -r --force-depends caribou" on an updated and upgraded 
sid installation with the gnome-core metapackage installed does not appear to 
break anything in Settings or any on screen keyboard functionality.

I propose that caribou be removed from the dependency list of gnome-core.

Bug#999421: qemu-user-static: lli-13/arm64 causes segfault on amd64 host

[Michael Tokarev]

Control: tag -1 + confirmed upstream
Control: found -1 1:7.0+dfsg-1

I was able to reproduce this one, including qemu 7.0 version.

/mjt