Bug#992320: Missing breaks/replaces with kdenlive-data 21.04.3-1

[Didier 'OdyX' Raboud]

Package: breeze-icon-theme
Version: 4:5.78.0-2
Severity: normal

Upgrading fails if kdenlive-data is installed:

Unpacking breeze-icon-theme (4:5.83.0-2) over (4:5.78.0-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/breeze-icon-theme_4%3a5.83.0-2_all.deb (--unpack):
 trying to overwrite 
'/usr/share/icons/breeze-dark/actions/16/add-subtitle.svg', which is also in 
package kdenlive-data 21.04.3-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/breeze-icon-theme_4%3a5.83.0-2_all.deb


-- System Information:
Debian Release: 11.0
  APT prefers buildd-unstable
  APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (100, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages breeze-icon-theme depends on:
it  hicolor-icon-theme  0.17-2

breeze-icon-theme recommends no packages.

breeze-icon-theme suggests no packages.

-- no debconf information

Bug#992321: freeradius isn't creating a PID file

[Dan MacLeod]

Package: freeradius
Version: 3.0.21+dfsg-2.2
Severity: important
X-Debbugs-Cc: dan...@insertcomment.com

Dear Maintainer,

We use monit to check the PID file at /var/log/freeradius/freeradius.pid and 
restart the service if it goes down, and this works in stretch and buster but 
no PID file seems to be created in bullseye. 

I tried checking the permissions of the folder and looking through log files 
and can't find a reason it wouldn't be created. 

After this I removed our configuration and did a base install and neither seems 
to generate this file. 

While there are workarounds I want to confirm if freeradius is still meant to 
generate this file and isn't, or if there are any further troubleshooting steps 
I can try. 

Thanks 

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages freeradius depends on:
ii  freeradius-common  3.0.21+dfsg-2.2
ii  freeradius-config  3.0.21+dfsg-2.2
ii  libc6  2.31-13
ii  libcrypt1  1:4.4.18-4
ii  libct4 1.2.3-1
ii  libfreeradius3 3.0.21+dfsg-2.2
ii  libgdbm6   1.19-2
ii  libpam0g   1.4.0-9
ii  libperl5.325.32.1-4+deb11u1
ii  libreadline8   8.1-1
ii  libsqlite3-0   3.34.1-3
ii  libssl1.1  1.1.1k-1
ii  libsystemd0247.3-6
ii  libtalloc2 2.3.1-2+b1
ii  libwbclient0   2:4.13.5+dfsg-2
ii  lsb-base   11.1.0

Versions of packages freeradius recommends:
ii  freeradius-utils  3.0.21+dfsg-2.2

Versions of packages freeradius suggests:
pn  freeradius-krb5
pn  freeradius-ldap
pn  freeradius-mysql   
pn  freeradius-postgresql  
pn  freeradius-python3 
pn  snmp   

-- no debconf information

Bug#972146: /usr/share/applications/mono-runtime-common.desktop: should not handle MIME type by executing arbitrary code

[Salvatore Bonaccorso]

Hi Monio Maintainers,

On Tue, May 04, 2021 at 10:30:57PM +0200, Gabriel Corona wrote:
> Hi,
> 
> Any update on this? This is actually very dangerous.
> 
> $ xdg-open hello.exe
> Hello World!
> $ cp hello.exe hello.ΡDF # <- actually not a P but a uppercase rho
> $ xdg-open hello.PDF
> Hello World!

Friendly ping on this issue. This issue was ingored for bullseye
release, at least during the freeze. Any suggestion for it's further
handling?

Regards,
Salvatore

Bug#992322: ITP: node-minipass -- Nodejs minimal implementation of a PassThrough stream

[Yadd]

Package: wnpp
Severity: wishlist
Owner: Yadd 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-javascript-de...@lists.alioth.debian.org

* Package name: node-minipass
  Version : 3.1.3
  Upstream Author : npm, Inc. and Contributors
* URL : https://github.com/isaacs/minipass
* License : ISC
  Programming Lang: JavaScript
  Description : Nodejs minimal implementation of a PassThrough stream

minipass is a very minimal implementation of a PassThrough stream

It's very fast for objects, strings, and buffers.

Supports pipe()ing (including multi-pipe() and backpressure transmission),
buffering data until either a data event handler or pipe() is added (so
you don't lose the first chunk), and most other cases where PassThrough
is a good idea.

Currently, minipass is embedded in npm, node-cacache, node-ssri and
node-tar. It is also a dependency of next node-tap. The goal of this ITP
is to package it separately and then remove embedded minipass. The
package will embed also some little reverse dependencies of minipass
needed by node-cacache, npm and node-tap:
 * minipass-flush
 * minipass-collect
 * minipass-pipeline
 * minipass-json-stream
 * minipass-sized

This package will be maintained under Pkg-JS umbrella.

Cheers,
Yadd

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[jiho lee]

I'd like to maintain the shutter package and related package.

In principle, shutter-team has exchanged opinions via e-mail and is
officially packaged and serviced in the distributed repository, and
shutter-team has created a related repository (
https://github.com/search5/shutter-deb), so please package it yourself and
upload it to the Debian.

I'm not a Debian maintainer, but I'd like to keep it for a while until
there's someone who can take care of the shutter.

Please give me your opinion.


There is a future society, but my future is not what others do.
Dept. of Information Science, Graduate School, Korea National Open
University

Bug#990622: bitlbee-plugin-facebook: The plugin does not start

[Jean-Philippe MENGUAL]

Le 16/08/2021 à 21:46, Sean Whitton a écrit :

control: tag -1 - fixed-upstream patch + moreinfo

Hello,

On Fri 02 Jul 2021 at 10:38PM +02, Jean-Philippe MENGUAL wrote:


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

* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
  ineffective)?

 From a set bitlbee properly, run:
account facebook on

* What was the outcome of this action?

After connecting, I get: ERROR_QUEUE_OVERFLOW

* What outcome did you expect instead?

Should display the buddies list

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


Could you test version 1.2.2, as just uploaded?


Excellent news! It works fine now. Thanks for the update. The bug seems 
to be fixed then


Best regards



Thanks.

Bug#992323: binutils-common: many manpares are empty

[Ingo Saitz]

Package: binutils-common
Version: 2.37-4
Severity: normal

The manpages for many of the included tools are just copressed empty
files (the 20 bytes are the compression header), as dpkg-deb -c shows:

-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/addr2line.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 ./usr/share/man/man1/ar.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 ./usr/share/man/man1/as.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/c++filt.1.gz
-rw-r--r-- root/root   621 2021-08-15 16:51 ./usr/share/man/man1/dwp.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/elfedit.1.gz
-rw-r--r-- root/root  8923 2021-08-15 16:51 ./usr/share/man/man1/gprof.1.gz
-rw-r--r-- root/root 43184 2021-08-15 16:51 ./usr/share/man/man1/ld.bfd.1.gz
-rw-r--r-- root/root  6705 2021-08-15 16:51 
./usr/share/man/man1/ld.gold.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 ./usr/share/man/man1/nm.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/objcopy.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/objdump.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 ./usr/share/man/man1/ranlib.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/readelf.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 ./usr/share/man/man1/size.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 
./usr/share/man/man1/strings.1.gz
-rw-r--r-- root/root20 2021-08-15 16:51 ./usr/share/man/man1/strip.1.gz


-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-rc4-pinguin20210802 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#992324: fakechroot: please consider creating an empty /etc/.pwd.lock when lckpwdf is called

[Johannes Schauer Marin Rodrigues]

Package: fakechroot
Version: 2.19-3.4
Severity: normal
Tags: patch
Control: affects -1 + mmdebstrap

Hi,

a chroot created using fakechroot is currently bit-by-bit identical to a
chroot created with normal root privileges except for the empty file
/etc/.pwd.lock missing from the chroot created with fakechroot. This is
because fakechroot wraps lckpwdf as a no-op:

https://github.com/dex4er/fakechroot/issues/94

This patch fixes the problem:

https://github.com/dex4er/fakechroot/pull/95/commits/11589e1037372c5ad719e1e46d7462fd196caa56

Since this difference affects my package mmdebstrap, I would offer to
NMU fakechroot again.

If you have any objections, please speak up. Otherwise I would upload
fakechroot with DELAYED+10.

Thanks!

cheers, josch

Bug#992325: rdiff-backup: '::' prefix on target directory causes crash - contrary to documentation (and earlier versions)

[Alexis Huxley]

Package: rdiff-backup
Version: 2.0.5-1~bpo10+1+b1
Severity: minor

Dear Maintainer,

in rdiff-backup 1.2.8-7 (buster) the man page synposis states:

rdiff-backup [options] [[[user@]host1.foo]::source_directory] 
[[[user@]host2.foo]::destination_directory]

i.e. *if* a destination is specified then the destination directory
*must* be preceded by '::' and that worked as documented:

lagane$ dpkg -l rdiff-backup | grep rdiff-backup
ii  rdiff-backup   1.2.8-7  amd64remote incremental backup
lagane$ 
lagane$ mkdir /tmp/src /tmp/dst
lagane$ touch /tmp/src/file{1,2,3}
lagane$ rdiff-backup lagane::/tmp/src ::/tmp/dst
lagane$ 

Doubtlessly, many people have written backup scripts that call
rdiff-backup in the manner that the man page says they should.

In rdiff-backup 2.0.5-1 (bullseye + buster backports) the man page
states exactly the same synposis:

rdiff-backup [options] [[[user@]host1.foo]::source_directory] 
[[[user@]host2.foo]::destination_directory]

However, now using the '::' prefix causes a crash with a python
stack dump:

damson$ dpkg -l rdiff-backup | grep rdiff-backup
ii  rdiff-backup   2.0.5-1~bpo10+1+b1 amd64remote incremental 
backup
damson$ mkdir /tmp/src /tmp/dst
damson$ touch /tmp/src/file{1,2,3}
damson$ rdiff-backup damson::/tmp/src ::/tmp/dst
Exception 'No file host in 'b'::/tmp/dst''' raised of class '':
  File "/usr/lib/python3/dist-packages/rdiff_backup/Main.py", line 395, 
in error_check_Main
Main(arglist)
  File "/usr/lib/python3/dist-packages/rdiff_backup/Main.py", line 412, 
in Main
cmdpairs = SetConnections.get_cmd_pairs(args, remote_schema, 
remote_cmd)
  File "/usr/lib/python3/dist-packages/rdiff_backup/SetConnections.py", 
line 67, in get_cmd_pairs
desc_pairs = list(map(parse_file_desc, arglist))
  File "/usr/lib/python3/dist-packages/rdiff_backup/SetConnections.py", 
line 127, in parse_file_desc
raise SetConnectionsException("No file host in '%s'" % file_desc)

Traceback (most recent call last):
  File "/usr/bin/rdiff-backup", line 32, in 
rdiff_backup.Main.error_check_Main(sys.argv[1:])
  File "/usr/lib/python3/dist-packages/rdiff_backup/Main.py", line 395, 
in error_check_Main
Main(arglist)
  File "/usr/lib/python3/dist-packages/rdiff_backup/Main.py", line 412, 
in Main
cmdpairs = SetConnections.get_cmd_pairs(args, remote_schema, 
remote_cmd)
  File "/usr/lib/python3/dist-packages/rdiff_backup/SetConnections.py", 
line 67, in get_cmd_pairs
desc_pairs = list(map(parse_file_desc, arglist))
  File "/usr/lib/python3/dist-packages/rdiff_backup/SetConnections.py", 
line 127, in parse_file_desc
raise SetConnectionsException("No file host in '%s'" % file_desc)
rdiff_backup.SetConnections.SetConnectionsException: No file host in 
'b'::/tmp/dst''
damson$ 

Without the '::' on the local destination it works fine:

damson$ rdiff-backup damson::/tmp/src /tmp/dst
damson$ 

Given that the man page synopsis has remained the same over multiple
versions of the tool itself, I assume that the upstream authors think
that '::' on a local target directory *should* still work, and as such
I think this is more serious than a minor error in the documention.

If I can provide any more information or test a new version then just
let me know.

Regards,

Alexis





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

Kernel: Linux 4.19.0-17-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rdiff-backup depends on:
ii  libc6  2.28-10
ii  librsync1  0.9.7-10+b1
ii  python33.7.3-1
ii  python3-pkg-resources  40.8.0-1
ii  python3-setuptools 40.8.0-1

Versions of packages rdiff-backup recommends:
pn  python3-pylibacl  
pn  python3-pyxattr   

rdiff-backup suggests no packages.

-- no debconf information

Bug#992317: installation-reports: Unnecessary 'You are about to do something potentially harmful.'

[Peter B]

Package: installation-reports
Severity: normal

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: network
Image version: 
Date: 

Machine: VM
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect media:   [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:


Doing a 32 to 64 bit cross grade on a bullseye server.  Hitting a
warning when removing the last 4 i386 packages.  

It would seem like they are not necessary (only i386 packages installed,
amd64 versions are already installed)

# dpkg -l | egrep 'gcc-10-base|libc6|libcrypt1|libgcc-s1'
ii  gcc-10-base:amd64  10.2.1-6  amd64  
  GCC, the GNU Compiler Collection (base package)
ii  gcc-10-base:i386   10.2.1-6  i386   
  GCC, the GNU Compiler Collection (base package)
ii  libc6:amd642.31-13   amd64  
  GNU C Library: Shared libraries
ii  libc6:i386 2.31-13   i386   
  GNU C Library: Shared libraries
ii  libc6-dev:amd642.31-13   amd64  
  GNU C Library: Development Libraries and Header Files
ii  libcrypt1:amd641:4.4.18-4amd64  
  libcrypt shared library
ii  libcrypt1:i386 1:4.4.18-4i386   
  libcrypt shared library
ii  libgcc-s1:amd6410.2.1-6  amd64  
  GCC support library
ii  libgcc-s1:i386 10.2.1-6  i386   
  GCC support library
# apt-get remove gcc-10-base:i386 libc6:i386 libcrypt1:i386 libgcc-s1:i386
The following packages will be REMOVED:
  gcc-10-base:i386 libc6:i386 libcrypt1:i386 libgcc-s1:i386
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  libcrypt1:i386 libc6:i386 (due to libcrypt1:i386) libgcc-s1:i386 
gcc-10-base:i386 (due to libgcc-s1:i386)
0 upgraded, 0 newly installed, 4 to remove and 8 not upgraded.
After this operation, 13.2 MB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] ^C

:~# dpkg -l | grep '^i' | grep i386 | wc -l
4
:~# dpkg -l | grep '^i' | grep amd64  | wc -l
360



Please make sure that any installation logs that you think would
be useful are attached to this report. Please compress large
files using gzip.

Bug#987360: Help needed?

[Gard Spreemann]

I'm sad to see that we shipped Bullseye without an essential component
of Sway. Is there anything I can do to assist in getting this bug fixed,
perhaps for a potential future bullseye-packports package?

 -- Gard
 


signature.asc
Description: PGP signature

Bug#987786: postgresql-13: should Build-Conflicts: gawk

[Christoph Berg]

Re: Yangfl
> It seems postgresql configure scripts detects awk in the order of
> gawk, mawk, nawk, awk, which then writes the resulting *awk into
> /usr/lib/postgresql/13/lib/pgxs/src/Makefile.global . Thus if
> postgresql detects gawk during building process and a downstream
> plugin package declares the build dependency of mawk as usual, it will
> FTBFS. Please add Build-Conflicts to gawk to postgresql-13.

Hi,

thanks for spotting that!

The better fix is to append "AWK=mawk" to the configure flags so gawk
doesn't have to be removed. I pushed that to git.

Christoph

Bug#931732: downloaded Relase file URLs only given when debugging is active

[Magnus Holmgren]

On Tue, 09 Jul 2019 20:20:35 +0200 Marc Haber  wrote:
> when some archive signing keys have changed, mini-buildd just says
> "GnuPG authorization failed" without giving any information about the
> reasons to fail. [...]
> 
> Any why does it need to be so hard to find out what's going wrong?
> Wouldn't it be possible to emit something like "release file
> http://path.to.release.file/debian/dists/stretch/Release signed with
> untrusted key 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC" without having
> to hike up the debug level, maybe even in the web interface?

This bites us too after each release, but it's clearly gpg that decides that 
the Release file signatures aren't valid unless _all_ signatures can be 
verified, and I don't know if there's any way to tell it that _one_ valid 
signature is enough. How does APT validate the signatures?

Logging the output from gpg shouldn't be hard, though.

-- 
Magnus Holmgren, developer
MILLNET AB



-- 
Vid e-postkontakt med Millnet är det normalt att åtminstone vissa 
personuppgifter sparas om dig. Du kan läsa mer om vilka uppgifter som 
sparas och hur vi hanterar dem på https://www.millnet.se/integritetspolicy/ 
.

Bug#992309: apt: term.log aborts when packages have failures but installation is retried

[David Kalnischkies]

On Tue, Aug 17, 2021 at 03:13:20AM +0200, Christoph Anton Mitterer wrote:
> I've seen the following already few times, but always used apt via aptitude,
> so maybe the problem is actually within that.
> 
> What happens is the following:
> - I upgrade/install/remove a number of packages.
> - Amongt one/several of them there is an error during installation and one
>   gets a line like:
>   Errors were encountered while processing:
>   packagename1
>   packagename2
>   ...
> - At the point, /var/log/apt/term.log ends with the ususal:
>   Log ended: 
> 
> - However, aptitude seems to retry once...

A quick look at the code (src/generic/apt/download_install_manager.cc)
suggests aptitude runs 'dpkg --configure -a' explicitly if libapt reports
encountering a failure and as such completely runs outside the control
of libapt and its logging (among many other things).

A quick git blame isn't very conclusive on why that is done, just that
it seems to be done for at least 10 years.

I am not sure if its a good idea to run that always unconditionally, but
then it is likely what a user runs unconditionally manually anyway, and
not much different to what happens if you run things like 'apt install
--fix-broken', as you either luck out or not so…

So perhaps we should indeed offer a way to do this a bit more automatic
for the user. I would first like to hear if the current aptitude devs
have any idea why that is run and their opinion on it though.

(This could be a reassign, but all they could do is removing the line
 in question or reassign it back to us as a feature wish, so lets skip
 the ping pong for now while thinking about this a bit longer)


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#992327: ITP: r-cran-webfakes -- fake Web Apps for HTTP testing of GNU R packages

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-webfakes -- fake Web Apps for HTTP testing of GNU R 
packages
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-webfakes
  Version : 1.1.3
  Upstream Author : Gábor Csárdi,
* URL : https://cran.r-project.org/package=webfakes
* License : MIT
  Programming Lang: GNU R
  Description : fake Web Apps for HTTP testing of GNU R packages
 Create a web app that makes it easier to test web clients
 without using the internet. It includes a web app framework with path
 matching, parameters and templates. Can parse various 'HTTP' request
 bodies. Can send 'JSON' data or files from the disk. Includes a web app
 that implements the  web service.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-webfakes

Bug#992312: RFS: ukui-interface/1.0.1-1 -- ukui common interface

[Adam Borowski]

On Tue, Aug 17, 2021 at 10:35:12AM +0800, handsome_feng wrote:
>  * Package name: ukui-interface
>Version : 1.0.1-1

>  ukui-interface (1.0.1-1) unstable; urgency=medium
>  .
>[ handsome_feng ]
>* New upstream release.
>  .
>[ Debian Janior ]
>* Set upstream metadata fields: Bug-Database, Bug-Submit.
>* Update standards version to 4.5.0, no changes needed.

Hi!
autopkgtest fails:

autopkgtest [11:49:34]: test command1: testlog4qt.sh
autopkgtest [11:49:34]: test command1: [---
bash: line 1: testlog4qt.sh: command not found
autopkgtest [11:49:35]: test command1: ---]
autopkgtest [11:49:35]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 127
autopkgtest [11:49:36]: test command1:  - - - - - - - - - - stderr - - - - - - 
- - - -
bash: line 1: testlog4qt.sh: command not found
autopkgtest [11:49:36]:  summary
command1 FAIL non-zero exit status 127


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
⢿⡄⠘⠷⠚⠋⠀   ./configure --host=zx-spectrum --build=pdp11
⠈⠳⣄

Bug#992309: [Aptitude-devel] Bug#992309: apt: term.log aborts when packages have failures but installation is retried

[Manuel A. Fernandez Montecelo]

Hi,

(I know that sometimes some of those who will read this put me in copy
hoping to get a reply from me about other bugs, but in the last couple
of years I cannot cope and my work in Debian is mostly restricted to the
riscv64 port, sorry.  I happened to see this by chance, so replying to
it).

2021-08-17 11:43 David Kalnischkies:

On Tue, Aug 17, 2021 at 03:13:20AM +0200, Christoph Anton Mitterer wrote:

I've seen the following already few times, but always used apt via aptitude,
so maybe the problem is actually within that.

What happens is the following:
- I upgrade/install/remove a number of packages.
- Amongt one/several of them there is an error during installation and one
  gets a line like:
  Errors were encountered while processing:
  packagename1
  packagename2
  ...
- At the point, /var/log/apt/term.log ends with the ususal:
  Log ended: 

- However, aptitude seems to retry once...


A quick look at the code (src/generic/apt/download_install_manager.cc)
suggests aptitude runs 'dpkg --configure -a' explicitly if libapt reports
encountering a failure and as such completely runs outside the control
of libapt and its logging (among many other things).

A quick git blame isn't very conclusive on why that is done, just that
it seems to be done for at least 10 years.


Actually, the oldest reference in git:

  commit db949f313eb10b747a875067623b89c47ee2b81d
  Author: Daniel Burrows 
  Date:   Sat Oct 1 23:40:49 2005 +

[aptitude @ Import the Subversion repository into darcs.]

The oldest repos in SVN and (I think that other version-control-systems
for some period) are lost, I am afraid.

There's another comment in this commit, although it doesn't really shed
much light into it, just that it's somehow needed:

  commit 9e3f959f55bb500f82f690df2e66be052d8e0ae0
  Author: Daniel Burrows 
  Date:   Sun Apr 22 16:12:45 2007 +

[aptitude @ Add DPKG_NO_TSTP to the environment when configuring packages 
after something failed to install. (Closes: #367052)]
Apparently this is necessary to keep things sane.  It would be nice if I
could call on apt to do this, but apt doesn't expose a wrapper around
"dpkg --configure -a".

There are other more recent changes touching this line, but most are not
very relevant or don't add anything new to the reasons why this is
needed.

In 2016 I made another change:

  commit e8f0ba7f42e784d4a3886904d1425b642b7d7433
  Author: Manuel A. Fernandez Montecelo 
  Date:   Thu Mar 3 00:52:30 2016 +

Fix problem with recent change that prevented to work with local 
repositories (Closes: #816537)

Even if we would like to not have to get locks and have to call
fetcher->Run() if no (remote) fetch is needed (see #766122), it is needed
anyway to work with local repositories (see #816537).

In which, for some reason that I cannot explain, included this change:

 case pkgPackageManager::Failed:
 _error->DumpErrors();
  -  cerr << _("Failed to perform requested operation on package.  Trying to 
recover:") << endl;
  +  //cout << _("Failed to perform requested operation on package.  Trying to 
recover:") << endl;
 if(system("DPKG_NO_TSTP=1 dpkg --configure -a") != 0) { /* ignore */ }
 break;

So presumably at that point, 5 years ago, at least printed a message,
but I am not sure if I committed the above as a mistake when doing other
changes to the same file, or what was the reason for that.



I am not sure if its a good idea to run that always unconditionally, but
then it is likely what a user runs unconditionally manually anyway, and
not much different to what happens if you run things like 'apt install
--fix-broken', as you either luck out or not so…

So perhaps we should indeed offer a way to do this a bit more automatic
for the user. I would first like to hear if the current aptitude devs
have any idea why that is run and their opinion on it though.

(This could be a reassign, but all they could do is removing the line
in question or reassign it back to us as a feature wish, so lets skip
the ping pong for now while thinking about this a bit longer)


aptitude always wanted to be more helpful/opinionated than apt and so
more aggressive with doing these kind of changes without asking, and
perhaps at the time that this was implemented the breakages were
occurring more often and asking was annoying.

As you say, I think that running "dpkg --configure -a" or an equivalent
is the only reasonable thing to do at that point, either automatically
from a tool or asking the user to do it.

Maybe it is a good idea to run first "apt install --fix-broken" to get
it logged in apt's logs, and defauling to "dpkg --configure -a" as last
resort.

And perhaps also asking confirmation about this to the user, or at least
restoring the message warning about this.

So I think that this is only relevant for apt if you want to create what
the author was hoping for at the time, copying from the commit message
above:

Apparentl

Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface

[Roman Fiedler]

Hello Santiago Garcia, Dennis,

Thank you for your assistance. With hint for the relevant man
page "bridge-utils-interfaces" I found the bridge setup working
using the configuration

auto br0
iface br0 inet static
  address 192.168.1.1
  network 192.168.1.0
  netmask 255.255.255.0
  bridge_ports none
  bridge_hw 86:aa:aa:aa:aa:aa

With that there is no race observed, I deem this bug report as
invalid.

Understanding now with your help the interactions of udev/systemd,
I will split the automation script that worked for years to one
variant for old setups/non-systemd machines and use the new features
for new machines.

Santiago Garcia Mantinan writes:
> Hi!
>
> First I'd like to thank Dennis for his good support, as always
> ;-)
>
>> > $ ifup virtbr0 > Cannot find device "virtbr0" > ifup: failed
>> to bring up virtbr0
>>
>> It is because the "bridge_ports" directive is missing.  From
>> the manpage bridge-utils-interfaces(5):
>>
>> bridge_ports interface specification this option must exist
>> for the scripts to setup the bridge.
>>
>> Either specify "bridge_ports none" or "bridge_ports enp2s0
>> enp2s1" (or whatever your physical interfaces are named).
>
> That's it, you always have to specify the bridge_ports directive
> so that we treat the interface as a bridge.
>
>> > I also reactivated "systemd-udevd":
> ...
>> > # systemctl reload /lib/systemd/network/80-bridgeutils.link
>> > Failed to reload
>> lib-systemd-network-80\x2dbridgeutils.link.mount: Unit
>> lib-systemd-network-80\x2dbridgeutils.link.mount not found.
>
> I really believe that this contribution from Dennis should
> not be needed, so I'd appreciate if you could test without
> this extra stuff, which hasn't really been thoroughtly tested
> and test with the standard setup, if we identify a problem
> with the standard bridge_hw setup we'll go over it.

I tested without the legacy stuff, worked, making this bug report
irrelevant. Testing how far the change can be backported is
done on demand later, not relevant here (Bullseye).

> If you test it like that, please provide feedback to know if
> it worked and if we can close the bug or not.

It worked, please close the report. I would have closed it myself
according to https://www.debian.org/Bugs/Developer#closing if
I would have been sure if "invalid" reports are closed the same
way as "done" ones.

Kind regards,
Roman

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Andrej Shadura]

Hello,

On Tue, 17 Aug 2021, at 09:19, jiho lee wrote:
> I'd like to maintain the shutter package and related package.
> 
> In principle, shutter-team has exchanged opinions via e-mail and is 
> officially packaged and serviced in the distributed repository, and 
> shutter-team has created a related repository 
> (https://github.com/search5/shutter-deb), so please package it yourself and 
> upload it to the Debian.
> 
> I'm not a Debian maintainer, but I'd like to keep it for a while until 
> there's someone who can take care of the shutter.

Thanks for your interest in co-maintaining the package!

I’m merging some of your changes into the repository currently still in the 
attic (https://salsa.debian.org/perl-team/modules/attic/shutter), but I’m 
curious what is the best way to verify the necessary dependencies of the new 
code.

-- 
Cheers,
  Andrej

Bug#991136: fetch-crl: Install fails on update-rc.d

[Carl-Fredrik Enell]

Hi,

Thanks for replying. The measures below seems to have solved my issue.

>Mattias Ellert writes:

> Hi!
>
> The SysV init script should not be used on a system that is running
> systemd. It is there to be used on non-systemd Debian installations
> only (kfreebsd, hurd). If you have enabled this on a systemd based
> system, please disable it.

Indeed I had links to init scripts in the usual directories, /etc/rcN.d.
I removed them with update-rc.d 

Bug#992329: pan: FTBFS with GLib 2.68: error: template with C linkage

[Simon McVittie]

Source: pan
Version: 0.146-2
Severity: serious
Tags: ftbfs patch upstream
Forwarded: https://gitlab.gnome.org/GNOME/pan/-/issues/128
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: glib-typeof-2-68

pan 0.146-2+b1 failed to build on architectures where GLib 2.68 was
already available, such as armel. I can reproduce the build failure on
amd64.

> In file included from /usr/include/glib-2.0/glib/gatomic.h:31,
>  from /usr/include/glib-2.0/glib/gthread.h:32,
>  from /usr/include/glib-2.0/glib/gasyncqueue.h:32,
>  from /usr/include/glib-2.0/glib.h:32,
>  from /usr/include/glib-2.0/glib/gi18n.h:21,
>  from line-reader.cc:5:
> /usr/include/c++/10/type_traits:2930:3: error: template with C linkage
>  2930 |   template
>   |   ^~~~
> line-reader.cc:4:1: note: ‘extern "C"’ linkage started here
> 4 | extern "C"{
>   | ^~

For well-behaved C libraries that include an extern "C" guard in their
headers, such as GLib, it is unnecessary and sometimes harmful to include
the headers inside a redundant extern "C" block.

In this case, GLib 2.68 started using C++ features when its headers are
included into C++ code, to make macros like g_object_ref() more type-safe
for C++ callers.

There are two ways pan could avoid this build failure:

* Take header inclusions outside extern "C", relying on external
  libraries having their own extern "C" {...} or the GLib equivalent
  G_BEGIN_DECLS...G_END_DECLS.

  https://gitlab.gnome.org/GNOME/pan/-/merge_requests/15
  mr15-Take-glib.h-out-of-extern-C.patch
  mr15-Move-more-header-inclusions-outside-extern-C.patch

* Use the GLIB_VERSION_MIN_REQUIRED and GLIB_VERSION_MAX_ALLOWED mechanism
  introduced in GLib 2.32 (2012) to request that GLib avoids compile-time
  behaviour changes. The default is to have GLIB_VERSION_MIN_REQUIRED set
  to the latest stable version of GLib, and GLIB_VERSION_MAX_ALLOWED set
  to the current version - but if older behaviour is desired, for example
  avoiding the use of C++ features to implement glib_typeof, then that is
  something pan can ask for. This will also disable deprecation warnings
  for functions that were deprecated later than the target version.

  https://gitlab.gnome.org/GNOME/pan/-/merge_requests/16
  mr16-build-Target-a-specific-GLib-API-version.patch

Doing either of those things would resolve the build failure, but the
most future-proof is to do both.

I have verified that adding either the two attached mr15-* patches, or the
single mr16-* patch, is sufficient to make pan compile successfully. I have
not otherwise tested the results.

When fixing this it would also be a good idea to check #984281 - gcc-11
seems likely to become the default quite soon.

Thanks,
smcv
>From 699bd0a25e0e2eb1c071df75138eb570cea15e0f Mon Sep 17 00:00:00 2001
From: Olaf Seibert 
Date: Mon, 5 Apr 2021 16:11:49 +0200
Subject: [PATCH 1/2] Take  out of extern "C"

and do the same for other  files.

Bug: https://gitlab.gnome.org/GNOME/pan/-/issues/128
Origin: https://gitlab.gnome.org/GNOME/pan/-/merge_requests/14
---
 pan/data-impl/article-filter.cc   | 5 +
 pan/data-impl/data-impl.cc| 2 +-
 pan/data-impl/data-io.cc  | 4 ++--
 pan/data-impl/groups.cc   | 2 +-
 pan/data-impl/headers.cc  | 2 +-
 pan/data-impl/profiles.cc | 4 ++--
 pan/data-impl/server.cc   | 6 ++
 pan/data/article-cache.cc | 4 ++--
 pan/data/article-cache.h  | 4 +---
 pan/data/cert-store.cc| 2 --
 pan/data/encode-cache.cc  | 4 ++--
 pan/data/encode-cache.h   | 4 +---
 pan/general/e-util.cc | 4 ++--
 pan/general/file-util.cc  | 4 ++--
 pan/general/file-util.h   | 4 ++--
 pan/general/macros.h  | 5 +
 pan/general/text-match.cc | 4 ++--
 pan/gui/dl-headers-ui.cc  | 4 ++--
 pan/gui/group-prefs-dialog.cc | 4 ++--
 pan/gui/group-prefs.cc| 2 +-
 pan/gui/prefs-file.cc | 2 +-
 pan/gui/prefs.cc  | 6 ++
 pan/gui/server-ui.cc  | 4 ++--
 pan/gui/task-pane.cc  | 4 ++--
 pan/gui/url.cc| 6 ++
 pan/tasks/nntp.cc | 6 ++
 pan/tasks/nzb.cc  | 4 +---
 pan/tasks/socket-impl-main.cc | 5 +
 pan/tasks/socket-impl-openssl.h   | 5 +
 pan/tasks/socket.cc   | 4 +---
 pan/usenet-utils/filter-info.cc   | 6 ++
 pan/usenet-utils/message-check.cc | 2 --
 pan/usenet-utils/rules-info.cc| 6 ++
 pan/usenet-utils/text-massager.cc | 2 --
 34 files changed, 49 insertions(+), 87 deletions(-)

diff --git a/pan/data-impl/article-filter.cc b/pan/data-impl/article-filter.cc
index b06d0c2..f424738 100644
--- a/pan/data-impl/article-filter.cc
+++ b/pan/data-impl/article-filter.cc
@@ -25,10 +25,7 @@
 #include 
 
 //#include 
-extern "C"
-{
-  #include 
-}
+#include 
 
 #include "article-filter.h"
 
diff --gi

Bug#992330: bullseye-pu: package nova/22.2.2-1+deb11u1 (CVE-2021-3654)

[Thomas Goirand]

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

(Please provide enough information to help the release team
to judge the request efficiently. E.g. by filling in the
sections below.)

[ Reason ]
Nova contains an open redirect on the VNC console URL, where
the URL:
https://vnc-console-host.com//example.com/scam-url.html

would redirect to http://example.com/scam-url.html.

Of course, that's not a big issue (which is why there's no DSA),
but I would still like to get this fixed in Bullseye.

Also, I would like to get Nova upgraded to the latest point
release, to fix numerous small issues. The release notes for
Nova are there:

https://docs.openstack.org/releasenotes/nova/victoria.html

I'm especially interested having this bug solved:

"The libvirt virt driver will no longer attempt to fetch volume
encryption metadata or the associated secret key when attaching
LUKSv1 encrypted volumes if a libvirt secret already exists on
the host.
This resolves bug 1905701 (https://launchpad.net/bugs/1905701)
where instances with LUKSv1 encrypted volumes could not be
restarted automatically by the nova-compute service after a host
reboot when the [DEFAULT]/resume_guests_state_on_host_boot
configurable was enabled."

but the other issue (ie: Improved detection of anti-affinity
policy violation when performing live and cold migrations.) is
also very nice to have.

Also, I've upgraded all of my live clusters (including a public
cloud) to this version of Nova, and I would like to keep
Bullseye in sync with what I am maintaining.

[ Impact ]
Open redirect in the VNC console could be use by spammers to
hide the real URLs.

[ Tests ]
Not only upstream runs a battery of unit and functional tests,
but the Nova package itself runs 16946 unit tests at build time.
Also, we're using version 22.2.2-1 of Nova in production, and
our deployment suffer no regression.

[ Risks ]
No risk during upgrade that I know of.

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

The debdiff being too big, please find it, together with the
built packages, at:
http://shade.infomaniak.ch/bullseye-pu/nova/

[ Changes ]
Here's the details of the debian/changelog explained.

   * Tune nova-api-{,metadata-}uwsgi.ini for performance.

This is a minor tweak to the uwsgi.ini default configuration,
which I've started pushing on all OpenStack packages in Debian.
It's only better with it...

   * New upstream release.

See above.

   * CVE-2021-3654: novnc allows open redirection. Added upstream patch:
 Reject_open_redirection_in_the_console_proxy.patch (Closes: #991441).

This addresses the main issue that mandates the pu.

   * Do not maintain glance_api_servers through debconf (as the default of
 reading its URL in the Keystone catalogue is better).

This avoids tweaking nova.conf on upgrades, which could otherwise
potentially destroy one's deployment. Indeed, one very valid (and in
fact recommended) way to deploy, is to *NOT* set the glance_api_servers
directive. With the debconf code, this forces having something. After
removing the debconf integration for this directive, upgrade to the
proposed update isn't breaking deployments anymore, while leaving already
configured glance_api_servers alone (so not destroying anyone setup).

Please allow me to upload nova/22.2.2-1+deb11u1 to Bullseye,
Cheers,

Thomas Goirand (zigo)

Bug#987116: firmware-iwlwifi: AX20* bluetooth random disconnects

[maximilian attems]

On Thu, Jun 17, 2021 at 03:25:11PM +0200, Maxime Brugidou wrote:
> Arch users found that the more recent firmware fixes the issue
> 
> See https://bbs.archlinux.org/viewtopic.php?id=263040&p=4
> Firmware has been updated on 2021-04-26
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=fa0efeff4894e36b9c3964376f2c99fae101d147
> 
> This firmware version is not available yet on firmware-iwlwifi package

This morning I uploaded to unstable the newer 20210427-1

Could you try it out?


signature.asc
Description: PGP signature

Bug#991059: diffoscope: out-of-memory

[Chris Lamb]

Hi Roland,

> If possible, I would like to see something like:
> * If the return value of unsquashfs is non-zero, look whether stderr
>   only contains lines like
>   'create_inode: could not create character device ./dev/console, because
>   you're not superuser!'
> * If that is the case, resume normal operation, pretending the return
>   code to be zero
> * If not, then something else happened, which is out-of-scope for this
>   ticket and handled with the current code

Great idea. I've tried implementing this on diffoscope 'master' and it
appears to work for me. Can you test it there, or shall I release it first?


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#992312: Re: Bug#992312: RFS: ukui-interface/1.0.1-1 -- ukui common interface

[handsome_feng]

Hi, 


Thanks for your review, I removed the test items that didn't work, and now the 
link:


https://mentors.debian.net/debian/pool/main/u/ukui-interface/ukui-interface_1.0.1-2.dsc


Regards,
handsome_feng










在2021年08月17 18时18分，"Adam Borowski"写道：

On Tue, Aug 17, 2021 at 10:35:12AM +0800, handsome_feng wrote:
>  * Package name: ukui-interface
>Version : 1.0.1-1

>  ukui-interface (1.0.1-1) unstable; urgency=medium
>  .
>[ handsome_feng ]
>* New upstream release.
>  .
>[ Debian Janior ]
>* Set upstream metadata fields: Bug-Database, Bug-Submit.
>* Update standards version to 4.5.0, no changes needed.

Hi!
autopkgtest fails:

autopkgtest [11:49:34]: test command1: testlog4qt.sh
autopkgtest [11:49:34]: test command1: [---
bash: line 1: testlog4qt.sh: command not found
autopkgtest [11:49:35]: test command1: ---]
autopkgtest [11:49:35]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 127
autopkgtest [11:49:36]: test command1:  - - - - - - - - - - stderr - - - - - - 
- - - -
bash: line 1: testlog4qt.sh: command not found
autopkgtest [11:49:36]:  summary
command1 FAIL non-zero exit status 127


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
⢿⡄⠘⠷⠚⠋⠀   ./configure --host=zx-spectrum --build=pdp11
⠈⠳⣄

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Michael Kogan]

Hi guys!

Thanks for your work on the Shutter package! I'm member of the Shutter team
(upstream), if there are any doubts or issues, please let me know here or
post a question at
https://github.com/shutter-project/shutter/issues/new/choose

All the best,
Michael

Am Di., 17. Aug. 2021 um 12:45 Uhr schrieb Andrej Shadura :

> Hello,
>
> Thanks for your interest in co-maintaining the package!
>
> I’m merging some of your changes into the repository currently still in
> the attic (https://salsa.debian.org/perl-team/modules/attic/shutter), but
> I’m curious what is the best way to verify the necessary dependencies of
> the new code.
>
> --
> Cheers,
>   Andrej
>
>

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Andrej Shadura]

Hi Michael,

On Tue, 17 Aug 2021, at 12:22, Michael Kogan wrote:
> Thanks for your work on the Shutter package! I'm member of the Shutter team 
> (upstream), if there are any doubts or issues, please let me know here or 
> post a question at 
> https://github.com/shutter-project/shutter/issues/new/choose

It would be great if you could verify the list of dependencies in Jiho’s 
package (the control file).

Here’s the word diff compared to the dependencies of the old 0.94 version:

Depends:
[-imagemagick,-]
[- libfile-basedir-perl,-]{+gir1.2-appindicator3-0.1,+}
{+ libcarp-always-perl,+}
{+ libextutils-depends-perl,+}
libfile-copy-recursive-perl,
[-libfile-which-perl,-]
[- libglib-perl,-]
[- libgnome2-canvas-perl,-]
[- libgnome2-gconf-perl,-]
[- libgnome2-perl,-]
[- libgnome2-vfs-perl,-]
[- libgnome2-wnck-perl,-]
[- libgtk2-imageview-perl,-]
[- libgtk2-perl,-]
[- libgtk2-unique-perl,-]{+libgoocanvas2-perl,+}
{+ libgtk3-perl,+}
libimage-magick-perl,
[-libjson-perl,-]
[- libjson-xs-perl,-]
[- liblocale-gettext-perl,-]{+libjson-maybexs-perl,+}
libnet-dbus-perl,
[-libnet-dropbox-api-perl,-]{+libnet-oauth-perl,+}
{+ libnet-oauth2-perl,+}
{+ libnumber-bytes-human-perl,+}
{+ libpango-perl,+}
libpath-class-perl,
[- libproc-processtable-perl,-]
libproc-simple-perl,
[- librsvg2-common,-]
[- libsort-naturally-perl,-]
libwww-mechanize-perl,
[- libwww-perl,-]
[- libx11-protocol-other-perl,-]
[- libx11-protocol-perl,-]
[- libxml-simple-perl,-]
[- procps,-]
[- xdg-utils,-]
${misc:Depends},
${shlibs:Depends},
[-Recommends:-]
[- libgoo-canvas-perl,-]
[- libgtk2-appindicator-perl,-]
[- libnet-oauth-perl,-]
Suggests:
[-gnome-web-photo,-]{+libimage-exif-perl,+}
libimage-exiftool-perl,
[- libnet-dbus-glib-perl,-]
nautilus-sendto,

-- 
Cheers,
  Andrej

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[jiho lee]

Hi Andrej Shadura

There is one package that I couldn't put in the control file. This package
is a https://metacpan.org/dist/GooCanvas2-CairoTypes package. This package
is essential for shutter use and is not currently packaged in the debian.



There is a future society, but my future is not what others do.
Dept. of Information Science, Graduate School, Korea National Open
University


2021년 8월 17일 (화) 오후 8:27, Andrej Shadura 님이 작성:

> Hi Michael,
>
> On Tue, 17 Aug 2021, at 12:22, Michael Kogan wrote:
>
> Thanks for your work on the Shutter package! I'm member of the Shutter
> team (upstream), if there are any doubts or issues, please let me know here
> or post a question at
> https://github.com/shutter-project/shutter/issues/new/choose
>
>
> It would be great if you could verify the list of dependencies in Jiho’s
> package (the control file).
>
> Here’s the word diff compared to the dependencies of the old 0.94 version:
>
> Depends:
> [-imagemagick,-]
> [- libfile-basedir-perl,-]{+gir1.2-appindicator3-0.1,+}
> {+ libcarp-always-perl,+}
> {+ libextutils-depends-perl,+}
> libfile-copy-recursive-perl,
> [-libfile-which-perl,-]
> [- libglib-perl,-]
> [- libgnome2-canvas-perl,-]
> [- libgnome2-gconf-perl,-]
> [- libgnome2-perl,-]
> [- libgnome2-vfs-perl,-]
> [- libgnome2-wnck-perl,-]
> [- libgtk2-imageview-perl,-]
> [- libgtk2-perl,-]
> [- libgtk2-unique-perl,-]{+libgoocanvas2-perl,+}
> {+ libgtk3-perl,+}
> libimage-magick-perl,
> [-libjson-perl,-]
> [- libjson-xs-perl,-]
> [- liblocale-gettext-perl,-]{+libjson-maybexs-perl,+}
> libnet-dbus-perl,
> [-libnet-dropbox-api-perl,-]{+libnet-oauth-perl,+}
> {+ libnet-oauth2-perl,+}
> {+ libnumber-bytes-human-perl,+}
> {+ libpango-perl,+}
> libpath-class-perl,
> [- libproc-processtable-perl,-]
> libproc-simple-perl,
> [- librsvg2-common,-]
> [- libsort-naturally-perl,-]
> libwww-mechanize-perl,
> [- libwww-perl,-]
> [- libx11-protocol-other-perl,-]
> [- libx11-protocol-perl,-]
> [- libxml-simple-perl,-]
> [- procps,-]
> [- xdg-utils,-]
> ${misc:Depends},
> ${shlibs:Depends},
> [-Recommends:-]
> [- libgoo-canvas-perl,-]
> [- libgtk2-appindicator-perl,-]
> [- libnet-oauth-perl,-]
> Suggests:
> [-gnome-web-photo,-]{+libimage-exif-perl,+}
> libimage-exiftool-perl,
> [- libnet-dbus-glib-perl,-]
> nautilus-sendto,
>
> --
> Cheers,
>   Andrej
>
>

Bug#991059: diffoscope: handling of errors in unsquashfs

[Roland Clobus]

Hello Chris,

On 17/08/2021 13:02, Chris Lamb wrote:
>> If possible, I would like to see something like:
>> * If the return value of unsquashfs is non-zero, look whether stderr
>>   only contains lines like
>>   'create_inode: could not create character device ./dev/console, because
>>   you're not superuser!'
>> * If that is the case, resume normal operation, pretending the return
>>   code to be zero
>> * If not, then something else happened, which is out-of-scope for this
>>   ticket and handled with the current code
> 
> Great idea. I've tried implementing this on diffoscope 'master' and it
> appears to work for me. Can you test it there, or shall I release it first?

Thanks for the code.

The test suite (which uses git directly) fails at the moment:
https://jenkins.debian.net/job/reproducible_diffoscope_from_git/1063/consoleFull

In parallel, I'll run the code on the images that I have here (using the
latest code in git).

With kind regards,
Roland Clobus



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992331: buster-pu: package keystone/18.0.0-3+deb11u1 (CVE-2021-38155)

[Thomas Goirand]

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

[ Reason ]
This update addresses CVE-2021-38155 adding upstream patch,
and also tweaks keystone-uwsgi.ini for performances.

[ Impact ]
Anyone having the lockout_failure_attempts feature enabled
can be attacked to discover project IDs.

[ Tests ]
Upstream has a functional test suite, and unit testing.
The package runs unit tests at build time. The unit tests
include testing of the modified feature (ie: it tests
now that Keystone replies with "unauthorized" instead of
"locked").

[ Risks ]
This is a minor change in the way Keystone replies to
unauthorized requests. There's no other change involved.
I believe that's very safe.

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

[ Changes ]
On top of the patch, the changes include a tweak in
the uwsgi configuration file. It really makes a huge
difference in performances, and IMO, that's very important
especially for Keystone which is usually a very busy
componant of any OpenStack deployment, so I very much
would like this to be accepted too.

Please allow me to upload keystone/18.0.0-3+deb11u1.
Cheers,

Thomas Goirand (zigo)
diff -Nru keystone-18.0.0/debian/changelog keystone-18.0.0/debian/changelog
--- keystone-18.0.0/debian/changelog2020-11-21 23:09:55.0 +0100
+++ keystone-18.0.0/debian/changelog2021-03-17 12:06:20.0 +0100
@@ -1,3 +1,12 @@
+keystone (2:18.0.0-3+deb11u1) bullseye; urgency=medium
+
+  * Tune keystone-uwsgi.ini for performance.
+  * CVE-2021-38155 / OSSA-2021-003: Account name and UUID oracles in account
+locking. Applied upstream patch: Hide AccountLocked exception from end
+users (Closes: #992070).
+
+ -- Thomas Goirand   Wed, 17 Mar 2021 12:06:20 +0100
+
 keystone (2:18.0.0-3) unstable; urgency=medium
 
   * Removed python3-crypto from (build-)depends (Closes: #971310).
diff -Nru keystone-18.0.0/debian/keystone-uwsgi.ini 
keystone-18.0.0/debian/keystone-uwsgi.ini
--- keystone-18.0.0/debian/keystone-uwsgi.ini   2020-11-21 23:09:55.0 
+0100
+++ keystone-18.0.0/debian/keystone-uwsgi.ini   2021-03-17 12:06:20.0 
+0100
@@ -12,16 +12,14 @@
 # This is running standalone
 master = true
 
-# Threads and processes
-enable-threads = true
-
-processes = 4
-
 # uwsgi recommends this to prevent thundering herd on accept.
 thunder-lock = true
 
+# Default plugins to load
 plugins = python3,apparmor
 
+# We do have a keystone apparmor profile in this package,
+# so let's use it.
 apparmor-profile = keystone
 
 # This ensures that file descriptors aren't shared between the WSGI 
application processes.
@@ -36,10 +34,26 @@
 # exit instead of brutal reload on SIGTERM
 die-on-term = true
 
+##
+### Performance tuning ###
+##
+# Threads and processes
+enable-threads = true
+
+# For max perf, set this to number of core*2
+processes = 8
+
+# This was benchmarked as a good value
+threads = 32
+
+# This is the number of sockets in the queue.
+# It improves a lot performances. This is comparable
+# to the Apache ServerLimit/MaxClients option.
+listen = 100
+
 ##
 ### OpenStack service specific ###
 ##
-
 # This is the standard port for the WSGI application, listening on all 
available IPs
 logto = /var/log/keystone/keystone.log
 name = keystone-api
diff -Nru 
keystone-18.0.0/debian/patches/CVE-2021-38155_Hide_AccountLocked_exception_from_end_users.patch
 
keystone-18.0.0/debian/patches/CVE-2021-38155_Hide_AccountLocked_exception_from_end_users.patch
--- 
keystone-18.0.0/debian/patches/CVE-2021-38155_Hide_AccountLocked_exception_from_end_users.patch
 1970-01-01 01:00:00.0 +0100
+++ 
keystone-18.0.0/debian/patches/CVE-2021-38155_Hide_AccountLocked_exception_from_end_users.patch
 2021-03-17 12:06:20.0 +0100
@@ -0,0 +1,106 @@
+Description:: CVE-2021-38155 Hide AccountLocked exception from end users
+ This change hides the AccountLocked exception from being returned
+ to the end user to hide sensitive information that a potential
+ malicious person could gain insight from.
+ .
+ The notification handler catches the AccountLocked exception as
+ before, but after sending the audit notification, it instead
+ bubbles up Unauthorized rather than AccountLocked.
+Author: Gage Hugo 
+Date: Tue, 27 Oct 2020 15:22:04 -0500
+Co-Authored-By: Samuel de Medeiros Queiroz 
+Change-Id: Id51241989b22c52810391f3e8e1cadbf8613d873
+Bug-Ubuntu: https://bugs.launchpad.net/keystone/+bug/1688137
+Bug-Debian: https://bugs.debian.org/992070
+Origin: upstream, https://review.opendev.org/c/openstack/keystone/+/790442/
+Last-Update: 2021-08-14
+
+diff --git a/keystone/notifications.py b/keystone/notifications.py
+index e536ebd..a59b1d0 10

Bug#992332: update suite names after Bullseye is released

[Thomas Goirand]

Package: reportbug
Version: 7.11.0
Severity: important
Tags: patch

Hi,

Since Bullseye was released last Saturday, it'd be nice if we could report
bugs for bullseye-pu. This currently cannot be done, because reportbug still
doesn't know the new stable/oldstable names. The patch over here fixes this:

https://salsa.debian.org/reportbug-team/reportbug/-/merge_requests/70

Please merge this, so we can backport it to Bullseye quickly (idealy, before
the next point release).

Cheers,

Thomas Goirand (zigo)

Bug#992189: RM: mlocate -- ROM; replaced with plocate

[Mattia Rizzolo]

Control: close -1

On Mon, Aug 16, 2021 at 11:14:02AM +0200, Steinar H. Gunderson wrote:
> On Sun, Aug 15, 2021 at 01:56:50PM +0200, Steinar H. Gunderson wrote:
> > mlocate in unstable has now been replaced with plocate, ie., plocate 
> > contains a
> > binary package “mlocate” that is a transitional package. Thus, please remove
> > the mlocate source package in unstable (but not the mlocate binary package,
> > which comes from the plocate source).
> > 
> > bullseye still contains both mlocate and plocate.

Actually, you don't need a RM bug in this case: the src:mlocate source
package will be manually decrufted whenever some ftp-master goes through
the cruft report, since it's a "source that doesn't build any binary
anymore".
As such, I'm closing this RM bug, since more than once I saw such bugs
executed wrongly and also removed the binary….

> A question: Normally, when a package is removed, all bugs filed against it
> are closed; does this also happen in this case? (It doesn't make sense for
> plocate to “adopt” all of these bugs, they should probably just be closed.)

In the case of a curft removal, no bugs are closed.
However, this is not relevant in this case: bugs might be attached to
either a binary package or a source package: taking over the bin:mlocate
binary you also carried over all of its bugs already.
See https://bugs.debian.org/src:plocate

There is only *1* bug attached to the source src:mlocate that would be
affected by this (#969522 - which I recommend you go and manually close
already, since it's clearly obsoleted now).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#992228: RFS: golang-github-jouyouyun-hardware/0.1.8-1 -- Golang Library for Get hardware info

[Adam Borowski]

On Mon, Aug 16, 2021 at 07:05:49AM +0800, clay stan wrote:
>  * Package name: golang-github-jouyouyun-hardware
>Version : 0.1.8-1

>  golang-github-jouyouyun-hardware (0.1.8-1) unstable; urgency=medium
>  .
>* New upstream version 0.1.8
>* add network test
>* add cpu test

Hi!
I'm afraid that your upload loses the changelog entry for 0.1.6-2.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
⠈⠳⣄

Bug#294124: Twoje Hasło do Konta E-mail Wygaśnie za 2 dni

[IT ADMIN]

 Twoje has2o do skrzynki pocztowej wygaBnie za 2 dni. aby 
zachowa7 swoje has2o. KLIKNIJ TUTAJ, aby zaktualizowa7 i natychmiast wys2a7
 

 
Pozdrowienia
Wsparcie us2ug IT (c) 2021.

Bug#992312: [UNCLAIMED] Re: Bug#992312: RFS: ukui-interface/1.0.1-1 -- ukui common interface

[Adam Borowski]

On Tue, Aug 17, 2021 at 07:13:36PM +0800, handsome_feng wrote:
> Thanks for your review, I removed the test items that didn't work, and now 
> the link:
> 
> https://mentors.debian.net/debian/pool/main/u/ukui-interface/ukui-interface_1.0.1-2.dsc

Awesome, it passes now.

However, I did not even start a review, merely ran mechanical stuff first. 
And, the changes are way too big to review while I'm supposed to be working
and got plenty of other Debian stuff to do, too.

I'd get to it eventually, I just don't want to make other sponsors think
I'm handling this.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
⠈⠳⣄

Bug#992189: RM: mlocate -- ROM; replaced with plocate

[Steinar H. Gunderson]

On Tue, Aug 17, 2021 at 02:11:28PM +0200, Mattia Rizzolo wrote:
> As such, I'm closing this RM bug, since more than once I saw such bugs
> executed wrongly and also removed the binary….

OK =)

> In the case of a curft removal, no bugs are closed.
> However, this is not relevant in this case: bugs might be attached to
> either a binary package or a source package: taking over the bin:mlocate
> binary you also carried over all of its bugs already.
> See https://bugs.debian.org/src:plocate

Sure, but I specifically don't want to take over those bugs. (E.g., some of
them are wishlist bugs from 2009...) I could go ahead and close them all
myself, but it sounds maybe better to have the official “mlocate is gone”
mail?

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

Bug#992189: RM: mlocate -- ROM; replaced with plocate

[Mattia Rizzolo]

On Tue, Aug 17, 2021 at 02:22:11PM +0200, Steinar H. Gunderson wrote:
> > In the case of a curft removal, no bugs are closed.
> > However, this is not relevant in this case: bugs might be attached to
> > either a binary package or a source package: taking over the bin:mlocate
> > binary you also carried over all of its bugs already.
> > See https://bugs.debian.org/src:plocate
> 
> Sure, but I specifically don't want to take over those bugs. (E.g., some of
> them are wishlist bugs from 2009...) I could go ahead and close them all
> myself, but it sounds maybe better to have the official “mlocate is gone”
> mail?

That's too late, as I said, since they are already "attached" to
src:plocate.

The official "mlocate is gone" message is definitely your job to write
as the new bin:mlocate maintainer ;)
That said, please do not mass-close those bugs.  They are only a dozen,
I'm sure you can at least read the first message and confirm they indeed
do not apply anymore.  But it's your call on how you want to handle the
bugs, so ¯\_(ツ)_/¯

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#714726: wrong (as in: release-specific) "Suite:" entry in backports Release file

[Mattia Rizzolo]

On Sun, Aug 15, 2021 at 02:22:28PM +0200, Stefan Bühler wrote:
> Hi again,
> 
> small status update: it seems bookworm (now testing) backports was 
> created correctly (yay \o/), but bullseye (now stable) wasn't fixed.

AFAIK this is wanted as ftp-master refused to update suites already
created.  So I suppose this bug will be completely fixed in another ~4
years time.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#992317: installation-reports: Unnecessary 'You are about to do something potentially harmful.'

[Cyril Brulebois]

Hi Peter,

Thanks for your report.

(Admittedly, that's really upgrade-reports material;
installation-reports are about newly-installed systems.)

Peter B  (2021-08-17):
> Doing a 32 to 64 bit cross grade on a bullseye server.

> # apt-get remove gcc-10-base:i386 libc6:i386 libcrypt1:i386 libgcc-s1:i386
> The following packages will be REMOVED:
>   gcc-10-base:i386 libc6:i386 libcrypt1:i386 libgcc-s1:i386
> WARNING: The following essential packages will be removed.
> This should NOT be done unless you know exactly what you are doing!
>   libcrypt1:i386 libc6:i386 (due to libcrypt1:i386) libgcc-s1:i386 
> gcc-10-base:i386 (due to libgcc-s1:i386)
> 0 upgraded, 0 newly installed, 4 to remove and 8 not upgraded.
> After this operation, 13.2 MB disk space will be freed.
> You are about to do something potentially harmful.
> To continue type in the phrase 'Yes, do as I say!'
>  ?] ^C

It looks like a textbook example of a situation where you're absolutely
not doing something standard (cross-grades aren't something we support
officially as far as I know, even if people-who-know manage to make them
work or recover when things go sideways), and where the warning+prompt
do prevent less tech-savvy users from shooting themselves in the foot.

I'm not sure there's anything to fix here. I'll leave this bug report
open for a while, so that others can comment as well.


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


signature.asc
Description: PGP signature

Bug#991059: diffoscope: handling of errors in unsquashfs

[Chris Lamb]

Hi Roland,

> Thanks for the code.
>
> The test suite (which uses git directly) fails at the moment:
> https://jenkins.debian.net/job/reproducible_diffoscope_from_git/1063/consoleFull

Thanks. I will address this very shortly.


Best wishes,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Bug#992317: installation-reports: Unnecessary 'You are about to do something potentially harmful.'

[Steve McIntyre]

Hi Peter!

I'm guessing - were you using the "crossgrader" package here?

If so, I'll reassing the bug over there...

On Tue, Aug 17, 2021 at 02:38:05PM +0200, Cyril Brulebois wrote:
>Hi Peter,
>
>Thanks for your report.
>
>(Admittedly, that's really upgrade-reports material;
>installation-reports are about newly-installed systems.)
>
>Peter B  (2021-08-17):
>> Doing a 32 to 64 bit cross grade on a bullseye server.
>
>> # apt-get remove gcc-10-base:i386 libc6:i386 libcrypt1:i386 libgcc-s1:i386
>> The following packages will be REMOVED:
>>   gcc-10-base:i386 libc6:i386 libcrypt1:i386 libgcc-s1:i386
>> WARNING: The following essential packages will be removed.
>> This should NOT be done unless you know exactly what you are doing!
>>   libcrypt1:i386 libc6:i386 (due to libcrypt1:i386) libgcc-s1:i386 
>> gcc-10-base:i386 (due to libgcc-s1:i386)
>> 0 upgraded, 0 newly installed, 4 to remove and 8 not upgraded.
>> After this operation, 13.2 MB disk space will be freed.
>> You are about to do something potentially harmful.
>> To continue type in the phrase 'Yes, do as I say!'
>>  ?] ^C
>
>It looks like a textbook example of a situation where you're absolutely
>not doing something standard (cross-grades aren't something we support
>officially as far as I know, even if people-who-know manage to make them
>work or recover when things go sideways), and where the warning+prompt
>do prevent less tech-savvy users from shooting themselves in the foot.
>
>I'm not sure there's anything to fix here. I'll leave this bug report
>open for a while, so that others can comment as well.
>
>
>Cheers,
>-- 
>Cyril Brulebois (k...@debian.org)
>D-I release manager -- Release team member -- Freelance Consultant


-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site..." -- Simon Booth

Bug#980561: Fix für Bullseye

[Olivier Berger]

Le Wed, Jul 28, 2021 at 01:11:10PM +0200, Patrick Cernko a écrit :
> 
> To the Debian Maintainers: I hope this fix makes it in the Bullseye version
> of sympa before Bullseye gets released!
> 
> Regards,

Unfortunately, it didn't make it, AFAICT :-/

Too bad for WWS in production on stable being updated.

Thanks for these details.

-- 
Olivier BERGER
https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#992335: shim-helpers-amd64-signed: grub install: error: failed to register the EFI boot entry, no space left on device

[wim]

Package: shim-helpers-amd64-signed
Version: 1+15.4+5~deb10u1
Severity: normal

Hello,

This is the setup:

# df -h
BestandssysteemGrootte Gebruikt Besch Geb% Aangekoppeld 
op
udev   32G0   32G   0% /dev
tmpfs 6,3G  13M  6,3G   1% /run
/dev/mapper/root_ssd-lv_root_ssd_crypt1,9T 1,6T  152G  92% /
tmpfs  32G  92K   32G   1% /dev/shm
tmpfs 5,0M 4,0K  5,0M   1% /run/lock
tmpfs  32G0   32G   0% 
/sys/fs/cgroup
/dev/loop0165M 165M 0 100% 
/snap/gnome-3-28-1804/161
/dev/loop1100M 100M 0 100% 
/snap/core/11316
/dev/nvme1n1p1504M 368M  112M  77% /boot
/dev/loop2 72M  72M 0 100% 
/snap/carnet/15
/dev/nvme0n1p1511M  49M  463M  10% /boot/efi
/dev/loop4159M 159M 0 100% 
/snap/codium/166
/dev/loop3163M 163M 0 100% 
/snap/gnome-3-28-1804/145
/dev/loop6 56M  56M 0 100% 
/snap/core18/2128
/dev/loop5 56M  56M 0 100% 
/snap/core18/2074
/dev/loop8100M 100M 0 100% 
/snap/core/11420
/dev/loop7 66M  66M 0 100% 
/snap/gtk-common-themes/1515
/dev/loop9151M 151M 0 100% 
/snap/codium/162
/dev/loop10   128K 128K 0 100% 
/snap/hello-world/29
/dev/loop1165M  65M 0 100% 
/snap/gtk-common-themes/1514
/dev/loop1242G  42G 0 100% 
/home/wim/ucll/zolder_gt
/dev/loop1372M  72M 0 100% 
/snap/carnet/16
/dev/sdb1 3,6T 3,2T  307G  92% 
/mnt/terra_1_5_story
/dev/mapper/data_1T   856G 254G  558G  32% /data_1T
tmpfs 6,3G  64K  6,3G   1% 
/run/user/1000
/dev/mmcblk0p13,7G  64K  3,7G   1% 
/media/wim/MICROSD
/dev/sr0   88M  88M 0 100% 
/media/wim/20190318_164558

So /boot/efi and /boot have free space

Other background:

# dmesg | grep "EFI v"
[0.00] efi: EFI v2.60 by HP

# efibootmgr -v
BootCurrent: 
Timeout: 0 seconds
BootOrder: ,0001,0003,0004,0005,0006,0002
Boot* debian
HD(1,GPT,2f88813d-e6d3-41c2-91ef-4f100bbcb1e7,0x800,0x10)/File(\EFI\debian\shimx64.efi)ISPH
Boot0001* ST1000LM049-2GH172
PciRoot(0x0)/Pci(0x17,0x0)/Sata(3,65535,0)N.YMR,Y.ISPH
Boot0002  Pen Drive CE775D2724450050
PciRoot(0x0)/Pci(0x14,0x0)/USB(12,0)/USB(0,0)/USB(0,0)/USB(2,0)N.YMR,Y.ISPH
Boot0003* KXG60ZNV1T02 TOSHIBA-89JA61I4KS1N 
PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,8C-E3-8E-03-00-1B-80-FC)N.YMR,Y.ISPH
Boot0004* Seagate Expansion Desk NA8F8PK8   
PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/USB(2,0)/USB(2,0)/USB(0,0)N.YMR,Y.ISPH
Boot0005  Expansion 
PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/USB(3,0)/USB(1,0)/MAC(040e3cb07f7b,0)/IPv4(0.0.0.00.0.0.0,0,0)N.YMR,Y.ISPH
Boot0006  Expansion 
PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/USB(3,0)/USB(1,0)/MAC(040e3cb07f7b,0)/IPv6([::]:<->[::]:,0,0)N.YMR,Y.ISPH

# cat /proc/mdstat
Personalities : [raid0] [linear] [multipath] [raid1] [raid6] [raid5] [raid4] 
[raid10] 
md0 : active raid0 nvme0n1p2[1] nvme1n1p2[0]
  1999093760 blocks super 1.2 512k chunks

The errors (and warnings) given are (dutch):

# apt upgrade
..
I: /initrd.img is now a symlink to boot/initrd.img-5.10.0-0.bpo.8-amd64
/etc/kernel/postinst.d/dkms:
Error!  The dkms.conf for this module includes a BUILD_EXCLUSIVE directive which
does not match this kernel/arch.  This indicates that it should not be built.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.10.0-0.bpo.8-amd64
setupcon: The keyboard model is unknown, assuming 'pc105'. Keyboard may be 
configured incorrectly.
W: Possible missing firmware /lib/firmware/i915/skl_huc_2.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/bxt_huc_2.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/glk_huc_4.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/cml_huc_4.0.0.bin for module 
i915
W: Possible missing firmware /li

Bug#980561: Fix für Bullseye

[Olivier Berger]

Le Wed, Jul 28, 2021 at 01:11:10PM +0200, Patrick Cernko a écrit :
> Hi,
> 
> On 20/06/2021 13:28, Philipp Kolmann wrote:
> > I have faced the same issue and with several sources across the
> > internet I was able to fix it for me.
> >
> > 1.) Adding a wwsympa.service
> > 2.) Changing the apache config.
> >
> > Maybe this helps someone facing the issues while updating to bullseye.
> >
> 
> Thanks for this fix. However, it might be worth mentioning that you have to
> enable apache module proxy_fcgi (and it's dependency proxy) for the handler
> to work:
> 
> a2enmod proxy_fcgi # will enable proxy as dependency
> 
> In my setup apache2 otherwise answered all requests to /wws with a 404 with
> no hint, what's missing. Enabling module proxy at least gave:
> 
> AH01144: No protocol handler was valid for the URL /wws (scheme 'unix'). If
> you are using a DSO version of mod_proxy, make sure the proxy submodules are
> included in the configuration using LoadModule.
> 
> Ah, and you have to install package spawn-fcgi obviously.
> 

A few notes after experiencing the same issue, upgrading a stable server
:
- instructions for adding the wwsympa.service are documented in upstream
  docs
  
(https://sympa-community.github.io/manual/install/configure-http-server-spawnfcgi.html),
  should you beunfamiliar with systemd
- the apache config file patch mentioned in
  
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=980561;filename=apache-sympa.diff;msg=10
  gives a hint at to how to change the
  /etc/apache2/conf-available/sympa.conf file. In my case, I preserved
  the /wws path, in "" to align with the previous "ScriptAlias 
/wws"

Hope this helps,

Best regards,

-- 
Olivier BERGER
https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#992336: RM: kdenlive [armel mips64el ppc64el s390x] -- ANAIS; Package requires qtwebengine5-dev, not available on every architecture

[Patrick Matthäi]

Package: ftp.debian.org
Severity: normal

Hi,
with kdenlive >= 21.04 qtwebengine5 is required, which is missing on armel 
mips64el ppc64el s390x.
Could you please remove kdenlive in testing/unstable from these four 
architectures, so it
also could migrate to testing again?

Bug#951374: RFP: gh -- the GitHub CLI

[Antoine Beaupré]

On 2021-08-16 21:27:33, Anthony Fok wrote:

[...]

> So, in summary, it just means the following in debian/control:
>
> Source: github-cli
> ...
> XS-Go-Import-Path: github.com/github/cli
> ...
> Package: github-cli
> ...
> Conflicts: gitsome, gh
> Provides: gh
> Replaces: gh

I do not see why you would Conflicts with `gh` here. It's not an actual
package name, so it doesn't need that. I am not sure that Replaces is
necessary either. Those would be required if we were renaming or
replacing an existing package, which is not quite the case here.

Some would argue that installing gitsome *and* gh *would* be desirable,
however, which might make the Conflicts problematic. If that's the case,
then there is a number of mechanisms that we could use, but I'd actually
cross that bridge when we get there.

a.
-- 
C'est la nuit qu'il est beau de croire à la lumière
- Edmond Rostand

Bug#992337: O: mysqltcl -- interface to the MySQL database for the Tcl language

[Sven Hoexter]

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

I intend to orphan the mysqltcl package.

The package description is:
 The mysqltcl package provides a Tcl interface to the MySQL database system.
 Within Tcl you've a range of Tcl commands and a global Tcl array available
 to access the database server.
 Written in C mysqltcl uses the official MySQL C-API so that almost all
 Tcl commands correspond to MySQL C-API functions.

I tried to give the package a little bit of love but do not use it anymore.
The git repo I used to maintain it in with gbp is still available for a
potential adopter to clone from if he likes to.
The last upstream release happened in 2012, so it's been a while. In general
the upstream author replied to mails and applied patches in the past.

Regards,
Sven

Bug#992338: O: tclcurl -- Tcl bindings to libcurl

[Sven Hoexter]

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

I intend to orphan the tclcurl package.

The package description is:
 This module enables the use of libcurl in Tcl scripts. Please refer to
 the libcurl documentation available in the libcurl4-gnutls-dev package.
 .
 NOTE: the SSL support is provided by GnuTLS.

This package is without an active upstream. Lately there has been some
activity by flightware guys in https://github.com/flightaware/tclcurl-fa/
but the current package is _not_ based on this one. There is also
additional activity in 
https://www.androwish.org/index.html/timeline?chng=jni/TclCurl/*
with occasional fixes.

The git repo I used to maintain this package with gbp is still referenced and 
available.
If a new maintainer would like to continue on this code base it's possible to 
clone it
to host it on salsa or somewhere else.

Regards,
Sven

Bug#694703: Unvanquished is FOSS and beta

[Steven De Herdt]

For those interested in this game (I hope this mailing list is relevant,
I don't mean to spam):

Unvanquished is now fully free, and the project considers it to be in beta.
See:
https://unvanquished.net/now-we-are-free/
https://unvanquished.net/unvanquished-0-52-beta-is-there/

They also provide a Flatpak release.


Kind regards
-Steven

Bug#991059: diffoscope: handling of errors in unsquashfs

[Roland Clobus]

Hello Chris,

On 17/08/2021 14:34, Chris Lamb wrote:
>> The test suite (which uses git directly) fails at the moment:
>> https://jenkins.debian.net/job/reproducible_diffoscope_from_git/1063/consoleFull
> 
> Thanks. I will address this very shortly.

Thanks, ab780bf6ad6bfa0c88767827065d3fdba4fd3b32 made the test pass in
Jenkins.
https://jenkins.debian.net/job/reproducible_diffoscope_from_git/1065/

Meanwhile, my computer worked for 2 hours, and now I can confirm that
the output is generated without issues and is correct.

With kind regards,
Roland Clobus



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992339: pipewire: Pipewire reports problems during system start

[Alex]

Package: pipewire
Version: 0.3.19-4
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Fresh install of Debian 11 Bullseye with a Live ISO and non free 
drivers. After the fresh install the commend "journalctl -xb -p 3" displayed 
the following error messages:
Aug 17 15:18:52 linuxpc pipewire[1001]: Failed to receive portal pid: 
org.freedesktop.DBus.Error.NameHasNoOwner: Could not get PID of name 
'org.freedesktop.portal.Desktop': no such name
Aug 17 15:19:00 linuxpc pipewire[1073]: Failed to receive portal pid: 
org.freedesktop.DBus.Error.NameHasNoOwner: Could not get PID of name 
'org.freedesktop.portal.Desktop': no such name

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I checked that my audio is working - okay
I checked if pipewire is evening installed - no
I read the Arch Wiki article about pipewire to check for some known issues.
I did a research in the internet and found a similar bug report for Mageia 8 - 
however the solution did not apply

   * What was the outcome of this action?
Outcome of the actions: I gathered the information I could. A solution could 
not be identified yet.

   * What outcome did you expect instead?
I am just trying to check the system startup after a fresh install and a 
typically try to resolve all issues identified in order to provide a maximum 
stability.



-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, 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 pipewire depends on:
ii  init-system-helpers  1.60
ii  libpipewire-0.3-modules  0.3.19-4
ii  pipewire-bin 0.3.19-4

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#992340: network.service error after fresh install

[Alex]

Package: network.service
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Fresh install of Debian 11 Live ISO with non-free firmware. Error messages 
occured aftr fresh install - systemctl status network.service displayed error 
message that dhclient had issues during start.
I traced the error back to the unit file of systemd network.service - the 
command "ifup -a --read-environment" lead to the error, because the file 
/etc/network/interface.d/setup had eth0 as general
network interface.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I replace eth0 in the file /etc/network/interface.d/setup with the correct 
network interface identifier "enp7...".

   * What was the outcome of this action?
This particular error message was gone after the changes that I applied.



-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, 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

Bug#992341: bird2: does not properly take over /etc/bird/bird.conf

[Jonathan Wiltshire]

Package: bird2
Severity: important
Version: 2.0.4-1

Hi,

When bird2 supersedes bird it does not properly take over the 
configuration file /etc/bird/bird.conf in ucf. When the bird package is 
purged, it results in the following situation:


# aptitude search '~c'
c   bird - Internet Routing Daemon 



# apt policy bird bird2
bird:
  Installed: (none)
  Candidate: 1.6.8-2.1
  Version table:
 1.6.8-2.1 500
500 http://mirror.bytemark.co.uk/debian bullseye/main amd64 
Packages

 1.6.6-1+deb10u1 -1
100 /var/lib/dpkg/status
bird2:
  Installed: 2.0.7-4.1
  Candidate: 2.0.7-4.1
  Version table:
 *** 2.0.7-4.1 500
500 http://mirror.bytemark.co.uk/debian bullseye/main amd64 
Packages

100 /var/lib/dpkg/status
# apt purge bird
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  bird*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
(Reading database ... 86367 files and directories currently installed.)
Purging configuration files for bird (1.6.6-1+deb10u1) ...
ucfr: Association belongs to bird2, not bird
ucfr: Aborting
dpkg: error processing package bird (--purge):
 installed bird package post-removal script subprocess returned error 
exit status 5

Errors were encountered while processing:
 bird
E: Sub-process /usr/bin/dpkg returned an error code (1)

But the postrm for bird has already removed the configuration file:

# ls /etc/bird/
envvars  local.conf

so now bird2 fails to start and the configuration is lost (yay backups).


--
Jonathan Wiltshire

Red Hat Certified Engineer (#170-281-083)

Tiger Computing Ltd
ISO27001:2017 Certified

Tel: 01600 483 484
Web: http://www.tiger-computing.co.uk

Registered in England. Company number: 3389961
Registered address: Woodlands, Staunton,
 Coleford, GL16 8NU

Bug#992343: ITP: r-cran-ggtext -- improved text rendering support for 'ggplot2'

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-ggtext -- improved text rendering support for 'ggplot2'
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-ggtext
  Version : 0.1.1
  Upstream Author : Claus O. Wilke
* URL : https://cran.r-project.org/package=ggtext
* License : GPL-2
  Programming Lang: GNU R
  Description : improved text rendering support for 'ggplot2'
 A 'ggplot2' extension that enables the rendering of
 complex formatted plot labels (titles, subtitles, facet labels,
 axis labels, etc.). Text boxes with automatic word wrap are also
 supported.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-ggtext

Bug#992342: ITP: chromono -- A circular color puzzle game

[Thomas Perl]

Package: wnpp
Severity: wishlist

chro.mono is a puzzle game originally developed in 2013 for mobile devices. It 
has recently been open sourced. The goal of the game is to touch half-colored 
spheres with full-colored spheres in such a way that all spheres are filled 
with a single color each. Later on in the game, additional limitations and 
variations on the game mechanics keep the gameplay interesting. The game is 
written in C++ and uses SDL2 for platform abstraction (windowing, input, audio 
output), OpenGL for rendering and libvorbis and zlib for decoding game data.

Webpage: https://thp.io/2013/chromono/
Source code: https://thp.io/2013/chromono/chromono-1.1.0.tar.gz
License: GNU General Public License, v2 or later


Thomas

Bug#992300: ca-certificates: ca-certificate update fails because of missing /usr/bin/cert-sync

[Michael Shuler]

Control: notfound -1 20210119
Control: reassign -1 ca-certificates-mono
Control: tags -1 + moreinfo

On 8/16/21 4:58 PM, Alex wrote:

...
Updating Mono key store
/etc/ca-certificates/update.d/mono-keystore: 10: /usr/bin/cert-sync: not found
Done


Reassigning to appropriate package, ca-certificates-mono.

Bug reporter's ca-certificates-mono version is unknown, but it appears 
that #902663 with the same error report was fixed in 
ca-certificates-mono 5.18.0.240+dfsg-2. Please, update bug report with 
the proper "found" version.


Kind regards,
Michael

Bug#908196: linux-image-4.9.0-8-armmp: Please set CONFIG_LEDS_PCA963X=m

[Vincent Blut]

Package: src:linux
Followup-For: Bug #908196

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 moreinfo

Hi Reco,

Sorry it took so long to get back to you.

Is it still worthwhile to enable this option? Looking at device tree
information, the pca963x LED drivers seem to be used only by the
Linksys WRT1200AC (pca9635), other devices generally prefer to use GPIO
connected LEDs or a different expander (PCA9555, etc.)

So if this router does not run on Linux 5.13+, it's probably not worth to enable
this option.

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYRvKjwAKCRAQn1qAt/bg
AdBHAP9fDZdx3++JQg02zknaSgh+Wa/s5q8Ko5NRMKXlZtCgyQD+LZzzeUOTownu
JQFLgTD3dG/gPvf0oJE0WLcxhahSOQ0=
=X1j+
-END PGP SIGNATURE-

Bug#991059: diffoscope: handling of errors in unsquashfs

[Chris Lamb]

tags 991059 + pending
thanks

Hey,

> Thanks, ab780bf6ad6bfa0c88767827065d3fdba4fd3b32 made the test pass in
> Jenkins.
> https://jenkins.debian.net/job/reproducible_diffoscope_from_git/1065/
>
> Meanwhile, my computer worked for 2 hours, and now I can confirm that
> the output is generated without issues and is correct.

Huzzah! I'll release diffoscope with these changes very soon.


Best wishes,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Bug#992344: wireguard-tools ought not depend on linux-image-rt-amd64

[Vincent Batts]

Package: wireguard-tools
Version: 1.0.20210223-1
Severity: normal
X-Debbugs-Cc: vba...@hashbangbash.com

Dear Maintainer,

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

   * What led up to the situation?
   
Building a minimal filesystem to generate wireguard private keys. Say:
```shell
docker run -it --rm debian:bullseye
apt update && apt install -y wireguard-tools
```

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

the list of dependencies brought in for only wireguard-tools included
linux-image-rt-amd64 (5.10.46-4).
(this minimal filesystem does not boot, and should not have a kernel)

   * What outcome did you expect instead?

Just the basic packages needed for /usr/bin/wg

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


-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.43.3-microsoft-standard-WSL2 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages wireguard-tools depends on:
ii  libc6  2.31-13

Versions of packages wireguard-tools recommends:
ii  iptables1.8.7-1
pn  wireguard-modules | wireguard-dkms  

Versions of packages wireguard-tools suggests:
pn  openresolv | resolvconf  

Bug#992328: snmpd init script isn't sourcing /etc/default/snmpd, uses always default parameters

[Marcel Meckel]

Package: snmpd
Version: 5.7.3+dfsg-5+deb10u2

When starting snmpd on a non-systemd machine the init script

  /etc/init.d/snmpd

fails to source the file

  /etc/default/snmpd

which results in SNMPDOPTS specified in the default file
being ignored:

  % grep ^SNMPDOPTS /etc/default/snmpd
  SNMPDOPTS='-Lf /dev/null -u Debian-snmp -g Debian-snmp -I 
-smux,mteTrigger,mteTriggerConf -p /run/snmpd.pid'


  % service snmpd restart
  [ ok ] Restarting SNMP Services: snmpd.

  % ps auxf|grep snmpd
  Debian-+  3480  0.0  0.0  33872  8344 ?S12:28   0:00 
/usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I 
-smux mteTrigger mteTriggerConf -p /run/snmpd.pid


Please note the parameter "-Lsd" to snmpd in the process list
which is not present in SNMPDOPTS in /etc/default/snmpd.

Snippet from the init script:

  DEFAULT_SNMPDOPTS="-Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I 
-smux,mteTrigger,mteTriggerConf"

  [ -z "$SNMPDOPTS" ] && SNMPDOPTS=$DEFAULT_SNMPDOPTS

It checks $SNMPDOPTS which isn't defined because the defaults file 
wasn't sourced.


The init script from snmpd from stretch has these lines:

  # Reads config file (will override defaults above)
  [ -r /etc/default/snmpd ] && . /etc/default/snmpd

After updating snmpd from stretch to buster the default file is being 
ignored.


This affects

  buster (oldstable) snmpd-5.7.3+dfsg-5+deb10u2
  bullseye  (stable) snmpd-5.9+dfsg-3+b1

Bug#912271: newlib: diff for NMU version 3.3.0-1.1

[John Scott]

Control: tags 912271 + pending

Dear maintainer,

I've prepared an NMU for newlib (versioned as 3.3.0-1.1) and
uploaded it to DELAYED/15 via sponsorship. Please feel free
to tell me if I should delay it longer.

Regards.

diff -Nru newlib-3.3.0/debian/changelog newlib-3.3.0/debian/changelog
--- newlib-3.3.0/debian/changelog   2020-02-29 08:35:41.0 -0500
+++ newlib-3.3.0/debian/changelog   2021-06-08 17:17:43.0 -0400
@@ -1,3 +1,11 @@
+newlib (3.3.0-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Add newlib-source binary package to aid building for new targets.
+(Closes: #912271)
+
+ -- John Scott   Tue, 08 Jun 2021 17:17:43 -0400
+
 newlib (3.3.0-1) unstable; urgency=medium
 
   [ Agustin Henze ]
diff -Nru newlib-3.3.0/debian/control newlib-3.3.0/debian/control
--- newlib-3.3.0/debian/control 2020-02-29 08:35:41.0 -0500
+++ newlib-3.3.0/debian/control 2021-02-03 10:05:40.0 -0500
@@ -56,3 +56,14 @@
  .
  This package contains the newlib library compiled for Cortex-A*,
  Cortex-R4/R5/R7 and Cortex-M0/M0+/M3/M4 targets.
+
+Package: newlib-source
+Architecture: all
+Section: libdevel
+Description: C library and math library for embedded systems (source)
+ Newlib is a C library and math library intended for use on embedded systems.
+ It is a conglomeration of several library parts, all under free software
+ licenses that make them easily usable on embedded products.
+ .
+ This package contains the upstream source code suitable for targeting
+ new platforms.
diff -Nru newlib-3.3.0/debian/newlib-source.install 
newlib-3.3.0/debian/newlib-source.install
--- newlib-3.3.0/debian/newlib-source.install   1969-12-31 19:00:00.0 
-0500
+++ newlib-3.3.0/debian/newlib-source.install   2021-02-03 10:02:42.0 
-0500
@@ -0,0 +1 @@
+debian/newlib-*.tar.xz usr/src/newlib/
diff -Nru newlib-3.3.0/debian/rules newlib-3.3.0/debian/rules
--- newlib-3.3.0/debian/rules   2020-02-29 08:35:41.0 -0500
+++ newlib-3.3.0/debian/rules   2021-02-11 19:59:47.0 -0500
@@ -66,11 +66,14 @@
 %:
dh $@ -B$(BUILD_DIR) --with autotools-dev --parallel
 
+debian/newlib-$(DEB_VERSION_UPSTREAM).tar.xz:
+   tar -acf $@ --exclude=debian --exclude-vcs --exclude='*.dh-orig' 
`pwd`/../`basename $(TOP_DIR)`
+
 override_dh_clean:
dh_clean
-   rm -rf $(BUILD_DIR) $(BUILD_NANO_DIR) $(TMP_NANO_DIR)
+   rm -rf $(BUILD_DIR) $(BUILD_NANO_DIR) $(TMP_NANO_DIR) 
debian/newlib-*.tar.xz
 
-override_dh_auto_configure:
+override_dh_auto_configure: debian/newlib-$(DEB_VERSION_UPSTREAM).tar.xz
dh_auto_configure -B$(BUILD_DIR) -- $(CONFIGURE_FLAGS)
dh_auto_configure -B$(BUILD_NANO_DIR) -- $(CONFIGURE_FLAGS_NANO)
 

Bug#992345: www.debian.org: bullseye release-notes are misleading about the needed disk space

[Vincent Lefevre]

Package: www.debian.org
Severity: important

The bullseye release-notes at

  
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html

are misleading about the needed disk space.

"apt -o APT::Get::Trivial-Only=true full-upgrade" was saying

649 upgraded, 113 newly installed, 11 to remove and 1 not upgraded.
Need to get 455 MB of archives.
After this operation, 558 MB of additional disk space will be used.

and I had around 650 MB free space, but the upgrade failed due to
lack of disk space when processing the new Linux kernel
(linux-image-5.10.0-8-amd64_5.10.46-4_amd64.deb). I tried to
complete the upgrade after another "apt clean", but this wasn't
enough (and increasing the disk space couldn't be done without
rebooting).

I suspect that some packages like this one need a lot of temporary
disk space (could this be related to initrd before compression?).
But there is nothing about that in the release notes. And perhaps
a warning should have been output by apt.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#992038: systemd: regression with systemd-networkd + dropbear initramfs and kernel ip autoconfig(?)

[Axel Scheepers]

Hi,

I've been trying to bisect but it's not going well. Maybe you can give
me a hand with this:

axel@nuc:~/src/Git/systemd$ git bisect start
axel@nuc:~/src/Git/systemd$ git bisect bad v248
axel@nuc:~/src/Git/systemd$ git bisect good v249
Bisecting: a merge base must be tested
[938bdfc0fa737d86eb3ecc70506e11e5f740e0dc] Merge pull request #19157
from keszybz/read-medium-sized-virtual-file

I did the bisect for the other commits by reverting bad/good but that
didn't work out and all builds failed. I'd like to try to bisect this
merge commit if that makes sense. If you have a better idea i'm all
ears. The setup will move next month however and then the fritzbox will
be out of the loop. I've also converted the production box to just
dhcpcd. When looking at the logs for that i notice:

Aug 17 16:40:47 amber dhcpcd[7852]: enp1s0: DHCPv6 REPLY: iana not found
Aug 17 16:40:47 amber dhcpcd[7852]: enp1s0: soliciting a DHCPv6 lease
Aug 17 16:40:48 amber dhcpcd[7852]: wlp2s0: DHCPv6 REPLY: iana not found
Aug 17 16:40:48 amber dhcpcd[7852]: wlp2s0: soliciting a DHCPv6 lease

Not sure if that is related. As dhcpcd works fine the issue is not
really relevant for me anymore but i still like to help resolve the
issue as long as time permits.

Kind regards,

Axel Scheepers

Bug#992300: ca-certificates: ca-certificate update fails because of missing /usr/bin/cert-sync

[Michael Shuler]

On 8/17/21 9:40 AM, Alex wrote:


I am not sure if ca-certificates-mono was installed at all. I do not
have mono on the system.


The machine did have the packages below installed at some point.


$ dpkg -l|grep mono|grep -v fonts-|grep -v python3-monotonic
rc  ca-certificates-mono 4.6.2.7+dfsg-1
all  Common CA certificates (Mono keystore)
rc  mono-runtime-common  4.6.2.7+dfsg-1
amd64Mono runtime - common files


The packages were removed (r), leaving behind configuration (c) files.


$ ls /etc/ca-certificates/update.d/mono-keystore /usr/bin/cert-sync
ls: cannot access '/usr/bin/cert-sync': No such file or directory
/etc/ca-certificates/update.d/mono-keystore


Version 4.6.2.7+dfsg-1 is listed on p.d.o as the latest version from 
Stretch, so it could have been quite some time ago and your logs for 
that were likely rotated, so not in the latest dpkg.log file. Purging 
packages would also remove configurations, so if you wish to do a little 
clean up:


  apt purge ca-certificates-mono mono-runtime-common

Seems this bug can likely be closed, the fix version for #902663 is 
later than the reporter's old "rc" remnants.


Kind regards,
Michael

Bug#992346: elpa-org: install script from elpa-org package failed

[Damien Couroussé]

Package: elpa-org
Version: 9.1.14+dfsg-3
Severity: important

The package install fails with the following error message:

ERROR: install script from elpa-org package failed
dpkg: error processing package elpa-org (--configure):
 installed elpa-org package post-installation script subprocess 
returned error exit status 1

Errors were encountered while processing:
 elpa-org
E: Sub-process /usr/bin/dpkg returned an error code (1)


Please find below the complete error log.

best,
Damien




-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable'), (200, 
'testing'), (100, 'unstable'), (10, 'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)

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

Versions of packages elpa-org depends on:
ii  elpa-htmlize    1.54-1
ii  emacsen-common  3.0.4

Versions of packages elpa-org recommends:
ii  emacs  1:27.1+1-3~bpo10+1
ii  emacs-gtk [emacs]  1:27.1+1-3~bpo10+1

Versions of packages elpa-org suggests:
pn  ditaa  
ii  org-mode-doc   9.1.14-1
pn  texinfo    
ii  texlive-fonts-recommended  2018.20190227-2
ii  texlive-latex-extra    2018.20190227-2

-- no debconf information






# env LANG=C apt install elpa-org
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  elpa-htmlize
Suggested packages:
  ditaa texinfo
The following NEW packages will be installed:
  elpa-htmlize elpa-org
0 upgraded, 2 newly installed, 0 to remove and 219 not upgraded.
Need to get 0 B/1 080 kB of archives.
After this operation, 6 117 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Selecting previously unselected package elpa-htmlize.
(Reading database ... 348317 files and directories currently installed.)
Preparing to unpack .../elpa-htmlize_1.54-1_all.deb ...
Unpacking elpa-htmlize (1.54-1) ...
Selecting previously unselected package elpa-org.
Preparing to unpack .../elpa-org_9.1.14+dfsg-3_all.deb ...
Unpacking elpa-org (9.1.14+dfsg-3) ...
Setting up elpa-htmlize (1.54-1) ...
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Install elpa-htmlize for emacs
install/htmlize-1.54: Handling install of emacsen flavor emacs
install/htmlize-1.54: byte-compiling for emacs
Setting up elpa-org (9.1.14+dfsg-3) ...
tsort: -: input contains a loop:
tsort: elpa-htmlize
tsort: emacsen-common
Install elpa-htmlize for emacs
install/htmlize-1.54: Handling install of emacsen flavor emacs
install/htmlize-1.54: byte-compiling for emacs
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Install elpa-org for emacs
install/org-9.1.14: Handling install of emacsen flavor emacs
install/org-9.1.14: byte-compiling for emacs

In org-babel-open-src-block-result:
ob-core.el:1039:25:Warning: `org-bracket-link-regexp' is an obsolete 
variable

    (as of Org 9.3); use `org-link-bracket-re' instead.

In org-babel-sha1-hash:
ob-core.el:1227:8:Warning: function org-babel-sha1-hash used to take 0-2
    arguments, now takes 0-1

In org-babel-params-from-properties:
ob-core.el:1430:8:Warning: function org-babel-params-from-properties used to
    take 0-2 arguments, now takes 0-1

In org-babel-parse-header-arguments:
ob-core.el:1534:8:Warning: function org-babel-parse-header-arguments used to
    take 1-2 arguments, now takes 1

In org-babel-demarcate-block:
ob-core.el:1879:42:Warning: `org-get-indentation' is an obsolete 
function (as

    of Org 9.2); use `current-indentation' instead.

In org-babel-read-element:
ob-core.el:2086:28:Warning: `org-bracket-link-regexp' is an obsolete 
variable

    (as of Org 9.3); use `org-link-bracket-re' instead.

In org-babel-read-link:
ob-core.el:2128:32:Warning: `org-bracket-link-regexp' is an obsolete 
variable

    (as of Org 9.3); use `org-link-bracket-re' instead.

In org-babel-insert-result:
ob-core.el:2276:33:Warning: `org-get-indentation' is an obsolete 
function (as

    of Org 9.2); use `current-indentation' instead.

In org-babel-result-end:
ob-core.el:2473:51:Warning: `org-bracket-link-regexp' is an obsolete 
variable

    (as of Org 9.3); use `org-link-bracket-re' instead.

In org-babel-update-block-body:
ob-core.el:2539:18:Warning: `org-get-indentation' is an obsolete 
function (as

    of Org 9.2); use `current-indentation' instead.

In org-babel-exp-process-buffer:
ob-exp.el:247:36:Warning: `org-get-indentation' is an obsolete function 
(as of

    Org 9.2); use `current-indentation' instead.

In org-babel-execute:haskell:
ob-haskell.el:86:22:Warning: `org-babel-strip-quotes' is an obsolete 

Bug#992348: mapserver: please re-enable build of ruby-mapscript package

[Tomas Pospisek]

Source: mapserver
Version: 7.6.4-1
Severity: wishlist

Hi Debian GIS maintainers, hi Bas!

tldr: would it be possible to re-enable the ruby-mapscript package
build?

Extended explication: requiring a packaged version of ruby-mapscript
on Ubuntu 20.04 I today basically reverted commits [1] and [2] and
ruby-mapscript built just fine. A quick test showed ruby-mapscript
to work. Then I did the same thing on bullseye and again,
ruby-mapscript build fine.

Questions:

* would it be possible to start building the ruby-mapscript package again?

* I see commit [1] that says "Build Ruby MapScript only for default version",
  but it doesn't say why builds for other ruby versions are being dropped.
  What was the reason for dropping the build of ruby-mapscript for the
  various existing Ruby versions?

* half an hour later there's a commit [2] that drops ruby-mapscript
  alltogether. I couldn't find a log of the respective FTBS. But
  maybe it doesn't matter any more since it does seem to build just
  fine now.

So would it be possible to revert [1] and [2]? Or should I fork the
project on Salsa and file a PR?

Either way: *thanks a lot for maintaining mapserver*!!!

Greetings,
*t

[1] 
https://salsa.debian.org/debian-gis-team/mapserver/-/commit/45f6f67e4272122d9d9fa0c49f247d68690c659a
[2] 
https://salsa.debian.org/debian-gis-team/mapserver/-/commit/8d14c0fe55e33ef1922ac529e23cbb04776afd9a


-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Bug#681177: closed by "Steinar H. Gunderson" (Closing mlocate bugs)

[Martin-Éric Racine]

You might wanna consider adding Provides: mlocate

Right now, packages that depend on mlocate refuse to install if
plocate is installed.

ti 17. elok. 2021 klo 18.24 Debian Bug Tracking System
(ow...@bugs.debian.org) kirjoitti:
>
> This is an automatic notification regarding your Bug report
> which was filed against the mlocate package:
>
> #681177: mlocate: cron.daily job killed with error 137
>
> It has been closed by "Steinar H. Gunderson" .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact "Steinar H. Gunderson" 
>  by
> replying to this email.
>
>
> --
> 681177: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681177
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: "Steinar H. Gunderson" 
> To: 593431-d...@bugs.debian.org, 681177-d...@bugs.debian.org, 
> 746943-d...@bugs.debian.org, 926290-d...@bugs.debian.org, 
> 972980-d...@bugs.debian.org, 664206-d...@bugs.debian.org, 
> 784428-d...@bugs.debian.org, 925169-d...@bugs.debian.org, 
> 524134-d...@bugs.debian.org, 989574-d...@bugs.debian.org, 
> 472059-d...@bugs.debian.org, 969522-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 17 Aug 2021 17:05:16 +0200
> Subject: Closing mlocate bugs
> Hi,
>
> As of bookworm, mlocate no longer exists in Debian and is replaced by plocate.
> There's still an “mlocate” package, but it is only a transitional package
> to install plocate (and convert over the old database).
>
> Thus, I'm closing a series of bugs related to mlocate that I believe are
> either:
>
>  1. Already fixed in plocate, or
>  2. Related to implementation bugs in mlocate that are highly unlikely
> to reappear in plocate (which only shares configuration parsing code,
> no other internals).
>
> If you believe this is in error and the bug is relevant for plocate,
> please reopen it with a message as of why that is the case (and reassign it
> to plocate). Thanks!
>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
>
>
> -- Forwarded message --
> From: "Martin-Éric Racine" 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Wed, 11 Jul 2012 09:18:31 +0300
> Subject: mlocate: cron.daily job killed with error 137
> Package: mlocate
> Version: 0.23.1-1
> Severity: normal
>
> As mailed to me by cron:
>
> /etc/cron.daily/mlocate: line 36:29683 Killed $IONICE 
> /usr/bin/updatedb.mlocate
> run-parts: /etc/cron.daily/mlocate exited with return code 137
>
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers testing
>   APT policy: (1001, 'testing')
> Architecture: i386 (i586)
>
> Kernel: Linux 3.2.0-3-486
> Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages mlocate depends on:
> ii  adduser  3.113+nmu3
> ii  libc62.13-33
>
> mlocate recommends no packages.
>
> mlocate suggests no packages.
>
> -- no debconf information
>
>

Bug#681177: closed by "Steinar H. Gunderson" (Closing mlocate bugs)

[Martin-Éric Racine]

For instance, cruft-ng.

ti 17. elok. 2021 klo 18.46 Steinar H. Gunderson (se...@debian.org) kirjoitti:
>
> On Tue, Aug 17, 2021 at 06:34:54PM +0300, Martin-Éric Racine wrote:
> > You might wanna consider adding Provides: mlocate
> >
> > Right now, packages that depend on mlocate refuse to install if
> > plocate is installed.
>
> Hm, can you give an example of such a package? There's still a dummy
> transition package mlocate that depends on plocate, and I thought that would
> be enough.
>
> /* Steinar */
> --
> Homepage: https://www.sesse.net/

Bug#530924: mlocate: Please add support for searching for files owned by a user

[Steinar H. Gunderson]

On Thu, May 28, 2009 at 08:42:16PM +0100, Dominic Hargreaves wrote:
> It would be really nice to have support for searching for files owned by
> a given user/group. Presumably the information is already in the database,
> for authorization reasons.

Hi,

As of bookworm, mlocate is removed from the archive in favor of plocate.
Is this bug still relevant for you? (If not, I will close it, along with the
other bugs inherited from plocate.)

Do note that the information is _not_ already in the database, neither for
mlocate nor plocate; authorization is done by checking every directory up
from the root, ie., effectively asking the kernel. (Notably, the file itself
isn't checked, since one doesn't need access to it to scan it.) Anything else
would be very difficult wrt. complicated ACLs, networked filesystems or
simply access rights that have been changed since the database was created.
Thus, if someone made such an option for plocate, it would be no more
efficient than piping the list of results through a shell script to check the
owner (and with ACLs, is the owner always what you want?).

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

Bug#992349: libclang-common-11-dev: Cannot install amd64 and armhf together

[Anton]

Package: libclang-common-11-dev
Version: 1:11.0.1-2~bpo10+1
Severity: minor

Dear Maintainer,

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

   * What led up to the situation?
Try to install both packages.
apt install clang-11/buster-backports   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Manually extract files from armhf pacakge and copy it
   * What was the outcome of this action?
I cannot install amd64 and armhf version together. It's a problem for 
cross-compilation with clang because you cannot link against compiler-rt.
 For example I have issue with m4 (libm4), m4 can be compiled with gcc 
and linked against libgcc, also it can be compiled with clang and linked 
against compiler-rt, but it cannot be compiled with clang and linked against 
libgcc. It leads to:
/usr/bin/arm-linux-gnueabihf-ld: symtab.o: in function `symtab_init':
symtab.c:(.text+0x34): undefined reference to `__mulodi4'
/usr/bin/arm-linux-gnueabihf-ld: ../lib/libm4.a(clean-temp.o): in function 
`create_temp_dir':
clean-temp.c:(.text+0x9c): undefined reference to `__mulodi4'
/usr/bin/arm-linux-gnueabihf-ld: ../lib/libm4.a(fatal-signal.o): in function 
`at_fatal_signal':
fatal-signal.c:(.text+0x190): undefined reference to `__mulodi4'
/usr/bin/arm-linux-gnueabihf-ld: ../lib/libm4.a(xmalloc.o): in function 
`xnmalloc':
xmalloc.c:(.text+0x30): undefined reference to `__mulodi4'
/usr/bin/arm-linux-gnueabihf-ld: ../lib/libm4.a(xmalloc.o): in function 
`xnrealloc':
xmalloc.c:(.text+0xe4): undefined reference to `__mulodi4'
/usr/bin/arm-linux-gnueabihf-ld: 
../lib/libm4.a(xmalloc.o):xmalloc.c:(.text+0x334): more undefined references to 
`__mulodi4' follow
Briefly speaking it leads to missing 
/usr/lib/llvm-11/lib/clang/11.0.1/lib/linux/libclang_rt.builtins-armhf.a
 
   * What outcome did you expect instead?
I didn't expect conflict between multiarch packages.


-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

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

Versions of packages libclang-common-11-dev depends on:
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libllvm11   1:11.0.1-2~bpo10+1
ii  libstdc++6  8.3.0-6

libclang-common-11-dev recommends no packages.

libclang-common-11-dev suggests no packages.

-- no debconf information

Bug#984368: tpm2-pkcs11: ftbfs with GCC-11

[Simon Chopin]

This appears fixed upstream, see
https://github.com/tpm2-software/tpm2-pkcs11/pull/677

Bug#992345: www.debian.org: bullseye release-notes are misleading about the needed disk space

[Cyril Brulebois]

Hi Vincent,

Vincent Lefevre  (2021-08-17):
> 649 upgraded, 113 newly installed, 11 to remove and 1 not upgraded.
> Need to get 455 MB of archives.
> After this operation, 558 MB of additional disk space will be used.
> 
> and I had around 650 MB free space

455+558 >> 650 so it was very unlikely to work?

But yeah, even if the release notes mention “After the download […]”
things, it could probably point out that you should look at both
numbers, instead of just using xx.x and AAA placeholders.

> I suspect that some packages like this one need a lot of temporary
> disk space (could this be related to initrd before compression?).
> But there is nothing about that in the release notes. And perhaps
> a warning should have been output by apt.

There's one for the directory where debs are downloaded (which you
didn't get since 455 << 650), but I suspect it's harder to estimate
where the whole “additional disk space” is going to end up, depending on
file system layout, etc.?


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


signature.asc
Description: PGP signature

Bug#992350: ifupdown-extra: Hardcoded "wlan0" in /etc/network/if-up.d/10check-duplicate-ip6

[Matti Kurkela]

Package: ifupdown-extra
Version: 0.32
Severity: normal
Tags: ipv6 patch

Dear Maintainer,

When adding package "ifup-extra" on a fresh installation of Debian 11, 
I started getting error messages referring to "wlan0" at ifup time.
This was unexpected as this system had no interface named "wlan0"
at the time.

An easy grep revealed that /etc/network/if-up.d/10check-duplicate-ip6
had a hard-coded reference to network interface "wlan0" where a 
variable was supposed to be used.

Here's a patch to fix it:

--- 10check-duplicate-ip6.old   2021-08-17 18:22:03.02908 +0300
+++ 10check-duplicate-ip6   2021-08-17 18:22:53.037696969 +0300
@@ -70,7 +70,7 @@ do_ndisc() {
 
 # First determine physical interface in case aliased interfaces are used
 real_iface=$(echo "$IFACE" | sed -e 's|:[[:digit:]]\+||')
-link_address=$(ip link show wlan0 | grep link | awk '{print 
toupper($2)}')
+link_address=$(ip link show "$real_iface" | grep link | awk '{print 
toupper($2)}')
 
 if [ -z "`ip link show $real_iface up`" ]; then
 return

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-8-686 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.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 ifupdown-extra depends on:
ii  bind9-host [host]1:9.16.15-1
ii  curl 7.74.0-1.3+b1
ii  dpkg 1.20.9
ii  iproute2 5.10.0-4
ii  iputils-arping   3:20210202-1
ii  iputils-ping [ping]  3:20210202-1
ii  lsb-base 11.1.0
ii  net-tools1.60+git20181103.0eebece-1
ii  netcat-openbsd   1.217-3

Versions of packages ifupdown-extra recommends:
ii  ethtool  1:5.9-1
ii  ndisc6   1.0.4-2

ifupdown-extra suggests no packages.

-- Configuration Files:
/etc/network/if-up.d/10check-duplicate-ip6 changed:
DEFAULT=/etc/default/network-test
[ -r "$DEFAULT" ] && . $DEFAULT
[ "$DO_ARPING" = "no" ]  && exit 0
NDISC=/usr/bin/ndisc6
[ ! -x "$NDISC" ] && exit 0 # Silent exit if ndisc is not installed
DO_SYSLOG=${DO_SYSLOG:-yes}
VERBOSITY=${VERBOSITY:-0}
LC_ALL=C
export LC_ALL
if [ "$DO_SYSLOG" = "yes" ] ; then
OUTPUT="logger -i -p daemon.err -s"
else
OUTPUT="echo"
fi
do_ndisc() {
real_iface=$(echo "$IFACE" | sed -e 's|:[[:digit:]]\+||')
link_address=$(ip link show $real_iface | grep link | awk '{print 
toupper($2)}')
if [ -z "`ip link show $real_iface up`" ]; then
return
fi
for ADDR in $IF_ADDRESS; do
# Only check IP address if it is IPv6
if echo ${ADDR} | grep -q ":" ; then
[ "$VERBOSITY" -eq 1 ] && $OUTPUT "DEBUG: Sending arp pings 
through $real_iface (for $IFACE) to detect other systems using $ADDR"
dup_link_address=$($NDISC -q $ADDR $real_iface)
if [ $? -eq 0 ] ; then
# If the link address is the same as our address this is 
not a problem
# (ndisc returns it in at least Wireless interfaces), only 
report if the link 
# address does not match
if [ "$link_address" != "$dup_link_address" ] ; then
$OUTPUT "ERROR: Duplicate address $ADDR assigned in the 
network where $real_iface is connected to."
fi
fi
fi
done
}
find_ip6() {
   export IF_ADDRESS
   IF_ADDRESS=$(ip addr show "$IFACE" 2>/dev/null | sed -rne 
's|^[[:blank:]]*inet6[[:blank:]]+([^/]+)/.*|\1|p')
   return 0
}
if [ -z "$IFACE" ] ; then
echo "ERROR: Do not know what interface to check. IFACE environment 
variable is not defined!" >&2
exit 1
fi
case $IFACE in
sl* | ww* | lo*) exit 0 ;;
*) ;;
esac
[ -z "$IF_ADDRESS" ] && find_ip6
[ -z "$IF_ADDRESS" ] && exit 0
do_ndisc 
exit 0


-- no debconf information

Bug#681177: closed by "Steinar H. Gunderson" (Closing mlocate bugs)

[Steinar H. Gunderson]

On Tue, Aug 17, 2021 at 06:52:23PM +0300, Martin-Éric Racine wrote:
> For instance, cruft-ng.

cruft-ng installs just fine here (by pulling in the mlocate dummy package).
It isn't actually useful due to #976367, though (it expects to be able to
read mlocate's private data format).

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

Bug#992351: molly-guard dracut issue

[Anton Lundin]

Package: molly-guard
Version: 0.7.2

Hi.

When using molly-guard together with dracut machine fails to
poweroff/halt/reboot with a issue like:


[   67.897697] dracut Warning: Killing all remaining processes
dracut Warning: Killing all remaining processes
[   67.975525] dracut Warning: Unmounted /oldroot.
[   68.002391] dracut: Disassembling device-mapper devices
E: not a regular file: /lib/molly-guard/poweroff[   68.036575] dracut Warning: 
poweroff failed!

dracut Warning: poweroff failed!


[   68.039669] dracut Warning: 
dracut Warning: 


Generating "/run/initramfs/rdsosreport.txt"
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.

To get more debug information in the report,
reboot with "rd.debug" added to the kernel command line.

Dropping to debug shell.

shutdown:/# 


This is because the /lib/molly-guard/poweroff symlink isn't available in
the dracut initramfs.


This can be worked around by adding this:
install_items+=" /lib/molly-guard/poweroff /lib/molly-guard/reboot 
/lib/molly-guard/halt /lib/molly-guard/shutdown "

to

/etc/dracut.conf.d/20-molly-guard.conf


And rebuilding the initramfs.


//Anton

Bug#681177: closed by "Steinar H. Gunderson" (Closing mlocate bugs)

[Steinar H. Gunderson]

On Tue, Aug 17, 2021 at 06:34:54PM +0300, Martin-Éric Racine wrote:
> You might wanna consider adding Provides: mlocate
> 
> Right now, packages that depend on mlocate refuse to install if
> plocate is installed.

Hm, can you give an example of such a package? There's still a dummy
transition package mlocate that depends on plocate, and I thought that would
be enough.

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

Bug#992353: ITP: r-cran-spatstat.core -- core functionality of the 'spatstat' family of GNU R packages

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-spatstat.core -- core functionality of the 'spatstat' 
family of GNU R packages
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-spatstat.core
  Version : 2.3
  Upstream Author : Adrian Baddeley,
* URL : https://cran.r-project.org/package=spatstat.core
* License : GPL-2+
  Programming Lang: GNU R
  Description : core functionality of the 'spatstat' family of GNU R 
packages
 Functionality for data analysis and modelling of spatial data, mainly
 spatial point patterns, in the 'spatstat' family of packages. (Excludes
 analysis of spatial data on a linear network, which is covered by the
 separate package 'spatstat.linnet'.) Exploratory methods include quadrat
 counts, K-functions and their simulation envelopes, nearest neighbour
 distance and empty space statistics, Fry plots, pair correlation
 function, kernel smoothed intensity, relative risk estimation with cross-
 validated bandwidth selection, mark correlation functions, segregation
 indices, mark dependence diagnostics, and kernel estimates of covariate
 effects. Formal hypothesis tests of random pattern (chi-squared, Kolmogorov-
 Smirnov, Monte Carlo, Diggle-Cressie-Loosmore-Ford, Dao-Genton, two-
 stage Monte Carlo) and tests for covariate effects (Cox-Berman-Waller-
 Lawson, Kolmogorov-Smirnov, ANOVA) are also supported. Parametric models
 can be fitted to point pattern data using the functions ppm(), kppm(),
 slrm(), dppm() similar to glm(). Types of models include Poisson, Gibbs
 and Cox point processes, Neyman-Scott cluster processes, and
 determinantal point processes. Models may involve dependence on
 covariates, inter-point interaction, cluster formation and dependence on
 marks. Models are fitted by maximum likelihood, logistic regression,
 minimum contrast, and composite likelihood methods. A model can be
 fitted to a list of point patterns (replicated point pattern data) using
 the function mppm(). The model can include random effects and fixed
 effects depending on the experimental design, in addition to all the
 features listed above. Fitted point process models can be simulated,
 automatically. Formal hypothesis tests of a fitted model are supported
 (likelihood ratio test, analysis of deviance, Monte Carlo tests) along
 with basic tools for model selection (stepwise(), AIC()) and variable
 selection (sdr). Tools for validating the fitted model include
 simulation envelopes, residuals, residual plots and Q-Q plots, leverage
 and influence diagnostics, partial residuals, and added variable plots.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-spatstat.core

Bug#197427: We are fine here

[Maxwell Watford]

I was expecting to hear from you or call me, did you get my first mail.
Thanks
Maxwell Watford.

Bug#973312: gedit: Add gir1.2-tepl-5 package dependency

[Jeffery To]

Since upstream has removed the dependency on tepl[1] and this has been
backported to the Debian package[2], I think this issue can be closed.

[1]: 
https://gitlab.gnome.org/GNOME/gedit/-/commit/fa587e033c97fac65dacdb3c9520635beca68fbc
[2]: 
https://salsa.debian.org/gnome-team/gedit/-/commit/f70d7c12f4df479c580a1110ab86081623e5b119

Bug#964785: I'd like to create a shutter package and add it to the Debian package.

[Michael Kogan]

logix2 has taken over the maintenance for the official Ubuntu PPA at
https://launchpad.net/~shutter/+archive/ubuntu/ppa/+packages?field.name_filter=&field.status_filter=published&field.series_filter=hirsute
recently.

I assume that the package names are valid for Debian as well, so the
package most probably could be reused for Debian with only minor
modifications. Here's a direct link to the actual Shutter package:
https://launchpad.net/~shutter/+archive/ubuntu/ppa/+sourcefiles/shutter/0.98-1~1ppa1~hirsute0/shutter_0.98-1~1ppa1~hirsute0.debian.tar.xz

Am Di., 17. Aug. 2021 um 13:30 Uhr schrieb jiho lee :

> Hi Andrej Shadura
>
> There is one package that I couldn't put in the control file. This package
> is a https://metacpan.org/dist/GooCanvas2-CairoTypes package. This
> package is essential for shutter use and is not currently packaged in the
> debian.
>
> 
> 
> There is a future society, but my future is not what others do.
> Dept. of Information Science, Graduate School, Korea National Open
> University
>
>
> 2021년 8월 17일 (화) 오후 8:27, Andrej Shadura 님이 작성:
>
>> Hi Michael,
>>
>> On Tue, 17 Aug 2021, at 12:22, Michael Kogan wrote:
>>
>> Thanks for your work on the Shutter package! I'm member of the Shutter
>> team (upstream), if there are any doubts or issues, please let me know here
>> or post a question at
>> https://github.com/shutter-project/shutter/issues/new/choose
>>
>>
>> It would be great if you could verify the list of dependencies in Jiho’s
>> package (the control file).
>>
>> Here’s the word diff compared to the dependencies of the old 0.94 version:
>>
>> Depends:
>> [-imagemagick,-]
>> [- libfile-basedir-perl,-]{+gir1.2-appindicator3-0.1,+}
>> {+ libcarp-always-perl,+}
>> {+ libextutils-depends-perl,+}
>> libfile-copy-recursive-perl,
>> [-libfile-which-perl,-]
>> [- libglib-perl,-]
>> [- libgnome2-canvas-perl,-]
>> [- libgnome2-gconf-perl,-]
>> [- libgnome2-perl,-]
>> [- libgnome2-vfs-perl,-]
>> [- libgnome2-wnck-perl,-]
>> [- libgtk2-imageview-perl,-]
>> [- libgtk2-perl,-]
>> [- libgtk2-unique-perl,-]{+libgoocanvas2-perl,+}
>> {+ libgtk3-perl,+}
>> libimage-magick-perl,
>> [-libjson-perl,-]
>> [- libjson-xs-perl,-]
>> [- liblocale-gettext-perl,-]{+libjson-maybexs-perl,+}
>> libnet-dbus-perl,
>> [-libnet-dropbox-api-perl,-]{+libnet-oauth-perl,+}
>> {+ libnet-oauth2-perl,+}
>> {+ libnumber-bytes-human-perl,+}
>> {+ libpango-perl,+}
>> libpath-class-perl,
>> [- libproc-processtable-perl,-]
>> libproc-simple-perl,
>> [- librsvg2-common,-]
>> [- libsort-naturally-perl,-]
>> libwww-mechanize-perl,
>> [- libwww-perl,-]
>> [- libx11-protocol-other-perl,-]
>> [- libx11-protocol-perl,-]
>> [- libxml-simple-perl,-]
>> [- procps,-]
>> [- xdg-utils,-]
>> ${misc:Depends},
>> ${shlibs:Depends},
>> [-Recommends:-]
>> [- libgoo-canvas-perl,-]
>> [- libgtk2-appindicator-perl,-]
>> [- libnet-oauth-perl,-]
>> Suggests:
>> [-gnome-web-photo,-]{+libimage-exif-perl,+}
>> libimage-exiftool-perl,
>> [- libnet-dbus-glib-perl,-]
>> nautilus-sendto,
>>
>> --
>> Cheers,
>>   Andrej
>>
>>

Bug#992354: lesspipe: Look for user-defined filter in $XDG_CONFIG_HOME

[Jeffery To]

Package: less
Version: 551-2
Severity: wishlist

Currently, lesspipe looks for a user-defined filter in the user's home
directory only (~/.lessfilter).

This change allows the user-defined filter to be placed at
$XDG_CONFIG_HOME/lessfilter (or ~/.config/lessfilter if
$XDG_CONFIG_HOME is empty or not defined), falling back to
~/.lessfilter if the filter is not found.
commit ff12f0e26ae7b35d7c04e9fec47718aa289a98b0
Author: Jeffery To 
Date:   Wed Aug 18 01:13:30 2021 +0800

lesspipe: Look for user-defined filter in $XDG_CONFIG_HOME

Currently, lesspipe looks for a user-defined filter in the user's home
directory only (~/.lessfilter).

This change allows the user-defined filter to be placed at
$XDG_CONFIG_HOME/lessfilter (or ~/.config/lessfilter if $XDG_CONFIG_HOME
is empty or not defined), falling back to ~/.lessfilter if the filter is
not found.

diff --git a/debian/lesspipe b/debian/lesspipe
index 98224b0..14b33f6 100644
--- a/debian/lesspipe
+++ b/debian/lesspipe
@@ -25,6 +25,7 @@
 #$2  filename that was created during LESSOPEN
 
 TMPDIR=${TMPDIR:-/tmp}
+CONFIGDIR=${XDG_CONFIG_HOME:-~/.config}
 BASENAME=`basename $0`
 LESSFILE=lessfile
 
@@ -60,9 +61,13 @@ if [ $# -eq 1 ] ; then
 		if [ $BASENAME = $LESSFILE ]; then exec > $TMPFILE; fi
 
 		# Allow for user defined filters
-		#if [ -x ~/.lessfilter -a -O ~/.lessfilter ]; then
-		if [ -x ~/.lessfilter ]; then
-			~/.lessfilter "$1"
+		if [ -x "$CONFIGDIR/lessfilter" ]; then
+			USERFILTER="$CONFIGDIR/lessfilter"
+		elif [ -x ~/.lessfilter ]; then
+			USERFILTER=~/.lessfilter
+		fi
+		if [ -n "$USERFILTER" ]; then
+			"$USERFILTER" "$1"
 			if [ $? -eq 0 ]; then
 if [ $BASENAME = $LESSFILE ]; then
 	if [ -s $TMPFILE ]; then

Bug#992347: open-iscsi on upgrades fail to finish postinst script

[Ritesh Raj Sarraf]

Hello Jose,

Good to hear from you. I recollect having met you, in person, at
Debconf Heidelberg or Debconf Capetown. I hope you are doing good. :-)

On Tue, 2021-08-17 at 16:27 +0100, Jose M Calhariz wrote:
> During upgrades of open-iscsi on my environment it fails to run
> postinst with success.  I got the following messages:
> 
> Setting up open-iscsi (2.1.3-5) ...
> open-iscsi postinst: since the check in preinst some iSCSI sessions
> have
>  failed. -> will wait 30s for automatic recovery
> open-iscsi postinst: some sessions are still in failed state ->
> iscsid
>  will be restarted regardless, since that may
>  actually help with the session recovery.
> dpkg: error processing package open-iscsi (--configure):
>  installed open-iscsi package post-installation script subprocess
> returned error exit status 1
> 
> 
> I have tried to change the postinst to wait for more time, for
> example
> 120s and it worked, after 40 seconds of wait.

Hmmm. Usually, the sessions should recover within a couple of seconds.
IIRC, the check is every 5 seconds.


Did you change/tweak any of the default timeout values ?


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#989087: rtw_8822ce and rtw_8821ce: firmware crash

[Clément CACHINHO]

Package: firmware-realtek
Version: 20210315-3
Followup-For: Bug #989087
X-Debbugs-Cc: clement.cachi...@gmail.com

Dear Maintainer,

Google translate: There is probably the same problem as for the rtw_8821ce. The
driver works several minutes before crashing for no apparent reason (no
relation to a strong use of the connection or a temporal regularity.) The
firmware problem has been present since version 5.x of the kernel (I have
noticed it on all testing version of bulleyes).
The only way to fix the problem is to restart the computer.

Original: Il y a probablement le même problème que pour le rtw_8821ce. Le
driver fonctionne plusieurs minutes avant de crash sans raison apparentes
(aucun rapport avec une forte utilisation de la connexion ou une régularité
temporelle.) Le problème du firmware est présent depuis les versions 5.x du
kernel (je l'ai constaté sur toutes les versions testing de bulleyes).
Le seul moyen de résoudre le problème est de redémarrer l'ordinateur.


Attached are the full crash logs.
Thanks in advance if you find a solution.
Cordially.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.140
Aug 17 18:57:19 LenovoDebian kernel: [  598.927259] rtw_8821ce :07:00.0: 
timed out to flush queue 2
Aug 17 18:57:19 LenovoDebian kernel: [  599.075248] rtw_8821ce :07:00.0: 
timed out to flush queue 2
Aug 17 18:57:52 LenovoDebian kernel: [  631.555980] rtw_8821ce :07:00.0: 
timed out to flush queue 1
Aug 17 18:57:52 LenovoDebian kernel: [  631.699972] rtw_8821ce :07:00.0: 
timed out to flush queue 2
Aug 17 18:57:52 LenovoDebian kernel: [  631.843936] rtw_8821ce :07:00.0: 
timed out to flush queue 1
Aug 17 18:57:52 LenovoDebian kernel: [  631.38] rtw_8821ce :07:00.0: 
timed out to flush queue 2
Aug 17 18:57:54 LenovoDebian kernel: [  634.283743] rtw_8821ce :07:00.0: 
timed out to flush queue 1
Aug 17 18:57:54 LenovoDebian kernel: [  634.427662] rtw_8821ce :07:00.0: 
timed out to flush queue 2
Aug 17 18:57:55 LenovoDebian kernel: [  634.575654] rtw_8821ce :07:00.0: 
timed out to flush queue 1
Aug 17 18:57:55 LenovoDebian kernel: [  634.715656] rtw_8821ce :07:00.0: 
timed out to flush queue 2
Aug 17 18:58:38 LenovoDebian wpa_supplicant[906]: wlp7s0: CTRL-EVENT-BEACON-LOSS
Aug 17 18:58:38 LenovoDebian kernel: [  677.827347] [ cut here 
]
Aug 17 18:58:38 LenovoDebian kernel: [  677.827350] failed to read DBI 
register, addr=0x0719
Aug 17 18:58:38 LenovoDebian kernel: [  677.827399] WARNING: CPU: 3 PID: 5035 
at drivers/net/wireless/realtek/rtw88/pci.c:1173 
rtw_dbi_read8.constprop.0+0xa0/0xb0 [rtw88_pci]
Aug 17 18:58:38 LenovoDebian kernel: [  677.827400] Modules linked in: rfcomm 
md4 sha512_ssse3 sha512_generic nls_utf8 cifs dns_resolver fscache libdes 
xt_CHECKSUM nft_chain_nat xt_MASQ>
Aug 17 18:58:38 LenovoDebian kernel: [  677.827460]  
soundwire_generic_allocation intel_rapl_msr rtw88_pci irqbypass bluetooth 
snd_soc_core squashfs rtw88_core snd_compress soundwire_ca>
Aug 17 18:58:38 LenovoDebian kernel: [  677.827528]  ip_tables x_tables autofs4 
ext4 crc16 mbcache jbd2 crc32c_generic btrfs xor raid6_pq libcrc32c hid_generic 
usbhid sd_mod i915 crc32_>
Aug 17 18:58:38 LenovoDebian kernel: [  677.827577] CPU: 3 PID: 5035 Comm: 
kworker/u16:3 Tainted: PW  OE 5.10.0-8-amd64 #1 Debian 5.10.46-4
Aug 17 18:58:38 LenovoDebian kernel: [  677.827579] Hardware name: LENOVO 
INVALID/INVALID, BIOS BGCN34WW 05/21/2021
Aug 17 18:58:38 LenovoDebian kernel: [  677.827624] Workqueue: phy0 
ieee80211_beacon_connection_loss_work [mac80211]
Aug 17 18:58:38 LenovoDebian kernel: [  677.827630] RIP: 
0010:rtw_dbi_read8.constprop.0+0xa0/0xb0 [rtw88_pci]
Aug 17 18:58:38 LenovoDebian kernel: [  677.827633] Code: be ed 03 00 00 48 8b 
40 50 e8 3c c2 ef de 5b 5d 41 88 04 24 31 c0 41 5c c3 be 19 07 00 00 48 c7 c7 
c0 83 f0 c2 e8 e3 45 b7 de <>
Aug 17 18:58:38 LenovoDebian kernel: [  677.827635] RSP: 0018:bd87c5fafd68 
EFLAGS: 00010286
Aug 17 18:58:38 LenovoDebian kernel: [  677.827637] RAX:  RBX: 
 RCX: 9aece64d8a08
Aug 17 18:58:38 LenovoDebian kernel: [  677.827639] RDX: ffd8 RSI: 
0027 RDI: 9aece64d8a00
Aug 17 18:58:38 LenovoDebian kernel: [  677.827640] RBP: 9aeba0371f00 R08: 
 R09: bd87c5fafb88
Aug 17 18:58:38 LenovoDebian kernel: [  677.82

Bug#992355: ITP: r-cran-spatstat.linnet -- linear networks functionality of the 'spatstat' family of GNU R

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-spatstat.linnet -- linear networks functionality of the 
'spatstat' family of GNU R
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-spatstat.linnet
  Version : 2.3
  Upstream Author : Adrian Baddeley,
* URL : https://cran.r-project.org/package=spatstat.linnet
* License : GPL-2+
  Programming Lang: GNU R
  Description : linear networks functionality of the 'spatstat' family of 
GNU R
 Defines types of spatial data on a linear network and provides
 functionality for geometrical operations, data analysis and modelling
 of data on a linear network, in the 'spatstat' family of packages.
 Contains definitions and support for linear networks, including
 creation of networks, geometrical measurements, topological
 connectivity, geometrical operations such as inserting and deleting
 vertices, intersecting a network with another object, and interactive
 editing of networks. Data types defined on a network include point
 patterns, pixel images, functions, and tessellations. Exploratory
 methods include kernel estimation of intensity on a network, K-
 functions and pair correlation functions on a network, simulation
 envelopes, nearest neighbour distance and empty space distance,
 relative risk estimation with cross-validated bandwidth selection.
 Formal hypothesis tests of random pattern (chi-squared, Kolmogorov-
 Smirnov, Monte Carlo, Diggle-Cressie-Loosmore-Ford, Dao-Genton, two-
 stage Monte Carlo) and tests for covariate effects (Cox-Berman-Waller-
 Lawson, Kolmogorov-Smirnov, ANOVA) are also supported. Parametric
 models can be fitted to point pattern data using the function lppm()
 similar to glm(). Only Poisson models are implemented so far. Models
 may involve dependence on covariates and dependence on marks. Models
 are fitted by maximum likelihood. Fitted point process models can be
 simulated, automatically. Formal hypothesis tests of a fitted model are
 supported (likelihood ratio test, analysis of deviance, Monte Carlo
 tests) along with basic tools for model selection (stepwise(), AIC())
 and variable selection (sdr). Tools for validating the fitted model
 include simulation envelopes, residuals, residual plots and Q-Q plots,
 leverage and influence diagnostics, partial residuals, and added
 variable plots. Random point patterns on a network can be generated
 using a variety of models.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-spatstat.linnet

Bug#992356: kde-config-gtk-style-preview: GTK style preview doesn't work

[Alex Volkov]

Package: kde-config-gtk-style-preview
Version: 4:5.20.5-2
Severity: important

Dear Maintainer,

the said package shows empty panel in systemsettings and gives

./gtk3_preview

(gtk3_preview:2216): dbind-WARNING **: 22:43:19.869: AT-SPI: Error retrieving 
accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.a11y.Bus was not provided by any .service files

** (gtk3_preview:2216): WARNING **: 22:43:19.869: Failed to open file “/usr/
share/kcm-gtk-module//preview.ui”: No such file or directory
free(): invalid pointer
Aborted

at the attempt to start by command line.


-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (991, 'stable'), (500, 'stable-security'), (500, 'oldstable'), 
(99, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.194-bootes0-p-1000 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages kde-config-gtk-style-preview depends on:
ii  libc6 2.31-13
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4

Versions of packages kde-config-gtk-style-preview recommends:
ii  kde-config-gtk-style  4:5.20.5-2

kde-config-gtk-style-preview suggests no packages.

-- no debconf information

Bug#992357: kde-config-gtk-style-preview: GTK style preview doesn't work

[Alex Volkov]

Package: kde-config-gtk-style-preview
Version: 4:5.20.5-2
Severity: important

Dear Maintainer,

the said package shows empty panel in systemsettings and gives

./gtk3_preview

(gtk3_preview:2216): dbind-WARNING **: 22:43:19.869: AT-SPI: Error retrieving 
accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.a11y.Bus was not provided by any .service files

** (gtk3_preview:2216): WARNING **: 22:43:19.869: Failed to open file 
“/usr/share/kcm-gtk-module//preview.ui”: No such file or directory
free(): invalid pointer
Aborted

at the attempt to start by command line.


-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (991, 'stable'), (500, 'stable-security'), (500, 'oldstable'), 
(99, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.194-bootes0-p-1000 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages kde-config-gtk-style-preview depends on:
ii  libc6 2.31-13
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4

Versions of packages kde-config-gtk-style-preview recommends:
ii  kde-config-gtk-style  4:5.20.5-2

kde-config-gtk-style-preview suggests no packages.

-- no debconf information

Bug#906474: ircp-tray: FTBFS in buster/sid (linux/irda.h: No such file or directory)

[Daniele Napolitano]

I'm the developer of ircp-tray. Sadly the IrDA support has been
removed from the kernel.

See the removal of irda-utils:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955337

-- 
Daniele Napolitano
dna...@gmail.com

Bug#992358: transition: pdal

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
Control: forwarded -1 https://release.debian.org/transitions/html/auto-pdal.html

PDAL 2.3.0 has been in experimental for quite a while, I'd like to move it to 
unstable now.

All reverse dependencies built successfully with the version in experimental as 
summarized below.


Transition: pdal

 libpdal-base12 (2.2.0+ds-1+b1) -> libpdal-base13 (2.3.0+ds-1~exp1)
 libpdal-util12 (2.2.0+ds-1+b1) -> libpdal-util13 (2.3.0+ds-1~exp1)

The status of the most recent rebuilds is as follows.

 cloudcompare (2.10.3-4) OK
 grass(7.8.5-1)  OK
 paraview (5.9.0-2)  OK


Kind Regards,

Bas

Bug#992359: spdlog: Please package new upstream version (1.8.5)

[Boyuan Yang]

Source: spdlog
Severity: normal
Version: 1:1.8.1+ds-2.1
X-Debbugs-CC: cru...@debian.org

Dear Debian spdlog package maintainers,

Current version of spdlog in Debian is 1.8.1, and a new version of 1.8.5 is
now available. One of my packages (flameshot) needs spdlog/1.8.5 in the new
version. Could you please update spdlog to at least 1.8.5?

I see that the git packaging repo in Salsa GitLab already has a 1.8.5 version
prepared. It would be great if it can be packaged in near future. Please let
me know if I can provide with any help (such as package sponsorship).

Thanks,
Boyuan Yang


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

Bug#992300: ca-certificates: ca-certificate update fails because of missing /usr/bin/cert-sync

[Alex]

Am 17.08.21 um 16:32 schrieb Michael Shuler:
> Control: notfound -1 20210119
> Control: reassign -1 ca-certificates-mono
> Control: tags -1 + moreinfo
> 
> On 8/16/21 4:58 PM, Alex wrote:
>> ...
>> Updating Mono key store
>> /etc/ca-certificates/update.d/mono-keystore: 10: /usr/bin/cert-sync:
>> not found
>> Done
> 
> Reassigning to appropriate package, ca-certificates-mono.
> 
> Bug reporter's ca-certificates-mono version is unknown, but it appears
> that #902663 with the same error report was fixed in
> ca-certificates-mono 5.18.0.240+dfsg-2. Please, update bug report with
> the proper "found" version.

I am not sure if ca-certificates-mono was installed at all. I do not
have mono on the system.

$ dpkg -l|grep mono|grep -v fonts-|grep -v python3-monotonic
rc  ca-certificates-mono 4.6.2.7+dfsg-1
all  Common CA certificates (Mono keystore)
rc  mono-runtime-common  4.6.2.7+dfsg-1
amd64Mono runtime - common files


$ ls /etc/ca-certificates/update.d/mono-keystore /usr/bin/cert-sync
ls: cannot access '/usr/bin/cert-sync': No such file or directory
/etc/ca-certificates/update.d/mono-keystore


$ grep ca-certificates /var/log/dpkg.log
2021-08-16 22:31:53 upgrade ca-certificates:all 20200601~deb10u2 20210119
2021-08-16 22:31:53 status half-configured ca-certificates:all
20200601~deb10u2
2021-08-16 22:31:53 status unpacked ca-certificates:all 20200601~deb10u2
2021-08-16 22:31:53 status half-installed ca-certificates:all
20200601~deb10u2
2021-08-16 22:32:13 status unpacked ca-certificates:all 20210119
2021-08-16 23:50:04 configure ca-certificates:all 20210119 
2021-08-16 23:50:04 status unpacked ca-certificates:all 20210119
2021-08-16 23:50:05 status half-configured ca-certificates:all 20210119
2021-08-16 23:50:12 status installed ca-certificates:all 20210119
2021-08-16 23:50:12 status triggers-pending ca-certificates:all 20210119
2021-08-16 23:55:15 trigproc ca-certificates:all 20210119 
2021-08-16 23:55:15 status half-configured ca-certificates:all 20210119
2021-08-16 23:55:18 status installed ca-certificates:all 20210119

$ grep mono /var/log/dpkg.log|grep -v python-monotonic|grep -v
python3-monotonic|grep -v fonts-noto-mono
(empty)

with kind regards,
Alex

Bug#992360: xfce4-notes missing from bullseye

[Alan Burlison]

Package: xfce4-notes
Severity: serious
Justification: 3

Dear Maintainer,

   * What led up to the situation?
 Upgrade from buster to bullseye

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

   * What was the outcome of this action?
 xfce4-notes no longer available post upgrade.
 Tried manual reinstallation with the following results:

 # apt install xfce4-notes
 Reading package lists... Done
 Building dependency tree... Done
 Reading state information... Done
 Package xfce4-notes is not available, but is referred to by another
package.
 This may mean that the package is missing, has been obsoleted, or
 is only available from another source

 E: Package 'xfce4-notes' has no installation candidate
 #

   * What outcome did you expect instead?
 xfce4-notes still to be installed

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages xfce4-notes depends on:
ii  libc6   2.31-13
ii  libcairo2   1.16.0-5
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libglib2.0-02.66.8-1
ii  libgtk2.0-0 2.24.33-2
ii  libpango-1.0-0  1.46.2-3
pn  libunique-1.0-0 
ii  libx11-62:1.7.2-1
ii  libxfce4ui-1-0  4.12.1-3
ii  libxfce4util7   4.16.0-1
ii  libxfconf-0-2   4.12.1-1

xfce4-notes recommends no packages.

Bug#992192: cpio RCE Exploit Caused by Integer Overflow

[Diederik de Haas]

Looks very much like the same issue as mentioned here:
https://lists.gnu.org/archive/html/bug-cpio/2021-08/msg5.html

On Debian, the new problem is tracked at https://bugs.debian.org/992192 which 
is a 'continuation' of https://bugs.debian.org/992098

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

Bug#947261: ITP: python-poetry -- Python dependency management and packaging made easy

[Taihsiang Ho (tai271828)]

Hi Emmanuel,

Thank you for the update. Is this the DPT thread?
https://lists.debian.org/debian-python/2021/06/msg00017.html
If yes, I will give it a try and update my progress on the thread.

Cheers,
Tai

On Sun, Jun 20, 2021 at 12:12 AM Emmanuel Arias  wrote:

> Hello!
>
> On 6/17/21 6:00 PM, Taihsiang Ho (tai271828) wrote:
> > Hi Emmanuel,
> >
> > I can help as a poetry user for a while if you don't mind. It seems that
> I
> > could reproduce the pytest-mock issue by building this poetry deb
> source[1]
> > with Ubuntu 21.04. For better communication, I am wondering the following
>
> I fixed with this patch [0].
>
> I guess I finished a first complete package of poetry. Please look in
> the DPT
> mailing list.
>
>
> [0]
>
> https://salsa.debian.org/python-team/packages/poetry/-/blob/debian/master/debian/patches/0002-Fix-incompatibility-between-pytest-and-pytest-mock.patch
>
> Cheers
>
> --
> Emmanuel Arias
> @eamanu
> yaerobi.com
>
>

Bug#992345: www.debian.org: bullseye release-notes are misleading about the needed disk space

[Vincent Lefevre]

Hi Cyril,

On 2021-08-17 18:01:44 +0200, Cyril Brulebois wrote:
> Hi Vincent,
> 
> Vincent Lefevre  (2021-08-17):
> > 649 upgraded, 113 newly installed, 11 to remove and 1 not upgraded.
> > Need to get 455 MB of archives.
> > After this operation, 558 MB of additional disk space will be used.
> > 
> > and I had around 650 MB free space
> 
> 455+558 >> 650 so it was very unlikely to work?

This is what I was wondering initially, but the release notes say:

  If you do not have enough space for the upgrade, apt will warn you
  with a message like this:
  E: You don't have enough free space in /var/cache/apt/archives/.

i.e. if the test was 455+558 < 650, the lack of space would be
detectable by apt, so that I should have got a warning. Since I
didn't get the warning, I supposed that the 455 MB were included in
the 558 MB (the last message is not clear: "additional disk space"
compared to the status before or after the download?).

> > I suspect that some packages like this one need a lot of temporary
> > disk space (could this be related to initrd before compression?).
> > But there is nothing about that in the release notes. And perhaps
> > a warning should have been output by apt.
> 
> There's one for the directory where debs are downloaded (which you
> didn't get since 455 << 650), but I suspect it's harder to estimate
> where the whole “additional disk space” is going to end up,
> depending on file system layout, etc.?

The text from the release notes clearly says "for the upgrade", not
"for the download of the archives". Thus the comparison would have
been 455+558 vs 650 if 455 is not included in the 558. Perhaps it
should assume that everything goes to the same partition since
AFAIK, this is the most common case (optionally check whether
/var/cache/apt/archives and / are on different partitions); this
is just a warning after all.

In my case, there's a second disk, but mounted on /srv. So this
shouldn't count.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#992334: blhc: False positive with ff-c++ from FreeFEM++ package

[Eriberto]

Em ter., 17 de ago. de 2021 às 16:10, François Mazen  escreveu:
>
> Hi Eriberto,
>
> thanks for the pointer and the examples, and sorry for the noise!

You're welcome.

Bug#970380: xrdp: Newer version (0.9.14) available

[Link, Bruce]

I'd like to add that as per 
https://ddei5-0-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fgithub.com%2fneutrinolabs%2fxorgxrdp%2fissues%2f156&umid=503431C4-C9C6-2805-86D7-D38FC443EA39&auth=2628ad18b21f934c4a3f3bcb7fa326f6a4758e66-ee2307a34be4246e304542e194cb071a22ba5149,
 that Debian Bullseye is broken out of the box with the current version of xrdp 
and xorgxrdp installed. Migrating these to 0.9.14 corrects this issue.

Bug#992347: open-iscsi on upgrades fail to finish postinst script

[Jose M Calhariz]

Package: open-iscsi
Version: 2.1.3-5
Severity: normal

During upgrades of open-iscsi on my environment it fails to run
postinst with success.  I got the following messages:

Setting up open-iscsi (2.1.3-5) ...
open-iscsi postinst: since the check in preinst some iSCSI sessions have
 failed. -> will wait 30s for automatic recovery
open-iscsi postinst: some sessions are still in failed state -> iscsid
 will be restarted regardless, since that may
 actually help with the session recovery.
dpkg: error processing package open-iscsi (--configure):
 installed open-iscsi package post-installation script subprocess returned 
error exit status 1


I have tried to change the postinst to wait for more time, for example
120s and it worked, after 40 seconds of wait.

Kind regards
Jose M Calhariz


-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages open-iscsi depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13
ii  libisns0   0.100-3
ii  libkmod2   28-1
ii  libmount1  2.36.1-8
ii  libopeniscsiusr2.1.3-5
ii  libssl1.1  1.1.1k-1
ii  libsystemd0247.3-6
ii  udev   247.3-6

open-iscsi recommends no packages.

open-iscsi suggests no packages.

-- debconf information:
  open-iscsi/upgrade_recovery_error:
  open-iscsi/upgrade_even_with_failed_sessions:
  open-iscsi/downgrade_and_break_system:
  open-iscsi/remove_even_with_active_sessions:

Bug#992361: O: python-slip

[Michael Biebl]

Package: wnpp
Severity: normal
X-Debbugs-Cc: python-modules-t...@lists.alioth.debian.org, bi...@debian.org
Control: affects -1 src:python-slip

Hi,

I'm orphaning the python-slip package.
In the past, it was a dependency of firewalld, which is why I packaged
it for Debian.
Starting with firewalld 1.0, it no longer depends on python-slip [1].
I'm therefor orphaning the package.
The last upstream release is from 2017, upstream appears to be not that
active [2].

I've CCed the Python modules team, maybe they have an interest in taking
over the package.
I already asked Laurent Bigonville, the maintainer of selinux-dbus and
selinux-python (the remaining rdeps of python-slip), but he suggested to
orphan the package.

Regards,
Michael


[1] https://github.com/firewalld/firewalld/pull/793
[2] https://github.com/nphilipp/python-slip/commits/master

Bug#992334: blhc: False positive with ff-c++ from FreeFEM++ package

[Eriberto]

To help you a bit more... Note that debian/rules will write an
'ignore' line in the .build file. Considering your package has a long
time building process, to test, you can manually write a similar line
in .build and test using 'blhc --all --debian .build', before
changing the debian/rules. See below an example about what write in
.build file (see the middle line):

Makefile:894: warning: ignoring prerequisites on suffix rule definition
blhc: ignore-line-regexp: eval\ \./ff-c\+\+\ .*\.cpp.*
eval ./ff-c++ tetgen.cpp -ltet

Cheers,

Eriberto

Bug#992362: release-notes: Out of step wuth apt maintainers

[Brian Potkin]

Package: release-notes
Severity: normal


Please see

  https://lists.debian.org/debian-doc/2021/08/msg00077.html

Then look at

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

How abut a bit of consistency?

-- 
Brian.