Bug#993759: uucp FTBFS: dh_installsystemd vs /usr-merge

[Helmut Grohne]

Source: uucp
Version: 1.07-27
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: debhel...@packages.debian.org

The /usr-merge broke the uucp build. dh_installsystemd now moves
.services files from /lib to /usr/lib. The consequence is as follows:

|debian/rules override_dh_installsystemd
| make[1]: Entering directory '/<>'
| dh_installsystemd
| # we come from an inetd service, so we have to set accept=yes in uucp.socket 
and such require the @
| mv `pwd`/debian/uucp/lib/systemd/system/uucp.service 
`pwd`/debian/uucp/lib/systemd/system/uucp@.service
| mv: cannot stat 
'/<>/debian/uucp/lib/systemd/system/uucp.service': No such file or 
directory
| make[1]: *** [debian/rules:119: override_dh_installsystemd] Error 1
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:27: binary] Error 2
| dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
exit status 2

Please don't shoot the messenger.

Helmut

Bug#979501: DEBUG MY ACCOUNT

[Shishir Kumar Dey]

Bug#993758: source-includes-file-in-files-excluded should be smarter

[Julien Puydt]

Package: lintian
Version: 2.104.0
Severity: wishlist

The source-includes-file-in-files-excluded error should be made
smarter. I have a javascript package where most of the upstream tarball
is garbage, so d/copyright reads:

Files-Excluded: *
Files-Included: very short list

and that makes lintian go postal.

It really should filter out the errors for files which have been
excluded then included.

Cheers,

J.Puydt

Bug#993157: autoconf-2.71 regression?

[Marko Lindqvist]

 Likely an autoconf-2.71 (currently in unstable, but blocked from
migrating to testing due to regressions caused) issue.


 - ML

Bug#970636: tracker: conffile not removed: /etc/xdg/autostart/tracker-{store,extract,miner-fs}.desktop

[Paul Wise]

Package: tracker
Version: 3.1.1-3
Followup-For: Bug #970636
Control: retitle -1 tracker: conffiles not removed: 
/etc/xdg/autostart/tracker-{store,extract,miner-fs}.desktop

With the latest tracker in Debian unstable there are a few more
conffiles that are obsolete and need to be removed.

tracker: obsolete-conffile /etc/xdg/autostart/tracker-store.desktop
tracker-extract: obsolete-conffile /etc/xdg/autostart/tracker-extract.desktop
tracker-miner-fs: obsolete-conffile /etc/xdg/autostart/tracker-miner-fs.desktop

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages tracker depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2
ii  dpkg  1.20.9
ii  libc6 2.31-17
ii  libglib2.0-0  2.68.4-1
ii  libglib2.0-bin2.68.4-1
ii  libicu67  67.1-7
ii  libsqlite3-0  3.36.0-2
ii  libstemmer0d  2.1.0-1
ii  libtracker-sparql-3.0-0   3.1.1-3
ii  shared-mime-info  2.0-1

Versions of packages tracker recommends:
ii  tracker-miner-fs  3.1.1-4

tracker suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#993632: Replace x11-utils dependency by a range of options that includes zenity and kdialog

[Carsten Schoenert]

Hello Alexis,

Am 05.09.21 um 23:42 schrieb Alexis PM:
> But changing the dependency declaration from 'x11-utils' to 'x11-utils |
> zenity | kdialog' makes a tiling manager user have to have x11-utils (or
> zenity or kdialog) installed and allows a user of xfce+zenity or
> lxde+zenity to not have to install x11-utils.

that's a useful suggestion and I think I can modify the part in
d/control that way.
Coming up with a patch or a proposal what the reporter like to change is
always better as it help to not get into misreadings.

> The problem with the x11-utils package is that it is not just xmessage,
> but populates the system and the menu with a dozen additional programs
> including a display information utility for X, an X event displayer, a
> glyph displayer, two X font browsers/selectors/displayers, xkill, an X
> client displayer,... For anyone setting up a desktop with a few
> carefully chosen applications, having to install the full suite of
> applications 'x11-utils' is counterintuitive.
I've a slight different view still on this.
I don't see much usefulness in completely dropping x11-utils and get rid
of about 720kB installed size, but have now to deal with which exact
package list instead the user need to know now.
Disk space isn't a problem any more on graphical work places.

-- 
Regards
Carsten

Bug#973942: nemo: thumbnailing doesn't work for all kinds of videos

[Christoph Anton Mitterer]

Control: reassign -1 totem-common
Control: severity -1 important


Hey.


I think I found the reason for this...


I tried with various further debug options:

$ /usr/bin/totem-video-thumbnailer  -s 256 file:///home/calestyo/test.mp4 foo -v
TotemVideoThumbnailer-Message: 06:45:48.757: Initialised libraries, about to 
create video widget
TotemVideoThumbnailer-Message: 06:45:48.763: setting URI 
file:///home/calestyo/test.mp4
TotemVideoThumbnailer-Message: 06:45:48.763: Video widget created
TotemVideoThumbnailer-Message: 06:45:48.763: About to open video file
TotemVideoThumbnailer-Message: 06:45:49.000: Checking whether file has cover
TotemVideoThumbnailer-Message: 06:45:49.000: Opened video file: 
'file:///home/calestyo/test.mp4'
TotemVideoThumbnailer-Message: 06:45:49.000: About to seek to 0,33
TotemVideoThumbnailer-Message: 06:45:49.020: About to get frame for iter 0

(totem-video-thumbnailer:401457): GLib-ERROR **: 06:45:49.023: 
../../../glib/gmem.c:112: failed to allocate 1244311 bytes
Trace/breakpoint trap

$ /usr/bin/totem-video-thumbnailer -v -s 256 file:///home/calestyo/test.mp4 foo
TotemVideoThumbnailer-Message: 06:39:48.944: Initialised libraries, about to 
create video widget
TotemVideoThumbnailer-Message: 06:39:48.950: setting URI 
file:///home/calestyo/test.mp4
TotemVideoThumbnailer-Message: 06:39:48.951: Video widget created
TotemVideoThumbnailer-Message: 06:39:48.951: About to open video file
TotemVideoThumbnailer-Message: 06:39:49.197: Checking whether file has cover
TotemVideoThumbnailer-Message: 06:39:49.197: Opened video file: 
'file:///home/calestyo/test.mp4'
TotemVideoThumbnailer-Message: 06:39:49.197: About to seek to 0,33
TotemVideoThumbnailer-Message: 06:39:49.211: About to get frame for iter 0

(totem-video-thumbnailer:400083): GStreamer-WARNING **: 06:39:49.213: failed to 
create thread: Error creating thread: Resource temporarily unavailable


$ /usr/bin/totem-video-thumbnailer  -s 256 file:///home/calestyo/test.mp4 foo 
-v --gst-debug-level=
TotemVideoThumbnailer-Message: 06:46:18.672: Initialised libraries, about to 
create video widget
TotemVideoThumbnailer-Message: 06:46:18.679: setting URI 
file:///home/calestyo/test.mp4
TotemVideoThumbnailer-Message: 06:46:18.679: Video widget created
TotemVideoThumbnailer-Message: 06:46:18.679: About to open video file
TotemVideoThumbnailer-Message: 06:46:18.917: Checking whether file has cover
TotemVideoThumbnailer-Message: 06:46:18.918: Opened video file: 
'file:///home/calestyo/test.mp4'
TotemVideoThumbnailer-Message: 06:46:18.918: About to seek to 0,33
TotemVideoThumbnailer-Message: 06:46:18.929: About to get frame for iter 0

***MEMORY-ERROR***: totem-video-thumbnailer[401516]: GSlice: failed to allocate 
4080 bytes (alignment: 4096): Cannot allocate memory

Aborted



So it seems there is some issue with creating new threads and not
enough memory being available for that.

With these errors I found:
https://blog.frehi.be/2021/06/19/missing-video-thumbnails-in-nautilus-in-debian-bullseye/


Adding a "-l" to the Exec= line in
/usr/share/thumbnailers/totem.thumbnailer indeed fixes the issue.

I haven't checked now, whether removing libopenblas0-pthread
respectively switching to another one, also fixes it, as described in
the chat.


Since the bug is rather in totem, reassigning it there.


Cheers,
Chris.

Bug#993757: ITP: r-bioc-mbkmeans -- GNU R mini-batch K-means clustering for single-cell RNA-seq

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-mbkmeans -- GNU R mini-batch K-means clustering for 
single-cell RNA-seq
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-mbkmeans
  Version : 1.8.0
  Upstream Author : Yuwei Ni,
* URL : https://bioconductor.org/packages/mbkmeans/
* License : MIT
  Programming Lang: GNU R
  Description : GNU R mini-batch K-means clustering for single-cell RNA-seq
 Implements the mini-batch k-means algorithm for large
 datasets, including support for on-disk data representation.

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

Bug#993756: ITP: r-cran-benchmarkme -- GNU R crowd sourced system benchmarks

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-benchmarkme -- GNU R crowd sourced system benchmarks
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-benchmarkme
  Version : 1.0.7
  Upstream Author : Colin Gillespie
* URL : https://cran.r-project.org/package=benchmarkme
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R crowd sourced system benchmarks
 Benchmark your CPU and compare against other CPUs.
 Also provides functions for obtaining system specifications, such as
 RAM, CPU type, and R version.

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

Bug#993754: manpages-dev: 5.10 fails to upgrade due to conflict with manpages 4.10

[Otto Kekäläinen]

Package: manpages-dev
Version: 5.10-1

Hello!

I spotted on Salsa-CI runs that when a Stretch system with manpages
4.10 tries to upgrade to Sid, it fails due to conflict with
manpages-dev 5.10. There should probably be some conflicts/breaks
defined in manpages-dev on manpages.

This is visible on a CI system where every step is reproducible and
runs off clean Docker images, so this is not a sporadic error.

Full log at:
https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/1911231

Relevant log snippet below:

# Replace any old repos with just Sid
echo 'deb http://deb.debian.org/debian sid main' > /etc/apt/sources.list
# Upgrade minimal stack first
apt-get update
apt-get install -y apt
...
dpkg: considering deconfiguration of manpages, which would be broken
by installation of manpages-dev ...
dpkg: yes, will deconfigure manpages (broken by manpages-dev)
Preparing to unpack .../1-manpages-dev_5.10-1_all.deb ...
De-configuring manpages (4.10-2) ...
Unpacking manpages-dev (5.10-1) over (4.10-2) ...
dpkg: error processing archive
/tmp/apt-dpkg-install-nJwkNl/1-manpages-dev_5.10-1_all.deb (--unpack):
 trying to overwrite '/usr/share/man/man4/console_ioctl.4.gz', which
is also in package manpages 4.10-2
dpkg: considering deconfiguration of manpages-dev, which would be
broken by installation of manpages ...
dpkg: yes, will deconfigure manpages-dev (broken by manpages)
Preparing to unpack .../2-manpages_5.10-1_all.deb ...
De-configuring manpages-dev (4.10-2) ...
Unpacking manpages (5.10-1) over (4.10-2) ...
Replacing files in old package manpages-dev (4.10-2) ...
Selecting previously unselected package libcrypt-dev:amd64.
Preparing to unpack .../3-libcrypt-dev_1%3a4.4.25-2_amd64.deb ...
Unpacking libcrypt-dev:amd64 (1:4.4.25-2) ...
Replacing files in old package manpages-dev (4.10-2) ...
Preparing to unpack .../4-libcomerr2_1.45.7-1_amd64.deb ...
Unpacking libcomerr2:amd64 (1.45.7-1) over (1.43.4-2+deb9u2) ...
Selecting previously unselected package libcom-err2:amd64.
Preparing to unpack .../5-libcom-err2_1.46.4-1_amd64.deb ...
Unpacking libcom-err2:amd64 (1.46.4-1) ...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-nJwkNl/1-manpages-dev_5.10-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
...

Bug#993755: libcrypt.so.1: cannot open shared object file when upgrading from Stretch to Sid

[Otto Kekäläinen]

Package: libcrypt1

The file /lib/x86_64-linux-gnu/libcrypt.so.1 used to be in package
libc6 on Stretch and Buster until it was split off into a separate
libcrypt in Bullseye (and in Sid).

Something in the upgrade logic to adopt the new pacakge is lacking
when upgrading libc6 as the system ends in a situation where
libcrypt.so.1 is removed before the replacement from a new package is
installed.

I noticed this on Salsa-CI for my own package. It happens in a
reproducible way on a clean Docker image. See full log at:
https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/1911234

Here is the relevant part:

# Replace any old repos with just Sid
echo 'deb http://deb.debian.org/debian sid main' > /etc/apt/sources.list
# Upgrade minimal stack first
apt-get update
apt-get install -y apt
apt-get install -y pkg-config libmariadb2 libmariadb-dev libmariadb-dev-compat
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  bzip2 libdpkg-perl libffi6 libfile-fcntllock-perl libgdbm3 libglib2.0-0
  libglib2.0-data libicu57 liblocale-gettext-perl libperl5.24 libssl1.1
  libxml2 netbase perl perl-modules-5.24 rename sgml-base shared-mime-info
  xdg-user-dirs xml-core xz-utils
Suggested packages:
  bzip2-doc debian-keyring gnupg | gnupg2 gcc | c-compiler binutils patch
  perl-doc libterm-readline-gnu-perl | libterm-readline-perl-perl make
  sgml-base-doc debhelper
The following NEW packages will be installed:
  bzip2 libdpkg-perl libffi6 libfile-fcntllock-perl libgdbm3 libglib2.0-0
  libglib2.0-data libicu57 liblocale-gettext-perl libmariadb-dev
  libmariadb-dev-compat libmariadb2 libperl5.24 libssl1.1 libxml2 netbase perl
  perl-modules-5.24 pkg-config rename sgml-base shared-mime-info xdg-user-dirs
  xml-core xz-utils
0 upgraded, 25 newly installed, 0 to remove and 0 not upgraded.
...
Preparing to unpack .../libc6_2.31-17_amd64.deb ...
Checking for services that may need to be restarted...
Checking init scripts...
Unpacking libc6:amd64 (2.31-17) over (2.24-11+deb9u4) ...
Setting up libc6:amd64 (2.31-17) ...
Installing new version of config file
/etc/ld.so.conf.d/x86_64-linux-gnu.conf ...
/usr/bin/perl: error while loading shared libraries: libcrypt.so.1:
cannot open shared object file: No such file or directory
dpkg: error processing package libc6:amd64 (--configure):
 subprocess installed post-installation script returned error exit status 127
Errors were encountered while processing:
 libc6:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#935334: closed by Lyndon Brown (Re: Re: debootstrap: man page says that --include will add package to download and extract list, but an experiment shows opposite)

[Askar Safin]

control: reopen 935334

Hi, Lyndon Brown. It seems you don't understand what I mean, please, re-read 
bug report.

First of all, note on terminology, specially on word "extracting". I will use 
output of "debootstrap" tool itself as source of terminology. Look here, this 
is output of debootstrap: https://paste.debian.net/1210574/ . As you can see, 
debootstrap output uses word "extracting" in one very specific sense: 
"extracting" means extracting using "dpkg-deb" or "ar" at very early stage of 
debootstrap. Other actions have different names, for example, "unpacking". So, 
word "extract" means "extract using dpkg-deb or ar", this is different from 
"unpack using dpkg --unpack". So, I will use word "extract" in this sense.

Next. We know that --foreign causes early stopping of debootstrap. This 
stopping happens AFTER extracting stage (I use here word "extracting" in sense 
introduced above).

Next. Man page says: "--include=alpha,beta Comma separated list of packages 
which will be added to download and extract lists".

So, --include=aptitude should add aptitude to extract list, i. e. aptitude 
should be extracted at extract stage. --foreign runs extract stage, so 
--foreign should extract aptitude. But it doesn't. So man page (or debootstrap 
output or debootstrap itself) is wrong.

So, we anyway have a bug either in debootstrap implementation or in terminology 
used in its output or in manual page. I think we should fix the latter.

==
Askar Safin
http://safinaskar.com
https://sr.ht/~safinaskar
https://github.com/safinaskar

Bug#993211: inn2: ovdb_monitor/server can't start due to missing /run/news

[Russ Allbery]

I had forgotten more about this structure than I thought and should have
re-read the source.  The inode number in question isn't the link between
the index and data file; it's between the top-level group.index file and
the index file for a specific group.  It's still correct that it's used to
detect when the group has been expired so that the index can be remapped.

John Goerzen  writes:

> This was running inside a Docker container.  Initially I installed some
> things, then tar'd up /var/{lib,spool}/news in preparation for making them
> into Docker volumes.  I did make the volumes, and unpacked the tarball
> over them.  Was this coinciding with the log messages?  That I don't know,
> but it's the most plausible explanation I have right now.

Oh, okay.  Yeah, this is probably underdocumented, but if you move the
overview spool, you probably want to run tdx-util -A to check the results
and tdx-util -F to fix any problems.  It will correct all of the inode
references.

> I'm sure this is right.  I will note that people may like to be able to
> mount a ZFS snapshot -- which would certainly have a different st_dev or
> st_ino -- without 50,000 errors.  But it may well be that I had
> forgotten this.

Different st_dev is fine.  It would be nice if the snapshot preserved the
inode number, but I have no idea if it would.

-- 
Russ Allbery (r...@debian.org)  

Bug#993211: inn2: ovdb_monitor/server can't start due to missing /run/news

[John Goerzen]

On Sun, Sep 05 2021, Russ Allbery wrote:


We could, but it does indicate an actual problem, so I'd love to
understand more about why this is happening.  If ZFS does change 
the
inodes on every reboot, another possible solution may be to 
ensure that
expireover fixes the inode references (I'm not sure that it does 
right now
in cases where it didn't need to change anything during 
expiration), which

means the messages will only happen once after each reboot.


This has been nagging at me, and after giving it some more 
thought, I am remembering something now -- the exact timing is 
lost, and I apologize for not thinking of it before.


This was running inside a Docker container.  Initially I installed 
some things, then tar'd up /var/{lib,spool}/news in preparation 
for making them into Docker volumes.  I did make the volumes, and 
unpacked the tarball over them.  Was this coinciding with the log 
messages?  That I don't know, but it's the most plausible 
explanation I have right now.  The volumes were on a different ZFS 
dataset so that would certainly have different inode numbers. 
Again, I apologize for not thinking of this before.


I assume ZFS can't be changing them constantly without a reboot 
or a
remounting of the file system, since presumably that would break 
lots of

other software.


I'm sure this is right.  I will note that people may like to be 
able to mount a ZFS snapshot -- which would certainly have a 
different st_dev or st_ino -- without 50,000 errors.  But it may 
well be that I had forgotten this.


- John

Bug#993705: freeorion: 'PythonAI failed to initialize' when starting singleplayer game with AI

[joyfulmange]

I should have looked at this first, but the game's log files for both AI and 
world generation show some errors in relation to importing of a module 
(specifically on line 150 of CommonFramework.cpp). I'm not too savvy with C++, 
but I do know that something is messed up with how its importing 
"common.configure_logging". Judging by their documentation on the python 
directory, common.configure_logging is supposed to be imported from a folder 
above turn_events.py 
,
 however isn't 
(https://github.com/freeorion/freeorion/tree/84c2e2e820d0ec55d2bd1f8f903398bab6cdf0d9/default/python).
 
Sep 5, 2021, 17:16 by joyfulma...@tutanota.com:

> I opted to try to reproduce the problem on both a unstable Devuan and Debian 
> VM and it worked as intended. It's likely that there is something up with my 
> system then that's causing this problem. If I can figure out what in specific 
> it is, I'll let you know in case its an incompatible package.
>
> Sep 5, 2021, 09:32 by a...@debian.org:
>
>> Control: tags -1 moreinfo
>>
>> Hello,
>>
>> On Sun, 5 Sep 2021 03:36:44 +0200 (CEST) joyfulma...@tutanota.com wrote:
>>
>>> Package: freeorion
>>> Version: 0.4.10.2-1
>>> Severity: normal
>>>
>>> Dear Maintainer,
>>>
>>>    * What led up to the situation?
>>>    In the unstable version, starting a game with AI fails to allow a
>>>    game to start.
>>>    * What exactly did you do (or not do) that was effective (or
>>>  ineffective)?
>>>  I attempted recompiling the game and researching the bug to see if
>>>  I was missing a dependency, however this resulted in nothing
>>>  worthwhile occouring.
>>>    * What was the outcome of this action?
>>>    'PythonAI failed to initialize' in console and "The connection to the
>>>    server has been lost" as an error from the game
>>>    * What outcome did you expect instead?
>>>    I expected a game to start with AI enabled
>>>
>>>
>>>
>>> -- System Information:
>>> Distributor ID:   Devuan
>>> Description:  Devuan GNU/Linux 4 (chimaera)
>>> Release:  4
>>> Codename: n/a
>>> Architecture: x86_64
>>>
>>
>> The single player mode with AI works for me. I noticed you are using Devuan 
>> not
>> Debian. Can you reproduce the problem in Debian unstable and tell me the 
>> exact
>> steps to reproduce the problem?
>>
>> Regards,
>>
>> Markus
>>
>
>

Bug#980136: ITP: zutty -- high-end terminal for low-end systems

[Sergio Cipriano]

I forgot to put the bug in CC.

‐‐‐ Original Message ‐‐‐

On Sunday, September 5th, 2021 at 08:32, Sergio Cipriano 
 wrote:

> Hi Ricardo,
>
> On Sunday, September 5th, 2021 at 08:04, Ricardo Mones mo...@debian.org wrote:
>
> > control: owner -1 !
> >
> > Hi Sergio,
> >
> > On Mon, 30 Aug 2021 23:22:23 + Sergio Cipriano
> >
> > sergios...@protonmail.com wrote:
> >
> > > retitle 980136 ITP: zutty -- high-end terminal for low-end systems
> > >
> > > owner 980136 !
> >
> > Seems you didn't noticed the tag I set on this bug on August 27th [1], but
> >
> > this has already been packaged and it's waiting on the new queue:
> >
> > https://ftp-master.debian.org/new/zutty_0.9.2.20210612.134406%2Bdfsg1-1.html
> >
> > regards,
> >
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980136;msg=7
>
> Thanks, you're right, I didn't see the tag.
>
> Regards,
>
> 
>
> Sérgio Cipriano.

--
Sérgio Cipriano.

Bug#993730: snapd: - Mount snap "core" (11606) (snap is unusable due to missing files; contact developer)

[Michael Hudson-Doyle]

This is already fixed in testing I think.

On Mon, 6 Sept 2021 at 03:45, matteo  wrote:

> Package: snapd
> Version: 2.49-1+b5
> Severity: important
> X-Debbugs-Cc: eng.matteo.nunzi...@gmail.com
>
> Dear Maintainer,
>
>* What led up to the situation?
> tring to install any package with the snap command
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> tried to install: core, hello-world, google-cloud-sdk --classic. all failed
>* What was the outcome of this action?
> see above
>* What outcome did you expect instead?
> having snap installed
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> 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=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages snapd depends on:
> ii  adduser  3.118
> ii  apparmor 3.0.3-2
> ii  ca-certificates  20210119
> ii  gnupg2.2.27-2
> ii  gnupg1   1.4.23-1.1
> ii  libapparmor1 3.0.3-2
> ii  libc62.31-17
> ii  libcap2  1:2.44-1
> ii  libseccomp2  2.5.1-1
> ii  libudev1 247.9-1
> ii  openssh-client   1:8.4p1-5
> ii  squashfs-tools   1:4.5-2
> ii  systemd  247.9-1
> ii  udev 247.9-1
>
> Versions of packages snapd recommends:
> ii  gnupg  2.2.27-2
>
> Versions of packages snapd suggests:
> ii  zenity  3.32.0-7
>
> -- no debconf information
>

Bug#993705: freeorion: 'PythonAI failed to initialize' when starting singleplayer game with AI

[joyfulmange]

I opted to try to reproduce the problem on both a unstable Devuan and Debian VM 
and it worked as intended. It's likely that there is something up with my 
system then that's causing this problem. If I can figure out what in specific 
it is, I'll let you know in case its an incompatible package.

Sep 5, 2021, 09:32 by a...@debian.org:

> Control: tags -1 moreinfo
>
> Hello,
>
> On Sun, 5 Sep 2021 03:36:44 +0200 (CEST) joyfulma...@tutanota.com wrote:
>
>> Package: freeorion
>> Version: 0.4.10.2-1
>> Severity: normal
>>
>> Dear Maintainer,
>>
>>    * What led up to the situation?
>>    In the unstable version, starting a game with AI fails to allow a
>>    game to start.
>>    * What exactly did you do (or not do) that was effective (or
>>  ineffective)?
>>  I attempted recompiling the game and researching the bug to see if
>>  I was missing a dependency, however this resulted in nothing
>>  worthwhile occouring.
>>    * What was the outcome of this action?
>>    'PythonAI failed to initialize' in console and "The connection to the
>>    server has been lost" as an error from the game
>>    * What outcome did you expect instead?
>>    I expected a game to start with AI enabled
>>
>>
>>
>> -- System Information:
>> Distributor ID:   Devuan
>> Description:  Devuan GNU/Linux 4 (chimaera)
>> Release:  4
>> Codename: n/a
>> Architecture: x86_64
>>
>
> The single player mode with AI works for me. I noticed you are using Devuan 
> not
> Debian. Can you reproduce the problem in Debian unstable and tell me the exact
> steps to reproduce the problem?
>
> Regards,
>
> Markus
>

Bug#993753: debhelper: remove-on-upgrade in DEBIAN/conffiles is not equivalent to 'dpkg-maintscript-helper rm_conffile' in maintscripts

[Felix Lechner]

Package: debhelper
Severity: normal
X-Debbugs-CC: debian-lint-ma...@lists.debian.org

Hi,

The Lintian maintainers recently made several accommodations [1] for
some of the new features coming in Debhelper, but it is not clear from
Lintian's own packaging efforts that the 'remove-on-upgrade' attribute
in conffiles always works as intended. For a recent Lintian artifact
built on unstable [2] the development version of Lintian produces the
following hint:

E: lintian: conffile-is-not-in-package etc/lintianrc

Lintian prides itself on provoking no hints [3] so the matter received
some attention. Upon inspection, it seems debhelper turned the
instruction in d/lintian.maintscript

rm_conffile /etc/lintianrc 2.90.0~ lintian

into that line in DEBIAN/conffiles

remove-on-upgrade /etc/lintianrc

but those two ideas are not the same! Lintian has not shipped
/etc/lintianrc for some time. [4]

Debhelper also stopped inserting those generated lines in the
maintainer scripts (and in fact shipped no scripts at all):

# Automatically added by dh_installdeb/13.2.1
dpkg-maintscript-helper rm_conffile /etc/lintianrc 2.90.0\~ lintian -- "$@"
# End automatically added section

For this inquiry, we compared the recent build artifacts from Salsa CI
[2] with the Lintian version 2.104.0 currently in unstable.

I believe this is a bug in Debhelper. Please let us know if you concur
with our analysis. Thank you!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/commit/b8c88b5a604c541d1389c1f7e3eb6315ac80f1d9
[2] 
https://salsa.debian.org/lintian/lintian/-/jobs/1914634/artifacts/browse/debian/output/
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993711#5
[4] 
https://salsa.debian.org/lintian/lintian/-/commit/4b878e14d9758f7b44210ae65fc26acd30c67dc6

Bug#993632: Replace x11-utils dependency by a range of options that includes zenity and kdialog

[Alexis PM]

 Hello

>> In order to avoid unnecessary dependencies, please consider replacing
>> the strict x11-tools dependency with a range of options including
>> zenity and kdialog. > thunderbird-wrapper-helper.sh already supports zenity 
>> and kdialog,
>> only the package dependency declaration needs to be modified.
>
> well, the named helper script has a fallback to use xmessage that is
> needed in environments there no DE is installed and kdialog and zenity
> isn't available. Like users which only use a tiling manager, e.g. on i3.

But changing the dependency declaration from 'x11-utils' to 'x11-utils | zenity 
| kdialog' makes a tiling manager user have to have x11-utils (or zenity or 
kdialog) installed and allows a user of xfce+zenity or lxde+zenity to not have 
to install x11-utils.

> Currently the dependency on this package is still required.
> 
> Dropping x11-utils isn't gain that much.

The problem with the x11-utils package is that it is not just xmessage, but 
populates the system and the menu with a dozen additional programs including a 
display information utility for X, an X event displayer, a glyph displayer, two 
X font browsers/selectors/displayers, xkill, an X client displayer,... For 
anyone setting up a desktop with a few carefully chosen applications, having to 
install the full suite of applications 'x11-utils' is counterintuitive.

Thank you.

  

Bug#993752: lightdm-gtk-greeter: works badly with 2 screens of different widths (laptop + external monitor)

[Vincent Lefevre]

Package: lightdm-gtk-greeter
Version: 2.0.8-2
Severity: normal

I have a laptop with two 4K external monitors (bigger than the laptop
screen). Just after boot, only the laptop screen is active, and
everything is OK (well, except that I would prefer an external monitor
to be detected automatically, but that's another issue).

After logging out, the laptop screen and an external monitor are both
active (the driver[*] cannot handle 3 screens, thus the other external
monitor is off, which is OK).

So, basically, the configuration is 2 screens of different widths,
which matters in particular for the menu bar. By default, the width
of the 4K monitor is taken into account. But when I use a menu, the
display temporarily switches to the width of the laptop screen. This
doesn't prevent me from using the menu, but it is a bit annoying and
makes the menu a bit less easy to use.

[*] This is the proprietary Nvidia driver, as the nouveau driver
does not work with more than one screen.

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

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

Versions of packages lightdm-gtk-greeter depends on:
ii  libayatana-indicator3-7  0.8.4-1
ii  libc62.31-17
ii  libcairo21.16.0-5
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.68.4-1
ii  libgtk-3-0   3.24.30-3
ii  liblightdm-gobject-1-0   1.26.0-7
ii  libx11-6 2:1.7.2-1

Versions of packages lightdm-gtk-greeter recommends:
ii  adwaita-icon-theme  40.1.1-2
ii  desktop-base11.0.3
ii  gnome-themes-extra  3.28-1
ii  policykit-1 0.105-31

lightdm-gtk-greeter suggests no packages.

-- Configuration Files:
/etc/lightdm/lightdm-gtk-greeter.conf changed:
[greeter]
icon-size=64
xft-dpi=160
indicators=~host;~spacer;~clock;~spacer;~session;~language;~a11y;~power
clock-format=%F %T


-- no debconf information

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

Bug#993750: rgtk2: FTBFS on s390x: smoke-test failure: caught segfault

[Dirk Eddelbuettel]

Also: No other R packages here.  Maybe something off with gtk2?

  Build-Depends: debhelper (>= 10), dh-r (>= 20180615), \
 r-base-dev (>= 3.6.1), libgtk2.0-dev (>= 2.10.12), \
 libglade2-dev, libpango1.0-dev, libcairo2-dev 

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#993750: rgtk2: FTBFS on s390x: smoke-test failure: caught segfault

[Dirk Eddelbuettel]

On 6 September 2021 at 00:46, Simon McVittie wrote:
| Source: rgtk2
| Version: 2.20.36-2
| Severity: serious
| Tags: ftbfs bookworm sid
| Justification: fails to build from source (but built successfully in the past)
| X-Debbugs-Cc: debian-s...@lists.debian.org
| User: debian-s...@lists.debian.org
| Usertags: s390x
| 
| rgtk2 failed to build on s390x when binNMU'd recently, with what appears
| to be a smoke-test failure during installation:

Hm. Please explain what a smoke-test failure is.

(What we see below is the standard R behaviour of loading a package as the
finaly step of building it. A segfault here usually means /some/ API along
the way changed :-/ and is rare as a one-arch-only occurrence.

Dirk

| > make[1]: Leaving directory '/<>/src'
| > installing to 
/<>/debian/r-cran-rgtk2/usr/lib/R/site-library/00LOCK-rgtk2-2.20.36/00new/RGtk2/libs
| > ** R
| > ** demo
| > ** inst
| > ** byte-compile and prepare package for lazy loading
| > ** help
| > *** installing help indices
| > ** building package indices
| > ** testing if installed package can be loaded from temporary location
| > 
| >  *** caught segfault ***
| > address (nil), cause 'memory not mapped'
| > 
| > Traceback:
| >  1: gtkInit(args)
| >  2: fun(libname, pkgname)
| >  3: doTryCatch(return(expr), name, parentenv, handler)
| >  4: tryCatchOne(expr, names, parentenv, handlers[[1L]])
| >  5: tryCatchList(expr, classes, parentenv, handlers)
| >  6: tryCatch(fun(libname, pkgname), error = identity)
| >  7: runHook(".onLoad", env, package.lib, package)
| >  8: loadNamespace(package, lib.loc)
| >  9: doTryCatch(return(expr), name, parentenv, handler)
| > 10: tryCatchOne(expr, names, parentenv, handlers[[1L]])
| > 11: tryCatchList(expr, classes, parentenv, handlers)
| > 12: tryCatch({attr(package, "LibPath") <- which.lib.locns <- 
loadNamespace(package, lib.loc)env <- attachNamespace(ns, pos = pos, deps, 
exclude, include.only)}, error = function(e) {P <- if (!is.null(cc <- 
conditionCall(e))) paste(" in", deparse(cc)[1L])else ""msg <- 
gettextf("package or namespace load failed for %s%s:\n %s", 
sQuote(package), P, conditionMessage(e))if (logical.return && !quietly) 
message(paste("Error:", msg), domain = NA)else stop(msg, call. = FALSE, 
domain = NA)})
| > 13: library(pkg_name, lib.loc = lib, character.only = TRUE, logical.return 
= TRUE)
| > 14: withCallingHandlers(expr, packageStartupMessage = function(c) 
tryInvokeRestart("muffleMessage"))
| > 15: suppressPackageStartupMessages(library(pkg_name, lib.loc = lib, 
character.only = TRUE, logical.return = TRUE))
| > 16: doTryCatch(return(expr), name, parentenv, handler)
| > 17: tryCatchOne(expr, names, parentenv, handlers[[1L]])
| > 18: tryCatchList(expr, classes, parentenv, handlers)
| > 19: tryCatch(expr, error = function(e) {call <- conditionCall(e)if 
(!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch))) 
call <- sys.call(-4L)dcall <- deparse(call)[1L]prefix <- 
paste("Error in", dcall, ": ")LONG <- 75Lsm <- 
strsplit(conditionMessage(e), "\n")[[1L]]w <- 14L + nchar(dcall, type = 
"w") + nchar(sm[1L], type = "w")if (is.na(w)) w <- 14L + 
nchar(dcall, type = "b") + nchar(sm[1L], type = "b")if 
(w > LONG) prefix <- paste0(prefix, "\n  ")}else prefix <- 
"Error : "msg <- paste0(prefix, conditionMessage(e), "\n")
.Internal(seterrmessage(msg[1L]))if (!silent && 
isTRUE(getOption("show.error.messages"))) {cat(msg, file = outFile) 
   .Internal(printDeferredWarnings())}invisible(structure(msg, class = 
"try-error", condition = e))})
| > 20: try(suppressPackageStartupMessages(library(pkg_name, lib.loc = lib, 
character.only = TRUE, logical.return = TRUE)))
| > 21: tools:::.test_load_package("RGtk2", 
"/<>/debian/r-cran-rgtk2/usr/lib/R/site-library/00LOCK-rgtk2-2.20.36/00new")
| > An irrecoverable exception occurred. R is aborting now ...
| > Segmentation fault
| > ERROR: loading failed
| > * removing 
‘/<>/debian/r-cran-rgtk2/usr/lib/R/site-library/RGtk2’
| > dh_auto_install: error: R CMD INSTALL -l 
/<>/debian/r-cran-rgtk2/usr/lib/R/site-library --clean . 
"--built-timestamp='Thu, 02 Sep 2021 09:20:27 +'" returned exit code 1

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

[Simon McVittie]

On Sun, 05 Sep 2021 at 23:56:23 +, Paul Flaherty wrote:
> I am wondering if we can do a transition on gnome web

I think you are misunderstanding what is being tracked in #992870.

GNOME Web in Debian is the epiphany-browser package, which is already
at version 40 in testing/unstable.

> and also what other
> applications have been transitioned over to gnome 40 and GTK 4

The transition-tracking bug #992870 is about updating core components
of the GNOME desktop itself, in Debian testing/unstable. It is not about
individual applications.

Individual applications are not generally "transitioned over to gnome 40".
GNOME 40 versions of several applications are already in testing/unstable.
Some others are not yet available because they are blocked by separate
library transitions for libgweather and evolution-data-server, but those
are not part of the transition discussed in #992870.

Individual applications can switch from GTK 3 to GTK 4 without needing
coordination with the release team. This requires considerable changes
to happen in each application upstream, and will often take months or
years (some applications still use GTK 2). It does not have to happen
all at once: we can have a mixture of GTK 2, 3 and 4 applications if
necessary.

The only reason why GTK 4 was required for gnome-shell 40 is that one of
the few applications that is already using GTK 4 is gnome-extensions-app,
in the gnome-shell-extension-prefs package.

smcv

Bug#978893: ripperx: ftbfs with autoconf 2.70

[Simon McVittie]

On Thu, 31 Dec 2020 at 14:28:53 +, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> autoconf 2.70, but succeeds to build with autoconf 2.69.
...
> The full build log can be found at:
> http://qa-logs.debian.net/2020/09/26.ac270/ripperx_2.8.0-2_unstable_ac270.log
> The last lines of the build log are at the end of this report.

I don't think those lines indicate the actual error, which looks like a C++
compiler problem (perhaps because the new Autoconf version passes options
that make the compiler more strict?):

> In file included from /usr/include/c++/10/ext/string_conversions.h:41,
>  from /usr/include/c++/10/bits/basic_string.h:6535,
>  from /usr/include/c++/10/string:55,
>  from /usr/include/c++/10/stdexcept:39,
>  from err_dialog_handler.h:6,
>  from common.h:21,
>  from calc_stat.h:3,
>  from calc_stat.c:1:
> /usr/include/c++/10/cstdlib:151:11: error: ‘malloc’ has not been declared in 
> ‘::’
>   151 |   using ::malloc;
>   |   ^~
> In file included from /usr/include/c++/10/stdlib.h:36,
>  from cddbp.c:6:
> /usr/include/c++/10/cstdlib:151:11: error: ‘malloc’ has not been declared in 
> ‘::’
>   151 |   using ::malloc;
>   |   ^~
> In file included from cddbp.c:6:
> /usr/include/c++/10/stdlib.h:65:12: error: ‘malloc’ has not been declared in 
> ‘std’
>65 | using std::malloc;
>   |^~
> In file included from /usr/include/c++/10/stdlib.h:36,
>  from cddb.c:6:
> /usr/include/c++/10/cstdlib:151:11: error: ‘malloc’ has not been declared in 
> ‘::’
>   151 |   using ::malloc;
>   |   ^~
> In file included from cddb.c:6:
> /usr/include/c++/10/stdlib.h:65:12: error: ‘malloc’ has not been declared in 
> ‘std’
>65 | using std::malloc;
>   |^~

I tried to reproduce this in sbuild and got a different error:

> checking for strndup... (cached) yes
> checking for strstr... (cached) yes
> checking for openpty... no
> checking for openpty in -lutil... no
> configure: error: Missing required function: openpty
>   tail -v -n \+0 config.log
> ==> config.log <==
...
> configure:5959: checking for openpty
> configure:5959: g++ -o conftest -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c  >&5
...
> /usr/bin/ld: /tmp/ccVfJfLG.o: in function `main':
> ./conftest.c:65: undefined reference to `openpty'
> collect2: error: ld returned 1 exit status
| #ifdef __cplusplus
| extern "C"
| #endif
| char openpty ();
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS.  Some functions are actually named
| something starting with __ and the normal name is an alias.  */
| #if defined __stub_openpty || defined __stub___openpty
| choke me
| #endif
|
| int
| main (void)
| {
| return openpty ();
|   ;
|   return 0;
| }
...
> configure:5964: checking for openpty in -lutil
> configure:5987: g++ -o conftest -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c -lutil   >&5
> /usr/bin/ld: /tmp/ccvWpbnJ.o: in function `main':
> ./conftest.c:46: undefined reference to `openpty()'
...
| /* Override any GCC internal prototype to avoid an error.
|Use char because int might match the return type of a GCC
|builtin and then its argument prototype would still apply.  */
| char openpty ();
| int
| main (void)
| {
| return openpty ();
|   ;
|   return 0;
| }

This new error might be an Autoconf bug: the second check (with -lutil)
looks like it's missing an extern "C" on the prototype. If so,
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=b27bc3e230bb12fdd9a813e38e82bc4c3e22b4cc
might help.

smcv

Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

[Paul Flaherty]

I am wondering if we can do a transition on gnome web and also what other 
applications have been transitioned over to gnome 40 and GTK 4.

Get Outlook for iOS

From: Simon McVittie 
Sent: Sunday, September 5, 2021 7:47:10 PM
To: 992...@bugs.debian.org <992...@bugs.debian.org>
Cc: debian-gtk-gn...@lists.debian.org 
Subject: Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

Control: tags -1 - moreinfo

I think we're ready for the libmutter-8-0 / gnome-shell transition when
the release team is.

On Sat, 28 Aug 2021 at 13:52:40 +0100, Simon McVittie wrote:
> Non-transition blockers that need to be uploaded in advance:
>
> - wayland-protocols (from experimental, non-GNOME, #992857)
> - pango1.0 (from experimental)
> - gtk4 (from experimental, #992907)

wayland-protocols and pango1.0 are in testing, gtk4 should migrate today.

> Then the libmutter/gnome-shell transition when the release team are
> ready for it:
>
> - gsettings-desktop-schemas (from experimental)
> - gnome-settings-daemon
>   (from experimental, with a patch to decouple it from the libgweather
>   transition which I'm testing now)
> - gnome-control-center (from experimental)
> - mutter (from experimental)
> - gnome-shell
>   (from experimental, with a patch to decouple it from the libgweather
>   transition which I'm testing now)
> - gnome-remote-desktop (from experimental)
> - gnome-shell-extensions (from experimental)
> - budgie-desktop (non-GNOME, from experimental)

All of these are staged in experimental.

> as usual various third-party extensions will need either updating, or
> temporarily removing from testing

The ones I know about are
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fudd.debian.org%2Fcgi-bin%2Fbts-usertags.cgi%3Fuser%3Dpkg-gnome-maintainers%2540lists.alioth.debian.org%26tag%3Dgnome-shell-40data=04%7C01%7C%7Cc7ca50e1fc2e446eab5808d970c80d96%7C84df9e7fe9f640afb435%7C1%7C0%7C637664826785050179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2%2BmEHwAVaTFYaVGz%2BXf4eTfN1s8K2P3OSBgTosLLRjw%3Dreserved=0
(plus a few that I maintain myself, which are fixed in experimental already).

The closed bugs on that list are already fixed in either unstable or
experimental; the ones in experimental will just need a re-upload to unstable.

The packages with unclosed bugs on that list are likely to need temporary
removal from testing to let gnome-shell migrate. A few are probably obsolete
and will go away permanently via RM:RoM:
gnome-shell-extension-remove-dropdown-arrows is the only one I'm aware of
right now.

smcv

--
To unsubscribe, send mail to 992870-unsubscr...@bugs.debian.org.

Bug#993668: CUPS is missing after a default GNOME Desktop Install

[Holger Wansing]

Hi,

Brian Potkin  wrote (Sun, 5 Sep 2021 11:14:43 +0100):
> I have a recent bullseye installation that has only the base system.
> Therefore, I can be confident that 'apt install task-x-desktop
> will show all the packages to be installed. Only kde and cinnamon
> install the cups package.
> 
> libcups2 has shared libraries. For a working printing system it is
> essential to have the scheduler, cupsd, available, This is in the
> cups-daemon package and would be installed when cups is pulled in.

Hmm, apparently you are right.
(I was under the impression, that the libcups2 package pulls all the needed
cups packages, but I was wrong here.)

So we will need to add cups to all the *-desktop tasks probably, to
make this work again.
(Rationale: the print server task has been removed from tasksel under the
assumption, that cups is installed with all desktop environments anyway.
However, this is not true as it seems, at least not now.)


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#993751: aptitude: add a do-exactly-as-specified-mode-without-further-questions

[Christoph Anton Mitterer]

Package: aptitude
Version: 0.8.13-3
Severity: wishlist


Hi.

I couldn't find a way in the documentation to get the following done.

What's often wanted when maintaining large clusters of systems, which have
a similar (but not exactly equal) set of packages is a mode where apitude
would contine perform the selected actions if - and only if - exactly those
(and those alone) could be performed.

Imagine I want to replace package foo with a similar package bar:

aptitude install foo_ bar+

This would then required interactive input, which could of course be
avoided with --assume-yes.

The problem with --assume-yes is, that it affects all Y/N question.



Imagine that there's one package baz which stricly depends on foo.

aptitude --assume-yes install foo_ bar+

Would now also delete baz, but this is not what was specified, but
rather just a consequence of the --assume-yes.


So ideally there would be some --magic option which behaves like this:

aptitude --magic install foo_ bar+

- If nothing (pre-)depends on foo AND nothing conflicts/breaks bar => do it.
- Recommens on foo would be ignored, so even if something would Recommend it
  since exactly foo_ bar+ could be done, the Recommend doesn't count.
- I think it would not be possible to combine --magic with e.g.
  --with-recommends, --purge-unused or any other option, that would 
automatically
  change what's done in terms of changing the package status.
  But maybe, one might want to add another variant, e.g. --magic-with-installs
  which would allow any non-explicitly named installations (e.g. Dependencies
  or Recommends).
- If there would be an option, that allows removal of Essential packages, the
  logic should still apply, say if one would say:
  aptitude --allow-removing-essentials --magic install base-files_
  this would still not work, as e.g. bash, which depends on base-files would
  also needed to be removed but is not specified to be so

Also --magic should mean, that actions are only performed if *all* of them can
be done, consider:
aptitude --magic install bash foo_

If something depends on foo (and thus foo wouldn't be removed with --maigc)
bash shouldn't be performed either; neither should e.g. any installations).



Cheers,
Chris

Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

[Simon McVittie]

Control: tags -1 - moreinfo

I think we're ready for the libmutter-8-0 / gnome-shell transition when
the release team is.

On Sat, 28 Aug 2021 at 13:52:40 +0100, Simon McVittie wrote:
> Non-transition blockers that need to be uploaded in advance:
> 
> - wayland-protocols (from experimental, non-GNOME, #992857)
> - pango1.0 (from experimental)
> - gtk4 (from experimental, #992907)

wayland-protocols and pango1.0 are in testing, gtk4 should migrate today.

> Then the libmutter/gnome-shell transition when the release team are
> ready for it:
> 
> - gsettings-desktop-schemas (from experimental)
> - gnome-settings-daemon
>   (from experimental, with a patch to decouple it from the libgweather
>   transition which I'm testing now)
> - gnome-control-center (from experimental)
> - mutter (from experimental)
> - gnome-shell
>   (from experimental, with a patch to decouple it from the libgweather
>   transition which I'm testing now)
> - gnome-remote-desktop (from experimental)
> - gnome-shell-extensions (from experimental)
> - budgie-desktop (non-GNOME, from experimental)

All of these are staged in experimental.

> as usual various third-party extensions will need either updating, or
> temporarily removing from testing

The ones I know about are
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org=gnome-shell-40
(plus a few that I maintain myself, which are fixed in experimental already).

The closed bugs on that list are already fixed in either unstable or
experimental; the ones in experimental will just need a re-upload to unstable.

The packages with unclosed bugs on that list are likely to need temporary
removal from testing to let gnome-shell migrate. A few are probably obsolete
and will go away permanently via RM:RoM:
gnome-shell-extension-remove-dropdown-arrows is the only one I'm aware of
right now.

smcv

Bug#993750: rgtk2: FTBFS on s390x: smoke-test failure: caught segfault

[Simon McVittie]

Source: rgtk2
Version: 2.20.36-2
Severity: serious
Tags: ftbfs bookworm sid
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-s...@lists.debian.org
User: debian-s...@lists.debian.org
Usertags: s390x

rgtk2 failed to build on s390x when binNMU'd recently, with what appears
to be a smoke-test failure during installation:

> make[1]: Leaving directory '/<>/src'
> installing to 
> /<>/debian/r-cran-rgtk2/usr/lib/R/site-library/00LOCK-rgtk2-2.20.36/00new/RGtk2/libs
> ** R
> ** demo
> ** inst
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
> ** building package indices
> ** testing if installed package can be loaded from temporary location
> 
>  *** caught segfault ***
> address (nil), cause 'memory not mapped'
> 
> Traceback:
>  1: gtkInit(args)
>  2: fun(libname, pkgname)
>  3: doTryCatch(return(expr), name, parentenv, handler)
>  4: tryCatchOne(expr, names, parentenv, handlers[[1L]])
>  5: tryCatchList(expr, classes, parentenv, handlers)
>  6: tryCatch(fun(libname, pkgname), error = identity)
>  7: runHook(".onLoad", env, package.lib, package)
>  8: loadNamespace(package, lib.loc)
>  9: doTryCatch(return(expr), name, parentenv, handler)
> 10: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 11: tryCatchList(expr, classes, parentenv, handlers)
> 12: tryCatch({attr(package, "LibPath") <- which.lib.locns <- 
> loadNamespace(package, lib.loc)env <- attachNamespace(ns, pos = pos, 
> deps, exclude, include.only)}, error = function(e) {P <- if (!is.null(cc 
> <- conditionCall(e))) paste(" in", deparse(cc)[1L])else ""msg 
> <- gettextf("package or namespace load failed for %s%s:\n %s", 
> sQuote(package), P, conditionMessage(e))if (logical.return && !quietly)   
>   message(paste("Error:", msg), domain = NA)else stop(msg, call. = 
> FALSE, domain = NA)})
> 13: library(pkg_name, lib.loc = lib, character.only = TRUE, logical.return = 
> TRUE)
> 14: withCallingHandlers(expr, packageStartupMessage = function(c) 
> tryInvokeRestart("muffleMessage"))
> 15: suppressPackageStartupMessages(library(pkg_name, lib.loc = lib, 
> character.only = TRUE, logical.return = TRUE))
> 16: doTryCatch(return(expr), name, parentenv, handler)
> 17: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 18: tryCatchList(expr, classes, parentenv, handlers)
> 19: tryCatch(expr, error = function(e) {call <- conditionCall(e)if 
> (!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch)))   
>   call <- sys.call(-4L)dcall <- deparse(call)[1L]prefix 
> <- paste("Error in", dcall, ": ")LONG <- 75Lsm <- 
> strsplit(conditionMessage(e), "\n")[[1L]]w <- 14L + nchar(dcall, type 
> = "w") + nchar(sm[1L], type = "w")if (is.na(w)) w <- 14L 
> + nchar(dcall, type = "b") + nchar(sm[1L], type = "b")
> if (w > LONG) prefix <- paste0(prefix, "\n  ")}else 
> prefix <- "Error : "msg <- paste0(prefix, conditionMessage(e), "\n")
> .Internal(seterrmessage(msg[1L]))if (!silent && 
> isTRUE(getOption("show.error.messages"))) {cat(msg, file = outFile)   
>  .Internal(printDeferredWarnings())}invisible(structure(msg, 
> class = "try-error", condition = e))})
> 20: try(suppressPackageStartupMessages(library(pkg_name, lib.loc = lib, 
> character.only = TRUE, logical.return = TRUE)))
> 21: tools:::.test_load_package("RGtk2", 
> "/<>/debian/r-cran-rgtk2/usr/lib/R/site-library/00LOCK-rgtk2-2.20.36/00new")
> An irrecoverable exception occurred. R is aborting now ...
> Segmentation fault
> ERROR: loading failed
> * removing ‘/<>/debian/r-cran-rgtk2/usr/lib/R/site-library/RGtk2’
> dh_auto_install: error: R CMD INSTALL -l 
> /<>/debian/r-cran-rgtk2/usr/lib/R/site-library --clean . 
> "--built-timestamp='Thu, 02 Sep 2021 09:20:27 +'" returned exit code 1

Bug#981446: Possible adoption of logcheck

[Hannes von Haugwitz]

On Fri, Sep 03, 2021 at 01:46:23PM +0100, Jose M Calhariz wrote:
> For now my question is:  Who is the upstream that you are using?

There is no upstream, since logcheck is a native Debian package (see
debian/copyright for details[0]).

Best regards

Hannes

[0] https://salsa.debian.org/debian/logcheck/-/blob/master/debian/copyright

Bug#988596: akonadi-server: akonadi crashes permanently; akonadiconsole does not start

[Fab Stz]

Hello,

I had the same problem after migrating from Buster to Bullseye.

However, I remembered that in the past I moved the akonadi folder in ~/.local/
share/ to another partition and then created a symbolic link to it.

I reverted that and relocated the akonadi folder to its initial place, what 
fixed the problem for me.

I don't really know AppArmor, but I noticed that akonadiserver didn't have a 
profile in buster but has one in bullseye.

Maybe this can help someone.

Regards

On Tue, 24 Aug 2021 18:10:27 +0200 Matteo Semplice  
wrote:
> Hi.
> 
> Same issue on my machine after upgrading it to Debian 11.
> 
> The file .local/share/akonadi/Akonadi.error contains
> 
> 2021-08-24T18:02:17 [WARN ] default: Connecting to deprecated signal 
> QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
> 2021-08-24T18:04:38 [WARN ] org.kde.pim.akonadicontrol: ProcessControl: 
> Application '/usr/bin/akonadiserver' returned with exit code 253 (Errore 
> sconosciuto)
> 2021-08-24T18:05:39 [WARN ] org.kde.pim.akonadicontrol: ProcessControl: 
> Application '/usr/bin/akonadiserver' returned with exit code 253 (Errore 
> sconosciuto)
> 
> Thanks,
> 
>  Matteo
> 
> 
> 

Bug#993749: network-manager: Connecting/creating a WWAN connection fails with gnome shell js-error in journal

[Johan Kröckel]

Package: network-manager
Version: 1.30.0-2
Severity: important
X-Debbugs-Cc: johan.kroec...@gmail.com

When I click "connect" in the mobile broadband submenu the assistant for 
creating a new connection should open, but nothing happens and the journal 
shows:

Sep 06 00:50:10 X gnome-shell[1507]: JS ERROR: Error: Argument string 
may not be null
 
_packVariant@resource:///org/gnome/gjs/modules/core/overrides/GLib.js:104:29
 
_init/this.Variant._new_internal@resource:///org/gnome/gjs/modules/core/overrides/GLib.js:298:35
 
launchSettingsPanel/param<@resource:///org/gnome/shell/ui/status/network.js:88:31
 
launchSettingsPanel@resource:///org/gnome/shell/ui/status/network.js:88:22
 
_autoConnect@resource:///org/gnome/shell/ui/status/network.js:567:28
 
addAction/<@resource:///org/gnome/shell/ui/popupMenu.js:538:21
 
activate@resource:///org/gnome/shell/ui/popupMenu.js:191:14
 
vfunc_button_release_event@resource:///org/gnome/shell/ui/popupMenu.js:138:14

When I try to create the connection directly, the assistant fails at the end 
with:

Sep 06 00:55:56 X gnome-control-c[3357]: value 
"((NMSettingSerialParity) 110)" of type 'NMSettingSerialParity' is invalid or 
out of range for property 'parity' of type 'NMSettingSerialParity'
Sep 06 00:55:56 X NetworkManager[664]:   [1630882556.8868] audit: 
op="connection-add-activate" pid=3357 uid=1000 result="fail" reason="Connection 
'T-Mobile(Telekom) Vorgabe' is not available on device cdc-wdm0 because device 
is not available"
Sep 06 00:55:56 X gnome-control-c[3357]: Failed to add new connection: 
(2) Connection 'T-Mobile(Telekom) Vorgabe' is not available on device cdc-wdm0 
because device is not available

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/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager depends on:
ii  adduser  3.118
ii  dbus 1.12.20-2
ii  libaudit11:3.0-2
ii  libbluetooth35.55-3.1
ii  libc62.31-13
ii  libcurl3-gnutls  7.74.0-1.3+b1
ii  libglib2.0-0 2.66.8-1
ii  libgnutls30  3.7.1-5
ii  libjansson4  2.13.1-1.1
ii  libmm-glib0  1.14.12-0.2
ii  libndp0  1.6-1+b1
ii  libnewt0.52  0.52.21-4+b3
ii  libnm0   1.30.0-2
ii  libpsl5  0.21.0-1.2
ii  libreadline8 8.1-1
ii  libselinux1  3.1-3
ii  libsystemd0  247.3-6
ii  libteamdctl0 1.31-1
ii  libudev1 247.3-6
ii  libuuid1 2.36.1-8
ii  policykit-1  0.105-31
ii  udev 247.3-6
ii  wpasupplicant2:2.9.0-21

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  iptables 1.8.7-1
ii  libpam-systemd   247.3-6
ii  modemmanager 1.14.12-0.2
ii  ppp  2.4.9-1+1
ii  wireless-regdb   2020.04.29-2

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.3
pn  libteam-utils

-- no debconf information

Bug#980936: emacs-gtk: Warning!!! Pure space overflow !!!Warning

[Rafael Hirschfeld]

Package: emacs
Version: 1:27.1+1-3.1
Followup-For: Bug #980936
X-Debbugs-Cc: r...@unipay.nl

Dear Maintainer,

This issue was reported in bullseye testing for a previous version of
the package.  Perhaps this message is redundant but it's just to
confirm that the issue is still present in bullseye stable (for i386,
not for amd64).  Here are the contents of the emacs startup screen
showing the warning at the top and the build details at the bottom:

Warning Warning!!!  Pure space overflow!!!Warning Warning
(See the node Pure Storage in the Lisp manual for details.)
Welcome to GNU Emacs, one component of the GNU/Linux operating system.
To follow a link, click Mouse-1 on it, or move to it and type RET.
To quit a partially entered command, type Control-g.

Important Help menu items:
Emacs Tutorial  Learn basic Emacs keystroke commands
Read the Emacs Manual   View the Emacs manual using Info
(Non)Warranty   GNU Emacs comes with ABSOLUTELY NO WARRANTY
Copying Conditions  Conditions for redistributing and changing Emacs
More Manuals / Ordering Manuals  How to order printed manuals from the FSF

Useful tasks:
Visit New File  Specify a new file’s name, to edit the file
Open Home Directory Open your home directory, to operate on its files
Customize Startup   Change initialization settings including this screen

GNU Emacs 27.1 (build 1, i686-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 
1.16.0)
 of 2021-03-28, modified by Debian
Copyright (C) 2020 Free Software Foundation, Inc.


-- 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-pae (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs depends on:
ii  emacs-gtk  1:27.1+1-3.1

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#993728: Multi-user data corruption issue

[Andrew Bartlett]

I'm very sorry, this report has so little detail that it is essentially
impossible to understand.

I suggest reporting the issue upstream in any case, as only upstream
has the resources to even start investigating the issue.

You will need to share extensive details as to your configuration and
what steps may be triggering the issue.

The upstream bugzilla is at https://bugzilla.samba.org

Andrew Bartlett

-- 
Andrew Bartlett (he/him)   https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Samba Development and Support, Catalyst IT - Expert Open Source
Solutions

Bug#831274: fwsnort 1.6.8-1 and dependency to fwsnort

[Leandro Cunha]

> I see that on 2020-12-27, Leandro Cunha submitted an unstable build of 
> 1.6.8-1 and it was signed by: Adam Borowski
>
>
> Then on 2021-01-01 fwsnort 1.6.8-1 MIGRATED to testing (Debian testing watch)
>
>
> However FWSNORT has a dependency on PSAD which really needs an upgrade from 
> 2.4.3 to 2.4.6
>
>
> I’m happy to help out, but I don’t want to duplicate work on this.

Hi,

I'm going to do a study on the packaging of this new version and see
what needs to be done. Thanks.
The package has been orphaned with no maintainer activity since 2018.
I opened a bug to make it an orphan.

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.

Bug#993417: Installation failure on i386 system / Debian 11

[Craig Norborg]

That appears to have done it, about halfway through installing right now.
 Will let you know if that changes.

On Sun, Sep 5, 2021 at 7:21 AM Steve McIntyre  wrote:

> Hi again Craig!
>
> On Tue, Aug 31, 2021 at 06:51:40PM -0600, Craig Norborg wrote:
> >I used software called "Rufus".   screen cap below of the options.  Same
> exact
> >drive when I did it with Ubuntu.
>
> Hmmm, that surprises me - Rufus normally works very well with our
> images. Out of curiosity, could you please try again using "dd" mode?
> IIRC that's one of the advanced options.
>
> This *might* possibly be a hardware issue with the USB drive, but
> let's check the software options first.
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> "War does not determine who is right - only who is left."
>-- Bertrand Russell
>
>

Bug#993269: e-antic FTBFS with flint 2.8.0

[peter green]

Tags 993269 +patch
thanks

I decided to have a poke around to see if anyone else had fixed this. I 
followed the homepage link
to  e-antic FTBFS with flint 2.8.0 and noted that the "master" branch was a 
much newer release series,
but there was also a "master0" branch. Selecting that branch told me it was 
forked from and behind
flatsurf/e-antic, I'm not sure what the relationship between flatsurf and 
videlec is but I followed
the link through and had a look at the history. In said history I found there 
was a commit that
claimed to fix the build with flint 2.7, with a followup commit to make it 
conditional and allow
building with both newer and older flint.

Debian skipped from flatsurf 2.6 to 2.8 so I figured a fix for flatsurf 2.7 may 
also work for
flatsurf 2.8 or at least reduce the number of errors. I applied the commits to 
the Debian package
and they did indeed fix the build.

Debdiff is attatched. I am about to go upload this to raspbian, I don't have 
any current plans to
NMU this in Debian.
diff -Nru e-antic-0.1.8+ds/debian/changelog e-antic-0.1.8+ds/debian/changelog
--- e-antic-0.1.8+ds/debian/changelog   2021-02-21 14:17:56.0 +
+++ e-antic-0.1.8+ds/debian/changelog   2021-09-05 22:14:10.0 +
@@ -1,3 +1,11 @@
+e-antic (0.1.8+ds-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patches from https://github.com/flatsurf/e-antic/commits/master0
+for flint 2.7 and above.
+
+ -- Peter Michael Green   Sun, 05 Sep 2021 22:14:10 +
+
 e-antic (0.1.8+ds-1) unstable; urgency=medium
 
   * Debianization:
diff -Nru e-antic-0.1.8+ds/debian/patches/flint-2.7-conditional.patch 
e-antic-0.1.8+ds/debian/patches/flint-2.7-conditional.patch
--- e-antic-0.1.8+ds/debian/patches/flint-2.7-conditional.patch 1970-01-01 
00:00:00.0 +
+++ e-antic-0.1.8+ds/debian/patches/flint-2.7-conditional.patch 2021-09-05 
22:13:03.0 +
@@ -0,0 +1,356 @@
+commit 5337ecb9715f26a78fbef53fe0aef5e6d2cb3a88
+Author: Matthias Koeppe 
+Date:   Tue Feb 23 08:31:35 2021 -0800
+
+Conditionalize changes on __FLINT_RELEASE >= 20700
+
+diff --git a/e-antic/nf_elem.h b/e-antic/nf_elem.h
+index 570b537..e15c544 100644
+--- a/e-antic/nf_elem.h
 b/e-antic/nf_elem.h
+@@ -580,13 +580,25 @@ FLINT_DLL
+ void nf_elem_get_nmod_poly(nmod_poly_t pol, const nf_elem_t a, const nf_t nf);
+ 
+ FLINT_DLL
++#if (__FLINT_RELEASE >= 20700)
+ void _nf_elem_get_fmpz_mod_poly(fmpz_mod_poly_t pol, const nf_elem_t a, const 
nf_t nf, const fmpz_mod_ctx_t ctx);
++#else
++void _nf_elem_get_fmpz_mod_poly(fmpz_mod_poly_t pol, const nf_elem_t a, const 
nf_t nf);
++#endif
+ 
+ FLINT_DLL
++#if (__FLINT_RELEASE >= 20700)
+ void nf_elem_get_fmpz_mod_poly_den(fmpz_mod_poly_t pol, const nf_elem_t a, 
const nf_t nf, int den, const fmpz_mod_ctx_t ctx);
++#else
++void nf_elem_get_fmpz_mod_poly_den(fmpz_mod_poly_t pol, const nf_elem_t a, 
const nf_t nf, int den);
++#endif
+ 
+ FLINT_DLL
++#if (__FLINT_RELEASE >= 20700)
+ void nf_elem_get_fmpz_mod_poly(fmpz_mod_poly_t pol, const nf_elem_t a, const 
nf_t nf, const fmpz_mod_ctx_t ctx);
++#else
++void nf_elem_get_fmpz_mod_poly(fmpz_mod_poly_t pol, const nf_elem_t a, const 
nf_t nf);
++#endif
+ 
+ 
/**
+  
+diff --git a/nf_elem/get_fmpz_mod_poly.c b/nf_elem/get_fmpz_mod_poly.c
+index eba9c64..b55c5bb 100644
+--- a/nf_elem/get_fmpz_mod_poly.c
 b/nf_elem/get_fmpz_mod_poly.c
+@@ -25,68 +25,124 @@
+ 
+ #include "e-antic/nf_elem.h"
+ 
++#if (__FLINT_RELEASE >= 20700)
+ void _nf_elem_get_fmpz_mod_poly(fmpz_mod_poly_t pol, const nf_elem_t a,
+const nf_t nf, const fmpz_mod_ctx_t 
ctx)
++#else
++void _nf_elem_get_fmpz_mod_poly(fmpz_mod_poly_t pol, const nf_elem_t a, const 
nf_t nf)
++#endif
+ {
+ if (nf_elem_is_zero(a, nf))
+ {
++#if (__FLINT_RELEASE >= 20700)
+ fmpz_mod_poly_zero(pol, ctx);
+ 
++#else
++fmpz_mod_poly_zero(pol);
++#endif
+ return;
+ }
+ if (nf->flag & NF_LINEAR)
+ {
+ {
++#if (__FLINT_RELEASE >= 20700)
+ fmpz_mod_poly_fit_length(pol, 1, ctx);
+ 
+ fmpz_mod(pol->coeffs + 0, LNF_ELEM_NUMREF(a), ctx->n);
+ 
++#else
++fmpz_mod_poly_fit_length(pol, 1);
++fmpz_mod(pol->coeffs + 0, LNF_ELEM_NUMREF(a), &(pol->p));
++#endif
+ _fmpz_mod_poly_set_length(pol, 1);
+ _fmpz_mod_poly_normalise(pol);
+ 
+ }
+ } else if (nf->flag & NF_QUADRATIC)
+ {
++#if (__FLINT_RELEASE >= 20700)
+ fmpz_mod_poly_fit_length(pol, 3, ctx);
+ 
+ fmpz_mod(pol->coeffs + 0, QNF_ELEM_NUMREF(a), ctx->n);
+ fmpz_mod(pol->coeffs + 1, QNF_ELEM_NUMREF(a) + 1, ctx->n);
+ fmpz_mod(pol->coeffs + 2, QNF_ELEM_NUMREF(a) + 2, ctx->n);
+ 
++#else
++fmpz_mod_poly_fit_length(pol, 3);
++fmpz_mod(pol->coeffs + 0, QNF_ELEM_NUMREF(a), &(pol->p));
++

Bug#992790: Is this fixed in kernel version 5.13?

[Dave Rubie]

One more data point on this issue with this old HP Proliant ML330 G6 - 
installing the Liquorix kernel 5.13.0-14.1-liquorix-amd64 fixed it, the machine 
now boots without having to drop back to the 4.19 kernel.

Bug#993748: rkhunter: patch for /etc/apt.conf.d/90rkhunter

[Richard Lewis]

Package: rkhunter
Version: 1.4.6-9
Severity: normal
Tags: patch

Dear Maintainer,

Please consider the attached patch for
  /etc/apt/apt.conf.d/90rkhunter

It adds || true to ensure apt completes its
actions even if there are problems running
rkhunter. 

I had such issues when 
upgrading from buster to bullseye because
the default /etc/rkhunter.conf
has a SCRIPTWHITELIST that assumes grep is in 
/usr/bin -- this is not true on a system without
usrmerge

Thanks for considering

-- 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/1 CPU thread)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rkhunter depends on:
ii  binutils   2.35.2-2
ii  debconf [debconf-2.0]  1.5.77
ii  file   1:5.39-3
ii  lsof   4.93.2+dfsg-1.1
ii  net-tools  1.60+git20181103.0eebece-1
ii  perl   5.32.1-4+deb11u1
ii  ucf3.0043

Versions of packages rkhunter recommends:
ii  curl   7.74.0-1.3+b1
ii  e2fsprogs  1.46.2-2
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  iproute2   5.10.0-4
ii  mailutils [mailx]  1:3.10-3+b1
ii  unhide 20130526-4
ii  unhide.rb  22-5
ii  wget   1.21-1+b1

Versions of packages rkhunter suggests:
ii  liburi-perl 5.08-1
ii  libwww-perl 6.52-1
pn  powermgmt-base  

-- Configuration Files:
/etc/apt/apt.conf.d/90rkhunter changed [not included]
/etc/logcheck/ignore.d.server/rkhunter [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/rkhunter'
/etc/rkhunter.conf changed [not included]

-- debconf information:
* rkhunter/apt_autogen: true
* rkhunter/cron_daily_run: true
* rkhunter/cron_db_update: false
--- apt.conf.d__90rkhunter.orig 2021-09-05 22:56:18.992369673 +0100
+++ apt.conf.d__90rkhunter.new  2021-09-05 22:55:59.400391786 +0100
@@ -1,2 +1,2 @@
 // Makes sure that rkhunter file properties database is updated after each 
remove or install only APT_AUTOGEN is enabled
-DPkg::Post-Invoke { "if [ -x /usr/bin/rkhunter ] && grep -qiE 
'^APT_AUTOGEN=.?(true|yes)' /etc/default/rkhunter; then 
/usr/share/rkhunter/scripts/rkhupd.sh; fi"; };
+DPkg::Post-Invoke { "if [ -x /usr/bin/rkhunter ] && grep -qiE 
'^APT_AUTOGEN=.?(true|yes)' /etc/default/rkhunter; then 
/usr/share/rkhunter/scripts/rkhupd.sh || true; fi"; };

Bug#993394: transition: glibc 2.32

[Aurelien Jarno]

Hi Sebastian,

On 2021-09-05 19:15, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/glibc-2.32.html
> 
> On 2021-09-02 22:11:50 +0200, Aurelien Jarno wrote:
> > On 2021-08-31 20:54, Aurelien Jarno wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > X-Debbugs-Cc: debian-gl...@lists.debian.org
> > > 
> > > Dear release team,
> > > 
> > > I would like to get a transition slot for glibc 2.32. It has been built
> > > successfully on all release architectures except mips*el, however I have
> > > successfully built them manually on eller.d.o. It also builds fine on most
> > > ports architectures.
> > 
> > It has been finally built on mipsel and mips64el, successfully.
> 
> Please go ahead.

Thanks, I have just uploaded it.

Cheers,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#993747: network-manager-gnome: only Recommend network-manager

[Christoph Anton Mitterer]

Package: network-manager-gnome
Version: 1.24.0-1
Severity: wishlist



Hi.

AFAIU network-manager-gnome is just the GUI applet for controlling NM, and it
seems to work just fine without network-manager itself (well it simply cannot
do anything, but does so gracefully).


Would it be possible to only Recommend network-manager instead of Depending on
it?

That would allow to install minimum desktop enviornments on systems where e.g.
there is normally no networking and where pulling in all dependencies of NM 
itself
makes not much sense.


A desktop environment that still wants to make sure that NM is installed could
depend on it in one of it's higher levelpackages (e.g. like from gnome or
cinnamon-desktop-environment)

Cheers,
Chris.

Bug#993738: systemd: same problem with multiple patition with same partlabel

[Huf]

Package: systemd
Version: 247.3-6
Followup-For: Bug #993738

Dear Maintainer,

Looks like i was hit by simillar problem following upgrade from buster to 
bullseye.
Symptom : several LVM logical volume are not started at boot time,
entering emergency shell, waiting few minutes, and doing "mount -a" allow to 
boot
quite strange...

"journalctl -xb" log was full of : systemd-udev device Failed to update device 
symlinks: Too many levels of symbolic links

After investigation, problem was cause by having 80+ GPT partitions with same 
partlabel :-)
causing, a least, problems to populate /dev/disk/by-partlabel directory
(partlabel was not needed, an error longtime ago in script creating GPT 
partition caused this)
Removing/clearing partlabel for all partition with command like "sgdisk -c42:"" 
/dev/sdd" solve the issue

Don't know if it's a bug, but in buster the machine booted fine, it's more like 
a regretion
Not sure a lot of user have 80+ partitions with same partlabel, hope this 
message can help them :-)

Thanks guys for maintaining Debian,
Have a nice day,


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser3.118
ii  libacl12.2.53-10
ii  libapparmor1   2.13.6-10
ii  libaudit1  1:3.0-2
ii  libblkid1  2.36.1-8
ii  libc6  2.31-13
ii  libcap21:2.44-1
ii  libcrypt1  1:4.4.18-4
ii  libcryptsetup122:2.3.5-1
ii  libgcrypt201.8.7-6
ii  libgnutls303.7.1-5
ii  libgpg-error0  1.38-2
ii  libip4tc2  1.8.7-1
ii  libkmod2   28-1
ii  liblz4-1   1.9.3-2
ii  liblzma5   5.2.5-2
ii  libmount1  2.36.1-8
ii  libpam0g   1.4.0-9
ii  libseccomp22.5.1-1
ii  libselinux13.1-3
ii  libsystemd0247.3-6
ii  libzstd1   1.4.8+dfsg-2.1
ii  mount  2.36.1-8
ii  ntp [time-daemon]  1:4.2.8p15+dfsg-1
ii  util-linux 2.36.1-8

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-10.105-31
ii  systemd-container  247.3-6

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   247.3-6
ii  libpam-systemd   247.3-6
ii  udev 247.3-6

-- no debconf information

Bug#993746: python3-django-postorius: CVE-2021-40347 New upstream to fix security bug

[Peter Chubb]

Package: python3-django-postorius
Version: 1.3.4-2
Severity: important
Tags: upstream

Dear Maintainer,

There is a new upstream (and patches to this version) available, to address 
security issue CVE-2021-40347.  This vulnerability allows any logged-in-user
to unsubscribe any user from any list.

Version 1.3.5 fixes the issue; plus a patch was posted to the 
mailman3 mailing list.



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

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

Versions of packages python3-django-postorius depends on:
ii  fonts-glyphicons-halflings  1.009~3.4.1+dfsg-2
ii  libjs-bootstrap44.5.2+dfsg1-8
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-sphinxdoc 3.5.4-2
ii  node-html5shiv  3.7.3+dfsg-3
ii  python3 3.9.2-3
ii  python3-cmarkgfm0.4.2-1+b3
ii  python3-django  2:2.2.24-1
ii  python3-django-mailman3 1.3.5-2
ii  python3-mailmanclient   3.3.2-1
ii  python3-readme-renderer 24.0-3
ii  sphinx-rtd-theme-common 0.5.1+dfsg-1

Versions of packages python3-django-postorius recommends:
ii  mailman3-web  0+20200530-2

python3-django-postorius suggests no packages.

-- no debconf information

Bug#993745: O: psad -- Designed to work with iptables to detect port scans

[Leandro Cunha]

Package: wnpp
Severity: normal

Hi,

I communicate that due to the inactivity since 2018 in the psad package,
I am orphaning this package and in this case the QA group becomes the
maintainer. If you are still interested in working on this package, please
respond to this bug, which I can close. Thanks for the work.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#993743: xdemorse: autopkgtest regression: warning on stderr

[Simon McVittie]

On Sun, 05 Sep 2021 at 21:57:18 +0200, Paul Gevers wrote:
> (xdemorse:3992): dbind-WARNING **: 01:17:04.875: AT-SPI: Error
> retrieving accessibility bus address:
> org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not
> provided by any .service files

To avoid this warning, either depend on at-spi2-core (if you need
accessibility technologies), or export NO_AT_BRIDGE=1 (if you don't need
accessibility technologies and just want to silence the warning).

The gtk+3.0 source package currently has examples of both methods in its
autopkgtests. The installed-tests depend on at-spi2-core (some of them use
accessibility interfaces to remote-control a GTK app, I think), and the
superficial python3-gi test sets NO_AT_BRIDGE=1.

smcv

Bug#993744: ibus-client-clutter FTCBFS: generates a syntax error in the glib dependency

[Helmut Grohne]

Source: ibus-client-clutter
Version: 0.0+git20090728.a936bacf-7
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ibus-client-clutter fails to cross build from source, because it
generates an invalid dependency on glib. The libglib2.0-0 package
happens to have two instances during cross builds, so the query in
debian/rules constructs the dependency twice without separating them
with a comma. The attached patch restricts it to only the host
architecture instance and makes ibus-client-clutter cross buildable.
Please consider applying it.

Helmut
diff --minimal -Nru 
ibus-client-clutter-0.0+git20090728.a936bacf/debian/changelog 
ibus-client-clutter-0.0+git20090728.a936bacf/debian/changelog
--- ibus-client-clutter-0.0+git20090728.a936bacf/debian/changelog   
2021-03-27 12:33:11.0 +0100
+++ ibus-client-clutter-0.0+git20090728.a936bacf/debian/changelog   
2021-09-05 20:56:46.0 +0200
@@ -1,3 +1,10 @@
+ibus-client-clutter (0.0+git20090728.a936bacf-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Fix glib dependency syntax. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 05 Sep 2021 20:56:46 +0200
+
 ibus-client-clutter (0.0+git20090728.a936bacf-7) unstable; urgency=medium
 
   [ Andreas Beckmann  ]
diff --minimal -Nru ibus-client-clutter-0.0+git20090728.a936bacf/debian/rules 
ibus-client-clutter-0.0+git20090728.a936bacf/debian/rules
--- ibus-client-clutter-0.0+git20090728.a936bacf/debian/rules   2021-03-27 
12:26:39.0 +0100
+++ ibus-client-clutter-0.0+git20090728.a936bacf/debian/rules   2021-09-05 
20:56:44.0 +0200
@@ -4,6 +4,7 @@
 DEB_VERSION := $(shell dpkg-parsechangelog | grep Version: | sed -e 
's/Version: //')
 DEB_UPSTREAM_VERSION := $(shell echo $(DEB_VERSION) | sed -e 's/-[^-]*$$//')
 
+include /usr/share/dpkg/architecture.mk
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/rules/autoreconf.mk
@@ -14,7 +15,7 @@
 DEB_CONFIGURE_EXTRA_FLAGS += --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)\
 
 # tighten libglib2.0-0 dependency due to glib_check_version() usage (#985453)
-DEB_DH_GENCONTROL_ARGS_ibus-clutter = -- -V'glib:Depends=$(shell dpkg-query -f 
'$${package} (>= $${source:Upstream-Version})' -W libglib2.0-0)'
+DEB_DH_GENCONTROL_ARGS_ibus-clutter = -- -V'glib:Depends=$(shell dpkg-query -f 
'$${package} (>= $${source:Upstream-Version})' -W 
'libglib2.0-0:${DEB_HOST_ARCH}')'
 
 GIT_URL = git://git.moblin.org/ibus-client-clutter
 

Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye

[Rob Leslie]

I also encountered this.

My working hypothesis is that it may be related to this (from README.Debian):

> Since version 1.6-6 we support multiple stanzas of the interface usefull,
> for example, to describe the IPv4 and IPv6 addresses of an interface. The
> only requirement for this is that all of them need to have bridge_ports
> specified.

Could you try duplicating the bridge_ports in the inet6 stanza and see if that 
eliminates the problem?

Alternatively, perhaps adding dad-attempts 0 would work.

I have not yet been able to try either remedy. Please let me know if one of 
them helps.

-- 
Rob Leslie
r...@mars.org

Bug#993728: Acknowledgement (Fwd:)

[Jimmy Parr]

same problem also occurs on opening database.mdb with multiple user

Le dim. 5 sept. 2021, à 11 h 33, Debian Bug Tracking System <
ow...@bugs.debian.org> a écrit :

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 993728:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993728.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Samba Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 993...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 993728: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993728
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#993743: xdemorse: autopkgtest regression: warning on stderr

[Paul Gevers]

Source: xdemorse
Version: 3.6.4-1
X-Debbugs-CC: debian...@lists.debian.org, mo...@debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
xdemorse   from testing3.6.4-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looking at the
actual test, I wonder how useful it is. There was a discussion somewhere
recently about xvfb and maybe also about ending with "&", but I forgot
the details. It may be that the test can't fail (apart from output to
stderr, which is exactly what's happening here).

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? I think dropping the
test until something more sensible comes up makes sense. At the very
least, it also needs to be tagged as superficial, as documented in the
release policy [2]

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

Paul

[1] https://qa.debian.org/excuses.php?package=xdemorse
[2] https://release.debian.org/testing/rc_policy.txt section 6(a)

https://ci.debian.net/data/autopkgtest/testing/amd64/x/xdemorse/15038359/log.gz

autopkgtest [01:17:04]: test command1: xvfb-run -a xdemorse -v
autopkgtest [01:17:04]: test command1: [---

(xdemorse:3992): dbind-WARNING **: 01:17:04.875: AT-SPI: Error
retrieving accessibility bus address:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not
provided by any .service files
xdemorse 3.6.4
autopkgtest [01:17:05]: test command1: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993742: gtklp: Missing file name in "Files to print" dialog

[Olivier Berger]

Package: gtklp
Version: 1.3.1-1+b1
Severity: normal

Dear Maintainer,

When passing gtklp a file to print as an argument, like :
LANG=C /usr/bin/gtklp -Pprinter /tmp/prspool-nKRHaT.ps
the file seems to be in the first tab's widget "Files to print", but
with an empty label. One may select the line, but the list appears to be
empty. This quite misleading as it looks like the file provided as an
argument to te invocation isn't recognized.

Hope this helps,

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

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

Versions of packages gtklp depends on:
ii  libc62.31-17
ii  libcups2 2.3.3op2-6
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.68.4-1
ii  libgtk2.0-0  2.24.33-2
ii  libx11-6 2:1.7.2-1

Versions of packages gtklp recommends:
ii  sensible-utils  0.0.17

gtklp suggests no packages.

-- debconf-show failed

-- 
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#993741: cloud.debian.org: Support IPv6 endpoints for AWS NTP, DNS, and instance metadata

[Noah Meyerhans]

Package: cloud.debian.org
Severity: wishlist
User: cloud.debian@packages.debian.org
Usertags: aws image


AWS has recently announced that VPC-internal services are available via
IPv6.  In order to facilitate deployments that don't configure IPv4
addresses, we should enable support for accessing these services over IPv6.

We'll need to continue to support IPv4 access as well, as the feature is
only available to Nitro-based instances, and some users will disable IPv6
even when it is available.

https://aws.amazon.com/about-aws/whats-new/2021/08/Ipv6-amazon-ec2-metadata-time-sync-vpc-dns/

Bug#993252: Astroquery doesn't work with Astropy 4.3.1

[vivi]

Hi,

I recently tried to update astroquery.
Indeed, version 0.4.3 solves the issue, but it introduces another bug
that prevents uploading.
I reported it upstream.
Patching the current version would probably be more efficient than
waiting for upstream to fix the new bug.
Is there any replacement for the missing import?

Best regards,
Vincent

Le 05/09/2021 à 20:23, Nilesh Patra a écrit :
> On Sun, 29 Aug 2021 13:08:57 +0200 Ole Streicher  wrote:
>> Package: python3-astroquery
>> Version: 0.4.1+dfsg-4
>> Severity: serious
>>
>> Dear maintainer,
>>
>> The unit tests of astrquery errors with astropy version 4.3.1 which is
>> currently in unstable. Could you please update astroquery to the latest
>> version 0.4.3, which should resolve this?
>>
>> A test log is here:
>>
>> https://ci.debian.net/data/autopkgtest/testing/amd64/a/astroquery/14913971/log.gz
> Hi Vincent,
>
> Can I ask you to fix this soonish? Probably a low hanging fruit, but
> this is unfortunately blocking transition of new astropy to testing.
>
> Nilesh

Bug#993728: Fwd:

[Jimmy Parr]

Package: Samba
Version: 2:4.13.5+dfsg-2

Linux serveur-belcher 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4
(2021-08-03) x86_64 GNU/Linux

more than 20 server

the same problem happens when multiple users doing accounting(acomba
software acceo solution, similar to sage) kind of self database system
!

at a certain time ! data corruption starts to begin, and everything breaks.

could not find any log file of any sort to explain
even with full audit.


ive been  running on samba since jessy. never see an outstanding bug like this !

had to create back all my servers to debian 10 and everything went
back to normal.

regards

Bug#993726: RFS: vnstat/2.8-1 -- console-based network traffic monitor

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "vnstat":

 * Package name: vnstat
   Version : 2.8-1
   Upstream Author : Teemu Toivola 
 * URL : https://humdi.net/vnstat/
 * License : GPL-any, GPL-2
 * Vcs : https://salsa.debian.org/debian/vnstat
   Section : net

It builds those binary packages:

  vnstati - image output support for vnStat
  vnstat - console-based network traffic monitor

To access further information about this package, please visit the
following URL:

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

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_2.8-1.dsc

Changes since the last upload:

 vnstat (2.8-1) unstable; urgency=medium
 .
   * New upstream version 2.8
 .
   * d/patches: rebase and drop upstream applied ones
   * d/control: bump to std version 4.6.0 (no further changes)

Regards,
 Christian Göttsche

Bug#993727:

[Jimmy Parr]

Package: Samba
Version: 2:4.13.5+dfsg-2

Merci
Bonne Journée

Jimmy Parr
Technicien Senior
Arcsys Industries
418-573-6434 : Cellulaire
418-681-1219 Poste: 101

---

AVIS IMPORTANT : Cette transmission électronique est strictement
réservée à l'usage de la (des) personne(s) à qui elle est adressée
et contient des informations privilégiées et confidentielles. Toute
divulgation, distribution, copie, ou autre utilisation de cette
transmission par une autre personne est strictement prohibée. Si vous
avez reçu ce courriel par erreur, veuillez s'il vous plaît en aviser
immédiatement l'expéditeur par courriel et détruire tout exemplaire
ou copie de la transmission originale.

WARNING: This electronic transmission contains confidential information,
intended only for the person(s) named above, and is privileged. If you
are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or any other use of this email is
strictly prohibited. If you have received this transmission by error,
please notify us immediately by return email and destroy the original
transmission immediately and all copies thereof.

---

Bug#992956: bullseye-pu: package modsecurity-crs/3.3.0-1

[Salvatore Bonaccorso]

Hi Adam,

On Sat, Sep 04, 2021 at 03:17:25PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2021-08-25 at 16:55 +0200, Alberto Gonzalez Iniesta wrote:
> > This [1] security bug was found in modsecurity-crs.
> > As stated in #992863 by the security team, a DSA won't be issued
> > (security team on Cc:) so I'm targeting bullseye proposed updates
> > instead.
> > 
> 
> >From reading #992863 and checking the Security Tracker, it appears that
> the issue is already fixed in unstable. However, that fact is not
> reflected in the BTS. Assuming that I haven't missed anything, please
> add an appropriate fixed version to #992863 and go ahead.

Looks that
https://tracker.debian.org/news/1251194/accepted-modsecurity-crs-332-1-source-into-unstable/
did contain a typo for the bug number so got not closed automatically,
I send a BTS command accordingly.

Regards,
Salvatore

Bug#993725: cryptsetup-initramfs: LV activation disregards activation/auto_activation_volume_list setting

[Guilhem Moulin]

Control: tag -1 - moreinfo
Control: severity -1 minor

On Sun, 05 Sep 2021 at 20:13:03 +0200, Lukas Schwaighofer wrote:
> On Sun, 5 Sep 2021 17:04:06 +0200 Guilhem Moulin  wrote:
> Without the suggested patch it's impossible to prevent some LVs that
> share the same volume group as e.g. the root partition from being
> activated automatically. Concretely I was trying to work around a
> different bug [1] by avoiding automatically opening some LVs using the
> `auto_activation_volume_list` option in the lvm.conf. I was surprised
> to still see all my LVs activated (and thus the bug triggered,
> rendering my system unbootable).
> 
> Indeed, if somebody changed their `auto_activation_volume_list` to not
> contain the necessary partitions during boot, that would render their
> system unbootable.  I believe this is the correct behavior, and this
> would also happen in a pure LVM setup since the script from the LVM2
> package uses the `-a ay` flag [2].

I see, thanks for the details.  Makes sense to mimic what the lvm2
folks are doing since we're trying to workaround initramfs-tools lacks
of expressiveness here and ideally would defer everything to
lvm2-provided logic.

I've lowered the severity as I don't think this issue warrants
‘Severity: important’, but will probably merge this as is — we're early
enough in the release cycle to try potentially disruptive changes :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#993740: /etc/cron.weekly/man2html: this version of `which' is deprecated

[Bob Proulx]

Package: man2html
Version: 1.6g-14
Severity: normal

The recent change to "which" now cascades to this weekly message.

From: Cron Daemon
To: root
Subject: Cron  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.weekly )

/etc/cron.weekly/man2html:
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.

The problematic script line is this one.

[ -d "$CACHEDIR" ] && which index++ >/dev/null || exit 0

Thank you for maintaining man2html.

Bob


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

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

Versions of packages man2html depends on:
ii  apache2 [httpd-cgi]  2.4.48-4
ii  debconf [debconf-2.0]1.5.77
ii  gawk 1:5.1.0-1
ii  libc62.31-17
ii  lynx 2.9.0dev.9-2
it  man-db   2.9.4-2
ii  man2html-base1.6g-14
ii  nginx-light [httpd-cgi]  1.18.0-6.1
ii  sensible-utils   0.0.17

man2html recommends no packages.

Versions of packages man2html suggests:
ii  chromium [www-browser] 90.0.4430.212-1
ii  dwb [www-browser]  20150419git-2+b1
ii  elinks [www-browser]   0.13.2-1+b2
ii  firefox [www-browser]  88.0.1-1
ii  firefox-esr [www-browser]  78.13.0esr-1
ii  links [www-browser]2.23-1
ii  links2 [www-browser]   2.23-1
ii  lynx [www-browser] 2.9.0dev.9-2
ii  midori [www-browser]   7.0-2.1+b1
pn  swish++
ii  w3m [www-browser]  0.5.3+git20210102-6

-- debconf information:
  man2html/index_manpages: true

Bug#993714: conffile which got removed during upgrade reported missing

[Axel Beckert]

Hi Florian,

Florian Schlichting wrote:
> On Sun, Sep 05, 2021 at 01:19:44PM +0200, Evangelos Ribeiro Tzaras wrote:
> > Is this behaviour expected? Could it be that the new `remove-on-upgrade`
> > feature added to dpkg in 1.20.9 is not (yet) understood by debsums?
> 
> this.

Yep.

> I think this is similar to conffiles marked "obsolete" (cf.
> #689508),

Probably.

> and I've just pushed a one-line patch to ignore all lines containing the
> remove-on-upgrade flag. However I'd prefer if somebody else has a look
> to confirm this solution,

Will do.

> (Axel, you must have looked into this when developing the "obsolete"
> fix?)

Actually Andreas Beckmann came up with that and I just fine-tuned
things a bit.

But that was back in 2017 while remove-on-upgrade is really, really
new. Actually it got introduced just very shortly before the soft
freeze for Bullseye when IIRC the toolchain freeze (December 2020,
right?) actually was already through if I read dpkg's changelog
correctly. *sigh*

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#992170: How to test a stable package in sid

[David W. Kennedy]

Hello Robbi,

It is possible to test a stable package in Debian sid. You can create a 
minimal debootstrap of the stable distribution, then chroot to it and 
install the 0ad-data/bullseye package. Here are example commands for 
this. I don't think that it is strictly required that you do this in 
order to close the bug report, but if you want to be extra thorough then 
you can do this before closing the report. There is a remote possibility 
that there is a bug in 0ad-data triggered by obscure hardware. Commands 
preceded by a # indicate that you should run them as root or with sudo.


# apt-get install debootstrap
# mkdir /bullseye
# debootstrap  bullseye /bullseye https://deb.debian.org/debian
# chroot /bullseye
# apt-get update

Note that if networking isn't working in the chroot then you likely need 
to configure the DNS resolver, such as in /etc/resolv.conf.


# apt-get upgrade
# apt-get install 0ad-data/bullseye 0ad-data-common/bullseye 
0ad/bullseye


When it finishes, you can exit the chroot by typing exit or pressing 
Ctrl-D.


# exit

--
Dave Kennedy

Bug#993738: udev: symlink creation race condition can cause log delays

[Lukas Schwaighofer]

Hi,

> Thanks for finding that! I'll report back once I've had a chance to
> try this.

The attached PR is quite large and I wasn't able to apply it against
the version now in bullseye, and I don't want to change to a different
systemd/udev altogether. Carefully reading the descriptions I'm
confident that this is indeed the same issue. I have a workaround in
place now that doesn't have any drawbacks for me. I'll just stick with
that for now.

Thanks for your help
Lukas


pgpki4K5ItXCE.pgp
Description: OpenPGP digital signature

Bug#992777: linux-image-5.10.0-0.bpo.8-amd64: does not raise ethernet interface Intel Corporation 82579LM Gigabit Network Connection (rev 04)

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Axel,

On Mon, Aug 23, 2021 at 12:01:33PM +0200, Axel Stammler wrote:
> Package: src:linux
> Version: 5.10.46-4~bpo10+1
> Severity: normal
> 
> Dear Maintainer,
> 
> the interface is not raised and made available during boot.
> 
> -- Package-specific info:
> ** Version:
> Linux version 5.10.0-0.bpo.8-amd64 (debian-ker...@lists.debian.org) (gcc-8 
> (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP 
> Debian 5.10.46-4~bpo10+1 (2021-08-07)
> 
> ** Command line:
> BOOT_IMAGE=/boot/vmlinuz-5.10.0-0.bpo.8-amd64 
> root=UUID=5e13c7af-0eae-48cf-a0f1-4d495df46174 ro quiet
> 
> ** Tainted: W (512)
>  * kernel issued warning
> 
> ** Kernel log:
> [ 1426.043900] wlp3s0: send auth to b6:fb:e4:11:b9:3a (try 1/3)
> [ 1426.045809] wlp3s0: authenticated
> [ 1426.045958] wlp3s0: waiting for beacon from b6:fb:e4:11:b9:3a
> [ 1426.095675] wlp3s0: associate with b6:fb:e4:11:b9:3a (try 1/3)
> [ 1426.100495] wlp3s0: RX AssocResp from b6:fb:e4:11:b9:3a (capab=0x411 
> status=0 aid=1)
> [ 1426.120394] wlp3s0: associated
> [ 1646.156714] wlp3s0: authenticate with 82:2a:a8:c4:d8:3f
> [ 1646.161660] wlp3s0: send auth to 82:2a:a8:c4:d8:3f (try 1/3)
> [ 1646.184047] wlp3s0: authenticated
> [ 1646.184305] wlp3s0: waiting for beacon from 82:2a:a8:c4:d8:3f
> [ 1646.261469] wlp3s0: associate with 82:2a:a8:c4:d8:3f (try 1/3)
> [ 1646.322977] wlp3s0: RX AssocResp from 82:2a:a8:c4:d8:3f (capab=0x431 
> status=0 aid=2)
> [ 1646.348257] wlp3s0: associated
> [ 2034.439690] wlp3s0: authenticate with 82:2a:a8:c4:da:9f
> [ 2034.442957] wlp3s0: send auth to 82:2a:a8:c4:da:9f (try 1/3)
> [ 2034.448467] wlp3s0: authenticated
> [ 2034.448834] wlp3s0: waiting for beacon from 82:2a:a8:c4:da:9f
> [ 2037.843522] wlp3s0: authenticate with 82:2a:a8:c4:da:9f
> [ 2037.844744] wlp3s0: send auth to 82:2a:a8:c4:da:9f (try 1/3)
> [ 2037.849092] wlp3s0: authenticated
> [ 2037.849276] wlp3s0: waiting for beacon from 82:2a:a8:c4:da:9f
> [ 2037.912078] wlp3s0: associate with 82:2a:a8:c4:da:9f (try 1/3)
> [ 2037.919600] wlp3s0: RX AssocResp from 82:2a:a8:c4:da:9f (capab=0x431 
> status=0 aid=7)
> [ 2037.939599] wlp3s0: associated
> [ 2078.130483] wlp3s0: authenticate with 82:2a:a8:c5:d8:3f
> [ 2078.133998] wlp3s0: send auth to 82:2a:a8:c5:d8:3f (try 1/3)
> [ 2078.734997] wlp3s0: send auth to 82:2a:a8:c5:d8:3f (try 2/3)
> [ 2079.013622] wlp3s0: authenticated
> [ 2079.014112] wlp3s0: waiting for beacon from 82:2a:a8:c5:d8:3f
> [ 2080.225612] wlp3s0: authenticate with 82:2a:a8:c4:d8:3f
> [ 2080.228623] wlp3s0: send auth to 82:2a:a8:c4:d8:3f (try 1/3)
> [ 2080.234710] wlp3s0: authenticated
> [ 2080.238894] wlp3s0: associate with 82:2a:a8:c4:d8:3f (try 1/3)
> [ 2080.249005] wlp3s0: RX AssocResp from 82:2a:a8:c4:d8:3f (capab=0x431 
> status=0 aid=1)
> [ 2080.274519] wlp3s0: associated
> [ 2157.833470] wlp3s0: disconnect from AP 82:2a:a8:c4:d8:3f for new auth to 
> 82:2a:a8:c5:d8:3f
> [ 2157.853439] wlp3s0: authenticate with 82:2a:a8:c5:d8:3f
> [ 2157.857903] wlp3s0: send auth to 82:2a:a8:c5:d8:3f (try 1/3)
> [ 2158.273464] wlp3s0: send auth to 82:2a:a8:c5:d8:3f (try 2/3)
> [ 2158.282471] wlp3s0: send auth to 82:2a:a8:c5:d8:3f (try 3/3)
> [ 2158.285650] wlp3s0: authenticated
> [ 2158.289499] wlp3s0: associate with 82:2a:a8:c5:d8:3f (try 1/3)
> [ 2158.298718] wlp3s0: associate with 82:2a:a8:c5:d8:3f (try 2/3)
> [ 2158.303803] wlp3s0: RX ReassocResp from 82:2a:a8:c5:d8:3f (capab=0x411 
> status=0 aid=1)
> [ 2158.323642] wlp3s0: associated
> [ 2164.078865] wlp3s0: authenticate with b6:fb:e4:11:b9:3a
> [ 2164.082071] wlp3s0: send auth to b6:fb:e4:11:b9:3a (try 1/3)
> [ 2164.084151] wlp3s0: authenticated
> [ 2164.085463] wlp3s0: associate with b6:fb:e4:11:b9:3a (try 1/3)
> [ 2164.090920] wlp3s0: RX AssocResp from b6:fb:e4:11:b9:3a (capab=0x411 
> status=0 aid=12)
> [ 2164.110924] wlp3s0: associated
> [ 2203.659437] [ cut here ]
> [ 2203.659442] queue 11 already used - expect issues
> [ 2203.659490] WARNING: CPU: 3 PID: 13396 at 
> drivers/net/wireless/intel/iwlwifi/pcie/tx.c:1010 
> iwl_trans_pcie_txq_enable+0x3f3/0x430 [iwlwifi]
> [ 2203.659492] Modules linked in: fuse tun rfcomm ctr ccm cmac binfmt_misc 
> uinput bnep dm_crypt algif_skcipher af_alg btusb btrtl btbcm intel_rapl_msr 
> btintel intel_rapl_common bluetooth x86_pkg_temp_thermal jitterentropy_rng 
> intel_powerclamp coretemp snd_hda_codec_hdmi kvm_intel dm_mod 
> snd_hda_codec_realtek drbg snd_hda_codec_generic kvm snd_hda_intel irqbypass 
> snd_intel_dspcfg crc32_pclmul soundwire_intel soundwire_generic_allocation 
> iwldvm snd_soc_core aes_generic ghash_clmulni_intel uvcvideo snd_compress 
> videobuf2_vmalloc aesni_intel soundwire_cadence mac80211 videobuf2_memops 
> videobuf2_v4l2 crypto_simd ansi_cprng libarc4 videobuf2_common snd_hda_codec 
> mei_wdt mei_hdcp cryptd snd_hda_core glue_helper iwlwifi snd_hwdep videodev 
> rapl soundwire_bus intel_cstate ecdh_generic ecc mc snd_pcm libaes 
> intel_uncore joydev iTCO_wdt intel_pmc_bxt 

Bug#993739: Blends-common

[ThePPK]

Package: blends-common
Version: 0.7.2

Hi,
Today I installed science-config package, and while configure I received 
error with missing tempfile.
After debugging, I found file 
(/usr/share/blends/unixgroups/blend-actions) and defined TMPFILE 
variable with assigned `tempfile` in them. I replaced that with `mktemp` 
and that started working.
While writing this mail, I found debianutils package whose contain 
tempfile exec.
Can be code wrote to work correctly with coreutils and debianutils for 
other users? Or add debianutils as depends for dpkg?

Bug#993738: udev: symlink creation race condition can cause log delays

[Lukas Schwaighofer]

Hi Michael,

thanks a lot for your quick response.

On Sun, 5 Sep 2021 19:44:15 +0200
Michael Biebl  wrote:

> So you create a lot of partitions which all have the same label?
> 
> Isn't this asking for trouble anyway as you can't be certain, which 
> device the /dev/disk/by-label/dummy will point to?

I'm using this in a virtualization setup. The LVs I use have a label of
"root", "var", etc. Within the VMs those are unique and are used
in /etc/fstab..  I don't care about these labels on the host system but
I'd like my system to not break if possible :) .

> Sounds like
> https://github.com/systemd/systemd/issues/20212
> 
> You might give the linked PR
> https://github.com/systemd/systemd/pull/20603
> a try

Thanks for finding that! I'll report back once I've had a chance to try
this.

Regards
Lukas


pgpXz6VYZdwMP.pgp
Description: OpenPGP digital signature

Bug#992170: Thanks for the follow-up

[David W. Kennedy]

Hello Robbi,

Thanks for the follow-up. It helps with package maintenance to have 
confirmation about this. I agree that we can conclude that it's not a 
bug in 0ad.


I have noticed a correlation between faulty power supplies and faulty 
hard drives. So you might want to check or preemptively replace your 
power supply. This advice assumes that there wasn't excessive physical 
force on your hard drive, such as moving the computer while the hard 
drive was spinning or a collision of some sort.


You can close this bug following the steps in link [1]. Ignore the 
statements about the requirement of a new version of the package in 
order to close a bug, because that requirement is not applicable in this 
case.


Basically, send email to 992170-d...@bugs.debian.org and in the body of 
the email include a brief statement that you had a hardware problem and 
the symptoms are unreproducible since you have replaced the hard drive 
(assuming that is actually true). If it doesn't make sense then 
nevermind, and the package maintainer will later close this bug.


Thanks.

Links
[1] https://www.debian.org/Bugs/Developer#closing

--
Dave Kennedy

Bug#991981: python3-skbio: package installs .../dist-packages/benchmarks/..

[Nilesh Patra]

On Sat, 07 Aug 2021 15:38:00 +0200 Steffen Moeller  wrote:
> Package: python3-skbio
> Version: 0.5.6-4
> Severity: normal
> 
> Dear Maintainer,
> 
> Unpacking python3-skbio (0.5.6-4) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/python3-skbio_0.5.6-4_amd64.deb (--unpack):
>  trying to overwrite '/usr/lib/python3/dist-packages/benchmarks/__init__.py', 
> which is also in package cutesv 1.0.11-1
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Errors were encountered while processing:
>  /var/cache/apt/archives/python3-skbio_0.5.6-4_amd64.deb
> 
> I just fixed cutesv, leaving this as a reminder to also fix skbio.
  ^^

Hi Steffen,

this RC bug is triggering removal of several q2-* plugins from testing.
Can you fix this now?

Nilesh


signature.asc
Description: PGP signature

Bug#993463: Bug#991981: python3-skbio: package installs .../dist-packages/benchmarks/..

[Nilesh Patra]

Hi Ole,

Can I ask you to fix this with sunpy soonish? This is one of the reasons
for keeping sunpy out of testing too

Nilesh

On Wed, 1 Sep 2021 20:20:47 +0300 Adrian Bunk  wrote:
> Control: severity -1 serious
> Control: clone -1 -2
> Control: reassign -2 python3-sunpy 3.0.1-3
> Control: retitle -2 python3-sunpy: package installs 
> .../dist-packages/benchmarks/..
> 
> On Sat, Aug 07, 2021 at 03:38:00PM +0200, Steffen Moeller wrote:
> > Package: python3-skbio
> > Version: 0.5.6-4
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > Unpacking python3-skbio (0.5.6-4) ...
> > dpkg: error processing archive 
> > /var/cache/apt/archives/python3-skbio_0.5.6-4_amd64.deb (--unpack):
> >  trying to overwrite 
> > '/usr/lib/python3/dist-packages/benchmarks/__init__.py', which is also in 
> > package cutesv 1.0.11-1
> > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> > Errors were encountered while processing:
> >  /var/cache/apt/archives/python3-skbio_0.5.6-4_amd64.deb
> > 
> > I just fixed cutesv, leaving this as a reminder to also fix skbio.
> 
> And now python3-sunpy does the same:
> 
> ...
> Unpacking python3-sunpy (3.0.1-3) over (2.0.7-1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-wnyRIj/135-python3-sunpy_3.0.1-3_amd64.deb (--unpack):
>  trying to overwrite '/usr/lib/python3/dist-packages/benchmarks/__init__.py', 
> which is also in package python3-skbio 0.5.6-4
> ...
> 
> > Cheers,
> > Steffen
> 
> cu
> Adrian
> 
> 


signature.asc
Description: PGP signature

Bug#993252: Astroquery doesn't work with Astropy 4.3.1

[Nilesh Patra]

On Sun, 29 Aug 2021 13:08:57 +0200 Ole Streicher  wrote:
> Package: python3-astroquery
> Version: 0.4.1+dfsg-4
> Severity: serious
> 
> Dear maintainer,
> 
> The unit tests of astrquery errors with astropy version 4.3.1 which is
> currently in unstable. Could you please update astroquery to the latest
> version 0.4.3, which should resolve this?
> 
> A test log is here:
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/a/astroquery/14913971/log.gz

Hi Vincent,

Can I ask you to fix this soonish? Probably a low hanging fruit, but
this is unfortunately blocking transition of new astropy to testing.

Nilesh


signature.asc
Description: PGP signature

Bug#993725: cryptsetup-initramfs: LV activation disregards activation/auto_activation_volume_list setting

[Lukas Schwaighofer]

Hi Guilhem,

thanks for your quick response.

On Sun, 5 Sep 2021 17:04:06 +0200
Guilhem Moulin  wrote:

> Which concrete problem does this fix?  At initramfs stage only
> required devices (holding /, /usr, the resume device, or those
> explicitely marked ‘initramfs’) are unlocked and we *do* need to
> activate LVs in order to mount these.  So it's unclear to me what's
> the benefit of checking /etc/lvm/lvm.conf is — and a misconfigured
> LVM configuration file could lead to an unbootable system with this
> patch no?

Without the suggested patch it's impossible to prevent some LVs that
share the same volume group as e.g. the root partition from being
activated automatically. Concretely I was trying to work around a
different bug [1] by avoiding automatically opening some LVs using the
`auto_activation_volume_list` option in the lvm.conf. I was surprised
to still see all my LVs activated (and thus the bug triggered,
rendering my system unbootable).

Indeed, if somebody changed their `auto_activation_volume_list` to not
contain the necessary partitions during boot, that would render their
system unbootable.  I believe this is the correct behavior, and this
would also happen in a pure LVM setup since the script from the LVM2
package uses the `-a ay` flag [2].

I've since found a different work around for the original bug I've been
trying to solve, so this is no longer critical for me. I understand you
have to weight the risk of rendering systems unbootable vs having an
option not work exactly as documented, so feel free to close this if
you feel it's not appropriate.

Thanks
Lukas

[1] https://bugs.debian.org/993738
[2] 
https://salsa.debian.org/lvm-team/lvm2/-/blob/master/debian/initramfs-tools/lvm2/scripts/local-top/lvm2#L23


pgpyb0ZI5hPqo.pgp
Description: OpenPGP digital signature

Bug#991896: New upstream version 2.1.0 available

[Elimar Riesebieter]

Hi Lukas,

* Lukas Wunner  [2021-09-05 13:08 +0200]:

> Control: tags -1 + patch
> 
> Here's a patch to update the Debian packaging for 2.1.0.
> 
> Merge upstream's zfs-2.1.0 tag into current master, then apply the patch.
> A ready-to-use branch is available here:
> 
> https://github.com/l1k/zfs/commits/debian/2.1.0-1
> 
> The resulting Debian packages work fine for me with kernel 5.13.

Your patch won't work in sid as there are no abigail-tools << 1.8
available. It shouldn't be possible to run a version out of
oldstable, though.

For further investigation please check the patches in debian/patches
whether they are fuzzy or malformed.

Elimar
-- 
  The path to source is always uphill!
-unknown-

Bug#993738: udev: symlink creation race condition can cause log delays

[Michael Biebl]

Am 05.09.21 um 19:34 schrieb Michael Biebl:

Am 05.09.21 um 19:24 schrieb Lukas Schwaighofer:



 for i in `seq 0 49` ; do
   lvcreate -L 4M -n dummy-${i} vgtest
   mkfs.ext4 -L dummy /dev/vgtest/dummy-${i}


So you create a lot of partitions which all have the same label?

Isn't this asking for trouble anyway as you can't be certain, which 
device the /dev/disk/by-label/dummy will point to?





Sounds like

https://github.com/systemd/systemd/issues/20212

You might give the linked PR
https://github.com/systemd/systemd/pull/20603

a try



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993738: udev: symlink creation race condition can cause log delays

[Michael Biebl]

Am 05.09.21 um 19:24 schrieb Lukas Schwaighofer:

Package: udev
Version: 247.3-6
Severity: important


Dear systemd/udev Maintainers,

I've noticed a race condition with udev symlink creation, that can
cause long delays when activating logical volumes in LVM. Steps to
reproduce the problem (needs root):

 # prepare
 truncate -s 1G test.img
 loop="$(losetup --show -f test.img)"
 echo "Loop device used: $loop"
 pvcreate "$loop"
 vgcreate vgtest "$loop"
 # create 50 LVs with an ext4 fs, all with same label
 # (increase the number to make the problem more sever)
 for i in `seq 0 49` ; do
   lvcreate -L 4M -n dummy-${i} vgtest
   mkfs.ext4 -L dummy /dev/vgtest/dummy-${i}


So you create a lot of partitions which all have the same label?

Isn't this asking for trouble anyway as you can't be certain, which 
device the /dev/disk/by-label/dummy will point to?





OpenPGP_signature
Description: OpenPGP digital signature

Bug#993351: transition: folks

[Sebastian Ramacher]

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

On 2021-08-31 11:12:37 +0200, Laurent Bigonville wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> I would like to upload src:folks to unstable

Please go ahead

Cheers

> 
> All the library packages have bump their soname from 25 to 26
> 
> I tried to rebuild all the rdependencies and they build fine
> 
> https://release.debian.org/transitions/html/auto-folks.html
> 
> Kind regards,
> Laurent Bigonville
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#976811: transition: php8.0

[Ondřej Surý]

Hi Sebastian,

the PHP 8.1 RC1 was released, so I think it would be better to skip php8.0
and go directly with php8.1.  I do have the base package, but I haven’t tested
any extensions yet, but I do plan to do so in upcoming weeks.

I’ll update this issue when I am ready.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 5. 9. 2021, at 19:14, Sebastian Ramacher  wrote:
> 
> Hi Ondřej
> 
> On 2020-12-08 09:28:38 +0100, Ondřej Surý wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> 
>> Hi,
>> 
>> I would like to transition the PHP to version 8.0; it's not such a huge bump 
>> as
>> it was with 5.6 -> 7.0 and most of the packages that were compatible with PHP
>> 7.4 are working just fine with PHP 8.0.
>> 
>> I do have most of the extensions ready for PHP 8.0 either via new upstream 
>> version
>> or with patches.
> 
> bullseye was released so I think we can revisit this transition. What's
> the status here?
> 
> Cheers
> 
>> 
>> Ondrej
>> 
>> Ben file:
>> 
>> title = "php8.0";
>> is_affected = .depends ~ "phpapi-20190902" | .depends ~ "phpapi-20200930";
>> is_good = .depends ~ "phpapi-20200930";
>> is_bad = .depends ~ "phpapi-20190902";
>> 
>> 
>> -- System Information:
>> Debian Release: 10.7
>>  APT prefers stable-updates
>>  APT policy: (500, 'stable-updates'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>> 
>> Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores)
>> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
>> LANGUAGE=en_IE:en (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> 
>> 
> 
> -- 
> Sebastian Ramacher

Bug#993738: udev: symlink creation race condition can cause log delays

[Lukas Schwaighofer]

Package: udev
Version: 247.3-6
Severity: important


Dear systemd/udev Maintainers,

I've noticed a race condition with udev symlink creation, that can
cause long delays when activating logical volumes in LVM. Steps to
reproduce the problem (needs root):

# prepare
truncate -s 1G test.img
loop="$(losetup --show -f test.img)"
echo "Loop device used: $loop"
pvcreate "$loop"
vgcreate vgtest "$loop"
# create 50 LVs with an ext4 fs, all with same label
# (increase the number to make the problem more sever)
for i in `seq 0 49` ; do
  lvcreate -L 4M -n dummy-${i} vgtest
  mkfs.ext4 -L dummy /dev/vgtest/dummy-${i}
done
# set all LVs in vgtest as inactive
vgchange -an vgtest

# trigger the problem by activating all lvs with the same label at
# once (run `journalctl -f` in a different shell to see log
# messages)
vgchange -ay vgtest
# can be repeated by setting as inactive and then active again

# cleanup
vgchange -an vgtest
losetup -d "$loop"
rm test.img


Observe that the activation takes a very long time. The log is flodded
with messages like

dm-??: Failed to update device symlinks: Too many levels of symbolic links

The devices are opened only very slowly (observe by running
`ls /dev/vgtest` while the activation is in progress).  This has
rendered one of my systems unbootable (wait for one of the necessary
volumes times out during boot).

I've temporarily worked around the issue by disabling the "by-label"
symlinks in udev for device mapper devices:

sed '/by-label/ s/^/#/' \
  /lib/udev/rules.d/60-persistent-storage-dm.rules \
  > /etc/udev/rules.d/60-persistent-storage-dm.rules
udevadm control --reload

Notice how the activation now is very fast. To undo this workaround
remove /etc/udev/rules.d/60-persistent-storage-dm.rules and reload udev
rules again.

The same issue is *not* present in the udev version from buster
(241-7~deb10u8).

Thank you
Lukas Schwaighofer


pgp7lJETh0lyP.pgp
Description: OpenPGP digital signature

Bug#993737: ITP: r-cran-clusterr -- GNU R Gaussian mixture models, k-means and others

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-clusterr -- GNU R Gaussian mixture models, k-means and 
others
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-clusterr
  Version : 1.2.5
  Upstream Author : Lampros Mouselimis,
* URL : https://cran.r-project.org/package=ClusterR
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R Gaussian mixture models, k-means and others
 This GNU R package provides Gaussian mixture models, k-means Mini-Batch-
 Kmeans, K-Medoids and Affinity Propagation Clustering Gaussian mixture
 models, k-means, mini-batch-kmeans, k-medoids and affinity propagation
 clustering with the option to plot, validate, predict (new data) and
 estimate the optimal number of clusters. The package takes advantage of
 'RcppArmadillo' to speed up the computationally intensive parts of the
 functions. For more information, see (i) "Clustering in an Object-
 Oriented Environment" by Anja Struyf, Mia Hubert, Peter Rousseeuw
 (1997), Journal of Statistical Software, ;
 (ii) "Web-scale k-means clustering" by D. Sculley (2010), ACM Digital
 Library, ; (iii) "Armadillo: a template-
 based C++ library for linear algebra" by Sanderson et al (2016), The
 Journal of Open Source Software, ; (iv)
 "Clustering by Passing Messages Between Data Points" by Brendan J. Frey
 and Delbert Dueck, Science 16 Feb 2007: Vol. 315, Issue 5814, pp. 972-
 976, .

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

Bug#993394: transition: glibc 2.32

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/glibc-2.32.html

On 2021-09-02 22:11:50 +0200, Aurelien Jarno wrote:
> On 2021-08-31 20:54, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: debian-gl...@lists.debian.org
> > 
> > Dear release team,
> > 
> > I would like to get a transition slot for glibc 2.32. It has been built
> > successfully on all release architectures except mips*el, however I have
> > successfully built them manually on eller.d.o. It also builds fine on most
> > ports architectures.
> 
> It has been finally built on mipsel and mips64el, successfully.

Please go ahead.

Cheers

> 
> Regards,
> Aurelien
> 
> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#979397: transition: ntfs-3g

[Sebastian Ramacher]

Control: forwarded -1 
https://release.debian.org/transitions/html/auto-ntfs-3g.html
Control: tags -1 forwarded

On 2021-01-06 08:11:20 +0100, László Böszörményi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi RMs,
> 
> Only three packages are affected: partclone, testdisk and wimlib. Test
> rebuilds are fine on amd64 but as freeze is around the corner I can
> test it on more architectures if needed.
> The main note that it has an udeb so probably KiBi also would like to
> ACK / NACK this transition.

Please go ahead.

Cheers

> 
> Regards,
> Laszlo/GCS
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#976811: transition: php8.0

[Sebastian Ramacher]

Hi Ondřej

On 2020-12-08 09:28:38 +0100, Ondřej Surý wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> I would like to transition the PHP to version 8.0; it's not such a huge bump 
> as
> it was with 5.6 -> 7.0 and most of the packages that were compatible with PHP
> 7.4 are working just fine with PHP 8.0.
> 
> I do have most of the extensions ready for PHP 8.0 either via new upstream 
> version
> or with patches.

bullseye was released so I think we can revisit this transition. What's
the status here?

Cheers

> 
> Ondrej
> 
> Ben file:
> 
> title = "php8.0";
> is_affected = .depends ~ "phpapi-20190902" | .depends ~ "phpapi-20200930";
> is_good = .depends ~ "phpapi-20200930";
> is_bad = .depends ~ "phpapi-20190902";
> 
> 
> -- System Information:
> Debian Release: 10.7
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_IE:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#993736: ITP: r-cran-kohonen -- GNU R supervised and unsupervised self-organising maps

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-kohonen -- GNU R supervised and unsupervised 
self-organising maps
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-kohonen
  Version : 3.0.10
  Upstream Author : Ron Wehrens and Johannes Kruisselbrink
* URL : https://cran.r-project.org/package=kohonen
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R supervised and unsupervised self-organising maps
 Functions to train self-organising maps (SOMs). Also interrogation of
 the maps and prediction using trained maps are supported. The name of
 the package refers to Teuvo Kohonen, the inventor of the SOM.

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

Bug#993735: knot-resolver FTBFS with knot 3.1.1

[Adrian Bunk]

Source: knot-resolver
Version: 5.3.1-1
Severity: serious
Tags: ftbfs bookworm sid
Control: close -1 5.4.1-1

https://buildd.debian.org/status/package.php?p=knot-resolver=sid

...
FAILED: daemon/kresd.p/io.c.o
cc -Idaemon/kresd.p -Idaemon -I../daemon -Icontrib -I../contrib -I. -I.. 
-I/usr/include/p11-kit-1 -I/usr/include/luajit-2.1 -fdiagnostics-color=always 
-DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu11 -D_GNU_SOURCE 
-Wformat -Wformat-security -Wtype-limits -Wshadow 
-Werror=implicit-function-declaration -Werror=attributes -fvisibility=hidden 
-DHAVE_ASPRINTF=1 -fno-strict-aliasing -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -pedantic -fno-omit-frame-pointer -Wdate-time 
-D_FORTIFY_SOURCE=2 -MD -MQ daemon/kresd.p/io.c.o -MF daemon/kresd.p/io.c.o.d 
-o daemon/kresd.p/io.c.o -c ../daemon/io.c
../daemon/io.c: In function ‘xdp_warn_mode’:
../daemon/io.c:855:8: error: unknown type name ‘knot_xdp_mode_t’
  855 |  const knot_xdp_mode_t mode = knot_eth_xdp_mode(if_index);
  |^~~
../daemon/io.c:855:31: error: implicit declaration of function 
‘knot_eth_xdp_mode’ [-Werror=implicit-function-declaration]
  855 |  const knot_xdp_mode_t mode = knot_eth_xdp_mode(if_index);
  |   ^
../daemon/io.c:857:7: error: ‘KNOT_XDP_MODE_FULL’ undeclared (first use in this 
function); did you mean ‘KNOT_XDP_MSG_FIN’?
  857 |  case KNOT_XDP_MODE_FULL:
  |   ^~
  |   KNOT_XDP_MSG_FIN
../daemon/io.c:857:7: note: each undeclared identifier is reported only once 
for each function it appears in
../daemon/io.c:859:7: error: ‘KNOT_XDP_MODE_EMUL’ undeclared (first use in this 
function); did you mean ‘KNOT_XDP_MSG_MSS’?
  859 |  case KNOT_XDP_MODE_EMUL:
  |   ^~
  |   KNOT_XDP_MSG_MSS
../daemon/io.c:863:7: error: ‘KNOT_XDP_MODE_NONE’ undeclared (first use in this 
function); did you mean ‘KNOT_EDNS_EDE_NONE’?
  863 |  case KNOT_XDP_MODE_NONE: // enum warnings from compiler
  |   ^~
  |   KNOT_EDNS_EDE_NONE
cc1: some warnings being treated as errors
...


This is already fixed in knot-resolver in experimental.

Bug#992170: (no subject)

[Robbi Nespu]

I assume it cause from my disk hardware issue, I unable to recheck 
because I have replace the disk with newer and bigger storage and now I 
using Sid release.


Please close the issue and thanks for your support :)

--
Robbi Nespu 
D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
https://robbinespu.gitlab.io | https://mstdn.social/@robbinespu

Bug#992616: transition: botan

[GCS]

On Wed, Sep 1, 2021 at 10:41 AM Sebastian Ramacher  wrote:
> On 2021-08-21 10:49:04 +0200, László Böszörményi wrote:
> > Again a small transition of botan to 2.18.1 version. Reverse
> > dependencies are biboumi, rnp (sid only) and thunderbird. All build
> > fine with the new botan version in experimental. Actually there's a
> > new upstream version of Thunderbird in experimental, that's built fine
> > as well with the new Botan release.
>
> biboumi is also involved in the ongoing libidn transition. So let's
> postpone this transition until libidn is done.
 That's just done. Am I clear to go with botan?

Regards,
Laszlo/GCS

Bug#993211: inn2: ovdb_monitor/server can't start due to missing /run/news

[Russ Allbery]

Julien ÉLIE  writes:

>> FWIW, tradindexed uses that inode number as an optimization.  When
>> expireover rewrites the data file, it does so in a way that changes the
>> inode number (and updates that field in the index file), which
>> communicates to any other process such as running nnrpd instances with
>> open maps that the data file has changed and should be re-opened to
>> pick up the new data file.  Therefore, these error messages shouldn't
>> result in any incorrect behavior (I think); it will just make things
>> slower because the data file may be re-opened unnecessarily even when
>> it hasn't changed.

> As these messages do not result in any incorrect behaviour, couldn't we
> just lower their log level to notice instead of warn, and silent them in 
> innreport?

We could, but it does indicate an actual problem, so I'd love to
understand more about why this is happening.  If ZFS does change the
inodes on every reboot, another possible solution may be to ensure that
expireover fixes the inode references (I'm not sure that it does right now
in cases where it didn't need to change anything during expiration), which
means the messages will only happen once after each reboot.

I assume ZFS can't be changing them constantly without a reboot or a
remounting of the file system, since presumably that would break lots of
other software.

-- 
Russ Allbery (r...@debian.org)  

Bug#992563: transition: gdal

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: tags 992358 confirmed

On 2021-08-20 11:32:16 +0200, Bas Couwenberg wrote:
> 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-gdal.html
> Control: block -1 by 992527 992528
> 
> For the Debian GIS team I'd like to transition to GDAL 3.3.1.
> 
> Most reverse dependencies rebuilt successfully with GDAL 3.3.1 from
> experimental as summarized below.
> 
> libgdal-grass doesn't need a binNMU as the 3.3.1 version will be
> uploaded to unstable instead.

Assuming that the version of pdal in experimental also builds fine
against the new version of gdal, please go ahead and also start the pdal
transition.

Cheers

> 
> 
> Transition: gdal
> 
>  libgdal28 (3.2.2+dfsg-2) -> libgdal29 (3.3.1+dfsg-1~exp1)
> 
> The status of the most recent rebuilds is as follows.
> 
>  fiona   (1.8.20-2)   OK
>  gazebo  (11.1.0+dfsg-6)  OK
>  gmt (6.2.0+dfsg-1)   OK
>  libcitygml  (2.0.9-3)OK
>  libosmium   (2.17.0-1)   OK
>  mapcache(1.10.0-2)   OK
>  mapnik  (3.1.0+ds-1) OK
>  mapproxy(1.13.2-1)   OK
>  mapserver   (7.6.4-1)OK
>  merkaartor  (0.19.0~rc1+ds-1)OK
>  mysql-workbench (8.0.26+dfsg-1)  OK
>  ncl (6.6.2-7)OK
>  node-srs(1.2.0+~2.6.2-1) FTBFS (#992527)
>  octave-mapping  (1.4.1-1)FTBFS (#992528)
>  openorienteering-mapper (0.9.4-2)OK
>  openscenegraph  (3.6.5+dfsg1-7)  OK
>  pdal(2.2.0+ds-1) OK
>  pgsql-ogr-fdw   (1.1.1-1)OK
>  pktools (2.6.7.6+ds-3)   OK
>  postgis (3.1.3+dfsg-1)   OK
>  python-django   (2:2.2.24-1) OK
>  qmapshack   (1.16.0-1)   OK
>  r-cran-rgdal(1.5-21+dfsg-1)  OK
>  r-cran-sf   (0.9-7+dfsg-5)   OK
>  rasterio(1.2.6-1)OK
>  saga(7.3.0+dfsg-5)   OK
>  vtk6(6.3.0+dfsg2-8.1)OK
>  vtk7(7.1.1+dfsg2-10) OK
>  vtk9(9.0.1+dfsg1-8)  OK
> 
>  cloudcompare(2.10.3-4)   OK
>  grass   (7.8.5-2)OK
>  opencv  (4.5.1+dfsg-5)   OK
>  osmcoastline(2.3.0-2)OK
>  paraview(5.9.0-2)OK
>  sumo(1.8.0+dfsg2-5)  OK
> 
>  libgdal-grass   (3.2.2-1 / 3.3.1-1~exp1) FTBFS / OK
>  otb (7.2.0+dfsg-1)   OK
>  qgis(3.16.10+dfsg-1) OK
> 
> 
> Kind Regards,
> 
> Bas
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#993714: conffile which got removed during upgrade reported missing

[Florian Schlichting]

Hi Evangelos, Axel, Perl team:

On Sun, Sep 05, 2021 at 01:19:44PM +0200, Evangelos Ribeiro Tzaras wrote:
> Is this behaviour expected? Could it be that the new `remove-on-upgrade`
> feature added to dpkg in 1.20.9 is not (yet) understood by debsums?

this.

I've built gnome-calls 41~rc-1 from your salsa repo. The source's

| $ cat debian/gnome-calls.maintscript
| rm_conffile /etc/xdg/autostart/sm.puri.Calls.desktop 0.2.0-1~
| rm_conffile /etc/xdg/autostart/sm.puri.Calls-daemon.desktop 41~alpha-1~

in the binary package now becomes

| $ cat DEBIAN/conffiles
| remove-on-upgrade /etc/xdg/autostart/sm.puri.Calls.desktop
| remove-on-upgrade /etc/xdg/autostart/sm.puri.Calls-daemon.desktop
| /etc/xdg/autostart/org.gnome.Calls-daemon.desktop

So when upgrading gnome-calls from 0.2.0-2 to 41~rc-1, the dpkg database
now reports the following conffiles:

| dpkg-query --showformat='${Conffiles}' --show gnome-calls
|  /etc/xdg/autostart/sm.puri.Calls.desktop newconffile remove-on-upgrade
|  /etc/xdg/autostart/sm.puri.Calls-daemon.desktop 
1789a2d13445edfdced51660c298d7c0 remove-on-upgrade
|  /etc/xdg/autostart/org.gnome.Calls-daemon.desktop 
f78af49e6b5f5cdd5e123aa95f5da75c

This output is parsed by debsums, which assumes that
sm.puri.Calls-daemon.desktop must exist because it has a hash value,
whereas in reality it has already been removed from the system during
the upgrade.

I think this is similar to conffiles marked "obsolete" (cf. #689508),
and I've just pushed a one-line patch to ignore all lines containing the
remove-on-upgrade flag. However I'd prefer if somebody else has a look
to confirm this solution, as I'm rather unfamiliar with debsums and the
dpkg database, and failed to understand why dpkg would keep hashes for
deleted files. (Axel, you must have looked into this when developing the
"obsolete" fix?)

Florian

Bug#993734: RFP: Cawbird - A fork of the Corebird GTK Twitter client that continues to work with Twitter

[Robbi Nespu]

Package: wnpp
Severity: wishlist

  Package name: cawbird
  Version : 1.4.1-1+4.31
  Upstream Author : IBBoard 
  URL : https://github.com/IBBoard/cawbird
  License : GPL-3.0 License  - 
https://github.com/IBBoard/cawbird/blob/master/COPYING

  Programming Lang: vala
  Description : Cawbird is a fork of the Corebird Twitter client 
from Baedert, which became unsupported after Twitter disabled the 
streaming API. Cawbird works with the new APIs and includes a few fixes 
and modifications that have historically been patched in to IBBoard's 
custom Corebird build on his personal Open Build Service account.



I personally able to use repository[1] from openbuild service for my Sid 
installed machine with little adjustment, it will be great if cawbird 
available on official repository


[1] 
https://robbinespu.gitlab.io/posts/linux-twitter-client-cawbird/#solving-ibboardopen-build-service-obs-public-key-issue


- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
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_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8

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

Versions of packages cawbird depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gstreamer1.0-gtk31.18.4-2
ii  gstreamer1.0-plugins-bad 1.18.4-3
ii  gstreamer1.0-plugins-good1.18.4-2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-17
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.68.4-1
ii  libgspell-1-21.8.4-1
ii  libgstreamer1.0-01.18.4-2.1
ii  libgtk-3-0   3.24.30-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  liboauth01.0.3-5
ii  libpango-1.0-0   1.48.9+ds1-2
ii  librest-0.7-00.8.1-1.1
ii  libsoup2.4-1 2.74.0-2
ii  libsqlite3-0 3.36.0-2
ii  libx11-6 2:1.7.2-1

Versions of packages cawbird recommends:
ii  fonts-noto-color-emoji  2.028-1
ii  gstreamer1.0-libav  1.18.4-3

cawbird suggests no packages.

$ apt-cache policy cawbird
cawbird:
  Installed: 1.4.1-1+4.31
  Candidate: 1.4.1-1+4.31
  Version table:
 *** 1.4.1-1+4.31 500
500 
http://download.opensuse.org/repositories/home:/IBBoard:/cawbird/Debian_Unstable 
 Packages

100 /var/lib/dpkg/status


--
Robbi Nespu 
D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
https://robbinespu.gitlab.io | https://mstdn.social/@robbinespu

Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye

[Dennis Filder]

X-Debbugs-CC: Pieter Hollander 

> auto br0
> iface br0 inet static
> address  10.10.10.1
> netmask  255.255.255.0
> bridge_ports none
> bridge_stp off
> bridge_fd 0
>
> iface br0 inet6 static
> address 2001:db8::2
> netmask 64

These stanzas are missing the "bridge_hw" entry which can be a MAC
address or the name of the interface whose MAC to take.  Thus your
bridge ends up being connected to nothing.

The NEWS.Debian file has details on why this was introduced (the
kernel changed behaviour).  You aren't the only one who ran into this.

Regards.

Bug#991631: nfs-utils: please update to newer upstream version

[Anibal Monsalve Salazar]

On Mon, Sep 6, 2021 at 1:46 AM Salvatore Bonaccorso  wrote:
> On Mon, Sep 06, 2021 at 01:31:35AM +1000, Anibal Monsalve Salazar wrote:
> > On Sat, Sep 4, 2021 at 10:47 PM Hector Oron  wrote:
> > > El ds., 4 de set. 2021, 9:33, Anibal Monsalve Salazar  
> > > va escriure:
> > >>
> > >> Hello Salvatore, Héctor,
> > >>
> > >> Just to let you know that I have been working with version 2.5.4 and the 
> > >> 2.5.5 RCs for the last few days, almost full time. Currently, I'm 
> > >> reviewing once again all the patches.
> > >
> > > Excellent! I worked on it sometime, but my work is not ready, I should 
> > > post it once it is ready for review and testing.
> > >
> > > Anibal, do you have some WIP you can publish (on salsa) for review and/or 
> > > testing?
> > >
> > > I feel we are pretty close for a real update. :-)
> > >
> > > Thanks all for the work
> >
> > I uploaded nfs-utils 1:2.5.4-1~exp1 to experimental. Please try it.
> > I'm using it right now.
> >
> > I plan to keep working on it.
>
> Great thank you, and from now on I guess it will be much easier to
> keep on track.
>
> Can you please push the changes to the packaging repository?
>
> https://salsa.debian.org/kernel-team/nfs-utils/

Sure.

Bug#993662: lintian: Please warn for source file that have This file was autogenerated or DO NOT EDIT BY HAND

[Russ Allbery]

"Bastien Roucariès"  writes:

> Doing some code review on mozilla I found this interesting file
> https://sources.debian.org/src/firefox-
> esr/78.13.0esr-1/js/src/frontend/BinASTEnum.h/?hl=1#L1

> // This file was autogenerated by binjs_generate_spidermonkey,
> // please DO NOT EDIT BY HAND.

> I think we should warn level pedantic when we found this 'file (was|is)
> autogenerated' and Do not edit by hand

> It will help work of ftpmaster BTW

I know that Lintian is the tool that we have and thus the easiest place to
add this, and I'm not objecting to that to be clear.  But, in the long
run, I wonder an override is the best place to gather and store this
information.

Your immediate goal is to ask maintainers to check that every generated
file does have source in the package (and ideally is regenerated during
the package build).  But it would also be useful to have a place to
document where that source *is*, and possibly flag whether or not the work
to regenerate it during the package build has been done.  This make me
think the ideal way to store that information would be in a separate YAML
(or some similar format) file that documents derived sources included in
the source package and where they came from.  The Lintian check could then
look for derived sources that aren't documented there and warn about them,
without then responding to those warnings by putting structured data into
the overrides file.

This also provides a possibly smoother rollout strategy: any maintainer
can opt in to documenting their derived source by creating that file, and
if the file exists Lintian could be more aggressive about warning about
derived source because it knows a maintainer is already intending to do
so.  It also opens up the possibility of interesting integrations with
other tools; for example, dh_clean could automatically remove generated
sources that are marked as regenerated in the build system, which would
save some mucking about with manual configuration (but dh_clean wouldn't
want to have to look at lintian overrides to find that information).

Again, this isn't an objection to your proposed deployment strategy or the
Lintian check as you proposed it, which is much simpler.  Just a possible
alternative approach that would give us richer package metadata in the
long run and avoid carrying lots of mostly unstructured overrides
indefinitely in favor of documenting these files in a format designed to
do so.

-- 
Russ Allbery (r...@debian.org)  

Bug#993612: bugs.debian.org: Socionext SynQuacer fails to mount rootfs after upgrade to Bullseye

[Steve McIntyre]

On Sat, Sep 04, 2021 at 06:50:16PM +0100, Steve McIntyre wrote:
>
>I have a synquacer here still and I'll take a look. I noticed on
>bullseye release day that USB stuff didn't seem to work in the
>installer on the synquacer either. Maybe there's been a regression in
>config. :-/
>
>I'll take a look...

Hmmm, booting 5.10.0-0.bpo.8-arm64 here does not work at all. I'm
seeing a lot of errors around DMA setup, e.g.:

[0.142797] OF: translation of DMA address(0) to CPU address failed node()
[0.142824] sram 4520.sram: Invalid size 0x1 for dma-range(s)
[0.142991] OF: translation of DMA address(0) to CPU address failed node()
[0.143008] uart-pl011 2a40.uart: Invalid size 0x1 for dma-range(s)
...
[3.843964] OF: translation of DMA address(0) to CPU address failed node()
[3.850875] armv8-pmu pmu: Invalid size 0x1 for dma-range(s)
[3.857518] hw perfevents: enabled with armv8_pmuv3 PMU driver, 7 counters 
available
...
[3.954986] OF: translation of DMA address(0) to CPU address failed node()
...
[4.391564] OF: translation of DMA address(0) to CPU address failed node()
[4.398449] pcieport :00:00.0: Invalid size 0x1 for dma-range(s)
[4.405253] OF: translation of DMA address(0) to CPU address failed node()
[4.412161] pcieport :01:01.0: Invalid size 0x1 for dma-range(s)
[4.418885] OF: translation of DMA address(0) to CPU address failed node()
[4.425778] pcieport :01:03.0: Invalid size 0x1 for dma-range(s)
[4.432487] OF: translation of DMA address(0) to CPU address failed node()
[4.439385] pcieport :01:05.0: Invalid size 0x1 for dma-range(s)
[4.446095] OF: translation of DMA address(0) to CPU address failed node()
[4.452988] pcieport :01:07.0: Invalid size 0x1 for dma-range(s)
[4.459693] pci :04:00.0: enabling device ( -> 0002)
[4.465488] OF: translation of DMA address(0) to CPU address failed node()
...
[4.472385] pci-host-generic 7000.pcie: Invalid size 0x1 for dma-range(s)

Shortly after this, I see looping errors in the sdhci driver:
[5.728589] xhci_hcd: probe of :04:00.0 failed with error -12
[5.734347] sp : 8000142bbb10
[5.734351] x29: 8000142bbb10 x28:  
[5.734358] x27: 000801ebf848 x26:  
[5.768201] x25: 0080 x24: 0001 
[5.773514] x23: 00080176ac10 x22: 000889b60080 
[5.778826] x21:  x20:  
[5.784139] x19: 8000117c9788 x18: 0020 
[5.789451] x17: 00080833da00 x16: 0080 
[5.794763] x15:  x14: 2820776f6c667265 
[5.800076] x13: 766f203633353536 x12: 2b66 
[5.805389] x11:  x10: 6678302072646461 
[5.810701] x9 : 80001011159c x8 : 62202c66 
[5.816013] x7 : 66206b73616d x6 : 00087f4647c0 
[5.821325] x5 : 8000142bb828 x4 :  
[5.826637] x3 :  x2 :  
[5.831949] x1 : 3082d45f0379e900 x0 :  
[5.837262] Call trace:
[5.839708]  swiotlb_map+0x294/0x2a8
[5.843281]  dma_map_page_attrs+0xec/0x228
[5.847382]  sdhci_setup_host+0xa8c/0xee8 [sdhci]
[5.852086]  sdhci_add_host+0x20/0x58 [sdhci]
[5.856444]  sdhci_f_sdh30_probe+0x2a8/0x380 [sdhci_f_sdh30]
[5.862104]  platform_drv_probe+0x5c/0xb0
[5.866113]  really_probe+0xf0/0x4d8
[5.869686]  driver_probe_device+0xfc/0x168
[5.873868]  __driver_attach_async_helper+0xbc/0xc8
[5.878743]  async_run_entry_fn+0x50/0x218
[5.882837]  process_one_work+0x1bc/0x480
[5.886843]  worker_thread+0x158/0x4e0
[5.890590]  kthread+0x12c/0x130
[5.893817]  ret_from_fork+0x10/0x30
[5.897389] ---[ end trace 986b9b1a11578595 ]---

Longer log attached. I'm wondering if there's a DTB mismatch or
something - my system here is still using the built-in DTB from the
EFI firmware, and I don't see a newer DTB available in the debian
package nor in upstream git.

@Arnd any clues please?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
“Changing random stuff until your program works is bad coding
 practice, but if you do it fast enough it’s Machine Learning.”
   -- https://twitter.com/manisha72617183


synquacer.log.gz
Description: application/gzip

Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye

[Pieter Hollander]

Package: bridge-utils
Version: 1.7-1
Severity: critical
Tags: ipv6
Justification: breaks unrelated software

After upgrading from Buster to Bullseye, bridge-utils no longer 
configures my IPv6 network bridge correctly.
It fails to bring up br0 and therefore also breaks Unbound on my system, 
as the IPv6 interface address Unbound needs to bind to remains in 
"tentative" state.
Looking at the bridge-utils changelog, I thought it might be related to 
the fixes for #980752, but I am unsure about this.
I have personally not been able to fix the problem yet and cannot find 
documentation explaining the change in bridge-utils behaviour.


The following setup works correctly on buster but fails on bullseye.
"sudo journalctl -u networking -f" shows the following message:

Starting Raise network interfaces...
Sep 02 12:10:30 x ifup[849]: Waiting for DAD... Done
Sep 02 12:10:37 x ifup[1042]: Waiting for DAD... Timed out
Sep 02 12:10:37 x ifup[712]: ifup: failed to bring up br0
Sep 02 12:10:37 x systemd[1]: networking.service: Main process exited, 
code=exited, status=1/FAILURE
Sep 02 12:10:37 x systemd[1]: networking.service: Failed with result 
'exit-code'.

Sep 02 12:10:37 x systemd[1]: Failed to start Raise network interfaces.

Overview of configuration:

/etc/network/interfaces:

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

auto ens3
iface ens3 inet static
    address 203.0.113.0.118
    netmask 255.255.255.0
    gateway 203.0.113.0.1
    dns-nameservers 127.0.0.1

iface ens3 inet6 static
    address 2001:db8::1
    netmask 128
    gateway fe80::1
    dns-nameservers ::1

auto br0
iface br0 inet static
    address  10.10.10.1
    netmask  255.255.255.0
    bridge_ports none
    bridge_stp off
    bridge_fd 0

iface br0 inet6 static
    address 2001:db8::2
    netmask 64

/etc/sysctl.conf

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.ens3.proxy_ndp=1

/etc/ndppd.conf

route-ttl 3
proxy ens3 {
    router no
    timeout 500
    ttl 3
    rule 2001:db8::/64 {
    auto
    }
}

/etc/unbound/unbound.conf:

include: "/etc/unbound/unbound.conf.d/*.conf"

server:
interface: 127.0.0.1
interface: ::1
access-control: 127.0.0.0/8 allow
access-control: ::1/128 allow

# Listen on the LXC bridge IPv4 & IPv6 network
interface: 10.10.10.1
interface: 2001:db8::2
# Allow access to Unbound from containers
access-control: 10.10.10.1/24 allow
access-control: 2001:db8::1/64 allow


-- 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/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 bridge-utils depends on:
ii  libc6  2.31-13

bridge-utils recommends no packages.

Versions of packages bridge-utils suggests:
ii  ifupdown  0.8.36

-- no debconf information

Bug#993733: libinput-bin: Thinkpad T470 trackpoint is too sensitive since 1.9.0

[Dmitry Maluka]

Package: libinput-bin
Version: 1.16.4-3
Severity: normal

Dear Maintainer,

Starting with libinput 1.9.0, the trackpoint on Thinkpad T470 is barely usable:
it is too sensitive and seems impossible to fine-tune using hw settings or
libinput accel speed setting.

A fix is to add a quirk with multiplier set to 0.4, same as for T480:

[Lenovo T470 Trackpoint]
MatchName=*TPPS/2 IBM TrackPoint
MatchDMIModalias=dmi:*svnLENOVO:*:pvrThinkPadT470:*
AttrTrackpointMultiplier=0.4

It is already merged upstream:
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/680

With this quirk it is as good (or better) as with libinput 1.8.4. Sensitivity
feels the same as with 1.8.4 with the same hw settings for speed and 
sensitivity.


-- 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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libinput-bin depends on:
ii  libc6  2.31-13
ii  libevdev2  1.11.0+dfsg-1
ii  libudev1   247.3-6
ii  libwacom2  1.8-2

libinput-bin recommends no packages.

libinput-bin suggests no packages.

-- no debconf information

Bug#993732: gdisk: declares compliance with bogus not-yet-released Policy 4.6.1

[Jonas Smedegaard]

Package: gdisk
Version: 1.0.8-2
Severity: serious
Justification: Policy 4.1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package control file contains the following:

> Standards-Version: 4.6.1

Debian Policy is currently at version 4.6.0.1 which is lower than above,
and states in § 4.1 that

> When updating existing packaging, the Standards-Version must not be
> updated except after reviewing the changes between the old and the new
> versions of the standards and updating your package if necessary

Since you could not possibly have verified the package against a
non-existing Policy version, and that doing so is a "must", I am using
severity "serious" here.  Possibly that's not necessary, but perhaps
some tooling explodes due to this?...

NB! 4th tuple is for editorial changes, so it is better to omit that -
i.e. declare "4.6.0" (not "4.6.0.1"),


Kind regards, and thanks for maintaining this great little tool,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmE05c4ACgkQLHwxRsGg
ASHL5xAAi17G+401RGhKk/Oz7cxofx7JxYBihxfEm5BCNlODntODORvJ7NY+4ZWh
Zw/TYPQqFigzdyJWUYzLs2nYz8TRFZF+mKNJ3+WBAQjGGi3S519IPS+75xmvR14B
IzUy2qJdq9O9Nckk9cU57qvvEiVEUlzr44R6eZzk+Z4O4Az0gFG9RF2AxVl5l18h
qt7qpoyl6hBCTBU15iXK7vEJgl6FAi4R2TCVjXo1WDZFZys0KVRKs+ioZk515/hu
rf5Tg+d7p2aF2ojgmFkRE2GRo8OU30+KM7vKEelw6i8xQ5rV910mITXxe35LMPJX
peheeg4TmMm/3V3BrFExo9/POfbwKHM5AC2yujQbBTe3ElXTkWqsnnc0XL1v42+U
qROynjcmMvw9WptUsgmd5NEmbvTJ2YaCnd5HTaBW/wZo63VLhLZKYmTD7jolPJUd
ivuD5b/0cQy/u8haeXcCtwg6V+uktSaQRokbQtY3aouKeqt+TBCDalzb/hNp/wip
1Lo8cp8++DgjhgBnTdKy0ohc9hqfiRs7WYi85LPHhLHY+yxrCPmtBWw/CiY+wYxW
0SGwbM9bHuScA8/GkaBzXl4s471dAPRRsy1L5VZRLUVc2P4SFPfDunQKmkJHNFgy
DUY3Es23A1HFtBIOx/B0QyF8iTXPqhsoyiyKVZiC71XqJj2O27o=
=qD+p
-END PGP SIGNATURE-

Bug#991631: nfs-utils: please update to newer upstream version

[Salvatore Bonaccorso]

Hi Anibal,

On Mon, Sep 06, 2021 at 01:31:35AM +1000, Anibal Monsalve Salazar wrote:
> On Sat, Sep 4, 2021 at 10:47 PM Hector Oron  wrote:
> > El ds., 4 de set. 2021, 9:33, Anibal Monsalve Salazar  
> > va escriure:
> >>
> >> Hello Salvatore, Héctor,
> >>
> >> Just to let you know that I have been working with version 2.5.4 and the 
> >> 2.5.5 RCs for the last few days, almost full time. Currently, I'm 
> >> reviewing once again all the patches.
> >
> > Excellent! I worked on it sometime, but my work is not ready, I should post 
> > it once it is ready for review and testing.
> >
> > Anibal, do you have some WIP you can publish (on salsa) for review and/or 
> > testing?
> >
> > I feel we are pretty close for a real update. :-)
> >
> > Thanks all for the work
> 
> I uploaded nfs-utils 1:2.5.4-1~exp1 to experimental. Please try it.
> I'm using it right now.
> 
> I plan to keep working on it.

Great thank you, and from now on I guess it will be much easier to
keep on track.

Can you please push the changes to the packaging repository?

https://salsa.debian.org/kernel-team/nfs-utils/

Regards,
Salvatore

Bug#992748: systemd-cron: postinst error - CVE-2017-9525?

[Salvatore Bonaccorso]

Control: clone 992748 -1
Control: retitle -1 systemd-cron: CVE-2017-9525: group crontab to root 
escalation via postinst
Control: severity -1 important
Control: found -1 1.5.16-1
Control: found -1 1.5.14-2
Control: tags 992748 - security

Hi Chris,

On Sun, Sep 05, 2021 at 02:49:40PM +0200, Chris Hofstaedtler wrote:
> Control: tags -1 + security
> 
> * Alexandre Detiste  [210905 12:47]:
> > Le lun. 23 août 2021 à 04:57, Martin-Éric Racine
> >  a écrit :
> > > Setting up systemd-cron (1.5.17-1) ...
> > > xargs: warning: options --max-args and --replace/-I/-i are mutually 
> > > exclusive, ignoring previous --max-args value
> > > Thanks.
> > 
> > This was copy-pasted from src:cron, which must have the same bug now.
> 
> src:cron removed the offending code as part of a security fix in
> 2018:
> 
> https://salsa.debian.org/debian/cron/-/commit/a10ab4e346e941aaa92f4b671a96895392b917af
> 
> This would suggest CVE-2017-9525 also affects src:systemd-cron.

Looks right and confirmed in a quick test. If the attacher has gained
crontab group then further escalation is possible.

Though technically those two bugs will be resolved at the same step I
though to be good to separate the escalation issue and the error in
postinst (but as said, they will be fixed basically together).

Once fixed in unstable, can you please fix the issue as well via
upcoming point releases for bullseye and buster? Similarly as for the
src:cron case a DSA is not warranted.

Regards,
Salvatore

Bug#993730: snapd: - Mount snap "core" (11606) (snap is unusable due to missing files; contact developer)

[matteo]

Package: snapd
Version: 2.49-1+b5
Severity: important
X-Debbugs-Cc: eng.matteo.nunzi...@gmail.com

Dear Maintainer,

   * What led up to the situation?
tring to install any package with the snap command
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
tried to install: core, hello-world, google-cloud-sdk --classic. all failed
   * What was the outcome of this action?
see above
   * What outcome did you expect instead?
having snap installed

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages snapd depends on:
ii  adduser  3.118
ii  apparmor 3.0.3-2
ii  ca-certificates  20210119
ii  gnupg2.2.27-2
ii  gnupg1   1.4.23-1.1
ii  libapparmor1 3.0.3-2
ii  libc62.31-17
ii  libcap2  1:2.44-1
ii  libseccomp2  2.5.1-1
ii  libudev1 247.9-1
ii  openssh-client   1:8.4p1-5
ii  squashfs-tools   1:4.5-2
ii  systemd  247.9-1
ii  udev 247.9-1

Versions of packages snapd recommends:
ii  gnupg  2.2.27-2

Versions of packages snapd suggests:
ii  zenity  3.32.0-7

-- no debconf information

Bug#993729: aalib: declares compliance with bogus not-yet-released Policy 4.6.1'

[Jonas Smedegaard]

Source: aalib
Version: 1.4p5-49
Severity: serious
Justification: Policy 4.1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package control file contains the following:

> Standards-Version: 4.6.1

Debian Policy is currently at version 4.6.0.1 which is lower than above,
and states in § 4.1 that

> When updating existing packaging, the Standards-Version must not be
> updated except after reviewing the changes between the old and the new
> versions of the standards and updating your package if necessary

Since you could not possibly have verified the package against a
non-existing Policy version, and that doing so is a "must", I am using
severity "serious" here.  Possibly that's not necessary, but perhaps
some tooling explodes due to this?...


Kind regards,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmE05FUACgkQLHwxRsGg
ASFy3RAAkxobtA3zN13mtqtBOb3QfJsWQW8ZgSR2eX9BZUxiJxlLKnM/6DNu9Qez
4sBqDcLmJRLJfj6Bk+efqa64/dJgZXqBfpJOtmRyFg+easj7nEXxWdO/i5W+9Kfo
d/53q+1bsdjTpYQuuKNTWOfuwGF5GSp63Ps4I/Cdcgns8Hm4uTpBntiXsiLswrTH
J/U277HqaWW7dsANBhOUMVJc+VEG9UDjivbdOEmp5TPUs7U0TdRYvo0rTVNOoak+
2rWvzUOLhLCSySk32+VZrYf06eeFuVDis0EHkv44BWs9KhJY8o3qDJhp58Bb5nhP
IlzwQ4N6ZUZjxQozEhZWvAuu7IrmTu7guz1WQIpIiXUNck34x2hLqfK7G8taq0qw
arlwgQkSPXkG54rq9tC8tGhmTKWfaW18kagEO/aO+bzUo2WjbNR4gXD9SFEbJ/Zn
KrT+UxCfO+zDb9xHrl2x49zTluQXaiZOW5fzFGPJYqt20nU/pBFpUUlSS9qid7uc
Rv+T1jePHgPOozif09I5pZgyfC6D4ehRW7t3bk6WQjTgzYVhttCeLwMDTQVd2Zmd
8hyWXD0sKXrwDFbNsB2S3iq1ZYmWTuGTvDWTdC+3ldH+YvPYQznsg6gedGrxGbCr
nogZ7Hvrf/RRkruPLcC91gdooCvHIpuzDHYMwHWZaFUe7qsGr3M=
=sGWb
-END PGP SIGNATURE-

Bug#991631: nfs-utils: please update to newer upstream version

[Anibal Monsalve Salazar]

On Sat, Sep 4, 2021 at 10:47 PM Hector Oron  wrote:
> El ds., 4 de set. 2021, 9:33, Anibal Monsalve Salazar  va 
> escriure:
>>
>> Hello Salvatore, Héctor,
>>
>> Just to let you know that I have been working with version 2.5.4 and the 
>> 2.5.5 RCs for the last few days, almost full time. Currently, I'm reviewing 
>> once again all the patches.
>
> Excellent! I worked on it sometime, but my work is not ready, I should post 
> it once it is ready for review and testing.
>
> Anibal, do you have some WIP you can publish (on salsa) for review and/or 
> testing?
>
> I feel we are pretty close for a real update. :-)
>
> Thanks all for the work

I uploaded nfs-utils 1:2.5.4-1~exp1 to experimental. Please try it.
I'm using it right now.

I plan to keep working on it.