Bug#983727: thinkfan should not ship an example in /etc/thinkfan.yaml

[Evgeni Golov]

found 983727 1.2.1-1
thanks

Hey David!

Thanks for the report.

On February 28, 2021 9:29:54 PM UTC, "David Prévot"  wrote:
>Package: thinkfan
>Version: 1.2.1-3
>Severity: serious
>
>The “thinkfan Example Config File” currently shipped as
>/etc/thinkfan.yaml “is NOT a working config file that can just be
>copied” (quotes from the file itself).

Technically, neither was the old one ;)

>Pretending that “The new default configuration might not work for your
>system” in NEWS.Debian implies that it could work in some cases, but
>that does not seem to be the case at all.
>
>By installing /etc/thinkfan.yaml on systems with a working configuration
>in /etc/thinkfan.conf, the daemon simply fails to start (while simply
>removing the new /etc/thinkfan.yaml allow one to start it again).

Isn't the old one renamed to thinkfan.conf.dpkg-bak and thus not found?

>Please, ship the “thinkfan Example Config File” in
>/usr/share/doc/thinkfan/examples in order to not break existing
>configuration, especially since it can’t work as is anyway.

I'll look into this that weekend.

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

Bug#983777: libgnunet0.14: missing Breaks+Replaces: gnunet (<< 0.14.0-4)

[Andreas Beckmann]

On 01/03/2021 19.42, Daniel Baumann wrote:

On 3/1/21 6:33 PM, Andreas Beckmann wrote:

IMO only the /usr/lib/* part belongs into libgnunet0.14,
the remaining ones should have stayed in gnunet.


the idea here is that the stuff in libgnunet0.14 is used by the


If it's intentional, that is fine. Just don't forget B+R: libgnunet0.14 
if libgnunet0.15 gets uploaded some day ... ;-)



Andreas

Bug#983562: installation-reports: rtw_8822ce non-free firmware not detected with weekly build of debian installer

[Christian Britz]

Hello Cyril,

Am 27.02.21 um 11:40 schrieb Cyril Brulebois:

Any chance you could attach /var/log/installer/syslog (compressed)
through reply-all, please?
I did not find a file with exactly that path, but here comes the 
compressed /var/log/syslog


Regards,
Christian


syslog.gz
Description: application/gzip

Bug#983786: fix crash caused by a malformed DNS query/response.

[PICCORO McKAY Lenz]

Source: courier
Version: 1.0.15-1
Severity: serious

already upstream in  Fixes a crash caused by a malformed DNS query/response.

in details: backporting this:
https://github.com/svarshavchik/courier/commit/91b3f7ca6c38c9b56c93484f8687c99d6c62c091

-- 
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#983365: Info received (Bug#983365: linphone-desktop: chat messages)

[David Pirotte]

Hello,

Thanks all for having worked on this. Sorry for the little delay in
answering, I actually thought the packages would 'find their way' to
bullseye, so I was (and still am) updating daily, a few times per day
actually, but now I see you said sid, not bullseye ...

> an updated liblinphone has been uploaded to sid yesterday. Could you
> please try liblinphone10 and liblinphone++10 from sid (4.4.21-2) and
> report back? If it does not work you might need libsoci-core4.0 and
> libsoci-sqlite3-4.0 from unstable as well (4.0.1-4).

I am using bullseye (n idea why reportbug says bullseye/sid), so I
don't have the right config to pick those 2 from sid, and so many years
I haven't done this that I forgot my 'apt/preferencesfu' to do that -
but by all means, the bug is in bullseye, won't you make these packages
available in bullseye?

Thanks,
David


pgpg5XHoH7vvv.pgp
Description: OpenPGP digital signature

Bug#941624: Recommending ibus breaks fcitx

[Andreas Henriksson]

Hello Shengjing Zhu,

(FYI I've not been part of pkg-gnome maintenance for the better part of
bullseye development cycle and don't speak for pkg-gnome team, but I
feel this is not a new issue and hopefully my input can hopefully help
shed some light on the situation at hand...)

First let me be clear that IBus is *THE* input method supported by
GNOME. This is not a decision made by or influenced in any way by
pkg-gnome maintainers. The pkg-gnome maintainers simply makes
a judgement call on how to best describe the situation in the form
of package relations.

It is also my previous experience that pkg-gnome team has little to no
influence over how tasksel describes things (and I doubt anything has
changed). You might find it that a third party actually has higher
chance of getting tasksel maintainers to make changes to tasksel if they
discuss it with tasksel maintainers, rather than trying to go via
pkg-gnome team.
My personal best recommendation is to simply not use tasksel!
(And I wish I could have all the time back that I've wasted on
supporting confused users who ended up with problems from using tasksel
over simply using gnome meta-packages. Tasksel simply isn't helpful.)

All the problems you describe to me just sounds like you're describing
tasksel issues. Some specific comments for things you raised below.

On Mon, Mar 01, 2021 at 11:06:53PM +0800, Shengjing Zhu wrote:
[...]
> + Users are now possible to install two input engines. It troubles than 
> benefits.

Bring this up with input engine maintainers. If it's true that having
more than one installed at any time isn't useful, then the solution is
that they all provide a common (virtual) package which they all also
conflict against. Then pulling in one will push out all the others.

This is not related to gnome-shell!

> + And the tasksel won't install corresponding language library for ibus.
> + And for the im-config, it's not possible to decide which engine is preferred
>   by the tasksel data.

Please bring up tasksel issues with tasksel maintainers.

This is not related to gnome-shell!

> Yes you can say that users change it by hand, but it's not
>   what we want to achieve. We want a working desktop for different users by 
> default.
> 
> If GNOME maintainer want to change the default input method, it's better to
> do it in tasksel package.

I don't understand why you think tasksel has any influence over what
GNOME does Likely many/most GNOME developers aren't even aware of
tasksel existance. It's an arcane Debian-only program after all.

> 
> Please downgrade ibus to Suggests for bullseye.

It is my personal general reflection that issues like this exists
because debian maintainers tries too hard to be accomodating towards
tweakers which just causes problems and confusion.

As ripping out IBus from under GNOME already requires hacks, I think
it would simply be a better idea to bump to Depends (and tell tweakers
to use equivs). That would hopefully make the situtation less confusing
for people and more obvious that tweakers are on their own with whatever
hack they come up with. Some info already available at:
https://wiki.debian.org/InputMethodBuster

Possibly we could also consider adding (versioned?) Conflicts against
tasksel packages, since there's a long standing disconnect between GNOME
and tasksel meta-package descriptions. To be able to do versioned
conflicts tasksel would first need to have a fixed version though, so
please bring it up with them and then feedback which packages and
versions are relevant to conflict against.

As of right now, this is something I simply consider "wontfix"
from gnome-shells point of view. No matter how the package relationship
is described, the situation that GNOME relies on IBus won't change!

Please also feel free to follow up you severity bump with a
justification pointing out which specific policy paragraph you're
refering to.

Hope this helps. Please also remember that my views are mine and might
not neccessarily reflect the official pkg-gnome standpoint.

Regards,
Andreas Henriksson

Bug#983785: wims-lti: fails to install: post-installation script subprocess returned error exit status 2

[Andreas Beckmann]

Package: wims-lti
Version: 0.4.4-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up wims-lti (0.4.4-2) ...
  dpkg: error processing package wims-lti (--configure):
   installed wims-lti package post-installation script subprocess returned 
error exit status 2
  Processing triggers for libc-bin (2.31-9) ...
  Processing triggers for ca-certificates (20210119) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   wims-lti

If I insert set -x in the postinst script, the race ends with

[...]
+ db_get wims-lti/virtualHost
+ _db_cmd GET wims-lti/virtualHost
+ _db_internal_IFS=

+ IFS=
+ printf %s\n GET wims-lti/virtualHost
+ IFS=

+ read -r _db_internal_line
+ IFS=

+ RET=wims-lti.example.com
+ return 0
+ virtualHost=wims-lti.example.com
+ appDir=/var/lib/wims-lti
+ apacheConfDist=/etc/apache2/sites-available/wims-lti-django.conf-dist
+ apacheConf=/etc/apache2/sites-available/wims-lti-django.conf
+ getent passwd lti
+ lti_entry=

I'd suggest this change to fix the logic, and something similar for the group:

-lti_entry=$(getent passwd lti)
-if [ -z "$lti_entry" ]; then
+if ! getent passwd lti >/dev/null ; then


cheers,

Andreas


wims-lti_0.4.4-2.log.gz
Description: application/gzip

Bug#983784: obs-api: fails to install: Could not find gem 'data_migrate (= 5.3.1)'

[Andreas Beckmann]

Package: obs-api
Version: 2.9.4-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Setting up obs-api (2.9.4-3) ...
  [ESC][31mCould not find gem 'data_migrate (= 5.3.1)' in any of the gem 
sources listed in
  your Gemfile.[ESC][0m
  dpkg: error processing package obs-api (--configure):
   installed obs-api package post-installation script subprocess returned error 
exit status 7
  Processing triggers for libc-bin (2.31-9) ...
  Processing triggers for ca-certificates (20210119) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   obs-api


cheers,

Andreas


obs-api_2.9.4-3.log.gz
Description: application/gzip

Bug#983579: jalview 2.11.1.3+dfsg2-4: Please update the PO translation for the package jalview

[Helge Kreutzmann]

Hello Pierre,
On Mon, Mar 01, 2021 at 11:41:22AM +0100, Pierre Gruet wrote:
> I had the templates file of the debconf questions for jalview reviewed by
> debian-l10n-english. It has evolved quite a bit.

And thanks for the added explanations, it really helps understanding
the text and providing good translations.

> You can find enclosed the updated de.po, as you offered to update the
> translation after these changes. If you have time, could you please update
> it?

Please find the update translation attached. Please place it as de.po
in debian/po/

Btw., there is still a small typo:
-"Jalview cam automatically download the latest \"BioJS\" HTML export template "
+"Jalview can automatically download the latest \"BioJS\" HTML export template "
  ~~~

I suggest you wait until the deadline expires and then correct the error
and then unfuzzy all translations. If you feel uncomfortable doing so
I can support you with this, just ping me.

Best greetings

 Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the jalview package.
# Helge Kreutzmann , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: jalview 2.11.1.3+dfsg2-4\n"
"Report-Msgid-Bugs-To: jalv...@packages.debian.org\n"
"POT-Creation-Date: 2021-02-27 21:34+0100\n"
"PO-Revision-Date: 2021-03-01 19:43+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#. Translators: "identifiers" or "accessions" are short tokens that may be
#. downloaded from identifiers.org to easily access some biological databases.
#. A bit more info at identifiers.org if needed.
#: ../templates:1001
msgid "Automatically download identifiers from jalview.org?"
msgstr "Kennzeichner von www.jalview.org automatisch herunterladen?"

#. Type: boolean
#. Description
#. Translators: "identifiers" or "accessions" are short tokens that may be
#. downloaded from identifiers.org to easily access some biological databases.
#. A bit more info at identifiers.org if needed.
#: ../templates:1001
msgid ""
"Jalview can automatically download a list of identifiers.org URL templates  "
"for viewing accessions from various biological databases."
msgstr ""
"Jalview kann automatisch eine Liste von identifiers.org-URL-Vorlagen zur "
"Betrachtung von Signaturen aus verschiedenen biologischen Datenbanken."

#. Type: boolean
#. Description
#. Translators: "identifiers" or "accessions" are short tokens that may be
#. downloaded from identifiers.org to easily access some biological databases.
#. A bit more info at identifiers.org if needed.
#: ../templates:1001
msgid ""
"This is a convenience for users but can be deactivated as it causes an "
"automatic ping to www.jalview.org/services/identifiers, which records usage "
"statistics."
msgstr ""
"Dies dient der Bequemlichkeit der Benutzer, kann aber deaktiviert werden, da "
"es zu einem automtischen Ping an www.jalview.org/services/identifiers führt, "
"wo Benutzungsstatistiken aufgezeichnet werden."

#. Type: boolean
#. Description
#. Translators: "identifiers" or "accessions" are short tokens that may be
#. downloaded from identifiers.org to easily access some biological databases.
#. A bit more info at identifiers.org if needed.
#. Type: boolean
#. Description
#: ../templates:1001 ../templates:5001
msgid "Individual users can override this setting in their configuration file."
msgstr ""
"Einzelne Benutzer können diese Voreinstellung in ihrer eigenen "
"Konfigurationsdatei außer Kraft setzen."

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Automatically display news from jalview.org?"
msgstr "Neuigkeiten von jalview.org automatisch anzeigen?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Jalview can automatically show updates from https://www.jalview.org/feeds/;
"desktop/rss in a popup window."
msgstr ""
"Jalview kann automatisch Aktualisierungen von https://www.jalview.org/feeds/;
"desktop/rss in einem aufklappenden Fenster anzeigen."

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"The news feed is informative to users but its retrieval pings www.jalview."
"org, which records usage statistics."
msgstr ""
"Der Neuigkeiten-Feed ist für Benutzer informativ, aber beim Abruf wird www."
"jalview.org kontaktiert, wo Benutzungsstatistiken aufgezeichnet werden."

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"If this is disabled, users may still manually open the news reader. Users "
"can also override this preference in the Preferences window or from their "

Bug#983777: libgnunet0.14: missing Breaks+Replaces: gnunet (<< 0.14.0-4)

[Daniel Baumann]

Hi Andreas,

thanks for reporting, I totally missed one the breaks/replaced like you
pointed out.

On 3/1/21 6:33 PM, Andreas Beckmann wrote:
> IMO only the /usr/lib/* part belongs into libgnunet0.14,
> the remaining ones should have stayed in gnunet.

the idea here is that the stuff in libgnunet0.14 is used by the
non-gnunet (upcoming) packages for gnu taler, entirely unrelated to
gnunet-specific-and-not-used-by-anything-outside-of-gnunet within the
bin:gnunet package.

anyhow, there will be the one or other adjustment (i'm going to
coordinate this with upstream hopefully next week), and gnunet 0.14 will
stay quite a while in experimental until everything is ironed out.

Regards,
Daniel

Bug#983783: linux-image-5.10.0-3-amd64: tpm device nodes missing

[Jens Mueller]

Package: src:linux
Version: 5.10.13-1
Severity: normal
X-Debbugs-Cc: tschen...@gmx.de

Dear Maintainer,

the device nodes for tpm, /dev/tpm0 and /dev/tpmrm0, are not existent on my
system. There are no issues with tpm nodes on Debian Buster or Ubuntu 20.04.

Regards, Jens


-- Package-specific info:
** Version:
Linux version 5.10.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP 
Debian 5.10.13-1 (2021-02-06)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-3-amd64 
root=UUID=f0414806-9d42-4e52-be48-6a3ec394e3ba ro quiet splash

** Tainted: I (2048)
 * workaround for bug in platform firmware applied

** Kernel log:
[   11.485514] iwlwifi :04:00.0: loaded firmware version 17.3216344376.0 
3160-17.ucode op_mode iwlmvm
[   11.485536] iwlwifi :04:00.0: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[   11.485538] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   11.490718] intel_rapl_common: Found RAPL domain package
[   11.490721] intel_rapl_common: Found RAPL domain core
[   11.490724] intel_rapl_common: Found RAPL domain uncore
[   11.490726] intel_rapl_common: Found RAPL domain dram
[   11.865556] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 
3160, REV=0x164
[   11.889961] iwlwifi :04:00.0: base HW address: 34:e6:ad:05:ae:ba
[   12.002247] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[   12.018529] iwlwifi :04:00.0 wlp4s0: renamed from wlan0
[   12.356803] tpm tpm0: Operation Timed out
[   12.356866] DMAR: DRHD: handling fault status reg 3
[   12.984660] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   13.220966] Bluetooth: Core ver 2.22
[   13.220995] NET: Registered protocol family 31
[   13.220997] Bluetooth: HCI device and connection manager initialized
[   13.221000] Bluetooth: HCI socket layer initialized
[   13.221001] Bluetooth: L2CAP socket layer initialized
[   13.221005] Bluetooth: SCO socket layer initialized
[   13.272655] Adding 999420k swap on /dev/sdc3.  Priority:-2 extents:1 
across:999420k FS
[   13.389072] usbcore: registered new interface driver btusb
[   13.402850] Bluetooth: hci0: read Intel version: 3707100100012d0d2a
[   13.402852] Bluetooth: hci0: Intel device is already patched. patch num: 2a
[   13.677288] audit: type=1400 audit(1614623185.627:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=947 comm="apparmor_parser"
[   13.677912] audit: type=1400 audit(1614623185.627:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=948 comm="apparmor_parser"
[   13.685702] audit: type=1400 audit(1614623185.635:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="firejail-default" pid=950 
comm="apparmor_parser"
[   13.746466] audit: type=1400 audit(1614623185.695:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="traceroute" pid=953 
comm="apparmor_parser"
[   13.753306] audit: type=1400 audit(1614623185.703:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nmbd" pid=954 
comm="apparmor_parser"
[   13.765091] audit: type=1400 audit(1614623185.715:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=955 
comm="apparmor_parser"
[   13.765638] audit: type=1400 audit(1614623185.715:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="syslog-ng" pid=952 
comm="apparmor_parser"
[   13.776106] audit: type=1400 audit(1614623185.723:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/cups/backend/cups-pdf" pid=949 comm="apparmor_parser"
[   13.776110] audit: type=1400 audit(1614623185.723:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cupsd" pid=949 
comm="apparmor_parser"
[   13.776113] audit: type=1400 audit(1614623185.723:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/sbin/cupsd//third_party" pid=949 comm="apparmor_parser"
[   14.356840] tpm tpm0: Operation Timed out
[   14.356863] tpm_crb: probe of MSFT0101:00 failed with error -62
[   15.500319] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   15.500322] Bluetooth: BNEP filters: protocol multicast
[   15.500326] Bluetooth: BNEP socket layer initialized
[   15.572397] NET: Registered protocol family 38
[   16.758469] ACPI: \: failed to evaluate _DSM (0x1001)
[   16.758473] ACPI: \: failed to evaluate _DSM (0x1001)
[   16.919512] ACPI: \: failed to evaluate _DSM (0x1001)
[   16.919515] ACPI: \: failed to evaluate _DSM (0x1001)
[   19.694976] e1000e :00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: Rx/Tx
[   19.695010] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s25: link becomes ready
[   19.828719] [UFW BLOCK] IN=enp0s25 OUT= 
MAC=68:f7:28:c3:f6:90:ac:44:f2:4d:e4:0a:08:00 SRC=192.168.20.36 

Bug#983751: [Pkg-utopia-maintainers] Bug#983751: Info received ( Bug#983751: dosfstools-4.2 breaks vfat formatting of entire device)

[Michael Biebl]

Control: reassign -1 libblockdev2
Control: found -1 2.25-1

Am 01.03.21 um 16:54 schrieb Allison Karlitskaya:

https://github.com/storaged-project/udisks/issues/851


Thanks a lot for forwarding the issue. Reading the upstream bug report 
this appears to be a libblockdev issue, so reassigning accordingly.


Will cherry-pick the changes from 
https://github.com/storaged-project/libblockdev/pull/618 and make a new 
libblockdev release for Debian.


Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983746: firejail: with --private=, an existing "bin" directory is read-only

[Reiner Herrmann]

Hi Vincent,

On Mon, Mar 01, 2021 at 02:49:32AM +0100, Vincent Lefevre wrote:
> When using --private=, an existing "bin" directory in 
> is read-only. This is silly: this means that one cannot restart
> a firejail session:
> 
[...]
> 
> I don't see the point to have "bin" read-only in this case, as the
> purpose of "--private=" is that this "bin" directory is specific to
> the firejail session.

The reason why the bin directory is mounted read-only is the
disable-common.inc file that is included in the default and many other
profiles:
  read-only ${HOME}/bin

It's writable the first time, because it does not exist yet when the
jail is created.

If you want to allow writing in this directory, you can add a local
override in the file /etc/firejail/disable-common.local with this line:
  ignore read-only ${HOME}/bin

Alternatively you can create your own profile that does not include
disable-common.inc.

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#983781: init.c: various additions and corrections

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 5fa6eef9a1162d9ce90a8a45f6dad138502d60e2 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Mon, 1 Mar 2021 02:29:22 +
>Subject: [PATCH] init.c:

  Include  for the declaration of the data type "intptr_t".

  Remove a repeated declaration of "in_menu_mode".

  Add external variable "init_on_entry"; used here and in "nn.c".

  Add information to a message.

  Define "dflt_init_files[]" with type "const".

  Add the character array "init_files[]".

  Use "snprintf()" instead of "sprintf()".

  Declare the variable "code" to be of type "intptr_t", not "int":

init.c:793:9: warning: cast from pointer to integer of different size 
[-Wpointer-to-int-cast]
  793 |  code = (int) m_define("-2", initf);
  | ^

Signed-off-by: Bjarni Ingi Gislason 
---
 init.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/init.c b/init.c
index 676bc85..e222108 100644
--- a/init.c
+++ b/init.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include  /* For type intptr_t */
 #include 
 #include 
 #include 
@@ -74,12 +75,11 @@ extern int  terminal_speed, slow_speed;
 extern char*pname;
 extern char*start_up_macro;
 extern char*newsrc_file;
-extern int  in_menu_mode;
 extern int  do_kill_handling;
 extern char printer[];
 extern char*mail_box;
 
-
+extern int init_on_entry;
 
 void
 init_message(char *fmt,...)
@@ -237,7 +237,7 @@ chain_file:
*seq_hook_ptr = init;
return; /* no close !! */
} else {
-   init_message("load file contains 'sequence'");
+   init_message("load file %s contains 'sequence'", init);
fclose(init);
return;
}
@@ -247,23 +247,26 @@ chain_file:
 fclose(init);
 }
 
-static char dflt_init_files[] = ",init";
+static const char dflt_init_files[] = ",init";
 
 void
 visit_init_file(int only_seq, char *first_arg)
 {
 char   *next_arg;
+char  init_files[sizeof dflt_init_files];
 
 in_init = 1;
 load_init_file(relative(lib_directory, "setup"), (FILE **) NULL, 0);
 in_init = 0;
 
+strcpy(init_files, dflt_init_files);
+
 if (first_arg && strncmp(first_arg, "-I", 2) == 0) {
if (first_arg[2] == NUL)
return;
first_arg += 2;
 } else
-   first_arg = dflt_init_files;
+   first_arg = init_files;
 
 in_init = 1;
 while (first_arg) {
@@ -439,7 +442,7 @@ alt_completion(char *buf, int index)
 
case 2:
other_compl = file_completion;
-   sprintf(buffer, "%s.%s",
+   snprintf(buffer, FILENAME, "%s.%s",
relative(help_directory, "help"), head);
len = strlen(buffer);
head = buffer + len;
@@ -739,7 +742,9 @@ err:
 static int
 do_map(FILE * initf)
 {
-int code, map_menu, map_show, must_redraw = 0;
+intptr_tcode;
+int map_menu, map_show, must_redraw = 0;
+
 key_typebind_to;
 register struct key_map_def *map_def;
 register int   *map;
@@ -790,7 +795,7 @@ do_map(FILE * initf)
 map_menu = map_def->km_flag & K_BIND_ORIG;
 
 if (ARG(3, "(")) {
-   code = (int) m_define("-2", initf);
+   code = (intptr_t) m_define("-2", initf);
must_redraw = 1;
if (code == K_UNBOUND)
goto mac_err;
@@ -943,11 +948,14 @@ parse_on_to_end(FILE * f)
if (ARGTAIL) {
for (ii = 2; argv(ii); ii++) {
start_group_search(argv(ii));
-   while ((gh = get_group_search()))
+   while ((gh = get_group_search())) {
gh->enter_macro = macro;
+   }
}
} else
dflt_enter_macro = macro;
+/* Repeat reading the init file if "on entry" is there */
+   init_on_entry = 1;
return;
}
 
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#983782: zfsutils-linux: zpool import failed: one or more devices is currently unavailable

[Patrice Duroux]

Package: zfsutils-linux
Version: 2.0.3-1
Severity: normal

Hi,

After creating a pool ('store') with a file system dataset ('store/scratch'),
everything was fine to me until a reboot after which all the setting seemed to
be lost.

I started to address by simply running:
$ zpool import store
cannot import 'store': no such pool available

Then I checked systemd services and found 'zfs-import-cache.service' in a
failed state.
So using 'journalctl' I saw the following:

mars 01 13:31:26 chipiron systemd[1]: Starting Install ZFS kernel module...
mars 01 13:31:26 chipiron systemd[1]: Finished Install ZFS kernel module.
mars 01 13:31:26 chipiron kernel: ZFS: Loaded module v2.0.3-1, ZFS pool version
5000, ZFS filesystem version 5
mars 01 13:31:26 chipiron systemd[1]: Starting Import ZFS pools by cache
file...
mars 01 13:31:27 chipiron zpool[2397]: cannot import 'store': one or more
devices is currently unavailable
mars 01 13:31:27 chipiron systemd[1]: zfs-import-cache.service: Main process
exited, code=exited, status=1/FAILURE
mars 01 13:31:27 chipiron systemd[1]: zfs-import-cache.service: Failed with
result 'exit-code'.
mars 01 13:31:27 chipiron systemd[1]: Failed to start Import ZFS pools by cache
file.
mars 01 13:31:27 chipiron systemd[1]: Reached target ZFS pool import target.
mars 01 13:31:27 chipiron systemd[1]: Starting Mount ZFS filesystems...
mars 01 13:31:27 chipiron systemd[1]: Starting Wait for ZFS Volume (zvol) links
in /dev...
mars 01 13:31:27 chipiron systemd[1]: Finished Mount ZFS filesystems.

Then looking at this service, I realized that 'zool import' needed to explain
the cache file unlike
all the other zpool commands, weird!

But at least I was able to reproduced the error running:
$ zpool import -c /etc/zfs/zpool.cache -aN
cannot import 'store': one or more devices is currently unavailable

Here is the 'zdb' output:

$ zdb
store:
version: 5000
name: 'store'
state: 0
txg: 4
pool_guid: 14836119471077797826
errata: 0
hostid: 1739059050
hostname: 'chipiron'
com.delphix:has_per_vdev_zaps
vdev_children: 1
vdev_tree:
type: 'root'
id: 0
guid: 14836119471077797826
create_txg: 4
children[0]:
type: 'raidz'
id: 0
guid: 9286456085254631639
nparity: 1
metaslab_array: 134
metaslab_shift: 34
ashift: 12
asize: 7201382989824
is_log: 0
create_txg: 4
com.delphix:vdev_zap_top: 129
children[0]:
type: 'disk'
id: 0
guid: 14694741801978214455
path: '/dev/sdb1'
devid: 'scsi-3539a38598c81-part1'
phys_path: 'pci-:33:00.0-sas-phy2-lun-0'
whole_disk: 1
create_txg: 4
com.delphix:vdev_zap_leaf: 130
children[1]:
type: 'disk'
id: 1
guid: 1592048366807419050
path: '/dev/sdc1'
devid: 'scsi-3539a385991e9-part1'
phys_path: 'pci-:33:00.0-sas-phy4-lun-0'
whole_disk: 1
create_txg: 4
com.delphix:vdev_zap_leaf: 131
children[2]:
type: 'disk'
id: 2
guid: 18150426818928785530
path: '/dev/sdd1'
devid: 'scsi-3539a38598709-part1'
phys_path: 'pci-:33:00.0-sas-phy7-lun-0'
whole_disk: 1
create_txg: 4
com.delphix:vdev_zap_leaf: 132
children[3]:
type: 'disk'
id: 3
guid: 11296186532713133135
path: '/dev/sde1'
devid: 'scsi-3539a385986d1-part1'
phys_path: 'pci-:33:00.0-sas-phy5-lun-0'
whole_disk: 1
create_txg: 4
com.delphix:vdev_zap_leaf: 133
features_for_read:
com.delphix:hole_birth
com.delphix:embedded_data

Here is also the 'fdisk' output:

$ LANG=C fdisk -l /dev/sdb /dev/sdc /dev/sdd /dev/sde
Disk /dev/sdb: 1.64 TiB, 1800360124416 bytes, 3516328368 sectors
Disk model: AL15SEB18EQY
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 271363D9-0F42-4F4E-BDE1-C8E2190DC266

Device  StartEndSectors  Size Type
/dev/sdb12048 3516311551 3516309504  1.6T Solaris /usr & Apple ZFS
/dev/sdb9  3516311552 3516327935  163848M Solaris reserved 1


Disk /dev/sdc: 1.64 TiB, 1800360124416 bytes, 3516328368 sectors
Disk model: AL15SEB18EQY
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 

Bug#983774: radicale: events.example.org.conf has ref to wrong file

[Jonas Smedegaard]

Control: forcemerge 959073 -1

Hi Wim,

Quoting wim (2021-03-01 18:06:22)
> The /usr/share/doc/radicale/examples/apache2-vhost.conf
> should have
> 
> radicale-uwsgi.conf
> 
> instead of
> 
> radicale.conf (nonexistent)

Thanks for reporting this issue.

It was previously reporteded by Michael Jarosch as well, and has been 
fixed since radicale 2.1.12.

The issue is considered too minor for a stable bugfix.

Kind regards,

 - 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#983780: impass: impass gui fails silently when trying to create a new password when ~/.impass/keyid refers to an OpenPGP certificate incapable of signing

[Daniel Kahn Gillmor]

Package: impass
Version: 0.12.2-1

After transitioned to a new key (but failing to update ~/.impass/keyid),
i tried to use impass to create a new password (yes, i saw the red
warning message about being unable to verify the signature).  Clicking
"Create" in the gui after entering the new context string did nothing --
it just silently failed.  on stderr, i see:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gpg/core.py", line 308, in encrypt
self.op_encrypt_sign(recipients, flags, plaintext, ciphertext)
  File "/usr/lib/python3/dist-packages/gpg/core.py", line 163, in wrapper
return _funcwrap(self, *args)
  File "/usr/lib/python3/dist-packages/gpg/core.py", line 141, in _funcwrap
return errorcheck(result, name)
  File "/usr/lib/python3/dist-packages/gpg/errors.py", line 129, in errorcheck
raise GPGMEError(retval, extradata)
gpg.errors.GPGMEError: gpgme_op_encrypt_sign: Unspecified source: Unusable 
secret key

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/impass/gui.py", line 466, in 
simpleclicked
self.create(None)
  File "/usr/lib/python3/dist-packages/impass/gui.py", line 486, in create
self.db.save()
  File "/usr/lib/python3/dist-packages/impass/db.py", line 227, in save
encdata = self._encryptDB(cleardata, keyid)
  File "/usr/lib/python3/dist-packages/impass/db.py", line 124, in _encryptDB
encdata, _, _ = self._gpg.encrypt(data, [recipient],
  File "/usr/lib/python3/dist-packages/gpg/core.py", line 324, in encrypt
raise errors.InvalidSigners(
gpg.errors.InvalidSigners: F20691179038E5C6: No secret key

It's appropriate that impass should not be able to make such a
signature (and therefore probably appropriate to fail), but
inappropriate to fail silently.  there should be  clearer diagnostics
presented to the user in this case.

  --dkg


signature.asc
Description: PGP signature

Bug#983779: gitlab: Installation fails with "TypeError: Throttle is not a module"

[Lars Kruse]

Package: gitlab
Version: 13.7.7-1~fto10+1
Severity: normal

Dear Maintainer,

while upgrading from 13.6.7 to 13.7.7, the installation stops (see error
log below).

The cause of the error was guessed within minutes via IRC (thanks!):

> 18:49  sumpfralle1: that looks like an obsolete initializer that I 
> did not see. I guess you have been upgrading for a long time. Thanks for 
> testing
> 18:50  Can you open a bug? I will remove it automatically from next 
> version.
> 18:51  For now, you can remove this file manually.
> 18:51  Remove the initializers/rack_attack_global.rb

Cheers,
Lars


Attention: used pure ruby version of MurmurHash3
DEPRECATION WARNING: ActionDispatch::Http::ParameterFilter is deprecated and 
will be removed from Rails 6.1. Use ActiveSupport::ParameterFilter instead. 
(called from  at 
/usr/lib/ruby/vendor_ruby/grape_logging/util/parameter_filter.rb:2)
/usr/share/gitlab/lib/gitlab.rb:38: warning: already initialized constant 
Gitlab::COM_URL
/usr/share/gitlab/lib/gitlab.rb:38: warning: previous definition of COM_URL was 
here
/usr/share/gitlab/lib/gitlab.rb:39: warning: already initialized constant 
Gitlab::STAGING_COM_URL
/usr/share/gitlab/lib/gitlab.rb:39: warning: previous definition of 
STAGING_COM_URL was here
/usr/share/gitlab/lib/gitlab.rb:40: warning: already initialized constant 
Gitlab::APP_DIRS_PATTERN
/usr/share/gitlab/lib/gitlab.rb:40: warning: previous definition of 
APP_DIRS_PATTERN was here
/usr/share/gitlab/lib/gitlab.rb:41: warning: already initialized constant 
Gitlab::SUBDOMAIN_REGEX
/usr/share/gitlab/lib/gitlab.rb:41: warning: previous definition of 
SUBDOMAIN_REGEX was here
/usr/share/gitlab/lib/gitlab.rb:42: warning: already initialized constant 
Gitlab::VERSION
/usr/share/gitlab/lib/gitlab.rb:42: warning: previous definition of VERSION was 
here
/usr/share/gitlab/lib/gitlab.rb:43: warning: already initialized constant 
Gitlab::INSTALLATION_TYPE
/usr/share/gitlab/lib/gitlab.rb:43: warning: previous definition of 
INSTALLATION_TYPE was here
/usr/share/gitlab/lib/gitlab.rb:44: warning: already initialized constant 
Gitlab::HTTP_PROXY_ENV_VARS
/usr/share/gitlab/lib/gitlab.rb:44: warning: previous definition of 
HTTP_PROXY_ENV_VARS was here
rake aborted!
TypeError: Throttle is not a module
/usr/share/gitlab/lib/gitlab/throttle.rb:4: previous definition of Throttle was 
here
/usr/share/gitlab/config/initializers/rack_attack_global.rb:1:in `'
/usr/share/rubygems-integration/all/gems/activesupport-6.0.3.4/lib/active_support/dependencies.rb:318:in
 `load'
/usr/share/rubygems-integration/all/gems/activesupport-6.0.3.4/lib/active_support/dependencies.rb:318:in
 `block in load'
/usr/share/rubygems-integration/all/gems/activesupport-6.0.3.4/lib/active_support/dependencies.rb:291:in
 `load_dependency'
/usr/share/rubygems-integration/all/gems/activesupport-6.0.3.4/lib/active_support/dependencies.rb:318:in
 `load'
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/engine.rb:666:in
 `block in load_config_initializer'
/usr/share/rubygems-integration/all/gems/activesupport-6.0.3.4/lib/active_support/notifications.rb:182:in
 `instrument'
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/engine.rb:665:in
 `load_config_initializer'
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/engine.rb:625:in
 `block (2 levels) in '
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/engine.rb:624:in
 `each'
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/engine.rb:624:in
 `block in '
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/initializable.rb:32:in
 `instance_exec'
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/initializable.rb:32:in
 `run'
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/initializable.rb:61:in
 `block in run_initializers'
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/initializable.rb:50:in
 `each'
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/initializable.rb:50:in
 `tsort_each_child'
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/initializable.rb:60:in
 `run_initializers'
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/application.rb:363:in
 `initialize!'
/usr/share/gitlab/config/environment.rb:5:in `'
/usr/share/rubygems-integration/all/gems/activesupport-6.0.3.4/lib/active_support/dependencies.rb:324:in
 `require'
/usr/share/rubygems-integration/all/gems/activesupport-6.0.3.4/lib/active_support/dependencies.rb:324:in
 `block in require'
/usr/share/rubygems-integration/all/gems/activesupport-6.0.3.4/lib/active_support/dependencies.rb:291:in
 `load_dependency'
/usr/share/rubygems-integration/all/gems/activesupport-6.0.3.4/lib/active_support/dependencies.rb:324:in
 `require'
/usr/share/rubygems-integration/all/gems/railties-6.0.3.4/lib/rails/application.rb:339:in
 `require_environment!'

Bug#978105: vorta: SIGSEGV on exit

[Manuel Riel]

Hi Nicholas,

I was actually working on this over the weekend and already merged another fix 
for this into the current master branch earlier today

The trick was to remove the system tray *before* quitting the app itself. Fix 
is 2 lines:

https://github.com/borgbase/vorta/blob/master/src/vorta/application.py#L108

Didn't see the issue since then. Hope it's the same for you. There can be some 
differences depending on how Qt was installed. And they made some changes to 
their Python package a few days ago. The Arch guys were bitten by that.

Manu

> I can confirm that the fix included in 0.7.4 changes the trigger case
> for me, and after about a dozen runs of manual testing I found that I
> could reliably trigger this crash 4/4 times:
> 
> 1. With a new user who has no Vorta config
> 2. Open Vorta
> 3. Do nothing
> 4. Quit from tray icon
> 5. Exit code 139 (SIGEGV)
> 

Bug#976553: mojoshader: FTBFS: segfaults

[Adrian Bunk]

Control: tags -1 patch

>...
> > make[3]: Entering directory '/<>/obj-aarch64-linux-gnu'
> > [  9%] Generating ../mojoshader_parser_hlsl.h
> > ./lemon -q -T/<>/misc/lempar.c 
> > /<>/mojoshader_parser_hlsl.lemon
> > Segmentation fault
> > make[3]: *** [CMakeFiles/mojoshader.dir/build.make:86: 
> > ../mojoshader_parser_hlsl.h] Error 139
>...

The attached patch fixes the segfault on architectures where char is 
unsigned.

cu
Adrian
Description: Fix FTBFS on architectures where char is unsigned
Author: Adrian Bunk 
Bug-Debian: https://bugs.debian.org/976553

--- mojoshader-0.0~hg1314+dfsg.orig/misc/lemon.c
+++ mojoshader-0.0~hg1314+dfsg/misc/lemon.c
@@ -3466,7 +3466,7 @@ void print_stack_union(
   int maxdtlength;  /* Maximum length of any ".datatype" field. */
   char *stddt;  /* Standardized name for a datatype */
   int i,j;  /* Loop counters */
-  int hash; /* For hashing the name of a type */
+  unsigned int hash;/* For hashing the name of a type */
   const char *name; /* Name of the parser */
 
   /* Allocate and initialize types[] and allocate stddt[] */

Bug#983778: claws-mail: Segfault on selecting empty 'X-Face' custom header

[Florian Zieboll]

Package: claws-mail
Version: 3.17.3-2
Severity: normal
Tags: upstream


Hello,

when selecting an empty 'X-Face' custom header with mouse or keyboard (tab /
arrow down) under "Current custom headers" ("Configuration" -> "Edit accounts"
-> select account and "Edit" -> "Send" -> check "Add user-defined header" ->
"Edit"), claws-mail segfaults immediately.


related lines of 'strace -f' output:

[pid  5951] recvmsg(3, {msg_name=NULL, 
msg_namelen=0,msg_iov=[{iov_base="\2\27\rP1\256\233\0h\1\0\0\250\2\240\2\0\0\0\0\362\3g\2\21\1w\0\20\0\1\0",iov_len=4096}],
 msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
[pid  5951] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource 
temporarilyunavailable)
[pid  5951] poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 
([{fd=3,revents=POLLOUT}])
[pid  5951] 
writev(3,[{iov_base="\24\0\6\0h\1\0\0g\1\0\0!\0\0\0\0\0\0\0\377\377\377\377",iov_len=24},
 {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 24
[pid  5951] poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
[pid  5951] recvmsg(3, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\1\16P\1\0\0\0!\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,iov_len=4096}],
 msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 36
[pid  5951] poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 
([{fd=3,revents=POLLOUT}])
[pid  5951] writev(3, 
[{iov_base="\22\0\7\0\247\2\240\2Z\1\0\0\6\0\0\0\0\0\0\1\0\0\0001\256\233\0\26\0\4\0"...,
 iov_len=52}, {iov_base=NULL,iov_len=0}, {iov_base="", iov_len=0}], 3) = 52
[pid  5951] poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
[pid  5951] recvmsg(3, {msg_name=NULL, 
msg_namelen=0,msg_iov=[{iov_base="\34\0\17P\247\2\240\2Z\1\0\0004\256\233\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,iov_len=4096}],
 msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
[pid  5951] poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
[pid  5951] recvmsg(3, {msg_name=NULL, 
msg_namelen=0,msg_iov=[{iov_base="W\0\20P\1\0\240\2\0\0\0\0\1\0\0\0004\256\233\0001\256\233\0\0\0\0\0\0\0\0\0"...,iov_len=4096}],
 msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
[pid  5951] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL}
---
[pid  5952] <... poll resumed> ) = ?
[pid  5953] <... poll resumed> ) = ?
[pid  5953] +++ killed by SIGSEGV +++
[pid  5952] +++ killed by SIGSEGV +++
+++ killed by SIGSEGV +++
Segmentation fault



-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 3 (beowulf)
Release:3
Codename:   beowulf
Architecture: x86_64

Kernel: Linux 4.19.0-14-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages claws-mail depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4+deb10u1
ii  libcompfaceg11:1.5.2-5+b2
ii  libcurl3-gnutls  7.64.0-4+deb10u1
ii  libdb5.3 5.3.28+dfsg1-0.5
ii  libenchant1c2a   1.6.0-11.1+b1
ii  libetpan20   1.9.3-2
ii  libexpat12.2.6-2+deb10u1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u2
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgnutls30  3.6.7-4+deb10u6
ii  libgtk2.0-0  2.24.32-3
ii  libice6  2:1.0.9-2
ii  libldap-2.4-22.4.47+dfsg-3+deb10u6
ii  liblockfile1 1.14-1.1
ii  libnettle6   3.4.1-1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  librsvg2-2   2.44.10-2.1+deb10u3
ii  libsasl2-2   2.1.27+dfsg-1+deb10u1
ii  libsm6   2:1.2.3-1
ii  xdg-utils1.1.3-1+deb10u1

Versions of packages claws-mail recommends:
ii  aspell-de [aspell-dictionary]  20161207-7
ii  aspell-en [aspell-dictionary]  2018.04.16-0-1
ii  claws-mail-i18n3.17.3-2
ii  xfonts-100dpi  1:1.0.4+nmu1
ii  xfonts-75dpi   1:1.0.4+nmu1

Versions of packages claws-mail suggests:
ii  chromium [www-browser] 88.0.4324.182-1~deb10u1
pn  claws-mail-doc 
ii  claws-mail-tools   3.17.3-2
ii  dillo [www-browser]3.0.5-5
ii  edbrowse [www-browser] 3.7.4-3
ii  firefox-esr [www-browser]  78.8.0esr-1~deb10u1
pn  gedit | kwrite | mousepad | nedit  
ii  links2 [www-browser]   2.18-2
ii  lynx [www-browser] 2.8.9rel.1-3
ii  w3m [www-browser]  0.5.3-37

-- no debconf information

Bug#983777: libgnunet0.14: missing Breaks+Replaces: gnunet (<< 0.14.0-4)

[Andreas Beckmann]

Package: libgnunet0.14
Version: 0.14.0-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libgnunet0.14_0.14.0-4_amd64.deb ...
  Unpacking libgnunet0.14 (0.14.0-4) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libgnunet0.14_0.14.0-4_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/gnunet-arm', which is also in package gnunet 
0.13.1-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libgnunet0.14_0.14.0-4_amd64.deb


The following files were moved from gnunet/sid to libgnunet0.14/experimental:

usr/bin/gnunet-arm
usr/bin/gnunet-bugreport
usr/bin/gnunet-config
usr/bin/gnunet-ecc
usr/lib/x86_64-linux-gnu/gnunet/libexec/gnunet-service-arm
usr/lib/x86_64-linux-gnu/libgnunetarm.so.2
usr/lib/x86_64-linux-gnu/libgnunetarm.so.2.0.0
usr/lib/x86_64-linux-gnu/libgnunetcurl.so.0
usr/lib/x86_64-linux-gnu/libgnunetcurl.so.0.0.0
usr/lib/x86_64-linux-gnu/libgnunetjson.so.0
usr/lib/x86_64-linux-gnu/libgnunetjson.so.0.0.0
usr/lib/x86_64-linux-gnu/libgnunetpq.so.1
usr/lib/x86_64-linux-gnu/libgnunetpq.so.1.0.0
usr/lib/x86_64-linux-gnu/libgnunetsq.so.0
usr/lib/x86_64-linux-gnu/libgnunetsq.so.0.0.0
usr/lib/x86_64-linux-gnu/libgnunetutil.so.13
usr/lib/x86_64-linux-gnu/libgnunetutil.so.13.0.2
usr/share/gnunet/config.d/util.conf
usr/share/locale/de/LC_MESSAGES/gnunet.mo
usr/share/locale/es/LC_MESSAGES/gnunet.mo
usr/share/locale/fr/LC_MESSAGES/gnunet.mo
usr/share/locale/it/LC_MESSAGES/gnunet.mo
usr/share/locale/sv/LC_MESSAGES/gnunet.mo
usr/share/locale/vi/LC_MESSAGES/gnunet.mo
usr/share/locale/zh_CN/LC_MESSAGES/gnunet.mo
usr/share/man/man1/gnunet-arm.1.gz
usr/share/man/man1/gnunet-bugreport.1.gz
usr/share/man/man1/gnunet-config.1.gz
usr/share/man/man1/gnunet-ecc.1.gz

IMO only the /usr/lib/* part belongs into libgnunet0.14,
the remaining ones should have stayed in gnunet.
(Even if the non-libs get moved back, you still need the B+R
for the moved libraries.)

cheers,

Andreas


gnunet=0.13.1-2_libgnunet0.14=0.14.0-4.log.gz
Description: application/gzip

Bug#983776: libvkd3d-dev 1.2-3 breaks multi-arch support

[Francois Gouget]

Package: libvkd3d-dev
Version: 1.2-3
Severity: normal


libvkd3d-dev 1.2-3 ships the architecture-dependent
/usr/bin/vkd3d-compiler file which is incompatible with "Multi-Arch:
same".

So as is the package is invalid.

Multiarch support in vkd3d is really needed though because Wine
depends on it as Windows applications come in both 32-bit and 64-bit
flavors. So lack of multiarch support in vkd3d prevents Wine from
having D3D12 support in either its 32- or 64-bit versions thus making
development much harder.

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

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

Versions of packages libvkd3d-dev depends on:
ii  libc6 2.28-10
ii  libvkd3d-shader1  1.2-3
ii  libvkd3d-utils1   1.2-3
ii  libvkd3d1 1.2-3

libvkd3d-dev recommends no packages.

libvkd3d-dev suggests no packages.

-- no debconf information

Bug#983775: libgrokj2k: Baseline violation on amd64/i386

[Adrian Bunk]

Source: libgrokj2k
Version: 7.6.6-1
Severity: serious
Tags: patch

https://buildd.debian.org/status/fetch.php?pkg=libgrokj2k=amd64=7.6.6-1=1612309672=0

...
cd /<>/obj-x86_64-linux-gnu/src/lib/jp2 && /usr/bin/c++ 
-DSPDLOG_COMPILED_LIB -Dgrokj2k_EXPORTS 
-I/<>/obj-x86_64-linux-gnu/src/lib/jp2 
-I/<>/src/bin/common -I/<>/src/bin/jp2 
-I/<>/src/include -I/<>/src/lib/jp2 
-I/<>/src/lib/jp2/plugin -I/<>/src/lib/jp2/transform 
-I/<>/src/lib/jp2/t1 -I/<>/src/lib/jp2/t1/t1_part1 
-I/<>/src/lib/jp2/t1/t1_ht 
-I/<>/src/lib/jp2/t1/t1_ht/coding 
-I/<>/src/lib/jp2/t1/t1_ht/common 
-I/<>/src/lib/jp2/t1/t1_ht/others 
-I/<>/src/lib/jp2/util -I/<>/src/lib/jp2/codestream 
-I/<>/src/lib/jp2/codestream/markers 
-I/<>/src/lib/jp2/point_transform 
-I/<>/src/lib/jp2/t2 -I/<>/src/lib/jp2/tile 
-I/<>/src/lib/jp2/filters -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 
-fvisibility=hidden -mavx2 -mbmi2 -fPIC -Wall -Wextra -Wconversion 
-Wsign-conversion -Wunused-parameter -std=c++2a -o 
CMakeFiles/grokj2k.dir/util/GrkMappedFile.cpp.o -c 
/<>/src/lib/jp2/util/GrkMappedFile.cpp
...


"-mavx2 -mbmi2" is a violation of tha amd64 and i386 port baselines.

Fix:

--- debian/rules.old2021-03-01 17:09:49.253529618 +
+++ debian/rules2021-03-01 17:10:55.989543343 +
@@ -18,6 +18,7 @@
   -DBUILD_TESTING:BOOL=OFF \
   -DBUILD_DOC:BOOL=ON \
   -DBUILD_THIRDPARTY:BOOL=OFF \
+  -DAVX2_FOUND:BOOL=OFF \
   -DGRK_USE_LIBJPEG:BOOL=ON
 
 override_dh_auto_configure:

Bug#983774: radicale: events.example.org.conf has ref to wrong file

[wim]

Package: radicale
Version: 2.1.11-6
Severity: normal

Hello,

The /usr/share/doc/radicale/examples/apache2-vhost.conf
should have

radicale-uwsgi.conf

instead of

radicale.conf (nonexistent)

hth,
Wim

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

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

Versions of packages radicale depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  lsb-base 10.2019051400
ii  python3  3.7.3-1
ii  python3-radicale 2.1.11-6

Versions of packages radicale recommends:
ii  ssl-cert  1.0.39

Versions of packages radicale suggests:
ii  apache2 2.4.38-3+deb10u4
ii  apache2-utils   2.4.38-3+deb10u4
pn  libapache2-mod-proxy-uwsgi  
ii  python3-bcrypt  3.1.6-1
ii  python3-passlib 1.7.1-1
ii  uwsgi   2.0.18-1
ii  uwsgi-plugin-python32.0.18-1

-- Configuration Files:
/etc/radicale/config changed:
[server]
daemon = True
ssl = True
certificate = /etc/letsencrypt/live/bertelsw.im/fullchain.pem
key = /etc/letsencrypt/live/bertelsw.im/privkey.pem
[encoding]
[auth]
type = htpasswd
htpasswd_encryption = bcrypt
[rights]
type = authenticated
file = /etc/radicale/rights
[storage]
[web]
[logging]
config = /etc/radicale/logging
debug = True
[headers]

/etc/radicale/logging changed:
[loggers]
keys = root
[handlers]
keys = console,file
[formatters]
keys = simple
[logger_root]
level = WARNING
handlers = console,file
[handler_console]
class = StreamHandler
args = (sys.stderr,)
formatter = simple
[handler_file]
class = FileHandler
args = ('/var/log/radicale/radicale.log',)
level = INFO
formatter = simple
[formatter_simple]
format = [%(thread)x] %(levelname)s: %(message)s


-- no debconf information

Bug#983750: [Pkg-utopia-maintainers] Bug#983750: networkmanager: NM takes over slave interfaces of bond

[Michel Meyers]

On 2021-03-01 12:22, Michael Biebl wrote:

Am 01.03.21 um 11:56 schrieb Michel Meyers:
I have now created [device] sections declaring the slaves as managed=0 
in the NetworkManager.conf (left over after uninstalling NM), but 
anyone with the same config as me making the same mistake of 
inadvertently installing NM will land in the same weird situation 
where their bond0 interface is up but not getting its slaves. (I've 
also started looking at specifically declaring the slave interfaces in 
/etc/network/interfaces, but not had success with that so far as it 
stops the bond0 interface from coming up correctly. "Example 2" from 
the docs seems broken here ... more debugging to be done.)


Trying to parse and interpret /etc/network/interfaces in
NetworkManager is a losing battle I fear.

We have some support to understand basic ifupdown configurations, but
it's incomplete and buggy.

Can you share your /e/n/i?


Sure:

--
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# The first network card - this entry was created during the Debian 
installation

# (network, broadcast and gateway are optional)
#auto eth0
auto bond0
iface bond0 inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1
mtu 9000
slaves ens6 eth1
bond-mode active-backup
bond-miimon 100
bond-downdelay 200
bond-updelay 200
post-up route add 192.168.0.1 gw 192.168.1.147 && ip route add 
1.1.1.1 via 192.168.1.11 && ip route add 1.0.0.1 via 192.168.1.12
pre-down route del 192.168.0.1 gw 192.168.1.147 && ip route del 
1.1.1.1 via 192.168.1.11 && ip route del 1.0.0.1 via 192.168.1.12

iface bond0 inet6 auto
privext 2

auto bond0:0
allow-hotplug bond0:0
iface bond0:0 inet static
address 192.168.1.5
netmask 255.255.255.0
iface bond0:0 inet6 auto
privext 2
--

My guess is that the fact that there's no iface definition for the 
slaves (ens6 and eth1) caused them to be taken over by NM. (The only 
indication NM could've had to avoid them is the "slaves" stanza within 
the bond0 iface definition.)


I've since tried to re-define them like this:

--
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# The first network card - this entry was created during the Debian 
installation

# (network, broadcast and gateway are optional)
#auto eth0
auto bond0
iface bond0 inet static
address 192.168.1.200
netmask 255.255.255.0
gateway 192.168.1.1
mtu 9000
bond-slaves ens6 eth1
bond-primary ens6
bond-mode active-backup
bond-miimon 100
bond-downdelay 200
bond-updelay 200
post-up route add 192.168.0.1 gw 192.168.1.1 && ip route add 
1.1.1.1 via 192.168.1.11 && ip route add 1.0.0.1 via 192.168.1.12
pre-down route del 192.168.0.1 gw 192.168.1.1 && ip route del 
1.1.1.1 via 192.168.1.11 && ip route del 1.0.0.1 via 192.168.1.12

iface bond0 inet6 auto
privext 2

auto ens6
allow-bond ens6
iface ens6 inet manual
 bond-master bond0

auto eth1
allow-bond eth1
iface eth1 inet manual
 bond-master bond0

auto bond0:0
allow-hotplug bond0:0
iface bond0:0 inet static
address 192.168.1.5
netmask 255.255.255.0
iface bond0:0 inet6 auto
privext 2
--

But that fails with:
--
Mar  1 10:15:07 server ifup[69522]: No iface stanza found for master 
bond0
Mar  1 10:15:07 server ifup[69518]: run-parts: 
/etc/network/if-pre-up.d/ifenslave exited with return code 1

Mar  1 10:15:07 server ifup[69516]: ifup: failed to bring up ens6
--

I have yet to figure out why the ifenslave check fails. (Seems to be 
running 'ifstate -l "$IF_BOND_MASTER"': ifstate is not a command that's 
in my path and the only ifstate script that I found in 
/usr/share/doc/ifupdown/contrib/ifstate doesn't take -l as a parameter. 
Maybe some package versions are out of sync on my system.)



tl;dr: If it's easy to catch the 'slaves' stanza in /e/n/i and have NM 
consider the specified slaves as unmanaged, that would be nice, but the 
occurrence of this issue is admittedly very rare and thus may not be 
worth the effort.


- Michel

Bug#983365: linphone-desktop: chat messages

[Dennis Filder]

On Sun, Feb 28, 2021 at 11:07:31PM +0100, Bernhard Schmidt wrote:
> an updated liblinphone has been uploaded to sid yesterday. Could you
> please try liblinphone10 and liblinphone++10 from sid (4.4.21-2) and
> report back? If it does not work you might need libsoci-core4.0 and
> libsoci-sqlite3-4.0 from unstable as well (4.0.1-4).

I installed the packages and they work the same as mine.  Also I
managed to get asterisk running for chat and I do see now chat
messages are added to the DB linphone.db and the UI as they are
sent/received.  I also see at certain points signs that some form of
history is being reconstructed due to lines like

[07:20:39:145][0x56499abd2e10][Warning]qrc:/ui/modules/Linphone/Chat/Chat.qml:184:14:
 qrc:/ui/modules/Linphone/Chat/Chat.qml:184:14: QML Chat: Implicitly defined 
onFoo properties in Connections are deprecated. Use this syntax instead: 
function onFoo() { ... }

being written to stdout, one for every event, i.e. the output gets
longer for every message added to the DB.  The code apparently
reconstructs the history by just playing back the events from the DB.
However, I still don't see any history of past messages in the UI
after starting /usr/bin/linphone anew, and I don't fully understand
why.  Apparently there exist two different history concepts:

* global call log: holds call entries from all encountered contacts in
  chronological order with chat messages omitted for brevity

* peer-specific call log: the same, but only for the currently shown
  contact.

* peer-specific chat log: the chat history with the currently shown
  contact.

* peer-specific call+chat log: a combination of the two previous log

* something called a "conversation" which might be the name for the
  peer-specific call+chat log UI.

I think the chat history is read back in
linphone-desktop/linphone-app/src/components/chat/ChatModel.cpp in
ChatModel::setSipAddress() with a call to ChatRoom::getHistory(0)
which should fetch the entire history for the ChatRoom participants
(peerAddres, localAddress) and insert them into the UI:

...
 for (auto  : mChatRoom->getHistory(0))
mEntries << qMakePair(
  QVariantMap{
{ "type", EntryType::MessageEntry },
{ "timestamp", QDateTime::fromMSecsSinceEpoch(message->getTime() * 
1000) }
  },
  static_pointer_cast(message)
);

  // Get calls.
  for (auto  : core->getCallHistory(mChatRoom->getPeerAddress(), 
mChatRoom->getLocalAddress()))
insertCall(callLog);
...

Notice that call history entries are inserted with insertCall(),
whereas the code for chat history entries duplicates what
ChatModel::insertMessageAtEnd() does, but apparently without updating
the UI with endInsertRows():

...
void ChatModel::insertMessageAtEnd (const shared_ptr 
) {
  int row = mEntries.count();

  beginInsertRows(QModelIndex(), row, row);

  QVariantMap map{
{ "type", EntryType::MessageEntry },
{ "timestamp", QDateTime::fromMSecsSinceEpoch(message->getTime() * 1000) }
  };
  fillMessageEntry(map, message);
  mEntries << qMakePair(map, static_pointer_cast(message));

  endInsertRows();
}
...

I have no idea if this is intentional or what will happen if I change
that code to call insertMessageAtEnd() instead.  Commit 4ece007e[1]
also updated insertMessageAtEnd(), but the corresponding code in
setSipAddress() wasn't touched.  I will try to work on this and report
back when I know more.

Regards,
Dennis.

1: 
https://gitlab.linphone.org/BC/public/linphone-desktop/-/commit/4ece007eb322cceddb9d572c688c3c553f66ee85

Bug#983773: libgrokj2k FTBFS on armel/mipsel: undefined reference to `__atomic_fetch_add_8'

[Adrian Bunk]

Source: libgrokj2k
Version: 7.6.6-1
Severity: important
Tags: ftbfs patch

https://buildd.debian.org/status/package.php?p=libgrokj2k=sid

...
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -fvisibility=hidden 
-Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now 
CMakeFiles/grk_decompress.dir/grk_decompress.cpp.o 
CMakeFiles/grk_decompress.dir/__/common/convert.cpp.o 
CMakeFiles/grk_decompress.dir/__/image_format/ImageFormat.cpp.o 
CMakeFiles/grk_decompress.dir/__/image_format/FileStreamIO.cpp.o 
CMakeFiles/grk_decompress.dir/__/image_format/PNMFormat.cpp.o 
CMakeFiles/grk_decompress.dir/__/image_format/PGXFormat.cpp.o 
CMakeFiles/grk_decompress.dir/__/image_format/BMPFormat.cpp.o 
CMakeFiles/grk_decompress.dir/__/image_format/RAWFormat.cpp.o 
CMakeFiles/grk_decompress.dir/__/common/color.cpp.o 
CMakeFiles/grk_decompress.dir/__/common/common.cpp.o 
CMakeFiles/grk_decompress.dir/__/common/exif.cpp.o 
CMakeFiles/grk_decompress.dir/__/common/spdlog/spdlog.cpp.o 
CMakeFiles/grk_decompress.dir/__/common/spdlog/color_sinks.cpp.o 
CMakeFiles/grk_decompress.dir/__/common/spdlog/stdout_sinks.cpp.o 
CMakeFiles/grk_decompress.dir/__/common/spdlog/fmt.cpp.o 
CMakeFiles/grk_decompress.dir/__/common/spdlog/async.cpp.o 
CMakeFiles/grk_decompress.dir/__/common/spdlog/file_sinks.cpp.o 
CMakeFiles/grk_decompress.dir/__/image_format/TIFFFormat.cpp.o 
CMakeFiles/grk_decompress.dir/__/image_format/PNGFormat.cpp.o 
CMakeFiles/grk_decompress.dir/__/image_format/JPEGFormat.cpp.o 
CMakeFiles/grk_decompress.dir/__/image_format/iccjpeg.c.o -o 
../../../bin/grk_decompress  ../../../bin/libgrokj2k.so.7.6.6 
/usr/lib/arm-linux-gnueabi/libpng.so /usr/lib/arm-linux-gnueabi/libz.so 
/usr/lib/arm-linux-gnueabi/libtiff.so /usr/lib/arm-linux-gnueabi/liblcms2.so 
/usr/lib/arm-linux-gnueabi/libjpeg.so -ldl /usr/lib/arm-linux-gnueabi/libz.so 
/usr/lib/arm-linux-gnueabi/libperl.so.5.32 -lcrypt -lpthread 
/usr/lib/arm-linux-gnueabi/libtiff.so /usr/lib/arm-linux-gnueabi/liblcms2.so 
/usr/lib/arm-linux-gnueabi/libjpeg.so -ldl 
/usr/lib/arm-linux-gnueabi/libperl.so.5.32 -lcrypt 
/usr/bin/ld: ../../../bin/libgrokj2k.so.7.6.6: undefined reference to 
`__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status
make[3]: *** [src/bin/jp2/CMakeFiles/grk_decompress.dir/build.make:418: 
bin/grk_decompress] Error 1



Fix:

--- debian/rules.old2021-03-01 13:03:37.985499067 +
+++ debian/rules2021-03-01 13:04:48.726566643 +
@@ -6,6 +6,11 @@
 # as per upstream request:
 export DEB_CXXFLAGS_MAINT_APPEND = -fvisibility=hidden
 
+ifneq (,$(filter $(DEB_HOST_ARCH), armel m68k mips mipsel powerpc sh4))
+  export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic 
-Wl,--as-needed
+endif
+
+
 %:
dh $@
 

Bug#983772: linux-image-5.10.0-0.bpo.3-amd64: [rtw_8822be] WiFi suddenly stop working, only dmesg hint at a kernel bug

[ldng]

Package: src:linux
Version: 5.10.13-1~bpo10+1
Severity: normal

Dear Maintainer,

At times the driver go nuts and stop working. Started to happen with
5.10.13-1~bpo10+1 from backports.
As far as I can tell it did not with previous installed version
(5.10.12-1~bpo10+1 ? can't remember).

Unloading and reloading relevant modules (rt88 & Co) seems to
temporarly mitigate the issue.

Regards

-- Package-specific info:
** Version:
Linux version 5.10.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) (gcc-8
(Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP Debian
5.10.13-1~bpo10+1 (2021-02-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-0.bpo.3-amd64
root=UUID=ef99a64a-dc51-410f-9031-add6fa7d6271 ro cgroup_enable=memory
swapaccount=1 quiet psmouse.synaptics_intertouch=1 amd_iommu=on

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[20126.858625] RSP: 0018:ac55c0177e80 EFLAGS: 0246
[20126.858628] RAX: 9f1effdabc00 RBX: 0001 RCX:
001f
[20126.858629] RDX: 124e263ca16f RSI: 3a4a8673 RDI:

[20126.858630] RBP: 9f1bc908d800 R08: 0002 R09:
0002b480
[20126.858632] R10: 2837510f3b02 R11: 9f1effdaab84 R12:
124e263ca16f
[20126.858634] R13: 903b8ec0 R14: 0001 R15:

[20126.858641]  cpuidle_enter+0x29/0x40
[20126.858647]  do_idle+0x25c/0x2b0
[20126.858651]  cpu_startup_entry+0x19/0x20
[20126.858655]  start_secondary+0x113/0x150
[20126.858661]  secondary_startup_64_no_verify+0xb0/0xbb
[20126.858665] ---[ end trace 46f3fbf7314f58b6 ]---
[20157.221945] rtw_8822be :02:00.0: firmware failed to restore hardware
setting
[20178.561707] rtw_8822be :02:00.0: firmware failed to restore hardware
setting
[20194.617521] rtw_8822be :02:00.0: firmware failed to restore hardware
setting
[20202.585461] rtw_8822be :02:00.0: firmware failed to restore hardware
setting
[20208.601386] rtw_8822be :02:00.0: firmware failed to restore hardware
setting
[20292.640454] rtw_8822be :02:00.0: firmware failed to restore hardware
setting
[20372.635529] rtw_8822be :02:00.0: firmware failed to restore hardware
setting
[20436.721758] wlp2s0: deauthenticating from 08:3e:5d:f8:3f:37 by local choice
(Reason: 3=DEAUTH_LEAVING)
[20436.751525] rtw_8822be :02:00.0: sta 08:3e:5d:f8:3f:37 with macid 0 left
[20436.754473] rtw_8822be :02:00.0: stop vif 28:3a:4d:74:d2:83 on port 0
[20437.270747] rtw_8822be :02:00.0: start vif 96:66:ad:54:24:b0 on port 0
[20437.285706] rtw_8822be :02:00.0: stop vif 96:66:ad:54:24:b0 on port 0
[20437.798903] rtw_8822be :02:00.0: start vif 28:3a:4d:74:d2:83 on port 0
[20438.678938] Generic FE-GE Realtek PHY r8169-400:00: attached PHY driver
[Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-400:00, irq=IGNORE)
[20438.818845] r8169 :04:00.0 enp4s0f0: Link is Down
[20443.208363] wlp2s0: authenticate with 08:3e:5d:f8:3f:37
[20443.806752] wlp2s0: send auth to 08:3e:5d:f8:3f:37 (try 1/3)
[20443.807545] wlp2s0: authenticated
[20443.810792] wlp2s0: associate with 08:3e:5d:f8:3f:37 (try 1/3)
[20443.812202] wlp2s0: RX AssocResp from 08:3e:5d:f8:3f:37 (capab=0x1011
status=0 aid=1)
[20443.812241] rtw_8822be :02:00.0: sta 08:3e:5d:f8:3f:37 joined with macid
0
[20443.812678] wlp2s0: associated
[20443.837048] wlp2s0: Limiting TX power to 23 (23 - 0) dBm as advertised by
08:3e:5d:f8:3f:37
[20443.846165] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
[20489.624774] wlp2s0: deauthenticating from 08:3e:5d:f8:3f:37 by local choice
(Reason: 3=DEAUTH_LEAVING)
[20489.678346] rtw_8822be :02:00.0: sta 08:3e:5d:f8:3f:37 with macid 0 left
[20489.679302] rtw_8822be :02:00.0: stop vif 28:3a:4d:74:d2:83 on port 0
[20490.190174] rtw_8822be :02:00.0: start vif 8a:3d:83:af:c4:7f on port 0
[20494.544410] rtw_8822be :02:00.0: stop vif 8a:3d:83:af:c4:7f on port 0
[20495.050224] rtw_8822be :02:00.0: start vif 28:3a:4d:74:d2:83 on port 0
[20499.313707] wlp2s0: authenticate with 08:3e:5d:f8:3f:37
[20499.918119] wlp2s0: send auth to 08:3e:5d:f8:3f:37 (try 1/3)
[20499.918749] wlp2s0: authenticated
[20499.926108] wlp2s0: associate with 08:3e:5d:f8:3f:37 (try 1/3)
[20499.927071] wlp2s0: RX AssocResp from 08:3e:5d:f8:3f:37 (capab=0x1011
status=0 aid=1)
[20499.927106] rtw_8822be :02:00.0: sta 08:3e:5d:f8:3f:37 joined with macid
0
[20499.927515] wlp2s0: associated
[20499.952012] wlp2s0: Limiting TX power to 23 (23 - 0) dBm as advertised by
08:3e:5d:f8:3f:37
[20499.960754] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
[20545.638329] wlp2s0: deauthenticating from 08:3e:5d:f8:3f:37 by local choice
(Reason: 3=DEAUTH_LEAVING)
[20545.665703] rtw_8822be :02:00.0: sta 08:3e:5d:f8:3f:37 with macid 0 left
[20545.666721] rtw_8822be :02:00.0: stop vif 28:3a:4d:74:d2:83 on port 0
[20546.177715] rtw_8822be :02:00.0: start vif da:54:01:8a:0b:17 on port 0
[20550.225595] r8169 :04:00.0 enp4s0f0: Link is Down

Bug#983563: [debian-mysql] Bug#983563: mariadb-server: trigger fails when systemd is not running (eg. chroot)

[Arnaud R]

On 3/1/21 6:49 PM, Faustin Lammler wrote:

Hi Arnaud!

Arnaud Rebillout ,
26/02/2021 – 16:39:41 (+0700):


Hence I believe that the line:

   if [ -x "$(command -v systemctl)" ]; then

Should be replaced by:

   if [ -d /run/systemd/system ]; then

I am not sure that this is what we want here. Indeed, doing this would
lead to the execution of `invoke-rc.d mariadb restart` in your
particular case (but you are using systemd not sysv init). Or I am
missing something?



Oh, indeed, you're completely right, I don't want to run the line 
`invoke-rc.d ...`. In my case, and since systemd is not running, I think 
that the maintscript should not try to restart mariadb at all.


I *think* the code should be something like that:

    if [ -d /run/systemd/system ]; then
  systemctl daemon-reload
    elif [ -x "/etc/init.d/mariadb" ]; then
  invoke-rc.d mariadb restart
    fi

(note that it's exactly what is done at the end of this file, after the 
`#DEBHELPER#` line).




Could point me to the steps in your CI where this happen so I can try to
reproduce it?



This particular CI is unfortunately not public, however I can give you a 
procedure to reproduce the issue with Debian. The trick is to get the 
right package versions so that an update of mysql-common triggers 
mariadb-server (that's what happened in the Kali CI).


And so, here it goes:

    ## debootstrap an old version of sid
    sudo debootstrap sid debdir \
    http://snapshot.debian.org/archive/debian/20201205T204928Z
    sudo systemd-nspawn -D debdir

    ## install mariadb
    apt-get -o Acquire::Check-Valid-Until=false update
    apt-get install mariadb-server-10.5

    [...]
    mariadb-server-10.5 amd64 1:10.5.8-3
    mysql-common all 5.8+1.0.6
    [...]

    ## upgrade to debian testing
    echo 'deb http://deb.debian.org/debian testing main' > 
/etc/apt/sources.list

    apt-get update
    apt-get dist-upgrade

    [...]
    mysql-common all 5.8+1.0.7
    [...]
    Processing triggers for mariadb-server-10.5 (1:10.5.8-3) ...
    System has not been booted with systemd as init system (PID 1). 
Can't operate.

    Failed to connect to bus: Host is down
    dpkg: error processing package mariadb-server-10.5 (--configure):
 installed mariadb-server-10.5 package post-installation script 
subprocess returned error exit status 1

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

Cheers,

  Arnaud

Bug#983771: procps: /bin/ps -A -o lxc,.. f with lxc as column on debian testing shows no lxc name, only '-'

[Andreas Laut]

Package: procps
Version: 2:3.3.17-4
Severity: normal

Dear Maintainer,

at Debian 10 I used to run this command:
ps -A -o lxc,pid,time,args f --sort=lxc
which are working very well to see what processes running in which lxc.

At Debian Testing and also Sid the command above reports only '-' - for lxc 
processes and host processes.
If I run this
ps -A -o cgroup,pid,time,args f
it shows me the cgroups which are include also the lxc names but for my 
purposes its a bit ugly.

I didn't do any further debugging till now.

It would be nice if this problem could be fixed. I will workaround this using 
cgroup column name but lxc as column should also working (in my opinion and the 
manpage is the same meaning).

Kind regards,
Andreas

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

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

Versions of packages procps depends on:
ii  init-system-helpers  1.60
ii  libc62.31-9
ii  libncurses6  6.2+20201114-2
ii  libncursesw6 6.2+20201114-2
ii  libprocps8   2:3.3.16-5
ii  libtinfo66.2+20201114-2
ii  lsb-base 11.1.0

Versions of packages procps recommends:
pn  psmisc  

procps suggests no packages.

-- no debconf information

Bug#976340: jellyfish: Fails to build on some architectures

[Andreas Tille]

Hi,

(debian-perl in CC since this might be connected to some Makefile.PL
which is not interpreted correctly.)

On Mon, Mar 01, 2021 at 12:27:45AM +0200, Adrian Bunk wrote:
> Control: reopen -1
> Control: tags -1 ftbfs
> Control: retitle -1 jellyfish FTBFS with -I in builddir
> 
> On Thu, Dec 03, 2020 at 05:06:00PM +0100, Andreas Tille wrote:
> > mips64el-linux-gnuabi64-gcc -pthread -Wno-unused-result -Wsign-compare 
> > -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> > -Werror=format-security -g -O2 -fdebug-prefix-map=/<>=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> > -D_FORTIFY_SOURCE=2 -fPIC 
> > -I/build/jellyfishwEbe4/jellyfish-2.3.0/debian/tmp//usr/include/jellyfish-2.3.0
> >  -I/usr/include/python3.9 -c swig_wrap.cpp -o 
> > build/temp.linux-mips64el-3.9/swig_wrap.o -std=c++0x
> > swig_wrap.cpp:2826:10: fatal error: jellyfish/mer_dna.hpp: No such file or 
> > directory
> >  2826 | #include 
> >   |  ^~~
> > compilation terminated.
> > error: command '/usr/bin/mips64el-linux-gnuabi64-gcc' failed with exit code 
> > 1
> > 
> > 
> > Any idea what might be wrong here?
> 
> I: NOTICE: Log filtering will replace 
> 'build/jellyfish-IwEbe4/jellyfish-2.3.0' with '<>'
> I: NOTICE: Log filtering will replace 'build/jellyfish-IwEbe4' with 
> '<>'
> 
> Compare with 
> -I/build/jellyfishwEbe4/jellyfish-2.3.0/debian/tmp//usr/include/jellyfish-2.3.0
> 
> jellyfish-IwEbe4 -> jellyfishwEbe4
> 
> This looks like a variant of the -L problem handled with
> debian/patches/fix_replacement_of_-L_option.patch

So your suspicion is that the issue is created in cases where the build
dir by chance contains a '-I' string, right?  I tried to verify this by
creating a build dir /tmp/jellyfish-I-L-test and simply called `debuild`
there (since I did not found any comparable sed invocation like in the
-L case).  Astonishingly the resulting error was different than expected:

...
Running Mkbootstrap for jellyfish ()
chmod 644 "jellyfish.bs"
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- jellyfish.bs 
blib/arch/auto/jellyfish/jellyfish.bs 644
rm -f blib/arch/auto/jellyfish/jellyfish.so
x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/tmp/jellyfish-I-L-test=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,-z,now -lpthread  -shared -L/usr/local/lib -fstack-protector-strong  
swig_wrap.o  -o blib/arch/auto/jellyfish/jellyfish.so  \
   -ljellyfish-2.0 -lpthread   \
  
/usr/bin/ld: cannot find -ljellyfish-2.0
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:480: blib/arch/auto/jellyfish/jellyfish.so] Fehler 1
make[2]: Verzeichnis „/tmp/jellyfish-I-L-test/swig/perl5“ wird verlassen
...

(sorry for the German locale).  The relevant part in the Makefile that
was createt out of swig/perl5/Makefile.PL[1] seems to be:

...
# As Mkbootstrap might not write a file (if none is required)
# we use touch to prevent make continually trying to remake it.
# The DynaLoader only reads a non-empty file.
$(BASEEXT).bs : $(FIRST_MAKEFILE) $(BOOTDEP)
$(NOECHO) $(ECHO) "Running Mkbootstrap for $(BASEEXT) ($(BSLOADLIBS))"
$(NOECHO) $(PERLRUN) \
"-MExtUtils::Mkbootstrap" \
-e "Mkbootstrap('$(BASEEXT)','$(BSLOADLIBS)');"
$(NOECHO) $(TOUCH) "$(BASEEXT).bs"
$(CHMOD) $(PERM_RW) "$(BASEEXT).bs"
...


I admit I have no idea how to debug this or how to force the proper -L
option into this command line.  Any help is really appreciated.

Kind regards

 Andreas.


[1] 
https://salsa.debian.org/med-team/jellyfish/-/blob/master/swig/perl5/Makefile.PL

-- 
http://fam-tille.de

Bug#959407: dh-python: pybuild without setup.py

[Nicholas D Steeves]

Control: retitle -1 RFP: dephell -- project management for Python
Control: noowner -1

Unsetting myself as owner and converting the bug to an RFP, because I've
reevaluated my anticipated dedication to maintaining this package, and I
have too many "aspirational projects" ;-)

Bug#983751: Info received ([Pkg-utopia-maintainers] Bug#983751: dosfstools-4.2 breaks vfat formatting of entire device)

[Allison Karlitskaya]

https://github.com/storaged-project/udisks/issues/851

On Mon, Mar 1, 2021 at 4:51 PM Debian Bug Tracking System
 wrote:
>
> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Utopia Maintenance Team 
>
> If you wish to submit further information on this problem, please
> send it to 983...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 983751: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983751
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#982736: Accepted jinja2 2.11.3-1 (source) into unstable

[Salvatore Bonaccorso]

Source: jinja2
Source-Version: 2.11.3-1

On Mon, Mar 01, 2021 at 11:48:35AM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Mon, 01 Mar 2021 12:05:52 +0100
> Source: jinja2
> Architecture: source
> Version: 2.11.3-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Piotr Ożarowski 
> Changed-By: Hans-Christoph Steiner 
> Changes:
>  jinja2 (2.11.3-1) unstable; urgency=medium
>  .
>* Team upload.
>  .
>[ Ondřej Nový ]
>* d/control: Update Vcs-* fields with new Debian Python Team Salsa
>  layout.
>  .
>[ Debian Janitor ]
>* Apply multi-arch hints.
>  + python-jinja2-doc: Add Multi-Arch: foreign.
>  .
>[ Sandro Tosi ]
>* Use the new Debian Python Team contact name and address
>  .
>[ Hans-Christoph Steiner ]
>* New upstream release

The new upstream releases fixed CVE-2020-28493 (#982736) so closing
the bug.

Regards,
Salvatore

Bug#983751: [Pkg-utopia-maintainers] Bug#983751: dosfstools-4.2 breaks vfat formatting of entire device

[Allison Karlitskaya]

hi Michael,

Thanks for the quick reply.  I filed the bug here only because udisks
in Debian is the thing that I observe to fail.  I don't know where the
cause is.

I'll happily forward the issue upstream, as suggested.  For what it's
worth, dosfsutils *is* successfully creating the filesystem in
question, when called manually.

On Mon, Mar 1, 2021 at 10:40 AM Michael Biebl  wrote:
>
> Hi Allison,
>
> thanks for your bug report.
> I assume you do not consider this a regression in dosfstools, otherwise
> you'd probably have filed it against the dosfstools package.
> The Debian udisks2 package is not shipping any downstream patches in
> that regard, so it would be best if you can raise this
> dosfstools 4.2 incompatibility at
> https://github.com/storaged-project/udisks
>
> It's most likely that Debian won't be the only distro affected by this.
>
> Seeing that dosfstools 4.2 has already migrated to testing, it doesn't
> really help to file an RC bug against it to prevent testing migration.
>
> Regards,
> Michael
>
>
> Am 01.03.2021 um 10:10 schrieb Allison Karlitskaya:
> > Package: udisks2
> > Version: 2.9.1-3
> >
> > A new version of dosfstools (4.2) just landed on testing, and we're
> > suddenly seeing a new failure in cockpit's integration testing:
> > specifically, attempting to create a fat filesystem on /dev/sda (the
> > direct device, not a partition) fails.  This works correctly with
> > dosfstools 4.1.
> >
> > See https://github.com/cockpit-project/bots/pull/1701
> >
> > This problem is not limited to cockpit, however. You can see the
> > problem rather directly with this reproducer:
> >
> > root@debian:~# dpkg -i dosfstools_4.1-2_amd64.deb
> > dpkg: warning: downgrading dosfstools from 4.2-1 to 4.1-2
> > (Reading database ... 70287 files and directories currently installed.)
> > Preparing to unpack dosfstools_4.1-2_amd64.deb ...
> > Unpacking dosfstools (4.1-2) over (4.2-1) ...
> > Setting up dosfstools (4.1-2) ...
> > Processing triggers for man-db (2.9.4-1) ...
> > root@debian:~# gdbus call --system --dest org.freedesktop.UDisks2
> > --object-path /org/freedesktop/UDisks2/block_devices/sda --method
> > org.freedesktop.UDisks2.Block.Format vfat '{}'
> > ()
> >
> >
> > but then:
> >
> > root@debian:~# dpkg -i dosfstools_4.2-1_amd64.deb
> > (Reading database ... 70285 files and directories currently installed.)
> > Preparing to unpack dosfstools_4.2-1_amd64.deb ...
> > Unpacking dosfstools (4.2-1) over (4.1-2) ...
> > Setting up dosfstools (4.2-1) ...
> > Processing triggers for man-db (2.9.4-1) ...
> > root@debian:~# gdbus call --system --dest org.freedesktop.UDisks2
> > --object-path /org/freedesktop/UDisks2/block_devices/sda --method
> > org.freedesktop.UDisks2.Block.Format vfat '{}'
> > Error: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error
> > synchronizing after formatting with type `vfat': Timed out waiting for
> > object
> >
> >
> > note that attempting to format a partition works fine, even with the
> > new version:
> > root@debian:~# fdisk /dev/sda
> > [... create primary partition /dev/sda1 ... ]
> > Command (m for help): w
> > The partition table has been altered.
> > Calling ioctl() to re-read partition table.
> > Syncing disks.
> >
> > root@debian:~# gdbus call --system --dest org.freedesktop.UDisks2
> > --object-path /org/freedesktop/UDisks2/block_devices/sda1 --method
> > org.freedesktop.UDisks2.Block.Format vfat '{}'
> > ()
>
>
>

Bug#982586: otrs2: CVE-2021-21435

[Salvatore Bonaccorso]

On Mon, Mar 01, 2021 at 11:46:17AM +0100, Patrick Matthäi wrote:
> Hi
> 
> Am 12.02.21 um 08:26 schrieb Salvatore Bonaccorso:
> > Source: otrs2
> > Version: 6.0.30-2
> > Severity: important
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > Hi,
> > 
> > The following vulnerability was published for otrs2.
> > 
> > CVE-2021-21435[0]:
> > | Article Bcc fields and agent personal information are shown when
> > | customer prints the ticket (PDF) via external interface. This issue
> > | affects: OTRS AG OTRS 7.0.x version 7.0.23 and prior versions; 8.0.x
> > | version 8.0.10 and prior versions.
> > 
> > According to [1] it affects as well the 6.0.x versions but there is no
> > mention of a fix in the 6.0.x series yet.
> > 
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2021-21435
> >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21435
> > [1] https://otrs.com/release-notes/otrs-security-advisory-2021-02/
> > 
> > Please adjust the affected versions in the BTS as needed.
> > 
> > Regards,
> > Salvatore
> As described before before this issue does not affect the OTRS 6 community
> edition, since it relies on an external interface, which is only part of the
> business edition and otrs 7/8.

Okay thanks. What is confusing though is that they describe it on
theyr advisory page as explicitly affecting OTRS 6.x:

> This issue affects ((OTRS)) Community Edition 6.0.x.

But then we trust you that this is not the case.

Regards,
Salvatore

Bug#962459: unbound: constantly crashing after about 3 minutes since start

[Volker Schwicking]

Hi,

We saw this issue appearing on our unbound (1.9.0-2+deb10u2) nodes since Feb 
28th 8am CET as well.

Updating to the packages from

https://people.debian.org/~edmonds/unbound/1.9.6-0+deb10u0/

solved the issue for us.

Is there a specific query or command to reproduce this on the older version?

Im just wondering, why we started seeing this only since yesterday. We do take 
a bit of traffic on our unbound nodes and should have noticed this earlier.

Best regards
- Volker

Bug#941624: Recommending ibus breaks fcitx

[Shengjing Zhu]

Control: severity -1 serious
Control: affects -1 src:tasksel

On Thu, Oct 03, 2019 at 05:49:37AM -0400, Jeremy Bicha wrote:
> On Wed, Oct 2, 2019 at 9:51 PM Mo Zhou  wrote:
> > I've been using fcitx as the default Chinese input method for decades.
> > Recommending ibus simply breaks everything for me.
> 
> GNOME Shell uses Wayland by default. It is my understanding that ibus
> works in GNOME's Wayland session but fcitx does not.
> 
> Have you tried using im-config to choose fcitx over ibus? If that does
> not work, maybe you should file an im-config bug instead?
> 

Sorry I just find this bug when I read another bug[1] which is recently reported
to the debian-input-method team.

It has been working well previously that the choice of input method is decided
by src:tasksel package. Please see all the all the task-*-desktop packages:

+ fcitx is recommended by task-telugu-desktop, task-malayalam-desktop,
  task-kannada-desktop, task-chinese-t-desktop, task-chinese-s-desktop,
  task-amharic-desktop.

+ uim is recommended by task-japanese-desktop.
+ ibus is recommended by task-tamil-gnome-desktop, task-korean-desktop

Now GNOME just takes over the responsibility. Please don't, it't just broken
without coordination of src:tasksel maintainer.

+ Users are now possible to install two input engines. It troubles than 
benefits.
+ And the tasksel won't install corresponding language library for ibus.
+ And for the im-config, it's not possible to decide which engine is preferred
  by the tasksel data. Yes you can say that users change it by hand, but it's 
not
  what we want to achieve. We want a working desktop for different users by 
default.

If GNOME maintainer want to change the default input method, it's better to
do it in tasksel package.

Please downgrade ibus to Suggests for bullseye.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983695


signature.asc
Description: PGP signature

Bug#983750: [Pkg-utopia-maintainers] Bug#983750: networkmanager: NM takes over slave interfaces of bond

[Michel Meyers]

On 2021-03-01 11:27, Michael Biebl wrote:

Am 01.03.21 um 10:41 schrieb Andrei POPESCU:

Control: reassign -1 network-manager

On Lu, 01 mar 21, 10:00:26, Michel Meyers wrote:

Package: networkmanager
Severity: normal

Dear Maintainer,

I had a bond configured as described in Example 1 on: 
https://wiki.debian.org/Bonding


This morning, my server's bond interface showed down, and its slaves
kept getting removed. After some digging, I found that networkmanager
had gotten installed and a check in nmcli showed that it had taken 
over each of the slave interfaces

while listing bond0 as unmanaged.

It appears that NM ignores the "slaves eth0 eth1" directive in
/etc/network/interfaces so unless each of the interfaces is 
specifically

named as in Example 2, NM takes over the slaves, killing the bond.


If you want to prevent NM to "auto" manage your devices, you could use
/usr/share/doc/network-manager/examples/server.conf (copy it to
/etc/NetworkManager/conf.d/)


Alternative, you can tell NM explicitly which devices it should ignore.
See man NetworkManager.conf → unmanaged-devices


I don't normally use NM and don't have it installed. It must've gotten 
pulled in as a dependency of some package (my fault for not catching it 
really) and the nightly systemd restart of services then somehow caused 
it to take over.


I have now created [device] sections declaring the slaves as managed=0 
in the NetworkManager.conf (left over after uninstalling NM), but anyone 
with the same config as me making the same mistake of inadvertently 
installing NM will land in the same weird situation where their bond0 
interface is up but not getting its slaves. (I've also started looking 
at specifically declaring the slave interfaces in 
/etc/network/interfaces, but not had success with that so far as it 
stops the bond0 interface from coming up correctly. "Example 2" from the 
docs seems broken here ... more debugging to be done.)


- Michel

Bug#932456: Possible Patch

[Fabian Zaremba]

> Could you provide a binary package for Buster containing this patch? I
> would like to test this.

I published a package with this patch to the public Open Build Service
instance hosted by openSUSE.

https://build.opensuse.org/package/show/home:fabian-z:libvirt-kt/libvirt

https://download.opensuse.org/repositories/home:/fabian-z:/libvirt-kt/Debian_10/

The patched version is 5.0.0-4+deb10u1kt1.

If you want to install from a repository, execute the following commands
as root on Debian Buster. Please note the test binaries and the
repository are provided "as is" only for test purposes without any
warranty or maintenance:

curl -L
https://build.opensuse.org/projects/home:fabian-z:libvirt-kt/public_key
| apt-key add -

echo "deb
http://download.opensuse.org/repositories/home:/fabian-z:/libvirt-kt/Debian_10
./" >> /etc/apt/sources.list.d/libvirt.list

apt-get update && apt-get install qemu-system libvirt-clients
libvirt-daemon-system

Bug#983750: [Pkg-utopia-maintainers] Bug#983750: networkmanager: NM takes over slave interfaces of bond

[Michael Biebl]

Am 01.03.21 um 13:59 schrieb Michel Meyers:


# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
auto lo
iface lo inet loopback

# The first network card - this entry was created during the Debian 
installation

# (network, broadcast and gateway are optional)
#auto eth0
auto bond0
iface bond0 inet static
     address 192.168.1.2
     netmask 255.255.255.0
     gateway 192.168.1.1
     mtu 9000
     slaves ens6 eth1




Reading https://www.commandlinux.com/man-page/man5/interfaces.5.html , 
it appears "slave" is no native ifupdown config stanza.

I suppose it is implemented by a third party package?
Which brings me back to my concern, that this is really a losing battle, 
since the interfaces file format is not specified in a way, which would 
make it easy to gather all managed interfaces.


We already special case "bridge-ports" [1], and maybe we could extend 
that to also consider "slaves". But I really don't like that we don't 
have a proper API here.
Maybe you could convince the ifupdown maintainer to provide such an API, 
e.g. via "ifquery", where we could query all interfaces that are managed 
by ifupdown.


Regards,
Michael



[1] 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/master/src/core/settings/plugins/ifupdown/nms-ifupdown-plugin.c#L255




OpenPGP_signature
Description: OpenPGP digital signature

Bug#983653: task-japanese-gnome-desktop: no Japanese input method available out of the box

[Holger Wansing]

Hi,

Nobuhiro Iwamatsu  wrote (Mon, 1 Mar 2021 06:00:51 +0900):
> 2021年2月28日(日) 13:12 YOSHINO Yoshihito :
> >
> > Adding some Japanese input method to the ibus framework should work
> > around the problem
> > for Japanese users. Specifically, adding Recommends: ibus-mozc (or 
> > ibus-anthy on
> > architectures where mozc is not available) to this package should work
> > around the problem.
> > The attached patch should apply the work-around.
> 
> This patch seems to work for this issue.
> I have confirmed that ibus-mozc is installed in the GNOME environment by
> installing the tasksel/task-japanese-gnome-desktop packages with this patch
> applied.

May I ask how that interacts with the uim framework?

We currently have

Recommends:
[...]
uim,
uim-mozc | uim-anthy,

in task-japanese-desktop, so if you now add ibus-mozc | ibus-anthy to
task-japanese-gnome-desktop, we will have both, uim-mozc and ibus-mozc installed
on a Gnome system.
Is that ok? Or does that cause any harm/conflict/what ever?

Or did I got something wrong?


Holger


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

Bug#983754: uses threading.Thread.isAlive(), removed in python3.9

[Jeroen Ploemen]

Package: src:cherrypy3
Version: 8.9.1-7
Severity: important
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.9

Came across this while working on sabnzbdplus. To reproduce, start
sabnzbdplus on the cli in testing|unstable, then shut it down ctrl-c:

2021-03-01 09:59:05,259::ERROR::[_cplogging:219] [01/Mar/2021:09:59:05] ENGINE 
Error in 'stop' listener >
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cherrypy/process/wspbus.py", line 216, 
in publish
output.append(listener(*args, **kwargs))
  File "/usr/lib/python3/dist-packages/cherrypy/process/servers.py", line 264, 
in stop
self.httpserver.stop()
  File "/usr/lib/python3/dist-packages/cherrypy/wsgiserver/__init__.py", line 
2221, in stop
self.requests.stop(self.shutdown_timeout)
  File "/usr/lib/python3/dist-packages/cherrypy/wsgiserver/__init__.py", line 
1702, in stop
if worker is not current and worker.isAlive():
AttributeError: 'WorkerThread' object has no attribute 'isAlive'

According to https://bugs.python.org/issue37804 this method was
deprecated in 3.8 and removed in 3.9 in favour of is_alive().


pgp3rKsdRhW6K.pgp
Description: OpenPGP digital signature

Bug#983748: dh-r: pkg-r-autopkgtest breaks autopkgtests

[Graham Inggs]

Control: reopen -1

Hi Andreas

This didn't work [1].  You need root in order to run 'apt-get install':

E: No packages found
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13:
Permission denied)
E: Unable to acquire the dpkg frontend lock
(/var/lib/dpkg/lock-frontend), are you root?
autopkgtest [14:31:55]: test pkg-r-autopkgtest: ---]
autopkgtest [14:31:55]: test pkg-r-autopkgtest:  - - - - - - - - - -
results - - - - - - - - - -
pkg-r-autopkgtestFAIL non-zero exit status 100

Please revert the entire commit [2] and upload so we can fast track
dh-r back into testing to fix pkg-r-autopkgtests there.  Maybe speak
to debci team about whatever problem it is you are trying to solve,
and whether it is needed at this stage of the freeze.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-bioc-affy/unstable/amd64/
[2] 
https://salsa.debian.org/r-pkg-team/dh-r/-/commit/62a4128c07a17de845e9d7260504fae187c3d193

Bug#980906: closing as invalid, not reproducible, no feedback

[Matthias Klose]

Control: severity -1 normal

closing as invalid, not reproducible, no feedback

Bug#983770: rnp: FTBFS on 32-bit platforms (test suite failures)

[Daniel Kahn Gillmor]

Package: rnp
Version: 0.14.0-5
Severity: critical
Control: forwarded -1 https://github.com/rnpgp/rnp/issues/1436

RNP's test suites are failing on all of the 32-bit platforms in debian.
I've reported this upstream so that hopefully it can be resolved.

It should not migrate into testing in this current state.

   --dkg


signature.asc
Description: PGP signature

Bug#983756: can qemu-system-common be Multi-Arch: foreign again?

[Michael Tokarev]

01.03.2021 14:47, Helmut Grohne wrote:

Package: qemu-system-common
Version: 1:5.2+dfsg-6
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:libvirt

libvirt cannot be cross built from source, because its Build-Depends:
qemu-system-common now results in a conflict. The direct dependency asks
for the host architecture qemu-system-common and a Multi-Arch: foreign
qemu frontend also depends on qemu-system-common, which becomes a build
architecture dependency.


After some discussion on irc and clarifications about what's going on
in the first place, I see a few points here.

First, this is not about multi-arch really, but about our fake dependency
of qemu-system-common on one of qemu-system-FOO architectures. We never
thought that qemu-system-common can be used/installed by its own without
qemu itself.  We added this fake dependency (fake because qemu-system-common
does not actually depend on these other qemu-system-foo packages) in order
to ensure that qemu modules which were in -common for a few releases, are
of the right version - the same as the corresponding qemu-system-foo. The
thought was like, the modules can't be used by their own so at least one
qemu binary which can use these modules should be installed.

So for now, if we drop this dependency of qemu-system-common on qemu-system-foo,
this issue should go away.

Next, the question is why qemu-system-common is needed to BUILD libvirt.
This is because libvirt's build system finds the path of qemu-bridge-helper
(and uses default path which is not the one used on debian). Which immediately
leads to the next question: why libvirt uses qemu-bridge-helper in the first
place.

The thing is that on debian we still don't add set-uid bit to 
qemu-bridge-helper,
so this place in libvirt will never actually work. libvirt can manage network
by its own, or, if run unprivileged (is it ever possible?), it will try to
use qemu-bridge-helper, and that will fail too by default (unless the user
explicitly enabled set-uid bit for qemu-bridge-helper.

I looked at where qemu-bridge-helper is located on debian. It is 
/usr/lib/qemu/, -
which is not commonly used path, the default is /usr/libexec/. Now there's 3rd
question: what if we'll try to move this executable to the place where it is
installed to by default? How we can change libvirt? Adding versioning breaks/
requires seems to be the only way.

I think we should move qemu-bridge-helper to the default place, maybe even now
before bullseye, and drop qemu-system-common from libvirt's build-depends. At
the same time drop the fake versioned deps of qemu-system-common. And decide
when/how we should use the bridge-helper in the first place.

What do you think?

Thanks,

/mjt

Bug#983271: devscripts: [INTL:pt] Portuguese translation of MANPAGE

[Mattia Rizzolo]

Control: tag -1 moreinfo

On Thu, Feb 25, 2021 at 08:29:08PM +, Américo Monteiro wrote:
> > This is not just an update, but a whole new transation, so I'll have to
> > go read that makefile concerning l10n that I never touched.  oh well.
> I supose you just have to rename my file to 
> pt.po 
> and put it in some "po4a" directory in the source tree 
> it should allready be there at least an de.po (german translation) and a 
> fr.po 
> (french)

It's not just that, since the rest of the build system wasn't really
thought to handle more langs.
https://salsa.debian.org/debian/devscripts/-/commit/9125f92e3ab2e3161f3ebe3d775b12ab6649699f

But your translation seem to have several syntax issues:

../scripts/debchange.1:68: (po4a::man)
   Unknown '<' or '>' sequence. […]

after fixing that one another popped up, and there I stopped, so please
fix them.

I recommend you at least try to run po4a before submitting this, since
that's what caught this issue.

> > > There is also an addendum to add, hope it's allright.
> > 
> > It's my first time seeing this.  I see the ohter transations also have
> > some addendum, but none is in latex.  Can you give me a pointer to what
> > is that thing and how it's supposed to work?
> > FWIW, devscripts doesn't build any latext documents.
> 
> I'm not sure how it works... it's suppose to be a extra message that appear 
> when someone read the manpage in Portuguese...
> I've copied the format from other manpages

Right, but the probably lies in the syntax you are using.  We don't have
documentation in LaTeX, if you want to add such a message you'd have to
provide it in POD format, Groff and XSLT, not LaTeX.  (or just one of
them, then it'll appear only in the manpages built from that source).

See add_fr/ for one lanauge providing all of them, and add_de/ for one
providing only one for Groff.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

[Shengjing Zhu]

On Mon, Mar 1, 2021 at 1:15 PM YOSHINO Yoshihito  wrote:
>
> Hi,
>
> On Mon, Mar 1, 2021 at 3:32 AM Gunnar Hjalmarsson  wrote:
> >
> > On 2021-02-28 16:05, YOSHINO Yoshihito wrote:
> > > On the GNOME desktop, manual set-up in GNOME Settings is required
> > > in order to make ibus-anthy to work.
> >
> > Right. But does that differ in any way from other IBus input methods?
>
> Yesterday I filed Bug#983623 to ibus-mozc for a similar change and it
> has been uploaded to unstable.
>
> gnome-shell now Recommends: ibus, which breaks a fresh bullseye installation 
> of
> Japanese (and probably Chinese) default desktop (that is, GNOME desktop.)
> In order to work around this issue, in Bug#983653 I have proposed a patch
> to add "Recommends: ibus-mozc | ibus-anthy" to task-japanese-gnome-desktop.
>
> Buster Japanese GNOME desktop uses uim, which has worked out of the box.
> By adding auto set-up to at least those two ibus-* packages
> bullseye Japanese GNOME desktop on any architecture should work out of
> the box again.
>

I'm not a GNOME user. But reading this, I feel it's seriously broken.
GNOME shouldn't take over the responsibility of tasksel to decide what
the IM engine to use.
Japanese GNOME desktop users should continue to use uim if it's
prefered by Japanese users.
And Chinese GNOME desktop users should continue to use fcitx as their
default IM engine.

-- 
Shengjing Zhu

Bug#982892: ITP: binutils-or1k-elf -- GNU binary utilities for the Open RISC 1000 processors

[Nicolas Boulenguez]

Matthias, you may want to comment on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982892
(You did not receive first invitation because of a typo in your address)

> Some binutils bug is discovered. Once understood, Matthias is
> usually quick at uploading a fixed binutils.

If I understand well Matthias' point of view, this reactivity is
possible exactly because he can fix major architectures without
dealing with consequences on less important architectures.

If src:binutils were to build binutils-bpf or if binutils-bpf were to
Build-Depend on an exact DEB_VERSION of binutils-source, an
incompatibility between the fix and bpf would prevent migration of the
fixed src:binutils to testing.

Would these ideas mitigate the issues you are describing?
* debian/watch may automatically report packages outdated by a new
  binutils-source.deb, for example in the package tracking system.
* debian/README.source may allow no-change NMUs rebuilding against
  binutils-source (and ask for a RC bug report if the rebuild happens
  to fail).

Bug#983346: Update gitlab to 13.7.7 (installation fails - need help)

[Pirate Praveen]

On Sun, Feb 28, 2021 at 11:00 pm, Pirate Praveen 
 wrote:
On Sun, 28 Feb 2021 19:04:24 +0530 Pirate Praveen 
 wrote:

> Asking upstream for help
> https://gitlab.com/gitlab-org/gitlab/-/issues/323024

Removing these 3 files makes the upgrade to proceed,
/usr/share/gitlab/config/feature_flags/ops/api_kaminari_count_with 
_limit.yml

/usr/share/gitlab/config/feature_flags/licensed/resource_access_token.yml
/usr/share/gitlab/config/feature_flags/ops/marginalia.yml

Of these 3 
/usr/share/gitlab/config/feature_flags/licensed/resource_access_token.yml

can definitely be removed as it is not present in current version.

I think these are safe to remove, but I will wait a few days for an 
answer from upstream (till there is a new security release).


Or if someone else can confirm, this is safe, I can remove it as well.


ok, so the remaining two were also present in 
/usr/share/gitlab/config/feature_flags/development and were obsolete.


I confirmed the upgrade goes smooth after removing these and all other 
obsolete initializers. I have also implemented a check during build if 
any files in config is changed or not.


Moving 'config' directory out of /etc would be another option, but then 
that will need us to move files we would like users or package to be 
able to modify to /etc/gitlab manually (database.yml, gitlab.yml and 
some more .rb files like puma.rb). If anyone wants to give it a try, 
feel free.

Bug#983768: siridb-server ftbfs on riscv64

[Matthias Klose]

Package: src:siridb-server
Version: 2.0.43-1
Severity: important

siridb-server ftbfs on riscv64, should be linked with -latomic.

it looks like the binary has been silently removed:
https://buildd.debian.org/status/logs.php?pkg=siridb-server=2.0.42-1=riscv64=sid

[...]
Building target: siridb-server
Invoking: GCC C Linker
cc  -o "siridb-server" ./src/base64/base64.o ./src/xpath/xpath.o
./src/xmath/xmath.o ./src/timeit/timeit.o ./src/xstr/xstr.o ./src/vec/vec.o
./src/siri/service/account.o ./src/siri/service/client.o
./src/siri/service/request.o ./src/siri/net/bserver.o ./src/siri/net/clserver.o
./src/siri/net/pkg.o ./src/siri/net/promise.o ./src/siri/net/promises.o
./src/siri/net/protocol.o ./src/siri/net/stream.o ./src/siri/net/tcp.o
./src/siri/net/pipe.o ./src/siri/help/help.o ./src/siri/grammar/grammar.o
./src/siri/file/handler.o ./src/siri/file/pointer.o ./src/siri/db/access.o
./src/siri/db/aggregate.o ./src/siri/db/auth.o ./src/siri/db/buffer.o
./src/siri/db/db.o ./src/siri/db/ffile.o ./src/siri/db/fifo.o
./src/siri/db/forward.o ./src/siri/db/group.o ./src/siri/db/groups.o
./src/siri/db/initsync.o ./src/siri/db/insert.o ./src/siri/db/listener.o
./src/siri/db/lookup.o ./src/siri/db/median.o ./src/siri/db/misc.o
./src/siri/db/nodes.o ./src/siri/db/pcache.o ./src/siri/db/points.o
./src/siri/db/pool.o ./src/siri/db/pools.o ./src/siri/db/presuf.o
./src/siri/db/props.o ./src/siri/db/queries.o ./src/siri/db/query.o
./src/siri/db/re.o ./src/siri/db/reindex.o ./src/siri/db/replicate.o
./src/siri/db/series.o ./src/siri/db/server.o ./src/siri/db/servers.o
./src/siri/db/shard.o ./src/siri/db/shards.o ./src/siri/db/sset.o
./src/siri/db/tag.o ./src/siri/db/tags.o ./src/siri/db/tasks.o
./src/siri/db/tee.o ./src/siri/db/time.o ./src/siri/db/user.o
./src/siri/db/users.o ./src/siri/db/variance.o ./src/siri/db/walker.o
./src/siri/cfg/cfg.o ./src/siri/args/args.o ./src/siri/api.o ./src/siri/async.o
./src/siri/backup.o ./src/siri/buffersync.o ./src/siri/err.o ./src/siri/evars.o
./src/siri/health.o ./src/siri/heartbeat.o ./src/siri/optimize.o
./src/siri/siri.o ./src/siri/version.o ./src/qpack/qpack.o ./src/qpjson/qpjson.o
./src/procinfo/procinfo.o ./src/owcrypt/owcrypt.o ./src/logger/logger.o
./src/lock/lock.o ./src/llist/llist.o ./src/iso8601/iso8601.o
./src/lib/http_parser.o ./src/imap/imap.o ./src/omap/omap.o ./src/expr/expr.o
./src/ctree/ctree.o ./src/cfgparser/cfgparser.o ./src/cexpr/cexpr.o
./src/argparse/argparse.o ./main.o  -Wl,-z,relro -Wl,-z,now -luv -lm -lpcre2-8
-lcleri -lyajl -lcrypt -luuid
/usr/bin/ld: ./src/siri/net/stream.o: in function `sirinet__stream_free':
./Release/../src/siri/net/stream.c:274: undefined reference to
`__atomic_fetch_sub_2'
/usr/bin/ld: ./Release/../src/siri/net/stream.c:285: undefined reference to
`__atomic_fetch_sub_2'
/usr/bin/ld: ./Release/../src/siri/net/stream.c:255: undefined reference to
`__atomic_fetch_sub_2'
/usr/bin/ld: ./Release/../src/siri/net/stream.c:259: undefined reference to
`__atomic_fetch_sub_2'
/usr/bin/ld: ./src/siri/db/auth.o: in function `siridb_auth_user_request':
./Release/../src/siri/db/auth.c:40: undefined reference to 
`__atomic_fetch_add_2'

Bug#983767: nanopolish ftbfs with the nocheck profile

[Matthias Klose]

Package: src:nanopolish
Version: 0.13.2-2
Severity: important

nanopolish ftbfs with the nocheck profile:

[...]
make[1]: Entering directory '/<>'
dh_install
dh_install: warning: Cannot find (any matches for) "nanopolish_test" (tried in
., debian/tmp)

dh_install: warning: nanopolish missing files: nanopolish_test
dh_install: error: missing files, aborting
make[1]: *** [debian/rules:36: override_dh_install] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:26: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Bug#983764: /usr/share/chipcard/cards/README missing

[Micha Lenk]

Control: severity -1 serious

Hi Harald,

Am 01.03.21 um 14:44 schrieb Harald Welte:

Since the most recent update to libchipcard-date in unstable
yesterday, aqbanking-cli doesn't work with chipcard based banking
anymore:

chipcard-tool(31256):client.c:  215: Data files not found (-51)

Doing an strace showed that the program checks for the presence of
/usr/share/chipcard/cards/README and then fails if that doesn't exist.

A simple "sudo touch /usr/share/chipcard/cards/README" made aqbanking-cli
work again.


When removing that apparently bogus file, I didn't expect it to break 
the chipcard-tool binary. What a weird dependency...


Thank you for reporting this issue. Stay tuned, I'll upload a fixed 
package shortly.


Best regards,
Micha

Bug#983766: xphyle ftbfs from source

[Matthias Klose]

Package: src.xphyle
Version: 4.4.1-1
Severity: serious
Tags: sid bullseye

xphyle ftbfs from source, it needs at least the following changes:

  * Build-depend on python3-setuptools-scm.
  * Build-depend on python3-pytest.
  * Depend on python3-pkg-resources.

But then it still fails in the test suite:
https://launchpadlibrarian.net/525691852/buildlog_ubuntu-hirsute-amd64.xphyle_4.4.1-1ubuntu2_BUILDING.txt.gz

Bug#864603: gufw requires the xhost utility under wayland

[allada]

On Tue, 23 Feb 2021 13:02:27 +0100 Sebastian Spaeth 
 wrote:

The "crash" of gufw can easily be explained and fixed. However, I am not
sure we actually want this.

This is verified in bullseye: gufw 20.04.1-1

/usr/bin/gufw tests if we are under wayland and calls xhost:

if [ $(loginctl show-session $(loginctl|grep $(whoami) |awk '{print
$1}') -p Type) = "Type=wayland" ]; then
xhost +si:localuser:root
fi


which is in package "x11-xserver-utils" but which is not recorded by any
Debian package dependency.

So under wayland, "x11-xserver-utils" needs to become a dependency of
package gufw, or we crash as root cannot display stuff on the screen.

The question is whether we actually want such a far-reaching xhost
command sneaked in.




That script does not take into account the existence of several sessions.

$ loginctl
SESSION  UID USER  SEAT  TTY
 11 1000 user1 seat0 tty7
  2 1000 user1 seat0 tty2

2 sessions listed.


$ bash -xv /usr/bin/gufw
#!/bin/bash
if [ $(loginctl show-session $(loginctl|grep $(whoami) |awk '{print 
$1}') -p Type) = "Type=wayland" ]; then

xhost +si:localuser:root
fi
+++ loginctl
+++ awk '{print $1}'
 whoami
+++ grep user1
++ loginctl show-session 11 2 -p Type
+ '[' Type=wayland Type=wayland = Type=wayland ']'
/usr/bin/gufw: line 2: [: too many arguments


The condition could be replaced with something like:
if [ $(loginctl show-session $(loginctl|grep $(whoami) |awk '{print 
$1}'|tail -1) -p Type) = "Type=wayland" ]; then

Bug#983764: /usr/share/chipcard/cards/README missing

[Harald Welte]

Package: libchipcard-data
Version: 5.1.5rc2-6
Severity: important

Since the most recent update to libchipcard-date in unstable
yesterday, aqbanking-cli doesn't work with chipcard based banking
anymore:

chipcard-tool(31256):client.c:  215: Data files not found (-51)

Doing an strace showed that the program checks for the presence of
/usr/share/chipcard/cards/README and then fails if that doesn't exist.

A simple "sudo touch /usr/share/chipcard/cards/README" made aqbanking-cli
work again.


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

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

-- Configuration Files:
/etc/chipcard/client/chipcardc.conf changed:
char resmgr="pcsc"
server {
  char typ="local"
  char addr="/var/run/chipcard/chipcard.comm"
} # service


-- no debconf information

Bug#983765: r-cran-mice: autopkgtest failure on i386

[Adrian Bunk]

Source: r-cran-mice
Version: 3.13.0-2
Severity: important

https://ci.debian.net/packages/r/r-cran-mice/unstable/i386/

...
autopkgtest [10:27:56]: test run-unit-test: [---
sed: can't read testthat/test-pool.R: No such file or directory
autopkgtest [10:27:56]: test run-unit-test: ---]
autopkgtest [10:27:56]: test run-unit-test:  - - - - - - - - - - results - - - 
- - - - - - -
run-unit-testFAIL non-zero exit status 2



debian/tests/run-unit-test tries to sed-edit testthat/test-pool.R
a few lines after deleting the whole file.

Bug#983763: package unconditionally b-d's on libreoffice-writer

[Matthias Klose]

Package: src:gpredict
Version: 2.3-72-gc596101-3
Severity: serious
Tags: sid bullseye

package unconditionally b-d's on libreoffice-writer, not available on all
platforms, prohibiting migration to testing.

Bug#830180: Fixed since 1.5.3

[Mike Gabriel]

Control: close -1
Control: fixed -1 1:2.0.2-1~exp1

Upstream this has been fixed since 1.5.3. In Debian it was fixed with  
introducing libjpeg-turbo 2.0.2 in experimental.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpK5CXP7ooYC.pgp
Description: Digitale PGP-Signatur

Bug#983762: pokrok is missing a dependency on pkg_resources

[Matthias Klose]

Package: src:pokrok
Version: 0.2.0-1
Severity: serious
Tags: patch sid bullseye

pokrok is missing a dependency on pkg_resources.

patch at
http://launchpadlibrarian.net/525689938/pokrok_0.2.0-1_0.2.0-1ubuntu1.diff.gz

Bug#983723: Additional issues on arm64 and mips64el (Was: Bug#983723: rna-star FTBFS on ppc64el due to -march=native)

[Nilesh Patra]

Hi,

On Mon, 1 Mar, 2021, 6:13 pm Andreas Tille,  wrote:

> Hi,
>
> besides this on arm64[1] and mips64el:
>
> ...
> cd opal && \
> g++ -c -O3 -std=c++11 -march=native opal.cpp
> opal.cpp:9:10: fatal error: immintrin.h: No such file or directory
> 9 | #include  // AVX2 and lower
>   |  ^
> compilation terminated.
>
>
> Since this seems to be somehow related to simde and I'm lacking
> sufficient knowledge here I leave this to other team members in
> To-field.
>

This has been fixed in git repo, but I'm running out of time to finalize
this.
Discussion for the same has also been done on the mailing list

PS: this bug is on new version currently in unstable but *not* in testing,
and the bug report will probably not cause any removal warnings. It is
however best to fix this bug

Best Regards,
Nilesh

>

Bug#982050: [htcondor-debian] Bug#982050: There are fresh upstream releases (8.9.11 ATM) which address security and other issues

[Alex Waite]

@Tim That is great to hear that you're planning to push your changes for 8.8.12 
to NeuroDebian. I have been working on packaging the same release, and I have 
everything working except GLOBUS (which causes it to fail to build for me).

I've pushed what I have to https://salsa.debian.org/aqw-guest/htcondor

Let me know if/how you'd like to coordinate. :-)

I also have a problem with `/usr/lib/condor/libexec/condor_gpu_discovery 
-properties` segfaulting on ppc64el. It sounds a lot like HTCondor bug #7605 
[1], but persists in 8.8.12. What is the preferred way to report bugs to the 
HTCondor project: the mailing list or on HTCondor's bug tracker?

---Alex

[1] https://htcondor-wiki.cs.wisc.edu/index.cgi/tktview?tn=7605

Bug#861640: f2fs-tools: buffer overflow detected: fsck.f2fs terminated

[Diederik de Haas]

On Tue, 02 May 2017 07:52:47 +0200 Jerome Kieffer  
wrote:
> Package: f2fs-tools
> Version: 1.7.0-1.1~bpo8+1
> 
> I formated a complete SSD (Samsung 940evo, 250GB) interfaced in USB3 with
> F2FS on a debian stretch computer.
> 76GB of data were copied to it (mainly images and videos)
> 
> After 4 days, only 217MB of data remained.
> Running manually fsck on the volume crashed.
> Apparently this imay be related to:
> https://www.mail-archive.com/linux-f2fs-> 
> de...@lists.sourceforge.net/msg05070.html
> 
> The version 1.8 (compiled from sources) was able to run on the volume (while
> unable to retrieve the lost data).

The mentioned patch was first included in Debian's 1.10.0-1; f2fs-tools is at 
version 1.14.0-2 in testing/unstable, while Stable has version 1.11.0-1.1.

Can you confirm this issue is resolved?

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

Bug#983761: golang-android-soong FTBFS on 32bit

[Adrian Bunk]

Source: golang-android-soong
Version: 0.0~git20201014.17e97d9-2
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=golang-android-soong=sid

...
# android/soong/finder/fs
src/android/soong/finder/fs/fs_linux.go:46:35: cannot use linuxStats.Ctim.Sec 
(type int32) as type int64 in argument to time.Unix
src/android/soong/finder/fs/fs_linux.go:46:56: cannot use linuxStats.Ctim.Nsec 
(type int32) as type int64 in argument to time.Unix
android/soong/ui/metrics/upload_proto
...

Bug#968045: golang-gonum-v1-plot: please make the build reproducible

[Chris Lamb]

Hi Nilesh,

(Just to say that I did not see your two emails until now; the bug
submitter does not automatically receive emails sent directly to the
bug email address — one should either CC them directly or use the
968045-submitter@ alias too.)

> Thanks again, but unfortunately this patch breaks the autopkgtests :/
> The only way to make it reproducible and allow testing migration would
> be to disable the tests.

As I understand the problem:

* The data underneath /testdata/ has non-deterministic data (PDFs)

* The patch prevents /testdata/ from being installed in the binary
  package.

* The autopkgtests fail as they require this test data.

> What do you think would be better? Please let me know.

Interesting choice of trade-off. Would it be possible for the
autopkgtests to build the test data at "autopkgtest time"?

Alternatively, do we need these PDFs? We could ship the testdata
directory but not ship the .pdf files?

The other, nicer solution could be to patch fpdf to use the
SOURCE_DATE_EPOCH environment variable if it exists. This would seem
quite straightforward to do, actually -- this is fpdf.go from the
"golang-github-jung-kurt-gofpdf" source package:

  // returns Now() if tm is zero
  func timeOrNow(tm time.Time) time.Time {
if tm.IsZero() {
  return time.Now()
}
return tm
  }


Regards,

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

Bug#983750: networkmanager: NM takes over slave interfaces of bond

[Michel Meyers]

Package: networkmanager
Severity: normal

Dear Maintainer,

I had a bond configured as described in Example 1 on: 
https://wiki.debian.org/Bonding

This morning, my server's bond interface showed down, and its slaves
kept getting removed. After some digging, I found that networkmanager
had gotten installed and a check in nmcli showed that it had taken over each of 
the slave interfaces
while listing bond0 as unmanaged.

It appears that NM ignores the "slaves eth0 eth1" directive in
/etc/network/interfaces so unless each of the interfaces is specifically
named as in Example 2, NM takes over the slaves, killing the bond.

- Michel



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#940621: libmeanwhile1: Login verification down or unavailable on 1.0.2-9+b1

[Adrien CLERC]

On Fri, 26 Feb 2021 21:28:06 -0500 Boyuan Yang  wrote:
>
> Since the hard freeze is approaching, I will go with the conservative
> way and upload meanwhile/1.1.1-2 with the following line:
>
> export DEB_CFLAGS_MAINT_APPEND=-O0 -fno-tree-vrp
>
> Please test whether the built package fixes the bug once you have
> access to meanwhile/1.1.1-2 in Debian Sid. Let me know if it needs
> further fix.

Tested and verified, the package works fine for me.

Thanks for the quick fix!

Adrien

Bug#955549: [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults

[Diederik de Haas]

On Wed, 15 Apr 2020 11:28:46 +0800 Chao Yu  wrote:
> On 2020/4/10 7:32, Adam Borowski wrote:
> > I still get a segfault:
> 
> Oops..
> 
> > Program received signal SIGSEGV, Segmentation fault.
> > ...
> 
> Fixed with
> 
> [PATCH] fsck.f2fs: fix to avoid overflow during print_inode_info()

This patch is included in the version of f2fs-tools that's currently in 
testing and unstable (and stable backports).
Can you confirm the issue is resolved?

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

Bug#983760: java3d FTBFS on 32bit: error: conflicting types for ‘GLsizeiptr’

[Adrian Bunk]

Source: java3d
Version: 1.5.2+dfsg-16
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/buster/i386/java3d.html
https://buildd.debian.org/status/package.php?p=java3d=sid

...
 [exec] In file included from /usr/include/GL/gl.h:2050,
 [exec]  from 
/<>/j3d-core/src/native/ogl/gldefs.h:70,
 [exec]  from 
/<>/j3d-core/src/native/ogl/Canvas3D.c:47:
 [exec] /usr/include/GL/glext.h:469:25: error: conflicting types for 
‘GLsizeiptr’
 [exec]   469 | typedef khronos_ssize_t GLsizeiptr;
 [exec]   | ^~
 [exec] In file included from 
/<>/j3d-core/src/native/ogl/Canvas3D.c:47:
 [exec] /<>/j3d-core/src/native/ogl/gldefs.h:68:19: note: 
previous declaration of ‘GLsizeiptr’ was here
 [exec]68 | typedef ptrdiff_t GLsizeiptr;
 [exec]   |   ^~
...

Bug#978105: vorta: SIGSEGV on exit

[Nicholas D Steeves]

Hi Manu!

Thank you for working on this, and for reaching out here :-)

Manuel Riel  writes:

> Hi all,
>
> Thanks for tracking this bug. I couldn't reproduce it on Debian unstable with 
> Debian-provided PyQt. But it reliably fails when installing PyQt5 from PyPi.
>
> Based on other reports the key problem is the cleanup of Qt widgets. Some 
> sources suggest to remove all widgets in the right order bottom-up, but for 
> our case just removing the main (and only) window was enough:
>
> del app.main_window
>
> Here a PR to fix this by adding a more complete cleanup function: 
> https://github.com/borgbase/vorta/pull/877/files
>
> If possible, please let me know if this resolves the issue everywhere.
>

I can confirm that the fix included in 0.7.4 changes the trigger case
for me, and after about a dozen runs of manual testing I found that I
could reliably trigger this crash 4/4 times:

1. With a new user who has no Vorta config
2. Open Vorta
3. Do nothing
4. Quit from tray icon
5. Exit code 139 (SIGEGV)

Here is the backtrace:
Starting program: /usr/bin/python3 /usr/bin/vorta
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffef21a700 (LWP 37224)]
[New Thread 0x7fffee9f9700 (LWP 37225)]
[Detaching after fork from child process 37226]
[New Thread 0x7fffed05c700 (LWP 37227)]
[New Thread 0x7fffec85b700 (LWP 37228)]
[New Thread 0x7fffde80d700 (LWP 37229)]
[New Thread 0x7fffde00c700 (LWP 37230)]
[New Thread 0x7fffdd80b700 (LWP 37231)]
[New Thread 0x7fffdd00a700 (LWP 37232)]
[New Thread 0x7fffdc809700 (LWP 37233)]
[Detaching after fork from child process 37234]
[Thread 0x7fffdc809700 (LWP 37233) exited]
[Thread 0x7fffec85b700 (LWP 37228) exited]
[Thread 0x7fffed05c700 (LWP 37227) exited]

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
0x71b3b7e7 in QWidget::~QWidget (this=0x13b6710, __in_chrg=) at kernel/qwidget.cpp:1478
1478kernel/qwidget.cpp: No such file or directory.
#0  0x71b3b7e7 in QWidget::~QWidget (this=0x13b6710, 
__in_chrg=) at kernel/qwidget.cpp:1478
#1  0x71e85e2d in QSystemTrayIconSys::~QSystemTrayIconSys 
(this=0x13b6710, __in_chrg=)
at util/qsystemtrayicon_x11.cpp:76
#2  QSystemTrayIconSys::~QSystemTrayIconSys (this=0x13b6710, 
__in_chrg=) at util/qsystemtrayicon_x11.cpp:76
#3  0x71e85512 in QSystemTrayIconPrivate::destroyIcon (this=0x1372b90) 
at util/qsystemtrayicon_x11.cpp:278
#4  QSystemTrayIconPrivate::destroyIcon (this=0x1372b90) at 
util/qsystemtrayicon_x11.cpp:272
#5  QSystemTrayIconPrivate::remove_sys (this=0x1372b90) at 
util/qsystemtrayicon_x11.cpp:269
#6  0x71e65dab in QSystemTrayIcon::~QSystemTrayIcon (this=0x12b0a50, 
__in_chrg=)
at util/qsystemtrayicon.cpp:182
#7  0x721afd19 in sipQSystemTrayIcon::~sipQSystemTrayIcon 
(this=0x12b0a50, __in_chrg=)
at ./build-3.9/QtWidgets/sipQtWidgetspart1.cpp:52814
#8  0x7587fb7e in QObjectPrivate::deleteChildren (this=0x118ce40) at 
kernel/qobject.cpp:2104
#9  0x7588a754 in QObject::~QObject (this=, 
__in_chrg=) at kernel/qobject.cpp:1082
#10 0x7239f5e9 in sipQApplication::~sipQApplication (this=0x124d3a0, 
__in_chrg=)
at ./build-3.9/QtWidgets/sipQtWidgetspart9.cpp:17019
#11 0x75d2d7ad in cleanup_on_exit () at 
../../qpy/QtCore/qpycore_init.cpp:44
#12 0x0052606e in cfunction_vectorcall_NOARGS (func=0x75e49630, 
args=, nargsf=, 
kwnames=) at ../Objects/methodobject.c:485
#13 0x00631090 in atexit_callfuncs (module=) at 
../Modules/atexitmodule.c:93
#14 0x0061af1d in call_py_exitfuncs (tstate=0x962e80) at 
../Python/pylifecycle.c:2374
#15 0x0061a76d in Py_FinalizeEx () at ../Python/pylifecycle.c:1373
#16 0x0062c008 in Py_Exit (sts=0) at ../Python/pylifecycle.c:2433
#17 0x0061c43b in handle_system_exit () at ../Python/pythonrun.c:722
#18 0x0061c3a2 in _PyErr_PrintEx (set_sys_last_vars=1, tstate=0x962e80) 
at ../Python/pythonrun.c:732
#19 PyErr_PrintEx (set_sys_last_vars=1) at ../Python/pythonrun.c:827
#20 0x00619845 in PyErr_Print () at ../Python/pythonrun.c:833
#21 pyrun_simple_file (flags=0x7fffe428, closeit=, 
filename=0x775f8030, fp=)
at ../Python/pythonrun.c:455
#22 PyRun_SimpleFileExFlags (fp=, filename=, 
closeit=, flags=0x7fffe428)
at ../Python/pythonrun.c:482
#23 0x0060d4e3 in pymain_run_file (cf=0x7fffe428, config=0x9617e0) 
at ../Modules/main.c:373
#24 pymain_run_python (exitcode=0x7fffe420) at ../Modules/main.c:598
#25 Py_RunMain () at ../Modules/main.c:677
#26 0x005ea6e9 in Py_BytesMain (argc=, argv=) at ../Modules/main.c:731
#27 0x77c44d0a in __libc_start_main () from 
/lib/x86_64-linux-gnu/libc.so.6
#28 0x005ea5ea in _start () at ../Python/getplatform.c:11

Sandro, can you tell if this backtrace indicates that Debian's PyQt
and/or QtWidgets might have a problem? "kernel/qwidget.cpp: No such file
or 

Bug#979296: u-boot: Restructure the packaging

[Nicolas Boulenguez]

Source: u-boot
Followup-For: Bug #979296

Hello.
This suggestion and related ones like 980{236,358-363} will probably
wait for the end of the freeze.  Meanwhile, I am doing trivial but
non-automatic rebases locally.  It does not seem useful to flood
this bug log with intermediate rebases, so if this is OK with you,
I will only send up-to-date versions on demand.

Bug#983759: Enable CONFIG_DRM_DW_HDMI_CEC on arm64

[Punit Agrawal]

Package: linux-image-arm64
Severity: normal

Hi,

I am using Debian on a RK3399 based RockPro64[0] connected to a CEC enabled TV.

The HDMI port on the board supports CEC - I was able to verify this in
a local kernel build with CONFIG_DRM_DW_HDMI_CEC enabled. It would be
great if this driver could be enabled in the Debian kernel package as
a module.

Thanks,
Punit

[0] https://www.pine64.org/rockpro64/

Bug#983723: Additional issues on arm64 and mips64el (Was: Bug#983723: rna-star FTBFS on ppc64el due to -march=native)

[Andreas Tille]

Hi,

besides this on arm64[1] and mips64el:

...
cd opal && \
g++ -c -O3 -std=c++11 -march=native opal.cpp
opal.cpp:9:10: fatal error: immintrin.h: No such file or directory
9 | #include  // AVX2 and lower
  |  ^
compilation terminated.


Since this seems to be somehow related to simde and I'm lacking
sufficient knowledge here I leave this to other team members in
To-field.

Kind regards

Andreas.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=rna-star=arm64=2.7.8a%2Bdfsg-1=1614105813=0
[2] 
https://buildd.debian.org/status/fetch.php?pkg=rna-star=mips64el=2.7.8a%2Bdfsg-1=1614106363=0

On Sun, Feb 28, 2021 at 09:46:50PM +0100, Helmut Grohne wrote:
> Source: rna-star
> Version: 2.7.8a+dfsg-1
> Severity: serious
> Tags: ftbfs
> 
> rna-star fails to build from source on ppc64el (but previsouly built
> there), because it now passes -march=native to g++:
> 
> | g++ -c -O3 -std=c++11 -march=native opal.cpp
> | g++: error: unrecognized command-line option ‘-march=native’; did you mean 
> ‘-mcpu=native’?

-- 
http://fam-tille.de

Bug#983695: ibus-anthy: does not work out of the box on the GNOME desktop

[YOSHINO Yoshihito]

Hi,

On Mon, Mar 1, 2021 at 5:56 PM Gunnar Hjalmarsson  wrote:
> In  you write:
>
> > This is caused by the change in the gnome-shell package (Bug#815050)
> > to add "Recommends: ibus", which breaks any non-ibus input method
> > framework (Bug#941624),

What I am talking about here is im-config's preference ordering.
Its default is found in /usr/share/im-config/data/:
21_ibus.rc
22_fcitx.rc
23_fcitx5.rc
24_uim.rc
...
where ibus is most preferred.
(IMO this ordering itself is carefully managed and good.)
This used to be able to be overridden by IM_CONFIG_PREFERRED_RULE in
/etc/default/im-config, while it is no longer possible,
as long as DESKTOP_SETUP_IBUS contains "GNOME".
(IMO this variable itself is reasonable because gnome-shell
unconditionally starts /usr/bin/ibus-daemon if it is found and then
it sometimes interferes with another IM framework.)

So once ibus is installed on the GNOME desktop for some reason,
ibus is always preferred by default.
On the GNOME desktop, "non-ibus IM framework is installed and used by
default, switch to ibus if you want it" is no longer possible.
I wrote "breaks" in this sense.

By the way ...

> We did have an issue with im-config where the presence of IBus disabled
> im-config and prevented you from configuring some non-IBus input method
> framework. That issue has been fixed, and in Bullseye you will be able
> to configure e.g. Fcitx or UIM via im-config.
>
> https://salsa.debian.org/input-method-team/im-config/-/commit/c2055cc4

Yes I saw your commit several months ago.
Now that DESKTOP_SETUP_IBUS variable exists, non-ibus users are
already warned:
"When ibus is installed, another IM system is not preferred by default,
which may be interfered by ibus"
So IMO this commit is now reasonable.

Regards,
-- 
YOSHINO Yoshihiro 

Bug#983758: python-xarray: autopkgtest regression on several architectures

[Adrian Bunk]

Source: python-xarray
Version: 0.17.0-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/arm64/p/python-xarray/10765498/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/p/python-xarray/10765498/log.gz

...
=== FAILURES ===
___ TestDataArray.test_pad_constant 

self = 

def test_pad_constant(self):
ar = DataArray(np.arange(3 * 4 * 5).reshape(3, 4, 5))
actual = ar.pad(dim_0=(1, 3))
expected = DataArray(
np.pad(
np.arange(3 * 4 * 5).reshape(3, 4, 5).astype(np.float32),
mode="constant",
pad_width=((1, 3), (0, 0), (0, 0)),
constant_values=np.nan,
)
)
assert actual.shape == (7, 4, 5)
assert_identical(actual, expected)

ar = xr.DataArray([9], dims="x")

actual = ar.pad(x=1)
expected = xr.DataArray([np.NaN, 9, np.NaN], dims="x")
assert_identical(actual, expected)

actual = ar.pad(x=1, constant_values=1.23456)
expected = xr.DataArray([1, 9, 1], dims="x")
assert_identical(actual, expected)

if LooseVersion(np.__version__) >= "1.20":
with pytest.raises(ValueError, match="cannot convert float NaN to 
integer"):
ar.pad(x=1, constant_values=np.NaN)
else:
actual = ar.pad(x=1, constant_values=np.NaN)
expected = xr.DataArray(
[-9223372036854775808, 9, -9223372036854775808], dims="x"
)
>   assert_identical(actual, expected)
E   AssertionError: Left and right DataArray objects are not identical
E   
E   Differing values:
E   L
E   array([0, 9, 0])
E   R
E   array([-9223372036854775808,9, 
-9223372036854775808],
E dtype=int64)

/usr/lib/python3/dist-packages/xarray/tests/test_dataarray.py:4523: 
AssertionError
=== warnings summary ===
...


https://ci.debian.net/data/autopkgtest/testing/i386/p/python-xarray/10765494/log.gz

...
=== FAILURES ===
___ TestDataArray.test_pad_constant 

self = 

def test_pad_constant(self):
ar = DataArray(np.arange(3 * 4 * 5).reshape(3, 4, 5))
actual = ar.pad(dim_0=(1, 3))
expected = DataArray(
np.pad(
np.arange(3 * 4 * 5).reshape(3, 4, 5).astype(np.float32),
mode="constant",
pad_width=((1, 3), (0, 0), (0, 0)),
constant_values=np.nan,
)
)
assert actual.shape == (7, 4, 5)
assert_identical(actual, expected)

ar = xr.DataArray([9], dims="x")

actual = ar.pad(x=1)
expected = xr.DataArray([np.NaN, 9, np.NaN], dims="x")
assert_identical(actual, expected)

actual = ar.pad(x=1, constant_values=1.23456)
expected = xr.DataArray([1, 9, 1], dims="x")
assert_identical(actual, expected)

if LooseVersion(np.__version__) >= "1.20":
with pytest.raises(ValueError, match="cannot convert float NaN to 
integer"):
ar.pad(x=1, constant_values=np.NaN)
else:
actual = ar.pad(x=1, constant_values=np.NaN)
expected = xr.DataArray(
[-9223372036854775808, 9, -9223372036854775808], dims="x"
)
>   assert_identical(actual, expected)
E   AssertionError: Left and right DataArray objects are not identical
E   
E   Differing values:
E   L
E   array([-2147483648,   9, -2147483648])
E   R
E   array([-9223372036854775808,9, 
-9223372036854775808],
E dtype=int64)

/usr/lib/python3/dist-packages/xarray/tests/test_dataarray.py:4523: 
AssertionError
=== warnings summary ===
...

Bug#983756: can qemu-system-common be Multi-Arch: foreign again?

[Helmut Grohne]

Package: qemu-system-common
Version: 1:5.2+dfsg-6
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:libvirt

libvirt cannot be cross built from source, because its Build-Depends:
qemu-system-common now results in a conflict. The direct dependency asks
for the host architecture qemu-system-common and a Multi-Arch: foreign
qemu frontend also depends on qemu-system-common, which becomes a build
architecture dependency.

According to the git history, qemu-system-common was Multi-Arch:
foreign. Then you moved qemu modules into it and (rightly) removed the
foreign annotation. At a later point it seems that the modules were
moved out again (e.g. to qemu-system-gui) and now I cannot find any
modules in qemu-system-common anymore.

Can we mark it Multi-Arch: foreign again?

libvirt wants qemu-bridge-helper. What is the correct dependency for
that tool? It presently uses qemu-system-common and that's ok if it
becomes M-A:foreign again.

Helmut

Bug#983755: trapperkeeper-webserver-jetty9-clojure FTBFS on IPV6-only buildds

[Adrian Bunk]

Source: trapperkeeper-webserver-jetty9-clojure
Version: 4.1.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=trapperkeeper-webserver-jetty9-clojure=all

Bug#983563: [debian-mysql] Bug#983563: mariadb-server: trigger fails when systemd is not running (eg. chroot)

[Faustin Lammler]

Hi Arnaud!

Arnaud Rebillout ,
26/02/2021 – 16:39:41 (+0700):

> Hence I believe that the line:
> 
>   if [ -x "$(command -v systemctl)" ]; then
> 
> Should be replaced by:
> 
>   if [ -d /run/systemd/system ]; then
I am not sure that this is what we want here. Indeed, doing this would
lead to the execution of `invoke-rc.d mariadb restart` in your
particular case (but you are using systemd not sysv init). Or I am
missing something?

Could point me to the steps in your CI where this happen so I can try to
reproduce it?

-- 
Faustin Lammler
GPG: F652 BCD1 1AA8 8975 F010 48A5 390A 2F27 832A 5C79


signature.asc
Description: PGP signature

Bug#983653: task-japanese-gnome-desktop: no Japanese input method available out of the box

[YOSHINO Yoshihito]

Hi,

On Mon, Mar 1, 2021 at 7:51 PM Holger Wansing  wrote:
> May I ask how that interacts with the uim framework?
>
> We currently have
>
> Recommends:
> [...]
> uim,
> uim-mozc | uim-anthy,
>
> in task-japanese-desktop, so if you now add ibus-mozc | ibus-anthy to
> task-japanese-gnome-desktop, we will have both, uim-mozc and ibus-mozc 
> installed
> on a Gnome system.

Yes.

> Is that ok? Or does that cause any harm/conflict/what ever?

This is ok. "im-config" package deals with such an IM framework selection.
When ibus and uim are both installed, ibus is preferred and used by default.
(The selection can be changed by user choice.)
Then no input method in ibus framework is currently installed,
so its user cannot type Japanese text out of the box.

Regards,
-- 
YOSHINO Yoshihito 

Bug#982982: u-boot: Add support for the pinetab platform

[Nicolas Boulenguez]

Source: u-boot
Followup-For: Bug #982982

Hello.
The attachment is rebased on debian/2021.01+dfsg-3.
>From 9abe9a8b72aeeb672178d418abec5bc988ce779c Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Wed, 17 Feb 2021 18:45:27 +0100
Subject: Add support for the pinetab platform

The patch adding a defconfig has been forwarded to u-boot upstream.

diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
index dc948840be..8355329d56 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -42,6 +42,7 @@ if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
"Pine64+") TARGET="/usr/lib/u-boot/pine64_plus" ;;
"Pine64 LTS") TARGET="/usr/lib/u-boot/pine64-lts" ;;
"PineRiver Mini X-Plus") TARGET="/usr/lib/u-boot/Mini-X" ;;
+   "PineTab") TARGET="/usr/lib/u-boot/pinetab" ;;
"Xunlong Orange Pi Plus / Plus 2") 
TARGET="/usr/lib/u-boot/orangepi_plus" ;;
"Xunlong Orange Pi Zero") 
TARGET="/usr/lib/u-boot/orangepi_zero" ;;
*)
diff --git a/debian/patches/pinetab/0001-configs-add-PineTab-defconfig.patch 
b/debian/patches/pinetab/0001-configs-add-PineTab-defconfig.patch
new file mode 100644
index 00..03b9c32f33
--- /dev/null
+++ b/debian/patches/pinetab/0001-configs-add-PineTab-defconfig.patch
@@ -0,0 +1,29 @@
+From 2c346cacb4b0841051bceb27a57058020860ab8b Mon Sep 17 00:00:00 2001
+From: Arnaud Ferraris 
+Date: Wed, 2 Sep 2020 09:53:50 +0200
+Subject: [PATCH] configs: add PineTab defconfig
+
+--- /dev/null
 b/configs/pinetab_defconfig
+@@ -0,0 +1,21 @@
++CONFIG_ARM=y
++CONFIG_ARCH_SUNXI=y
++CONFIG_SPL=y
++CONFIG_IDENT_STRING=""
++CONFIG_MACH_SUN50I=y
++CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
++CONFIG_DRAM_CLK=552
++CONFIG_DRAM_ZQ=3881949
++CONFIG_MMC_SUNXI_SLOT_EXTRA=2
++# CONFIG_VIDEO_DE2 is not set
++CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pinetab"
++# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
++CONFIG_BOOTDELAY=0
++CONFIG_SYS_CONSOLE_INFO_QUIET=y
++# CONFIG_DISPLAY_CPUINFO is not set
++# CONFIG_DISPLAY_BOARDINFO is not set
++# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
++# CONFIG_SPL_BANNER_PRINT is not set
++# CONFIG_SPL_POWER_SUPPORT is not set
++# CONFIG_NET is not set
++# CONFIG_EFI_LOADER is not set
diff --git a/debian/patches/series b/debian/patches/series
index 6e737632d3..745b81bf22 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -19,3 +19,5 @@ 
riscv64/qemu-riscv64_smode-sifive-fu540-fix-extlinux-define-.patch
 n900/bootz_and_raw_initrd.patch
 
 rk3399/disable-preboot
+
+pinetab/0001-configs-add-PineTab-defconfig.patch
diff --git a/debian/targets b/debian/targets
index a2855f6daf..04c5b31978 100644
--- a/debian/targets
+++ b/debian/targets
@@ -259,6 +259,9 @@ arm64   sunxi   pinebook
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.b
 # Arnaud Ferraris  (1.1, 1.2)
 arm64  sunxi   pinephone   
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pinephone-1.1.dtb 
arch/arm/dts/sun50i-a64-pinephone-1.2.dtb u-boot-sunxi-with-spl.fit.itb
 
+# Arnaud Ferraris 
+arm64  sunxi   pinetab 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pinetab.dtb 
u-boot-sunxi-with-spl.fit.itb
+
 # Jonas Smedegaard 
 arm64  sunxi   teres_i 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-teres-i.dtb 
u-boot-sunxi-with-spl.fit.itb
 

Bug#983750: [Pkg-utopia-maintainers] Bug#983750: networkmanager: NM takes over slave interfaces of bond

[Michael Biebl]

Am 01.03.21 um 11:56 schrieb Michel Meyers:
I have now created [device] sections declaring the slaves as managed=0 
in the NetworkManager.conf (left over after uninstalling NM), but anyone 
with the same config as me making the same mistake of inadvertently 
installing NM will land in the same weird situation where their bond0 
interface is up but not getting its slaves. (I've also started looking 
at specifically declaring the slave interfaces in 
/etc/network/interfaces, but not had success with that so far as it 
stops the bond0 interface from coming up correctly. "Example 2" from the 
docs seems broken here ... more debugging to be done.)


Trying to parse and interpret /etc/network/interfaces in NetworkManager 
is a losing battle I fear.


We have some support to understand basic ifupdown configurations, but 
it's incomplete and buggy.


Can you share your /e/n/i?



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983706: gzip FTBFS on mips64el: FAIL: timestamp

[YunQiang Su]

Adrian Bunk  于2021年3月1日周一 下午5:27写道：
>
> On Mon, Mar 01, 2021 at 10:59:20AM +0800, YunQiang Su wrote:
> > Adrian Bunk  于2021年3月1日周一 上午7:13写道：
> > >
> > > Source: gzip
> > > Version: 1.10-2
> > > Severity: serious
> > > Tags: ftbfs
> > >
> > > https://buildd.debian.org/status/fetch.php?pkg=gzip=mips64el=1.10-3=1614531854=0
> >
> > It seems due to some problem of kernel or filesystem:
> >...
> > > On the porterbox eller, 1.10-2 fails the same as 1.10-3.
> > > 1.10-3 builds in a buster chroot.
>
> This implies that what changed is in userspace.
>
> >...
> > On x86:
> > syq@vm208:~$ touch -t 196912312359.59 in
> > syq@vm208:~$ ls -l in
> > -rw-r--r-- 1 syq syq 0 Dec 31  1969 in
> > syq@vm208:~$ cp -a in in.xx
> > syq@vm208:~$ ls -l in.xx
> > -rw-r--r-- 1 syq syq 0 Dec 31  1969 in.xx
> >
> > On mips:
> > syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ ls -l in
> > -rw-r--r-- 1 syq syq 0 Dec 31  1969 in
> > syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ cp -a in in.xx
> > syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ ls -l in.xx
> > -rw-r--r-- 1 syq syq 0 Feb  7  2106 in.xx
>
> On eller the difference is that in buster
> the "ls -l in" already shows the 2106 date:
>
> (buster_mips64el-dchroot)bunk@eller:~$ ls -l in
> -rw-r--r-- 1 bunk bunk 0 Feb  7  2106 in
>
> (sid_mips64el-dchroot)bunk@eller:~$ ls -l in
> -rw-r--r-- 1 bunk bunk 0 Dec 31  1969 in

With some digging, we found the real problem:
mips64 has y2106 problem

the struct stat in asm/stat.h, the timestamp is unsigned int (uint32_t),
so in the SYS_stat, -1 is converted to 0xff.

Then in glibc wrapper of stat, 0x need to convert to int64_t, then,
it is converted to 2016.

So, current, for gzip, we can just ignore the test fails on mips64el.

To solve this problem: I guess that we can wrap `statx' instead of
`stat' in glibc.
Since the timestamp in bits/stat.h is 64bit, there will no ABI broken.

>
>
> cu
> Adrian



-- 
YunQiang Su

Bug#979765: Kernel panic of linux 5.10.13-1 with VIA Nano L2200 on VX800

[8vvbbqzo567a]

My issue looks the same as that of Kazimierz, but I have a VIA Nano L2200 with 
VX800 chipset.
I upgraded from buster to bullseye. The 5.10.13-1 kernel panics during boot, 
but the system boots when I use the old buster 4.19.171-2 kernel.

Panic message (full boot messages attached):
[   12.879551] general protection fault:  [#1] SMP PTI
[   12.879553] CPU: 0 PID: 216 Comm: udevadm Not tainted 5.10.0-3-amd64 #1 
Debian 5.10.13-1
[   12.879555] Hardware name: VIA Technologies Ltd. VX800 /VX800 , BIOS 6.00 PG 
02/26/2009
[   12.879557] RIP: 0010:native_read_pmc+0x4/0x40
[   12.879560] Code: 00 00 00 0f 1f 00 53 48 89 fb 66 66 90 66 90 48 89 df e8 
6f 11 01 00 48 89 c6 48 89 33 5b c3 0f 1f 80 00 00 00 00 41 54 89 f9 <0f> 33 66 
66 66 66 90 48 c1 e2 20 49 89 d4 49 09 c4 4c 89 e0 41 5c
[   12.879561] RSP: 0018:fe00bc88 EFLAGS: 00010046
[   12.879565] RAX: 0021 RBX: fffc467f5200 RCX: 4001
[   12.879567] RDX: 0021 RSI: 0040 RDI: 4001
[   12.879569] RBP: 907ac11c8000 R08: 030a R09: 
[   12.879570] R10:  R11:  R12: 907ac11c81e0
[   12.879572] R13: 0018 R14: 0021 R15: 907b35c119a0
[   12.879574] FS:  7fd7a9b908c0() GS:907b35c0() 
knlGS:
[   12.879576] CS:  0010 DS:  ES:  CR0: 80050033
[   12.879577] CR2: 55da8b1ea080 CR3: 067fe000 CR4: 06f0
[   12.879578] Call Trace:
[   12.879580]  
[   12.879581]  x86_perf_event_update+0x4a/0xa0
[   12.879582]  zhaoxin_pmu_handle_irq+0x13a/0x250
[   12.879584]  perf_event_nmi_handler+0x28/0x50
[   12.879585]  nmi_handle+0x58/0x100
[   12.879586]  default_do_nmi+0x42/0x130
[   12.879588]  exc_nmi+0x131/0x150
[   12.879589]  end_repeat_nmi+0x16/0x55
[   12.879590] RIP: 0010:kernfs_dop_revalidate+0x27/0xc0
[   12.879593] Code: 00 00 00 66 66 66 66 90 83 e6 40 0f 85 a5 00 00 00 41 54 
31 c0 55 53 48 8b 57 30 48 89 fb 48 85 d2 74 45 4c 8b a2 50 02 00 00 <48> c7 c7 
60 51 d8 95 e8 4d 59 54 00 41 8b 44 24 04 85 c0 78 1b 48
[   12.879595] RSP: 0018:9e938018fcc8 EFLAGS: 0286
[   12.879598] RAX:  RBX: 907ac749ce40 RCX: 0030
[   12.879599] RDX: 907ac753 RSI:  RDI: 907ac749ce40
[   12.879601] RBP: 907ac749c600 R08: 2f2f2f2f2f2f2f2f R09: 746e65766575
[   12.879603] R10: 0006 R11: 8b919a899a8a R12: 907ac12b2800
[   12.879604] R13: 9e938018fdd0 R14: 9e938018fdd0 R15: 907b3077e400
[   12.879606]  ? kernfs_dop_revalidate+0x27/0xc0
[   12.879607]  ? kernfs_dop_revalidate+0x27/0xc0
[   12.879608]  
[   12.879610]  lookup_fast+0xd7/0x150
[   12.879611]  path_openat+0x10d/0x1100
[   12.879612]  ? ehci_work.part.0+0x933/0xb20 [ehci_hcd]
[   12.879614]  do_filp_open+0x88/0x130
[   12.879615]  ? getname_flags.part.0+0x29/0x1a0
[   12.879616]  ? __check_object_size+0x136/0x150
[   12.879618]  do_sys_openat2+0x97/0x150
[   12.879619]  __x64_sys_openat+0x54/0x90
[   12.879620]  do_syscall_64+0x33/0x80
[   12.879622]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   12.879623] RIP: 0033:0x7fd7aa129767
[   12.879626] Code: 25 00 00 41 00 3d 00 00 41 00 74 47 64 8b 04 25 18 00 00 
00 85 c0 75 6b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 
f0 ff ff 0f 87 95 00 00 00 48 8b 4c 24 28 64 48 2b 0c 25
[   12.879628] RSP: 002b:7ffc09a32e20 EFLAGS: 0246 ORIG_RAX: 
0101
[   12.879631] RAX: ffda RBX:  RCX: 7fd7aa129767
[   12.879633] RDX: 00080101 RSI: 56150acc5d40 RDI: ff9c
[   12.879634] RBP: 56150acc5d40 R08: fefefefefefefe00 R09: ff00
[   12.879636] R10:  R11: 0246 R12: 00080101
[   12.879638] R13: 0040 R14: 7ffc09a33f38 R15: 56150acc5d40
[   12.879639] Modules linked in: fuse configfs ip_tables x_tables autofs4 ext4 
crc16 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq 
async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath 
linear md_mod hid_generic usbhid hid sd_mod t10_pi crc_t10dif crct10dif_generic 
crct10dif_common ata_generic uas usb_storage uhci_hcd ehci_pci ehci_hcd 
sata_sil pata_via libata usbcore r8169 scsi_mod realtek mdio_devres libphy 
i2c_viapro usb_common fan
[   13.243786] ---[ end trace 44b496d47959a5df ]---
[   13.243787] RIP: 0010:native_read_pmc+0x4/0x40
[   13.243790] Code: 00 00 00 0f 1f 00 53 48 89 fb 66 66 90 66 90 48 89 df e8 
6f 11 01 00 48 89 c6 48 89 33 5b c3 0f 1f 80 00 00 00 00 41 54 89 f9 <0f> 33 66 
66 66 66 90 48 c1 e2 20 49 89 d4 49 09 c4 4c 89 e0 41 5c
[   13.243792] RSP: 0018:fe00bc88 EFLAGS: 00010046
[   13.243795] RAX: 0021 RBX: fffc467f5200 RCX: 4001
[   13.243796] RDX: 0021 RSI: 0040 RDI: 4001
[   13.243798] RBP: 907ac11c8000 R08: 

Bug#983750: [Pkg-utopia-maintainers] Bug#983750: networkmanager: NM takes over slave interfaces of bond

[Michael Biebl]

Am 01.03.21 um 10:41 schrieb Andrei POPESCU:

Control: reassign -1 network-manager

On Lu, 01 mar 21, 10:00:26, Michel Meyers wrote:

Package: networkmanager
Severity: normal

Dear Maintainer,

I had a bond configured as described in Example 1 on: 
https://wiki.debian.org/Bonding

This morning, my server's bond interface showed down, and its slaves
kept getting removed. After some digging, I found that networkmanager
had gotten installed and a check in nmcli showed that it had taken over each of 
the slave interfaces
while listing bond0 as unmanaged.

It appears that NM ignores the "slaves eth0 eth1" directive in
/etc/network/interfaces so unless each of the interfaces is specifically
named as in Example 2, NM takes over the slaves, killing the bond.


If you want to prevent NM to "auto" manage your devices, you could use
/usr/share/doc/network-manager/examples/server.conf (copy it to 
/etc/NetworkManager/conf.d/)



Alternative, you can tell NM explicitly which devices it should ignore.
See man NetworkManager.conf → unmanaged-devices



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982737: gnome-autoar: CVE-2020-36241

[Michael Biebl]

Hi  Salvatore

Am 01.03.21 um 10:57 schrieb Salvatore Bonaccorso:

Hi,

On Sat, Feb 13, 2021 at 07:33:00PM +0100, Salvatore Bonaccorso wrote:

Source: gnome-autoar
Version: 0.2.4-2
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/gnome-autoar/-/issues/7
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.2.3-2

Hi,

The following vulnerability was published for gnome-autoar.

CVE-2020-36241[0]:
| autoar-extractor.c in GNOME gnome-autoar through 0.2.4, as used by
| GNOME Shell, Nautilus, and other software, allows Directory Traversal
| during extraction because it lacks a check of whether a file's parent
| is a symlink to a directory outside of the intended extraction
| location.

If possible this ideally should be fixed in bullseye in time.


Would it be possible to cherry-pick the fix so we have the fix
included in bullseye?



Seems reasonable. That said, I haven't really done any GNOME related 
uploads for quite a while.



Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983753: ardour: sometimes can't be stopped while playing if midi tracks are used.

[Wolfram Wagner]

Package: ardour
Version: 1:6.5.0+ds0-1
Severity: important
X-Debbugs-Cc: mrthehowlingw...@gmail.com

Dear Maintainer,

I run Ardour and record some midi tracks. After using those, the program can
get into a state that does not allow to stop the playing.

The workaround is to save the session and reload it.

This seems to be a known issue upstream and it is reported to be solved in at
least the nightly builds.

Reference: https://tracker.ardour.org/view.php?id=8490

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

   * What led up to the situation?
Running Ardour with midi tracks and recording them
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?
Thet ardour can be stopped while running.


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

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

Versions of packages ardour depends on:
ii  ardour-data   1:6.5.0+ds0-1
ii  ardour-lv2-plugins1:6.5.0+ds0-1
ii  libarchive13  3.4.3-2
ii  libasound21.2.4-1.1
ii  libatkmm-1.6-1v5  2.28.0-3
ii  libaubio5 0.4.9-4+b4
ii  libc6 2.31-9
ii  libcairo2 1.16.0-5
ii  libcairomm-1.0-1v51.12.2-4
ii  libcurl3-gnutls   7.74.0-1.1
ii  libcwiid1 0.6.91-2+b1
ii  libdbus-1-3   1.12.20-1
ii  libfftw3-single3  3.3.8-2
ii  libfluidsynth22.1.7-1
ii  libfontconfig12.13.1-4.2
ii  libgcc-s1 10.2.1-6
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.7-1
ii  libglibmm-2.4-1v5 2.64.2-2
ii  libgtk2.0-0   2.24.33-1
ii  libgtkmm-2.4-1v5  1:2.24.5-4
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  liblilv-0-0   0.24.12-2
ii  liblo70.31-1
ii  liblrdf0  0.6.1-2
ii  libltc11  1.3.1-1
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libpangoft2-1.0-0 1.46.2-3
ii  libpangomm-1.4-1v52.42.1-1
ii  libpulse0 14.1-1
ii  libqm-dsp01.7.1-4
ii  librubberband21.9.0-dmo1
ii  libsamplerate00.2.1+ds0-1
ii  libsigc++-2.0-0v5 2.10.4-2
ii  libsndfile1   1.0.31-1
ii  libstdc++610.2.1-6
ii  libsuil-0-0   1:0.10.10-dmo1
ii  libtag1v5 1.11.1+dfsg.1-3
ii  libusb-1.0-0  2:1.0.24-2
ii  libvamp-hostsdk3v51:2.10.0-dmo1
ii  libvamp-sdk2v51:2.10.0-dmo1
ii  libwebsockets16   4.0.20-2
ii  libx11-6  2:1.7.0-2
ii  libxml2   2.9.10+dfsg-6.3+b1

Versions of packages ardour recommends:
ii  ardour-video-timeline  1:6.5.0+ds0-1

ardour suggests no packages.

Bug#983749: The autopkgtest test depends are not available on s390x

[Andreas Tille]

Hi Sebastien,

On Mon, Mar 01, 2021 at 09:40:07AM +0100, Sebastien Bacher wrote:
> 
> debian/tests/control has a Depends on r-cran-lwgeom which isn't build on
> s390x anymore since
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961211 , it makes the
> s390x autopkgtests fail
> (Debian has currently no builder set, but log from Ubuntu
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/s390x/r/r-cran-sf/20210228_211230_bcd0f@/log.gz)
> 
> Either the depends should be removed or the package should also not be
> built on s390x anymore?

I hope this change

   
https://salsa.debian.org/r-pkg-team/r-cran-sf/-/commit/0134ec6c5ef2b1145e17766e4ba7c8f29ccfa2e3

fixes the situation.

> (r-cran-stars is in a similar situation)

I'll observe debci and will implement the same for r-cran-stars if it works.
Otherwise I'd consider removing r-cran-sf (-stars) for s390x.

Thanks a lot for spotting the issue

 Andreas.

-- 
http://fam-tille.de

Bug#819107: certbot: plus 1

[wim]

Package: certbot
Version: 0.31.0-1+deb10u1
Followup-For: Bug #819107

Hello,

i agree,
the ssl-cert group role should be used,
so other applications can use the certificates by granting them this group role 
ssl-cert,
instead of granting root to them (which is more insecure)

workaround:
chgrp -R ssl-cert /etc/letsencrypt/archive
chgrp -R ssl-cert /etc/letsencrypt/live
chmod -R 750 /etc/letsencrypt/archive
chmod -R 750 /etc/letsencrypt/live

hth,
Wim

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

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

Versions of packages certbot depends on:
ii  python3  3.7.3-1
ii  python3-certbot  0.31.0-1+deb10u1

certbot recommends no packages.

Versions of packages certbot suggests:
pn  python-certbot-doc  
ii  python3-certbot-apache  0.31.0-1
pn  python3-certbot-nginx   

-- no debconf information

Bug#982737: gnome-autoar: CVE-2020-36241

[Salvatore Bonaccorso]

Hi,

On Sat, Feb 13, 2021 at 07:33:00PM +0100, Salvatore Bonaccorso wrote:
> Source: gnome-autoar
> Version: 0.2.4-2
> Severity: important
> Tags: security upstream
> Forwarded: https://gitlab.gnome.org/GNOME/gnome-autoar/-/issues/7
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: found -1 0.2.3-2
> 
> Hi,
> 
> The following vulnerability was published for gnome-autoar.
> 
> CVE-2020-36241[0]:
> | autoar-extractor.c in GNOME gnome-autoar through 0.2.4, as used by
> | GNOME Shell, Nautilus, and other software, allows Directory Traversal
> | during extraction because it lacks a check of whether a file's parent
> | is a symlink to a directory outside of the intended extraction
> | location.
> 
> If possible this ideally should be fixed in bullseye in time.

Would it be possible to cherry-pick the fix so we have the fix
included in bullseye?

Regards,
Salvatore

Bug#961298: jodd: CVE-2018-21234: Potential vulnerability in JSON deserialization

[Salvatore Bonaccorso]

Hi Emmanuel,

On Sat, May 30, 2020 at 02:50:32PM +0200, Emmanuel Bourg wrote:
> Control: severity -1 important
> 
> Le 22/05/2020 à 22:51, Salvatore Bonaccorso a écrit :
> 
> > The following vulnerability was published for jodd. I'm filling it as
> > RC severity since altough one might dispute the severity for the issue
> > itself, it looks that in Debian there was ever only one upload of
> > jodd, there are no reverse (build) dependencies neither.
> > 
> > Is the package acutally of some use or planned use?
> 
> Thank you for the report Salvatore.
> 
> jodd is a new dependency of JMeter 3, I haven't finished the packaging yet.
> 
> Note that the fix for CVE-2018-21234 merely adds an optional
> whitelisting feature to check the classes being deserialized. But the
> default behavior is still the same (no check), so the charge of
> addressing the vulnerability is actually shifted to the applications
> using jodd.

Back when we lowered the severity this above was the reasoning, but
jmeter 3 is not in bullseye.

So should we remove src:yodd to at least not be included in bullseye?
According to dak this is no problem to do:

carnil@coccia:~$ dak rm --suite=testing -n -R jodd
Will remove the following packages from testing:

  jodd |  3.8.6-1.1 | source
libjodd-java |  3.8.6-1.1 | all

Maintainer: Debian Java Maintainers 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

carnil@coccia:~$

Regards,
Salvatore

Bug#977468: smuxi is marked for autoremoval from testing

[Salvatore Bonaccorso]

Hi Mirco,

On Mon, Jan 11, 2021 at 10:54:27AM +0800, Mirco Bauer wrote:
> Thanks for your email and raised concern, Jeremy.
> 
> Full accessibility in Smuxi has been a high priority for me for a long
> time.
> 
> I looked into the vulnerability of the log4net library that Smuxi depends
> on. my assessment doesn't classify a XXE for local configuration file as
> release critical. An attacker would need to have write access to the
> configuration file to exploit it. It that point a XXE is pointless, he can
> just execute curl, wget, perl, python or write something to ~/.bashrc
> directly.

I can agree here.

What I though to raise is a concern: Is log4net actively maintained? A
RC severiy might be warranted in such a case to hilight the problem.
log4net was on same version since stretch for the Debian revision and
even longer ago for the upstream version.

This was tried to explain with the comment in message 14.

> Having identified the offending code the fix is a one line change on the
> other hand. I plan to upload a fixed version of log4net in the coming days.

Do you have a chance to make an upload so that the underlying issue is
fixed at least starting in bullseye?

> To bump the version to the latest one of log4net so late in the release
> cycle I don't see as a good option. There are 2 other reverse dependencies
> that could break where I am not upstream of.

Jupp this might defintively be too late now.

Regards,
Salvatore

Bug#983750: networkmanager: NM takes over slave interfaces of bond

[Andrei POPESCU]

Control: reassign -1 network-manager

On Lu, 01 mar 21, 10:00:26, Michel Meyers wrote:
> Package: networkmanager
> Severity: normal
> 
> Dear Maintainer,
> 
> I had a bond configured as described in Example 1 on: 
> https://wiki.debian.org/Bonding
> 
> This morning, my server's bond interface showed down, and its slaves
> kept getting removed. After some digging, I found that networkmanager
> had gotten installed and a check in nmcli showed that it had taken over each 
> of the slave interfaces
> while listing bond0 as unmanaged.
> 
> It appears that NM ignores the "slaves eth0 eth1" directive in
> /etc/network/interfaces so unless each of the interfaces is specifically
> named as in Example 2, NM takes over the slaves, killing the bond.
> 
> - Michel
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (650, 'testing'), (600, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-3-amd64 (SMP w/12 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Reassigning to correct package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#981422: xdg-utils: autopkgtest failure: make: dh: No such file or directory

[Emilio Pozuelo Monfort]

On 30/01/2021 22:22, Nicholas Guriev wrote:

Hello!

On Sat, 2021-01-30 at 21:54 +0100, Paul Gevers wrote:

You recently added an autopkgtest to your package xdg-utils, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?


There are several ways to fix the failure.

1. Replace `debian/rules patch` line in a test script with `chmod +x
autotests/tty{on,off}`.

--- a/debian/tests/entry
+++ b/debian/tests/entry
@@ -13,6 +13,6 @@ fi
  BASH_XTRACEFD=1
  set -x
·
-debian/rules patch
  ./configure
+chmod +x autotests/tty{on,off}
  make autotest SHELL="${1:-/bin/sh}"

https://salsa.debian.org/freedesktop-team/xdg-utils/-/commit/9928933504932f19fb39a0f671cdc7be78aada29

2. Put the "patch" target back as it was in -3 revision, and fix arch-
independent build.

https://salsa.debian.org/freedesktop-team/xdg-utils/-/merge_requests/4/diffs?commit_id=0617f9284ae4d79b51c4ad4bc7d781e93561cb23

I still prefer the later option with the "patch" target. Because that
chmod fixes flaws of quilt and dpkg and this solutions is more
universal. I hope someone will choose to upload another one-liner fix.


You can ship the files directly in the debian.tar by adding them to 
debian/source/include-binaries, and that way you don't need to call chmod as 
their mode will be preserved. That would probably help with this autopkgtest 
patch issue.


Cheers,
Emilio

Bug#982904: mumble: CVE-2021-27229

[Salvatore Bonaccorso]

Hi

[Adding CC to security-team alias]

On Mon, Mar 01, 2021 at 08:31:54AM +, Chris Knadle wrote:
> Salvatore Bonaccorso:
> > Source: mumble
> > Version: 1.3.3-1
> > Severity: grave
> > Tags: security upstream
> > Justification: user security hole
> > Forwarded: https://github.com/mumble-voip/mumble/pull/4733
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > 
> > 
> > Hi,
> > 
> > The following vulnerability was published for mumble.
> > 
> > CVE-2021-27229[0]:
> > | Mumble before 1.3.4 allows remote code execution if a victim navigates
> > | to a crafted URL on a server list and clicks on the Open Webpage text.
> > 
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2021-27229
> >  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27229
> > [1] https://github.com/mumble-voip/mumble/pull/4733
> > [2] 
> > https://github.com/mumble-voip/mumble/commit/e59ee87abe249f345908c7d568f6879d16bfd648
> > 
> > Please adjust the affected versions in the BTS as needed.
> 
> I've reviewed the upstream git repo; there are 2 patches that are security
> related -- the other is for an OCB2 XEXStarAttack on encryption, both of
> which comprise the majority of the bugfix release of mumble 1.3.4. It seems
> to me that the best way to proceed is to upload mumble 1.3.4 as the other
> changes are incidental, and I hope that this will be acceptable during the
> soft freeze.

Yes new upstream version might still be possible in the soft-freeze,
so if that's the most sensible solution then I would go for that.

https://release.debian.org/bullseye/freeze_policy.html

For buster btw we marked in no-dsa, so if you can shedule a fix via a
point release this would be great.

Regards,
Salvatore

Bug#983751: [Pkg-utopia-maintainers] Bug#983751: dosfstools-4.2 breaks vfat formatting of entire device

[Michael Biebl]

Hi Allison,

thanks for your bug report.
I assume you do not consider this a regression in dosfstools, otherwise 
you'd probably have filed it against the dosfstools package.
The Debian udisks2 package is not shipping any downstream patches in 
that regard, so it would be best if you can raise this

dosfstools 4.2 incompatibility at
https://github.com/storaged-project/udisks

It's most likely that Debian won't be the only distro affected by this.

Seeing that dosfstools 4.2 has already migrated to testing, it doesn't 
really help to file an RC bug against it to prevent testing migration.


Regards,
Michael


Am 01.03.2021 um 10:10 schrieb Allison Karlitskaya:

Package: udisks2
Version: 2.9.1-3

A new version of dosfstools (4.2) just landed on testing, and we're
suddenly seeing a new failure in cockpit's integration testing:
specifically, attempting to create a fat filesystem on /dev/sda (the
direct device, not a partition) fails.  This works correctly with
dosfstools 4.1.

See https://github.com/cockpit-project/bots/pull/1701

This problem is not limited to cockpit, however. You can see the
problem rather directly with this reproducer:

root@debian:~# dpkg -i dosfstools_4.1-2_amd64.deb
dpkg: warning: downgrading dosfstools from 4.2-1 to 4.1-2
(Reading database ... 70287 files and directories currently installed.)
Preparing to unpack dosfstools_4.1-2_amd64.deb ...
Unpacking dosfstools (4.1-2) over (4.2-1) ...
Setting up dosfstools (4.1-2) ...
Processing triggers for man-db (2.9.4-1) ...
root@debian:~# gdbus call --system --dest org.freedesktop.UDisks2
--object-path /org/freedesktop/UDisks2/block_devices/sda --method
org.freedesktop.UDisks2.Block.Format vfat '{}'
()


but then:

root@debian:~# dpkg -i dosfstools_4.2-1_amd64.deb
(Reading database ... 70285 files and directories currently installed.)
Preparing to unpack dosfstools_4.2-1_amd64.deb ...
Unpacking dosfstools (4.2-1) over (4.1-2) ...
Setting up dosfstools (4.2-1) ...
Processing triggers for man-db (2.9.4-1) ...
root@debian:~# gdbus call --system --dest org.freedesktop.UDisks2
--object-path /org/freedesktop/UDisks2/block_devices/sda --method
org.freedesktop.UDisks2.Block.Format vfat '{}'
Error: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error
synchronizing after formatting with type `vfat': Timed out waiting for
object


note that attempting to format a partition works fine, even with the
new version:
root@debian:~# fdisk /dev/sda
[... create primary partition /dev/sda1 ... ]
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

root@debian:~# gdbus call --system --dest org.freedesktop.UDisks2
--object-path /org/freedesktop/UDisks2/block_devices/sda1 --method
org.freedesktop.UDisks2.Block.Format vfat '{}'
()

Bug#983706: gzip FTBFS on mips64el: FAIL: timestamp

[Adrian Bunk]

On Mon, Mar 01, 2021 at 10:59:20AM +0800, YunQiang Su wrote:
> Adrian Bunk  于2021年3月1日周一 上午7:13写道：
> >
> > Source: gzip
> > Version: 1.10-2
> > Severity: serious
> > Tags: ftbfs
> >
> > https://buildd.debian.org/status/fetch.php?pkg=gzip=mips64el=1.10-3=1614531854=0
> 
> It seems due to some problem of kernel or filesystem:
>...
> > On the porterbox eller, 1.10-2 fails the same as 1.10-3.
> > 1.10-3 builds in a buster chroot.

This implies that what changed is in userspace.

>...
> On x86:
> syq@vm208:~$ touch -t 196912312359.59 in
> syq@vm208:~$ ls -l in
> -rw-r--r-- 1 syq syq 0 Dec 31  1969 in
> syq@vm208:~$ cp -a in in.xx
> syq@vm208:~$ ls -l in.xx
> -rw-r--r-- 1 syq syq 0 Dec 31  1969 in.xx
> 
> On mips:
> syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ ls -l in
> -rw-r--r-- 1 syq syq 0 Dec 31  1969 in
> syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ cp -a in in.xx
> syq@m530-2:~/tmp/gzip/gzip-1.10/builddir$ ls -l in.xx
> -rw-r--r-- 1 syq syq 0 Feb  7  2106 in.xx

On eller the difference is that in buster
the "ls -l in" already shows the 2106 date:

(buster_mips64el-dchroot)bunk@eller:~$ ls -l in
-rw-r--r-- 1 bunk bunk 0 Feb  7  2106 in

(sid_mips64el-dchroot)bunk@eller:~$ ls -l in
-rw-r--r-- 1 bunk bunk 0 Dec 31  1969 in


cu
Adrian

Bug#983677: Further information

[jffry]

Thanks for the report and the log file.

For every option combination, the log file writes "Options support paper 
size 'xx'". The other possibility is never written to the log file.


I suspect the culprit is the fact that the fujitsu backend is returning 
SANE_INFO_INEXACT for many of the geometry options and gscan2pdf is 
getting confused between them.


I'll work on reproducing the problem with the test backend and then on a 
fix.


I appreciate that the bug is important for you, but I think it is 
specific to your backend, and thus only affects those gscan2pdf users 
with fujitsu scanners.

Bug#983737: open-iscsi: configuration does not finish with sysvinit-core

[Ritesh Raj Sarraf]

Dear Ryutaroh,

On Mon, 2021-03-01 at 08:48 +0900, Ryutaroh Matsumoto wrote:
> Setting up netbase (6.2) ...
> Setting up open-iscsi (2.1.3-2) ...
> Starting iSCSI initiator daemon: iscsidSetting up iSCSI targets:
> iscsiadm: No records found

I see nothing wrong here. What is the output you expect ?

iscsiadm is reporting correct that the iscisi database has no record of
any iscsi target. So the daemon has run successful but there's no
target to connect to.

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


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