Bug#1004037: Segmentation fault in plink2 (Was: src:plink2: fails to migrate to testing for too long: autopkgtest regression)

[Andreas Tille]

Hi Chris,

Am Sat, Feb 19, 2022 at 11:37:34PM -0800 schrieb Chris Chang:
> To elaborate: when I look at
> https://salsa.debian.org/med-team/plink2/-/tree/master , I can see that
> plink2.cc, include/plink2_base.h, and include/plink2_base.cc don't have the
> same contents as the v2.00a3-20220218 GitHub tag/release.  So I don't know
> where you grabbed the code from this time, but it does not appear to be
> from GitHub.

That's true since on Github the source code of plink1.9 and plink2 is not
separated.  Thus I download the tarball from

   https://www.cog-genomics.org/plink/2.0/

which points to

   https://www.cog-genomics.org/static/bin/plink2_src_220217.zip

I confirm that the tag on Github says v2.00a3-20220218 which seems to be
later than 220217.  In principle I could point the packaging metadata to
Github and exclude everything that I do not need for plink2 packaging (so
remove 1.9 directory and code copies of libdeflate, simde and zstd in 2.0)

In case you consider this the safer way to download plink2 code I'll do so.

Kind regards and thanks a lot for comparing the code base

 Andreas.

> On Sat, Feb 19, 2022 at 7:54 AM Chris Chang  wrote:
> 
> > If you build off the current head, the version string should say "18 Feb
> > 2022", not "17 Feb 2022".
> >
> > On Sat, Feb 19, 2022 at 7:02 AM Andreas Tille  wrote:
> >
> >> Hi again,
> >>
> >> Am Sat, Feb 19, 2022 at 12:28:21AM -0800 schrieb Chris Chang:
> >> > Ok, new release/tag created.
> >>
> >> I've built the new version now.  The bad news is that it keeps on
> >> SEGFAULTing for me:
> >>
> >> ...
> >> (gdb) run
> >> Starting program: /usr/lib/plink2/plink2-sse3 --debug --pfile tmp_data
> >> --export vcf vcf-dosage=DS --out tmp_data2
> >> [Thread debugging using libthread_db enabled]
> >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> >> [New Thread 0x74cc7640 (LWP 985019)]
> >> [New Thread 0x744c6640 (LWP 985020)]
> >> [New Thread 0x7fffebcc5640 (LWP 985021)]
> >> PLINK v2.00a3 64-bit (17 Feb 2022)
> >> www.cog-genomics.org/plink/2.0/
> >> (C) 2005-2022 Shaun Purcell, Christopher Chang   GNU General Public
> >> License v3
> >> Logging to tmp_data2.log.
> >> Options in effect:
> >>   --debug
> >>   --export vcf vcf-dosage=DS
> >>   --out tmp_data2
> >>   --pfile tmp_data
> >>
> >> Start time: Sat Feb 19 16:00:00 2022
> >> 31998 MiB RAM detected; reserving 15999 MiB for main workspace.
> >> Using up to 4 compute threads.
> >> [New Thread 0x77fc5640 (LWP 985022)]
> >>
> >> Thread 1 "plink2-sse3" received signal SIGSEGV, Segmentation fault.
> >> plink2::LoadPsam (psamname=psamname@entry=0x7fffbe60
> >> "tmp_data.psam", pheno_range_list_ptr=, fam_cols=...,
> >> pheno_ct_max=,
> >> missing_pheno=, affection_01=0, max_thread_ct=4,
> >> piip=0x7fff8870, sample_include_ptr=0x7fff8790,
> >> founder_info_ptr=0x7fff87a8, sex_nm_ptr=0x7fff8798,
> >> sex_male_ptr=0x7fff87a0, pheno_cols_ptr=0x7fff8770,
> >> pheno_names_ptr=0x7fff8780, raw_sample_ct_ptr=0x7fff8728,
> >> pheno_ct_ptr=0x7fff8720,
> >> max_pheno_name_blen_ptr=0x7fff87b0) at ../plink2_psam.cc:611
> >> 611 pheno_cols[pheno_idx].nonmiss = nullptr;
> >>
> >>
> >> Please let me know if I can do further checks.
> >>
> >> Kind regards
> >>
> >>   Andreas.
> >>
> >> --
> >> http://fam-tille.de
> >>
> >

-- 
http://fam-tille.de

Bug#1006163: ITP: pyyaml-env-tag -- Custom YAML tag for referencing environment variables

[Carsten Schoenert]

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

* Package name: pyyaml-env-tag
  Version : 0.1
  Upstream Author : Waylan Limberg 
* URL : https://github.com/waylan/pyyaml-env-tag
* License : MIT
  Programming Lang: Python
  Description : Custom YAML tag for referencing environment variables

 This library is the Python port of yaml-env-tag, a Ruby library to use
 referenced environment variables within YAML files.

This library is a new build dependency for recent versions of python-mkdocs.
It will be maintained under the umbrella of Debian Python Team.

Bug#1004037: Segmentation fault in plink2 (Was: src:plink2: fails to migrate to testing for too long: autopkgtest regression)

[Chris Chang]

To elaborate: when I look at
https://salsa.debian.org/med-team/plink2/-/tree/master , I can see that
plink2.cc, include/plink2_base.h, and include/plink2_base.cc don't have the
same contents as the v2.00a3-20220218 GitHub tag/release.  So I don't know
where you grabbed the code from this time, but it does not appear to be
from GitHub.

On Sat, Feb 19, 2022 at 7:54 AM Chris Chang  wrote:

> If you build off the current head, the version string should say "18 Feb
> 2022", not "17 Feb 2022".
>
> On Sat, Feb 19, 2022 at 7:02 AM Andreas Tille  wrote:
>
>> Hi again,
>>
>> Am Sat, Feb 19, 2022 at 12:28:21AM -0800 schrieb Chris Chang:
>> > Ok, new release/tag created.
>>
>> I've built the new version now.  The bad news is that it keeps on
>> SEGFAULTing for me:
>>
>> ...
>> (gdb) run
>> Starting program: /usr/lib/plink2/plink2-sse3 --debug --pfile tmp_data
>> --export vcf vcf-dosage=DS --out tmp_data2
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> [New Thread 0x74cc7640 (LWP 985019)]
>> [New Thread 0x744c6640 (LWP 985020)]
>> [New Thread 0x7fffebcc5640 (LWP 985021)]
>> PLINK v2.00a3 64-bit (17 Feb 2022)
>> www.cog-genomics.org/plink/2.0/
>> (C) 2005-2022 Shaun Purcell, Christopher Chang   GNU General Public
>> License v3
>> Logging to tmp_data2.log.
>> Options in effect:
>>   --debug
>>   --export vcf vcf-dosage=DS
>>   --out tmp_data2
>>   --pfile tmp_data
>>
>> Start time: Sat Feb 19 16:00:00 2022
>> 31998 MiB RAM detected; reserving 15999 MiB for main workspace.
>> Using up to 4 compute threads.
>> [New Thread 0x77fc5640 (LWP 985022)]
>>
>> Thread 1 "plink2-sse3" received signal SIGSEGV, Segmentation fault.
>> plink2::LoadPsam (psamname=psamname@entry=0x7fffbe60
>> "tmp_data.psam", pheno_range_list_ptr=, fam_cols=...,
>> pheno_ct_max=,
>> missing_pheno=, affection_01=0, max_thread_ct=4,
>> piip=0x7fff8870, sample_include_ptr=0x7fff8790,
>> founder_info_ptr=0x7fff87a8, sex_nm_ptr=0x7fff8798,
>> sex_male_ptr=0x7fff87a0, pheno_cols_ptr=0x7fff8770,
>> pheno_names_ptr=0x7fff8780, raw_sample_ct_ptr=0x7fff8728,
>> pheno_ct_ptr=0x7fff8720,
>> max_pheno_name_blen_ptr=0x7fff87b0) at ../plink2_psam.cc:611
>> 611 pheno_cols[pheno_idx].nonmiss = nullptr;
>>
>>
>> Please let me know if I can do further checks.
>>
>> Kind regards
>>
>>   Andreas.
>>
>> --
>> http://fam-tille.de
>>
>

Bug#1006038: git-remote-hg: FTBFS: dh_auto_test: error: make -j8 test returned exit code 2

[Paul Wise]

Control: forwarded -1 https://github.com/mnauw/git-remote-hg/issues/48

On Sat, 2022-02-19 at 07:31 +0100, Lucas Nussbaum wrote:

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

This appears to be caused by git 1:2.35.1-1 in unstable,
the autopkgtests regressed too with the new git version.

https://tracker.debian.org/pkg/git

I've forwarded this issue upstream for debugging/fixing.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1006162: expat: autopkgtest regressions (from CVE-2022-25313 fix)

[GCS]

Control: tags -1 +confirmed

Hi Salvatore,

On Sun, Feb 20, 2022 at 8:15 AM Salvatore Bonaccorso  wrote:
> There appears to be regressions from the CVE-2022-25313 fix in 2.4.5.
> They are known already upstream, cf.
> https://github.com/NixOS/nixpkgs/pull/160826#issuecomment-1046074523
>
> I will hold of the planned expat security release until this is
> addressed.
 ACK, watching this GitHub issue and will update the package accordingly.

Thanks,
Laszlo/GCS

Bug#1006162: expat: autopkgtest regressions (from CVE-2022-25313 fix)

[Salvatore Bonaccorso]

Source: expat
Version: 2.4.5-1
Severity: serious
Justification: autopkgtest regression
X-Debbugs-Cc: car...@debian.org
Control: affects -1 
src:libxml-parser-perl,src:python2.7,src:python3.10,src;python3.9

Hi Laszlo,

There appears to be regressions from the CVE-2022-25313 fix in 2.4.5.
They are known already upstream, cf.
https://github.com/NixOS/nixpkgs/pull/160826#issuecomment-1046074523

I will hold of the planned expat security release until this is
addressed.

Regards,
Salvatore

Bug#1005959: mig-for-host:amd64 should not exist

[Helmut Grohne]

Hi Samuel,

On Sun, Feb 20, 2022 at 12:01:36AM +0100, Samuel Thibault wrote:
> Mmm, it still targets hurd- explicitly, so I'd say it should still
> be called mig-x86-64-gnu.

I can relate to that, yes.

> What I'm wondering is why we added -linux/-kfreebsd since here they are
> host, not target. The package name is supposed to designated the target
> doesn't it?  I'm actually now unsure what "mig-for-host" was supposed to
> mean.  AIUI we'd want it to pull a native-for-host binary that targets
> the architecture equivalent on the hurd port. E.g. on linux-amd64 it'd
> pull a linux-amd64 x86-64-gnu-mig binary.  Currently gnumach is fine
> with this

I think the -linux/-kfreebsd ones originate from the fact that you used
any-amd64. In the end, there will be a sparsely filled binary matrix of
builds.

I see how the build/host/target terminology can become confusing here.
It depends on the point of view. mig's point of view, host is what
architecture the built mig is being run on, but the target architecture
is what architecture it is being used for. The downstream packages
(mainly hurd) relate to mig via their host architecture though. Thus the
"-for-host" part is hurd's host, but mig's target in a sense.

So why do we have mig-for-host? We want hurd to depend on some mig for
its host architecture (i.e. a mig where build=don't care, host=don't
care, target=host of hurd). And that directly means, we only need
mig-for-host for hurd-any. How about changing its architecture field
from "any-i386 any-amd64" to "hurd-any"?

Then, mig-x86-64-linux-gnu has no reverse dependencies anymore and can
go way. Unfortunately, that also means that we won't have any mig
executable on amd64 anymore, but having it would be useful for cross
building hurd. To fix that, we can change the Architecture field of
mig-x86-64-gnu from "hurd-amd64" to "any-amd64". Once doing that, we
effectively get the very same packages just without -linux or -kfreebsd.

Circling back to this matrix of builds. It has two dimensions (host
architecture and target architecture). In the packaging, we decide which
of these combinations generate a package by default. Of course the
diagnoal (host==target) is needed. There is no question about that, but
for other combinations it is less obvious. You currently try to fill
same-cpu combinations. I'm wondering whether that is needed (given that
rebootstrap builds its own mig anyway) and I'm wondering whether that
should be expanded to just cover the full matrix withing x86
architectures (32bit and 64bit) to ease hurd-amd64 development on
hurd-i386. Do you have a preference here?

> checking for i686-gnu-mig... i686-linux-gnu-mig
> 
> but that's still relatively bogus.

After the change above, there would not be any i686-linux-gnu-mig, but
i686-gnu-mig instead.

If you agree with this change in principle, I can look into writing a
patch for it.

Helmut

Bug#1006161: RM: muscle [arm64 armhf armel mips64el mipsel ppc64el s390x alpha hppa hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k powerpc ppc64 risc64 sh4 sparc64] -- ROM; Currently FTBFS for non-I

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-med-packag...@lists.alioth.debian.org

Hi,

the new upstream version of muscle is using some ASM statements which
are only available on Intel (and compatible) architectures.  This is
known to upstream and they are working on this[1].  Since muscle would
be nice to have in testing at least for the architectures where it
currently builds please remove all failing architectures for the moment.

Thanks a lot for your work as ftpmaster

  Andreas.


[1] https://github.com/rcedgar/muscle/issues/25
https://github.com/rcedgar/muscle/issues/22

Bug#993350: xsane: Scanimage detects scanner but Xsane won't start it

[Hans Georg Colle]

Hi,
after updating libsane1 yesterday xsane works as expected.
Georg

Bug#1005861: bullseye-pu: package pdb2pqr/2.1.1+dfsg-7+deb11u1

[Andrius Merkys]

On 2022-02-19 19:52, Adam D. Barratt wrote:
> Please go ahead.

Thanks, uploaded.

Best wishes,
Andrius

Bug#979407: amd64-microcode: Amd64 microcode is not being loaded by the kernel from early initramfs.

[Shmerl]

On Wed, 06 Jan 2021 10:39:38 + Philip Armstrong 
wrote:
> if I trigger a microcode
> load from the shell with
>
>   echo 1 > /sys/devices/system/cpu/microcode/reload
>
> after booting then the microcode is updated to that newer version.

How do you check the current version of microcode in use?

Since amd64-microcode package is so outdated in Debian, I updated microcode
files manually from
the upstream Linux firmware repo, putting them in
/usr/lib/firmware/amd-ucode. Then I ran
sudo dpkg-recoconfigure amd64-microcode hoping it will update it.

On next reboot I have the same version as before (basically what's in my
UEFI)
according to dmesg.

Doing echo 1 > /sys/devices/system/cpu/microcode/reload and checking
/proc/cpuinfo
I also don't see any change.

Thanks,
Shmerl.

Bug#1004678: git-lfs: allow offline operation

[Stephen Gelman]

 Thanks for reporting this. I agree that it sounds useful, though it might
be very challenging due to the decentralized nature of git-lfs. I’m happy
to keep this bug open, but it seems better served for the upstream tracker
at https://github.com/git-lfs/git-lfs/issues.

Stephen

On Jan 31, 2022 at 9:50:31 AM, Barak A. Pearlmutter 
wrote:

> Package: git-lfs
> Version: 3.0.2-1
> Severity: wishlist
> X-Debbugs-Cc: none, Barak A. Pearlmutter 
>
> I have a repo whose only remote is on a gitlab instance. I'm using
> git-lfs to manage large binary files in this repo. The remote goes down.
> Now "git add foo.pdf / git commit", when *.pdf files are tracked by lfs,
> freezes! Waits forever for the remote when trying to transfer the big
> blobs.
>
> This violates what I consider a central concept of git, namely that
> operations are local unless you explicitly fetch or push. It means you
> cannot work with lfs while offline, like on an aeroplane, or even (as
> above) when the gitlab instance is offline for maintenance.
>
> There is also a potential security issue. Users might reasonably assume
> they can safely do "git add/commit/rebase" operations locally, with
> intermediate steps exposing secret information that is later removed
> before doing a push. Nope!
>
> Anyway: I *wish* git-lfs allowed remote operation, like git-annex does.
> It seems like it should be technically possible to wait until an
> lfs-tracked file (well, its https://git-lfs.github.com/spec/v1 smudge
> stub) is actually pushed before transferring the associated big binary
> blob. Or at the very least, giving up and remembering to try again later
> if there's a big binary blob transfer problem.
>
> -- System Information:
> Versions of packages git-lfs depends on:
> ii  git1:2.34.1-1
> ii  libc6  2.33-5
>
>

Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1

[Daniel Kahn Gillmor]

On Sat 2022-02-19 17:09:21 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
>
> On Thu, 2022-01-27 at 17:02 -0500, Daniel Kahn Gillmor wrote:
>> Please consider an update to GnuPG in debian bullseye, from version
>> 2.2.27-2 to 2.2.27-2+deb11u1.
>> 
>
> The version mentioned above is correct, but the proposed changelog is
> not:
>
> +gnupg2 (2.2.27-2+deb11+1) bullseye; urgency=medium
>
> (it should be "deb11u1", not "deb11+1").

thanks for catching that, i've corrected it and pushed the corrected
version to the debian/bullseye branch in salsa.

> That looks fine to me, but will need a d-i ack as the package builds a
> udeb; tagging and CCing accordingly.

Understood -- i'll wait for a d-i ack before uploading.

   --dkg


signature.asc
Description: PGP signature

Bug#1006159: orphan-sysvinit-scripts: request backport of 0.08 or later to bullseye-backports

[Chen-Yu Tsai]

Package: orphan-sysvinit-scripts
Version: 0.07
Severity: important

Dear Maintainer,

rsyslog 8.2110.0-4 was backported to bullseye-backports a couple months
ago. This version no longer contains the SysV init script, which was
removed in 8.2110.0-2.

Anyone still running sysvinit on bullseye-backports would likely be
caught off guard and left with a non-functioning syslog after an upgrade.

Would it be possible to backport orphan-sysvinit-scripts 0.08 (or later)
to bullseye-backport to cover such a situation?


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages orphan-sysvinit-scripts depends on:
ii  ucf  3.0043

orphan-sysvinit-scripts recommends no packages.

orphan-sysvinit-scripts suggests no packages.

Bug#1006158: RFP: webp-pixbuf-loader -- WebP GDK Pixbuf Loader library

[Matti Palmström]

Package: wnpp
Severity: wishlist

* Package name: webp-pixbuf-loader
  Version : 0.0.3
  Upstream Author : Alberto Ruiz 
* URL : https://github.com/aruiz/webp-pixbuf-loader
* License : LGPL-2
  Programming Lang: C
  Description : Add support for WebP to different programs using
the GDK Pixbuf Loader library.

Bug#1006157: /lib/modules/5.16.0-1-sparc64-smp/kernel/fs/ext4/ext4.ko: [sparc64+ext4] reads see zeros w/ simultaneous write

[Noah Misch]

Package: src:linux
Version: 5.16.7-2
Severity: normal
File: /lib/modules/5.16.0-1-sparc64-smp/kernel/fs/ext4/ext4.ko

Dear Maintainer,

   * What led up to the situation?

The context is an ext4 filesystem on a sparc64 host.  I've observed
this with each of the three sparc64 kernels that I've tested.  Those
kernels were 5.16.0-1-sparc64-smp (this report), 5.15.0-2-sparc64-smp,
and 4.9.0-13-sparc64-smp.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

See the included file for a minimal test program.  It creates two
processes, each of which loops indefinitely.  One opens a file, writes
0x1 to a 256-byte region, and closes the file.  The other process
opens the same file, reads the same region, and prints a message if
any byte is not 0x1.

This thread has more discussion and a more-configurable test program:
https://postgr.es/m/flat/20220116071210.ga735...@rfd.leadboat.com

   * What was the outcome of this action?

The program prints messages, at least ten per second.  The mismatch
always appears at an offset divisible by eight.  Some offsets are more
common than others.  Here's output from 300s of runtime, filtered
through "sort -nk3 | uniq -c":

   1729 mismatch at 8: got 0, want 1
   1878 mismatch at 16: got 0, want 1
   1030 mismatch at 24: got 0, want 1
 41 mismatch at 40: got 0, want 1
373 mismatch at 48: got 0, want 1
 24 mismatch at 56: got 0, want 1
349 mismatch at 64: got 0, want 1
  13525 mismatch at 72: got 0, want 1
401 mismatch at 80: got 0, want 1
365 mismatch at 88: got 0, want 1
  1 mismatch at 96: got 0, want 1
 32 mismatch at 104: got 0, want 1
 34 mismatch at 112: got 0, want 1
 19 mismatch at 120: got 0, want 1
 34 mismatch at 128: got 0, want 1
253 mismatch at 136: got 0, want 1
149 mismatch at 144: got 0, want 1
138 mismatch at 152: got 0, want 1
  1 mismatch at 160: got 0, want 1
  4 mismatch at 168: got 0, want 1
  7 mismatch at 176: got 0, want 1
  4 mismatch at 184: got 0, want 1
  1 mismatch at 192: got 0, want 1
 83 mismatch at 200: got 0, want 1
 58 mismatch at 208: got 0, want 1
   3301 mismatch at 216: got 0, want 1
  2 mismatch at 232: got 0, want 1
  1 mismatch at 248: got 0, want 1

If I run the program atop an xfs filesystem (still with sparc64), it
prints nothing.  If I run it with x86_64 or powerpc64 (atop ext4), it
prints nothing.

   * What outcome did you expect instead?

I expected the program to print nothing, indicating that the reader
process observes only 0x1 bytes.  That is how x86_64+ext4 behaves.

POSIX is stricter, requiring read() and write() implementations such
that "each call shall either see all of the specified effects of the
other call, or none of them"
(https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_07).
ext4 does not conform, which may be pragmatic.  However, with x86_64
and powerpc64, readers see each byte as either its before-write value
or its after-write value.  They don't see a zero in an offset that
will have been nonzero both before and after the ongoing write().


-- Package-specific info:
** Version:
Linux version 5.16.0-1-sparc64-smp (debian-ker...@lists.debian.org) (gcc-11 
(Debian 11.2.0-16) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37.90.20220130) 
#1 SMP Debian 5.16.7-1 (2022-02-06)

** Command line:
BOOT_IMAGE=/vmlinux-5.16.0-1-sparc64-smp root=/dev/mapper/vg1-nroot ro

** Tainted: E (8192)
 * unsigned module was loaded

** Kernel log:
[344103.150402] null-4.exe[3045591]: segfault at 0 ip 01000990 (rpc 
01000984) sp 07feff952831 error 1 in null-4.exe[100+2000]
[344103.533876] null-4.exe[3045722]: segfault at 8 ip 01000990 (rpc 
01000984) sp 07feffa8c841 error 1 in null-4.exe[100+2000]
[344103.911758] null-4.exe[3045896]: segfault at 8 ip 010007e4 (rpc 
010007dc) sp 07feffeec841 error 1 in null-4.exe[100+2000]
[344104.319288] null-4.exe[3046052]: segfault at 8 ip 010007e4 (rpc 
010007dc) sp 07feffa2e841 error 1 in null-4.exe[100+2000]
[344104.703441] null-4.exe[3046206]: segfault at 8 ip 010007c8 (rpc 
010007bc) sp 07feffeb8841 error 1 in null-4.exe[100+2000]
[344105.411714] null-4.exe[3046494]: segfault at 8 ip 010007e4 (rpc 
010007dc) sp 07feff9ec841 error 1 in null-4.exe[100+2000]
[344105.921598] null-4.exe[3046699]: segfault at 8 ip 010007e4 (rpc 
010007dc) sp 07feffd3a841 error 1 in null-4.exe[100+2000]
[344106.302875] null-5.exe[3046860]: segfault at 0 ip 010009b0 (rpc 
010009a4) sp 07feffbc6831 error 1 in null-5.exe[100+2000]
[344107.467462] show_signal_msg: 2 callbacks suppressed
[344107.467472] null-5.exe[3047293]: segfault at 0 ip 010007f0 (rpc 
010007dc) sp 07feff9a8841 error 1 in null-5.exe[100+2000]

Bug#996028: [debian-mysql] Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Otto Kekäläinen]

Control: reassign -1 mariadb-server-10.3
Control: tags moreinfo

Hello!

Is the issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996028
still affecting people? Did anybody figure out the root cause or what
upstream issue it was, or what version it was fixed in?

Bug#975911: [debian-mysql] Bug#975911: mariadb-client and libedit

[Otto Kekäläinen]

Hello!

If somebody wants to continue to work on this issue[1], please submit
your packaging improvement suggestion as a Merge Request on Salsa[2].
I promise to review them promptly.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975911
[2] 
https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian

Bug#917872: Ensure Mroonga plugin install/upgrade/uninstall for MariaDB

[Otto Kekäläinen]

Package: mariadb-plugin-mroonga
Version: 10.6.5-1
Severity: normal
Tags: newcomer

Hello!

If somebody wants to continue working on this[1] newcomer friendly tagged
bug report, please submit Merge Requests[2].

I promise to review them quickly.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917872
[2] 
https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian

Bug#1006111: [debian-mysql] Bug#1006111: mariadb-server: wrong groupby result in newly filled myISAM table

[Otto Kekäläinen]

Hello!

Thanks for using MariaDB. In the scope of Debian packaging we do not
fix upstream bugs. If you have a reproducible test case you could file
bug report upstream.

We are in the process of uploading 10.3.34, 10.5.15 and 10.6.7 to
Debian. If these versions fix the issue then we can mark the issue
resolved for Debian.

Bug#1005737: Purging sane-utils deletes the scanner group, created by libsane1

[David Ward]

Package: sane-utils
Version: 1.1.1-2
Severity: serious

(The original title and description of this bug were inaccurate; please 
disregard those. The existing pull request has been updated.)


When the libsane1 package is installed, a "scanner" group is created on 
the system, which has access to the device nodes for local scanners.


If the sane-utils package is also installed, it creates a "saned" user 
and group for running the network daemon. By default, the "saned" user 
is added to the "scanner" group, so that the daemon has access to local 
scanners (but this behavior is controlled using debconf).


If the sane-utils package is purged, it not only deletes the "saned" 
user and group, but it also unconditionally deletes the "scanner" group, 
which it did not create and which libsane1 still uses for device node 
permissions. (Assuming sane-utils was purged alone, attempting to 
reinstall it will also fail during the configure phase, since the 
"saned" user cannot be added to the missing "scanner" group.)

Bug#1002291: bpfcc: Fails to build with libbpf/0.6.1-1

[Sudip Mukherjee]

On Sat, Feb 19, 2022 at 5:36 AM Vasudev Kamath  wrote:
>
> Sudip Mukherjee  writes:
>
> > I have now uploaded libbpf/0.7.0 to experimental, can you please try
> > building bpfcc and let me know if it works for you.
> >
>
> I'm ending up getting different error now related to deprecation.

I am not sure why and how you are getting the error. I have tried
building bpfcc_0.22.0+ds-2 with sbuild and have also tried building in
an unstable VM with dpkg-buildpackage and in both the cases it has
built fine with libbpf/0.7.0


-- 
Regards
Sudip

Bug#1005402: Abuses netfilter conntrack notifier API

[Ben Hutchings]

On Fri, 2022-02-18 at 23:23 +0100, Axel Beckert wrote:
> Control: tag -1 - moreinfo
> 
> Hi Ben,
> 
> Ben Hutchings wrote:
> > > What would be the impact if I don't disable this feature? Can you
> > > please elaborate?
> > 
> > Then the module will not report all the events that might be expected.
> 
> I see. That's indeed not what I'd expected so far.
[...]

Sorry, I read your question wrongly before.

The impact if you *don't* disable the feature includes:

- If nf_conntrack_netlink is loaded after iptables-netflow, the kernel
  will log a WARNING and disable NAT event reporting through
  iptables-netflow
- If nf_conntrack_netlink is loaded before iptables-netflow and then
  removed, the kernel will disable NAT event reporting through
  iptables-netflow

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?


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

Bug#1005884: linux-image-5.16.0-1-amd64: Kernel oops (unable to handle page fault) during boot

[Richard B. Kreckel]

Hi Salvatore,

On 19.02.22 20:31, Salvatore Bonaccorso wrote:
> Alright thank you for confirming that. Would it be possible that you
> as well build the kernel with
> https://git.kernel.org/linus/bea2662e7818e15d7607d17d57912ac984275d94
> applied on top to see if this resolved the issue?

Yes that patch fixes it.

  -richy.
-- 
Richard B. Kreckel

Bug#1006156: ITP: parolottero -- compose words using a 4x4 grid of letters

[Salvo "LtWorf" Tomaselli]

Package: wnpp
Severity: wishlist
Owner: "Salvo \"LtWorf\" Tomaselli" 
X-Debbugs-Cc: debian-de...@lists.debian.org, tipos...@tiscali.it

* Package name: parolottero
  Version : 1.0
  Upstream Author : Salvo "LtWorf" Tomaselli 
* URL : https://github.com/ltworf/parolottero
* License : AGPL3
  Programming Lang: C++
  Description : compose words using a 4x4 grid of letters

It's a word game intended for mobile.

A grid is generated with random letters, and one drags the finger
or the mouse to make words, that are checked against a dictionary.

For now 3 languages are present, but adding more is quite trivial.

Intended mostly for my pinephone, but works also on desktop, though
it's a bit annoying to play with the mouse.

Bug#1006155: ITP: explosive-c4 -- four in a row game, mostly for phones, but works on desktop too

[Salvo "LtWorf" Tomaselli]

Package: wnpp
Severity: wishlist
Owner: "Salvo \"LtWorf\" Tomaselli" 
X-Debbugs-Cc: debian-de...@lists.debian.org, tipos...@tiscali.it

* Package name: explosive-c4
  Version : 1.0
  Upstream Author : Salvo "LtWorf" Tomaselli 
* URL : https://github.com/ltworf/explosive-c4
* License : AGPL3
  Programming Lang: C++
  Description : four in a row game, mostly for phones, but works on desktop 
too

It's a four in a row game, two players can play on the same machine or one can
play against the AI.

Made in Qt, originally for Android.

Since I now have a pinephone with mobian, I thought it might be a nice addition
to have, to the very few games available.

Bug#1006154: nmu: evolution-rss_0.3.96-4

[Jeremy Bicha]

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

Please schedule this rebuild to finish the auto-upperlimit evolution
3.43 mini-transition:

nmu evolution-rss_0.3.96-4 . ANY . unstable . -m "Rebuild against
evolution 3.43"

Thanks,
Jeremy Bicha

Bug#1005959: mig-for-host:amd64 should not exist

[Samuel Thibault]

Hello,

Helmut Grohne, le ven. 18 févr. 2022 14:13:09 +0100, a ecrit:
> On Fri, Feb 18, 2022 at 12:45:57PM +0100, Guillem Jover wrote:
> > Just to spell out, what might perhaps be obvious here, but I think
> > they key is that MIG is "kernel independent", so it provides an
> > interface which is none- which means it can be used on any-
> > to target hurd-. Perhaps this should be mentioned in the packages
> > description, because otherwise I agree it seems a bit confusing?
> 
> Thank you. In that case, I think it shouldn't be mig-x86-64-linux-gnu
> nor mig-x86-64-gnu nor mig-x86-64-kfreebsd-gnu, but simply mig-x86-64 as
> that's what it is specific to.

Mmm, it still targets hurd- explicitly, so I'd say it should still
be called mig-x86-64-gnu.

What I'm wondering is why we added -linux/-kfreebsd since here they are
host, not target. The package name is supposed to designated the target
doesn't it?  I'm actually now unsure what "mig-for-host" was supposed to
mean.  AIUI we'd want it to pull a native-for-host binary that targets
the architecture equivalent on the hurd port. E.g. on linux-amd64 it'd
pull a linux-amd64 x86-64-gnu-mig binary.  Currently gnumach is fine
with this

checking for i686-gnu-mig... i686-linux-gnu-mig

but that's still relatively bogus.

Samuel

Bug#1006148: Chromium constantly tries to access CPUFreq API in VMs

[MichaIng]

Package: chromium
Version: 98.0.4758.102-1~deb11u1

Ah sorry, my bad, the errors do show up on version 98.0.4758.102-1~deb11u1.

So then it is not an upstream issue but a difference between the build 
or environment on Bullseye vs Bookworm.


Best regards,

Micha

Bug#1005995: espeakup: not systemd support

[Samuel Thibault]

Control: tags -1 +moreinfo

Hello,

espeakup does have systemd support.

Bardot Jerome, le ven. 18 févr. 2022 18:55:45 +0100, a ecrit:
> update-rc.d: warning: start and stop actions are no longer supported; falling
> back to defaults
> Restarting Speakup/espeak connector: espeakup failed!
> invoke-rc.d: initscript espeakup, action "restart" failed.

How did you get these? What command did you type? Also

systemctl status espeakup

will tell us a lot about what actually happened beyond "failed".

Samuel

Bug#1006140: New version can't load old databases

[Markus Koschany]

Am Samstag, dem 19.02.2022 um 23:13 +0100 schrieb Jochen Sprickerhof:
> * Markus Koschany  [2022-02-19 22:38]:
> > Ok. Did you file an upstream bug report already?
> 
> I did not yet. Upstream bundles the old binary version so I don't think 
> I can convince them to do a quick migration.
> But I will open a bug to get it fixed there.
> 
> > The old version of H2 is already present in Ubuntu or Debian stable. You
> > could
> > either ask users to execute all those commands manually (README.Debian,
> > Debian.NEWS) or there could be some kind of pre/post hook script that does
> > all
> > that automatically.
> 
> Asking users to install packages from other releases does not sound 
> convincing. We can't use the pre/post maintainer scripts as the database 
> files could be stored anywhere on disk (default is in $HOME but could 
> even be on a thumb drive). So we can only hook into the jameica 
> executable. I don't think doing this before the Ubuntu jammy freeze is 
> feasible.

I believe there is a misunderstanding somewhere. We don't need to ask users to
install anything. They simply upgrade from an older version to a newer one.
There must be some sort of logic for the database storage. It is possible to
move a file to a different location but your program will always look in the
same place. If your database isn't there, then a good script would ask where it
is, you enter the new location and the program proceeds. 

> > For a quick solution you could upload 1.4.197 again based on the version in
> > Bullseye
> 
> Thanks, I will do that, i.e. I will upload 2.1.210+really1.4.197-1 = 
> 1.4.197-4+deb11u1 as proposed in my initial bug report.
> 
> > but this doesn't really solve the problem.
> 
> Can you explain what you mean here?


You only fix your single use case. You keep an unsupported and buggy version of
the H2 database in Debian and this is not how we usually solve problems in
Debian. 


> > As I said we don't need multiple H2 versions in Debian.
> 
> Can you give reasons why you think so? As I stated multiple times I 
> don't see a way not to have multiple versions available in one release 
> to support the migration.

You don't need multiple version of H2 in Bookworm. We ship 1.4.197 in Bullseye
and 2.x in Bookworm, that's it. When users upgrade from Bullseye to Bookworm,
they either have to perform some manual migration steps, or the package takes
care of them automatically. That's how it works for every package in Debian. We
also don't ship multiple Tomcat or Jetty, MariaDB or PostgreSQL versions in
stable releases because we support only one of them for their life cycle. This
is because of security and maintenance reasons, otherwise we would have
multiple versions of every piece of Java software in Debian and we could stop
using system libraries and instead bundle everything together in fat jars. At
one point you have to upgrade to a newer H2 database, that's a fact and it
should happen before we freeze for Bookworm.

> > You should only do that if you are willing to
> > support an officially unsupported piece of software for the next Debian 12
> > LTS
> > cycle until the year 2028. And that means taking care of all other libh2-
> > java
> > dependencies too, dealing with people who request an upgrade to 2.x because
> > their use case depends on it, etc. And you and the rest of the users should
> > be
> > fine with the disabled H2 console and all the other bugs in that version.
> 
> That would be fine with me.

Ok, that's your choice but please add yourself to the list of Uploaders and
keep an eye on all H2 bug reports from now on because I won't. ;>




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

Bug#1006152: mozjs91: FTBFS on i386: test262/built-ins/Date/UTC/fp-evaluation-order.js

[Simon McVittie]

Source: mozjs91
Version: 91.6.0-1
Severity: serious
Tags: ftbfs

After applying patches to fix compilation on i386 and mipsel (see commits
3f0f229d, 585dadd4) there is a test failure unresolved on i386:

## test262/built-ins/Date/UTC/fp-evaluation-order.js: rc = 3, run time = 
0.022397
/home/smcv/mozjs/js/src/tests/test262/shell.js:415:9 uncaught exception: 
Test262Error: order of operations / precision in MakeTime Expected 
SameValue(«29256», «29312») to be true
Stack:
  Test262Error.thrower@/home/smcv/mozjs/js/src/tests/test262/shell.js:415:9
  assert.sameValue@/home/smcv/mozjs/js/src/tests/test262/shell.js:51:9
  
@/home/smcv/mozjs/js/src/tests/test262/built-ins/Date/UTC/fp-evaluation-order.js:19:8
TEST-UNEXPECTED-FAIL | test262/built-ins/Date/UTC/fp-evaluation-order.js | 
(args: "") [0.0 s]

mipsel is still running tests on eller, I'll open a separate bug if
there are unexpected failures.

smcv

Bug#1006151: fakeroot: assumes linuxish stat version

[Samuel Thibault]

Package: fakeroot
Version: 1.27-1
Severity: important
Tags: patch

Hello,

When redirecting the xstat functions, fakeroot is passing _STAT_VER
but it assumes it should pass the Linux values, making it unusable on
non-Linux. The attached patch fixes it by checking for __linux__, and
add the GNU/Hurd case.

Samuel

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

Kernel: Linux 5.16.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 fakeroot depends on:
ii  libc62.33-6
ii  libfakeroot  1.27-1

fakeroot recommends no packages.

fakeroot suggests no packages.

-- no debconf information
Index: fakeroot-1.27/libfakeroot.c
===
--- fakeroot-1.27.orig/libfakeroot.c
+++ fakeroot-1.27/libfakeroot.c
@@ -96,18 +96,22 @@
 #endif
 
 #ifndef _STAT_VER
- #if defined (__aarch64__)
-  #define _STAT_VER 0
- #elif defined (__powerpc__) && __WORDSIZE == 64
-  #define _STAT_VER 1
- #elif defined (__riscv) && __riscv_xlen==64
-  #define _STAT_VER 0
- #elif defined (__s390x__)
-  #define _STAT_VER 1
- #elif defined (__x86_64__)
-  #define _STAT_VER 1
- #else
-  #define _STAT_VER 3
+ #if defined __linux__
+  #if defined (__aarch64__)
+   #define _STAT_VER 0
+  #elif defined (__powerpc__) && __WORDSIZE == 64
+   #define _STAT_VER 1
+  #elif defined (__riscv) && __riscv_xlen==64
+   #define _STAT_VER 0
+  #elif defined (__s390x__)
+   #define _STAT_VER 1
+  #elif defined (__x86_64__)
+   #define _STAT_VER 1
+  #else
+   #define _STAT_VER 3
+  #endif
+ #elif defined __GNU__
+   #define _STAT_VER 0
  #endif
 #endif
 

Bug#1004407: ITS: dfu-util

[Tormod Volden]

dfu-util 0.11-1 has been uploaded to the DELAYED queue with a delay of
7 days, see attached nmudiff.

Tormod


dfu-util-0.11-1.nmudiff
Description: Binary data

Bug#1006150: python3-pip: Error when trying to list packages that need to be updated (local and system-wide)

[Christian Britz]

Package: python3-pip
Version: 20.3.4-4
Severity: normal
X-Debbugs-Cc: cbr...@t-online.de

Dear Maintainer,

I am trying to list Python3 packages which need to be updated. Running "pip
list --user --outdated" I get the following error. This happens also, when I
run "sudo pip list --outdated", so I think it is not related to my user
profile.

ERROR: Exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/base_command.py", line
223, in _main
status = self.run(options, args)
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line
175, in run
packages = self.get_outdated(packages, options)
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line
184, in get_outdated
return [
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line
184, in 
return [
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line
237, in iter_packages_latest_infos
for dist in map_multithread(latest_info, packages):
  File "/usr/lib/python3.9/multiprocessing/pool.py", line 870, in next
raise value
  File "/usr/lib/python3.9/multiprocessing/pool.py", line 125, in worker
result = (True, func(*args, **kwds))
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/list.py", line
214, in latest_info
all_candidates = finder.find_all_candidates(dist.key)
  File "/usr/lib/python3/dist-packages/pip/_internal/index/package_finder.py",
line 825, in find_all_candidates
package_links = self.process_project_url(
  File "/usr/lib/python3/dist-packages/pip/_internal/index/package_finder.py",
line 793, in process_project_url
page_links = list(parse_links(html_page))
  File "/usr/lib/python3/dist-packages/pip/_internal/index/collector.py", line
324, in wrapper_wrapper
return list(fn(page))
  File "/usr/lib/python3/dist-packages/pip/_internal/index/collector.py", line
335, in parse_links
document = html5lib.parse(
  File "/usr/share/python-wheels/html5lib-1.1-py2.py3-none-
any.whl/html5lib/html5parser.py", line 44, in parse
tb = treebuilders.getTreeBuilder(treebuilder)
  File "/usr/share/python-wheels/html5lib-1.1-py2.py3-none-
any.whl/html5lib/treebuilders/__init__.py", line 85, in getTreeBuilder
return etree.getETreeModule(implementation, **kwargs).TreeBuilder
AttributeError: module 'html5lib.treebuilders.etree' has no attribute
'getETreeModule'


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

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

Versions of packages python3-pip depends on:
ii  ca-certificates 20210119
ii  python-pip-whl  20.3.4-4
ii  python3 3.9.2-3
ii  python3-distutils   3.9.2-1
ii  python3-setuptools  52.0.0-4
ii  python3-wheel   0.34.2-1

Versions of packages python3-pip recommends:
ii  build-essential  12.9
ii  python3-dev  3.9.2-3

python3-pip suggests no packages.

Bug#1006017: playitslowly doesn't start (hasn't for awhile)

[Andreas Beckmann]

Followup-For: Bug #1006017
Control: found -1 1.5.0-1

This seems to go back to stretch:

# xvfb-run playitslowly
Traceback (most recent call last):
  File "", line 890, in _find_spec
AttributeError: 'DynamicImporter' object has no attribute 'find_spec'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/playitslowly/app.py", line 36, in 

from gi.repository import Gtk, GObject, Gst, Gio, Gdk
  File "/usr/lib/python3/dist-packages/gi/importer.py", line 127, in find_module
'introspection typelib not found' % namespace)
ImportError: cannot import name Gtk, introspection typelib not found


Andreas

Bug#1006140: New version can't load old databases

[Markus Koschany]

Hi Jochen,

Am Samstag, dem 19.02.2022 um 21:21 +0100 schrieb Jochen Sprickerhof:
> Hi Markus,
> 
> thanks for your quick reply.
> 
> * Markus Koschany  [2022-02-19 21:01]:
> > That means only hibiscus/jameica require our attention. I would try to
> > remove
> > the obsolete connection setting mentioned in #1005838.
> 
> Tried that already, did not solve the problem.


Ok. Did you file an upstream bug report already?

> 
> > You could also try to
> > dump the SQL database with the current version in stable and then try to
> > re-
> > import the SQL tables with H2 in unstable. That should actually work
> > because
> > the SQL syntax will not have changed. (See also the Upgrading paragraph
> > here
> > https://h2database.com/html/migration-to-v2.html)
> 
> That would be the plan, yes. But for that we would need to provide both 
> versions to our users, thus I propose to upload the new version as a new 
> source and binary package.
> 
> Also the SQL syntax did change.
[...]
> Can you explain how you want to implement this re-import feature then?


I don't think the SQL syntax itself did change. SQL is a separate language and
different SQL databases must be compatible in this regard. MySQL, MariaDB,
hsqldb, H2, they all should be able to read and write SQL. If H2 changed some
H2 specific commands, then all we have to do is to execute a command for the
old H2 database to dump the old database and then use another command to re-
import the database into H2 2.x. 

The old version of H2 is already present in Ubuntu or Debian stable. You could
either ask users to execute all those commands manually (README.Debian,
Debian.NEWS) or there could be some kind of pre/post hook script that does all
that automatically. 

I would try to solve that problem on the package level though, and ask upstream
to come up with a migration plan because sticking with 1.4.x forever is not a
great plan.

> I would really appreciate a quick solution here so users of the next 
> Ubuntu version would not be locked out of their homebanking system.
> 
> I'm happy to help with uploading new versions and NEW is rather empty 
> currently so I don't see the point in not doing a proper transition 
> here.

For a quick solution you could upload 1.4.197 again based on the version in
Bullseye but this doesn't really solve the problem. As I said we don't need
multiple H2 versions in Debian. You should only do that if you are willing to
support an officially unsupported piece of software for the next Debian 12 LTS
cycle until the year 2028. And that means taking care of all other libh2-java
dependencies too, dealing with people who request an upgrade to 2.x because
their use case depends on it, etc. And you and the rest of the users should be
fine with the disabled H2 console and all the other bugs in that version. 



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

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Diederik de Haas]

On Saturday, 19 February 2022 22:04:14 CET Petra R.-P. wrote:
> Package: src:linux
> Version: 5.16.7-2
> 
> This new kernel version does not boot on two fairly similar
> old IBM T41 Thinkpads.
> ...
> linux-image-5.15.0-3-686, which I am using to write this
> message, runs fine.
> 
> pn  firmware-iwlwifi  

I see you don't have firmware-iwlwifi installed, but there have been other bug 
reports which could be similar, so with the 5.15 kernel, do you have the 
'iwlwifi' kernel module loaded? If so, could you blacklist that and try to 
reboot into the 5.16 kernel and see whether it then works?

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005884#17

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

Bug#995224: [Debian-med-packaging] Bug#995224: relion-cuda: FTBFS with cub 1.14

[Andreas Beckmann]

On 19/02/2022 20.13, Sascha Steinbiss wrote:

79 | #error The version of CUB in your include path is not compatible
with this release of Thrust. CUB is now included in the CUDA Toolkit, so
you no longer need to use your own checkout of CUB. Define
THRUST_IGNORE_CUB_VERSION_CHECK to ignore this.
   |  ^


Currently thrust and cub are out of sync. I got somewhat distracted ... 
trying to add some autopkg tests.
But this bug points out that thrust should have a tighter dependency on 
cub (not only >= upstreamversion , but also << upstreamversion+1).


If you want to blame anything, it's thrust.

Andreas, trying to fix this soon

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Petra R.-P.]

Package: src:linux
Version: 5.16.7-2
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

This new kernel version does not boot on two fairly similar
old IBM T41 Thinkpads.

What reproducibly happens is as follows:

After the lines

   Loading Linux 5.16.0-1-686 ...
   Loading initial ramdisk ...

the screen gets flushed, and I see:
   
   [  4.xx] ata1.00: Read log 0x00 page 0x00 failed  Emask 0x1
   

The "xx" vary for every try.

Then nothing else happens.
Ctrl-Alt-Del has no effect.
I have to reset the computer by pressing the button.

On an old PC running the same kernel the same message "ata1.00: Read log ..."
appears, but then the boot process continues normally.

linux-image-5.15.0-3-686, which I am using to write this
message, runs fine.


  Thanks for maintaining this package
 and best regards,
   Petra R.-P.


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

** Model information

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 82855PM Processor to I/O 
Controller [8086:3340] (rev 03)
Subsystem: IBM Thinkpad T40 series [1014:0529]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: agpgart-intel

00:01.0 PCI bridge [0604]: Intel Corporation 82855PM Processor to AGP 
Controller [8086:3341] (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-

00:1d.0 USB controller [0c03]: Intel Corporation 82801DB/DBL/DBM 
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 01) (prog-if 00 
[UHCI])
Subsystem: IBM ThinkPad [1014:052d]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge 
[8086:2448] (rev 81) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-

00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface 
Bridge [8086:24cc] (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 
Kernel driver in use: snd_intel8x0
Kernel modules: snd_intel8x0

00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) 
AC'97 Modem Controller [8086:24c6] (rev 01) (prog-if 00 [Generic])
Subsystem: IBM ThinkPad T4x Series [1014:0524]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: snd_intel8x0m
Kernel modules: snd_intel8x0m

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] RV200/M7 [Mobility Radeon 7500] [1002:4c57] (prog-if 00 [VGA 
controller])
Subsystem: IBM ThinkPad T4x Series [1014:0530]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping+ SERR+ FastB2B+ DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: radeon
Kernel modules: radeonfb, radeon

02:00.0 CardBus bridge [0607]: Texas Instruments PCI4520 PC card Cardbus 
Controller [104c:ac46] (rev 01)
Subsystem: IBM ThinkPad [1014:0552]
Physical Slot: 1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
Capabilities: 
Kernel driver in use: yenta_cardbus
Kernel modules: yenta_socket

02:00.1 CardBus bridge [0607]: Texas Instruments PCI4520 PC card Cardbus 
Controller [104c:ac46] (rev 01)
Subsystem: IBM ThinkPad [1014:0552]
Physical Slot: 1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- Reset+ 

Bug#1006147: Merge request

[Dave Jones]

I've now submitted the following merge request for this issue:

https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/10


Best regards,

Dave Jones.

Bug#1006148: Chromium constantly tries to access CPUFreq API in VMs

[MichaIng]

Package: chromium
Version: 90.0.4430.212-1

Hey guys,

I recognised that Chromium on Bullseye is constantly trying to access 
the CPUFreq API, even when it runs within a VM where this API is 
expected to be not available. This triggers constant error messages:

---
*** stack smashing detected ***: terminated
[0219/213510.894782:ERROR:file_io_posix.cc(144)] open 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or 
directory (2)
[0219/213510.895538:ERROR:file_io_posix.cc(144)] open 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or 
directory (2)

*** stack smashing detected ***: terminated
[0219/213511.092091:ERROR:file_io_posix.cc(144)] open 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or 
directory (2)
[0219/213511.093493:ERROR:file_io_posix.cc(144)] open 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or 
directory (2)

---

This does not happen on Bookworm, so likely it got fixed upstream in the 
meantime? Probably this fix can be cherry picked for Debian Bullseye?


Best regards,

Micha

Bug#1005336: RFS: srpc/0.9.6 [ITP] Sogou RPC Library

[Adam Borowski]

On Fri, Feb 11, 2022 at 01:42:57PM +, Lance Lin wrote:
>  * Package name: srpc
>Version : 0.9.6

>   dget -x https://mentors.debian.net/debian/pool/main/s/srpc/srpc_0.9.6-1.dsc

Hi!
I'm afraid the package fails to build, it needs a Build-Depend on
liblz4-dev.

Some files are "Copyright 2019, OpenTelemetry Authors" without being
mentioned in debian/copyright.

You install /usr/bin/srpc_generator to libsrpc-dev yet
/usr/share/man/man1/srpc_generator.1.gz to libsrpc -- they should be in
the same package.

The runtime library package should have a soname included in its name;
this will allow ABI bumps in the future.

The -dev package can't be "Multi-Arch: foreign" as its architecture must
match whatever [Build-]Depends on it.  Currently, if you want to build
a riscv64 package on an amd64 host, M-A: foreign would allow:
compiler:riscv64
libsrpc-dev:amd64
libsrpc0:amd64
which won't work.


喵!
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋⠀ Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!

Bug#1005952: [Pkg-javascript-devel] RFP: libjs-vega -- programmed web graphics with JSON

[Nilesh Patra]

On 19 February 2022 7:47:29 pm IST, Yadd  wrote:
>Package is ready in https://salsa.debian.org/js-team/vega.js
>
>To build package, remove debian/nodejs/extlinks. This is enough for node-vega 
>but provides probably broken libjs-vega files (I'm unable to test this but 
>rollup warns).
>
>If you keep debian/nodejs/extlinks, rollup will fail and show that d3-* 
>libraries are outdated.
>
>Note that it requires pkg-js-tools 0.12.7. Else you have to add a 
>debian/nodejs/additional_components file with "packages/*" in it.

Thanks, Yadd. @Steffen can you please test it with the qiime package? And see 
that it's rendering okay?

Regards,
Nilesh

Bug#1005952: [Pkg-javascript-devel] RFP: libjs-vega -- programmed web graphics with JSON

[Nilesh Patra]

On 19 February 2022 8:22:24 pm IST, Yadd  wrote:
>Maybe only d3-array should be updated:
>  'quantileSorted' is not exported by
>  ../../../../../usr/share/nodejs/d3-array/src/index.js,
>  imported by src/quantiles.js
>
>I moved debian/nodejs/extlinks to debian/nodejs/extcopies to have better 
>browser files

Thanks again. Do you think it'd be possible to upgrade d3-array in foreseeable 
future?

I have not checked how intrusive this package upgrading could be for reverse 
dependencies, I wonder if you'd have some idea there?

Regards,
Nilesh

Bug#1006140: New version can't load old databases

[Jochen Sprickerhof]

Hi Markus,

thanks for your quick reply.

* Markus Koschany  [2022-02-19 21:01]:

That means only hibiscus/jameica require our attention. I would try to remove
the obsolete connection setting mentioned in #1005838.


Tried that already, did not solve the problem.


You could also try to
dump the SQL database with the current version in stable and then try to re-
import the SQL tables with H2 in unstable. That should actually work because
the SQL syntax will not have changed. (See also the Upgrading paragraph here
https://h2database.com/html/migration-to-v2.html)


That would be the plan, yes. But for that we would need to provide both 
versions to our users, thus I propose to upload the new version as a new 
source and binary package.


Also the SQL syntax did change.


I would advise against that plan because

a) jameica/hibiscus is the only affected package

b) the grave security issues would be present again #1003894.

I have fixed the most severe ones in stable releases by disabling the H2
console and JNDI lookups. There are probably more issues mentioned by upstream
here:

https://github.com/h2database/h2database/issues/3360#issuecomment-1018351050

However users would want an up-to-date version of H2 in the future. At some
point an upgrade is inevitable.

c) two source packages make only sense if we talk about an (important) library
that is incompatible and breaks many reverse-dependencies. H2 is a database and
affects only 2 packages.

d) versions 1.4.xxx are no longer supported. 1.4.197 is already four years old.
That makes security support or any support in general not feasible if we want
to release this version again for Bookworm.


I would contact jameica/hibiscus upstream and report this issue as a bug. A
database dump and re-import should be possible in any case and depending on a
supported version of H2 is surely desirable for all parties.


Can you explain how you want to implement this re-import feature then?

I would really appreciate a quick solution here so users of the next 
Ubuntu version would not be locked out of their homebanking system.


I'm happy to help with uploading new versions and NEW is rather empty 
currently so I don't see the point in not doing a proper transition 
here.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#1006147: debconf: dpkg-reconfigure fails to restart services after #994204

[Dave Jones]

Package: debconf
Version: 1.5.73
Severity: important

Dear Maintainer,

As part of fixing an issue with restarting services in debhelper 
(#994204), I proposed a patch [1] that, in certain circumstances (when 
--no-restart-after-upgrade is specified) moves the duty of stopping 
services from the prerm maintainer script to the preinst maintainer 
script (see #994204 for the reasoning behind this change). That fix has 
been merged in Debian, although not yet released. In Ubuntu, the fix has 
also been merged and is currently in our -proposed pocket.

One issue [2] that arose during the testing of the fix was that, for the 
slapd service (part of the openldap package), dpkg-reconfigure now 
failed to restart the service. The slapd service is indeed declared with 
--no-restart-after-upgrade and, and digging into dpkg-reconfigure's code 
I found that it runs prerm, config, and postinst, but not preinst. 
Hence, with services using --no-restart-after-upgrade, prerm no longer 
stops the service and by the time it gets to postinst, the "start" 
operation there has nothing to do.

My assumption is that prerm was only in that sequence to stop services 
(it's seems a little odd to me for it to be in dpkg-reconfigure 
otherwise? Am I missing something else there?). However, I'm guessing 
that replacing prerm with preinst would lead to breakage in packages 
that assume prerm is still run by dpkg-reconfigure. Instead, I'm 
proposing to add preinst to the list of maintainer scripts run by 
dpkg-reconfigure. I'll propose a merge request to the debconf salsa repo 
that adds preinst to the list, and update this with the link shortly.

Many thanks for any attention you can give this, and for any light you 
can shed on my assumptions above. If you need any more detail on the 
reasoning behind the fix for #994204 (and its related issue #989155), 
please let me know.

[1]: https://salsa.debian.org/debian/debhelper/-/merge_requests/61

[2]: https://bugs.launchpad.net/bugs/1959054 (comment # 15 onwards)


Best regards,

Dave Jones.

Bug#1006146: xmonad: gsd-media-keys doesn't start with gnome-flashback-xmonad session

[Chung-chieh Shan]

Package: xmonad
Version: 0.15-4+b2
Severity: normal

Within the last few months, gnome-flashback-xmonad stopped starting
gsd-media-keys when I log in.  Even when I start gsd-media-keys
manually, it fails to adjust screen brightness.  This turns out to fix
it:

cd /usr/lib/systemd/user
sudo cp -a gnome-session@gnome-flashback-metacity.target.d
gnome-session-x11@gnome-flashback-xmonad.target.d

The file 
/usr/lib/systemd/user/gnome-session@gnome-flashback-metacity.target.d/session.conf
is provided by the gnome-session-flashback package, whose changelog
for gnome-flashback 3.38.0-1 says "Update
debian/gnome-session-flashback.install for new systemd session
configuration."

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

Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=en_US.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 xmonad depends on:
ii  libc6 2.33-6
ii  libffi8   3.4.2-4
ii  libgmp10  2:6.2.1+dfsg-3
ii  libx11-6  2:1.7.2-2+b1
ii  libxext6  2:1.3.4-1
ii  libxinerama1  2:1.1.4-3
ii  libxrandr22:1.5.2-1
ii  libxss1   1:1.2.3-1
ii  x11-utils 7.7+5

Versions of packages xmonad recommends:
ii  libghc-xmonad-dev  0.15-4+b2
ii  libghc-xmonad-doc  0.15-4
ii  xfonts-base1:1.0.5

Versions of packages xmonad suggests:
pn  dmenu
ii  gnome-session-flashback  3.42.0-2

-- no debconf information

Bug#1005813: debian-edu-config: apparmor blocks cups-browsed.conf from being read

[Wolfgang Schweer]

[ Petter Reinholdtsen, 2022-02-19 ]
> [Wolfgang Schweer]
> > As the symlink seems to be the problem, another solution would be to
> > let cfengine copy the file instead:
> 
> Sure.  The reason a symlink was used was to ensure upgrades would take
> effect.
 
Right. In case an upgraded debian-edu-config package contains a changed 
cups-browsed-debian-edu.conf file, 'cf-agent -v -D installation' would 
need to be run to update the cups-browsed.conf file.

In the past, the status pages have been updated at point release days to 
cope with changes concerning (among others) the debian-edu-config 
package, including information if a cf-agent run is needed; see:

https://wiki.debian.org/DebianEdu/Status/Buster
and
https://wiki.debian.org/DebianEdu/Status/Bullseye

In case of release upgrades, a cf-agent run is required anyway (like 
documented in the manuals)

Wolfgang


signature.asc
Description: PGP signature

Bug#1003894: fixed in h2database 2.1.210-1

[Markus Koschany]

Control: fixed -1 1.4.197-4+deb10u1
Control: fixed -1 1.4.197-4+deb11u1


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

Bug#1006140: New version can't load old databases

[Markus Koschany]

Hi,

Am Samstag, dem 19.02.2022 um 18:52 +0100 schrieb Jochen Sprickerhof:
> Package: libh2-java
> Version: 2.1.210-1
> Severity: important
> X-Debbugs-Cc: jspri...@debian.org, Markus Koschany 
> Control: -1 affects mediathekview jameica hibiscus
> 
> Hi,
> 
> the new version of libh2-java uses a new SQL syntax and file format and
> is not able to read old data or work with the old syntax:
> 
> https://h2database.com/html/migration-to-v2.html
> 
> This renders all it's users, i.e. mediathekview and jameica/hibiscus,
> unusable.

I had rebuilt all reverse-dependencies of libh2-java and they still can be
built from source. Unfortunately there are runtime problems as you have rightly
pointed out. Actually only mediathekview and jamaica/hibiscus are really
affected. Mediathekview downloads a large json file from the internet (the
filmlist) and then it is converted into a h2 database. Normally it should be
fine to remove the old database and then mediathekview would create a new
database again. Persistent settings are saved in xml files anyway. However I
just noticed at least one SQLException when this happens and the conversion
appears to take forever. Probably solvable but...

the latest version of Mediathekview uses a SQLite database now, because
upstream likes changing dependencies, thus upgrading to the lastest upstream
release would solve the problem.

That means only hibiscus/jameica require our attention. I would try to remove
the obsolete connection setting mentioned in #1005838. You could also try to
dump the SQL database with the current version in stable and then try to re-
import the SQL tables with H2 in unstable. That should actually work because
the SQL syntax will not have changed. (See also the Upgrading paragraph here
https://h2database.com/html/migration-to-v2.html)


> 
> Given that there is no online conversion available, the H2MigrationTool
> actually contains jars of the different version, I would propose to
> upload the v2 version with a new source and binary package name and
> upload the v1 version to unstable again with a +really version number:
> 
> 2.1.210+really1.4.197-1
> 
> based on the git tag debian/1.4.197-4+deb11u1.
> 
> Given that this affects all linked programs and that v2 already
> transitioned to testing as well as the next Ubuntu version (which will
> stop importing from Debian soon) I would like to get this fixed fast.
> 
> I'm planning to upload the +really version tomorrow unless someone
> disagrees.

I would advise against that plan because

a) jameica/hibiscus is the only affected package

b) the grave security issues would be present again #1003894.

 I have fixed the most severe ones in stable releases by disabling the H2
console and JNDI lookups. There are probably more issues mentioned by upstream
here: 

https://github.com/h2database/h2database/issues/3360#issuecomment-1018351050

However users would want an up-to-date version of H2 in the future. At some
point an upgrade is inevitable. 

c) two source packages make only sense if we talk about an (important) library
that is incompatible and breaks many reverse-dependencies. H2 is a database and
affects only 2 packages.

d) versions 1.4.xxx are no longer supported. 1.4.197 is already four years old.
That makes security support or any support in general not feasible if we want
to release this version again for Bookworm.


I would contact jameica/hibiscus upstream and report this issue as a bug. A
database dump and re-import should be possible in any case and depending on a
supported version of H2 is surely desirable for all parties.

Regards,

Markus



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

Bug#1005884: linux-image-5.16.0-1-amd64: Kernel oops (unable to handle page fault) during boot

[Martin Dickopp]

On Sat, Feb 19, 2022 at 03:55:20PM +0100, Salvatore Bonaccorso wrote:
> This is possibly the same as reported in
> https://lore.kernel.org/stable/05b11936073c8d6b7a28c07cc...@stwm.de/
> where the reporter found that the culprit is ab07506b0454 ("iwlwifi:
> fix leaks/bad data after failed firmware load")
> 
> Does the upstream commit bea2662e7818 ("iwlwifi: fix
> use-after-free")[0] fixes the issue for you?
> 
>  [0] https;//git.kernel.org/linus/bea2662e7818e15d7607d17d57912ac984275d94

Yes, this commit fixes the issue for me. Thanks!

Best regards,
Martin

Bug#1006145: RM: primer3 [s390x] -- ROM; Please remove temporarily for s390x to enable testing migration

[Andreas Tille]

Package: ftp.debian.org
Severity: normal


Hi,

it would be great if primer3 could migrate to testing.  For some reason
which is not fully understood the build time test fails on s390x[1]. 
Please remove primer3 on s390x where it is probably not used in practical
applications anyway.

Kind regards and thanks for working as ftpmaster

  Andreas.


[1] 
https://buildd.debian.org/status/fetch.php?pkg=primer3=s390x=2.6.1-2=1645296414=log

Bug#1006144: pychromecast: autopkgtest regression: ModuleNotFoundError: No module named 'requests'

[Paul Gevers]

Source: pychromecast
Version: 9.4.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
pychromecast   from testing9.4.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looks like a 
missing (test) dependency to me.


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=pychromecast

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pychromecast/19345096/log.gz

Testing with python3.10:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pychromecast/__init__.py", line 
12, in 

from .config import *  # noqa: F403
  File "/usr/lib/python3/dist-packages/pychromecast/config.py", line 6, 
in 

import requests
ModuleNotFoundError: No module named 'requests'
autopkgtest [19:10:51]: test autodep8-python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006143: kas: autopkgtest regression: ModuleNotFoundError: No module named 'snack'

[Paul Gevers]

Source: kas
Version: 2.6.3-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
kasfrom testing2.6.3-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looks like a 
missing (test) dependency to me.


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=kas

https://ci.debian.net/data/autopkgtest/testing/amd64/k/kas/19345088/log.gz

= test session starts 
==

platform linux -- Python 3.9.10, pytest-6.2.5, py-1.10.0, pluggy-0.13.0
rootdir: /tmp/autopkgtest-lxc.q1wq9y5j/downtmp/build.jcd/src
collected 26 items

tests/test_build_system.py . 
 [  3%]
tests/test_commands.py .. 
 [ 11%]
tests/test_environment_variables.py .. 
 [ 19%]
tests/test_includehandler.py  
 [ 65%]
tests/test_layers.py  
 [ 80%]
tests/test_menu.py F 
 [ 84%]
tests/test_patch.py F. 
 [ 92%]
tests/test_refspec.py .. 
 [100%]


=== FAILURES 
===
__ test_menu 
___


monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7f62f84bd100>
tmpdir = local('/tmp/pytest-of-debci/pytest-0/test_menu0')

def test_menu(monkeypatch, tmpdir):
tdir = str(tmpdir.mkdir('test_menu'))
shutil.rmtree(tdir, ignore_errors=True)
shutil.copytree('tests/test_menu', tdir)
cwd = os.getcwd()
os.chdir(tdir)
>   monkeypatch.setattr('snack.GridFormHelp.runOnce', mock_runOnce)

/tmp/autopkgtest-lxc.q1wq9y5j/downtmp/build.jcd/src/tests/test_menu.py:64: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ /usr/lib/python3/dist-packages/_pytest/monkeypatch.py:98: in 
derive_importpath

target = resolve(module)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

name = 'snack.GridFormHelp'

def resolve(name: str) -> object:
# Simplified from zope.dottedname.
parts = name.split(".")
used = parts.pop(0)

  found = __import__(used)

E   ModuleNotFoundError: No module named 'snack'

/usr/lib/python3/dist-packages/_pytest/monkeypatch.py:59: 
ModuleNotFoundError
__ test_patch 
__


changedir = None, tmpdir = 
local('/tmp/pytest-of-debci/pytest-0/test_patch0')


def test_patch(changedir, tmpdir):
tdir = str(tmpdir.mkdir('test_patch'))
shutil.rmtree(tdir, ignore_errors=True)

  shutil.copytree('tests/test_patch', tdir)


/tmp/autopkgtest-lxc.q1wq9y5j/downtmp/build.jcd/src/tests/test_patch.py:32: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

src = 'tests/test_patch'
dst = '/tmp/pytest-of-debci/pytest-0/test_patch0/test_patch', symlinks = 
False

ignore = None, copy_function = 
ignore_dangling_symlinks = False, dirs_exist_ok = False

def copytree(src, dst, symlinks=False, ignore=None, 
copy_function=copy2,

 ignore_dangling_symlinks=False, dirs_exist_ok=False):
"""Recursively copy a directory tree and return the destination 
directory.
dirs_exist_ok dictates whether to raise an exception in 
case dst or any

missing parent directory already exists.
If exception(s) occur, an Error is raised with a list of 
reasons.

If the optional symlinks flag is true, symbolic links in the
source tree result in symbolic links in the destination tree; if
it is false, the contents of the files pointed to by symbolic
links are copied. If the file pointed by the symlink doesn't
exist, an exception will be added in the list of errors raised in
an Error exception at the end of the copy process.
You can set the optional ignore_dangling_symlinks flag to 
true if you

want to silence this exception. Notice that this has no effect on
platforms that don't support os.symlink.
The optional ignore argument is a callable. If given, it
is called with the `src` parameter, which is the directory
being visited by copytree(), and `names` which is the list of
`src` contents, as returned by os.listdir():
callable(src, names) -> ignored_names
Since copytree() 

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

[Michael Biebl]

On Sun, 23 Jan 2022 22:59:21 +0200 Adrian Bunk  wrote:

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

  * CVE-2019-17041: Heap overflow in the AIX message parser.
(Closes: #942067)
  * CVE-2019-17042: Heap overflow in the Cisco log message parser.
(Closes: #942065)


Adrian,

can you please push your changes (once uploaded), to a
debian/buster branch (including a proper tag).

Thanks for the update.

Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006121: (no subject)

[Francesco Muzio]

I do not agree, because Xine using hardware acceleration (if I don't 
force to disable it by setting LIBVA_DRIVER_NAME,VDPAU_DRIVER ) and 
playing entire sample only with a glitch.

VLC must do it with the same behaviour

Bug#1005884: linux-image-5.16.0-1-amd64: Kernel oops (unable to handle page fault) during boot

[Salvatore Bonaccorso]

Hi Richard,

On Sat, Feb 19, 2022 at 07:40:42PM +0100, Richard B. Kreckel wrote:
> Hi,
> 
> I'm running a AMD Ryzen 3 4300U with Radeon Graphics system and found
> myself suddenly unable to boot linux-image-5.16.0-1-amd64 until a point
> where I could log in. (linux-image-5.15.0-3-amd64 and previous versions
> all had worked fine.)
> 
> After reading your link
> https://lore.kernel.org/stable/05b11936073c8d6b7a28c07cc...@stwm.de/, I
> just removed the iwlwifi.ko module and it boots just fine now.

Alright thank you for confirming that. Would it be possible that you
as well build the kernel with
https://git.kernel.org/linus/bea2662e7818e15d7607d17d57912ac984275d94
applied on top to see if this resolved the issue?

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2

gives the simple patching and building guide.

Regards,
Salvatore

Bug#1005993: Add additional command line options

[Oliver Sauder]

Diodon is a desktop utility and not a command line tool. So far the only 
two things you can do from the command line is to open diodon or to open 
it in debug mode by setting `G_MESSAGES_DEBUG` to `all`. Both those 
options are documented in the man page.


It would be great to have more options but need to be added first.

There is also a upstream issue reported for this at 
https://bugs.launchpad.net/diodon/+bug/1309898


Oliver

Bug#1001454: buster-pu: package privoxy/3.0.28-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2021-12-10 at 13:00 +0100, Roland Rosenfeld wrote:
> This fixes CVE-2021-44540 and CVE-2021-44543.
> Since all are tagged "minor issue" in the security-tracer, I tend to
> send this into the next point release of buster.
> 

Please go ahead. Sorry for the delay.

Regards,

Adam

Bug#1004575: bullseye-pu: package mutter/3.38.6-2~deb11u2

[Simon McVittie]

On Sat, 19 Feb 2022 at 17:32:40 +, Adam D. Barratt wrote:
> On Sun, 2022-01-30 at 17:45 +, Simon McVittie wrote:
> > Bug fix updates from upstream gnome-3-38 branch, prompted by user
> > request in #1002651.
> 
> Please go ahead; thanks.

Uploaded.

smcv

Bug#1003826: buster-pu: package libjackson-json-java/1.9.13-2~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-01-16 at 14:17 +0200, Adrian Bunk wrote:
>   * Add upstream fixes.
> - Serializing types for deeply nested Maps.
> - Set Secure Processing flag on DocumentBuilderFactory.
> - Set setExpandEntityReferences(false). (Fixes: CVE-2019-10172)
> - WriteRawValue surrogate pair fix.
> - Fix deserialization.
> - All known security fixes. (Fixes: CVE-2017-15095 and CVE-2017-
> 7525)
>   * Update Standards-Version to 4.5.0
> 
> Except for Standards-Version and the dh compat bump reverted
> in this backport, the bullseye package was the buster package
> with several bugfixes applied (including fixes for 3 CVEs).

Please go ahead.

Regards,

Adam

Bug#1003825: buster-pu: package libetpan/1.9.3-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-01-16 at 13:59 +0200, Adrian Bunk wrote:
>   * CVE-2020-15953: STARTTLS response injection that
> affects IMAP, SMTP, and POP3. (Closes: #966647)

Please go ahead.

Regards,

Adam

Bug#1003795: buster-pu: package evolution-data-server/3.30.5-1+deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-01-16 at 00:27 +0200, Adrian Bunk wrote:
>   * CVE-2020-16117: Crash on malformed server response with
> minimal capabilities.

Please go ahead.

Regards,

Adam

Bug#1005694: bullseye-pu: package gtk+3.0/3.24.24-4+deb11u1

[Simon McVittie]

On Sat, 19 Feb 2022 at 17:49:13 +, Adam D. Barratt wrote:
> That looks OK to me, but will need a d-i ack as gtk+3.0 builds
> a udeb

Since kibi confirmed that d-i doesn't actually use GTK 3, I've uploaded.

smcv

Bug#1003841: buster-pu: package cimg/2.4.5+dfsg-1+deb10u1

[Adam D. Barratt]

Control: clone -1 -2
Control: retitle -2 nmu: beads/1.1.18+dfsg-3
Control: tags -1 + confirmed

On Sun, 2022-01-16 at 20:51 +0200, Adrian Bunk wrote:
>   * CVE-2020-25693: Fix multiple heap buffer overflows.
> (Closes: #973770)
> 

Please go ahead.

> This is a headers-only library, the only user in buster needs
> to be rebuilt:
>   nmu beads_1.1.18+dfsg-3 . ANY . buster . 'Rebuild with cimg-dev
> 2.4.5+dfsg-1+deb10u1'
>   dw beads_1.1.18+dfsg-3 . ANY . buster . -m 'cimg-dev (>=
> 2.4.5+dfsg-1+deb10u1)'

That wants handling via a separate bug so we can track the fixes more
accurately; cloning.

Regards,

Adam

Bug#1003827: buster-pu: package wireshark/2.6.20-0+deb10u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-01-16 at 15:08 +0200, Adrian Bunk wrote:
>   * CVE-2021-22207: Excessive memory consumption in the MS-WSP
> dissector.
> (Closes: #987853)
>   * CVE-2021-22235: Crash in the DNP dissector.
>   * CVE-2021-39921: NULL pointer exception in the Modbus dissector.
>   * CVE-2021-39922: Buffer overflow in the C12.22 dissector.
>   * CVE-2021-39923: Large loop in the PNRP dissector.
>   * CVE-2021-39924: Large loop in the Bluetooth DHT dissector.
>   * CVE-2021-39928: NULL pointer exception in the IEEE 802.11
> dissector.
>   * CVE-2021-39929: Uncontrolled Recursion in the Bluetooth DHT
> dissector.

Please go ahead.

Regards,

Adam

Bug#995224: [Debian-med-packaging] Bug#995224: relion-cuda: FTBFS with cub 1.14

[Sascha Steinbiss]

Hi all,

greetings from the Debian Med Sprint 2021!

[...]
> /usr/bin/nvcc -M -D__CUDACC__ 
> /build/relion-cuda-3.1.0/src/acc/cuda/cuda_projector_plan.cu -o 
> /build/relion-cuda-3.1.0/build/src/apps/CMakeFiles/relion_gpu_util.dir/__/acc/cuda/relion_gpu_util_generated_cuda_projector_plan.cu.o.NVCC-depend
>  -ccbin /usr/bin/cc -m64 -DINSTALL_LIBRARY_DIR=/usr/lib/ 
> -DSOURCE_DIR=/build/relion-cuda-3.1.0/src/ -DACC_CUDA=2 -DACC_CPU=1 -DCUDA 
> -DALLOW_CTF_IN_SGD -DHAVE_SINCOS -DHAVE_TIFF -Xcompiler 
> ,\"-g\",\"-O2\",\"-ffile-prefix-map=/build/relion-cuda-3.1.0=.\",\"-fstack-protector-strong\",\"-Wformat\",\"-Werror=format-security\",\"-O3\",\"-DNDEBUG\"
>  -arch=sm_35 -D__INTEL_COMPILER --default-stream per-thread 
> --disable-warnings -DNVCC -I/usr/include 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
> -I/build/relion-cuda-3.1.0 -I/usr/lib/fltk -I/usr/include/x86_64-linux-gnu
> nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35', 'sm_37' 
> and 'sm_50' architectures are deprecated, and may be removed in a future 
> release (Use -Wno-deprecated-gpu-targets to suppress warning).
> In file included from /usr/include/thrust/system/cuda/config.h:33,
>  from 
> /usr/include/thrust/system/cuda/detail/execution_policy.h:35,
>  from 
> /usr/include/thrust/iterator/detail/device_system_tag.h:23,
>  from 
> /usr/include/thrust/iterator/detail/iterator_facade_category.h:22,
>  from /usr/include/thrust/iterator/iterator_facade.h:37,
>  from 
> /build/relion-cuda-3.1.0/src/acc/cuda/cub/device/../iterator/arg_index_input_iterator.cuh:48,
>  from 
> /build/relion-cuda-3.1.0/src/acc/cuda/cub/device/device_reduce.cuh:41,
>  from 
> /build/relion-cuda-3.1.0/src/acc/cuda/cuda_utils_cub.cuh:16,
>  from 
> /build/relion-cuda-3.1.0/src/acc/cuda/cuda_projector_plan.cu:10:
> /usr/include/cub/util_namespace.cuh:46:2: error: #error CUB requires a 
> definition of CUB_NS_QUALIFIER when CUB_NS_PREFIX/POSTFIX are defined.
>46 | #error CUB requires a definition of CUB_NS_QUALIFIER when 
> CUB_NS_PREFIX/POSTFIX are defined.
>   |  ^
> CMake Error at 
> relion_gpu_util_generated_cuda_projector_plan.cu.o.Release.cmake:220 
> (message):
>   Error generating
>   
> /build/relion-cuda-3.1.0/build/src/apps/CMakeFiles/relion_gpu_util.dir/__/acc/cuda/./relion_gpu_util_generated_cuda_projector_plan.cu.o
> 
> 
> make[4]: *** [src/apps/CMakeFiles/relion_gpu_util.dir/build.make:1439: 
> src/apps/CMakeFiles/relion_gpu_util.dir/__/acc/cuda/relion_gpu_util_generated_cuda_projector_plan.cu.o]
>  Error 1
> make[4]: Leaving directory '/build/relion-cuda-3.1.0/build'
> 
> 
> This seems to be the Breaking Change described in
> https://github.com/NVIDIA/cub/releases/tag/1.14.0:
> 
> #350: When the CUB_NS_[PRE|POST]FIX macros are set, CUB_NS_QUALIFIER
> must also be defined to the fully qualified CUB namespace (e.g.
> #define CUB_NS_QUALIFIER ::foo::cub). Note that this is handled
> automatically when using the new [THRUST_]CUB_WRAPPED_NAMESPACE mechanism.

I updated the relion code to the latest upstream version (3.1.3) and
tried to rebuild in the hope that it changed something: it did, now I get:

[...]
/usr/bin/nvcc -M -D__CUDACC__
/build/relion-cuda-3.1.3/src/acc/cuda/cuda_projector_plan.cu -o
/build/relion-cuda-3.1.3/build/src/apps/CMakeFiles/relion_gpu_util.dir/__/acc/cuda/relion_gpu_util_generated_cuda_projector_plan.cu.o.NVCC-depend
-ccbin /usr/bin/cc -m64 -DINSTALL_LIBRARY_DIR=/usr/lib/
-DSOURCE_DIR=/build/relion-cuda-3.1.3/src/ -DACC_CUDA=2 -DACC_CPU=1
-DCUDA -DALLOW_CTF_IN_SGD -DHAVE_SINCOS -DHAVE_TIFF -Xcompiler
,\"-g\",\"-O2\",\"-ffile-prefix-map=/build/relion-cuda-3.1.3=.\",\"-fstack-protector-strong\",\"-Wformat\",\"-Werror=format-security\",\"-O3\",\"-DNDEBUG\"
-arch=sm_35 -D__INTEL_COMPILER --default-stream per-thread
--disable-warnings -DNVCC -I/usr/include
-I/usr/lib/x86_64-linux-gnu/openmpi/include
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi
-I/build/relion-cuda-3.1.3 -I/usr/lib/fltk -I/usr/include/x86_64-linux-gnu
nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35',
'sm_37' and 'sm_50' architectures are deprecated, and may be removed in
a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
In file included from
/usr/include/thrust/system/cuda/detail/execution_policy.h:35,
 from
/usr/include/thrust/iterator/detail/device_system_tag.h:23,
 from
/usr/include/thrust/iterator/detail/iterator_facade_category.h:22,
 from /usr/include/thrust/iterator/iterator_facade.h:37,
 from
/build/relion-cuda-3.1.3/src/acc/cuda/cub/device/../iterator/arg_index_input_iterator.cuh:48,
 from
/build/relion-cuda-3.1.3/src/acc/cuda/cub/device/device_reduce.cuh:41,
 from

Bug#1004055: buster-pu: package raptor2/2.0.14-1.1~deb10u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2022-01-19 at 22:30 +, Thorsten Alteholz wrote:
> The attached debdiff for raptor2 fixes CVE-2020-25713 in Buster. This
> CVE 
> is marked as no-dsa by the security team.
> 

Please go ahead.

Regards,

Adam

Bug#1003842: buster-pu: package flac/1.3.2-3+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-01-16 at 21:03 +0200, Adrian Bunk wrote:
>   * CVE-2020-0499: Out of bounds read due to a heap buffer overflow.
> (Closes: #977764)

Please go ahead.

Regards,

Adam

Bug#1004050: bullseye-pu: package zziplib/0.13.62-3.3+deb11u1.debdiff

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2022-01-19 at 22:19 +, Thorsten Alteholz wrote:
> The attached debdiff for zziplib fixes CVE-2020-18442 in Bullseye.
> This 
> CVE is marked as no-dsa by the security team.
> 

Please go ahead.

Regards,

Adam

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

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-01-23 at 17:27 +0200, Adrian Bunk wrote:
>   * CVE-2020-8955: A crafted irc message 324 (channel mode) could
> result in a crash. (Closes: #951289)
>   * CVE-2020-9759: A crafted irc message 352 (who) could result
> in a crash.
>   * CVE-2020-9760: A crafted irc message 005 (setting a new mode
> for a nick) could result in a crash.
>   * CVE-2021-40516: A crafted WebSocket frame could result in a crash
> in the Relay plugin. (Closes: #993803)

Please go ahead.

Regards,

Adam

Bug#982869: This might be related to a Fedora Bug reported on bug-datam...@gnu.org

[Erik Auerswald]

Hi,

the error message the test matches on occurs only once in the GNU datamsh
sources.  That same line has resulted in a build failure on Fedora for
the armv7hl platform[1], which is 32bit.  I have suggested two possible
fixes[2], but cannot test them, since I do not have an ARM system for
build tests available.  Those compile fixes just use the correct format
specifier for the variable holding the line number.

This might fix the tests as well, but I don't know this.  Perhaps you would
like to try this.

Of course, datamash 1.7 is quite old and thus the patches agains current
git might not apply cleanly.

HTH,
Erik

[1] https://lists.gnu.org/archive/html/bug-datamash/2022-01/msg3.html
[2] https://lists.gnu.org/archive/html/bug-datamash/2022-01/msg4.html
-- 
The most effective debugging tool is still careful thought, coupled with
judiciously placed print statements.
-- Brian W. Kernighan

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

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-01-23 at 23:07 +0200, Adrian Bunk wrote:
>   * CVE-2019-15165: Improper PHB header length validation.
> (Closes: #941697)

Please go ahead.

Regards,

Adam

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

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-01-23 at 20:21 +0200, Adrian Bunk wrote:
>   * CVE-2019-15945: Out-of-bounds access of an ASN.1 Bitstring.
> (Closes: #939668)
>   * CVE-2019-15946: Out-of-bounds access of an ASN.1 Octet string.
> (Closes: #939669)
>   * CVE-2019-19479: Incorrect read operation in the Setec driver.
> (Closes: #947383)
>   * CVE-2019-20792: Double free in the Coolkey driver.
>   * CVE-2020-26570: Heap-based buffer overflow in the Oberthur
> driver.
> (Closes: #972037)
>   * CVE-2020-26571: Stack-based buffer overflow in the GPK driver.
> (Closes: #972036)
>   * CVE-2020-26572: Stack-based buffer overflow in the TCOS driver.
> (Closes: #972035)

Please go ahead.

Regards,

Adam

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

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-01-23 at 22:59 +0200, Adrian Bunk wrote:
>   * CVE-2019-17041: Heap overflow in the AIX message parser.
> (Closes: #942067)
>   * CVE-2019-17042: Heap overflow in the Cisco log message parser.
> (Closes: #942065)

Please go ahead.

Regards,

Adam

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

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-01-23 at 23:15 +0200, Adrian Bunk wrote:
>   * CVE-2019-15531: Invalid read for malformed DVI files.
> (Closes: #935553)

The reformatting in the patch makes things rather noisier than they
need be, given that so far as I can tell the actual changes for the
issue are two new lines, rather than:

src/plugins/dvi_extractor.c | 88 +++--
 1 file changed, 45 insertions(+), 43 deletions(-)

Please go ahead.

Regards,

Adam

Bug#1005218: buster-pu: package spip/3.2.4-1+deb10u6

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2022-02-09 at 03:31 -0400, David Prévot wrote:
> Two security issues (XSS) have been fixed in the latest upstream
> version. As agreed with the security team, those are not worth a DSA.
> 
> [ Impact ]
> Without these fixes, websites are vulnerable to already public XSS
> issues.
> 

Please go ahead.

Regards,

Adam

Bug#1002051: bullseye-pu: package heartbeat/1:3.0.6-11+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-12-21 at 00:27 +0100, Valentin Vidic wrote:
> heartbeat deamon starts correctly after installation, but not
> after reboot because of missing /run/heartbeat directories.
> The change reintroduces a tempfiles configuration for creating
> the required directories on boot.
> 
[...]
> [ Other info ]
> The bug only affects systemd installations since the init script
> recreates the required directories on every start.
> 

Please go ahead.

Regards,

Adam

Bug#1001740: bullseye-pu: package fcitx5-chinese-addons/5.0.4-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2021-12-14 at 20:39 -0500, Boyuan Yang wrote:
> Currently the table input methods provided by fcitx5-table (in
> src:fcitx5-
> chinese-addons) will not work due to missing dependencies on fcitx5-
> module-
> pinyinhelper and fcitx5-module-punctuation. This is reported as
> https://bugs.debian.org/1001739 . The bug is present from the very
> beginning.
> While the latest fcitx5-chinese-addons/5.0.9-2 upload has fixed the
> bug in
> Debian Sid, This bullseye-pu will fix this bug in Debian 11 (stable).
> 
> [ Impact ]
> If this update is not present, users that only have fcitx5-table
> installed
> (i.e. did not explicitly install fcitx5-module-pinyinhelper and
> fcitx5-module-
> punctuation) will not be able to use any table input method in fcitx5
> framework.
> 

Please go ahead.

Regards,

Adam

Bug#1004459: bullseye-pu: package lxc/1:4.0.6-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2022-01-27 at 21:32 -0300, Antonio Terceiro wrote:
> This update fixes the download of container images using the
> "download"
> template. pool.sks-keyservers.net is not active anymore, so the patch
> (already included in the upstream release present in sid/bookworm)
> changes that to keyserver.ubuntu.com.
> 

+  * lxc-download: Switch GPG server.
+The default server used to download gpg keys from has ben deprecated,

s/ben/been/

Please go ahead.

Regards,

Adam

Bug#1005813: debian-edu-config: apparmor blocks cups-browsed.conf from being read

[Petter Reinholdtsen]

[Wolfgang Schweer]
> As the symlink seems to be the problem, another solution would be to
> let cfengine copy the file instead:

Sure.  The reason a symlink was used was to ensure upgrades would take
effect.

Perhaps dpkg-divert can be used?  I have vague memories of divert on
conffiles being a bad idea, but do not know why any more.

-- 
Happy hacking
Petter Reinholdtsen

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

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-01-23 at 17:18 +0200, Adrian Bunk wrote:
>   * CVE-2021-40516: A crafted WebSocket frame could result in a crash
> in the Relay plugin. (Closes: #993803)

Please go ahead.

Regards,

Adam

Bug#1003765: bullseye-pu: package node-markdown-it/10.0.0+dfsg-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2022-01-15 at 12:52 +0100, Yadd wrote:
> [ Reason ]
> node-markdown-it is vulnerable to regex denial of service
> (CVE-2022-21670)
> 

Please go ahead.

Regards,

Adam

Bug#1005884: linux-image-5.16.0-1-amd64: Kernel oops (unable to handle page fault) during boot

[Richard B. Kreckel]

Hi,

I'm running a AMD Ryzen 3 4300U with Radeon Graphics system and found
myself suddenly unable to boot linux-image-5.16.0-1-amd64 until a point
where I could log in. (linux-image-5.15.0-3-amd64 and previous versions
all had worked fine.)

After reading your link
https://lore.kernel.org/stable/05b11936073c8d6b7a28c07cc...@stwm.de/, I
just removed the iwlwifi.ko module and it boots just fine now.

  -richy.
-- 

Richard B. Kreckel

Bug#1005694: bullseye-pu: package gtk+3.0/3.24.24-4+deb11u1

[Cyril Brulebois]

Hi,

Adam D. Barratt  (2022-02-19):
> Thanks. That looks OK to me, but will need a d-i ack as gtk+3.0 builds
> a udeb; tagging and CCing accordingly.

d-i in bullseye is still on gtk2 (sorry), so gtk3 should be a no-brainer. :)


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


signature.asc
Description: PGP signature

Bug#1006121: (no subject)

[Sebastian Ramacher]

Control: reassign -1 mesa-va-drivers 20.3.5-1

On 2022-02-19 18:38:32 +0100, Francesco Muzio wrote:
> gdb stack trace of the crash:
> 
> Thread 25 "vlc" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffbc7fb700 (LWP 9949)]
> 0x7fffab507cb3in ??() from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
> (gdb) bt
> #0 0x7fffab507cb3in  () at /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
> #1 0x7fffab4d7f09in  () at /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
> #2 0x7fffab4d6221in  () at /usr/lib/x86_64-linux-gnu/dri/r600_dri.so
> #3 0x7fff7b5a14c5in  () at
> /usr/lib/x86_64-linux-gnu/dri/r600_drv_video.so
> #4 0x7fffa0473adfin vaEndPicture() at
> /usr/lib/x86_64-linux-gnu/libva.so.2
> #5 0x7fff831757c8in  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.58
> #6 0x7fff83185c6ein  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.58
> #7 0x7fff82f9dfcain  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.58
> #8 0x7fff82f9e70din  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.58
> #9 0x7fff82ca92bbin  () at /usr/lib/x86_64-linux-gnu/libavcodec.so.58
> #10 0x7fff82ca9db8in avcodec_send_packet()
>    at /usr/lib/x86_64-linux-gnu/libavcodec.so.58
> #11 0x7fffbc20966cin  ()
>    at /usr/lib/x86_64-linux-gnu/vlc/plugins/codec/libavcodec_plugin.so
> #12 0x77cb01c8in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
> #13 0x77cafdf5in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
> #14 0x77cb0412in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
> #15 0x77f44ea7in start_thread(arg=) at
> pthread_create.c:477
> #16 0x77e6edefin clone() at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> 
> 
> The crash seems a curious combination between a (probably) not perfect
> signal reception, libvlc and the driver/hardware video.
> It not happens on another machine with same debian release, same
> architecture and same radeon driver video (but different GPU)
> It not happens if I disable HW decoding on VLC
> 
> with HW decoding enabled, when VLC start playing, shows me this message:
> [7f91d0c0b170] avcodec decoder: Using Mesa Gallium driver 20.3.5 for AMD
> RS880 (DRM 2.50.0 / 5.10.0-11-amd64, LLVM 11.0.1) for hardware decoding

So this sounds a lot like a bug in the vaapi driver for that GPU.
Especially since playing without hardware decoding works as expected.
Reassigning accordingly.

Cheers

> 
> when VLC segfaults I see these messages in dmesg logs
> [ 9647.012821] vlc[7168]: segfault at 30 ip 7fe06b0ffcb3 sp
> 7fe06846d738 error 4 in r600_dri.so[7fe06a6a5000+d47000]
> [ 9647.012857] Code: 1f 84 00 00 00 00 00 48 8b 46 30 ff 60 10 66 0f 1f 84
> 00 00 00 00 00 48 8b 06 48 8b 40 30 ff 60 18 66 0f 1f 44 00 00 48 8b 06 <48>
> 8b 40 30 ff 60 20 66 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55
> 
> so, as a workaround, I use --avcodec-hw none to VLC (or settings
> VDPAU_DRIVER=none LIBVA_DRIVER_NAME=none for other software using libvlc) to
> avoid the crash
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1004921: libtsm: Package too old for kmscon

[Victor Westerhuis]

Source: libtsm
Followup-For: Bug #1004921

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Aetf has released version 4.0.2 of their fork. I have
updated the version in my Salsa repository as well.

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmIRLJoTHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+xmwD/9HeMJhZPZ0GAa7ePdyq1CBEYqge8JF
+B62/e5vhm/pCDCLXNIEq92FNZLp2P9MLfE9ZZNEQ6G+IXaxN92Wc7E/aKUJlXBh
55hIaB39/Kt2Rhz0OcXF79NX5GoyEPyDDd2+Co97VMF5eovN7UsASMgs2JX/d7/5
FDS6mwX/EiC5OZC1J1GYV9o4p4JCllSo4xCYxZEdUTXIwDHDAFqXx5NZvI1C8Rdv
y5GUTiKK+w25REUB6lWJ0WleHLdCFH/BcTZ/7VxEvpC6BbnURAUX9Pz4s+r/hnpf
eGqVtU+dM3kgiJ0EAEww/LCIWvMWP2D76bJrAJGvXIyiOQNONzRW9TmhHpxn3M+R
2z61GLRtaXz2tUx8Lt80fz6xiLhjRmIibgGLehQWYRt/ZxO0+sNEhlhple06oYzh
yCn2+MbtGns9QODkGWabV+QElfoh6RZU0a/Vp9g8Nf+WByPtZuzoxRzLI4vzvsnk
Kqaqm+NQ5lbzDecpzRVlxAy8wymkrdbkENCYry31EQ9QCtuHIvlh7nNa0XIJnh4A
+dXlHpWHzxe+8r0uXFzO0p9VyQ+B9WgXbL+NDphEpP+WueoQLkXl7Q+mT71rAjnW
x9luQ0VpbpUmLcYnNjk0PBBqlgkRFeE2B/553uha739l18Vy8UOM52WJ4SjFHalX
hbqf9mn0KhCXPA==
=CEFL
-END PGP SIGNATURE-

Bug#1003548: transition: libwebp

[Sebastian Ramacher]

On 2022-02-18 10:26:26 +0100, Sebastian Ramacher wrote:
> On 2022-02-16 20:49:44, Jeff Breidenbach wrote:
> > libwebp 1.2.1-7 has been successfully uploaded to unstable.
> > 
> > Anthony and Iustin, help is very strongly appreciated for the NMUs.
> 
> Almost all reverse dependencies have successfully been rebuilt against
> libwebp7. Packages failing to build are weston (#998603) and openimageio
> (#1003470).

The builds of graphicsmagick (#1006110) and qtimageformats-opensource
(#1006009) failed due to tests related to libwebp. Could this be a bug
in libwebp?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1006141: supertuxkart: FTBFS on armhf: Error: selected FPU does not support instruction -- `vldmia.64 r10,{d0-d7}'

[Sebastian Ramacher]

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

supertuxkart FTBFS on armhf:

[ 26%] Building ASM object 
lib/angelscript/projects/cmake/CMakeFiles/angelscript.dir/__/__/source/as_callfunc_arm_gcc.S.o
cd /<>/obj-arm-linux-gnueabihf/lib/angelscript/projects/cmake && 
/usr/bin/cc -DANGELSCRIPT_EXPORT -DENABLE_IPV6 -DNO_IRR_COMPILE_WITH_OPENGL_ 
-DSUPERTUXKART_VERSION=\"1.3\" -DUSE_GLES2 -D_IRR_COMPILE_WITH_OGLES2_ -D_LIB 
-I/<>/lib/wiiuse/src -I/<>/lib/irrlicht/include 
-I/<>/lib/tinygettext/include 
-I/<>/lib/graphics_utils 
-I/<>/lib/graphics_engine/include 
-I/<>/lib/enet/include -I/<>/lib/bullet/src 
-I/usr/include -I/usr/include/SDL2 -I/<>/src 
-I/<>/lib/angelscript/projects/cmake/../../include   
-Wa,-mimplicit-it=always -o 
CMakeFiles/angelscript.dir/__/__/source/as_callfunc_arm_gcc.S.o -c 
/<>/lib/angelscript/source/as_callfunc_arm_gcc.S
/<>/lib/angelscript/source/as_callfunc_arm_gcc.S: Assembler 
messages:
/<>/lib/angelscript/source/as_callfunc_arm_gcc.S:328: Error: 
selected FPU does not support instruction -- `vldmia.64 r10,{d0-d7}'
/<>/lib/angelscript/source/as_callfunc_arm_gcc.S:377: Error: 
selected FPU does not support instruction -- `vstmia.64 r10,{d0-d7}'
/<>/lib/angelscript/source/as_callfunc_arm_gcc.S:403: Error: 
selected FPU does not support instruction -- `vldmia.64 r10,{d0-d7}'
/<>/lib/angelscript/source/as_callfunc_arm_gcc.S:464: Error: 
selected FPU does not support instruction -- `vstmia.64 r10,{d0-d7}'
/<>/lib/angelscript/source/as_callfunc_arm_gcc.S:493: Error: 
selected FPU does not support instruction -- `vldmia.64 r10,{d0-d7}'
/<>/lib/angelscript/source/as_callfunc_arm_gcc.S:558: Error: 
selected FPU does not support instruction -- `vstmia.64 r10,{d0-d7}'
/<>/lib/angelscript/source/as_callfunc_arm_gcc.S:583: Error: 
selected FPU does not support instruction -- `vldmia.64 r10,{d0-d7}'
/<>/lib/angelscript/source/as_callfunc_arm_gcc.S:634: Error: 
selected FPU does not support instruction -- `vstmia.64 r10,{d0-d7}'
/<>/lib/angelscript/source/as_callfunc_arm_gcc.S:661: Error: 
selected FPU does not support instruction -- `vldmia.64 r10,{d0-d7}'
/<>/lib/angelscript/source/as_callfunc_arm_gcc.S:714: Error: 
selected FPU does not support instruction -- `vstmia.64 r10,{d0-d7}'
make[3]: *** 
[lib/angelscript/projects/cmake/CMakeFiles/angelscript.dir/build.make:554: 
lib/angelscript/projects/cmake/CMakeFiles/angelscript.dir/__/__/source/as_callfunc_arm_gcc.S.o]
 Error 1
make[3]: *** Waiting for unfinished jobs

See
https://buildd.debian.org/status/fetch.php?pkg=supertuxkart=armhf=1.3%2Bdfsg1-2%2Bb1=1645095866=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1005813: debian-edu-config: apparmor blocks cups-browsed.conf from being read

[Wolfgang Schweer]

[ Holger Levsen, 2022-02-19 ]
> On Tue, Feb 15, 2022 at 07:20:01PM +, Mike Gabriel wrote:
> > Solution 2:
> > ---
> > Ask the cups src:pkg maintainers to add a line
> > /etc/cups/cups-browsed-debian-edu.conf to their
> > /etc/appamor.d/usr.sbin.cups-browsed apparmor profile.
> 
> to me this seems to be the cleanest approach.

As the symlink seems to be the problem, another solution would be to
let cfengine copy the file instead:

diff --git a/cf3/cf.cups b/cf3/cf.cups
index 9788fa5c..58a64493 100644
--- a/cf3/cf.cups
+++ b/cf3/cf.cups
@@ -29,7 +29,7 @@ files:
   debian.desktopintern.!server.installation::
 
 "/etc/cups/cups-browsed.conf"
-  link_from => ln_s("/etc/cups/cups-browsed-debian-edu.conf"),
+  copy_from => local_cp("/etc/cups/cups-browsed-debian-edu.conf"),
   move_obstructions => "true";
 }

(In both cases, the original file is renamed to 
/etc/cups/cups-browsed.conf.cfsaved)

Wolfgang


signature.asc
Description: PGP signature

Bug#1005841: debian-edu-config: No TJENER print queues appearing on Debian Edu clients, print queues named not like queue name on TJENER

[Wolfgang Schweer]

[ Mike Gabriel, 2022-02-16 ]
> The problem is that I think that the cups-browsing (or more strictly spoken
> cups-browsed-debian-edu.conf) never got really fully tested, because
> cups-browsed fails/failed to read cups-browsed-debian-edu.conf due to
> apparmor blocking.
 
Right.

> On normal workstations, I sense that some cups-browsed defaults kick into
> place (as the cups-browsed-debian-edu.conf is being blocked from reading at
> cups-browsed service startup) and that these defaults provide CUPS queues on
> TJENER to the clients via dnssd and the printer naming scheme is
> __ (which is an unwanted naming scheme here).

Right. Like you proposed, the correct file content should rather be:

diff --git a/etc/cups/cups-browsed-debian-edu.conf 
b/etc/cups/cups-browsed-debian-edu.conf
index b1479a4f..f58a99ad 100644
--- a/etc/cups/cups-browsed-debian-edu.conf
+++ b/etc/cups/cups-browsed-debian-edu.conf
@@ -28,5 +28,5 @@ BrowseAllow ipp.intern
 # to "No".
 
 CreateIPPPrinterQueues No
-CreateRemoteCUPSPrinterQueues No
-
+CreateRemoteCUPSPrinterQueues Yes
+LocalQueueNamingRemoteCUPS RemoteName

Wolfgang


signature.asc
Description: PGP signature

Bug#1003188: bullseye-pu: package mmdebstrap/0.7.5-2.2

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2022-01-05 at 20:28 +0100, Johannes Schauer Marin Rodrigues
wrote:
> Currently, when a user happens to have an ASCII armored key in
> /etc/apt/trusted.gpg.d, running mmdebstrap without any special
> options
> will not work. See #1003175 for details.
> 
> The problem is fixed in unstable and testing, starting with 0.8.0-1.
> 

0001-Do-not-use-gpg-trust-model-always isn't mentioned in the
changelog. Is it part of the fix for the issue mentioned above, or a
separate change?

Regards,

Adam

Bug#1006122: Provide a live image with enlightenment for a smaller image

[Andrew M.A. Cater]

On Sat, Feb 19, 2022 at 07:28:46PM +0530, Pirate Praveen wrote:
> Package: debian-cd
> Severity: wishlist
> 
> Currently all images except the standard image is >= 3.0 GB. I think
> providing a smaller graphical image with enlightenment (or icewm or wmaker
> or even all three together) to provide a graphical smaller disk image would
> be nice. It can be useful for smaller pen drives and people just wanting to
> test live images with more features than standard image (check video driver,
> wifi driver, sound and other hardware before installing).
>

Just a heads-up: you may want to close this/reassign to debian-live. 
Debian-cd don't have anything to do with the live builds except to
test them occasionally.

I doubt that the images will get smaller - they effectively include a
live filesystem to copy into RAM in order to run so they need to be
that big. Adding another desktop or three will require another dedicated
image and there's nobody much maintaining live images at all at the moment,
unfortunately.

All the very best, as ever,

Andy C.

Bug#1006000: transition: draco

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-draco.html

On 2022-02-18 20:06:20 +0100, Timo Röhling wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> I would like to transition draco for its new SONAME.
> The Ben tracker at
> https://release.debian.org/transitions/html/auto-draco.html looks fine.
> I rebuilt all reverse dependencies on amd64 successfully.

Please go ahead

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1003058: bullseye-pu: package openvswitch/2.15.0+ds1-2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2022-01-03 at 14:25 +0100, Thomas Goirand wrote:
> [ Reason ]
> Indeed, the updated version I would like to push contains a fix for
> CVE-2021-36980 (Debian bug #991308), and a fix for having libofproto
> properly installed if activating dpdk (which fixes #992406 and
> #989585). This update-alternatives fix has been in Unstable for a
> long
> time already.
> 
> [ Impact ]
> - CVE-2021-36980.
> - Non-working DPDK setup when using LLDP.
> 
> [ Tests ]
> The OVS package has a test suite that's run at build time.
> We also set it in real production and it worked for us.
> 

Please go ahead, thanks.

Regards,

Adam

Bug#1003018: bullseye-pu: package php-laravel-framework/6.20.14+dfsg-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-01-02 at 21:10 +0100, Robin Gustafsson wrote:
> [ Reason ]
> Security issues affecting the version in bullseye.
> * Bug #1001333 (CVE-2021-43808)
> * Bug #1002728 (CVE-2021-43617)
> 
> [ Impact ]
> * Users of web applications using certain templating features from
>   the framework may by vulnerable to XSS attacks.
> * Users who host web applications relying on the framework's file
> upload
>   validation features may be vulnerable to remote code execution
> attacks.
> 

Please go ahead, thanks.

Regards,

Adam

Bug#1002703: bullseye-pu: package libarchive/3.4.3-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2021-12-27 at 22:10 +0200, Peter Pentchev wrote:
> This is a future unblock request before I upload
> libarchive-3.4.3-2+deb11u1 to fix a couple of bugs that were
> fixed in later upstream versions and in unstable. They are all
> related to setting permissions and ACLs when extracting
> archive members that represent symbolic and hard links.
> 
> [ Impact ]
> Extracting some (rarely seen) archives may result in files
> having the wrong access permissions.
> 

Please go ahead, thanks.

Regards,

Adam

Bug#1003484: bullseye-pu: package openssl/1.1.1m-0+deb11u1

[Adam D. Barratt]

On Sat, 2022-02-19 at 18:52 +0100, Sebastian Andrzej Siewior wrote:
> On 2022-02-19 17:04:16 [+], Adam D. Barratt wrote:
> > Control: tags -1 + confirmed d-i
> …
> > Thanks. Assuming the above is still accurate, then this looks good
> > to
> > me.
> > 
> > As the package builds a udeb, it will need a d-i ack; tagging and
> > CCing
> > accordingly.
> 
> I'm confused. May I upload or do I wait for the d-i ack?
> 

Sorry for the confusion.

Feel free to upload; we'll wait for the d-i ack before accepting the
package into p-u.

Regards,

Adam

Bug#1002685: bullseye-pu: package prips/1.1.1-3+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2021-12-27 at 13:21 +0200, Peter Pentchev wrote:
> This is a future unblock request before I upload prips-1.1.1-
> 3+deb11u1
> to fix two upstream bugs that affect the base functionality of the
> program:
> an infinite loop if it is asked to print the addresses in a block
> that
> ends at the last IPv4 address (255.255.255.255), and incorrect output
> if
> asked to combine two very different IP addresses (e.g. 1.1.1.1 and
> 230.120.1.1) into a single CIDR block.
> 

Please go ahead; sorry for the delay.

Regards,

Adam