date:20211004

Hi Santiago,

since you haven't given any additional input, I prepared patches for both
options and attached them to this mail.

Quoting Johannes Schauer Marin Rodrigues (2021-09-24 16:25:04)
> If you want to change the current patch, I could:
> 
>  1. add a slash between $DPKG_ROOT and the next variable -- even if $DPKG_ROOT
> ends in a slash, multiple slashes don't make a difference

Patch in base-files-extra-slash.diff

>  2. add code to the respective functions that ensure that the arguments start
> with a slash

Patch in base-files-check-absolute.diff

> How would you like me to proceed?

Both patches are tested in our CI environment and produce a bit-by-bit
identical output compared to without DPKG_ROOT.

What else can I do for you?

Thanks!

cheers, josch--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -1,52 +1,75 @@
 #!/bin/sh
 set -e
 
+: "${DPKG_ROOT:=}"
+
+change_owner() {
+  local owner group
+  owner=${1%:*}
+  group=${1#*:}
+  owner=$(sed -n "s/^$owner:[^:]*:\\([0-9]*\\):.*/\\1/p" "$DPKG_ROOT/etc/passwd")
+  group=$(sed -n "s/^$group:[^:]*:\\([0-9]*\\):.*/\\1/p" "$DPKG_ROOT/etc/group")
+  chown "$owner:$group" "$DPKG_ROOT/$2"
+}
+
+change_mode() {
+  chmod "$1" "$DPKG_ROOT/$2"
+}
+
+ensure_file_owner_mode() {
+  if [ ! -f "$DPKG_ROOT/$1" ]; then
+: > "$DPKG_ROOT/$1"
+  fi
+  change_owner "$2" "$1"
+  change_mode "$3" "$1"
+}
+
 install_local_dir() {
-  if [ ! -d $1 ]; then
-mkdir -p $1
+  if [ ! -d "$DPKG_ROOT/$1" ]; then
+mkdir -p "$DPKG_ROOT/$1"
   fi
-  if [ -f /etc/staff-group-for-usr-local ]; then
-chown root:staff $1 2> /dev/null || true
-chmod 2775 $1 2> /dev/null || true
+  if [ -f "$DPKG_ROOT/etc/staff-group-for-usr-local" ]; then
+change_owner root:staff "$1" 2>/dev/null || true
+change_mode 2775 "$1" 2> /dev/null || true
   fi
 }
 
 install_from_default() {
-  if [ ! -f $2 ]; then
-cp -p /usr/share/base-files/$1 $2
+  if [ ! -f "$DPKG_ROOT/$2" ]; then
+cp -p "$DPKG_ROOT/usr/share/base-files/$1" "$DPKG_ROOT/$2"
   fi
 }
 
 install_directory() {
-  if [ ! -d /$1 ]; then
-mkdir /$1
-chown root:$3 /$1
-chmod $2 /$1
+  if [ ! -d "$DPKG_ROOT/$1" ]; then
+mkdir "$DPKG_ROOT/$1"
+change_owner "root:$3" "/$1"
+change_mode "$2" "/$1"
   fi
 }
 
 migrate_directory() {
-  if [ ! -L $1 ]; then
-rmdir $1
-ln -s $2 $1
+  if [ ! -L "$DPKG_ROOT/$1" ]; then
+rmdir "$DPKG_ROOT/$1"
+ln -s "$2" "$DPKG_ROOT/$1"
   fi
 }
 
 update_to_current_default() {
-  if [ -f $2 ]; then
-md5=`md5sum $2 | cut -f 1 -d " "`
-if grep -q "$md5" /usr/share/base-files/$1.md5sums; then
-  if ! cmp -s /usr/share/base-files/$1 $2; then
-cp -p /usr/share/base-files/$1 $2
+  if [ -f "$DPKG_ROOT/$2" ]; then
+md5=`md5sum "$DPKG_ROOT/$2" | cut -f 1 -d " "`
+if grep -q "$md5" "$DPKG_ROOT/usr/share/base-files/$1.md5sums"; then
+  if ! cmp -s "$DPKG_ROOT/usr/share/base-files/$1" "$DPKG_ROOT/$2"; then
+cp -p "$DPKG_ROOT/usr/share/base-files/$1" "$DPKG_ROOT/$2"
 echo Updating $2 to current default.
   fi
 fi
   fi
 }
 
-if [ ! -e /etc/dpkg/origins/default ]; then
-  if [ -e /etc/dpkg/origins/#VENDORFILE# ]; then
-ln -sf #VENDORFILE# /etc/dpkg/origins/default
+if [ ! -e "$DPKG_ROOT/etc/dpkg/origins/default" ]; then
+  if [ -e "$DPKG_ROOT/etc/dpkg/origins/#VENDORFILE#" ]; then
+ln -sf #VENDORFILE# "$DPKG_ROOT/etc/dpkg/origins/default"
   fi
 fi
 
@@ -62,8 +85,8 @@
   install_directory var/opt   755 root
   install_directory media 755 root
   install_directory var/mail 2775 mail
-  if [ ! -L /var/spool/mail ]; then
-ln -s ../mail /var/spool/mail
+  if [ ! -L "$DPKG_ROOT/var/spool/mail" ]; then
+ln -s ../mail "$DPKG_ROOT/var/spool/mail"
   fi
   install_directory run/lock 1777 root
   migrate_directory /var/run /run
@@ -79,25 +102,16 @@
   install_local_dir /usr/local/sbin
   install_local_dir /usr/local/src
   install_local_dir /usr/local/etc
-  ln -sf share/man /usr/local/man
+  ln -sf share/man "$DPKG_ROOT/usr/local/man"
 
-  if [ ! -f /var/log/wtmp ]; then
-echo -n>/var/log/wtmp
-  fi
-  if [ ! -f /var/log/btmp ]; then
-echo -n>/var/log/btmp
-  fi
-  if [ ! -f /var/log/lastlog ]; then
-echo -n>/var/log/lastlog
-  fi
-  chown root:utmp /var/log/wtmp /var/log/btmp /var/log/lastlog
-  chmod 664 /var/log/wtmp /var/log/lastlog
-  chmod 660 /var/log/btmp
+  ensure_file_owner_mode /var/log/wtmp root:utmp 664
+  ensure_file_owner_mode /var/log/btmp root:utmp 660
+  ensure_file_owner_mode /var/log/lastlog root:utmp 664
 fi
 
-if [ -d /usr/share/info ] && [ ! -f /usr/info/dir ] && [ ! -f /usr/share/info/dir ]; then
+if [ -d "$DPKG_ROOT/usr/share/info" ] && [ ! -f "$DPKG_ROOT/usr/info/dir" ] && [ ! -f "$DPKG_ROOT/usr/share/info/dir" ]; then
   install_from_default info.dir /usr/share/info/dir
-  chmod 644 /usr/share/info/dir
+  change_mode 644 /usr/share/info/dir
 fi
 
 if [ "$1" = "configure" ] && [ "$2" != "" ]; then
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -1,

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-04 Thread ‍小太

On Sun, 3 Oct 2021 12:33:48 +0100 Simon McVittie  wrote:
> On Sat, 02 Oct 2021 at 20:48:55 +1000, ‍小太 wrote:
> > What I can add is from reading the documentation of 
> > g_quark_from_static_string()
> > (https://docs.gtk.org/glib/func.quark_from_static_string.html)
> > is these particular lines seem to be of importance:
> >
> > > It can be used with statically allocated strings in the main program,
> > > but not with statically allocated memory in dynamically loaded
> > > modules, if you expect to ever unload the module again
> >
> > However, jackd will load jack_firewire.so three times (which means
> > loading and unloading its glibmm dependency three times)
>
> Perhaps jack_firewire.so and/or glibmm should be linked with -Wl,-z,nodelete
> to prevent it from being removed from the address space even after
> dlclose()? That would ensure that its static strings remain in memory.

I suppose that would solve the problem too.
But I think we should try to have the root cause fixed upstream first.

I wrote a short PoC without the involvement of JACK to demonstrate it is not
a JACK problem and the bug has existed (hidden) for 18 years already:
https://gitlab.gnome.org/GNOME/glibmm/-/issues/96#note_1281881

Bug#947234: ifupdown: Do not wait forever for ipv6 stateless dhcp

2021-10-04 Thread Santiago Ruano Rincón

Control: merge -1 752672

If I am not wrong, these are the same dhcp6 stateful issue.

El 22/09/21 a las 10:18, Santiago Ruano Rincón escribió:
> Control: tags -1 + pending
> 
> On Mon, 23 Dec 2019 10:56:04 +0100 Joerg Dorchain  wrote:
> > Package: ifupdown
> > Version: 0.8.35
> > Tags: Patch
> > 
> > Hi,
> > 
> > I have a Box that I want to connect to several network which do (or don't) 
> > IP
> > autoconfiguration.
> > For IPv4, this works fine. Even when there is no IPv4 dhcp server, the
> > machine continues to boot after a timeout.
> > 
> > For IPv6, when ausing SLAAC autoconfiguration for the address, and trying to
> > get the rest (resolver, ntp,...) via stateless dhcp, if currently hangs
> > forever trying to get this information on booted on a network which does not
> > have a IPv6 dhcp.
> > 
> > Which this patch, the call to dhclient has an option to timeout, so at least
> > the machine continues to boot.
> > 
> > Thanks for including it.
> ...
> 
> Applied. Thank you for the patch.
> 
> Cheers,
> 
>  -- Santiago




signature.asc
Description: PGP signature

Bug#834544: ITP: dh-copyright -- debhelper extension to aid in tracking copyright and licensing info


Tags: moreinfo

On Wed, 17 Aug 2016 00:27:07 +0200 Jonas Smedegaard  wrote:
>

* Package name: dh-copyright
  Version : 0.0.1
  Upstream Author : Jonas Smedegaard 
* License : GPL-3+
  Programming Lang: Perl
  Description : debhelper extension to aid in tracking copyright and 
licensing info

 dh-copyright provides a debhelper sequence addon named 'copyright' and
 the command dh_copyright.
 .
 The dh_copyright command uses licensecheck to check sourcecode of a
 package and compares the result against an existing machine-readable
 debian/copyright file.

The package will be maintained in the build-common team.


Hi Jonas,

Is this RFP still relevant? There is no URL to the source.

Thanks,
Bastian

Bug#995692: svn client does not allow plain text password store

2021-10-04 Thread debbug2

Package: subversion
X-Debbugs-Cc: debb...@igor2.repo.hu
Version: 1.14.1-3
Severity: normal


I've installed subversion in a chroot from unstable. It suddenly refused to 
remember my password. There was no clear indication for why. After editing all 
config files I could think of it still silently refused to remember my password.

It turns out this feature needs to be enabled in ./configure using 
--enable-plaintext-password-storage

I am a long tiem svn user. I have situations where storing password in plain 
text is okay from security viewpoint (e.g. encrypted file system). Enabling 
this in configure will not force users to store passwords in plain; the svn 
client even warns and asks the user about this when it is about to happen.

Please enable this feature so my workflow will not break after an upgrade.


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 4 (chimaera)
Release:4
Codename:   n/a
Architecture: x86_64

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

Versions of packages subversion depends on:
ii  libapr1  1.7.0-8
ii  libaprutil1  1.6.1-5
ii  libc62.32-4
ii  libsvn1  1.14.1-3

subversion recommends no packages.

Versions of packages subversion suggests:
pn  db5.3-util  
pn  libapache2-mod-svn  
ii  patch   2.7.6-7
pn  subversion-tools

-- no debconf information

Bug#995693: cockpit-machines: Request to build for bullseye-backports

2021-10-04 Thread José Miguel Gonçalves

Package: cockpit-machines
Version: 239-1
Severity: wishlist

I would like to try cockpit-machines v251 in bullseye but that is currently not 
possible because, while cockpit v251 package is released in bullseye-backports, 
cockpit-machines is not.
Please build cockpit-machines v251 for bullseye-backports. 

Best regards,
José Miguel Gonçalves

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

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

Versions of packages cockpit-machines depends on:
ii  libvirt-clients7.0.0-3
ii  libvirt-daemon-system  7.0.0-3
ii  libvirt-dbus   1.4.0-2

Versions of packages cockpit-machines recommends:
ii  gir1.2-libosinfo-1.0  1.8.0-1
ii  python3-gi3.38.0-2
ii  qemu-block-extra  1:5.2+dfsg-11+deb11u1
ii  virtinst  1:3.2.0-3

cockpit-machines suggests no packages.

-- no debconf information

Bug#995169: mc: Subshell Ctrl+o stopped working with upgrade from 4.8.26-1.1 => 4.8.27-1

2021-10-04 Thread David Nebauer

Package: mc
Version: 3:4.8.27-1
Followup-For: Bug #995169
X-Debbugs-Cc: davidneba...@gmail.com

Dear Maintainer,

I have the same change in behaviour reported by Pavel Reznicek during
the upgrade to 4.8.27.

I have noted a further behaviour change that may assist in
troubleshooting: when executing commands from mc's command line in
4.8.26 I was able to use zsh functions defined in
~/.zsh/functions-{available,enabled}/. After upgrading to 4.8.27 using
any of these functions results in errors like:
zsh:1: command not found: FN_NAME

In preparing to file this bug report I became aware that it is possible
to provide mc with a custom .zshrc file at ~/.local/share/mc/. There is
no such file on my system (and never has been).

David

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
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 mc depends on:
ii  libc6 2.32-4
ii  libext2fs21.46.4-1
ii  libglib2.0-0  2.70.0-1+b1
ii  libgpm2   1.20.7-9
ii  libslang2 2.3.2-5
ii  libssh2-1 1.10.0-2
ii  mc-data   3:4.8.27-1

Versions of packages mc recommends:
ii  mime-support3.66
ii  perl5.32.1-6
ii  sensible-utils  0.0.17
ii  unzip   6.0-26

Versions of packages mc suggests:
pn  arj  
ii  bzip21.0.8-4
pn  dbview   
pn  djvulibre-bin
pn  epub-utils   
ii  evince [pdf-viewer]  40.4-2
ii  file 1:5.39-3
ii  genisoimage  9:1.1.11-3.2
pn  gv   
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
pn  libaspell-dev
pn  odt2txt  
ii  okular [pdf-viewer]  4:21.08.1-1+b1
ii  poppler-utils20.09.0-3.1
pn  python-boto  
ii  python-is-python2 [python]   2.7.18-9
pn  python-tz
ii  texlive-binaries 2021.20210626.59705-1
ii  unar 1.10.1-2+b6
ii  w3m  0.5.3+git20210102-6
pn  wimtools 
ii  zip  3.0-12

-- no debconf information

Bug#995694: opendmarc: Debian patch ticket193.patch breaks opendmarc-import

2021-10-04 Thread David Bürgin

Package: opendmarc
Version: 1.4.0~beta1+dfsg-6
Severity: important

In Debian’s opendmarc we maintain patch ticket193.patch.

It is not documented what this patch is supposed to address or why it
was added. Though parts of the patch make sense, other parts are
unclear. The ticket at the old issue tracker
https://sourceforge.net/p/opendmarc/tickets/193/ does not help.

Now it has been reported that the patch is harmful. See:
https://github.com/trusteddomainproject/OpenDMARC/issues/189

I propose we delete the change to reports/opendmarc-import.in from the
patch.

We might need to do an update for Debian stable.

Help is welcome as I don’t use a database myself.

Bug#991967: Simply ACPI powerdown/reset issue?

2021-10-04 Thread Hans van Kranenburg

Hi Elliot and others,

Also including #994899 for once, since that's the bug number for the Xen
issue now.

On 9/26/21 5:27 AM, Elliott Mitchell wrote:
> On Tue, Sep 21, 2021 at 06:33:20AM -0400, Chuck Zmudzinski wrote:
>> I presume you are suggesting I try booting 4.19.181-1 on the
>> current version of Xen-4.14 for bullseye as a dom0. I am not
>> inclined to try it until an official Debian developer endorses
>> your opinion that the bug I am seeing is distinct
>> from #991967, at which point I will report the bug I am
>> seeing as a new bug.
> 
> Chuck Zmudzinski you are getting rather close to my threshold for calling
> harrassment.  You're not /quite/ there, but I'm concerned.
> 
> 
> Since the purpose of the bug reports is to find and diagnose bugs, I did
> a bit of experimentation and made some observations.
> 
> I checked out the Debian Xen source via git.  I got the current
> "master" branch which is presently the candidate 4.14.3-1 version,
> which includes urgent fixes.  The hash is:
> e7a17db0305c8de891b366ad3528e5a43015
> 
> On top of this I cherry-picked 3 commits from Xen's main branch:
> 5a4087004d1adbbb223925f3306db0e5824a2bdc
> 0f089bbf43ecce6f27576cb548ba4341d0ec46a8
> bc141e8ca56200bdd0a12e04a6ebff3c19d6c27b
> 
> (these can be retrieved via Xen's gitweb at
> https://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=<$hash> which is
> suitable for the `git am` command)
> 
> With these I built 4.14.3-1 and then tried kernels 4.19.181-1 and
> 4.19.194-3 (this system is presently mostly on oldstable).  The results
> were:
> 
> Xen 4.14.3-1 with Linux 4.19.181-1: system reboots were successful
> 
> Xen 4.14.3-1 with Linux 4.19.194-3: system reboots hung

Ok, so it included 0f089bbf43, which is probably the most important of
the 3 fixes that we need indeed. And, it's good that the above
difference is still visible afterwards, since it confirms that we're
looking at two distinct problems.

> Unfortunately I was too quick at installing the rebuilt 4.14.3-1 and I
> missed trying the vanilla Debian 4.14.2+25-gb6a8c4f72d-2 with
> Linux 4.19.181-1.  I believe this combination would have hung during
> reboot.

The Xen related breakage was introduced in 4.14.0+88-g1d1d1f5391-2, so
with that combination, I would expect you would experience both of the
bugs at the same time, yes.

> As such, I believe there are in fact two distinct bugs being observed.
> The presence of EITHER of these is sufficient to cause hangs during
> powerdown or reboot.
> 
> First, some patch originally from Linux's main branch breaks Xen reboots
> was backported somewhere between 4.19.181-1 and 4.19.194-3.  This may
> either have been introduced before 5.10 diverged from main, or may also
> have been backported to 5.10.  THIS is Debian bug #991967.
> 
> Second, the Xen patch 3c428e9ecb1f290689080c11e0c37b793425bef1 which is
> valuable to ARM devices breaks reboots and powerdowns on x86.  This is
> correctly fixed by 0f089bbf43ecce6f27576cb548ba4341d0ec46a8.  Presently
> this has no Debian bug report.

Correct. Thanks a lot for your help with hunting down and confirming this.

And now we have #994899 for it. So, I would like to kindly ask everyone
to stop hijacking this one, #991967, for discussing the Xen problem.

> The first is presently unidentified, someone enthusiastic either needs to
> read git logs/source code, or bisect and build to find where it got
> broken.
> 
> The second we seem to have a fix.  The only question is how many patches
> to cherry pick?  bc141e8ca562 is non-urgent as it is merely superficial
> and not needed for functionality.
> 5a4087004d1a is a workaround for Linux kernel breakage, but how likely
> are we to see that fixed in the Linux kernel packages?  The fix is
> well-contained and needed for some highly popular ARM devices.

Diederik also helped with testing changes, and when combining results,
the best thing we can do is pick the 4 changes that were initially
posted in Nov 2020 as "x86: ACPI and DMI table mapping fixes", and ended
up in Xen 4.15 as well.

 >8 

commit 8b6d55c1261820bb9db8d867ce9ee77397d05203
Author: Jan Beulich 
Date:   Tue Nov 24 11:26:02 2020 +0100

x86/ACPI: fix mapping of FACS

commit f390941a92f102ece1b54be206a602187fd7
Author: Jan Beulich 
Date:   Tue Nov 24 11:26:34 2020 +0100

x86/DMI: fix table mapping when one lives above 1Mb

commit 0f089bbf43ecce6f27576cb548ba4341d0ec46a8
Author: Jan Beulich 
Date:   Tue Jan 5 13:09:55 2021 +0100

x86/ACPI: fix S3 wakeup vector mapping

commit 16ca5b3f873f17f4fbdaecf46c133e1aa3d623b2
Author: Jan Beulich 
Date:   Tue Jan 5 13:11:04 2021 +0100

x86/ACPI: don't invalidate S5 data when S3 wakeup vector cannot be
determined

 >8 

The 4th one is not explicitly tagged with Fixes: 1c4aa69ca1e1, but I
agree with Diederik that we should keep them all together.

I do not know if this is also the thing Chuck tested in the end, but I'm
a bit lost in the walls of text that were produced in these two bugs.

https:/

Bug#990069: Still broken in ssh 8.4p1-5, libc6 2.31-13

2021-10-04 Thread Tim Connors

reopen 990069
thanks.

With these packages installed:

24573,4> dpkg --get-selections | grep ssh
clusterssh  install
libssh-4:amd64  install
libssh-gcrypt-4:amd64   install
libssh2-1:amd64 install
openssh-client  install
openssh-server  install
openssh-sftp-server install
ssh-askpass install
sshfs   install

This particular system is sysv, but I think my other machines suffering
this same problem were already on systemd by the time I upgraded.


24583,14> sudo grep -e ssh -e libc6 -e Restarting -e '^  [a-z]' -e Services  
/var/log/apt/term.log
Replacing files in old package libc6:amd64 (2.28-10) ...
Replacing files in old package libc6:i386 (2.28-10) ...
Preparing to unpack .../06-openssh-sftp-server_1%3a8.4p1-5_amd64.deb ...
Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
Preparing to unpack .../13-openssh-client_1%3a8.4p1-5_amd64.deb ...
Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
Preparing to unpack .../15-openssh-server_1%3a8.4p1-5_amd64.deb ...
Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
Preparing to unpack .../0-libc6-dev_2.31-13_amd64.deb ...
Unpacking libc6-dev:amd64 (2.31-13) over (2.28-10) ...
Preparing to unpack .../libc6_2.31-13_i386.deb ...
De-configuring libc6:amd64 (2.28-10) ...
Unpacking libc6:i386 (2.31-13) over (2.28-10) ...
Preparing to unpack .../libc6_2.31-13_amd64.deb ...
Unpacking libc6:amd64 (2.31-13) over (2.28-10) ...
Setting up libc6:amd64 (2.31-13) ...
Restarting services possibly affected by the upgrade:
  smbd: restarting...done.
  openbsd-inetd: restarting...done.
  exim4: restarting...done.
  cron: restarting...done.
  autofs: restarting...done.
  atd: restarting...done.
Services restarted successfully.
Setting up libc6:i386 (2.31-13) ...
Preparing to unpack .../libc6-dbg_2.31-13_amd64.deb ...
Unpacking libc6-dbg:amd64 (2.31-13) over (2.28-10) ...
Restarting services possibly affected by the upgrade:
  samba-ad-dc: stopping...starting...done.
  smbd: stopping...starting...done.
  exim4: stopping...starting...done.
  cron: stopping...starting...done.
  atd: stopping...starting...done.
Services restarted successfully.
Preparing to unpack .../137-libssh-gcrypt-4_0.9.5-1+deb11u1_amd64.deb ...
Unpacking libssh-gcrypt-4:amd64 (0.9.5-1+deb11u1) over (0.8.7-1+deb10u1) ...


At this point, there's:
24572,2> ls -lA /etc/init.d/ssh*
-rwxr-xr-x 1 root root 3939 Feb  1  2020 /etc/init.d/ssh
-rwxr-xr-x 1 root root 4056 Mar 13  2021 /etc/init.d/ssh.dpkg-new

and ssh isn't yet started - I did that manually because I knew the problem
was going to arise.




-- 
Tim Connors

Bug#995695: ITP: rinutils -- A C11 utilities header library


Package: wnpp
Severity: wishlist
Owner: Shlomi Fish 
Control: block -1 by 993764

* Package name: rinutils
  Version : 0.10.0
  Upstream Author : Shlomi Fish
* URL : https://github.com/shlomif/rinutils
* License : Expat
  Programming Lang: C
  Description : A C11 utilities header library

This is a set of C headers containing macros and static functions that are expected to 
work on Unix-like systems and MS Windows that have been extracted from Shlomi Fish´s projects.


They include:

sizeof-aware wrappers for malloc()/realloc()

COUNT() and LAST() macros.

DLLEXPORT symbols-modifiers.

likely() and unlikely() CPU branch-prediction hints (see Stack Overflow 
question).

long long sprintf()-formats

min() and max()

rinutils/portable_time.h for cross-platform time querying.

Some string utilities as inline functions.

typeof_wrap.h for C++-"auto"-like macros.

GCC_UNUSED for silencing warnings.

rinutils/rin_cmocka.h for reducing cmocka’s boilerplate.

Bug#989649: libjs-mathjax: integrate with dh_sphinxdoc

2021-10-04 Thread Drew Parsons

Source: mathjax
Followup-For: Bug #989649

It's not always so simple as adding the conf.py patch.

For the example of fenics-dolfinx 0.3.0-3 (in experimental), the
lintian privacy-breach-generic warning complains about

  https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js
  
But there is no local tex-mml-chtml.js file to replace it with.

Bug#995696: ITP: casa-formats-io -- Code to handle I/O from/to data in CASA format

2021-10-04 Thread Ole Streicher


Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
debian-as...@lists.debian.org

* Package name: casa-formats-io
  Version : 0.1
  Upstream Author : Thomas Robitaille
* URL : http://casa-formats-io.readthedocs.org
* License : LGPL
  Programming Lang: Python
  Description : Code to handle I/O from/to data in CASA format

The casa-formats-io package is a small package which implements functionality 
to read data stored in CASA formats (such as .image datasets). This 
implementation is independent of and does not use casacore. The motivation for 
this package is to provide efficient data access via dask arraye, 
cross-platform data access, and data access with all modern Python versions.

It is a new build dependency of the "spectral-cube" package. I will maintain it
within the Debian Astro team in Salsa:

https://salsa.debian.org/debian-astro-team/casa-formats-io

Best regards

Ole

Bug#993764: RFS: rinutils 0.10.0-0.1 [NMU] - a C headers library used by Shlomi Fish's projects

Control: tags -1 - moreinfo

On Mon, 4 Oct 2021 09:30:00 +0300 Shlomi Fish  wrote:

On Fri, 1 Oct 2021 12:46:26 +0200 Bastian Germann  wrote:
> This is not an NMU because this software is non-existing in Debian.
> Please file an ITP for it. 

Thanks, seems better now after your change.

I added an ITP for you. Please add (Closes: #995695) in the package's changelog.
Please remove the NMU in the changelog and adjust the Debian revision 
accordingly.
You should target unstable or experimental with your first version.

Please also fix these lintian warnings:

I: rinutils source: unused-override debian-watch-file-is-missing

I: librinutils-dev: wrong-section-according-to-package-name librinutils-dev => 
libdevel

Bug#995697: [INTL:sv] Swedish strings for tzdata debconf

2021-10-04 Thread Martin Bagge / brother


package: tzdata
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother
# Swedish translation of tzdata.
# Copyright: This file is in the public domain.
# This file is distributed under the same license as the tzdata package.
#
# Christer Andersson , 2008.
# Martin Bagge , 2008, 2011, 2013, 2021
msgid ""
msgstr ""
"Project-Id-Version: sv\n"
"Report-Msgid-Bugs-To: tzd...@packages.debian.org\n"
"POT-Creation-Date: 2021-09-29 00:36+0200\n"
"PO-Revision-Date: 2021-10-04 12:32+0200\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Africa"
msgstr "Afrika"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "America"
msgstr "Amerika"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Antarctica"
msgstr "Antarktis"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Australia"
msgstr "Australien"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Arctic"
msgstr "Norra Ishavet"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Asia"
msgstr "Asien"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Atlantic"
msgstr "Atlanten"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Europe"
msgstr "Europa"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Indian"
msgstr "Indiska Oceanen"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:1001 ../tzdata.templates:12001
msgid "Pacific"
msgstr "Stilla Havet"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "US"
msgstr "US"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Etc"
msgstr "Etc"

#. Type: select
#. Description
#: ../tzdata.templates:1002
msgid "Geographic area:"
msgstr "Geografiskt område:"

#. Type: select
#. Description
#: ../tzdata.templates:1002
msgid ""
"Please select the geographic area in which you live. Subsequent "
"configuration questions will narrow this down by presenting a list of "
"cities, representing the time zones in which they are located."
msgstr ""
"Välj det geografiska område du bor i. Följande konfigurationsfrågor kommer "
"att begränsa detta genom att presentera en lista med städer, som "
"representerar de tidszoner i vilka de är placerade."

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Abidjan"
msgstr "Abidjan"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Accra"
msgstr "Accra"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Addis_Ababa"
msgstr "Addis Abeba"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Algiers"
msgstr "Alger"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Asmara"
msgstr "Asmara"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Bamako"
msgstr "Bamako"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Bangui"
msgstr "Bangui"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.

Bug#994899: Bug#991967: Simply ACPI powerdown/reset issue?

2021-10-04 Thread Diederik de Haas

On Monday, 4 October 2021 11:46:54 CEST Hans van Kranenburg wrote:
> The 4th one is not explicitly tagged with Fixes: 1c4aa69ca1e1, but I
> agree with Diederik that we should keep them all together.

Context: Those 4 are part of 1 patch-set posted here:
https://lists.xen.org/archives/html/xen-devel/2020-11/msg01516.html

The 5th was already debatable and I choose to include it in my MR, but I'm fine 
with not including that one.

Cheers,
  Diederik

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

Bug#824594: please support DPKG_ROOT in base-files' postinst

2021-10-04 Thread Santiago Vila

Hi.

I guess what bothers me about this is the "specification" more than
the implementation.

Looking at the original report, I read this:

> It will point to the installation root with the trailing slash
> stripped. That means under normal conditions, it is empty.

So, if I understood correctly:

- if installation root is / then DPKG_ROOT is ""
- but if it's /mnt then DPKG_ROOT is "/mnt"

I guess this is unlikely to change at this point, however: Would not
have been cleaner to specify it as the installation root (without the
"trailing slash stripped" part).

Another question: Can you explain the usage of ":" command at the beginning?

: "${DPKG_ROOT:=}"

This is to define DPKG_ROOT as the empty string in case it's undefined,
right? Is this really needed in a POSIX shell? I believed ${DPKG_ROOT}
would expand to empty string when it's not defined.

Or maybe you meant this? : "${DPKG_ROOT:=/}"


Also: just to be sure: Am I right to think that the sed command in
change_owner function is there to be able to bootstrap a Debian system
from a non-Debian system?

And finally: Do we really need to consider DPKG_ROOT in
update_to_current_default function? (It should only used on upgrades).

Thanks.

Bug#995685: dictionaries-common: Failed to upgrade from 1.28.7

2021-10-04 Thread Jochen Sprickerhof


Control: tag -1 patch

Hi,

* Nelson A. de Oliveira  [2021-10-04 00:15]:

While upgrading dictionaries-common from 1.28.7 to 1.28.10:

=
Configurando dictionaries-common (1.28.10) ...
dmihd: No hunspell dir passed or available
dpkg: error processing package dictionaries-common (--configure):
installed dictionaries-common package post-installation script subprocess 
returned error exit status 2
(…)
dpkg: dependency problems prevent configuration of aspell-pt-br:
aspell-pt-br depende de dictionaries-common (>= 1.23~); porém:
 Pacote dictionaries-common não está configurado ainda.

dpkg: error processing package aspell-pt-br (--configure):
problemas de dependência - deixando desconfigurado
(…)
Erros foram encontrados durante o processamento de:
dictionaries-common
aspell-pt-br
E: Sub-process /usr/bin/dpkg returned an error code (1)
=


I ran into the same problem on a system with no hunspell dictionaries 
installed. The attached patch fixes the problem for me.


Cheers Jochen
diff --git a/scripts/perl5/Debian/DictionariesCommon.pm.in b/scripts/perl5/Debian/DictionariesCommon.pm.in
index 48edc11..e3ac624 100644
--- a/scripts/perl5/Debian/DictionariesCommon.pm.in
+++ b/scripts/perl5/Debian/DictionariesCommon.pm.in
@@ -425,8 +425,8 @@ sub dc_merge_installed_hunspell_dicts {
   my $hunspelldir = shift;
   my $main_dicts  = shift;
 
-  die "dmihd: No hunspell dir passed or available\n" unless ( -d $hunspelldir);
   $main_dicts = {} unless $main_dicts;
+  return $main_dicts unless ( -d $hunspelldir);
 
   my @hunspell_aff = <$hunspelldir/*.aff>;
   my $parsed_dicts = {};


signature.asc
Description: PGP signature

Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2

2021-10-04 Thread Reinhard Tartler

Hi Paul,

On Sun, Oct 3, 2021 at 12:39 PM Paul Gevers  wrote:

> Hi Reinhard,
>
> > The consistent OOM is surprising given that you state that the worker
> > has 250GB of RAM. Looking at the logs,
> > I note that the tests are being passed the option -p 160 by the
> > dh-golang helper, so it will build
> > and run test executables concurrently. That confirms to me that we are
> > indeed running on these 250GB/160 core workers.
>
> We only have one armhf host, so *all* armhf tests are run there. I'm
> also not seeing this problem back in the logs:
>
> https://ci.debian.net/munin/ci-worker-armel-01/ci-worker-armel-01/memory.html
> .
> But maybe the incident is too short to be caught by the once per 5
> minutes poll.
>

I think this might be the case. The whole package fails (or passes) usually
in less than 5 minutes.
These incidents would be very, very spiky. Probably something that captures
the maximum
values in the 5 minute interval would be more useful here.

> Is it possible that armhf is setting up ulimits that limits the amount
> > of memory the test may allocate?
>
> root@ci-worker-armel-01:~# ulimit
> unlimited
>
> > As far as I understand, all golang packages use autodep8 to declare the
> > tests,
> > which doesn't support adding the Architecture field.
>
> I think you're right, but maybe we should fix autodep8 to enable the
> change like the other overwrites in section `PACKAGE-SPECIFIC
> CONFIGURATION` of $(man autodep8).
>
> > In order to get
> > around this,
> > I guess I could remove the Testsuite field from debian/control and add a
> > debian/tests/control that looks similar to what autodep8 generates, but
> adds
> > the Architecture: !armhf  restriction.
>
> Maybe until autodep8 is fixed? I fear that this may cause future trouble
> if/when autodep8 support for golang gets updated.
>
Sure, I've cobbled up
https://salsa.debian.org/ci-team/autodep8/-/merge_requests/25 for this.

I've went ahead and implemented my limiting idea anyways:
https://salsa.debian.org/go-team/packages/golang-github-klauspost-compress/-/commit/836de264a300e102a54055c1e3d629f82a1e8a1b
Maybe Adrian is right and with too many goroutines going on at the same
time,
the test executable does exhaust the 3GB memory limitation on a 32bit
architecture.
debhelper has this convenient --max-parallel switch that I used in
combination with
setting GOMAXPROCS=8 to limit the number of goroutines in the test.

the most recent test on armhf passes with no noticeable slowdown. Maybe we
could go
higher than 8, but finding out the optimal number does not seem like a good
use of
our time.

Thanks for your help and input!

-- 
regards,
Reinhard

Bug#994173: completion broken on "apt-get u"

2021-10-04 Thread Philipp Marek


Hi Gabriel,


I could not reproduce this bug, even though I tried every version all
the way down to 1:2.10-2. Here's what I get:


Yeah, something else is broken - I had the same problem
with 5.1-2+b3/1:2.11-2 recently.


Perhaps I can find out what went wrong...
do you have any ideas? readline settings,
some shell function interfering (wrong completion load order?), ...??


Next time that happens, I'll dump all functions and env vars,
and compare to a working shell setup...

Bug#995661: ITS: utfcpp

2021-10-04 Thread Boyuan Yang

Hi,

在 2021-10-04星期一的 07:55 +0200，Mathieu Malaterre写道：
> Hi !
> 
> On Sun, Oct 3, 2021 at 8:27 PM Boyuan Yang  wrote:
> > 
> > Source: utfcpp
> > Version:  2.3.4-1.1
> > Severity: important
> > X-Debbugs-CC: ma...@debian.org
> > 
> > Dear package utfcpp maintainers in Debian,
> > 
> > After looking into the package you maintain (utfcpp,
> > https://tracker.debian.org/pkg/utfcpp), I found that this package
> > received no maintainer updates in the past 8 years with no activity on
> > Debian
> > BTS system. As a result, I am filing an ITS (Intent to Salvage) request
> > against your package according to section 5.12 in Debian's Developers'
> > Reference [1] with the intent to take over package maintenance in Debian.
> 
> Thanks for volunteering ! I must admit I have lost interest in this
> package. There is no need to add me in the maintainer list, I am not
> sure I'll be of great help.

Thanks, I will proceed to maintain this package. Thank you for your past work!

Regards,
Boyuan Yang

Bug#951331: hexchat apparmor profile

2021-10-04 Thread Mattia Rizzolo

Control: tag -1 moreinfo

Hi Patrick,

I realize only now that you probably haven't seen this email from Seth,
since he sent it only to the bug report and not also to the reporters.

Could you please revise your patch following their suggestions?

https://bugs.debian.org/951331#23


- Mattia

On Sat, Feb 29, 2020 at 04:30:59AM +, Seth Arnold wrote:
> Hello Mattia, Patrick,
> 
> Thanks so much for proposing an AppArmor profile for HexChat.
> 
> I've got a few comments; I'll paste in the entire 'main' block of the
> profile, and add my comments inline.:
> 
> 
> ## Copyright (C) 2014 troubadour 
> ## Copyright (C) 2014 - 2019 ENCRYPTED SUPPORT LP 
> ## See the file COPYING for copying conditions.
> 
>#include 
>#include 
>#include 
>#include 
>#include 
>#include 
>#include 
> 
> This should also #include 
> 
>deny @{PROC}/** r,
> 
>@{HOME}/ r,
>@{HOME}/.config/** rwk,
>@{HOME}/.xchat2/ r,
>@{HOME}/.xchat2/** rwixk,
>@{HOME}/.config/ r,
>@{HOME}/.config/hexchat/ r,
>@{HOME}/.config/hexchat/** rwixk,
>@{HOME}/.kde/share/config/gtkrc-2.0 r,
>@{HOME}/.kde/share/config/oxygenrc r,
>@{HOME}/.*/lib/python*/** r,
> 
>/bin/grep rix,
>/bin/uname rix,
>/bin/mkdir rix,
>/bin/rm rix,
> 
>/usr/bin/grep rix,
>/usr/bin/uname rix,
>/usr/bin/mkdir rix,
>/usr/bin/rm rix,
> 
>/dev/tty rwix,
>/dev/null rw,
> 
>/etc/passwd r,
>/etc/group r,
>/etc/host.conf r,
>/etc/hosts r,
>/etc/resolv.conf r,
>/etc/gai.conf r,
>/etc/nsswitch.conf r,
> 
> The lines between /etc/passwd and /etc/nsswitch.conf could be removed with
> abstractions/nameservice added.
> 
>/etc/ld.so.cache r,
>/etc/machine-id r,
>/etc/os-release r,
>/etc/xdg/xfce4/helpers.rc r,
>/etc/xfce4/defaults.list r,
>/etc/python*/sitecustomize.py r,
> 
>/lib/*-linux-gnu/** mr,
> 
> This line is very broad -- and overlaps with a lot of the libraries listed
> in abstractions/base -- if you found any libraries that are DENIED because
> they don't match a rule already in abstractions/base, it would be best to
> list them with a specific rule.
> 
>/usr/bin/xchat rix,
>/usr/bin/xdg-open rix,
>/usr/bin/dbus-send rix,
>/usr/bin/xprop  rix,
>/usr/bin/exo-open rix,
>/usr/bin/sensible-browser rix,
>/usr/bin/zenity rix,
>/usr/bin/torbrowser rix,
>/usr/bin/basename rix,
>/usr/bin/kde4-config rix,
>/usr/bin/aplay rix,
> 
> I'm really worried about these. I can appreciate trying to provide a
> profile that lets people click on links as usual, but actually running
> these applications in hexchat's profile will lead to bugs.
> 
> This also means the hexchat profile may need to be much wider, just to
> accomodate these other programs.
> 
> 
>/usr/lib/*-linux-gnu/** mrix,
> 
> This line is also very broad -- and shouldn't be needed with
> abstractions/base.
> 
>/usr/lib/xchat/plugins/* mr,
>/usr/lib/perl*/** mr,
>/var/lib/snapd/desktop/applications/ r,
> 
> Granting permission to read this directory without permission to read the
> *.desktop files is a bit wasted. What happens if this is denied?
> 
>## The Ux permission is too dangerous to be enabled by default.
>#/usr/lib/firefox-esr/firefox* Ux,
> 
>/usr/lib/python*/lib-dynload/*.so mr,
> 
>/usr/local/lib/python*/dist-packages/ r,
>/usr/local/lib/python*/dist-packages/* r,
> 
>/usr/share/icons/** r,
>/usr/share/enchant/* r,
>/usr/share/myspell/dicts/ r,
>/usr/share/hunspell/ r,
>/usr/share/hunspell/* r,
>/usr/share/ca-certificates/** r,
>/usr/share/xfce4/helpers/* r,
>/usr/share/xfce4/applications/ r,
>/usr/share/xfce4/applications/mimeinfo.cache r,
>/usr/share/zenity/* r,
>/usr/share/fontconfig/** r,
>/usr/share/poppler/cMap/ r,
>/usr/share/poppler/cMap/** r,
>/usr/share/perl*/** mr,
>/usr/share/tcltk/tcl8.5/* r,
>/usr/share/pyshared/* r,
>/usr/share/aspell/ r,
>/usr/share/aspell/** r,
> 
>/var/lib/aspell/* r,
> 
>/run/*/resolv.conf r,
> 
> This shouldn't be needed with abstractions/nameservice added.
> 
> 
> I know that the helper applications is a difficult point here. The more
> secure option is to prevent them from being used. The friendliest option
> is to use PUx execution rules to either launch them confined, if the user
> has profiles for them, or unconfined, if the user doesn't have profiles.
> 
> But having an unconfined way out of the profile drastically reduces the
> value of the profile.
> 
> Desktop applications are difficult to confine because many users want to
> use them to do everything. Other users don't mind some restrictions for
> security gains. And it's very hard to provide one profile for both.
> 
> It may not make sense to enable the profile by default. I'd rather have
> the tighter profile, without helper applications, but that may not reflect
> what most users would actually want.
> 
> Thanks

Bug#995332: Package reinstalls/upgrades with files on FAT partitions fail

2021-10-04 Thread MichaIng


Hi,

many thanks for your reply and linking that FAQ, this clarifies things. 
I also found the linked older bug report about the very same question: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825945


I personally would prefer more compatibility here, possibly combined 
with a flag to confirm direct overwrite of files without backup link. 
The benefit of a FAT /boot partition is precisely that it is easily 
possible to access and fix it from other OSes, so the acknowledged risk 
of an unbootable system in case of a power loss during file writes is 
somehow covered by the very reason why one chose such a partitioning.


As said, there is hardware which simply requires the boot partition to 
be FAT, and the workarounds for this dpkg limitation force package 
maintainers/admins to use much riskier methods, like removing all 
existing kernel files via kernel preinst hook, which extends the time 
frame significantly in which a power loss would render the system 
unbootable, compared to having that risk during individual file write 
only. Common reasons on such systems for being unbootable are not 
because of a failed package install or power loss, but because of the 
kernel or bootloader or initramfs itself being faulty, falsely generated 
or falsely configured and in such case it is very helpful if the 
filesystem can be accessed and fixed from e.g. Windows or macOS.


Just to clarify: I know this mostly from ARM SBCs, which are currently 
still mostly shipped with a manufacturer or 3rd party kernel and 
bootloader (not the Debian ones) and a /boot FAT partition is either 
strictly required by the hardware or explicitly chosen by the image 
provider, for mentioned reasons, despite the difficulties with dpkg. If 
dpkg would support FAT, it would lower the risk of kernel package 
installs on those systems.


In the FAQ it is mentioned

> As part of the dpkg credo, preserving human configuration is of 
utmost importance


and one could see a FAT partition mounted into root as a human 
configuration decision, despite the obvious downsides and limitations of 
FAT. And the question is whether this decision itself is seen as the 
bigger risk, or the workarounds done to cover the missing dpkg support 
for it.


However, I see that this is a long done design decision, I fully 
understand the reasons behind it and the chance to change that hence 
being close to zero. So yes feel free to close the issue :).


Best regards,

Micha

Bug#995699: pymol: Please update the build-depends to libglew-dev

Package: pymol
Severity: normal

As part of the glew transition, libglew1.5-dev is going away, while building 
against libglew-dev works.
Please update the build-depends accordingly.

Thanks
Alastair



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

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

Versions of packages pymol depends on:
pn  python3-pymol  

Versions of packages pymol recommends:
pn  apbs  

pymol suggests no packages.

Bug#995700: phlipple: Please update the build-depends to libglew-dev

Package: phlipple
Severity: normal

As part of the glew transition, libglew1.5-dev is going away, while building 
against libglew-dev works.
Please update the build-depends accordingly.

Thanks
Alastair



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

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

Bug#995698: rlvm: Please update the build-depends to libglew-dev

Package: rlvm
Severity: normal

As part of the glew transition, libglew1.5-dev is going away, while building 
against libglew-dev works.
Please update the build-depends accordingly.

Thanks
Alastair



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

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

Versions of packages rlvm depends on:
pn  fonts-vlgothic | fonts-japanese-gothic  
pn  libboost-filesystem1.74.0   
ii  libboost-iostreams1.74.01.74.0-9
pn  libboost-program-options1.74.0  
pn  libboost-serialization1.74.0
ii  libc6   2.31-13
ii  libgcc-s1   10.2.1-6
ii  libgl1  1.3.2-1
ii  libglew2.1  2.1.0-4+b1
ii  libglib2.0-02.66.8-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libgtk2.0-0 2.24.33-2
pn  libguichan-0.8.1-1v5
pn  libguichan-opengl-0.8.1-1v5 
pn  libguichan-sdl-0.8.1-1v5
ii  libjpeg62-turbo 1:2.0.6-4
ii  libpng16-16 1.6.37-3
pn  libsdl-image1.2 
pn  libsdl-mixer1.2 
pn  libsdl-ttf2.0-0 
pn  libsdl1.2debian 
ii  libstdc++6  10.2.1-6
ii  libvorbisfile3  1.3.7-1

rlvm recommends no packages.

Versions of packages rlvm suggests:
ii  ttf-dejavu-core  2.37-1

Bug#995701: tzdata: [INTL:ko] Korean debconf templates translation

2021-10-04 Thread Changwoo Ryu

Package: tzdata
Version: 2021c-1
Severity: wishlist
Tags: l10n patch

Please find the attached the debconf templates translation into Korean.



--
Changwoo Ryu
# tzdata debconf templates translation
# This file is distributed under the same license as the tzdata package.
# Changwoo Ryu , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: tzdata\n"
"Report-Msgid-Bugs-To: tzd...@packages.debian.org\n"
"POT-Creation-Date: 2021-09-29 00:36+0200\n"
"PO-Revision-Date: 2021-10-04 20:49+0900\n"
"Last-Translator: Changwoo Ryu \n"
"Language-Team: Debian L10N Korean \n"
"Language: Korean\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Africa"
msgstr "아프리카"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "America"
msgstr "아메리카"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Antarctica"
msgstr "남극"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Australia"
msgstr "오스트레일리아"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Arctic"
msgstr "북극"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Asia"
msgstr "아시아"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Atlantic"
msgstr "대서양"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Europe"
msgstr "유럽"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Indian"
msgstr "인도양"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:1001 ../tzdata.templates:12001
msgid "Pacific"
msgstr "태평양"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "US"
msgstr "미국"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Etc"
msgstr "기타"

#. Type: select
#. Description
#: ../tzdata.templates:1002
msgid "Geographic area:"
msgstr "지리적 지역:"

#. Type: select
#. Description
#: ../tzdata.templates:1002
msgid ""
"Please select the geographic area in which you live. Subsequent "
"configuration questions will narrow this down by presenting a list of "
"cities, representing the time zones in which they are located."
msgstr "거주하고 있는 지리적 지역을 선택하십시오. 이후의 설정 질문에서는 지역을 특정하려고 도시의 목록을 표시합니다. 표시하는 도시는 
도시 위치의 표준 시간대를 나타냅니다."

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Abidjan"
msgstr "아비장"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Accra"
msgstr "아크라"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Addis_Ababa"
msgstr "아디스아바바"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Algiers"
msgstr "알제"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Asmara"
msgstr "아스마라"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Bamako"
msgstr "바마코"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Bangui"
msgstr "방기"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Banjul"
msgstr "반줄"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Bissau"
msgstr "비사우"

#. Type: select
#. Choices
#.

Bug#995685: dictionaries-common: Failed to upgrade from 1.28.7

2021-10-04 Thread Agustin Martin

El lun, 4 oct 2021 a las 13:09, Jochen Sprickerhof
() escribió:
>
> Control: tag -1 patch

Hi,

Thanks for your feedback.

Do not know why your mail took this long to reach the BTS. In the
meantime 1.28.11 was uploaded and I think should fix this problem.
Please check.

Regards,

---
Agustin

Bug#995662: info-beamer: Please change build-depends to libglew-dev

Package: info-beamer
Followup-For: Bug #995662

As part of the glew transition, libglew1.5-dev is going away, while building 
against libglew-dev works.
Please update the build-depends accordingly.

Thanks
Alastair


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

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

Versions of packages info-beamer depends on:
ii  libavcodec587:4.3.2-0+deb11u2
ii  libavformat58   7:4.3.2-0+deb11u2
ii  libavutil56 7:4.3.2-0+deb11u2
ii  libc6   2.31-13
pn  libdevil1c2 
ii  libevent-2.1-7  2.1.12-stable-1
pn  libftgl2
ii  libgl1  1.3.2-1
ii  libglew2.1  2.1.0-4+b1
pn  libglfw3
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  liblua5.1-0 5.1.5-8.1+b3
ii  libswscale5 7:4.3.2-0+deb11u2

info-beamer recommends no packages.

info-beamer suggests no packages.

Bug#995702: TypeError: Cannot read property 'prefix_exceptions' of undefined

2021-10-04 Thread Dominik George

Package: node-autoprefixer
Version: 10.3.1.0+dfsg1+~cs14.6.19-1
Severity: grave
Justification: renders package unusable

autoprefixer currently does not work because it handles the agents
imported from caniuse-lite wrongly:


  /usr/share/nodejs/autoprefixer/lib/browsers.js:64
  let prefix = data.prefix_exceptions && data.prefix_exceptions[version]
  ^

  TypeError: Cannot read property 'prefix_exceptions' of undefined
  at Browsers.prefix (/usr/share/nodejs/autoprefixer/lib/browsers.js:64:23)
  at /usr/share/nodejs/autoprefixer/lib/prefixes.js:193:54
  at Array.map ()
  at Prefixes.select (/usr/share/nodejs/autoprefixer/lib/prefixes.js:193:31)
  at new Prefixes (/usr/share/nodejs/autoprefixer/lib/prefixes.js:133:53)
  at loadPrefixes 
(/usr/share/nodejs/autoprefixer/lib/autoprefixer.js:111:22)
  at Object.prepare 
(/usr/share/nodejs/autoprefixer/lib/autoprefixer.js:121:22)
  at /usr/share/nodejs/postcss/lib/lazy-result.js:133:39
  at Array.map ()
  at new LazyResult (/usr/share/nodejs/postcss/lib/lazy-result.js:131:43)


The problem comes from /usr/share/nodejs/autoprefixer/lib/autoprefixer.js:

  let { agents } = require('caniuse-lite')

The object loaded here contains another object called agents. For me, changing 
line 10
fixes the issue:

  - let autoprefixerData = { browsers: agents, prefixes: dataPrefixes }
  + let autoprefixerData = { browsers: agents.agents, prefixes: dataPrefixes }

I have no idea how this problem came to be, and how to properly fix it. Might be
an incompatibility between the versions of autoprefixer and canisue-lite?

-- 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_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages node-autoprefixer depends on:
ii  node-browserslist  4.17.0+~cs5.6.76-1
ii  node-caniuse-lite  1.0.30001224+dfsg-2
ii  node-normalize-range   0.1.2-2
ii  node-postcss [node-colorette]  8.2.1+~cs5.3.23-8
ii  node-postcss-value-parser  4.1.0-2
ii  nodejs 12.22.5~dfsg-5

node-autoprefixer recommends no packages.

node-autoprefixer suggests no packages.

-- no debconf information

Bug#995685: dictionaries-common: Failed to upgrade from 1.28.7

2021-10-04 Thread Jochen Sprickerhof


Hi Agustin,

* Agustin Martin  [2021-10-04 13:53]:

Do not know why your mail took this long to reach the BTS.


That's a known problem between my provider and the BTS. Normally I send 
through master.d.o because of that seems like I broke that config 
recently.



In the
meantime 1.28.11 was uploaded and I think should fix this problem.
Please check.


Looks good to me, thanks for fixing the issue and sorry for the noise.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#995703: opendmarc: Segfault when processing ARC-Seal headers

2021-10-04 Thread David Bürgin

Package: opendmarc
Version: 1.4.0~beta1+dfsg-6
Severity: important

OpenDMARC crashes when parsing certain ARC-Seal headers.

This bug was reported upstream. See:
https://github.com/trusteddomainproject/OpenDMARC/issues/183

In Debian, it is patched in 1.4.1.1-1.

However, we might want to update Debian stable with a patch, too.

Bug#995672: cockpit-machines: 253-1 fails to build via apt-src

2021-10-04 Thread Martin Pitt

Control: severity -1 normal
Control: tag -1 unreproducible moreinfo

Hello Friedemann,

Friedemann Schorer [2021-10-03 23:40 +0200]:
> Severity: serious

That feels inflated to me. The package builds fine in official buildds [1], in
upstream CI (which uses pbuilder) and locally in a debian-sid container, and it
is really quite harmless -- the build is more or less "install a bunch of
files". Also, the error message below doesn't even get to the point where it
even attempts to build c-machines, it seems to fail early in apt-src's
name-to-location mapping? So that's certainly not a regression compared to the
testing version.

[1] https://buildd.debian.org/status/package.php?p=cockpit-machines

> Got the latest source packages for cockpit-machines 253-1, unpacked them
> locally via 'dpkg-source -x', made the source known to apt-src ('apt-src
> import cockpit-machines --location cockpit-machines-253') and tried to
> build it.
> Here's the output:
> 
>  ~/build: apt-src list
>  
> i   cockpit-machin 253-1  /home/frschorer/build/cockpit-machines-253  
>  
>  ~/build: apt-src build cockpit-machines  
> 
> E: Not installed
> 
> When I import the sourcetree of cockpit 254-1 from unstable sources,
> too,  and then try to build cockpit-machines apt-src builds the other cockpit 
> packages instead.

I never used apt-src, so I'm trying to reproduce this:

  sudo apt install -y apt-src
  cd /tmp 
  apt-get source cockpit-machines
  apt-src import cockpit-machines --location cockpit-machines-253/
  apt-src build cockpit-machines
  
the latter works:

> dpkg-buildpackage: info: source package cockpit-machines
> dpkg-buildpackage: info: source version 253-1
> [...]
> dpkg-deb: building package 'cockpit-machines' in 
> '../cockpit-machines_253-1_all.deb'.
> dpkg-buildpackage: info: binary-only upload (no source included)
> I: Successfully built in /tmp/cockpit-machines-253

Do these exact commands work for you? What did you do differently? How does your
~/.apt-src/status file look like? If you move it away, or try this as a
different user, what result do you get?

Thanks,

Martin

Bug#968417: netkit-ftp-ssl: Please backport ftp-ssl to buster


On Fri, 14 Aug 2020 20:32:03 -0400 William Blough  wrote:

Since ftp-ssl did not make it into buster, there do not appear to be any
command line ftp clients in buster that support ssl/tls.


There are at least tnftp, curl, and lftp. Please use one of them.

Bug#995693: cockpit-machines: Request to build for bullseye-backports

2021-10-04 Thread Martin Pitt

Control: tag -1 pending

Hello José,

José Miguel Gonçalves [2021-10-04 10:29 +0100]:
> I would like to try cockpit-machines v251 in bullseye but that is currently 
> not possible because, while cockpit v251 package is released in 
> bullseye-backports, cockpit-machines is not.
> Please build cockpit-machines v251 for bullseye-backports. 

Thanks for the reminder! I wanted to do that anyway. I uploaded
cockpit-machines_251-1~bpo10+1.dsc, it'll be in the backports NEW queue for a
while.

Martin

Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

2021-10-04 Thread Ryan Thoryk


Upstream made a couple of commits which fix the Jack issue for me:
https://gitlab.gnome.org/GNOME/glibmm/-/commit/b67b77cb8cd37a7ec33ad15702831ab45ced7f64
https://gitlab.gnome.org/GNOME/glibmm/-/commit/f8b8e70fee19487df19019b4f8810715a7c77ad0

nos...@kota.moe also made some test code that triggers the bug, the bug 
goes away after commits.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#995569: debhelper: act on service files placed in usr/lib/systemd/system

2021-10-04 Thread wferi

Niels Thykier  writes:

> Unfortunately, I have no intention of acting on this request until the
> tech-ctte has resolved their advice on how they want the /usr-merge
> transition to be resolved (per #995569).
> [...]
> I wish I could provide you with something better, but I am personally
> not ready to invest in implementing this feature while there is a
> considerably risk that I would need to revert it again or it would be
> interpreted as "promoting dissent" against the upcoming /usr-merge
> transition[1].
> [...]
> [1] I have raised objections in public about some of the /usr-merge
> transition plans. I feel this is not an entirely theoretical concern
> that other project members would see it as a statement from me if I was
> to implement this feature without the explicit approval of the tech-ctte
> at this point in time.

Hi Niels,

Wow.  Ugh.  Thanks for your elaborate answer.  Don't worry, I can
certainly live without this feature, and I'm perfectly fine with this
aspect being handled as a minor bullet point in the eventual /usr-merge
transition plan.  The main point of my report was to avoid losing sight
of the issue.  And you've already ensured that. :)
-- 
Thanks again,
Feri

Bug#995702: TypeError: Cannot read property 'prefix_exceptions' of undefined

2021-10-04 Thread Dominik George

>   - let autoprefixerData = { browsers: agents, prefixes: dataPrefixes }
>   + let autoprefixerData = { browsers: agents.agents, prefixes: dataPrefixes }

It's
https://github.com/browserslist/caniuse-lite/commit/fde289588b2ccb129ba3d1552134be2c78fee8b7

So, this happened with a recent update of node-autoprefixer, because
the new autoprefixer relies on the new API of caniuse-lite.

caniuse-lite should, and will at some point, be updated in Debian as
well. However, this will break node-browserslist, because that relies
on the old API. Oh the joy!

Proposal:

 1. Add a patch to node-autoprefixer to use the old API
 2. Add a version constraint to the node-caniuse-lite dependency in
node-autoprefixer (<< 1.0.30001226~)
 3. Report a bug against node-caniuse-lite to update to the current
upstream version, with a gentle hint on what will break if updated
 4. Once updated, drop the patch, and remove the version constraint

@ JavaScript team, shall I proceed with that?

-nik


signature.asc
Description: PGP signature

Bug#980025: nextcloud-desktop: Nextcloud-desktop starts but window doesn't display properly and disappears in GNOME

2021-10-04 Thread Simon McVittie

Control: reassign -1 gnome-shell,nextcloud-desktop
Control: found -1 nextcloud-desktop/3.0.1-3
Control: tags -1 + unreproducible moreinfo

On Tue, 19 Jan 2021 at 18:15:29 +0100, Sandro Knauß wrote:
> This sounds not like the fault of nextcloud-desktop and I cannot reproduce it 
> under a KDE environment. that's why lowering the severity and forward to 
> gnome-shell.

I tried installing nextcloud-desktop and connecting it to the test
instance offered by , and I couldn't reproduce
this in a GNOME environment either. The original report could have been
a gnome-shell bug, or a nextcloud-desktop bug - we don't really have
any evidence either way - so I'm assigning this to both.

Does this still happen in an up-to-date testing/unstable installation,
or in an up-to-date installation of Debian 11 'bullseye'?

If yes, which gnome-shell version?

If you create a new temporary user account on the same system (so that
the new user does not have any special configuration), can you reproduce
the problem with  as the new user? If so,
please explain how?

Thanks,
smcv

Bug#993338: octave: Setting up octave fails due to missing libGL.so.1

2021-10-04 Thread Andreas Beckmann


Hi all,

On 15/09/2021 05.16, Guillem Jover wrote:

Control: reassign -1 glx-diversions 1.2.0



I reproduced the problem and replaced the postinst maintscript, and
got the output in «glx-diversions.postinst.log», and after that
there's no more libGL.so*. And these only get regenerated during the
triggers processing.
I've uploaded 1.2.1 to sid which reduces the time between creating the 
diversions and setting up the alternatives initially. That should fix 
the issue where libGL.so.1 etc. is missing over an extended timeframe 
(i.e. during the configuration of several unrelated packages).


It would be great if you could retest your scenario in sid, s.t. I can 
backport the fix to bullseye-pu.


Andreas

PS: once the 390 legacy driver and 418 tesla driver are EoL (end of 
2022, i.e. before bookworm), we can probably get rid of (most of) the 
diversion+alternatives construct, since all newer driver series are 
based on glvnd ;-)

Bug#995704: ITP: golang-github-cloudwego-netpoll -- A high-performance non-blocking I/O networking framework, which focused on RPC scenarios

2021-10-04 Thread Yanhao Mo

Package: wnpp
Severity: wishlist
Owner: Yanhao 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-cloudwego-netpoll
  Version : 0.0.4-1
  Upstream Author : Bytedance Inc.
* URL : https://github.com/cloudwego/netpoll
* License : Apache-2.0
  Programming Lang: Go
  Description : A high-performance non-blocking I/O networking
framework, which focused on RPC scenarios, developed by ByteDance.

 Netpoll is a high-performance non-blocking I/O networking framework,
 which focused on RPC scenarios, developed by ByteDance.

Bug#995702: [Pkg-javascript-devel] TypeError: Cannot read property 'prefix_exceptions' of undefined

2021-10-04 Thread Pirate Praveen




On 4 October 2021 6:02:19 pm IST, Dominik George  
wrote:
>>   - let autoprefixerData = { browsers: agents, prefixes: dataPrefixes }
>>   + let autoprefixerData = { browsers: agents.agents, prefixes: dataPrefixes 
>> }
>
>It's
>https://github.com/browserslist/caniuse-lite/commit/fde289588b2ccb129ba3d1552134be2c78fee8b7
>
>So, this happened with a recent update of node-autoprefixer, because
>the new autoprefixer relies on the new API of caniuse-lite.
>
>caniuse-lite should, and will at some point, be updated in Debian as
>well. However, this will break node-browserslist, because that relies
>on the old API. Oh the joy!

Is there a new version of browserslist that uses the new API?

>Proposal:
>
> 1. Add a patch to node-autoprefixer to use the old API
> 2. Add a version constraint to the node-caniuse-lite dependency in
>node-autoprefixer (<< 1.0.30001226~)
> 3. Report a bug against node-caniuse-lite to update to the current
>upstream version, with a gentle hint on what will break if updated
> 4. Once updated, drop the patch, and remove the version constraint
>
>@ JavaScript team, shall I proceed with that?

I think updating node-caniuse-lite and patching node-browserslist may be 
better. But if that is difficult, you can go ahead with this.

BTW I had noticed the breakage while updating gitlab and filed a bug, but did 
not get time to dig deeper. Thanks for these details.

>-nik

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#915373:

2021-10-04 Thread Meho Hodzić

F fv

Bug#995702: TypeError: Cannot read property 'prefix_exceptions' of undefined

2021-10-04 Thread Dominik George

Control: reassign -1 node-caniuse-lite 1.0.30001224+dfsg-2
Control: retitle -1 Broken exports in index.js
Control: affects -1 node-autoprefixer
Control: tags -1 + upstream fixed-upstream
Control: forwarded -1 https://github.com/browserslist/caniuse-lite/issues/70

> Proposal:
> 
>  1. Add a patch to node-autoprefixer to use the old API
>  2. Add a version constraint to the node-caniuse-lite dependency in
> node-autoprefixer (<< 1.0.30001226~)
>  3. Report a bug against node-caniuse-lite to update to the current
> upstream version, with a gentle hint on what will break if updated
>  4. Once updated, drop the patch, and remove the version constraint

Actually, all rdepends seem to use another import mechanism, which was
not broken.

Thus, reassigning to node-caniuse-lite to get it updated.

-nik


signature.asc
Description: PGP signature

Bug#995705: tnftp: d/copyright has wrong license name


Package: tnftp
Severity: important

The tnftp package's copyright file claims that the package's license is Unlicense while it 
is actually BSD-4-clause. Please fix that.

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

2021-10-04 Thread Thomas Goirand

Hi,

Thanks for your reply.

I have uploaded keystone/18.0.0-3+deb11u2 to Bullseye. You can flag it
for acceptance.

For Buster, I'm having the problem that I cannot build the package
without subunit 1.4.0-3 which is in Bullseye only (Buster has 1.3.0-1).
Would it be acceptable that I upload both subunit 1.4.0-3 and Keystone
2:14.2.0-0+deb10u2 to Buster? Please let me know your thoughts.

Cheers,

Thomas Goirand (zigo)

Bug#995704: ITP: golang-github-cloudwego-netpoll -- A high-performance non-blocking I/O networking framework, which focused on RPC scenarios

2021-10-04 Thread Jonas Smedegaard

Quoting Yanhao Mo (2021-10-04 14:46:54)
> Package: wnpp
> Severity: wishlist
> Owner: Yanhao 
> X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
> 
> * Package name: golang-github-cloudwego-netpoll
>   Version : 0.0.4-1
>   Upstream Author : Bytedance Inc.
> * URL : https://github.com/cloudwego/netpoll
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : A high-performance non-blocking I/O networking
> framework, which focused on RPC scenarios, developed by ByteDance.
> 
>  Netpoll is a high-performance non-blocking I/O networking framework,
>  which focused on RPC scenarios, developed by ByteDance.

Please beware that first line of Description should be a short 
not-a-full-sentence one-liner independent from the remaining description 
lines.

Seems you should not edit that first line but keep it as as part of the 
long description and instead _prepend_ another shorter line for use as 
short description.

More information here: 
https://www.debian.org/doc/debian-policy/ch-binary.html#the-single-line-synopsis


 - Jonas

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

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

signature.asc
Description: signature

Bug#994395: cups: uses sides=one-sided by default

2021-10-04 Thread Vincent Lefevre

On 2021-09-15 15:34:00 +0200, Vincent Lefevre wrote:
> Package: cups
> Version: 2.3.3op2-3+deb11u1
> Severity: important
> 
> On my Debian machine, files are printed one sided, even though I use
> Duplex=DuplexNoTumble in my .cups/lpoptions file. I suppose that this
> is due to the following issue.
> 
> cventin:~> lpoptions -p print-1
> ColorModel=Gray copies=1 device-uri=ipps://print-1.lip.ens-lyon.fr:443 
> Duplex=DuplexNoTumble finishings=3 job-cancel-after=10800 
> job-hold-until=no-hold job-priority=50 job-sheets=none,none 
> marker-change-time=1631710524 
> marker-colors=#00,#FF00FF,#00,#00,none 
> marker-high-levels=100,100,100,100,95 marker-levels=25,31,30,72,0 
> marker-low-levels=5,5,5,5,0 marker-names='Cyan\ TK-8335C,Magenta\ 
> TK-8335M,Yellow\ TK-8335Y,Black\ TK-8335K,Waste\ Toner\ Box' 
> marker-types=toner,toner,toner,toner,waste-toner media=iso_a4_210x297mm 
> number-up=1 output-bin=tray-1 print-color-mode=color printer-commands=none 
> printer-info='print-1 (Kyocera TASKalfa 3253ci)' 
> printer-is-accepting-jobs=true printer-is-shared=true 
> printer-is-temporary=false printer-location='Bocal (left)' 
> printer-make-and-model='3253ci - IPP Everywhere' printer-state=3 
> printer-state-change-time=1631710539 printer-state-reasons=none 
> printer-type=45180 printer-uri-supported=ipp://localhost/printers/print-1 
> sides=one-sided
> 
> See the "sides=one-sided" at the end, which doesn't come from
> my config, where .cups/lpoptions contains:
> 
> Default print-1 ColorModel=Gray Duplex=DuplexNoTumble
> 
> Ditto with cups 2.3.3op2-7.
[...]

I had kept the output I got after this printer was installed:

cventin:~> lpoptions -p print-1
ColorModel=Gray copies=1 device-uri=ipps://print-1.lip.ens-lyon.fr:443 
Duplex=DuplexNoTumble finishings=3 job-cancel-after=10800 
job-hold-until=no-hold job-priority=50 job-sheets=none,none 
marker-change-time=1602254655 
marker-colors=#00,#FF00FF,#00,#00,none 
marker-high-levels=100,100,100,100,95 marker-levels=96,96,96,95,0 
marker-low-levels=5,5,5,5,0 marker-names='Cyan\ TK-8335C,Magenta\ 
TK-8335M,Yellow\ TK-8335Y,Black\ TK-8335K,Waste\ Toner\ Box' 
marker-types=toner,toner,toner,toner,waste-toner number-up=1 
printer-commands=none printer-info='Kyocera TASKalfa 3253ci' 
printer-is-accepting-jobs=true printer-is-shared=true 
printer-is-temporary=false printer-location printer-make-and-model='3253ci - 
IPP Everywhere' printer-state=3 printer-state-change-time=1602254680 
printer-state-reasons=media-empty-report printer-type=45180 
printer-uri-supported=ipp://localhost/printers/print-1

That was on 2020-10-09, and there was no "sides=one-sided" at that
time, and this was with cups 2.3.3-3.

So, it is possible that the issue appeared after the switch to the
OpenPrinting CUPS fork in November 2020.

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

Bug#995706: lintian: Regression: false positive missing-build-dependency-for-dh-addon python3

2021-10-04 Thread Ole Streicher


Package: lintian
Version: 2.107.0

Dear maintainer,

The recently uploaded version of Lintian issues a false positive on the
following source (ITP; not uploaded yet):

https://salsa.debian.org/debian-astro-team/casa-formats-io/-/tree/5fec988b8b

E: casa-formats-io source: missing-build-dependency-for-dh-addon python3 
=> python3:any | python3-all:any | python3-dev:any | python3-all-dev:any 
| dh-sequence-python3


Full log on Salsa here:

https://salsa.debian.org/debian-astro-team/casa-formats-io/-/jobs/2034138

The package's d/control lists python3-all-dev as a build dependency. The 
problem was also checked locally. This is a regression, 2.106.0 
(currently in testing) does not show this problem.


Best regards

Ole

Bug#995707: ITP: r-cran-rcsdp -- R Interface to the CSDP Semidefinite Programming Library

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-rcsdp -- R Interface to the CSDP Semidefinite Programming 
Library
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-rcsdp
  Version : 0.1.57.1
  Upstream Author : Hector Corrada Bravo
* URL : https://cran.r-project.org/package=Rcsdp
* License : CPL-1.0
  Programming Lang: GNU R
  Description : R Interface to the CSDP Semidefinite Programming Library
 R interface to the CSDP semidefinite programming library. Installs
 version 6.1.1 of CSDP from the COIN-OR website if required. An
 existing installation of CSDP may be used by passing the proper
 configure arguments to the installation command. See the INSTALL file
 for further details.

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

Bug#824594: please support DPKG_ROOT in base-files' postinst

Hi,

Quoting Santiago Vila (2021-10-04 13:02:33)
> Looking at the original report, I read this:
> 
> > It will point to the installation root with the trailing slash
> > stripped. That means under normal conditions, it is empty.
> 
> So, if I understood correctly:
> 
> - if installation root is / then DPKG_ROOT is ""
> - but if it's /mnt then DPKG_ROOT is "/mnt"
> 
> I guess this is unlikely to change at this point, however: Would not
> have been cleaner to specify it as the installation root (without the
> "trailing slash stripped" part).

the path not having the trailing slash and thus the root path being the empty
string has the advantage, that it is easy to see that under normal operation,
the DPKG_ROOT patch does nothing. Most of our patches to maintainer scripts
look like this:

-sometool "/some/path"
+sometool "$DPKG_ROOT/some/path"

Since DPKG_ROOT is empty in normal circumstances, it is obvious that the patch
cannot change the behaviour of the script. Furthermore, since DPKG_ROOT is
usually used as a prefix of an absolute path, it also avoids a double slash
when concatenating them.

> Another question: Can you explain the usage of ":" command at the beginning?
> 
> : "${DPKG_ROOT:=}"
> 
> This is to define DPKG_ROOT as the empty string in case it's undefined,
> right? Is this really needed in a POSIX shell? I believed ${DPKG_ROOT}
> would expand to empty string when it's not defined.
> 
> Or maybe you meant this? : "${DPKG_ROOT:=/}"

That line is not needed anymore. The original patch was written in May 2016
when dpkg 1.18.5 which introduced DPKG_ROOT was just freshly uploaded to
unstable. Some maintainer scripts include a "set -u" which would cause an error
when variables that are not set are used. So back then, our patches included
that line to avoid this. Today, dpkg sets DPKG_ROOT even in old-old-stable so
it is save to assume that it is set. Additionally, the base-files script does
not call "set -u" so even if it were unset, it would just become the empty
string. So the line can be safely removed. I just updated our patch in our CI
infrastructure and can confirm that nothing breaks without that line.

> Also: just to be sure: Am I right to think that the sed command in
> change_owner function is there to be able to bootstrap a Debian system from a
> non-Debian system?

No, we don't expect the outside system not to be Debian. The sed is there so
that the chown call obtains user and group ids from the chroot instead of the
outside system. There are alternatives to this approach:

 a) assume that the outside /etc/passwd and /etc/group will always be in sync
with the copy of the chroot and thus place a few more restrictions on the
package versions of the outside system
 b) hardcode the uid of root and the gid of utmp and staff and hope those
never change
 c) obtain the uid of root and the gid of utmp and staff at build-time of
base-files and write them into the postinst script

> And finally: Do we really need to consider DPKG_ROOT in
> update_to_current_default function? (It should only used on upgrades).

No, that's not strictly necessary. Right now we only test installation and not
upgrades, so that can be dropped from the initial patch.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#995702: Updating caniuse-lite (was: Re: TypeError: Cannot read property 'prefix_exceptions' of undefined)

2021-10-04 Thread Pirate Praveen





On തി, ഒക്ടോ 4 2021 at 03:17:03 വൈകു +0200 +0200, 
Dominik George  wrote:

Hi,

concerning the update of node-caniuse-lite, I fixed upstream's
deployment script, so that uscan will find new upstream versions
again:

  https://github.com/browserslist/caniuse-lite/issues/84

Shall I update caniuse-lite and upload the new version once uscan is
satisfied again?



Yes, please. You can take a snapshot of the git commit manually (the 
commit logs have version in comments) if you don't want to wait for 
next version. From next version we can continue using uscan.



Cheers,
Nik

Bug#995591: RFS: minidb/2.0.5-2 -- simple SQLite3-based store for Python objects

2021-10-04 Thread Maxime Werlen

Control: tags -1 - moreinfo

Hi Jeroen,

Thanks for your review. I've made the requested changes :
* Removed python 3 version requirement
* Explicit B-D on python3 (for dh-python)
* Mark previous test as superficial and used upstream test as autopkgtest

A new package has been uploaded to mentors.
I hope I've done it correctly :)

Regards,

Maxime

On Sun, Oct 03, 2021 at 07:43:30PM +0200, Jeroen Ploemen wrote:
> Control: tags -1 moreinfo
> 
> On Sat, 02 Oct 2021 20:41:32 +0200
> Maxime Werlen  wrote:
> 
> > Package: sponsorship-requests
> > Severity: normal
> > 
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "minidb":
> 
> hi Maxime,
> 
> The package is not lintian clean:
>   E: minidb source: missing-build-dependency-for-dh-addon python3 => 
> python3:any | python3-all:any | python3-dev:any | python3-all-dev:any | 
> dh-sequence-python3
> 
> Control:
>   The ancient version requirement on the python3 build-dep is always
>   satisfied, please remove.
> 
> Tests:
>   Consider using the upstream testsuite (currently only run during
>   build) as autopkgtest. Be sure to copy the tests out of the source
>   dir and to loop over all supported python3 versions; there's plenty
>   of packages on the python team repo that can serve as examples,
>   including [1].
>   The current 'import.py' is rather basic in comparison, doesn't test
>   against all supported versions and should probably be marked
>   "superficial" - if at all retained.
> 
> 
> Please remove the moreinfo tag (and CC me directly) once you have an
> updated package ready.
> 
> 
> [1] 
> https://salsa.debian.org/python-team/packages/puremagic/-/tree/master/debian/tests




signature.asc
Description: PGP signature

Bug#995708: docker.io: dockerd dies with Illegal Instruction when run on a pre-SSE2-class x86 system

2021-10-04 Thread Jörn Heusipp

Package: docker.io
Version: 20.10.8+dfsg1-1
Severity: important
X-Debbugs-Cc: osm...@problemloesungsmaschine.de

Dear Maintainer,

Starting dockerd results in Illegal Instruction on a 32bit x86 system.

Looking at the core dump with gdb shows the offending instruction as
 >0x8ece78movsd  xmm0,QWORD PTR [eax]
(with eax containing 0x23fdc64).

This is 'Move Scalar Double-Precision Floating-Point Value', which is an SSE2 
instruction. SSE1 only supports single precision floating point.

The CPU in question here is an AMD Duron 1800, which supports SSE, but not SSE2.

As this CPU is still supported by Debian and will be (as far as I know) for the 
next release, I would expect to be able to run docker on it.

root@caesar:~# cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 8
model name  : AMD Duron(tm)
stepping: 1
cpu MHz : 1798.276
cache size  : 64 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall
bugs: fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 
spec_store_bypass
bogomips: 3596.55
clflush size: 32
cache_alignment : 32
address sizes   : 34 bits physical, 32 bits virtual
power management: ts


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

Kernel: Linux 5.14.0-1-686-pae (SMP w/1 CPU thread)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages docker.io depends on:
ii  adduser  3.118
ii  containerd   1.5.5~ds1-1
ii  dpkg 1.20.9
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.32-4
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libsystemd0  247.9-1
ii  lsb-base 11.1.0
ii  runc 1.0.2+ds1-1
ii  tini 0.19.0-1

Versions of packages docker.io recommends:
ii  apparmor 3.0.3-2
ii  ca-certificates  20210119
ii  cgroupfs-mount   1.4
ii  git  1:2.33.0-1
ii  needrestart  3.5-4
ii  xz-utils 5.2.5-2

Versions of packages docker.io suggests:
pn  aufs-tools   
ii  btrfs-progs  5.14.1-1
ii  debootstrap  1.0.123
pn  docker-doc   
ii  e2fsprogs1.46.4-1
pn  rinse
ii  rootlesskit  0.14.2-1+b3
ii  xfsprogs 5.13.0-1
ii  zfs-fuse 0.7.0-22

-- no debconf information

Bug#995704: ITP: golang-github-cloudwego-netpoll -- A high-performance non-blocking I/O networking framework, which focused on RPC scenarios

2021-10-04 Thread Yanhao Mo

Hi Jonas,
Thanks for pointing that out, I will fix the problem when I prepare
the first upload package.

On Mon, Oct 4, 2021 at 9:01 PM Jonas Smedegaard  wrote:
>
> Quoting Yanhao Mo (2021-10-04 14:46:54)
> > Package: wnpp
> > Severity: wishlist
> > Owner: Yanhao 
> > X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
> >
> > * Package name: golang-github-cloudwego-netpoll
> >   Version : 0.0.4-1
> >   Upstream Author : Bytedance Inc.
> > * URL : https://github.com/cloudwego/netpoll
> > * License : Apache-2.0
> >   Programming Lang: Go
> >   Description : A high-performance non-blocking I/O networking
> > framework, which focused on RPC scenarios, developed by ByteDance.
> >
> >  Netpoll is a high-performance non-blocking I/O networking framework,
> >  which focused on RPC scenarios, developed by ByteDance.
>
> Please beware that first line of Description should be a short
> not-a-full-sentence one-liner independent from the remaining description
> lines.
>
> Seems you should not edit that first line but keep it as as part of the
> long description and instead _prepend_ another shorter line for use as
> short description.
>
> More information here:
> https://www.debian.org/doc/debian-policy/ch-binary.html#the-single-line-synopsis
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#995709: korganizer: Korganizer fails to start due to Akonadi not working

2021-10-04 Thread Patrick Jaap

Package: korganizer
Version: 4:21.08.1-1+b1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: p...@posteo.de

Dear Maintainer,

Korganizer is not starting and tells that Akonadi is not working properly and 
then freezes.
I attach the terminal log of Korganizer.

Best,
Patrick


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (2, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages korganizer depends on:
ii  kdepim-runtime  4:21.08.1-1+b1
ii  kio 5.86.0-1
ii  libc6   2.33-0experimental1
ii  libgcc-s1   11.2.0-8
ii  libkf5akonadicalendar5abi1 [libkf5akonadicalendar5-21.  4:21.08.1-1+b1
ii  libkf5akonadicontact5 [libkf5akonadicontact5-21.08] 4:21.08.1-1+b1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-21.08]   4:21.08.1-1+b1
ii  libkf5akonadimime5 [libkf5akonadimime5-21.08]   4:21.08.1-1+b1
ii  libkf5akonadinotes5 [libkf5akonadinotes5-21.08] 4:21.08.1-1+b1
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-21.08  4:21.08.1-1+b1
ii  libkf5calendarcore5abi2 5:5.86.0-1
ii  libkf5calendarsupport5abi1 [libkf5calendarsupport5-21.  4:21.08.1-1+b1
ii  libkf5calendarutils5 [libkf5calendarutils5-21.08]   4:21.08.1-1+b1
ii  libkf5codecs5   5.86.0-1
ii  libkf5completion5   5.86.0-1
ii  libkf5configcore5   5.86.0-1
ii  libkf5configgui55.86.0-1
ii  libkf5configwidgets55.86.0-1
ii  libkf5contacts5 5:5.86.0-1
ii  libkf5coreaddons5   5.86.0-1
ii  libkf5crash55.86.0-1
ii  libkf5dbusaddons5   5.86.0-1
ii  libkf5eventviews5abi1 [libkf5eventviews5-21.08] 4:21.08.1-1+b1
ii  libkf5holidays5 1:5.86.0-1
ii  libkf5i18n5 5.86.0-1
ii  libkf5iconthemes5   5.86.0-1
ii  libkf5identitymanagement5 [libkf5identitymanagement5-2  21.08.1-1+b1
ii  libkf5incidenceeditor5abi1 [libkf5incidenceeditor5-21.  21.08.1-1+b1
ii  libkf5itemmodels5   5.86.0-1
ii  libkf5itemviews55.86.0-1
ii  libkf5jobwidgets5   5.86.0-1
ii  libkf5kcmutils5 5.86.0-1
ii  libkf5kiocore5  5.86.0-1
ii  libkf5kiogui5   5.86.0-1
ii  libkf5kiowidgets5   5.86.0-1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-21.08  21.08.1-1+b1
ii  libkf5libkdepim5 [libkf5libkdepim5-21.08]   4:21.08.1-1+b1
ii  libkf5mailtransport5 [libkf5mailtransport5-21.08]   21.08.1-1+b1
ii  libkf5mailtransportakonadi5 [libkf5mailtransportakonad  21.08.1-1+b1
ii  libkf5mime5abi1 [libkf5mime5-21.08] 21.08.1-1+b1
ii  libkf5newstuff5 5.86.0-2
ii  libkf5newstuffcore5 5.86.0-2
ii  libkf5notifications55.86.0-1
ii  libkf5parts55.86.0-1
ii  libkf5pimcommon5abi2 [libkf5pimcommon5-21.08]   4:21.08.1-1+b1
ii  libkf5pimcommonakonadi5abi1 [libkf5pimcommonakonadi5-2  4:21.08.1-1+b1
ii  libkf5service-bin   5.86.0-1
ii  libkf5service5  5.86.0-1
ii  libkf5widgetsaddons55.86.0-1
ii  libkf5windowsystem5 5.86.0-1
ii  libkf5xmlgui5   5.86.0-1
ii  libkuserfeedbackcore1   1.0.0-3
ii  libkuserfeedbackwidgets11.0.0-3
ii  libphonon4qt5-4 4:4.11.1-4
ii  libqt5core5a5.15.2+dfsg-12
ii  libqt5dbus5 5.15.2+dfsg-12
ii  libqt5gui5  5.15.2+dfsg-12
ii  libqt5widgets5  5.15.2+dfsg-12
ii  libstdc++6

Bug#995432: fetchmail is affected

2021-10-04 Thread Aristeu Rozanski

Hello,

I'm running bullseye and fetchmail seems affected. I had these happening:

fetchmail: socket error while fetching from aris@
fetchmail: Query status=2 (SOCKET)
fetchmail: Server certificate verification error: certificate has expired
fetchmail: OpenSSL reported: error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed

The machine I saw this error has been dist-upgraded since 2001 or so. Running
openssl s_client -showcerts -connect :995 -servername :

(snip)
Start Time: 1633325277
Timeout : 7200 (sec)
Verify return code: 10 (certificate has expired)
Extended master secret: no
Max Early Data: 0

Checking the certificate locally in the server it passed. Running same openssl
command in another bullseye machine did work. Did try to run
update-ca-certificates with and without -f, didn't help. It did reported
warnings:

Updating certificates in /etc/ssl/certs...
W:
/usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.crt
not found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/GeoTrust_Universal_CA_2.crt not
found, but listed in /etc/ca-certificates.conf.
W: /usr/share/ca-certificates/mozilla/Taiwan_GRCA.crt not found, but
listed in /etc/ca-certificates.conf.
W:
/usr/share/ca-certificates/mozilla/OISTE_WISeKey_Global_Root_GA_CA.crt not
found, but listed in /etc/ca-certificates.conf.
W:
/usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_Root_CA_-_G2.crt not
found, but listed in /etc/ca-certificates.conf.
W:
/usr/share/ca-certificates/mozilla/EE_Certification_Centre_Root_CA.crt not
found, but listed in /etc/ca-certificates.conf.
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

updates of cacerts keystore disabled.
done.

Finally gave up and copied ca-certificates.conf from the machine that was
working, re-ran update-ca-certificates and it got rid of the warnings and
fetchmail and openssl were happy again. I don't fully understand how
/etc/ca-certificates.conf is generated and don't remember ever changing it.

--
Aristeu

Bug#995710: O: netkit-ftp -- basic ftp client


Package: wnpp

ftp is unmaintained/non-existing upstream and the package seems to be unmaintained as well 
(see related #986997). It should be removed in favour of tnftp (fully command-line 
compatible) and tnftp should provide a package transition. Whoever wants to use the netkit 
source can still install ftp-ssl.


If noone wants to adopt the package, I am going to file a RM bug in a month to enable 
implementing that transition.

Bug#991900: prism2-usb-firmware-installer: missing Depends: ca-certificates

2021-10-04 Thread Tormod Volden

Hi Andreas,

Thanks for the report. The package already depends on wget, which
recommends ca-certificates, so this only affects users that have
decided (against the recommendation) to not install this.

In any case, the expected retrieved file has a known checksum (the
whole downloading dance is to avoid redistribution legal issues) so
I'll change it to use wget --no-check-certificate and subsequently
checksum the retrieved file. As long as the file is the same, we don't
care so much who actually delivered it :) This solution should work
for everyone, and in your case you will get a warning instead of an
error.

Regards,
Tormod

Bug#995711: ITP: r-cran-maotai -- Tools for Matrix Algebra, Optimization and Inference

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-maotai -- Tools for Matrix Algebra, Optimization and 
Inference
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-maotai
  Version : 0.2.1
  Upstream Author : Kisung You
* URL : https://cran.r-project.org/package=maotai
* License : MIT
  Programming Lang: GNU R
  Description : Tools for Matrix Algebra, Optimization and Inference
 Matrix is an universal and sometimes primary object/unit in applied
 mathematics and statistics. We provide a number of algorithms for
 selected problems in optimization and statistical inference. For general
 exposition to the topic with focus on statistical context, see the book
 by Banerjee and Roy (2014, ISBN:9781420095388).

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

Bug#994395: cups: uses sides=one-sided by default

2021-10-04 Thread Vincent Lefevre

Additional information:

On both Debian 10 and Debian unstable, I get

$ ipptool -tv ipp://localhost/printers/print-1 get-printer-attributes.test | 
grep sides-
sides-supported (1setOf keyword) = 
one-sided,two-sided-long-edge,two-sided-short-edge
sides-default (keyword) = one-sided

I suspect that for some reason, the old client did not take
into account sides-default, but the fork does. I don't know
whether this is intended, but I couldn't find any information
about such a change.

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

Bug#995712: tnftp: build with system's libedit


Package: tnftp
Severity: important

The tnftp package includes libedit source. Please define libedit-dev as a build dependency 
so that it ignores the vendored source and builds with Debian's libedit instead (the auto 
detection works).

Bug#995198: wsjtx: No transmit audio

2021-10-04 Thread tony mancill

Hello Hilary,

On Mon, Sep 27, 2021 at 09:07:49PM +0100, Hilary Snaden wrote:
> Package: wsjtx
> Version: 2.5.0~rc6+repack-1
> Severity: important
> 
> Dear Maintainer,
> 
> The program generates no audio output on transmit, in any mode. This is 
> identical to a bug which I reported on the previous version of wsjtx, under 
> Debian bullseye/sid (though on different hardware).
> 
> The program works satisfactorily on receive.
> 
> The similar (in function) program fldigi generates good, clean audio on 
> transmit on the same machine.

I am not experiencing any problems with transmit with this version of
wsjtx.  Can you provide more details about your configuration and/or
hardware?

Thank you,
tony

Bug#995713: ITP: r-cran-rcppdist -- 'Rcpp' Integration of Additional Probability Distributions

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-rcppdist -- 'Rcpp' Integration of Additional Probability 
Distributions
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-rcppdist
  Version : 0.1.1
  Upstream Author : JB Duck-Mayr
* URL : https://cran.r-project.org/package=RcppDist
* License : GPL-2+
  Programming Lang: GNU R
  Description : 'Rcpp' Integration of Additional Probability Distributions
 The 'Rcpp' package provides a C++ library to make it easier
 to use C++ with R. R and 'Rcpp' provide functions for a variety of
 statistical distributions. Several R packages make functions
 available to R for additional statistical distributions. However,
 to access these functions from C++ code, a costly call to the R
 functions must be made. 'RcppDist' provides a header-only C++ library
 with functions for additional statistical distributions that can be
 called from C++ when writing code using 'Rcpp' or 'RcppArmadillo'.
 Functions are available that return a 'NumericVector' as well as
 doubles, and for multivariate or matrix distributions, 'Armadillo'
 vectors and matrices. 'RcppDist' provides functions for the following
 distributions: the four parameter beta distribution; the location-
 scale t distribution; the truncated normal distribution; the
 truncated t distribution; a truncated location-scale t distribution;
 the triangle distribution; the multivariate normal distribution*;
 the multivariate t distribution*; the Wishart distribution*; and
 the inverse Wishart distribution*. Distributions marked with an
 asterisk rely on 'RcppArmadillo'.

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

Bug#995714: gnome-shell freezes with error

2021-10-04 Thread tkoeck

Package: gnome-shell
Version: 3.38.6-1~deb11u1
Severity: normal

Dear Maintainer,

 16:32:01 tron-nb gnome-shell[30171]: pushModal: invocation of begin_modal 
failed
Oct  4 16:32:05 tron-nb gnome-shell[30171]: pushModal: invocation of 
begin_modal failed
Oct  4 16:32:07 tron-nb gnome-shell[30171]: pushModal: invocation of 
begin_modal failed
Oct  4 16:32:07 tron-nb gnome-shell[30171]: pushModal: invocation of 
begin_modal failed

Only a kill with hub to the gnome-shell process helps

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


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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  evolution-data-server3.38.3-1
ii  gir1.2-accountsservice-1.0   0.6.55-3
ii  gir1.2-atspi-2.0 2.40.3-3~bpo11+1
ii  gir1.2-freedesktop   1.66.1-1+b1
ii  gir1.2-gcr-3 3.38.1-2
ii  gir1.2-gdesktopenums-3.0 3.38.0-2
ii  gir1.2-gdm-1.0   3.38.2.1-1
ii  gir1.2-geoclue-2.0   2.5.7-3
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-gnomebluetooth-1.03.34.3-2
ii  gir1.2-gnomedesktop-3.0  3.38.5-3
ii  gir1.2-gstreamer-1.0 1.18.4-2.1
ii  gir1.2-gtk-3.0   3.24.24-4
ii  gir1.2-gweather-3.0  3.36.1-3
ii  gir1.2-ibus-1.0  1.5.23-2
ii  gir1.2-mutter-7  3.38.6-2~deb11u1
ii  gir1.2-nm-1.01.30.0-2
ii  gir1.2-nma-1.0   1.8.30-1
ii  gir1.2-pango-1.0 1.46.2-3
ii  gir1.2-polkit-1.00.105-31
ii  gir1.2-rsvg-2.0  2.50.3+dfsg-1
ii  gir1.2-soup-2.4  2.72.0-2
ii  gir1.2-upowerglib-1.00.99.11-2
ii  gjs  1.66.2-1
ii  gnome-backgrounds3.38.0-1
ii  gnome-settings-daemon3.38.2-1
ii  gnome-shell-common   3.38.6-1~deb11u1
ii  gsettings-desktop-schemas3.38.0-2
ii  gstreamer1.0-pipewire0.3.19-4
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u2
ii  libcairo21.16.0-5
ii  libecal-2.0-13.38.3-1
ii  libedataserver-1.2-253.38.3-1
ii  libgcr-base-3-1  3.38.1-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgirepository-1.0-11.66.1-1+b1
ii  libgjs0g 1.66.2-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.66.8-1
ii  libglib2.0-bin   2.66.8-1
ii  libgnome-autoar-0-0  0.2.4-3
ii  libgnome-desktop-3-193.38.5-3
ii  libgraphene-1.0-01.10.4+dfsg1-1
ii  libgtk-3-0   3.24.24-4
ii  libical3 3.0.9-2
ii  libjson-glib-1.0-0   1.6.2-1
ii  libmutter-7-03.38.6-2~deb11u1
ii  libnm0   1.30.0-2
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpolkit-agent-1-0  0.105-31
ii  libpolkit-gobject-1-00.105-31
ii  libpulse-mainloop-glib0  14.2-2
ii  libpulse014.2-2
ii  libsecret-1-00.20.4-2
ii  libsystemd0  247.3-6
ii  libwayland-server0   1.18.0-2~exp1.1
ii  libx11-6 2:1.7.2-1
ii  libxfixes3   1:5.0.3-2
ii  python3  3.9.2-3

Versions of packages gnome-shell recommends:
ii  bolt  0.9.1-1
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.38.2.1-1
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center

Bug#995715: Internal Error, No file name for dictionaries-common:amd64

2021-10-04 Thread 積丹尼 Dan Jacobson

Package: aptitude
Version: 0.8.13-3

# aptitude reinstall dictionaries-common
The following packages will be REINSTALLED:
  dictionaries-common
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not 
upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Do you want to continue? [Y/n/?]
E: Internal Error, No file name for dictionaries-common:amd64

Bug#994824: slop: FTBFS on sid

2021-10-04 Thread Adrian Bunk

Control: forwarded -1 
https://github.com/naelstrof/slop/commit/5cbcb9e389a02d6288f90a790c6b547d9f9dcac7
Control: tags -1 patch fixed-upstream

On Tue, Sep 21, 2021 at 01:04:29PM +0100, Alastair McKinstry wrote:
> Package: slop
> Version: 7.5
> Severity: serious
> Tags: ftbfs
> Justification: FTBFS
> 
> This package now Fails to build in unstable:
> 
> [ 80%] Building CXX object CMakeFiles/slopy.dir/src/glrectangle.cpp.o
> /usr/bin/c++ -DCXXOPTS_USE_UNICODE -DSLOP_OPENGL=\"True\" 
> -DSLOP_VERSION=\"v7.5\" -Dslopy_EXPORTS 
> -I/build/slop-7.5/obj-x86_64-linux-gnu -g -O2 
> -ffile-prefix-map=/build/slop-7.5=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -std=c++11 -MD 
> -MT CMakeFiles/slopy.dir/src/glrectangle.cpp.o -MF 
> CMakeFiles/slopy.dir/src/glrectangle.cpp.o.d -o 
> CMakeFiles/slopy.dir/src/glrectangle.cpp.o -c 
> /build/slop-7.5/src/glrectangle.cpp
> /build/slop-7.5/src/framebuffer.cpp: In member function 'void 
> slop::Framebuffer::setShader(slop::Shader*)':
> /build/slop-7.5/src/framebuffer.cpp:55:9: error: 'XDestroyImage' was not 
> declared in this scope; did you mean 'eglDestroyImage'?
>55 | XDestroyImage( image );
>   | ^
>   | eglDestroyImage
> make[3]: *** [CMakeFiles/slopy.dir/build.make:219: 
> CMakeFiles/slopy.dir/src/framebuffer.cpp.o] Error 1
>...

Please add the one-line upstream fix I've linked above.

Thanks
Adrian

Bug#995498: FP? missing-build-dependency-for-dh-addon python3

2021-10-04 Thread Nilesh Patra

On Sun, 3 Oct 2021 12:29:41 +0100 Simon McVittie  wrote:
> > Either way, the documentation changes will probably be reverted when
> > the ':any' is dropped from the Python prerequisites.
> 
> I don't think removing the :any from the package names in e.g.
> /usr/share/lintian/data/scripts/interpreters is the right solution.
> 
> If I'm reading correctly, I think a better solution would probably be
> fixing the interpretation of comparing dependencies with "implies",
> so that it recognises that python3 is a "stronger" dependency than
> python3:any - that way, the data file could still list python3:any as
> the required dependency, and Lintian would recognise that a package with
> "Depends: python3" also guarantees that the necessary package to satisfy
> "Depends: python3:any" is available.

That makes perfect sense!
@Felix, can I please ask you to follow this up with the respective
maintainer(s) and fix the dependency interpretation?
Since lintian seems to have catched this problem, it'd be really nice if you
could do so.

Nilesh


signature.asc
Description: PGP signature

Bug#995432: fetchmail is affected

2021-10-04 Thread Julien Cristau

I think what you're seeing can be explained if you had
ca-certificates/trust_new_crts disabled (see debconf-show
ca-certificates) when ISRG Root X1 was added, in which case the "new"
root wouldn't be in your bundle and so you wouldn't have a trust path to
LE certs after the DST Root's expiration.

Cheers,
Julien

On Mon, Oct 04, 2021 at 09:55:52AM -0400, Aristeu Rozanski wrote:
> Hello,
> 
> I'm running bullseye and fetchmail seems affected. I had these happening:
> 
> fetchmail: socket error while fetching from aris@
> fetchmail: Query status=2 (SOCKET)
> fetchmail: Server certificate verification error: certificate has expired
> fetchmail: OpenSSL reported: error:1416F086:SSL 
> routines:tls_process_server_certificate:certificate verify failed
> 
> The machine I saw this error has been dist-upgraded since 2001 or so. Running
> openssl s_client -showcerts -connect :995 -servername :
> 
> (snip)
> Start Time: 1633325277
> Timeout   : 7200 (sec)
> Verify return code: 10 (certificate has expired)
> Extended master secret: no
> Max Early Data: 0
> 
> Checking the certificate locally in the server it passed. Running same openssl
> command in another bullseye machine did work. Did try to run
> update-ca-certificates with and without -f, didn't help. It did reported
> warnings:
> 
>   Updating certificates in /etc/ssl/certs...
>   W: 
> /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.crt
>  not found, but listed in /etc/ca-certificates.conf.
>   W: /usr/share/ca-certificates/mozilla/GeoTrust_Universal_CA_2.crt not 
> found, but listed in /etc/ca-certificates.conf.
>   W: /usr/share/ca-certificates/mozilla/Taiwan_GRCA.crt not found, but 
> listed in /etc/ca-certificates.conf.
>   W: 
> /usr/share/ca-certificates/mozilla/OISTE_WISeKey_Global_Root_GA_CA.crt not 
> found, but listed in /etc/ca-certificates.conf.
>   W: 
> /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_Root_CA_-_G2.crt not 
> found, but listed in /etc/ca-certificates.conf.
>   W: 
> /usr/share/ca-certificates/mozilla/EE_Certification_Centre_Root_CA.crt not 
> found, but listed in /etc/ca-certificates.conf.
>   0 added, 0 removed; done.
>   Running hooks in /etc/ca-certificates/update.d...
> 
>   updates of cacerts keystore disabled.
>   done.
> 
> 
> Finally gave up and copied ca-certificates.conf from the machine that was
> working, re-ran update-ca-certificates and it got rid of the warnings and
> fetchmail and openssl were happy again. I don't fully understand how
> /etc/ca-certificates.conf is generated and don't remember ever changing it.
> 
> --
> Aristeu
>

Bug#995708: docker.io: dockerd dies with Illegal Instruction when run on a pre-SSE2-class x86 system

2021-10-04 Thread Jörn Heusipp

I am by no means a Go expert, however given that docker is written in 
Go, and that Go increased the default i386 architecture requirements to 
SSE2 in 1.16 (see ), building the 
docker package with GO386=softfloat on i386 might solve this issue. The 
set of x86 CPUs supporting SSE2 but not also supporting amd64 is quite 
small. Basically, only the Pentium 4. Thus to be useful on 32bit x86 
systems in general, I think wider compatibility, even at a performance 
cost, could be considered.


Thanks,
Jörn

Bug#955610: ITP: libr4d -- Remote For Device-under-test (testlab manager lib)


Control: noowner -1
Control: retitle -1 RFP: libr4d -- Remote For Device-under-test (testlab 
manager lib)

The work done is available in https://salsa.debian.org/debian/libr4d

Bug#995716: ruby3.0 accesses the internet during the build

2021-10-04 Thread Adrian Bunk

Source: ruby3.0
Version: 3.0.2-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=ruby3.0&arch=amd64&ver=3.0.2-2&stamp=1633362344&raw=0

...
  1) Failure:
TestSocket_TCPSocket#test_initialize_connect_timeout 
[/<>/test/socket/test_tcp.rb:73]:
[Errno::ETIMEDOUT] exception expected, not #.

Finished tests in 791.435806s, 26.6073 tests/s, 3379.8319 assertions/s.
21058 tests, 2674920 assertions, 1 failures, 0 errors, 103 skips

ruby -v: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux-gnu]
make[2]: *** [uncommon.mk:800: yes-test-all] Error 1



The FTBFS is on an IPV6-only buildd, but this is forbidden
internet accesss during the build in any case.

Bug#995717: webkit2gtk: Please update CPPFLAGS on sh3 and sh4

2021-10-04 Thread John Paul Adrian Glaubitz

Source: webkit2gtk
Version: 2.34.0-1
Severity: normal
Tags: patch
User: debian-sup...@lists.debian.org
Usertags: sh3 sh4
X-Debbugs-Cc: debian-sup...@lists.debian.org

Hello!

I've made another attempt building webkit2gtk on sh4 and I finally managed to
build the package again with by dropping "-mlra" and lowering the optimization
level to 1:

--- debian/rules.orig   2021-09-23 12:10:43.0 +0200
+++ debian/rules2021-10-04 18:02:27.495610679 +0200
@@ -45,7 +45,7 @@
 # See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
 # and: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
 ifneq (,$(filter $(DEB_HOST_ARCH),sh3 sh4))
-CPPFLAGS += -mlra -fno-move-loop-invariants
+CPPFLAGS += -O1
 endif
 
 ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))

Could you update debian/rules with those changes above? I will check later which
of the optimizations from -O2 are actually responspible for the internal 
compiler
error and report the issue upstream or update the existing bug report.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig   2021-09-23 12:10:43.0 +0200
+++ debian/rules2021-10-04 18:02:27.495610679 +0200
@@ -45,7 +45,7 @@
 # See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
 # and: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
 ifneq (,$(filter $(DEB_HOST_ARCH),sh3 sh4))
-CPPFLAGS += -mlra -fno-move-loop-invariants
+CPPFLAGS += -O1
 endif
 
 ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))

Bug#993350: Also broken on Perfection 1640

2021-10-04 Thread ael

I too am seeing this problem on my Perfection 1640SU.
Pressing the acquire preview gives the message
"Failed to start scanner: Operation not supported".

This on Debian testing.

Now on the Advanced Options window, there is an
Autofocus button. I have deactivated it. I am pretty certain that this
model has no autofocus mechanism.

There  is also a Focus position bar. Again, I don't think this model
has any way to implement that. So I suspect that the "Operation
not supported" is to adjust the focus.

The old xsane (I probably mean the epson backend) just showed two
settings: "Focus on glass" or "Focus on film". That is from memory,
but something close to that. SO perhaps this old model had just
a binary switch for two focus positions, and the epson backend
has been broken by assuming that this model has more focus facilities.

So far this is pure speculation on my part.

ael

Bug#995691: [INTL:sv] Swedish strings for bilibop debconf

2021-10-04 Thread Anders Jonsson


Hi Martin,
this po file fixes trivial typos in the translation. You can look at the 
attached podiff for details.


Regards,
Anders
# Translation of bilibop debconf template to Swedish
# Copyright (C) 2021 Martin Bagge 
# This file is distributed under the same license as the bilibop package.
#
# Martin Bagge , 2021
# Jonatan Nyberg , 2016.
msgid ""
msgstr ""
"Project-Id-Version: bilibop 0.5.1\n"
"Report-Msgid-Bugs-To: bili...@packages.debian.org\n"
"POT-Creation-Date: 2020-02-08 18:15+\n"
"PO-Revision-Date: 2021-10-04 09:56+0200\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.2.1\n"

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:1001
msgid "Do you intend to install bilibop-rules on a Live System ?"
msgstr "Har du för avsikt att installera bilibop-rules på ett Live-system?"

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:1001
msgid ""
"Some bilibop-rules settings can be useful on non-volatile Operating Systems, "
"when running from a removable and writable media (USB sticks, external HDD "
"or SD cards); but they are currently useless or even harmful for LiveCD or "
"LiveUSB systems."
msgstr ""
"Vissa inställningar i bilibop-rules kan vara rimliga i ett stabilt "
"operativsystem, även om det körs från flyttbart media (USB-minnen, extern "
"hårddisk eller SD-kort) men de är i allmänhet meningslösa eller till och med "
"skadliga för system som körs från LiveDB eller LiveUSB."

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:1001
msgid ""
"If you choose this option, no other question will be asked; bilibop udev "
"rules will be applied but nothing else will be modified on your system. Note "
"that in that case, this package is overkill and you should probably replace "
"it by the lighter but as much as efficient bilibop-udev package."
msgstr ""
"Om du väljer detta alternativ kommer inga andra frågor att ställas. Bilibops "
"udev-regler kommer att användas men inget annat kommer att ändras på ditt "
"system. Observera att i detta läge är paketet nog alldeles för omfattande "
"och du bör överväga att ersätta det med paketet bilibop-udev."

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:2001
msgid "Do you want to use custom bilibop rules and build them now ?"
msgstr "Vill du använda anpassade bilibop-regler och bygga dessa nu?"

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:2001
msgid ""
"If tens of removable media are plugged on the computer your system boots "
"from, bilibop udev rules can significantly increase boot time. This can be "
"avoided by using custom udev rules, which are specific to the device your "
"system is installed on."
msgstr ""
"Om tiotals flyttbara enheter är anslutna till datorn som systemet startar "
"från så kan bilibops regler tydligt orsaka en lång startprocess. Detta kan "
"undvikas genom att använda anpassade udev-regler för just den enhet som ditt "
"system är installerat på."

#. Type: boolean
#. Description
#: ../bilibop-rules.templates:2001
msgid ""
"That said, if this device can boot from different hardware port types (as "
"USB/Firewire, USB/eSATA, USB/MMC/SD, etc.), you should check the resulting "
"rules by booting your system on the alternative port type, and if necessary "
"by running 'dpkg-reconfigure bilibop-rules' again with proper options, or "
"even by editing '/etc/udev/rules.d/66-bilibop.rules'."
msgstr ""
"Dock ska det tydligt påpekas att om denna enhet kan starta från olika typer "
"av portar (t.ex. USB/Firewire, USB/eSATA, USB/MMC/SD m.fl.) så ska du "
"kontrollera reglerna genom att starta systemet från en annan port och om det "
"verkar nödvändigt köra 'dpkg-reconfigure bilibop-rules' igen med rätt "
"alternativ eller ännu hellre justera '/etc/udev/rules.d/66-bilibop.rules'."

#. Type: select
#. Choices
#: ../bilibop-rules.templates:3001
msgid "keep existing custom rules"
msgstr "behåll redan existerande anpassade regler"

#. Type: select
#. Choices
#: ../bilibop-rules.templates:3001
msgid "rebuild custom rules"
msgstr "bygg om anpassade regler"

#. Type: select
#. Choices
#: ../bilibop-rules.templates:3001
msgid "remove custom rules"
msgstr "ta bort anpassade regler"

#. Type: select
#. Description
#: ../bilibop-rules.templates:3002
msgid "What do you want to do with your custom rules ?"
msgstr "Vad vill du göra med dina anpassade regler?"

#. Type: select
#. Description
#: ../bilibop-rules.templates:3002
msgid ""
"The file '/etc/udev/rules.d/66-bilibop.rules' exists. It is specific to the "
"drive on which your system is installed and overrides the one, more generic, "
"that is provided by the bilibop-rules package (in '/usr/lib/udev/rules.d')."
msgstr ""
"Filen '/etc/udev/rules.d/66-bilibop.rules' existerar. Den är specifik för "
"enheten som systemet är installerad på och gå

Bug#989334: bash: remove obsolete upgrade code from pre-wheezy from preinst

Hi,

On Tue, 1 Jun 2021 13:35:53 +0200 Helmut Grohne  wrote:
> While #958083 asks for removing bash.preinst, this bug asks for even less:
> The bash.preinst contains code for upgrading a bash that did contain /bin/sh
> to a current one. Since at least wheezy, bash did not contain /bin/sh, so
> this code can quite surely go away without trouble.
> 
> I'm attaching a patch to makes just this code go away. The deleted code
> is practically dead for years. Removing it should be uncontroversial and
> after it is removed, it becomes easier to reason about #958083 which
> asks to remove the rest of the preinst.
> 
> Essentially, this bug splits #958083 into a removing the majority of code
> that should be uncontroversial to remove.

since this is blocking our work on adding DPKG_ROOT support to the essential
package set and since bash is among the 10 remaining source packages that we
still have to patch, I would like to NMU bash with the patch provided by
Helmut. If you think this is inappropriate, please speak up. Otherwise, my plan
is to upload to DELAYED/10 in two weeks time. I'll send another mail to this
bug with the debdiff once I have the NMU ready.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#995718: grub2: enable RISC-V support

2021-10-04 Thread Heinrich Schuchardt


Package: grub2
Version: 2.04-20
Severity: wishlist

When upgrading to grub 2.06, please, consider enabling RISC-V support.

The patches currently are still in review upstream.

I hold a copy in:

https://github.com/xypron/grub-build/tree/qemu-riscv64/patch as

0001-loader-drop-argv-argument-in-grub_initrd_load.patch
0001-efi-add-definition-of-LoadFile2-protocol.patch
0001-efi-implemented-LoadFile2-initrd-loading-protocol-fo.patch
0001-linux-ignore-FDT-unless-we-need-to-modify-it.patch
0001-loader-Move-arm64-linux-loader-to-common-code.patch
0001-RISC-V-Update-image-header.patch
0001-RISC-V-Use-common-linux-loader.patch

Best regards

Heinrich

Bug#994963: dash: please support DPKG_ROOT

Hi,

On Fri, 24 Sep 2021 08:01:56 +0200 Johannes Schauer Marin Rodrigues 
 wrote:
> since dpkg 1.18.5, dpkg sets the variable DPKG_ROOT when invoking maintainer
> scripts. Usually that variable is empty but when calling dpkg with --root and
> --force-script-chrootless, dpkg will set DPKG_ROOT to the new root directory.
> In that mode, maintainer scripts are called without chroot(1) around them,
> and thus have to be able to possibly operate on the path from DPKG_ROOT
> instead of working on /. This is useful for bootstrapping, creating chroots
> for foreign architectures where utilities from inside the chroot cannot be
> executed, avoiding dependency loops between postinst scripts, installation
> without requiring superuser privileges and for creating installations that do
> not even contain dpkg. See
> https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap for more
> information.
> 
> We have set up a weekly salsa job that patches 10 source packages plus
> dash and then shows how a chroot created with DPKG_ROOT is bit-by-bit
> identical to a chroot created the normal way:
> 
> https://salsa.debian.org/helmutg/dpkg-root-demo/-/pipelines
> 
> The changes needed for dash are twofold:
> 
>  1. prefixing paths in dash.postinst with DPKG_ROOT (this bug)
>  2. replacing add-shell with triggers once debianutils >= 5.1-1 migrates
> to testing
> 
> Since debianutils is currently blocked from migration, this bug is about
> the first item.
> 
> Please consider applying the attached patch.

if you have no objections, I would prepare an NMU of dash with the changes in
above patch. What do you think?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#995432: fetchmail is affected

2021-10-04 Thread Aristeu Rozanski

On Mon, Oct 04, 2021 at 05:10:41PM +0200, Julien Cristau wrote:
> I think what you're seeing can be explained if you had
> ca-certificates/trust_new_crts disabled (see debconf-show
> ca-certificates) when ISRG Root X1 was added, in which case the "new"
> root wouldn't be in your bundle and so you wouldn't have a trust path to
> LE certs after the DST Root's expiration.

Yep, it was on 'ask' but I do unattended upgrades.
Thanks

-- 
Aristeu

Bug#994963: dash: please support DPKG_ROOT

2021-10-04 Thread Andrej Shadura

Hi,

On Mon, 4 Oct 2021, at 18:22, Johannes Schauer Marin Rodrigues wrote:
> if you have no objections, I would prepare an NMU of dash with the changes in
> above patch. What do you think?

I will upload it myself a bit later; however, I’m thinking maybe it would make 
more sense to get rid of most of the code there and drop diversions too. 
However, I don’t have capacity for that sort of changes now, but I’m also a bit 
hesitant to apply changes which will likely have to go away soon.

-- 
Cheers,
  Andrej

Bug#995719: bind9-host: dighost.c:2626: aborted

2021-10-04 Thread Tomáš Szaniszlo

Package: bind9-host
Version: 1:9.16.15-1
Severity: normal

During the today's outage of Facebook I obsereved a crash of host with SIGABRT:

$ host facebook.com
Host facebook.com not found: 2(SERVFAIL)
dighost.c:2626: REQUIRE((__builtin_expect(!!(((query)) != ((void *)0)), 1) && 
__builtin_expect(!!(((const isc__magic_t *)((query)))->magic == ((('D') << 24 | 
('i') << 16 | ('g') << 8 | ('q', 1))) failed, back trace
#0 0x7f8832ba2e47 in ??
#1 0x7f8832ba2d9a in ??
#2 0x55cbdab6ab6a in ??
#3 0x7f8832bd7720 in ??
#4 0x7f8832bdcf52 in ??
#5 0x7f8832b47eae in ??
#6 0x7f8832a77a5f in ??
Aborted

However, it does not seem to be reproducible; possibly due to a change of
circumstances in the meantime.

Best wishes
TomaS

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

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

Versions of packages bind9-host depends on:
ii  bind9-libs  1:9.16.15-1
ii  libc6   2.32-4
ii  libidn2-0   2.3.2-2

bind9-host recommends no packages.

bind9-host suggests no packages.

-- no debconf information

Bug#995720: RM: perl6-tap-harness -- ROM; obsolete, replaced by raku-tap-harness

2021-10-04 Thread Dominique Dumont

Package: ftp.debian.org
Severity: normal

Hi

Following the perl6 to raku rename, the name of this package was also
changed. Hence perl6-tap-harness was replaced by raku-tap-harness.

All the best

Bug#995721: tnftp: d/copyright is incomplete


Package: tnftp
Severity: important

The tnftp package's copyright file contains only the BSD-4-clause license. There are also 
2- and 3-clause BSD licensed files in the project with some copyright statements not 
included. Please fix the licenses and copyright statements. When you have fixed #995712 
you can ignore the copyright statements for libedit/* because they are not included in the 
resulting binary then.

Bug#995722: loash: Vendoring should be removed

2021-10-04 Thread Bastien Roucariès

Source: src:node-lodash
Version: 4.17.21+dfsg+~cs8.31.173-1
Severity: serious
Justification: do not compile from source

Dear Maintainer,

The vendor directory should be emptied

The debug version is compiled without source (lintian warn) and moreover the
rest of file are already packaged

grep -R vendor * gives only a few hit that could be cured by symlinking

Bastien

Bug#995714: gnome-shell freezes with error

2021-10-04 Thread Simon McVittie

On Mon, 04 Oct 2021 at 16:35:10 +0200, tkoeck wrote:
>  16:32:01 tron-nb gnome-shell[30171]: pushModal: invocation of begin_modal 
> failed
> Oct  4 16:32:05 tron-nb gnome-shell[30171]: pushModal: invocation of 
> begin_modal failed
> Oct  4 16:32:07 tron-nb gnome-shell[30171]: pushModal: invocation of 
> begin_modal failed
> Oct  4 16:32:07 tron-nb gnome-shell[30171]: pushModal: invocation of 
> begin_modal failed
> 
> Only a kill with hub to the gnome-shell process helps

Please could you say more about how to reproduce this problem? Is there a
particular application, or a particular UI action, or anything like that,
that triggers this?

Are you using any GNOME Shell extensions? If you are, does this still
happen after you disable the extensions?

Release team: it's possible that this is a regression in
gnome-shell_3.38.6-1~deb11u1, which is queued for inclusion in the Debian
11.1 point release. I'll try to get more information.

smcv

Bug#995723: ITP: r-cran-dbscan -- Density Based Clustering of Applications with Noise (DBSCAN)