Bug#869748: Cloned and assigned to aptitude

[Brian Thompson]

I cloned this bug and assigned it to the aptitude maintainers.

The bug number is #990747.

-- 
Best regards,

Brian T
B.S. Computer Science 2014 (Truman State University)
  Minor Stasitics
  Minor Chemistry
  Minor Mathematics


signature.asc
Description: PGP signature

Bug#990737: Audacity's new privacy policy may need to be addressed

[martin f krafft]

Regarding the following, written by "Paul Wise" on 2021-07-06 at 11:30 Uhr 
+0800:
IIRC the telemetry is off by default when building from source and only 
the official upstream binaries are affected.


Can confirm. I should have been explicit: check that the telemetry 
code is DFSG, or if it's not, switch to the fork.


Thanks Paul,

--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"ah, but a man's reach should exceed his grasp,

 or what's a heaven for?"
  -- robert browning


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#990508: RFS: apt-listchanges/3.24.1 [ITA] -- Proposed changes

[Brian Thompson]

David,

I'm thinking about the first line in debian/apt.conf to:

```
DPkg::Pre-Install-Pkgs { "/usr/bin/apt-listchanges --apt || test $? -lt
  10 >/dev/null 2&>1"; };$
```

adding the ">/dev/null 2&>1" in order to suppress dpkg errors in
apt-listchanges during the Pre-Install-Pkgs hook.  By doing this, the
original functionality will be preserved while at the same time piping
the misleading dpkg error message to /dev/null.  apt-listchanges will
still preserve its error message--"Aborting".

What do you think about this approach?

The alternative is to close out this bug since it is intended
functionality and leave it as-is.

-- 
Best regards,

Brian T
B.S. Computer Science 2014 (Truman State University)
  Minor Stasitics
  Minor Chemistry
  Minor Mathematics


signature.asc
Description: PGP signature

Bug#990708: [debian-mysql] Bug#990708: Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Olaf van der Spek]

On Tue, Jul 6, 2021 at 1:19 AM Otto Kekäläinen  wrote:
>
> On Mon, Jul 5, 2021 at 1:12 PM Olaf van der Spek  wrote:
> >
> > On Mon, Jul 5, 2021 at 9:24 PM Otto Kekäläinen  wrote:
> > > I wish somebody could contribute with exact steps on how to reproduce
> > > the issue. So far I've gotten some half attempts at that but they
> > > haven't been actionable for me.
> >
> > Hi Otto,
> >
> > I'd point to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988089
> > Not sure why it's not reproducible with those steps.
>
> I don't see *the* steps, but I see a lot of messages about many
> different steps. If you have them, why not copy-paste the steps here
> in email so I can copy-paste them into a Debian Buster Docker
> container and run the upgrade to isolate the regression?

Docker might be the problem, I'd try a real VM.


I do have this in a VM so I think we can easily repro this.

// Fresh VM install from debian-10.9.0-i386-netinst.iso
# history
1  visudo
2  rm /etc/motd
3  poweroff
4  apt install mariadb-server
5  dpkg -l|grep mariadb
6  sed -i 's/buster/bullseye/g' /etc/apt/sources.list
7  apt update
8  apt upgrade
9  apt dist-upgrade // output below
   10  dpkg -l|grep mariadb // output below
   11  apt dist-upgrade // output below
   12  history

-- 
Olaf

Bug#990732: iwlwifi fails to work after hibernation with linux-4.19.0-17-amd64

[Andrei POPESCU]

Control: reassign -1 src:linux 4.19.0-17

Reassigning to correct source package, full quote below for Maintainers' 
convenience.

Kind regards,
Andrei

On Lu, 05 iul 21, 20:44:58, Robert Scott wrote:
> Package: li1nux
> Version: 4.19.0-17
> 
> tl;dr: I have a feeling this is https://bugzilla.redhat.com/show_bug.cgi?
> id=1656233
> 
> After resuming a buster system with linux-4.19.0-17 on a thinkpad x220 the 
> intel 6205 wifi fails to work, with the below dmesg warnings.
> 
> Hopefully this _is_ just the same bug as linked, which would suggest the 
> solution is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
> linux.git/commit/drivers/pci/probe.c?
> id=10ecc818ea7319b5d0d2b4e1aa6a77323e776f76
> 
> [11218.145442] iwlwifi :03:00.0: Error, can not clear persistence bit
> [11218.145448] iwlwifi :03:00.0: Failed to start HW: -1
> [11218.145454] iwlwifi :03:00.0: Unable to initialize device.
> [11218.148066] iwlwifi :03:00.0: Error, can not clear persistence bit
> [11218.148072] iwlwifi :03:00.0: Failed to start HW: -1
> [11218.148079] iwlwifi :03:00.0: Unable to initialize device.
> [11315.009011] [ cut here ]
> [11315.009014] Timeout waiting for hardware access (CSR_GP_CNTRL 0x)
> [11315.009051] WARNING: CPU: 0 PID: 8807 at drivers/net/wireless/intel/
> iwlwifi/pcie/trans.c:2033 iwl_trans_pcie_grab_nic_access+0x1e8/0x220 [iwlwifi]
> [11315.009052] Modules linked in: rfcomm bnep btusb btrtl btbcm btintel 
> bluetooth drbg ansi_cprng ecdh_generic hid_generic usbhid hid nls_ascii 
> nls_cp437 vfat fat uas usb_storage ctr ccm tun intel_rapl arc4 
> x86_pkg_temp_thermal intel_powerclamp iwldvm(-) coretemp snd_hda_codec_hdmi 
> mei_wdt kvm_intel mac80211 uvcvideo snd_hda_codec_conexant videobuf2_vmalloc 
> videobuf2_memops snd_hda_codec_generic videobuf2_v4l2 joydev kvm 
> videobuf2_common irqbypass snd_hda_intel intel_cstate iwlwifi snd_hda_codec 
> sg 
> intel_uncore videodev wmi_bmof intel_rapl_perf serio_raw snd_hda_core media 
> pcspkr snd_hwdep cfg80211 snd_pcm thinkpad_acpi snd_timer mei_me nvram 
> iTCO_wdt iTCO_vendor_support mei snd soundcore pcc_cpufreq rfkill ac battery 
> evdev nf_log_ipv6 ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables ip6t_rt 
> nf_log_ipv4
> [11315.009080]  nf_log_common ipt_REJECT nf_reject_ipv4 xt_LOG nft_limit 
> xt_limit xt_addrtype xt_tcpudp xt_conntrack nft_compat nft_counter 
> nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat 
> nf_conntrack_ftp nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c 
> nf_tables nfnetlink parport_pc ppdev sunrpc lp parport ip_tables x_tables 
> autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb twofish_generic 
> twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common xts 
> algif_skcipher af_alg dm_crypt dm_mod sd_mod crct10dif_pclmul crc32_pclmul 
> crc32c_intel ghash_clmulni_intel pcbc i915 ahci aesni_intel libahci libata 
> sdhci_pci aes_x86_64 crypto_simd cryptd cqhci glue_helper scsi_mod psmouse 
> i2c_algo_bit sdhci drm_kms_helper mmc_core ehci_pci ehci_hcd i2c_i801 lpc_ich 
> drm mfd_core
> [11315.009108]  usbcore e1000e usb_common thermal wmi video button
> [11315.009114] CPU: 0 PID: 8807 Comm: rmmod Tainted: GW 
> 4.19.0-17-amd64 #1 Debian 4.19.194-1
> [11315.009115] Hardware name: LENOVO 4290A48/4290A48, BIOS 8DET49WW (1.19 ) 
> 07/01/2011
> [11315.009123] RIP: 0010:iwl_trans_pcie_grab_nic_access+0x1e8/0x220 [iwlwifi]
> [11315.009126] Code: e6 c3 49 8d 56 08 bf 00 02 00 00 e8 e2 36 dd c2 e9 33 ff 
> ff ff 89 c6 48 c7 c7 b0 b5 ed c0 c6 05 e1 45 02 00 01 e8 01 0d 44 c3 <0f> 0b 
> e9 ee fe ff ff 48 8b 7b 30 48 c7 c1 18 b6 ed c0 31 d2 31 f6
> [11315.009127] RSP: 0018:a81cc394fdc8 EFLAGS: 00010082
> [11315.009129] RAX:  RBX: 9a9e13830018 RCX: 
> 0006
> [11315.009130] RDX: 0007 RSI: 0092 RDI: 
> 9a9e160166b0
> [11315.009131] RBP:  R08: 05d9 R09: 
> 0004
> [11315.009132] R10:  R11: 0001 R12: 
> 9a9e1383a258
> [11315.009133] R13: a81cc394fdf8 R14:  R15: 
> 
> [11315.009135] FS:  7f3ddc3ab480() GS:9a9e1600() knlGS:
> 
> [11315.009136] CS:  0010 DS:  ES:  CR0: 80050033
> [11315.009137] CR2: 5573c3c42750 CR3: 00011e5f4003 CR4: 
> 000606f0
> [11315.009138] Call Trace:
> [11315.009149]  iwl_write_prph+0x37/0x90 [iwlwifi]
> [11315.009156]  iwl_pcie_apm_init+0x1b2/0x210 [iwlwifi]
> [11315.009164]  iwl_pcie_apm_stop+0x324/0x360 [iwlwifi]
> [11315.009171]  iwl_trans_pcie_op_mode_leave+0x86/0x150 [iwlwifi]
> [11315.009177]  iwl_op_mode_dvm_stop+0x8b/0xb0 [iwldvm]
> [11315.009184]  _iwl_op_mode_stop.isra.8+0x27/0x40 [iwlwifi]
> [11315.009190]  iwl_opmode_deregister+0x5e/0xb0 [iwlwifi]
> [11315.009196]  iwl_exit+0xc/0x486 [iwldvm]
> [11315.009200]  __x64_sys_delete_module+0x190/0x2e0
> [11315.009204]  do

Bug#932010: Some progress

[za3k]

I also encountered this issue as part of upgrading from debian 9 
(stretch) to debian 10 (buster).


At first, like the first reporter, I thought deleting and re-generating 
/etc/nsd/nsd_server.pem persists the problem. However, if I also delete 
/etc/nsd/nsd_server.key (which nsd-control-setup uses as a sort of 
'cache') I can't reproduce. I suspect the first reporter hit the same 
error. This means that it's probably the natural thing to do--can the 
error message be improved to mention how to fix it?


I can't explain why the initial problem occurs, but I have some idea why 
your reproduction didn't work.


My key was exactly 1.5K RSA bits, according to the output of 'sudo 
openssl x509 -text -noout -in /etc/nsd/nsd_server.pem' -- not 3K bits. 
The size switched from 1.5K to 3K in commit 
cc589ae757cb34b5827faa9be92f8cc9a46877bd, which is part of nsd v4.1.2 
RC2. I'm not sure how to check the _earliest_ version of a package in a 
particular debian release, but at least the latest stretch version 
includes the commit--meaning it probably can't be used to reproduce. To 
reproduce you'll probably need to start from at least debian 8 (jessie), 
which is before the key size change.

Bug#990627: python3-torchaudio: torchaudio import aborts

[Jochen Sprickerhof]

Control: severity -1 minor
Control: tags -1 - moreinfo + wontfix

* John O'Hagan  [2021-07-06 14:19]:

and that you don't have any additional files installed (like torch or
tensorflow from pip), also check

$HOME/.local/lib/python3*/site-packages



This was the problem, thank you. torch 1.9 was pulled into that
directory by torch.hub.load('ultralytics/yolov5', ). Renaming or
removing the torch subdirectory allows torchaudio to import normally.


Sounds like the upstream version is not compatible with the rest of your 
system.



The requirements file from the ultralytics repo only specifies torch >=
1.7, which is available in my distro, so I'm not sure why it pulls in
1.9.

Is this still to be regarded as a (perhaps different) bug?


I don't know enough about torchaudio to say how much this influences the 
usage of it but I can imagine that others run into the same problem. 
Given that you would need to load a version from elsewhere I mark this 
as minor and wontfix, Feel free to change if you think this is not 
appropriate.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#990746: /usr/bin/thawab-gtk: thawab fails to start.

[Awtul]

Package: thawab
Version: 4.1-2
Severity: important
File: /usr/bin/thawab-gtk

Dear Maintainer,

'thawab' fails to start. I get this when I execute "thawab-gtk" from cmdline:

"Traceback (most recent call last):
  File "/usr/bin/thawab-gtk", line 5, in 
from Thawab.gtkUi import main
  File "/usr/share/thawab/Thawab/gtkUi.py", line 34, in 
from Thawab.webApp import webApp, get_theme_dirs
  File "/usr/share/thawab/Thawab/webApp.py", line 25, in 
from cgi import escape # for html escaping
ImportError: cannot import name 'escape' from 'cgi' (/usr/lib/python3.9/cgi.py)"



Thanks for your work :)

Awal


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

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

Versions of packages thawab depends on:
ii  gir1.2-gtk-3.0  3.24.24-4
ii  gir1.2-webkit2-4.0  2.32.1-2
ii  mdbtools0.9.1-1
ii  python3 3.9.2-3
ii  python3-gi  3.38.0-2
ii  python3-okasha  0.2.4-4
ii  python3-othman  0.6.0-2
ii  python3-paste   3.5.0+dfsg1-1
ii  python3-whoosh  2.7.4+git6-g9134ad92-5

Versions of packages thawab recommends:
pn  islamic-menus  

thawab suggests no packages.

-- no debconf information

Bug#990745: better nvme device detection in cron scripts

[M. Zhou]

Source: zfs-linux
Version: 2.0.3-9
Severity: normal
Tags: patch

Credit: Miao Wang

get_transp(){
local dev="$1"
local par_dev="$dev"
local pd
while true; do
  pd=$(lsblk -dnr -o PKNAME "$par_dev")
  if [ "$?" -ne 0 ]; then
return $?
  fi
  if [ -z "$pd" ]; then
break
  else
par_dev="/dev/$pd"
  fi
done
lsblk -dnr -o TRAN "$par_dev"
}

Bug#990744: gnome-clocks: weekdays label for spanish shows wrong names on setting new alarm

[Andres Z]

Package: gnome-clocks
Version: 3.38.0-1
Severity: normal
X-Debbugs-Cc: sazamor...@gmail.com

Dear Maintainer,

Initial acronyms for the days of the week shows (for spanish):

L M X M V S S

instead of:

L M X J V S D

which correspond to:

L|unes
M|artes
X|iercoles
J|ueves
V|iernes
S|abado
D|omingo


Thank you in advance.


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

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

Versions of packages gnome-clocks depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  geoclue-2.0  2.5.7-3
ii  libc62.31-12
ii  libgeoclue-2-0   2.5.7-3
ii  libgeocode-glib0 3.26.2-2
ii  libglib2.0-0 2.66.8-1
ii  libgnome-desktop-3-193.38.5-2
ii  libgsound0   1.0.2-5
ii  libgtk-3-0   3.24.24-4
ii  libgweather-3-16 3.36.1-3
ii  libhandy-1-0 1.0.3-2

gnome-clocks recommends no packages.

gnome-clocks suggests no packages.

Bug#990737: Audacity's new privacy policy may need to be addressed

[Paul Wise]

On Tue, 6 Jul 2021 11:47:40 +1200 martin f krafft wrote:

> This may need addressing in the Debian packaging, i.e. in addition 
> to ensuring that the data collection is off by default, maybe the 
> whole tracking code needs to be removed?

IIRC the telemetry is off by default when building from source and only
the official upstream binaries are affected.

There is a fork that removes the telemetry code:

https://github.com/temporary-audacity/audacity

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#990581: nomad: CVE-2021-32575

[Dmitry Smirnov]

Dear Peter,

On Tuesday, 6 July 2021 6:54:14 AM AEST Peter Pentchev wrote:
> First of all, thanks for your work on nomad and Debian in general!

Thank you for your kind words and for your help.


> Dmitry, what do you think about my attempt to backport the upstream
> patch for CVE-2021-32575 to the Debian package of nomad?
> The upstream patch is at:
>  
> https://github.com/hashicorp/nomad/commit/003d68fe6df652b172bc68beabd11a25
> fd7e1b58
> 
> My proposed update to the Debian package is in my forked Salsa repo:
> 
>   https://salsa.debian.org/roam/nomad/-/commits/roam-CVE-2021-32575/
> 
>   git clone -b roam-CVE-2021-32575 https://salsa.debian.org/roam/nomad.git

Unfortunately I can not have a look right now...


> If you have no objections, I could push these commits to the team repo,
> upload to unstable, and send an unblock request to the release team.

Go for it. It would be great if you could do all this, if you think it
is worth the effort. Thank you.

Frankly, at this point I think we can allow Nomad to be dropped from
"testing". Without Podman support, Nomad is not as useful as I expected...

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Lies are the social equivalent of toxic waste: Everyone is potentially
harmed by their spread.
 -- Sam Harris

---

All-cause mortality during COVID-19: No plague and a likely signature of
mass homicide by government response. D. G. Rancourt, June 2020.
 -- https://deb.li/37mn4

https://www.researchgate.net/publication/341832637_All-cause_mortality_during_COVID-19_No_plague_and_a_likely_signature_of_mass_homicide_by_government_response


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

Bug#990214: unblock: dovecot-fts-xapian/1.4.9a-1

[Joe Nahmias]

Control: tags -1 - moreinfo

Hello,

On Sun, Jul 04, 2021 at 10:17:31PM +0200, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo confirmed
> 
> Assuming that the upload happens soon, please go ahead and remove the
> moreinfo tag once the new version is available in unstable.

Thanks for reviewing. I've added one additional patch cherry-picked from
upstream to fix a crash when reindexing, see attached. Uploaded to
unstable.

--Joe

Bug#990743: unblock: ncbi-entrez-direct/14.6.20210224+dfsg-4

[Aaron M. Ucko]

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

[ Introduction / Reason ]
I would like to issue a new ncbi-entrez-direct upload (patch attached)
adjusting two wrapper scripts to account fully for their wrappees'
repertoire of options, or at minimum acknowledging that NCBI's efetch
accepts -docsum as shorthand for -format docsum for the sake of
ncbi-blast+'s get_species_taxids script.
(https://bugs.debian.org/990741 has more details.)

[ Impact ]
Without this patch, on systems with ncbi-entrez-direct and acedb-other
both installed, some legitimate usage of efetch intended to pick up
NCBI's version will yield warnings; likewise for einfo with epub-utils
installed alongside ncbi-entrez-direct.  (In some corner cases, these
wrapper scripts might even wind up running the wrong efetch or einfo,
though they should at least warn about doing so.)

[ Tests ]
#990741 has an example of the current misbehavior; with this patch in
place, the only diagnostics should be the single WARNING: line from
NCBI's efetch itself, which is entirely safe to disregard.

[ Risks ]
AFAICT, this patch should not affect any command lines intended for
acedb-other's efetch or epub-utils's einfo, but if you want to be
extra cautious, I can limit it to adding -docsum for efetch for now.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
I am holding off on uploading anything pending feedback on whether to
go forward with the full patch or a scaled-down version that only adds
an acknowledgment of the -docsum shorthand.

Thanks!

unblock ncbi-entrez-direct/14.6.20210224+dfsg-4
diff --git a/debian/changelog b/debian/changelog
index f8b2667..5bb4c46 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+ncbi-entrez-direct (14.6.20210224+dfsg-4) UNRELEASED; urgency=medium
+
+  * debian/{efetch,einfo}: Refresh %ncbi_supported, taking care to include
+undocumented options.  (In particular, ncbi-blast+'s
+get_species_taxids uses efetch's undocumented -docsum shorthand.)
+(Closes: #990741.)
+
+ -- Aaron M. Ucko   Mon, 05 Jul 2021 22:12:10 -0400
+
 ncbi-entrez-direct (14.6.20210224+dfsg-3) unstable; urgency=medium
 
   * debian/man/eblast.1: Extend deprecation notice to eblast.
diff --git a/debian/efetch b/debian/efetch
index 603bdaa..79a2726 100755
--- a/debian/efetch
+++ b/debian/efetch
@@ -28,6 +28,7 @@ my %ncbi_supported = (
 'id'  => 's',
 'input'   => 's',
 'format'  => 's',
+'docsum'  => undef,
 'style'   => 's',
 'mode'=> 's',
 'seq_start'   => 'i',
@@ -38,10 +39,14 @@ my %ncbi_supported = (
 'complexity'  => 'i',
 'chr_start'   => 'i',
 'chr_stop'=> 'i',
+'showgi'  => undef,
 'extend'  => 'i',
 'extrafeat'   => 'i',
+'showgaps'=> undef,
+'show-gaps'   => undef,
 'start'   => 'i',
 'stop'=> 'i',
+'api_key' => 's',
 'raw' => undef,
 'json'=> undef,
 'nogi'=> undef,
@@ -49,14 +54,26 @@ my %ncbi_supported = (
 'tool'=> 's',
 'pipe'=> undef,
 'help'=> undef,
+'example' => undef,
+'examples'=> undef,
+'error'   => undef,
+'errors'  => undef,
 'silent'  => undef,
 'verbose' => undef,
 'debug'   => undef,
+'oldmode' => undef,
+'newmode' => undef,
 'log' => undef,
+'compact' => undef,
 'http'=> 's',
 'https'   => 's',
 'alias'   => 's',
-'base'=> 's');
+'base'=> 's',
+'web' => 's',
+'step'=> 'i',
+'label'   => 's',
+'timer'   => undef,
+'version' => undef);
 
 my %ncbi_abbrev = ();
 {
diff --git a/debian/einfo b/debian/einfo
index 570c088..a4d202a 100755
--- a/debian/einfo
+++ b/debian/einfo
@@ -26,19 +26,36 @@ my $epub_keys  = 't';
 my %ncbi_supported = (
 'db'  => 's',
 'dbs' => undef,
+'field'   => undef,
 'fields'  => undef,
+'link'=> undef,
 'links'   => undef,
+'test'=> undef,
+'tests'   => undef,
+'api_key' => undef,
 'email'   => 's',
 'tool'=> 's',
+'repeat'  => undef,
+'repeats' => undef,
+'error'   => undef,
+'errors'  => undef,
 'help'=> undef,
 'silent'  => undef,
 'verbose' => undef,
 'debug'   => undef,
+'oldmode' => undef,
+'newmode' => undef,
 'log' => undef,
+'compact' => undef,
 'http'=> 's',
 'https'   => 's',
 'alias'   => 's',
-'base'=> 's');
+'base'=> 's',
+'web' => 's',
+'step'=> 'i',
+'label'   => 's',
+'timer'   => und

Bug#990742: fcitx -> fcitx5 in IM_CONFIG_PREFERRED_RULE variable

[Gunnar Hjalmarsson]

Package: im-config
Version: 0.47-1
X-Debbugs-Cc: jianfen...@ubuntukylin.com

It struck me that

IM_CONFIG_PREFERRED_RULE="zh_CN,fcitx:zh_TW,fcitx:zh_HK,fcitx:zh_SG,fcitx"

in /etc/default/im-config probably should be changed to

IM_CONFIG_PREFERRED_RULE="zh_CN,fcitx5:zh_TW,fcitx5:zh_HK,fcitx5:zh_SG,fcitx5"

Not sure how urgent it is. I know that Ubuntu Kylin will ship both 
fcitx4 and fcitx5 in version 21.10, but want to keep using fcitx4 by 
default (and switch to fcitx5 in 22.04). So with my Ubuntu hat on I'd 
prefer to wait a few months.


If the change is considered more urgent in Debian, we could change it 
only in the Debian version of /etc/default/im-config to start with.


--
Gunnar

Bug#990741: ncbi-entrez-direct: efetch and einfo wrappers warn about some supported options

[Aaron M. Ucko]

Package: ncbi-entrez-direct
Version: 14.6.20210224+dfsg-3+b2
Severity: serious
Justification: maintainer prerogative

In the course of checking whether
https://bugs.launchpad.net/ubuntu/+source/ncbi-blast+/+bug/1934402
affects ncbi-blast+ in testing and unstable, I observed -- *only* -- a
different issue: the efetch wrapper Debian deploys to avoid needing a
formal conflict with acedb-other doesn't account for NCBI efetch's
undocumented -docsum shorthand, which get_species_taxids uses.  The
wrapper's heuristics conclude that the NCBI implementation is probably
in order, but it's a close call, and somewhat noisy:

  $ get_species_taxids -n 'Homo sapiens'
  Launching NCBI efetch rather than AceDB efetch despite misgivings,
  due to more severe misgivings about AceDB syntax compatibility.  If you
  meant to run AceDB efetch, please explicitly run it via efetch.acedb.
  AceDB misgivings (1 major, 2 minor):
-mode (major)
-db (minor)
taxonomy json (minor)
  NCBI misgivings (1 major, 0 minor):
-docsum (major)
  WARNING: Redundant -db 'taxonomy' argument
   
  Taxid : 9606 
   rank : species 
   division : primates 
   scientific name : Homo sapiens 
   common name : human 
  
  1 matche(s) found.

I could certainly patch get_species_taxids, but would prefer to adjust
ncbi-entrez-direct's efetch wrapper, since -docsum is legitimate, just
undocumented.  A full sweep revealed some other gaps in both this
wrapper and the analogous einfo wrapper, mostly around other
undocumented options.  AFAICT, these arguments are all at *best*
unlikely for these commands' homonyms; for instance, -docsum could
only correspond to

   -d  Specify database file (avoid this)

with an inline value "ocsum"(!)

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

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

Versions of packages ncbi-entrez-direct depends on:
ii  curl7.74.0-1.3
ii  libc6   2.31-12
ii  libwww-perl 6.52-1
ii  libxml-simple-perl  2.25-1
ii  perl5.32.1-4
ii  wget1.21-1+b1

ncbi-entrez-direct recommends no packages.

Versions of packages ncbi-entrez-direct suggests:
ii  curl   7.74.0-1.3
ii  libxml2-utils  2.9.10+dfsg-6.7
ii  python33.9.2-3

-- no debconf information

Bug#990740: esix package consumes 100% cpu

[Stewart C. Russell]

Package: esix

Version: 1-3

Severity: normal

X-Debbugs-Cc: scr...@gmail.com



Dear Maintainer,



Expected results:



1. Launch esix in terminal

2. Interact with ESI-X language REPL



Actual results:



1. Launch esix in terminal

2. Interact with ESI-X language REPL

3. Computer CPU usage climbs to 100% as REPL busy-waits for input.



Suggested bug fix:



Modify /usr/share/esix/esix.cfg from:



load esix.bin

run 5400



to



set cpu idle

load esix.bin

run 5400



This will cause the simh PDP-8 emulator that runs the ESI-X binary to
throttle down when it detects a busy loop. It may take 25-30 seconds for
CPU usage to calm down.


Previously reported to Ubuntu bugs as
https://bugs.launchpad.net/debian/+source/esix/+bug/1660456
but this issue is present in the upstream Debian esix.cfg file



-- System Information:

Debian Release: bullseye/sid

  APT prefers hirsute-updates

  APT policy: (500, 'hirsute-updates'), (500, 'hirsute-security'), (500,
'hirsute')

Architecture: amd64 (x86_64)

Foreign Architectures: i386



Kernel: Linux 5.11.0-22-generic (SMP w/8 CPU threads)

Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE

Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en_GB:en

Shell: /bin/sh linked to /usr/bin/dash

Init: systemd (via /run/systemd/system)

LSM: AppArmor: enabled

Bug#990735: [Ticket ID: 737032] Bug#990735: Acknowledgement (mirror submission for mirror.mia.velocihost.net)

[VelociHOST Support]

990...@bugs.debian.org,

Thank you for contacting our support team. A support ticket has now been opened 
for your request. You will be notified when a response is made by email. The 
details of your ticket are shown below.

Subject: Bug#990735: Acknowledgement (mirror submission for 
mirror.mia.velocihost.net)
Priority: Medium
Status: Open

You can view the ticket at any time at 
https://my.velocihost.net/viewticket.php?tid=737032&c=Pe9pH3LN

---
VelociHOST
Enterprise Cloud Hosting Solutions
Miami - New York - Data Centers
supp...@velocihost.net | www.velocihost.net

Bug#990735: mirror submission for mirror.mia.velocihost.net

[Support team]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.mia.velocihost.net
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Maintainer: Support team 
Country: US United States
Location: Miami, FL 
Sponsor: VelociHOST https://www.velocihost.net/
Comment: Hosted by VelociHOST Bare Metal Servers. Located in Miami, FL - Full 
native IPv6 and IPv4 support. Syncs every 6 hours.




Trace Url: http://mirror.mia.velocihost.net/debian/project/trace/
Trace Url: 
http://mirror.mia.velocihost.net/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.mia.velocihost.net/debian/project/trace/mirror.mia.velocihost.net

Bug#982139: q2-quality-control: test skipped on ppc64el

[Étienne Mollier]

Control: reassign -1 vsearch
Control: retitle -1 vsearch: breaks q2-quality-control test suite on ppc64el
Control: affects -1 + q2-quality-control

Greetings,

The issue below:
>   >   self.assertEqual(sorted(obs.index), sorted(
>   _dnafastaformats_to_series(self.query_seqs_short).index))
>   E   AssertionError: Lists differ: ['783', '867', '886'] 
> != ['750', '768', '783', '867', '886']
>   E   
>   E   First differing element 0:
>   E   '783'
>   E   '750'
>   E   
>   E   Second list contains 2 additional elements.
>   E   First extra element 3:
>   E   '867'
>   E   
>   E   - ['783', '867', '886']
>   E   + ['750', '768', '783', '867', '886']
>   E   ?  ++
>   
looks to be actually caused by vsearch:
>   Command: vsearch --usearch_global 
> /tmp/autopkgtest-lxc.p_pskvmx/downtmp/autopkgtest_tmp/q2_quality_control/tests/data/query-sequences-short.fasta
>  --id 0.97 --strand both --maxaccepts 1 --maxrejects 0 --db 
> /tmp/autopkgtest-lxc.p_pskvmx/downtmp/autopkgtest_tmp/q2_quality_control/tests/data/bacterial-ref-sequences.fasta
>  --threads 1 --userfields query+target+ql+qlo+qhi --userout /tmp/tmpbvtklulf
>   
>   - Captured stderr call 
> -
[…]
>   Matching unique query sequences: 3 of 5 (60.00%)

Extracting q2-quality-control test data, to run them against
standalone vsearch raises discrepancies in vsearch results:

  - on amd64:

$ vsearch \
--usearch_global query-sequences-short.fasta
--id 0.97 --strand both --maxaccepts 1 \
--maxrejects 0 \
--db bacterial-ref-sequences.fasta --threads 1 \
--userfields query+target+ql+qlo+qhi \
--userout output.amd64
[…]
Matching unique query sequences: 5 of 5 (100.00%)
$ cat output.amd64
886 886 15  1   15
867 867 15  1   15
783 783 15  1   15
768 768 15  1   15
750 750 15  1   15

  - on ppc64el:

$ vsearch \
--usearch_global query-sequences-short.fasta
--id 0.97 --strand both --maxaccepts 1 \
--maxrejects 0 \
--db bacterial-ref-sequences.fasta --threads 1 \
--userfields query+target+ql+qlo+qhi \
--userout output.ppc64el
[…]
Matching unique query sequences: 3 of 5 (60.00%)
$ cat output.ppc64el
886 886 15  1   15
867 867 15  1   15
783 783 15  1   15

I reassign the bug accordingly.

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/4, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#990739: buster-pu: package iptables-netflow/2.3-5+deb10u1

[Axel Beckert]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org, car...@debian.org

Hi,

an API change in the Linux kernel 4.19.194-1 uploaded with the Buster
10.10 stable minor update caused a regression in
iptables-netflow-dkms/2.3-5 built from the iptables-netflow source
package. The upstream API change happened in 4.19.191:

- modules: mark ref_module static

Relevant bug reports:

* Debian: https://bugs.debian.org/990123
* Upstream: https://github.com/aabc/ipt-netflow/issues/177

I would like to upload an updated package of iptables-netflow to
buster-proposed-updates which cherry-picks two upstream patches (see
below under [Changes] for details) which fix the issue initially and
then also for updated stable kernel lines like those in Buster.

[ Reason ]

Linux upstream has been backporting a change from kernel 5.9 to stable
kernel releases which makes sure that kernel modules which claim to be
GPL licensed and use _GPL exports, can no more depend on symbols from
non-GPL modules. This is has been solved by marking a function static,
i.e. no more being usable by kernel modules.

The Debian kernel team stated in  that it's unlikely that Linux kernel
upstream will revert the patches and they also stated that it's
unlikely that Debian's linux kernel will divert from upstream at this
point.

Context about this issue:

https://lore.kernel.org/lkml/20200730061027.29472-1-...@lst.de/
https://lore.kernel.org/stable/ymxnxqzcp0g1f...@kroah.com/

(Thanks to Salvatore Bonaccorso of the Debian kernel team for these
links and further reviews and suggestions on this issue!)

[ Impact ]

The package is currently no more working after a reboot into a current
Buster 10.10 kernel as the DKMS kernel module fails to build with
current kernel headers (see #990123). It is currently still usable
with kernels before 4.19.194-1.

It will also no more compile with non-debian kernels of the stable
kernel lines 4.14 (version 4.14.233 and above) and 5.4 (version 5.4.11
and above). (Compilation of kernels above 5.9rc1 never worked with the
version in Buster.)

[ Tests ]

The .deb as generated when applying the debdiff below runs in
production for about 1.5 weeks on two of my netflow generating
servers, first with kernel version 4.19.194-1, later with kernel
version 4.19.194-2, both with ABI 4.19.0-17-amd64.

I also tried installing it (aka compiling the DKMS module) on a box
which was still running linux-image-4.19.0-12-amd64 (package version
4.19.152-1 + headers) from October 2020. Since also further Debian
kernels were installed, I also successfully tested its compilation
against linux-{image,headers}-4.19.0-14-amd64 (package version
4.19.171-2).

No issues have been observed so far. Functionality is as expected.

[ Risks and Expected Regressions ]

The upstream patch https://github.com/aabc/ipt-netflow/commit/352cdb28
mostly removes CPP "#if LINUX_VERSION_CODE >= KERNEL_VERSION(…)"
blocks containing legacy code not needed for more modern kernels and
enables the modern code also for older releases.

As I read that upstream commit, now this kernel module will no more
compile with (vanilla) kernels before 2.6.35 which seems to have
introduced the functionality which is now used instead of the function
made static in 5.9.0, 4.19.191 and other recent stable kernel
releases. (I though didn't test any other kernels than those in Debian
Buster. For older kernels than 4.19.194-1 I just tested if the DKMS
module still compiles, not if it still works as before.)

Since upstream's approach also compiled against older stable kernels
than those affected by #990123 I took upstream's approach instead of
making those "#if LINUX_VERSION_CODE >= KERNEL_VERSION(…)" checks even
more complex by adding further constraints to list all the updated
stable kernels mentioned above.

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

Footnotes: * = Patch 1 (cherry-picked adfc6318) is already included in
   Debian Unstable and Bullseye as a cherry-picked patch
   from the currently most recent upstream 2.6 release. It
   fixes the same issue for kernels 5.9 and above since
   Debian package version 2.5.1-1, but its CPP
   conditionals were not prepared for that "mark
   ref_module static" change being backported to stable
   kernel lines.

   Patch 2 (cherry-picked 352cdb28) is not included in
   Debian Unstable and Bullseye as it is only necessary
   for kernels older than those in Unstable/Bullseye which
   got that change from 5.9 backported.

[ Changes ]

The proposed packages fixes #990123 by cherry-picking two upstream
commits in the same part of the code (I didn't want to

Bug#990706: [Pkg-net-snmp-devel] Bug#990706: libsnmp-dev shall depend/recommend libsnmp-perl because mib2c requires it

[Craig Small]

On Mon, 5 Jul 2021 at 19:15, Jan Gorski  wrote:

> libsnmp-dev contains mib2c script which gives following output if
> libsnmp-perl
> package is not installed:
>
[...]

> After installing libsnmp-perl mib2c seems to start up properly (save for
> some
> uninitialized variables warnings in SNMP.pm which are probaly upstream
> issue)
>
> Could you consider adding appropriate dependency/reccomendation to the
> libsnmp-dev package?
>

Hi Jan,
  I had a look at this. As you suggest we could either go as a dependency
or a recommendation.

A dependency would mean mib2c "just works" but it also means that anyone
using libsnmp-dev will pull in the Perl module and any other dependencies
that it needs, even if you never use mib2c.  That really isn't ideal for
most users.

However, a recommendation is a good idea. It could be installed but if you
don't want Perl then your system will still allow it.  I'll also look into
patching mib2c so the error message is more specific about Debian rather
than saying download something from the net-snmp website.

 - Craig

Bug#990738: ITP: xir -- Xilinx Intermediate Representation (XIR) for deep learning algorithms

[Nobuhiro Iwamatsu]

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

* Package name: xir
  Version : 1.3.2
  Upstream Author : Jian Weng 
* URL : https://github.com/Xilinx/Vitis-AI.git
* License : Apache-2.0
  Programming Lang: C++
  Description : Xilinx Intermediate Representation (XIR) for deep learning 
algorithms

 Xilinx Intermediate Representation (XIR) is a graph based
 intermediate representation of the AI algorithms which is well
 designed for compilation and efficient deployment of the
 Domain-specific Processing Unit (DPU) on the FPGA platform.
 Advanced users can apply Whole Application Acceleration to benefit from
 the power of FPGA by extending the XIR to support customized IP in
 Vitis AI flow.

Bug#990737: Audacity's new privacy policy may need to be addressed

[martin f krafft]

Package: audacity
Severity: important
Tags: upstream

Not yet in the archive I don't think, but flagging this here:

https://www.audacityteam.org/about/desktop-privacy-notice/

This may need addressing in the Debian packaging, i.e. in addition 
to ensuring that the data collection is off by default, maybe the 
whole tracking code needs to be removed?

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

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

Versions of packages audacity depends on:
ii  audacity-data 2.4.2~dfsg0-4
ii  libavcodec58  7:4.3.2-0+deb11u1
ii  libavformat58 7:4.3.2-0+deb11u1
ii  libavutil56   7:4.3.2-0+deb11u1
ii  libc6 2.31-12
ii  libexpat1 2.2.10-2
ii  libflac++6v5  1.3.3-2
ii  libflac8  1.3.3-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.8-1
ii  libgtk-3-03.24.24-4
ii  libid3tag00.15.1b-14
ii  liblilv-0-0   0.24.12-2
ii  libmad0   0.15.1b-10
ii  libogg0   1.3.4-0.1
ii  libportaudio2 19.6.0-1.1
ii  libportsmf0   0.1~svn20101010-5
ii  libsndfile1   1.0.31-1
ii  libsoundtouch12.2+ds1-2
ii  libsoxr0  0.1.3-4
ii  libstdc++610.2.1-6
ii  libsuil-0-0   0.10.10-1
ii  libtwolame0   0.4.0-2
ii  libvamp-hostsdk3v52.10.0-1
ii  libvorbis0a   1.3.7-1
ii  libvorbisenc2 1.3.7-1
ii  libvorbisfile31.3.7-1
ii  libwxbase3.0-0v5  3.0.5.1+dfsg-2
ii  libwxgtk3.0-gtk3-0v5  3.0.5.1+dfsg-2

audacity recommends no packages.

Versions of packages audacity suggests:
pn  ladspa-plugin  

-- no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Otto Kekäläinen]

Thanks Andreas for testing potential changes!

If you file them as MRs at
https://salsa.debian.org/mariadb-team/galera-4 and
https://salsa.debian.org/mariadb-team/mariadb-10.5 you'll get the
additional CI testing run on top of the for free for extra validation.
There is a mariadb-10.5 Bullseye update pending already, so this is
excellent time to put in more changes as long as they are justified
(these are).

We also plan to make a mariadb-10.3 stable update to Buster, so
putting a critical fix is also an option.

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Otto Kekäläinen]

> How would one use galera-3 in bullseye? There is no mariadb-10.3 in
> buster, only 10.5 which depends on galera-4 which blocks galera-3 from
> being installed.
> (Even if galera-3 gets removed from bullseye, it will stay in buster
> (and sid if you want))

One would use upstream repositories for MariaDB 10.3 on Bullseye (but
get Galera from Debian proper).

> What do you need the virtual galera package for? My gut feeling is that
> this is the source of our problems because it forms some kind of a
> conflicts cycle.

Yes, we probably don't need the virtual package for Galera. I guess it
has been around since the start and was used because all existing
packaging at that time form upstream Codership and Percona had such a
package, and the replacement had to offer it as well. I think that by
now in 2021 we could probably drop it.

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Andreas Beckmann]

Control: tag -1 patch

attached are two patches for mariadb-10.5 and galera-4 that might solve 
the upgrade issues, trying them now ...



Andreas
diff -Nru galera-4-26.4.8/debian/changelog galera-4-26.4.8/debian/changelog
--- galera-4-26.4.8/debian/changelog	2021-05-26 05:38:32.0 +0200
+++ galera-4-26.4.8/debian/changelog	2021-07-05 22:14:25.0 +0200
@@ -1,3 +1,10 @@
+galera-4 (26.4.8-2) UNRELEASED; urgency=medium
+
+  * Solve circular Conflicts with galera-3 by no longer providing a virtual
+galera package.  (Closes: #990708)
+
+ -- Andreas Beckmann   Mon, 05 Jul 2021 22:14:25 +0200
+
 galera-4 (26.4.8-1) unstable; urgency=medium
 
   * New upstream release 26.4.8
diff -Nru galera-4-26.4.8/debian/control galera-4-26.4.8/debian/control
--- galera-4-26.4.8/debian/control	2021-05-26 05:38:25.0 +0200
+++ galera-4-26.4.8/debian/control	2021-07-05 22:14:25.0 +0200
@@ -20,8 +20,7 @@
 Section: libs
 Depends: ${misc:Depends},
  ${shlibs:Depends}
-Conflicts: galera,
-   galera-3,
+Conflicts:
garbd-2,
garbd-3,
garbd2,
@@ -34,13 +33,12 @@
percona-xtradb-cluster-galera-4.x,
percona-xtradb-cluster-garbd-2.x,
percona-xtradb-cluster-garbd-3.x
-Provides: galera,
+Provides:
   galera4,
   percona-xtradb-cluster-galera-26,
   wsrep
-Breaks: galera,
-galera-3
-Replaces: galera
+Breaks: galera-3 (<< 26.4)
+Replaces: galera-3 (<< 26.4)
 Description: Replication framework for transactional applications
  Galera is a fast synchronous multimaster wsrep provider (replication engine)
  for transactional databases and similar applications. For more information
diff -Nru mariadb-10.5-10.5.10/debian/changelog mariadb-10.5-10.5.10/debian/changelog
--- mariadb-10.5-10.5.10/debian/changelog	2021-05-24 06:04:38.0 +0200
+++ mariadb-10.5-10.5.10/debian/changelog	2021-07-05 09:53:32.0 +0200
@@ -1,3 +1,10 @@
+mariadb-10.5 (1:10.5.10-3) UNRELEASED; urgency=medium
+
+  * mariadb-server-10.5: Add Breaks: galera-3 (<< 26.4) to ease switching from
+galera-3 to galera-4 on upgrades from buster.  (Closes: #990708)
+
+ -- Andreas Beckmann   Mon, 05 Jul 2021 09:53:32 +0200
+
 mariadb-10.5 (1:10.5.10-2) unstable; urgency=medium
 
   * Bugfix: Revert upstream code change to fix armhf build (Closes: #988629)
diff -Nru mariadb-10.5-10.5.10/debian/control mariadb-10.5-10.5.10/debian/control
--- mariadb-10.5-10.5.10/debian/control	2021-05-21 07:09:56.0 +0200
+++ mariadb-10.5-10.5.10/debian/control	2021-07-05 09:53:32.0 +0200
@@ -339,7 +339,7 @@
 Pre-Depends: adduser (>= 3.40),
  debconf,
  mariadb-common (>= ${source:Version})
-Depends: galera-4 (>=26.4),
+Depends: galera-4 (>= 26.4),
  gawk,
  iproute2 [linux-any],
  libdbi-perl,
@@ -364,6 +364,7 @@
mysql-server-core-8.0,
virtual-mysql-server
 Breaks: cqrlog (<< 1.9.0-5~),
+galera-3 (<< 26.4),
 mariadb-galera-server,
 mariadb-galera-server-10.0,
 mariadb-galera-server-5.5,

Bug#990708: [debian-mysql] Bug#990708: Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Otto Kekäläinen]

On Mon, Jul 5, 2021 at 1:12 PM Olaf van der Spek  wrote:
>
> On Mon, Jul 5, 2021 at 9:24 PM Otto Kekäläinen  wrote:
> > I wish somebody could contribute with exact steps on how to reproduce
> > the issue. So far I've gotten some half attempts at that but they
> > haven't been actionable for me.
>
> Hi Otto,
>
> I'd point to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988089
> Not sure why it's not reproducible with those steps.

I don't see *the* steps, but I see a lot of messages about many
different steps. If you have them, why not copy-paste the steps here
in email so I can copy-paste them into a Debian Buster Docker
container and run the upgrade to isolate the regression?

Bug#990729: meshlab: uppercase named file not visible in file picker

[Michal Herko]

Package: meshlab
Version: 2020.09+dfsg1-1
Severity: normal
X-Debbugs-Cc: michal.he...@disroot.org

Dear Maintainer,

I am trying to open a STL file in meshlab.
The name of the file is upper case, for example "TEST.STL".
Select Menu > Import Mesh ... and navigate to a folder containing the file.
The file entry is not displayed and so the file cannot be selected.
I expect the file to be visible and selectable.
Opening the file with command 'meshlab TEST.STL' or selecting 'Open With ...'
in file browser works correctly.

Thank you.


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

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

Versions of packages meshlab depends on:
ii  lib3ds-1-3  1.3.0-10
ii  libc6   2.31-12
ii  libgcc-s1   10.2.1-6
ii  libglew2.1  2.1.0-4+b1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libglx0 1.3.2-1
ii  libgmp102:6.2.1+dfsg-1
ii  libgomp110.2.1-6
ii  libmuparser2v5  2.2.6.1+dfsg-1
ii  libopenctm1 1.0.3+dfsg1-2.1
ii  libopengl0  1.3.2-1
ii  libqhull8.0 2020.2-3
ii  libqt5core5a5.15.2+dfsg-7
ii  libqt5gui5  5.15.2+dfsg-7
ii  libqt5network5  5.15.2+dfsg-7
ii  libqt5opengl5   5.15.2+dfsg-7
ii  libqt5qml5  5.15.2+dfsg-6
ii  libqt5widgets5  5.15.2+dfsg-7
ii  libqt5xml5  5.15.2+dfsg-7
ii  libstdc++6  10.2.1-6

Versions of packages meshlab recommends:
ii  chemical-mime-data  0.1.94-7.1

meshlab suggests no packages.

Bug#990508: RFS: apt-listchanges/3.24.1 [ITA] -- Show new changelog entries from Debian package archives

[Brian Thompson]

+Tia, the bug reporter for #989496.
-- 
Best regards,

Brian T
B.S. Computer Science 2014 (Truman State University)
  Minor Stasitics
  Minor Chemistry
  Minor Mathematics


signature.asc
Description: PGP signature

Bug#989496: Looking to change the subject

[Brian Thompson]

It was brought to my attention by David K. (thank you, David), that the
what you are seeing is intended functionality.  I proposed in the email
thread with David that we could improve the error message, since right
now it may be confusing to users that it is actually expected behavior.
A cleaner, clearer error message should resolve any confusion.

I will CC you Tia.

-- 
Best regards,

Brian T
B.S. Computer Science 2014 (Truman State University)
  Minor Stasitics
  Minor Chemistry
  Minor Mathematics


signature.asc
Description: PGP signature

Bug#990736: unblock: soapyosmo/0.2.5-4

[tony mancill]

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

Dear Release Team,

Please consider an unblock for package soapyosmo.

[ Reason ]
This upload addresses an RC bug in the soapyosmo package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990240 by configuring
it to build against boost::chrono.

[ Impact ]
#990240 will transitively impact 19 other packages via
autoremovals as per the mailing that went out on July 1st.

[ Tests ]
The updated soapyosmo was installed locally and confirmed to address
this error when starting sdrangelove:

> [ERROR] 
> SoapySDR::loadModule(/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/librfspaceSupport.so)
>   dlopen() failed: 
> /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/librfspaceSupport.so: undefined 
> symbol: _ZN5boost6chrono12steady_clock3nowEv

[ Risks ]
The fix is trivial.  It merely configures the build to make use of
libboost-chrono-dev.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
This unblock alone will not address the crash in sdrangelove initially
reported #990240; see the discussion in the bug report for more details
and discussion by the Debian Ham team.  However, it could address and
prevent other brokenness related to soapyosmo in Bullseye.  That is,
soapyosmo should depend upon 

Thank you for considering this unblock.

Cheers,
tony

unblock soapyosmo/0.2.5-4
diff -Nru soapyosmo-0.2.5/debian/changelog soapyosmo-0.2.5/debian/changelog
--- soapyosmo-0.2.5/debian/changelog2019-10-20 08:31:08.0 -0700
+++ soapyosmo-0.2.5/debian/changelog2021-07-03 09:31:09.0 -0700
@@ -1,3 +1,10 @@
+soapyosmo (0.2.5-4) unstable; urgency=medium
+
+  * Team upload.
+  * Add boost::chrono to build (Closes: #990240)
+
+ -- tony mancill   Sat, 03 Jul 2021 09:31:09 -0700
+
 soapyosmo (0.2.5-3) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru soapyosmo-0.2.5/debian/control soapyosmo-0.2.5/debian/control
--- soapyosmo-0.2.5/debian/control  2019-10-20 08:29:52.0 -0700
+++ soapyosmo-0.2.5/debian/control  2021-07-03 09:31:09.0 -0700
@@ -7,6 +7,7 @@
 debhelper (>= 12),
 cmake,
 libboost-dev,
+libboost-chrono-dev,
 libboost-system-dev,
 libboost-thread-dev,
 libosmosdr-dev,
diff -Nru soapyosmo-0.2.5/debian/patches/boost_chrono.patch 
soapyosmo-0.2.5/debian/patches/boost_chrono.patch
--- soapyosmo-0.2.5/debian/patches/boost_chrono.patch   1969-12-31 
16:00:00.0 -0800
+++ soapyosmo-0.2.5/debian/patches/boost_chrono.patch   2021-07-03 
09:31:09.0 -0700
@@ -0,0 +1,10 @@
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -102,6 +102,7 @@
+ SET(BOOST_REQUIRED_COMPONENTS
+ thread
+ system
++chrono
+ )
+ 
+ if(UNIX AND NOT BOOST_ROOT AND EXISTS "/usr/lib64")
diff -Nru soapyosmo-0.2.5/debian/patches/series 
soapyosmo-0.2.5/debian/patches/series
--- soapyosmo-0.2.5/debian/patches/series   2019-09-22 18:12:05.0 
-0700
+++ soapyosmo-0.2.5/debian/patches/series   2021-07-03 09:31:09.0 
-0700
@@ -1 +1,2 @@
 internal-common-library
+boost_chrono.patch
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .changes but not in first
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/02/3648071dde21b174c4010728faa35a85d25c68.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/4c/6fdb3aa8aaf3fd6894d57bb164d12126fe4d87.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/d3/bb600eb81e7d8a5f97b54989a5a2f70df62f71.debug

Files in first .changes but not in second
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/30/652528145c6ca4e902b0aaece5708b43cb256a.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/36/6254bfc9b5da96d62d80824e1a7deae0b8ec35.debug
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/80/1a1744f1e2b0a3eb110ac0767ccd56e40f5618.debug

Control files of package soapyosmo-common0.7: lines which differ (wdiff format)
---
Version: [-0.2.5-3-] {+0.2.5-4+}

Control files of package soapyosmo-common0.7-dbgsym: lines which differ (wdiff 
format)
--
Depends: soapyosmo-common0.7 (= [-0.2.5-3)-] {+0.2.5-4)+}
Version: [-0.2.5-3-] {+0.2.5-4+}

Control files of package soapysdr-module-mirisdr: lines which differ (wdiff 
format)
---
Depends: soapysdr0.7-module-mirisdr, soapyosmo-common0.7 (= [-0.2.5-3)-] 
{+0.2.5-4)+}
Version: [-0.2.5-3-] {+0.2.5-4+}

Control files of package soapysdr-module-osmosdr: lines which differ (wdiff 
format)
-

Bug#990696: unblock: netselect/0.3.ds1-29

[Sebastian Ramacher]

Control: tags -1 moreinfo confirmed

On 2021-07-05 00:20:02 +0200, Javier Fernández-Sanguino Peña wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package netselect
> 
> [ Reason ]
> 
> Netselect-apt is not able to properly parse the URLs in the mirror list
> available in the Debian website. This version fixes the bug in parsing which
> makes it work again.
> 
> [ Impact ]
> If the unblock is not implemented users will not be able to use netselect-apt
> 
> [ Tests ]
> I have run manually tests in my unstable system to confi
> 
> [ Risks ]
> The change is very simple. This is a package which is used by a small number 
> of
> users. 
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> unblock netselect/0.3.ds1-29

ACK, please remove the moreinfo tag once the package is available in
unstable.

Cheers

> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 5.10.0-1-686-pae (SMP w/4 CPU threads)
> Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

> diff -Nru netselect-0.3.ds1/debian/changelog 
> netselect-0.3.ds1/debian/changelog
> --- netselect-0.3.ds1/debian/changelog2021-07-05 00:14:53.0 
> +0200
> +++ netselect-0.3.ds1/debian/changelog2021-07-04 23:04:35.0 
> +0200
> @@ -1,3 +1,14 @@
> +netselect (0.3.ds1-29) unstable; urgency=high
> +
> +  * netselect-apt:
> +- Fix bug that makes it output some hosts with negative value (Closes: 
> 920907)
> +- Fix bug in the Pelr parsing which prevented it from processing properly
> +  the mirrors listed in the Debian website (Closes: 989674)
> +  * debian/control: Move curl to depends as it is required by netselect-apt
> +   (Closes: 788793)
> +
> + -- Javier Fernández-Sanguino Peña   Sun, 04 Jul 2021 
> 23:04:35 +0200
> +
>  netselect (0.3.ds1-28) unstable; urgency=medium
>  
>* Use debhelper files properly to relocation binaries and
> diff -Nru netselect-0.3.ds1/debian/control netselect-0.3.ds1/debian/control
> --- netselect-0.3.ds1/debian/control  2021-07-05 00:14:53.0 +0200
> +++ netselect-0.3.ds1/debian/control  2021-07-04 23:04:35.0 +0200
> @@ -22,8 +22,7 @@
>  
>  Package: netselect-apt
>  Architecture: all
> -Depends: wget, netselect (>= 0.3.ds1-17), ${misc:Depends}
> -Recommends: curl
> +Depends: wget, netselect (>= 0.3.ds1-17), curl, ${misc:Depends}
>  Enhances: apt
>  Suggests: dpkg-dev
>  Description: speed tester for choosing a fast Debian mirror
> diff -Nru netselect-0.3.ds1/netselect-apt netselect-0.3.ds1/netselect-apt
> --- netselect-0.3.ds1/netselect-apt   2021-07-05 00:14:53.0 +0200
> +++ netselect-0.3.ds1/netselect-apt   2021-07-04 23:04:35.0 +0200
> @@ -35,7 +35,7 @@
>  # Default distribution
>  distro="stable"
>  # Default protocol
> -protocol="HTTP"
> +protocol="http"
>  # Number of fastest hosts that will be validated
>  test_hosts="10"
>  # URL where the mirror list is retrieved from 
> @@ -120,7 +120,7 @@
>  
>  # Second test: do we have the test file we are looking for?
>  [ -n "$DEBUG" ] && log "DEBUG: Checking if the file '$test_file' is 
> available in site"
> -temp=`tempfile`
> +temp=`mktemp`
>  [ ! -e "$temp" ] && return 0 # Return without error if we cannot create
>   # a temporary file
>  curl -m 2 -q -s "$host/$test_file"  >$temp 2>&1
> @@ -156,12 +156,14 @@
>   SEARCH="$1"
>   PROTO="$2"
>  hosts=$(cat "$infile" \
> - | perl -n -e '
> +   | perl -n -e '
> +use warnings;
> +use strict;
>   $/="";
> -$country_name  = ".*";
> -$country_iso  = "..";
> -$country = "'"$country"'";
> -$my_country = 1;
> +my $country_name  = ".*";
> +my $country_iso  = "..";
> +my $country = "'"$country"'";
> +my $my_country = 1;
>  if ( $country ne "" ) {
>$my_country = 0;
>if ( $country =~ /^\w{2}$/ ) {
> @@ -184,7 +186,7 @@
>   next if $_ !~ /Site:/;
>   if( ( /Includes architectures:.+'"$arch"'.+/i ||
>   $_ !~ /Includes architectures:/ 
> ) &&
> - 
> m@'"$SEARCH"':.*@i && $my_country == 1
> +   
> m@'"

Bug#990581: nomad: CVE-2021-32575

[Peter Pentchev]

Hi,

First of all, thanks for your work on nomad and Debian in general!

Dmitry, what do you think about my attempt to backport the upstream
patch for CVE-2021-32575 to the Debian package of nomad?
The upstream patch is at:

  
https://github.com/hashicorp/nomad/commit/003d68fe6df652b172bc68beabd11a25fd7e1b58

My proposed update to the Debian package is in my forked Salsa repo:

  https://salsa.debian.org/roam/nomad/-/commits/roam-CVE-2021-32575/

  git clone -b roam-CVE-2021-32575 https://salsa.debian.org/roam/nomad.git

If you have no objections, I could push these commits to the team repo,
upload to unstable, and send an unblock request to the release team.

Thanks again, and keep up the great work!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#987704: webext-foxyproxy: 100% cpu stalling

[Christoph Anton Mitterer]

Hey.

I think this might be the same than:
#986567
#986027

and not just affecting foxyproxy... but rather all extensions.

Cheers,
Chris.

Bug#986027: merging duplicates

[Christoph Anton Mitterer]

Control: forcemerge 986567 986027

Hey.

I think these two are the same, thus merging. Probably #987704 is yet
another duplicate.

Cheers,
Chris.

Bug#990734: sbuild: option --build-dir is ignored in source directory

[Jochen Sprickerhof]

Package: sbuild
Version: 0.81.2
Severity: normal

steps to reproduce:

$ apt source hello
$ cd hello*/
$ sbuild --build-dir=/tmp
$ ls /tmp/hello* ../hello*  # all output files are in ../

whereas building the .dsc

$ cd ..
$ sbuild --build-dir=/tmp/ hello*.dsc
$ ls /tmp/hello*  # files are in /tmp

This is due to:

https://sources.debian.org/src/sbuild/0.81.2/bin/sbuild/#L231

changing it to:

$conf->_set_default('BUILD_DIR', $dscdir);

$ sbuild --build-dir=/tmp
$ ls /tmp/hello*  # files are now in /tmp

Sadly the change breaks autopkgtests:

$ cd hello*/
$ sbuild --build-dir=/tmp/ --run-autopkgtest
[..]
Unexpected error:
Traceback (most recent call last):
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 739, in mainloop
command()
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 668, in command
r = f(c, ce)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 602, in cmd_copydown
copyupdown(c, ce, False)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 490, in copyupdown
copyupdown_internal(ce[0], c[1:], upp)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 517, in 
copyupdown_internal
copydown_shareddir(sd[0], sd[1], dirsp, downtmp_host)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 472, in 
copydown_shareddir
shutil.copy(host, host_tmp)
  File "/usr/lib/python3.9/shutil.py", line 418, in copy
copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib/python3.9/shutil.py", line 264, in copyfile
with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/hello_2.10.orig.tar.gz'


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

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

Versions of packages sbuild depends on:
ii  adduser 3.118
ii  libsbuild-perl  0.81.2
ii  perl5.32.1-4

Versions of packages sbuild recommends:
ii  autopkgtest  5.16
ii  debootstrap  1.0.123
ii  schroot  1.6.10-12

Versions of packages sbuild suggests:
pn  deborphan  
ii  e2fsprogs  1.46.2-2
ii  kmod   28-1
ii  wget   1.21-1+b1

-- no debconf information

Bug#990733: xfwm4: Resolution drops from 3840x2160 to 2560x1440 on power save

[Keith Edmunds]

Package: xfwm4
Version: 4.16.1-1
Severity: normal

Dear Maintainer,

Occasionally - maybe once a week - after re-waking a sleeping monitor, the 
screen resolution changes as per subject. Settings, Display then shows a 
maximum available resolution of 2560x1440. Logging out and in keeps the lower 
resolution, but Settings, Display now allows it to be changed back to 2840x2160.

Monitor is Dell P2715Q; graphics card is NVIDIA Corporation GP107GL [Quadro 
P620] (rev a1).

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

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

Versions of packages xfwm4 depends on:
ii  libc6 2.31-12
ii  libcairo2 1.16.0-5
ii  libepoxy0 1.5.5-1
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libstartup-notification0  0.12-6+b1
ii  libwnck-3-0   3.36.0-1
ii  libx11-6  2:1.7.1-1
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1.1
ii  libxfce4ui-2-04.16.0-1
ii  libxfce4util7 4.16.0-1
ii  libxfconf-0-3 4.16.0-2
ii  libxfixes31:5.0.3-2
ii  libxinerama1  2:1.1.4-2
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxres1  2:1.2.0-4

Versions of packages xfwm4 recommends:
ii  librsvg2-common  2.50.3+dfsg-1

Versions of packages xfwm4 suggests:
ii  xfce4  4.16

-- no debconf information

Bug#990708: [debian-mysql] Bug#990708: Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Olaf van der Spek]

On Mon, Jul 5, 2021 at 9:24 PM Otto Kekäläinen  wrote:
> I wish somebody could contribute with exact steps on how to reproduce
> the issue. So far I've gotten some half attempts at that but they
> haven't been actionable for me.

Hi Otto,

I'd point to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988089
Not sure why it's not reproducible with those steps.


Greetings,
-- 
Olaf

Bug#990439: postsrsd: CVE-2021-35525

[Oxan van Leeuwen]

Hi,

On 29-06-2021 07:41, Salvatore Bonaccorso wrote:

The following vulnerability was published for postsrsd.

CVE-2021-35525[0]:


Thanks for the report, I've unfortunately missed this release. Do you 
want to fix this through a DSA, or should I prepare&upload a stable (and 
bullseye) update?


Kind regards,
Oxan van Leeuwen

Bug#990240: soapyosmo: does not link with boost chrono

[tony mancill]

On Mon, Jul 05, 2021 at 12:34:04PM +0200, Christoph Berg wrote:
> Re: tony mancill
> > However, the patched build alone does not resolve the crash of
> > sdrangelove on my system until I also install the updated hamlib4 from
> > experimental.  That is, sdrangelove appears to be affected by 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980472.
> > 
> > I'm not sure what the plans are for the hamlib4 with respect to
> > Bullseye.
> 
> 4.0 is probably not the ideal version to have in bullseye, but it's a
> great improvement over the version we had before (which was missing
> support for many transceivers on the market today).
> 
> Hamlib 4.1 is unfortunately incompatible with 4.0 in some internal
> data structures (which are supposed to be opaque, but aren't always in
> practise), so updating to that would need fixes in other programs (I
> know about wsjtx, see libhamlib4's Breaks:). I don't think we can or
> should try to push that into bullseye.

Yes, wstjx is twice as popular as sdrangelove according to popcon, and I
am surprised the delta isn't even greater.

> > Any concerns with an upload of soapyosmo to get us one step
> > closer?  
> 
> Seems sensible to me.

Thank you for the response.  I will to upload with this (minimal) change
and request an unblock.  Given that the upload addresses the retitled bug
in soapysdr, I will include "Closes: #990240" but want to point out that
the "affects" for sdrangelove isn't really applicable.  As far as I can
tell, the "ERROR" logged during startup isn't the actual cause of the
crash, it simply happens to be the last thing logged before the crash.

> [ERROR] 
> SoapySDR::loadModule(/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/librfspaceSupport.so)
>   dlopen() failed: 
> /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/librfspaceSupport.so: undefined 
> symbol: _ZN5boost6chrono12steady_clock3nowEv
> Hash collision!!! Fatal error!!
> pure virtual method called

Cheers,
tony


signature.asc
Description: PGP signature

Bug#990439: postsrsd: CVE-2021-35525

[Salvatore Bonaccorso]

Hi Oxan,

On Mon, Jul 05, 2021 at 06:03:10PM +0200, Oxan van Leeuwen wrote:
> Hi,
> 
> On 29-06-2021 07:41, Salvatore Bonaccorso wrote:
> > The following vulnerability was published for postsrsd.
> > 
> > CVE-2021-35525[0]:
> 
> Thanks for the report, I've unfortunately missed this release. Do you want
> to fix this through a DSA, or should I prepare&upload a stable (and
> bullseye) update?

I think we can do the following action plan, let me know if you agree:
The release btw is not yet fully missed, so I would suggest: upload a
very targetted fix aimed for bullseye to unstable, ask the release
team for unblocking and aging the package, so we make sure the fix
lands in bullseye before the release.

For buster, it looks to me that the issue is low severity enough that
we can have an update via an upcoming point release.

Do you concur?

Regards,
Salvatore

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Andreas Beckmann]

On 05/07/2021 21.20, Otto Kekäläinen wrote:

Hello!

I was able to reproduce this, and addressed it in
https://salsa.debian.org/mariadb-team/galera-4/-/commit/27a142792b5e02e66b8f1adf9a7b896c5722dd17
+ added Salsa-CI testing for this specific scenario so that it would
not regress again, but seems there is still some second scenario that
does not upgrade properly.

I wish somebody could contribute with exact steps on how to reproduce
the issue. So far I've gotten some half attempts at that but they
haven't been actionable for me.


I'm currently looking at upgrading roundcube-core in a minmal chroot 
with --install-recommends *DISABLED* ...



My plan was to keep Galera-3 in Debian stable / Ubuntu stable as for
the duration that MariaDB 10.3 is supported upstream, as MariaDB does
not offer Galera by themselves, so it is better to have it available
in distro.


How would one use galera-3 in bullseye? There is no mariadb-10.3 in 
buster, only 10.5 which depends on galera-4 which blocks galera-3 from 
being installed.
(Even if galera-3 gets removed from bullseye, it will stay in buster 
(and sid if you want))


What do you need the virtual galera package for? My gut feeling is that 
this is the source of our problems because it forms some kind of a 
conflicts cycle.



Andreas

Bug#990732: iwlwifi fails to work after hibernation with linux-4.19.0-17-amd64

[Robert Scott]

Package: li1nux
Version: 4.19.0-17

tl;dr: I have a feeling this is https://bugzilla.redhat.com/show_bug.cgi?
id=1656233

After resuming a buster system with linux-4.19.0-17 on a thinkpad x220 the 
intel 6205 wifi fails to work, with the below dmesg warnings.

Hopefully this _is_ just the same bug as linked, which would suggest the 
solution is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
linux.git/commit/drivers/pci/probe.c?
id=10ecc818ea7319b5d0d2b4e1aa6a77323e776f76

[11218.145442] iwlwifi :03:00.0: Error, can not clear persistence bit
[11218.145448] iwlwifi :03:00.0: Failed to start HW: -1
[11218.145454] iwlwifi :03:00.0: Unable to initialize device.
[11218.148066] iwlwifi :03:00.0: Error, can not clear persistence bit
[11218.148072] iwlwifi :03:00.0: Failed to start HW: -1
[11218.148079] iwlwifi :03:00.0: Unable to initialize device.
[11315.009011] [ cut here ]
[11315.009014] Timeout waiting for hardware access (CSR_GP_CNTRL 0x)
[11315.009051] WARNING: CPU: 0 PID: 8807 at drivers/net/wireless/intel/
iwlwifi/pcie/trans.c:2033 iwl_trans_pcie_grab_nic_access+0x1e8/0x220 [iwlwifi]
[11315.009052] Modules linked in: rfcomm bnep btusb btrtl btbcm btintel 
bluetooth drbg ansi_cprng ecdh_generic hid_generic usbhid hid nls_ascii 
nls_cp437 vfat fat uas usb_storage ctr ccm tun intel_rapl arc4 
x86_pkg_temp_thermal intel_powerclamp iwldvm(-) coretemp snd_hda_codec_hdmi 
mei_wdt kvm_intel mac80211 uvcvideo snd_hda_codec_conexant videobuf2_vmalloc 
videobuf2_memops snd_hda_codec_generic videobuf2_v4l2 joydev kvm 
videobuf2_common irqbypass snd_hda_intel intel_cstate iwlwifi snd_hda_codec sg 
intel_uncore videodev wmi_bmof intel_rapl_perf serio_raw snd_hda_core media 
pcspkr snd_hwdep cfg80211 snd_pcm thinkpad_acpi snd_timer mei_me nvram 
iTCO_wdt iTCO_vendor_support mei snd soundcore pcc_cpufreq rfkill ac battery 
evdev nf_log_ipv6 ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables ip6t_rt 
nf_log_ipv4
[11315.009080]  nf_log_common ipt_REJECT nf_reject_ipv4 xt_LOG nft_limit 
xt_limit xt_addrtype xt_tcpudp xt_conntrack nft_compat nft_counter 
nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat 
nf_conntrack_ftp nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c 
nf_tables nfnetlink parport_pc ppdev sunrpc lp parport ip_tables x_tables 
autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb twofish_generic 
twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common xts 
algif_skcipher af_alg dm_crypt dm_mod sd_mod crct10dif_pclmul crc32_pclmul 
crc32c_intel ghash_clmulni_intel pcbc i915 ahci aesni_intel libahci libata 
sdhci_pci aes_x86_64 crypto_simd cryptd cqhci glue_helper scsi_mod psmouse 
i2c_algo_bit sdhci drm_kms_helper mmc_core ehci_pci ehci_hcd i2c_i801 lpc_ich 
drm mfd_core
[11315.009108]  usbcore e1000e usb_common thermal wmi video button
[11315.009114] CPU: 0 PID: 8807 Comm: rmmod Tainted: GW 
4.19.0-17-amd64 #1 Debian 4.19.194-1
[11315.009115] Hardware name: LENOVO 4290A48/4290A48, BIOS 8DET49WW (1.19 ) 
07/01/2011
[11315.009123] RIP: 0010:iwl_trans_pcie_grab_nic_access+0x1e8/0x220 [iwlwifi]
[11315.009126] Code: e6 c3 49 8d 56 08 bf 00 02 00 00 e8 e2 36 dd c2 e9 33 ff 
ff ff 89 c6 48 c7 c7 b0 b5 ed c0 c6 05 e1 45 02 00 01 e8 01 0d 44 c3 <0f> 0b 
e9 ee fe ff ff 48 8b 7b 30 48 c7 c1 18 b6 ed c0 31 d2 31 f6
[11315.009127] RSP: 0018:a81cc394fdc8 EFLAGS: 00010082
[11315.009129] RAX:  RBX: 9a9e13830018 RCX: 
0006
[11315.009130] RDX: 0007 RSI: 0092 RDI: 
9a9e160166b0
[11315.009131] RBP:  R08: 05d9 R09: 
0004
[11315.009132] R10:  R11: 0001 R12: 
9a9e1383a258
[11315.009133] R13: a81cc394fdf8 R14:  R15: 

[11315.009135] FS:  7f3ddc3ab480() GS:9a9e1600() knlGS:

[11315.009136] CS:  0010 DS:  ES:  CR0: 80050033
[11315.009137] CR2: 5573c3c42750 CR3: 00011e5f4003 CR4: 
000606f0
[11315.009138] Call Trace:
[11315.009149]  iwl_write_prph+0x37/0x90 [iwlwifi]
[11315.009156]  iwl_pcie_apm_init+0x1b2/0x210 [iwlwifi]
[11315.009164]  iwl_pcie_apm_stop+0x324/0x360 [iwlwifi]
[11315.009171]  iwl_trans_pcie_op_mode_leave+0x86/0x150 [iwlwifi]
[11315.009177]  iwl_op_mode_dvm_stop+0x8b/0xb0 [iwldvm]
[11315.009184]  _iwl_op_mode_stop.isra.8+0x27/0x40 [iwlwifi]
[11315.009190]  iwl_opmode_deregister+0x5e/0xb0 [iwlwifi]
[11315.009196]  iwl_exit+0xc/0x486 [iwldvm]
[11315.009200]  __x64_sys_delete_module+0x190/0x2e0
[11315.009204]  do_syscall_64+0x53/0x110
[11315.009208]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[11315.009210] RIP: 0033:0x7f3ddc4cbdd7
[11315.009212] Code: 73 01 c3 48 8b 0d b9 10 0c 00 f7 d8 64 89 01 48 83 c8 ff 
c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 
01 f0 ff ff 73 01 c3 48 8b 0d 89 10 0c 00 f7 d8 64 89 01 48
[11315.009213] RSP: 002b:7ffe8

Bug#990500: unblock: lxml/4.6.3+dfsg-0.1

[Paul Gevers]

Control: tags -1 - moreinfo

Hi Sebastian,

On 04-07-2021 22:01, Sebastian Ramacher wrote:
>> diff -Nru lxml-4.6.3/debian/control lxml-4.6.3+dfsg/debian/control
>> --- lxml-4.6.3/debian/control2020-12-07 14:42:24.0 +0100
>> +++ lxml-4.6.3+dfsg/debian/control   2021-06-26 19:40:37.0 +0200
>> @@ -9,6 +9,7 @@
>>python3-setuptools (>= 0.6.29),
>>python3-bs4,
>>python3-html5lib,
>> +  python3-lxml ,
>>cython3, cython3-dbg,
>>python3-sphinx-autoapi,
>>  X-Python-Version: all
>> diff -Nru lxml-4.6.3/debian/rules lxml-4.6.3+dfsg/debian/rules
>> --- lxml-4.6.3/debian/rules  2020-07-17 11:16:59.0 +0200
>> +++ lxml-4.6.3+dfsg/debian/rules 2021-06-26 19:40:37.0 +0200
>> @@ -24,6 +24,9 @@
>>  touch $@
>>  build3-python%: prebuild
>>  python$* setup.py build
>> +ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS)))
>> +python$* doc/mkhtml.py doc/html . $(UPSTREAMVER)
>> +endif
> 
> Shouldn't this use the just built version of lxml, e.g., by setting the
> appropriate PYTHONPATH, instead of the old packaged lxml in python3-lxml?

Oh, yes. But as I don't do Python packaging (just didn't happen, I don't
object), I didn't know how to do that and I didn't want to spend too
much time on it to figure it out (and potentially getting it wrong).

Paul




OpenPGP_signature
Description: OpenPGP digital signature

Bug#990304: closed by Debian FTP Masters (reply to Christoph Berg ) (Bug#990304: fixed in barman 2.12-2)

[Jérémy Lal]

Grammar correction:
Severity might need to be raised.
Something rises itself, someone raises an issue.


Le lun. 5 juil. 2021 à 18:21, Debian Bug Tracking System <
ow...@bugs.debian.org> a écrit :

> This is an automatic notification regarding your Bug report
> which was filed against the barman package:
>
> #990304: barman: pg 13 expects wal_keep_size, not wal_keep_segments
>
> It has been closed by Debian FTP Masters 
> (reply to Christoph Berg ).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters <
> ftpmas...@ftp-master.debian.org> (reply to Christoph Berg )
> by
> replying to this email.
>
>
> --
> 990304: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990304
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 990304-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 05 Jul 2021 16:18:25 +
> Subject: Bug#990304: fixed in barman 2.12-2
> Source: barman
> Source-Version: 2.12-2
> Done: Christoph Berg 
>
> We believe that the bug you reported is fixed in the latest version of
> barman, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 990...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Christoph Berg  (supplier of updated barman package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Mon, 05 Jul 2021 17:59:18 +0200
> Source: barman
> Architecture: source
> Version: 2.12-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Marco Nenciarini 
> Changed-By: Christoph Berg 
> Closes: 990304
> Changes:
>  barman (2.12-2) unstable; urgency=medium
>  .
>* Team upload.
>* PG 13 expects wal_keep_size, not wal_keep_segments. (Closes: #990304)
> Checksums-Sha1:
>  d82eab0506e8f67fed9741b7f5355ffc35468693 2053 barman_2.12-2.dsc
>  37faac893a068267a92fea0dcc73948ea7b67cd4 12792 barman_2.12-2.debian.tar.xz
> Checksums-Sha256:
>  360a0fbaa76513b45636e5f31aeca44150fd8ef8e244d146de0ca0c9050835bc 2053
> barman_2.12-2.dsc
>  0e311cc86b6376b694692fb7354b2440b4db53a0fdd88ab4a5d337be7ba13d8c 12792
> barman_2.12-2.debian.tar.xz
> Files:
>  78a8837f1418fa3a9411af3483fa23ab 2053 database optional barman_2.12-2.dsc
>  86193bf58e881609ae76e8b86ac43091 12792 database optional
> barman_2.12-2.debian.tar.xz
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEXEj+YVf0kXlZcIfGTFprqxLSp64FAmDjLbkACgkQTFprqxLS
> p64AsxAAnVztHjELIUT+hvUGv1ApYmU3nULNKD/9Ggy9id1YykNW7PA90pNf0UPm
> QxClOTC7Q9Fwn4+u5u4dbpUfIJsrBTX7Yfdh5aVW5Ol6NYrbDcJfIzBi6hZMtYUm
> dfUmVNnPUOtQ1Xa4TwvwR5eSUi0wA29bQ9zL1Eloaq84Qg045u7sb519nbEpNBmS
> ZgbTs3sNL89mJt9JVvFPFnz+0Opiq3QsFERZChnq1ZXDERWx6NE3UlO4iRkpTDl3
> 5TBK8+xFsXvqwRbmv5Zmh/r1bTGAQEUQG0V07rfiQLUm30/M2lhyNAlvVWeIHLIi
> FIgC06nVDznI10IDOz6Woe3CmbL3+MbQq6QfhvRdAE7ZqmSy2r8fV0HfCNS6MNVt
> AdXOc2Hm9wQXwBxw99hWEbaevWQQu1HyxdfyzvHa3VmP9R3NzXpwL2+M6OadrTOj
> OkZVZN8Io52W6OBQSZjo6816v2Uz6PMZ4y+87M/z+p/9GUzy9yyJ/cvBUo+dh5lK
> kuZvjcypWOe8ZzQwnKZTaQFwH+4uQPViC94VqZSjdMdxlIi/gQCPeRIIOMACOcKL
> FNvJPCK5EJSuxznAyO2+Q7pzlXNlrKdlENIJ2Q2sEY6+RPAnAa78ZeXYjhN1ZGO1
> +DYVug2ybm3+uvNLqicZIljq1AwuujW9LOwrpdWdLLMijZwG5U0=
> =rxfE
> -END PGP SIGNATURE-
>
>
> -- Forwarded message --
> From: "Jérémy Lal" 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 25 Jun 2021 10:00:46 +0200
> Subject: barman: pg 13 expects wal_keep_size, not wal_keep_segments
> Package: barman
> Version: 2.12
> Severity: important
>
> See
> https://github.com/EnterpriseDB/barman/issues/302
> and this is fixed in commit
>
> https://github.com/EnterpriseDB/barman/commit/45ccd9d2f315ec208eee778eba1333c0aa4a4460
>
> This is going to hit Bullseyes users.
> Severity might need to be rised - after all it makes barman somewhat
> broken.
>
> Jérémy
>
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'unstable'), (500,
> 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages barman depends on:
> ii  adduser3.118
> ii  python3

Bug#990731: unblock: virulencefinder/2.0.3+git20190809.dde157a-3

[Nilesh Patra]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nil...@debian.org, debian-med-packag...@lists.alioth.debian.org

Please unblock package virulencefinder

[ Reason ]
virulencefinder is an unusable package w/o having a Depends on
python3-distutils
It also fixes the corresponding RC bug #990728

[ Impact ]
The package will be unusable for bullseye users w/o explicitly
installing python3-distutils on their own

[ Tests ]
The package has autopkgtests which pass

[ Risks ]
No risks, resfinder is a leaf package

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock virulencefinder/2.0.3+git20190809.dde157a-3

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru virulencefinder-2.0.3+git20190809.dde157a/debian/changelog 
virulencefinder-2.0.3+git20190809.dde157a/debian/changelog
--- virulencefinder-2.0.3+git20190809.dde157a/debian/changelog  2020-03-03 
11:39:54.0 +0530
+++ virulencefinder-2.0.3+git20190809.dde157a/debian/changelog  2021-07-06 
00:36:09.0 +0530
@@ -1,3 +1,11 @@
+virulencefinder (2.0.3+git20190809.dde157a-3) unstable; urgency=medium
+
+  * Team Upload.
+  * d/control: Add Missing Depends on python3-distutils
+(Closes: #990728)
+
+ -- Nilesh Patra   Tue, 06 Jul 2021 00:36:09 +0530
+
 virulencefinder (2.0.3+git20190809.dde157a-2) unstable; urgency=medium
 
   * Team Upload.
diff -Nru virulencefinder-2.0.3+git20190809.dde157a/debian/control 
virulencefinder-2.0.3+git20190809.dde157a/debian/control
--- virulencefinder-2.0.3+git20190809.dde157a/debian/control2020-03-03 
11:39:54.0 +0530
+++ virulencefinder-2.0.3+git20190809.dde157a/debian/control2021-07-06 
00:35:45.0 +0530
@@ -23,7 +23,8 @@
  python3-tabulate,
  python3-cgecore,
  ncbi-blast+,
- kma
+ kma,
+ python3-distutils
 Description: identify virulence genes in total or partial sequenced isolates 
of bacteria
  The VirulenceFinder service contains one Python script
  virulencefinder.py which is the script of the latest version of the
diff -Nru virulencefinder-2.0.3+git20190809.dde157a/debian/tests/control 
virulencefinder-2.0.3+git20190809.dde157a/debian/tests/control
--- virulencefinder-2.0.3+git20190809.dde157a/debian/tests/control  
2020-03-03 11:39:54.0 +0530
+++ virulencefinder-2.0.3+git20190809.dde157a/debian/tests/control  
2021-07-06 00:35:29.0 +0530
@@ -1,3 +1,3 @@
 Tests: run-unit-test
-Depends: @, python3-distutils
+Depends: @
 Restrictions: allow-stderr

Bug#990730: unblock: resfinder/3.2-3

[Nilesh Patra]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nil...@debian.org, debian-med-packag...@lists.alioth.debian.org

Please unblock package resfinder

[ Reason ]
resfinder is an unusable package w/o having a Depends on
python3-distutils
It also fixes the corresponding RC bug #990726

[ Impact ]
The package will be unusable for bullseye users w/o explicitly
installing python3-distutils on their own

[ Tests ]
The package has autopkgtests which pass

[ Risks ]
No risks, resfinder is a leaf package

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock resfinder/3.2-3

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru resfinder-3.2/debian/changelog resfinder-3.2/debian/changelog
--- resfinder-3.2/debian/changelog  2020-03-03 11:12:37.0 +0530
+++ resfinder-3.2/debian/changelog  2021-07-06 00:05:05.0 +0530
@@ -1,3 +1,13 @@
+resfinder (3.2-3) unstable; urgency=medium
+
+  * Team Upload.
+  * d/control: Add Missing Depends on python3-distutils
+(Closes: #990726)
+  * d/p/fix_syntaxwarning.patch: Fix syntax warning for
+literal comparison
+
+ -- Nilesh Patra   Tue, 06 Jul 2021 00:05:05 +0530
+
 resfinder (3.2-2) unstable; urgency=medium
 
   [ Nilesh Patra ]
diff -Nru resfinder-3.2/debian/control resfinder-3.2/debian/control
--- resfinder-3.2/debian/control2020-03-03 11:12:37.0 +0530
+++ resfinder-3.2/debian/control2021-07-06 00:01:06.0 +0530
@@ -19,7 +19,8 @@
  resfinder-db,
  python3-cgecore,
  python3-tabulate,
- ncbi-blast+-legacy
+ ncbi-blast+-legacy,
+ python3-distutils
 Description: identify acquired antimicrobial resistance genes
  ResFinder identifies acquired antimicrobial resistance genes in total or
  partial sequenced isolates of bacteria.
diff -Nru resfinder-3.2/debian/patches/fix_syntaxwarning.patch 
resfinder-3.2/debian/patches/fix_syntaxwarning.patch
--- resfinder-3.2/debian/patches/fix_syntaxwarning.patch1970-01-01 
05:30:00.0 +0530
+++ resfinder-3.2/debian/patches/fix_syntaxwarning.patch2021-07-06 
00:04:19.0 +0530
@@ -0,0 +1,14 @@
+Description: Use == instead of is
+Author: Nilesh Patra 
+Last-Update: 2021-07-05
+--- a/resfinder.py
 b/resfinder.py
+@@ -364,7 +364,7 @@
+   """
+   """
+   # Check if databases and config file are correct/correponds
+-  if databases is '':
++  if databases == '':
+ sys.exit("Input Error: No database was specified!\n")
+   elif databases is None:
+  # Choose all available databases from the config file
diff -Nru resfinder-3.2/debian/patches/series 
resfinder-3.2/debian/patches/series
--- resfinder-3.2/debian/patches/series 1970-01-01 05:30:00.0 +0530
+++ resfinder-3.2/debian/patches/series 2021-07-06 00:03:19.0 +0530
@@ -0,0 +1 @@
+fix_syntaxwarning.patch
diff -Nru resfinder-3.2/debian/tests/control resfinder-3.2/debian/tests/control
--- resfinder-3.2/debian/tests/control  2020-03-03 11:12:37.0 +0530
+++ resfinder-3.2/debian/tests/control  2021-07-06 00:01:06.0 +0530
@@ -1,3 +1,3 @@
 Tests: run-unit-test
-Depends: @, python3-distutils
+Depends: @
 Restrictions: allow-stderr

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Otto Kekäläinen]

Hello!

I was able to reproduce this, and addressed it in
https://salsa.debian.org/mariadb-team/galera-4/-/commit/27a142792b5e02e66b8f1adf9a7b896c5722dd17
+ added Salsa-CI testing for this specific scenario so that it would
not regress again, but seems there is still some second scenario that
does not upgrade properly.

I wish somebody could contribute with exact steps on how to reproduce
the issue. So far I've gotten some half attempts at that but they
haven't been actionable for me.


My plan was to keep Galera-3 in Debian stable / Ubuntu stable as for
the duration that MariaDB 10.3 is supported upstream, as MariaDB does
not offer Galera by themselves, so it is better to have it available
in distro.

- Otto

Bug#990717: [Pkg-xen-devel] Bug#990717: xen-system-amd64: Microcode isn't loaded when booting in xen mode

[José Luis Fernández Jambrina]

OMG, I supposed it will enough to put a line like:
ucode=scan
As soon as I tried a line like:
GRUB_CMDLINE_XEN="ucode=scan"
The system behaviour changed I still have a couple de lines in 
/var/log/kern.log saying:

Jul  5 19:38:19 xuxa3 kernel: [   22.487806] VPMU disabled by hypervisor.
| Jul  5 19:38:19 xuxa3 kernel: [   22.488166] Performance Events: 
unsupported p6 CPU model 79 no PMU driver, software events only. 
 But this seems another problem because while booting with standard 
kernel I got:
Jul  5 14:05:17 xuxa3 kernel: [0.837414] Performance Events: PEBS 
fmt2+, Broadwell events, full-width counters, Broken BIOS detected, 
complain to your hardware vendor.
Jul  5 14:05:17 xuxa3 kernel: [0.837427] [Firmware Bug]: the BIOS 
has corrupted hw-PMU resources (MSR 38d is 330)

Jul  5 14:05:17 xuxa3 kernel: [0.837504] Intel PMU driver.
Jul  5 14:05:17 xuxa3 kernel: [0.837508] ... version:3
Jul  5 14:05:17 xuxa3 kernel: [0.837509] ... bit 
width:  48

Jul  5 14:05:17 xuxa3 kernel: [0.837510] ... generic registers:  8
Jul  5 14:05:17 xuxa3 kernel: [0.837511] ... value 
mask: 
Jul  5 14:05:17 xuxa3 kernel: [0.837512] ... max 
period: 7fff

Jul  5 14:05:17 xuxa3 kernel: [0.837513] ... fixed-purpose events:   3
Jul  5 14:05:17 xuxa3 kernel: [0.837514] ... event 
mask: 000700ff
I don't know if you could help me with this, but as long I see the 
microcode has been loaded and this bugs can be closed Thanks very 
much,El lun, 05-07-2021 a las 14:35 +, Andy Smith escribió:

> Hello,
> 
> On Mon, Jul 05, 2021 at 03:13:17PM +0200, José L. Fernández Jambrina> 
wrote:

> > When booting in Xen mode my system doen't load microcode,
> 
> It is my understanding that when booting the hypervisor it is the

> hypervisor's job to load microcode, and it won't do so unless you
> have something like:
> 
> ucode=scan
> 
> in your hypervisor command line, e.g. by putting:
> 
> GRUB_CMDLINE_XEN="ucode=scan"
> 
> in /etc/default/grub.
> 
> Do you have something like that?
> 
> That will cause the hypervisor to scan the other boot files (kernel

> and initramfs) for microcode to apply, like the kernel itself would
> otherwise do.
> 
> It works for me, anyway.
> 
> Cheers,

> Andy

Bug#990728: virulencefinder: Should Depend on python3-distutils -- renders package unusable

[Nilesh Patra]

Package: virulencefinder
Version: 2.0.3+git20190809.dde157a-2
Severity: serious
X-Debbugs-Cc: nil...@debian.org

Dear Maintainer,

virulencefinder currently test-depends on python3-distutils,
however it really, really should "Depend" on python3-distutils for
there is an import call in the main file

virulencefinder.py:7:from distutils.spawn import find_executable

Nilesh

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

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

Versions of packages virulencefinder depends on:
pn  kma   
pn  ncbi-blast+   
ii  python3   3.9.2-2
pn  python3-cgecore   
pn  python3-tabulate  

virulencefinder recommends no packages.

virulencefinder suggests no packages.

Bug#988502: i think that file name will

[Gürkan Myczko]

not change ever.

cool-retro-term is very lazy about releases, some other fonts got 
updated recently,
however not so terminus, and for terminus exist newer versions over 
sourceforge.net,

however unless someone creates pull requests i don't see it updated.

meanwhile i've updated cool-retro-term packages, see
https://mentors.debian.net/package/cool-retro-term/

Bug#990727: bluetooth service hang laptop startup from time to time

[Andres Z]

Package: bluetooth
Version: 5.55-3.1
Severity: normal
X-Debbugs-Cc: sazamor...@gmail.com

Dear Maintainer,


● bluetooth.service - Bluetooth service
 Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor
preset: enabled)
 Active: active (running) since Mon 2021-07-05 14:28:14 -04; 19min ago
   Docs: man:bluetoothd(8)
   Main PID: 18528 (bluetoothd)
 Status: "Running"
  Tasks: 1 (limit: 18812)
 Memory: 816.0K
CPU: 33ms
 CGroup: /system.slice/bluetooth.service
 └─18528 /usr/libexec/bluetooth/bluetoothd

jul 05 14:28:14 debian bluetoothd[18528]: Bluetooth daemon 5.55
jul 05 14:28:14 debian systemd[1]: Started Bluetooth service.
jul 05 14:28:14 debian bluetoothd[18528]: Starting SDP server
jul 05 14:28:14 debian bluetoothd[18528]: Bluetooth management interface 1.18
initialized
jul 05 14:28:14 debian bluetoothd[18528]:
profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
jul 05 14:28:14 debian bluetoothd[18528]: sap-server: Operation not permitted
(1)
jul 05 14:28:14 debian bluetoothd[18528]: Failed to set mode: Blocked through
rfkill (0x12)
jul 05 14:28:14 debian bluetoothd[18528]: Endpoint registered: sender=:1.89
path=/MediaEndpoint/A2DPSink/sbc
jul 05 14:28:14 debian bluetoothd[18528]: Endpoint registered: sender=:1.89
path=/MediaEndpoint/A2DPSource/sbc
jul 05 14:28:14 debian bluetoothd[18528]: Failed to set mode: Blocked through
rfkill (0x12)




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

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

Versions of packages bluetooth depends on:
ii  bluez  5.55-3.1

bluetooth recommends no packages.

Versions of packages bluetooth suggests:
pn  bluez-cups   
pn  bluez-meshd  
ii  bluez-obexd  5.55-3.1

Bug#990726: resfinder: Should Depend on python3-distutils -- renders package unusable

[Nilesh Patra]

Package: resfinder
Version: 3.2-2
Severity: serious
X-Debbugs-Cc: nil...@debian.org

Dear Maintainer,

resfinder currently test-depends on python3-distutils,
however it really, really should "Depend" on python3-distutils for
there is an import call in the main file

resfinder.py:15:from distutils.spawn import find_executable

Also, it has a problem with literal comparision (is instead of ==) which
should be fixed

Installation warns about: "if databases is '':"

Nilesh

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

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

Versions of packages resfinder depends on:
pn  ncbi-blast+-legacy  
ii  python3 3.9.2-2
pn  python3-cgecore 
pn  python3-tabulate
pn  resfinder-db

resfinder recommends no packages.

resfinder suggests no packages.

Bug#803265: bluetooth.service: sap-server: Operation not permitted (1)

[Sergio Zamora]

On Sat, 31 Oct 2020 01:10:34 +0100 Norbert Lange 
wrote:
> On Fri, 10 Feb 2017 11:09:43 +0100 Laurent Bonnaud
>  wrote:
> > Hi,
> >
> > according to this:
> >
> >
https://raspberrypi.stackexchange.com/questions/40839/sap-error-on-bluetooth-service-status
> >
> > the error messages about SAP can be avoided by starting bluetoothd with
the "--noplugin=sap" option.
> >
> > Since SAP is probably of little use in Debian and since it does not
work anyway, how about disabling it by default?
> >
> > --
> > Laurent.
>
> This repeatedly bites me,
> now the path changed from /usr/lib/bluetooth/bluetoothd to
> /usr/libexec/bluetooth/bluetoothd,
> causing the override to be invalid.
>
> Please figure out why this is an issue, if you can get it to work with
debian,
> and if not disable it.
>
> Norbert
>
>

With the bluetooth adapter down on the Gnome GUI, some startups fail and
freeze totally without being able to continue starting the laptop.

Debian 11.-


● bluetooth.service - Bluetooth service
 Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor
preset: enabled)
 Active: active (running) since Mon 2021-07-05 14:28:14 -04; 9min ago
   Docs: man:bluetoothd(8)
   Main PID: 18528 (bluetoothd)
 Status: "Running"
  Tasks: 1 (limit: 18812)
 Memory: 816.0K
CPU: 33ms
 CGroup: /system.slice/bluetooth.service
 └─18528 /usr/libexec/bluetooth/bluetoothd

jul 05 14:28:14 debian bluetoothd[18528]: Bluetooth daemon 5.55
jul 05 14:28:14 debian systemd[1]: Started Bluetooth service.
jul 05 14:28:14 debian bluetoothd[18528]: Starting SDP server
jul 05 14:28:14 debian bluetoothd[18528]: Bluetooth management interface
1.18 initialized
jul 05 14:28:14 debian bluetoothd[18528]:
profiles/sap/server.c:sap_server_register() Sap driver initialization
failed.
jul 05 14:28:14 debian bluetoothd[18528]: sap-server: Operation not
permitted (1)
jul 05 14:28:14 debian bluetoothd[18528]: Failed to set mode: Blocked
through rfkill (0x12)
jul 05 14:28:14 debian bluetoothd[18528]: Endpoint registered: sender=:1.89
path=/MediaEndpoint/A2DPSink/sbc
jul 05 14:28:14 debian bluetoothd[18528]: Endpoint registered: sender=:1.89
path=/MediaEndpoint/A2DPSource/sbc
jul 05 14:28:14 debian bluetoothd[18528]: Failed to set mode: Blocked
through rfkill (0x12)

--

Bug#990725: xdg-utils: suggestions for the packaging

[Nicolas Boulenguez]

Package: xdg-utils
Version: 1.1.3-4.1
Severity: wishlist
Tags: patch

Hello.

After the freeze, please consider the attached suggestions.

The commit changing autopkgtests requires further discussion.

* Is 'BASH_XTRACEFD=1;set -x' useful?

  './configure' is already quite verbose.
  I suggest that 'echo' is sufficient to say which SHELL is tested.

* Are 'debian/tests/*' sometimes run manually (not by autopkgtest)?

  New shells can be tested otherwise.
  'make autotest SHELL=/bin/bashdb'

  The requirement that test can run outside autopkgtest increases
  their complexity, because they must reinvent autopkgtest.  For
  example,
  * they must check if AUTOPKGTEST_TMP is set
  * else they must safely create a temporary directory
  * and delete it after execution, failure or interruption
  (it is also possible to allow rw-build-tree, but then other problems
  occur, like the need for 'make clean')


xdg-utils.tar.gz
Description: application/gzip

Bug#990724: ITP: librem5-flash-image -- Utility to flash an image onto a Librem 5 device

[Henry-Nicolas Tourneur]

Package: wnpp
Severity: wishlist
Owner: Henry-Nicolas Tourneur 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: librem5-flash-image
  Version : 0.0+git20210705
  Upstream Author : Guido Günther 
* URL : https://source.puri.sm/Librem5/librem5-flash-image
* License : GPL3+
  Programming Lang: Python
  Description : Script to flash an image on a Librem 5 device

 Scripts useful to for working with the Librem 5 and the
 Librem 5 Devkit.
 .
 These tools are useful on the host side (e.g. the machine
 you use to flash the image from). They are not useful on
 the Librem 5 or the Devkit itself.

 This package will be maintained within the Debian On Mobile team.

Bug#990720: d-i.debian.org: [INTL:es] "Install the GRUB boot loader" => "Aunque p"

[Javier Fernandez-Sanguino]

Dear Cyril,

Thank you for forwarding me this bug (and to Federico for reporting). I'll
take a look and fix the string. There is clearly a mistake there.

Saludos,

Javier

El lun., 5 jul. 2021 18:42, Cyril Brulebois  escribió:

> Control: reassign -1 grub-installer 1.172
>
> ¡Ola Federico!
>
> And thanks for your report.
>
> Federico Pinal Moreira  (2021-07-05):
> > Dear Maintainer,
> >
> > Installing with debian-bullseye-DI-rc2-amd64 in spanish I got a prompt
> "Aunque
> > p" where I should have got something like "Instalar el cargador de
> arranque
> > GRUB".
> >
> > grub-installer.templates:28001 @ d-i/packages/po/sublevel1/es.po
>
> This seems to date back to the following commit:
>
> commit abe81e97d4ddef0dc17cc69e35d84c505064b23b
> Author: Javier Fernández-Sanguino 
> Date:   Sun Aug 23 17:03:03 2020 +0200
>
> Update translation and fix typos
>
> See:
>
> https://salsa.debian.org/installer-team/grub-installer/-/commit/9b7b5692e964b70260a7af4197cc017998291543
>
> Specifically:
>
> -msgstr "Instalando el cargador de arranque GRUB"
> +msgstr "Aunque p"
>
> which happened along with unfuzzying that particular message.
>
> Reassigning and cc-ing accordingly. If it were me, I would simply revert
> that single msgstr update, as the original translation doesn't seem
> crazy to me. I'll let Javier or the translation coordinator look at it
> first, as I'm absolutely no Spanish speaker. :)
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>

Bug#990678: budgie-desktop: Software windows don't display correctly, move badly or stay on the screen after being shut

[Pascal]

Package: budgie-desktop
Version: 10.5.2-3
Followup-For: Bug #990678
X-Debbugs-Cc: pascal.mart...@gmx.fr

Dear Maintainer and users,

About this bug with MPV (not being able to move the video window), a good way
to get rid of the problem is by pressing each time "Alt+Tab" (next app). It
kind of refreshes the screen and the window then is displayed correctly. It
should work also with the windows staying displayed on the screen after being
shut. It's just a simple idea to cope with the problem until the bug is
corrected.

Hoping it helps those who hadn't already thought of that.

Cordially,
Pascal.

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

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

Versions of packages budgie-desktop depends on:
ii  budgie-core  10.5.2-3
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-budgie-1.010.5.2-3
ii  gnome-control-center 1:3.38.4-1
ii  gnome-menus  3.36.0-1
ii  network-manager-gnome1.20.0-3

Versions of packages budgie-desktop recommends:
ii  budgie-desktop-view  1.1.1-1

Versions of packages budgie-desktop suggests:
ii  gnome-terminal  3.38.3-1
ii  nautilus3.38.2-1
pn  slick-greeter   

Bug#990720: d-i.debian.org: [INTL:es] "Install the GRUB boot loader" => "Aunque p"

[Cyril Brulebois]

Control: reassign -1 grub-installer 1.172

¡Ola Federico!

And thanks for your report.

Federico Pinal Moreira  (2021-07-05):
> Dear Maintainer,
> 
> Installing with debian-bullseye-DI-rc2-amd64 in spanish I got a prompt "Aunque
> p" where I should have got something like "Instalar el cargador de arranque
> GRUB".
> 
> grub-installer.templates:28001 @ d-i/packages/po/sublevel1/es.po

This seems to date back to the following commit:

commit abe81e97d4ddef0dc17cc69e35d84c505064b23b
Author: Javier Fernández-Sanguino 
Date:   Sun Aug 23 17:03:03 2020 +0200

Update translation and fix typos

See:
  
https://salsa.debian.org/installer-team/grub-installer/-/commit/9b7b5692e964b70260a7af4197cc017998291543

Specifically:

-msgstr "Instalando el cargador de arranque GRUB"
+msgstr "Aunque p"

which happened along with unfuzzying that particular message.

Reassigning and cc-ing accordingly. If it were me, I would simply revert
that single msgstr update, as the original translation doesn't seem
crazy to me. I'll let Javier or the translation coordinator look at it
first, as I'm absolutely no Spanish speaker. :)


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


signature.asc
Description: PGP signature

Bug#990723: unblock: barman/2.12-2

[Christoph Berg]

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

Please unblock package barman

[ Reason ]
The existing package does not support PG13 and users will have a hard
time actually restoring backups from archive.

[ Tests ]
The upstream git repository does contain tests, but the shipped
tarball does not. I have no idea why they thought this is a good idea,
and I'm only fixing this since Marco seems unavailable.

The fix has been confirmed to work upstream and the diff looks sane.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock barman/2.12-2

Thanks,
Christoph

No differences were encountered between the control files

diff -Nru barman-2.12/debian/changelog barman-2.12/debian/changelog
--- barman-2.12/debian/changelog	2020-11-04 10:39:52.0 +0100
+++ barman-2.12/debian/changelog	2021-07-05 17:59:18.0 +0200
@@ -1,3 +1,10 @@
+barman (2.12-2) unstable; urgency=medium
+
+  * Team upload.
+  * PG 13 expects wal_keep_size, not wal_keep_segments. (Closes: #990304)
+
+ -- Christoph Berg   Mon, 05 Jul 2021 17:59:18 +0200
+
 barman (2.12-1) unstable; urgency=medium
 
   * New upstream version 2.12
diff -Nru barman-2.12/debian/patches/pg13 barman-2.12/debian/patches/pg13
--- barman-2.12/debian/patches/pg13	1970-01-01 01:00:00.0 +0100
+++ barman-2.12/debian/patches/pg13	2021-07-05 17:59:14.0 +0200
@@ -0,0 +1,125 @@
+commit 45ccd9d2f315ec208eee778eba1333c0aa4a4460
+Author: Abhijit Menon-Sen 
+Date:   Wed Jan 20 19:47:37 2021 +0530
+
+Fetch wal_keep_size, not wal_keep_segments, from Postgres 13
+
+The `wal_keep_segments` parameter introduced in v9.0 was replaced with
+`wal_keep_size` in v13. Running Barman against Postgres 13 resulted in
+errors like the following being logged:
+
+barman ERROR:  unrecognized configuration parameter "wal_keep_segments"
+barman STATEMENT:  SHOW "wal_keep_segments"
+
+Here we change fetch_remote_status() to ask for wal_keep_size if the
+server version is >= 13. We didn't use this value anywhere, so we don't
+need any further changes to adapt to the different return value.
+
+Signed-off-by: Abhijit Menon-Sen 
+
+diff --git a/barman/postgres.py b/barman/postgres.py
+index 2414f77..6664620 100644
+--- a/barman/postgres.py
 b/barman/postgres.py
+@@ -827,7 +827,12 @@ class PostgreSQLConnection(PostgreSQL):
+ pg_settings.append('wal_level')
+ pg_settings.append('hot_standby')
+ pg_settings.append('max_wal_senders')
+-pg_settings.append('wal_keep_segments')
++# Retrieve wal_keep_segments from version 9.0 onwards, until
++# version 13.0, where it was renamed to wal_keep_size
++if self.server_version < 13:
++pg_settings.append('wal_keep_segments')
++else:
++pg_settings.append('wal_keep_size')
+ 
+ if self.server_version >= 90300:
+ pg_settings.append('data_checksums')
+diff --git a/doc/manual/42-server-commands.en.md b/doc/manual/42-server-commands.en.md
+index 90caea7..20e91d9 100644
+--- a/doc/manual/42-server-commands.en.md
 b/doc/manual/42-server-commands.en.md
+@@ -198,7 +198,8 @@ record of the transaction log. When the status file needs to be
+ cleaned, the `--reset` option can be used.
+ 
+ > **IMPORTANT:** If you are not using replication slots, you rely
+-> on the value of `wal_keep_segments`. Be aware that under high peeks
++> on the value of `wal_keep_segments` (or `wal_keep_size` from
++> PostgreSQL version 13.0 onwards). Be aware that under high peaks
+ > of workload on the database, the `receive-wal` process
+ > might fall behind and go out of sync. As a precautionary measure,
+ > Barman currently requires that users manually execute the command with the
+#diff --git a/tests/test_postgres.py b/tests/test_postgres.py
+#index 83c9f14..67636bb 100644
+#--- a/tests/test_postgres.py
+#+++ b/tests/test_postgres.py
+#@@ -822,6 +822,8 @@ class TestPostgres(object):
+#new_callable=PropertyMock)
+# @patch('barman.postgres.PostgreSQLConnection.is_in_recovery',
+#new_callable=PropertyMock)
+#+@patch('barman.postgres.PostgreSQLConnection.has_backup_privileges',
+#+   new_callable=PropertyMock)
+# @patch('barman.postgres.PostgreSQLConnection.is_superuser',
+#new_callable=PropertyMock)
+# @patch('barman.postgres.PostgreSQLConnection.server_txt_version',
+#@@ -847,6 +849,7 @@ class TestPostgres(object):
+#has_pgespresso_mock,
+#server_txt_version_mock,
+#is_superuser_mock,
+#+   has_backup_privileges_mock,
+#is_in

Bug#990627: python3-torchaudio: torchaudio import aborts

[Jochen Sprickerhof]

Control: tags -1 moreinfo

Hi John,

* John O'Hagan  [2021-07-03 12:48]:

The line "import torchaudio" at the python interactive shell or in a python
script or imported file results in the progra aborting with the following
output:


I tried this on a fresh amd64 bullseye installation and was not able to 
reproduce it. Can you make sure that all installed files are ok with 


sudo dpkg -V

and that you don't have any additional files installed (like torch or 
tensorflow from pip), also check 


$HOME/.local/lib/python3*/site-packages

and 


/usr/local/lib/python3*/dist-packages

Cheers Jochen


signature.asc
Description: PGP signature

Bug#990534: arduino: Arduino-IDE not starting witch Cinnamon Desktop.

[Thorsten Glaser]

On Mon, 5 Jul 2021, Carsten Schoenert wrote:

> > $ ls -la /usr/bin/java
> > lrwxrwxrwx 1 root root 22 19. Jun 2017  /usr/bin/java -> 
> > /etc/alternatives/java
> > $ ls -la /etc/alternatives/java
> > lrwxrwxrwx 1 root root 43  8. Nov 2018  /etc/alternatives/java -> 
> > /usr/lib/jvm/java-11-openjdk-amd64/bin/java

You can also use 「readlink -f $(which java)」, which finds
the java binary from $PATH. Do also manually inspect the
output of 「which -a java」 which shows all java binaries
reachable from $PATH, and whether any of the environment
variables, like $JAVA_HOME, are set (they shouldn’t, in a
normal Debian installation with one JRE installed).

> I've recently discovered similar problems elsewhere and I needed to
> reinstall the openjdk packages. So it's possible that some symlinking
> isn't correct.

You should use update-java-alternatives for that.

> It's also possible that something is changing the variable JAVA_OPTIONS
> that is finally used in the wrapper.
> 
> You can simply add a line like this right before the last line in the
> wrapper script.
> 
> > JAVA_OPTIONS+=("-splash:$APPDIR/lib/splash.png")
> >  fi
> >  
> > +echo "Using JAVA_OPTIONS: $JAVA_OPTIONS"

This will show only the first array element. You’ll need:
echo "Using JAVA_OPTIONS: ${JAVA_OPTIONS[*]}"

> >  "$JAVA" "${JAVA_OPTIONS[@]}" processing.app.Base "$@"
> 
> Then please call arduino again from CLI.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*

Bug#990721: RFS: pt2-clone/1.31+ds-1 -- Music tracker clone of ProTracker 2 for modern computers

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pt2-clone":

 * Package name: pt2-clone
   Version : 1.31+ds-1
   Upstream Author : Olav "8bitbubsy" Sørensen 
 * URL : https://16-bits.org/pt.php
 * License : zlib-style, BSD-3-clause
 * Vcs : https://salsa.debian.org/multimedia-team/pt2-clone
   Section : sound

It builds those binary packages:

  protracker - transitional dummy package
  pt2-clone - Music tracker clone of ProTracker 2 for modern computers

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


  https://mentors.debian.net/package/pt2-clone/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/p/pt2-clone/pt2-clone_1.31+ds-1.dsc


Changes since the last upload:

 pt2-clone (1.31+ds-1) experimental; urgency=medium
 .
   * New upstream version.

Regards,
--
  Gürkan Myczko

Bug#990722: RFS: cool-retro-term/1.1.1+git20210605-1 -- terminal emulator which mimics old screens

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "cool-retro-term":

 * Package name: cool-retro-term
   Version : 1.1.1+git20210605-1
   Upstream Author : Filippo Scognamiglio 
 * URL : https://github.com/Swordfish90/cool-retro-term
 * License : OFL-1.1, dfsg-compliant-text, BSD-3-clause, MIT, 
GPL-3
 * Vcs : 
https://salsa.debian.org/myczko-guest/cool-retro-term

   Section : x11

It builds those binary packages:

  fonts-proggy - Monospaced bitmap programming font
  fonts-terminus - Terminus monospace font
  fonts-hermit - Monospace Hermit Font for programming
  qml-module-qmltermwidget - QML port of qtermwidget
  cool-retro-term - terminal emulator which mimics old screens

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


  https://mentors.debian.net/package/cool-retro-term/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/c/cool-retro-term/cool-retro-term_1.1.1+git20210605-1.dsc


Changes since the last upload:

 cool-retro-term (1.1.1+git20210605-1) experimental; urgency=medium
 .
   * New upstream version.
   * Bump standards version to 4.5.1.

Regards,
--
  Gürkan Myczko

Bug#990720: d-i.debian.org: [INTL:es] "Install the GRUB boot loader" => "Aunque p"

[Federico Pinal Moreira]

Package: d-i.debian.org
Severity: wishlist
Tags: l10n
X-Debbugs-Cc: f...@fsfe.org

Dear Maintainer,

Installing with debian-bullseye-DI-rc2-amd64 in spanish I got a prompt "Aunque
p" where I should have got something like "Instalar el cargador de arranque
GRUB".

grub-installer.templates:28001 @ d-i/packages/po/sublevel1/es.po

Best regards

Bug#990719: unblock: tracker-miners/2.3.5-2.1

[Guido Günther]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-gnome-maintain...@lists.alioth.debian.org

Please unblock package tracker-miners

[ Reason ]
The filesystem miner crashes repeatedly on (at least) arm64 and linux
5.11 or later kernels. See #983637.

Due to a missing syscall whitelist of the miner's sandbox the filesystem
tracker crashes repeatedly on startup.  This doesn't happen on bullseye
amd64 and linux 5.10 but can be reproduced on amd64 and (at least)
kernel 5.11 or later.

[ Impact ]
Makes the miner unusable but also drains the battery quickly since
systemd restarts the miner unconditionally and endlessly. This is
especially bad if core files are enabled since the writing of those
over and over drains battery even quicker.

[ Tests ]
Whether the service is up can be checked via

   systemctl start --user tracker-miner-fs.service

[ Risks ]
The proposed fix is a backport of an upstream fix so
the risk seems minimal. Theoretically allowing more
syscalls in the sandbox could open a security hole.

unblock tracker-miners/2.3.5-2.1
diff --git a/debian/changelog b/debian/changelog
index 353d69ddf..4fa33a6bd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+tracker-miners (2.3.5-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * libtracker-miners-common: Add newstatat/statat64 syscalls.
+Backport upstream commit b3fdbaf to avoid constant crashes every 2s.
+Thanks Julian Andres Klode for forwarding this initially.
+(Closes: #983637)
+
+ -- Guido Günther   Mon, 05 Jul 2021 12:40:50 +0200
+
 tracker-miners (2.3.5-2) unstable; urgency=medium
 
   * Make the 'audio' tests non-fatal on powerpc and sparc64 as well
diff --git a/debian/patches/libtracker-miners-common-Add-newstatat-statat64-syscalls.patch b/debian/patches/libtracker-miners-common-Add-newstatat-statat64-syscalls.patch
new file mode 100644
index 0..832386d2c
--- /dev/null
+++ b/debian/patches/libtracker-miners-common-Add-newstatat-statat64-syscalls.patch
@@ -0,0 +1,24 @@
+From: Carlos Garnacho 
+Date: Sun, 25 Oct 2020 15:37:13 +0100
+Subject: libtracker-miners-common: Add newstatat/statat64 syscalls
+
+These are done in recent glib versions, should be observed here.
+
+(cherry picked from commit b3fdbaf1ab23ce7191ace6db79575dfce5f90881)
+---
+ src/libtracker-miners-common/tracker-seccomp.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/libtracker-miners-common/tracker-seccomp.c b/src/libtracker-miners-common/tracker-seccomp.c
+index c0327eb..01887e8 100644
+--- a/src/libtracker-miners-common/tracker-seccomp.c
 b/src/libtracker-miners-common/tracker-seccomp.c
+@@ -91,6 +91,8 @@ tracker_seccomp_init (void)
+ 	/* Basic filesystem access */
+ 	ALLOW_RULE (fstat);
+ 	ALLOW_RULE (fstat64);
++	ALLOW_RULE (fstatat64);
++	ALLOW_RULE (newfstatat);
+ 	ALLOW_RULE (stat);
+ 	ALLOW_RULE (stat64);
+ 	ALLOW_RULE (statfs);
diff --git a/debian/patches/series b/debian/patches/series
index a9bd2953d..f56af3a1f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@ prefer_systemd_activation.patch
 dont_start_for_root.patch
 Don-t-immediately-restart-tracker-extract-on-SIGSYS.patch
 debian/Revert-build-Include-libdir-in-rpath.patch
+libtracker-miners-common-Add-newstatat-statat64-syscalls.patch

Bug#883911: lmod: new version available upstream

[Jörg Behrmann]

Package: lmod
Version: 6.6-0.4
Followup-For: Bug #883911

The current upstream version is 8.5.8. It would be great if this package could
be updated to the current major release. It could then also bump the dependency
to lua 5.4.


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

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

Versions of packages lmod depends on:
ii  lua-filesystem  1.8.0-1
ii  lua-json1.3.4-2
pn  lua-posix   
pn  lua-term
pn  lua5.2  
ii  tcl 8.6.11+1

lmod recommends no packages.

lmod suggests no packages.

Bug#990717: [Pkg-xen-devel] Bug#990717: xen-system-amd64: Microcode isn't loaded when booting in xen mode

[Andy Smith]

Hello,

On Mon, Jul 05, 2021 at 03:13:17PM +0200, José L. Fernández Jambrina wrote:
> When booting in Xen mode my system doen't load microcode,

It is my understanding that when booting the hypervisor it is the
hypervisor's job to load microcode, and it won't do so unless you
have something like:

ucode=scan

in your hypervisor command line, e.g. by putting:

GRUB_CMDLINE_XEN="ucode=scan"

in /etc/default/grub.

Do you have something like that?

That will cause the hypervisor to scan the other boot files (kernel
and initramfs) for microcode to apply, like the kernel itself would
otherwise do.

It works for me, anyway.

Cheers,
Andy

Bug#920556: lua-md5: lua5.3 support

[Jörg Behrmann]

Package: lua-md5
Version: 1.2+git+1+8d87fee-1.1
Followup-For: Bug #920556

It would be great if lua 5.3 could be added to the package and if the current
version (1.3) could be packaged as well, as right, I need to depend on luarocks
for this package.


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

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

Versions of packages lua-md5 depends on:
ii  libc6  2.31-12

lua-md5 recommends no packages.

lua-md5 suggests no packages.

Bug#990534: arduino: Arduino-IDE not starting witch Cinnamon Desktop.

[Carsten Schoenert]

Hi,

Am 05.07.21 um 10:09 schrieb Rock Storm:
>> thanks fpr your answer. I tried all three points, same result.
>> openjdk-11-jdk was not installed, but also did not help. 
> 
> Hi Sven, I'm out of ideas here then. Thanks for trying.

the starting wrapper /usr/bin/arduino is simply using 'java' as the
binary name to call the JRE binary but does not check if the binary in
the path is usable or suitable.

%<
> JAVA=java
> if [ -x "$APPDIR/java/bin/java" ]; then
>   JAVA=$APPDIR/java/bin/java
> fi
>%

Sven, you could please check where /u/b/java is pointing to? It should
look like this.

> $ ls -la /usr/bin/java
> lrwxrwxrwx 1 root root 22 19. Jun 2017  /usr/bin/java -> 
> /etc/alternatives/java
> $ ls -la /etc/alternatives/java
> lrwxrwxrwx 1 root root 43  8. Nov 2018  /etc/alternatives/java -> 
> /usr/lib/jvm/java-11-openjdk-amd64/bin/java

I've recently discovered similar problems elsewhere and I needed to
reinstall the openjdk packages. So it's possible that some symlinking
isn't correct.

It's also possible that something is changing the variable JAVA_OPTIONS
that is finally used in the wrapper.

You can simply add a line like this right before the last line in the
wrapper script.

> JAVA_OPTIONS+=("-splash:$APPDIR/lib/splash.png")
>  fi
>  
> +echo "Using JAVA_OPTIONS: $JAVA_OPTIONS"
>  "$JAVA" "${JAVA_OPTIONS[@]}" processing.app.Base "$@"

Then please call arduino again from CLI.

-- 
Regards
Carsten

Bug#990718: RFS: duma/2.5.21-1 [ITA] -- Detect Unintended Memory Access (D.U.M.A)

[Peter]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name    : duma
   Version : 2.5.21-1
   Upstream Author : j...@gridfinity.com
 * URL : https://github.com/johnsonjh/duma
 * License : GPL-2
 * Vcs : https://github.com/johnsonjh/duma
   Section : devel

It builds those binary packages:

  duma - Detect Unintended Memory Access (D.U.M.A)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/d/duma/duma_2.5.21-1.dsc

Changes since the last upload:

 duma (2.5.21-1) unstable; urgency=medium
 .
   * Adopt package. (Closes: #565925)
   * New Upstream Release. (Closes: #550660, #623495, #655892, #984041)
   * Use "-U_FORTIFY_SOURCE" in rules file. (Closes: #532483)
   * Reproducible build. (use changelog file date instead of system date)
   * Enable bindnow.
   * Add autopkgtests

Regards,
--
  Peter Blackman



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990717: xen-system-amd64: Microcode isn't loaded when booting in xen mode

[José L . Fernández Jambrina]

Package: xen-system-amd64
Version: 4.11.4+107-gef32c7afa2-1
Severity: important

Dear Maintainer,

When booting in Xen mode my system doen't load microcode, I suposse this is the 
reason I have a line in /var/log/kern.log saying:

|Jun 28 17:09:28 xuxa3 kernel: [3.013020] Performance Events: unsupported 
p6 CPU model 79 no PMU driver, software events only

And perfomamce is degraded:

When booting the system in normal mode, no xen mode, the first two lines 
written in  /var/log/kern.log say:
| Jul  5 14:05:17 xuxa3 kernel: [0.00] microcode: microcode updated 
early to revision 0xb3e, date = 202
1-02-06
| Jul  5 14:05:17 xuxa3 kernel: [0.00] Linux version 4.19.0-17-amd64 
(debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP 
Debian 4.19.194-1 (2021-06-10)

In xen mode the first line insn't written at all.

I can't remenber if the first time I installed xen the microcode was loaded or 
not, but as long as I can check the microcode isn't loaded and the system 
performance is clearly degraded.

  Yours,

Jose L.

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

Kernel: Linux 4.19.0-17-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_ES.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 xen-system-amd64 depends on:
ii  xen-hypervisor-4.11-amd64  4.11.4+107-gef32c7afa2-1
ii  xen-hypervisor-common  4.11.4+107-gef32c7afa2-1
ii  xen-utils-4.11 4.11.4+107-gef32c7afa2-1

xen-system-amd64 recommends no packages.

xen-system-amd64 suggests no packages.

-- no debconf information

Bug#983637: tracker-extract: Add newfstat() to syscall list

[Simon McVittie]

Control: severity -1 grave

On Mon, 05 Jul 2021 at 15:35:29 +0200, Guido Günther wrote:
> For reference, i'm seeing [constant crashes] with these versions on arm64:
> 
>   libc: 2.31-12
>   glib: 2.66.8-1
>   linux: 5.12
> 
> It sure happened with older kernels too.

I think that should be considered RC for bullseye: even if the newer
kernel is necessary to reproduce this, combining bullseye user-space
with newer kernels is not going to be a rare combination. Thanks for
following up on this!

smcv

Bug#990716: libxml2 2.9.12 breaks all PHP versions use of DOMDocument::saveHTML() (Upstream bug #266)

[Patrick Allaert]

Package: libxml2
Version: 2.9.12+dfsg-0+0~20210621.9+debian10~1.gbp43e861
Severity: critical
Tags: upstream
Justification: breaks unrelated software

Dear Maintainer,

Could you please consider the upstream patch? (Upstream issue:
https://gitlab.gnome.org/GNOME/libxml2/-/issues/266)

Thank you,
-Patrick

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/12 CPU cores)
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 libxml2 depends on:
ii  libc6 2.28-10
ii  libicu65  65.1-1+0~20200223.8+debian10~1.gbp519cf3
ii  liblzma5  5.2.4-1
ii  zlib1g1:1.2.11.dfsg-1

libxml2 recommends no packages.

libxml2 suggests no packages.

-- no debconf information

Bug#988623: unblock: kodi-pvr-waipu/2.8.4+ds1-1

[Vasyl Gello]

Control: close -1

Hi Sebastian!

After more thorough review of commits themselves I feel not sure about 
re-authentication issue. So I am closing the bug until some Waipu.tv user 
reopens it.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#983637: tracker-extract: Add newfstat() to syscall list

[Guido Günther]

Hi,
On Mon, Jul 05, 2021 at 02:27:50PM +0100, Simon McVittie wrote:
> On Mon, 05 Jul 2021 at 14:18:12 +0100, Simon McVittie wrote:
> > On Mon, 05 Jul 2021 at 12:43:14 +0200, Guido Günther wrote:
> > > Attached is a diff I'd be happy to NMU to unstable and then ask for an
> > > unblock request.
> > 
> > I'm not a Tracker developer and it's far enough outside my area that I'd
> > prefer not to do a "team upload" for this, but the change seems obviously
> > correct, and I'd be happy with this NMU from the GNOME team point of view.
> 
> I asked on IRC and Laurent said
> 
> <@bigon> If it's merged upstream, I'm ok with it
> 
> so please go ahead.

Thanks! Uploaded. I'll do the unblock request once accepted.
 -- Guido

Bug#990715: prometheus-smokeping-prober: Package is non-functional by default, and steps necessary to make it functional are not documented and non-obvious

[Tim Small]

Package: prometheus-smokeping-prober
Version: 0.4.1-2+b4
Severity: important
X-Debbugs-Cc: t...@seoss.co.uk

Thanks for packaging this in Debian!  Unfortunately it does appear to
have an important problem which I think most users will hit, and is
actually quite difficult to debug.

Installing this package on a default bullseye system results in this
debconf database entry being set, without any prompting:

  prometheus-smokeping-prober/want_cap_net_raw: false

This makes the package fail silently, without any errors (even when run
with --log.level="debug").

The service appears to run correctly, but is unable to send out any ping
probes, and so just records no data (all metrics are zero).  No errors
are logged, and this debconf database setting is not documented
elsewhere in the package.

I think this setting should ideally be defaulted to true, since this is
the way that e.g. iputils-ping operates (it is always installed with
cap_net_raw=ep set).

Whilst I understand the possible security implication of this, since the
package defaults to executing the binary as the prometheus user, this
could perhaps be mitigated by setting the permissions so that
/usr/bin/prometheus-smokeping-prober is NOT world-executable, and has
group ownership set to the prometheus user.  e.g.

chmod 750 /usr/bin/prometheus-smokeping-prober
chgrp prometheus /usr/bin/prometheus-smokeping-prober

If it is preferred for some reason to continue to default this to false,
then I think the question should have at least "high" priority.

Additionally it would be useful to patch the daemon so that it logs when
it is not authorized to send pings, and probably the existance of the
setting should be documented (e.g. in:
/etc/default/prometheus-smokeping-prober or a README.Debian).


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

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

Versions of packages prometheus-smokeping-prober depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.75
ii  libc6  2.31-12
ii  libcap2-bin1:2.44-1

prometheus-smokeping-prober recommends no packages.

prometheus-smokeping-prober suggests no packages.

-- debconf information:
  prometheus-smokeping-prober/want_cap_net_raw: false

Bug#983637: tracker-extract: Add newfstat() to syscall list

[Guido Günther]

Hi,
On Mon, Jul 05, 2021 at 02:18:08PM +0100, Simon McVittie wrote:
> Control: severity -1 important
> Control: tags -1 + patch
> 
> On Mon, 05 Jul 2021 at 12:43:14 +0200, Guido Günther wrote:
> > Attached is a diff I'd be happy to NMU to unstable and then ask for an
> > unblock request.
> 
> I'm not a Tracker developer and it's far enough outside my area that I'd
> prefer not to do a "team upload" for this, but the change seems obviously
> correct, and I'd be happy with this NMU from the GNOME team point of view.
> 
> Is this reproducible with bullseye's libc6 and libglib2.0-0? If it is,
> then I think this should be considered RC for bullseye.
> 
> Even if it's only reproducible with newer libglib2.0-0, I think important
> severity and an unblock request would be appropriate: it seems reasonably
> likely that people will want to upgrade GLib during the bullseye release
> cycle.

For reference, i'm seeing this with these versions on arm64:

  libc: 2.31-12
  glib: 2.66.8-1
  linux: 5.12

It sure happened with older kernels too.
Cheers,
 -- Guido

Bug#971783: mate-volume-control-status-icon dies here too

[Maxime G.]

Hello, same issue here.

I have this bug, it happens randomly without manipulation.
Here the log:


(mate-volume-control-status-icon:362306): Gtk-WARNING **: 08:21:55.878: 
gtk_widget_size_allocate(): attempt to allocate widget with width -7 and height 
1

(mate-volume-control-status-icon:362306): Gtk-WARNING **: 12:58:14.570: Calling 
gtk_widget_realize() on a widget that isn't inside a toplevel window is not 
going to work very well. Widgets must be inside a toplevel container before 
realizing them.

(mate-volume-control-status-icon:362306): GLib-GObject-CRITICAL **: 
12:58:14.570: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

(mate-volume-control-status-icon:362306): Gdk-CRITICAL **: 12:58:14.570: 
gdk_window_get_scale_factor: assertion 'GDK_IS_WINDOW (window)' failed
**
Gtk:ERROR:../../../../gtk/gtkwidget.c:5871:gtk_widget_get_frame_clock: 
assertion failed: (window != NULL)
Bail out! 
Gtk:ERROR:../../../../gtk/gtkwidget.c:5871:gtk_widget_get_frame_clock: 
assertion failed: (window != NULL)
Abandon


Thanks.

Bug#983637: tracker-extract: Add newfstat() to syscall list

[Simon McVittie]

On Mon, 05 Jul 2021 at 14:18:12 +0100, Simon McVittie wrote:
> On Mon, 05 Jul 2021 at 12:43:14 +0200, Guido Günther wrote:
> > Attached is a diff I'd be happy to NMU to unstable and then ask for an
> > unblock request.
> 
> I'm not a Tracker developer and it's far enough outside my area that I'd
> prefer not to do a "team upload" for this, but the change seems obviously
> correct, and I'd be happy with this NMU from the GNOME team point of view.

I asked on IRC and Laurent said

<@bigon> If it's merged upstream, I'm ok with it

so please go ahead.

Thanks,
smcv

Bug#983637: tracker-extract: Add newfstat() to syscall list

[Simon McVittie]

Control: severity -1 important
Control: tags -1 + patch

On Mon, 05 Jul 2021 at 12:43:14 +0200, Guido Günther wrote:
> Attached is a diff I'd be happy to NMU to unstable and then ask for an
> unblock request.

I'm not a Tracker developer and it's far enough outside my area that I'd
prefer not to do a "team upload" for this, but the change seems obviously
correct, and I'd be happy with this NMU from the GNOME team point of view.

Is this reproducible with bullseye's libc6 and libglib2.0-0? If it is,
then I think this should be considered RC for bullseye.

Even if it's only reproducible with newer libglib2.0-0, I think important
severity and an unblock request would be appropriate: it seems reasonably
likely that people will want to upgrade GLib during the bullseye release
cycle.

Thanks,
smcv

Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709

[spi]

 From the above description one thin is not fully clear to me, so
aksing specifically: Is this a regression introduced with the
4.19.194-1 upload or can you reproduce the issue earlier?



I had no spontaneous reboots within the last years so yes, the issue
seems to got introduced with one of the recent kernels in the last few
months.


If a new regression introduced, can you possibly bisect to the
introducing commit?

Can you reproduce the issue with recent kernel from unstable or
buster-backports?



I'm going to try a more recent kernel from backports or unstable to see
if issue still persist. As I this issue only pops up while using bonding
interfaces on a multiport GBE NIC I wonder if there is "just" a
configuration issue with the bonding interfaces.

Cheers
spi

Bug#990585: patch to fix

[elfleg0las]

I found this bug on frr repo:

https://github.com/FRRouting/frr/issues/8521

and here fix:

https://github.com/FRRouting/frr/pull/8533

patch:

https://github.com/FRRouting/frr/pull/8533/commits/7573cb86a259d3c9ef6eae9dd5d529f8080922cd

Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Sat, Jul 03, 2021 at 05:26:04PM +0200, s...@gmxpro.de wrote:
> Package: src:linux
> Version: 4.19.194-1
> Severity: important
> 
> 
> 
> -- Package-specific info:
> ** Version:
> Linux version 4.19.0-17-amd64 (debian-ker...@lists.debian.org) (gcc
> version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.194-1 (2021-06-10)
> 
> ** Command line:
> placeholder root=/dev/mapper/srvxen04-root ro console=ttyS0,115200n8
> console=tty0 intel_iommu=on nomodeset net.ifnames=1 biosdevname=0
> 
> ** Not tainted
> 
> ** Kernel log:
> [   39.592859] vif vif-1-0 vif-fw2-OAM: renamed from vif1.0
> [   39.620827] vif vif-1-3 vif-fw2-FE: renamed from vif1.3
> [   39.648849] vif vif-1-2 vif-fw2-DMZ0: renamed from vif1.2
> [   39.676964] vif vif-1-6 vif-fw2-TEST: renamed from vif1.6
> [   39.712828] vif vif-1-8 vif-fw2-HOME: renamed from vif1.8
> [   39.796755] brLAN: port 2(vif-fw2-LAN) entered blocking state
> [   39.802908] brLAN: port 2(vif-fw2-LAN) entered disabled state
> [   39.809479] device vif-fw2-LAN entered promiscuous mode
> [   39.815267] brOAM: port 2(vif-fw2-OAM) entered blocking state
> [   39.821493] brOAM: port 2(vif-fw2-OAM) entered disabled state
> [   39.827692] device vif-fw2-OAM entered promiscuous mode
> [   39.833365] brWLAN: port 2(vif-fw2-WLAN) entered blocking state
> [   39.839769] brWLAN: port 2(vif-fw2-WLAN) entered disabled state
> [   39.846161] device vif-fw2-WLAN entered promiscuous mode
> [   39.851967] brDMZ0: port 2(vif-fw2-DMZ0) entered blocking state
> [   39.858295] brDMZ0: port 2(vif-fw2-DMZ0) entered disabled state
> [   39.864659] device vif-fw2-DMZ0 entered promiscuous mode
> [   39.874675] brFE: port 2(vif-fw2-FE) entered blocking state
> [   39.880621] brFE: port 2(vif-fw2-FE) entered disabled state
> [   39.886968] device vif-fw2-FE entered promiscuous mode
> [   39.893906] brRLAN: port 2(vif-fw2-RLAN) entered blocking state
> [   39.900254] brRLAN: port 2(vif-fw2-RLAN) entered disabled state
> [   39.907304] device vif-fw2-RLAN entered promiscuous mode
> [   39.915348] brTEST: port 2(vif-fw2-TEST) entered blocking state
> [   39.921718] brTEST: port 2(vif-fw2-TEST) entered disabled state
> [   39.928290] device vif-fw2-TEST entered promiscuous mode
> [   39.934666] brBE: port 2(vif-fw2-BE) entered blocking state
> [   39.940616] brBE: port 2(vif-fw2-BE) entered disabled state
> [   39.946814] device vif-fw2-BE entered promiscuous mode
> [   39.953792] brHOME: port 2(vif-fw2-HOME) entered blocking state
> [   39.960107] brHOME: port 2(vif-fw2-HOME) entered disabled state
> [   39.966581] device vif-fw2-HOME entered promiscuous mode
> [   42.160336] xen-blkback: backend/vbd/1/51712: using 1 queues,
> protocol 1 (x86_64-abi)
> [   42.353338] vif vif-1-0 vif-fw2-OAM: Guest Rx ready
> [   42.358612] brOAM: port 2(vif-fw2-OAM) entered blocking state
> [   42.364733] brOAM: port 2(vif-fw2-OAM) entered forwarding state
> [   42.378050] vif vif-1-1 vif-fw2-LAN: Guest Rx ready
> [   42.383309] brLAN: port 2(vif-fw2-LAN) entered blocking state
> [   42.389427] brLAN: port 2(vif-fw2-LAN) entered forwarding state
> [   42.428330] vif vif-1-2 vif-fw2-DMZ0: Guest Rx ready
> [   42.433682] brDMZ0: port 2(vif-fw2-DMZ0) entered blocking state
> [   42.440053] brDMZ0: port 2(vif-fw2-DMZ0) entered forwarding state
> [   42.448264] vif vif-1-3 vif-fw2-FE: Guest Rx ready
> [   42.453429] brFE: port 2(vif-fw2-FE) entered blocking state
> [   42.459409] brFE: port 2(vif-fw2-FE) entered forwarding state
> [   42.467498] vif vif-1-4 vif-fw2-BE: Guest Rx ready
> [   42.472669] brBE: port 2(vif-fw2-BE) entered blocking state
> [   42.478647] brBE: port 2(vif-fw2-BE) entered forwarding state
> [   42.486688] vif vif-1-5 vif-fw2-WLAN: Guest Rx ready
> [   42.492049] brWLAN: port 2(vif-fw2-WLAN) entered blocking state
> [   42.498370] brWLAN: port 2(vif-fw2-WLAN) entered forwarding state
> [   42.506575] vif vif-1-6 vif-fw2-TEST: Guest Rx ready
> [   42.511964] brTEST: port 2(vif-fw2-TEST) entered blocking state
> [   42.518364] brTEST: port 2(vif-fw2-TEST) entered forwarding state
> [   42.526458] vif vif-1-7 vif-fw2-RLAN: Guest Rx ready
> [   42.531790] brRLAN: port 2(vif-fw2-RLAN) entered blocking state
> [   42.538105] brRLAN: port 2(vif-fw2-RLAN) entered forwarding state
> [   42.546365] vif vif-1-8 vif-fw2-HOME: Guest Rx ready
> [   42.551699] brHOME: port 2(vif-fw2-HOME) entered blocking state
> [   42.557990] brHOME: port 2(vif-fw2-HOME) entered forwarding state
> [   52.749924] brBE: port 2(vif-fw2-BE) entered disabled state
> [   52.857180] vif vif-1-4 vif-fw2-BE: Guest Rx ready
> [   52.862389] brBE: port 2(vif-fw2-BE) entered blocking state
> [   52.868356] brBE: port 2(vif-fw2-BE) entered forwarding state
> [   53.011574] vif vif-1-4 vif-fw2-BE: Guest Rx ready
> [   53.011597] NOHZ: local_softirq_pending 08
> [   53.145228] vif vif-1-3 vif-fw2-FE: Guest Rx ready
> [   53.253183] vif vif-1-3 vif-fw2-FE: Guest Rx ready
> [   53.253214] NOHZ: local_softirq_pending 08
> [

Bug#706061: opendkim: Suggest creating /etc/opendkim/ (or equivalent) directory to store configuration files

[David Bürgin]

Control: tags -1 wontfix

I fundamentally agree that a dedicated directory in /etc for some
software package is the right way. I disagree with doing that now, only
in Debian, only for the OpenDKIM package.

I think the way forward would be to propose the change to upstream, for
all of OpenDKIM, OpenDMARC, OpenARC. That way the change could
eventually be rolled out everywhere evenly.

Bug#990714: thermald: Thermald cannot control CPU if intel_pstate status is passive

[Paul Cercueil]

Package: thermald
Version: 2.4.2-1
Severity: important

Dear Maintainer,

On my system (Asus N56VB with a i7-3630QM), the intel_pstate status is
"passive" by default.

This prevents thermald from being able to control the CPU frequency. Manually
switching it to "active" makes it work.

I address the problem locally, with a /etc/tmpfiles.d/pstate.conf file with the
following content:
w /sys/devices/system/cpu/intel_pstate/status - - - - active

Then thermald works perfectly.

I suppose the Debian package of thermald should provide a similar file.

Cheers,
-Paul

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (200, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages thermald depends on:
ii  libc6 2.31-12
ii  libdbus-1-3   1.12.20-2
ii  libdbus-glib-1-2  0.110-6
ii  libevdev2 1.11.0+dfsg-1
ii  libgcc-s1 10.2.1-6
ii  libglib2.0-0  2.66.8-1
ii  liblzma5  5.2.5-2
ii  libstdc++610.2.1-6
ii  libupower-glib3   0.99.11-2
ii  libxml2   2.9.10+dfsg-6.7
ii  lsb-base  11.1.0

thermald recommends no packages.

thermald suggests no packages.

-- Configuration Files:
/etc/thermald/thermal-cpu-cdev-order.xml changed:




intel_pstate

Bug#990704: Debian's installer's GRUB installer into a new non-primary drive (sdb) makes booting new Debian drive unbootable.

[Ant]

Package: debian-installer
Version: 
https://gemmei.ftp.acc.umu.se/debian-cd/current/amd64/iso-cd/debian-10.10.0-amd64-netinst.iso
 and 
https://gemmei.ftp.acc.umu.se/cdimage/unofficial/non-free/cd-including-firmware/bullseye_di_rc2+nonfree/amd64/iso-cd/firmware-bullseye-DI-rc2-amd64-netinst.iso
Severity: important
File: debian-installer

Downloaded, mounted, and booted Debian's net installer ISO (e.g., 
https://gemmei.ftp.acc.umu.se/debian-cd/current/amd64/iso-cd/debian-10.10.0-amd64-netinst.iso
 and 
https://gemmei.ftp.acc.umu.se/cdimage/unofficial/non-free/cd-including-firmware/bullseye_di_rc2+nonfree/amd64/iso-cd/firmware-bullseye-DI-rc2-amd64-netinst.iso)
 
into an old 64-bit W7 HPE SP1 VirtualBox v6.1 VM with a brand new virtual SSD 
(2 virtual drives = 1 old W7 HDD + 1 new 
blank SSD). I'm trying it before doing it virtually instead of my real physical 
PC to learn and practice (don't want to 
hose my 12 yrs. old real hardware production PC!). I picked most of Debian's 
defaults (no GUI packages to install for 
now). I'm currently having problems with its GRUB bootloader part.

I told it no to its "Install the GRUB boot loader to your primary drive." 
(https://i.ibb.co/1b2TYbr/primary.gif) and 
picked /dev/sdb (new virtual SSD) as shown in 
https://i.ibb.co/pRKBjBZ/2SDs.gif. I do NOT want to use its GRUB for dual 
booting. I'll manually boot the specific drive to boot its specific OS from 
BIOS' boot menu. Anyways, it completed. I 
told BIOS to boot the new SSD with Debian, but it got stuck with a blank black 
screen with its blinking _ cursor: 
https://i.ibb.co/v4xWdMP/rebooted-Stuck.gif. My 64-bit W7's drive still boots 
though.

I tried again with Buster v10.10, but got the same exact results. If I tell 
Debian installer to install its GRUB 
bootloader into the primary and /dev/sdb, then it will work but I get W7 in 
GRUB's boot loader which I don't want. 
https://groups.google.com/g/alt.os.linux.debian/c/Ww_-hii7o_Y/m/MUUni-hxAgAJ 
says Jack was able to reproduce it as well 
with his Debian installation, but not with Mint. There seems to be a bug in 
Debian's installers? :(

Thank you for reading and hopefully answering soon. :)

Bug#990440: debianutils: manage /etc/shells declaratively using triggers

[Helmut Grohne]

Hi Clint,

On Mon, Jul 05, 2021 at 11:46:58AM +, Clint Adams wrote:
> Why not put the shells.d directory in /etc so that dpkg's conffiles
> handling can be used to preserve admin changes?

Thank you for looking at it in more detail. It's good question with a
non-obvious answer.

TL;DR: Been there. Done that. Don't repeat.

The issue is that files in /etc are conffiles. conffiles persist on
package removal. Say you remove ksh. /etc/shells.d/ksh would be kept and
thus /etc/shells would continue to contain ksh. Only on purge of ksh,
ksh would disappear from /etc/shells. That's not what we want here.

Beyond this, I've been burned by dpkg bugs when it comes to activating
triggers on conffiles. See #88010 for the long story. Possibly they're
all sorted out now. Maybe not.

Also keep in mind that an administrator modifying a conffile will not
automatically invoke the trigger. So you may end up with a situation
where you modify /etc/shells.d/ksh. It doesn't take effect. You install
screen and suddenly /etc/shells is updated with your modification
performed months ago.

Let me know if something else pops up.

Helmut

Bug#903998: topal: suggestions for the packaging

[Nicolas Boulenguez]

Package: topal
Followup-For: Bug #903998

Hello.

An updated version of the suggestions is attached.

The upstream changes (first patch) are rebased on version 80, and
slightly improved.  The diff is a mess, but can only be split into
small testable commits once you have selected the ideas.

The remaining patches affect the Debian packaging. Few of them depend
on the upstream changes.


topal.tar.gz
Description: application/gzip

Bug#990440: debianutils: manage /etc/shells declaratively using triggers

[Clint Adams]

Another question:

Why not put the shells.d directory in /etc so that dpkg's conffiles
handling can be used to preserve admin changes?

Bug#990240: soapyosmo: does not link with boost chrono

[Radoslaw Biernacki]

> Fwiw, sdrangelove itself is quite obsolete and afaict hasn't seen any
> updates for years. The successor is sdrangel which I'm trying to
> package, but haven't finished reviewing the copyrights yet. Apart from
> that, the package is ready:
>
> https://salsa.debian.org/debian-hamradio-team/sdrangel

I would love to see sdrangel in debian!
Christoph, How many beers do I owe you? :D

Bug#990713: RFP: cargo-c -- cargo applet to build and install C-ABI-compatible dynamic and static libraries

[Simon McVittie]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net, 
libr...@packages.debian.org

* Package name: cargo-c
  Version : 0.9.1
  Upstream Author : Luca Barbato
* URL : https://github.com/lu-zero/cargo-c
* License : MIT/X11 (Expat)
  Programming Lang: Rust
  Description : cargo applet to build and install C-ABI-compatible dynamic 
and static libraries

Future versions of librsvg are likely to require cargo-c >= 0.9 as
a build-dependency. I don't know Rust, so I am not able to package or
maintain this myself.

smcv

Bug#990712: dpkg: triggers database contains architecture qualifiers in a non-reproducible way when changing the dpkg architecture

[Helmut Grohne]

Package: dpkg
Version: 1.20.9
X-Debbugs-Cc: jo...@debian.org

Hi Guillem,

this issue is co-reported by josch. While working on DPKG_ROOT
reproducibility, we observed that the trigger database differs for the
foreign and native case. In the foreign case, packages would carry an
architecture qualifier while a native case would lack them. The problem
is actually entirely independent of DPKG_ROOT and can be reproduced in
an essential chroot with e.g. amd64 native and i386 foreign. A simple
example package is man-db. Installing man-db:amd64, gives a trigger
database without architecture qualifiers while installing man-db:i386
gives one that includes them.

This is a problem both to using DPKG_ROOT for creating foreign
installations and for cross grading an installation.

While this may be solved by improving dpkg's notion of which
architecture is native when operating on a --root, I think in this case,
always including the architecture qualifier (for architecture-dependent
packages) would be the better option.

You hinted that commit d658a8ec1110c9b3b20987cd903a54f59801117f may be
at fault. I'm recording that here for your convenience.

Helmut

Bug#989236: crossgrader: crashes with "Could not mark python3-apt:amd64 for install, fixing manually."

[Steve McIntyre]

On Wed, Jun 30, 2021 at 08:56:51PM +0200, Adam Borowski wrote:
>Control: severity -1 serious
>
>On Mon, May 31, 2021 at 05:01:35PM +0200, Adam Borowski wrote:
>> On Mon, May 31, 2021 at 07:08:22AM -0700, Kevin Wu wrote:
>> > On Mon, May 31, 2021 at 4:26 AM Adam Borowski  wrote:
>> > > But, is there _any_ case when crossgrader might possibly work?  As it 
>> > > needs
>> > > python-apt-common, it will always fail.  That makes the package useless.
>> > > Should we bump #968458 to a RC severity?
>> > 
>> > crossgrader won't be able to work if python3-apt cannot be
>> > crossgraded, so there's no case where it would work. Would #968458
>> > merit critical for breaking unrelated software?
>
>As the other bug hasn't been fixed, crossgrader as it stands in Bullseye is
>useless.  So either we convince David to reconsider or a workaround has to
>be found.

Julian has just uploaded with the fix we need, so that should make
things better. Dropping severity.

(We'll probably need a fix for #990669, even so...)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[jim_p]

Source: linux
Followup-For: Bug #989010
X-Debbugs-Cc: pitsior...@gmail.com

There are 2 words that can completely justify my "appaling lack of respect for
debian developers": hardware failure. And it happened not once, but twice.
Plus, the support I received from here is non existant in every troubleshooting
step I made.

Do you see any response now that the requested logs are at anyone's disposal?
Did you see anyone replying on how will I get those logs when I asked before?
Did you see any meaningful response to why did a card that had nothing to do
with the nvidia driver (the ati one) died after a few boots with 5.10.38/40?
No to all I guess. So, do you still call all that "support"? Because I
definitely don't. All I see is an "nvidia is bad" attitude which has no
foundations.

On the other hand, the only good thing all this... condition has caused is for
me to see how bad nouveau is compared to nvidia. I already knew it was bad
before that, but now I have experienced it and I can judge it from every
aspect.

Tomorrow marks 30 full days and ~100 boots without a single issue and that is
because I stayed on 5.10.28. I would try a newer kernel if I could afford a new
card. Unfortunately I don't. I will stick to it as much as I can, but, as I see
it, in the very end, I will probably upgrade straight to 5.13+ or move to arch.
The latter seems more probable btw.

Last but not least, for me, this issue remains of critical severity despite the
downgrade it got. And I am sure if anyone of you faced the same you would have
a similar attitude.
Have a nice day.

p.s. In case anyone is wondering why arch and not some other distro like
opensuse or fedora or anything, the reason is simple. Arch, via aur, can still
provide me with nvidia 340, the other distros can't.

Bug#983637: tracker-extract: Add newfstat() to syscall list

[Guido Günther]

Hi,
On Thu, Jun 24, 2021 at 11:40:04AM +0200, Guido Günther wrote:
> Hi,
> On Sat, Feb 27, 2021 at 05:16:04PM +0100, Julian Andres Klode wrote:
> > Package: tracker-miners
> > Version: 2.3.5-2
> > Severity: normal
> > Tags: patch
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu hirsute ubuntu-patch
> > X-Debbugs-Cc: juli...@ubuntu.com
> > 
> > In Ubuntu, the attached patch was applied to achieve the following:
> > 
> > Fix tracker-extract crashing constantly with new glibc.
> 
> I somehow missed this bug when preparing
> 
> https://salsa.debian.org/gnome-team/tracker-miners/-/merge_requests/14
> 
> but i can confirm missing 'newfsstat` crashes the miner constantly like
> 
> Program terminated with signal SIGSYS, Bad system call.
> #0  __GI___xstat (vers=, name=0x803cd178 "/etc/localtime", 
> buf=0x4ae26bd0) at ../sysdeps/unix/sysv/linux/generic/xstat.c:36
> 36../sysdeps/unix/sysv/linux/generic/xstat.c: No such file or directory.
> [Current thread is 1 (Thread 0x4ae28050 (LWP 3217))]
> (gdb) bt
> #0  __GI___xstat (vers=, name=0x803cd178 "/etc/localtime", 
> buf=0x4ae26bd0) at ../sysdeps/unix/sysv/linux/generic/xstat.c:36
> #1  0x8033411c in __tzfile_read (file=file@entry=0x803cd178 
> "/etc/localtime", extra=extra@entry=0, extrap=extrap@entry=0x0) at 
> tzfile.c:155
> #2  0x80333cd0 in tzset_internal (always=always@entry=1) at 
> tzset.c:405
> #3  0x80333e14 in __tzset () at tzset.c:551
> #4  0x80332b14 in __GI_mktime (tp=tp@entry=0x4ae26d00) at 
> mktime.c:529
> #5  0x8094e7a0 in tracker_date_format_to_iso8601 
> (date_string=date_string@entry=0x4ae26d68 "2021:04:26 16:10:14", 
> format=format@entry=0x80952200 "%Y:%m:%d %H:%M:%S")
> at ../src/libtracker-extract/tracker-utils.c:464
> #6  0x8094a4a8 in get_date (exif=exif@entry=0x2c00ff20, 
> tag=tag@entry=EXIF_TAG_DATE_TIME) at 
> ../src/libtracker-extract/tracker-exif.c:83
> #7  0x8094b154 in parse_exif (buffer=buffer@entry=0x2c014840 
> "Exif", len=len@entry=342, data=data@entry=0x2c00f6e0, uri=0x2c0105d0 
> "file:///home/purism/Pictures/IMG20210426161014.jpg")
> at ../src/libtracker-extract/tracker-exif.c:478
> #8  0x8094bc7c in tracker_exif_new 
> (buffer=buffer@entry=0x2c014840 "Exif", len=len@entry=342, 
> uri=uri@entry=0x2c0105d0 
> "file:///home/purism/Pictures/IMG20210426161014.jpg")
> at ../src/libtracker-extract/tracker-exif.c:614
> #9  0x7c32faec in tracker_extract_get_metadata (info=0xd820b040) 
> at ../src/tracker-extract/tracker-extract-jpeg.c:230
> #10 0xb303f620 in get_file_metadata (task=task@entry=0xd850f590, 
> info_out=info_out@entry=0x4ae277e0) at 
> ../src/tracker-extract/tracker-extract.c:302
> #11 0xb303fd80 in get_metadata (task=0xd850f590) at 
> ../src/tracker-extract/tracker-extract.c:511
> #12 0xb303fdd4 in single_thread_get_metadata (queue=0xd8515200) 
> at ../src/tracker-extract/tracker-extract.c:539
> #13 0x805468f4 in g_thread_proxy (data=0xd8522a40) at 
> ../../../glib/gthread.c:820
> #14 0x80419628 in start_thread (arg=0x4ae27950) at 
> pthread_create.c:477
> #15 0x8037101c in thread_start () at 
> ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
> 
> and with the above it fixes it for me. The bug should likely have a
> higher priority since when e.g. systemd-coredump is installed as well
> the crash every 2s and writing the core file is a real battery drain.

Attached is a diff I'd be happy to NMU to unstable and then ask for an
unblock request.

Cheers,
 -- Guido
diff --git a/debian/changelog b/debian/changelog
index 353d69ddf..4fa33a6bd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+tracker-miners (2.3.5-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * libtracker-miners-common: Add newstatat/statat64 syscalls.
+Backport upstream commit b3fdbaf to avoid constant crashes every 2s.
+Thanks Julian Andres Klode for forwarding this initially.
+(Closes: #983637)
+
+ -- Guido Günther   Mon, 05 Jul 2021 12:40:50 +0200
+
 tracker-miners (2.3.5-2) unstable; urgency=medium
 
   * Make the 'audio' tests non-fatal on powerpc and sparc64 as well
diff --git a/debian/patches/libtracker-miners-common-Add-newstatat-statat64-syscalls.patch b/debian/patches/libtracker-miners-common-Add-newstatat-statat64-syscalls.patch
new file mode 100644
index 0..832386d2c
--- /dev/null
+++ b/debian/patches/libtracker-miners-common-Add-newstatat-statat64-syscalls.patch
@@ -0,0 +1,24 @@
+From: Carlos Garnacho 
+Date: Sun, 25 Oct 2020 15:37:13 +0100
+Subject: libtracker-miners-common: Add newstatat/statat64 syscalls
+
+These are done in recent glib versions, should be observed here.
+
+(cherry picked from commit b3fdbaf1ab23ce7191ace6db79575dfce5f90881)
+---
+ src/libtracker-miners-common/tracker-seccomp.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/

Bug#990240: soapyosmo: does not link with boost chrono

[Christoph Berg]

Re: tony mancill
> However, the patched build alone does not resolve the crash of
> sdrangelove on my system until I also install the updated hamlib4 from
> experimental.  That is, sdrangelove appears to be affected by 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980472.
> 
> I'm not sure what the plans are for the hamlib4 with respect to
> Bullseye.

4.0 is probably not the ideal version to have in bullseye, but it's a
great improvement over the version we had before (which was missing
support for many transceivers on the market today).

Hamlib 4.1 is unfortunately incompatible with 4.0 in some internal
data structures (which are supposed to be opaque, but aren't always in
practise), so updating to that would need fixes in other programs (I
know about wsjtx, see libhamlib4's Breaks:). I don't think we can or
should try to push that into bullseye.

> Any concerns with an upload of soapyosmo to get us one step
> closer?  

Seems sensible to me.

Fwiw, sdrangelove itself is quite obsolete and afaict hasn't seen any
updates for years. The successor is sdrangel which I'm trying to
package, but haven't finished reviewing the copyrights yet. Apart from
that, the package is ready:

https://salsa.debian.org/debian-hamradio-team/sdrangel

Christoph

Bug#990711: unblock: debian-games/4

[Markus Koschany]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: a...@debian.org

Please unblock package debian-games

[ Reason ]

debian-games is a metapackage that only recommends or suggests games.
This is an update to include the changes that occurred in the past
months during the freeze. Packages which were removed from Debian or
will not be part of Debian 11 have been either removed from the
list of recommended packages or downgraded to Suggests.

[ Impact ]

The list of recommended and suggested packages will be outdated.

[ Tests ]

There were no code changes. Only the list of recommended or suggested
packages was updated.

[ Risks ]

The change is trivial.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock debian-games/4
diff -Nru debian-games-3.3/debian/changelog debian-games-4/debian/changelog
--- debian-games-3.3/debian/changelog   2021-02-19 01:29:47.0 +0100
+++ debian-games-4/debian/changelog 2021-07-04 08:50:03.0 +0200
@@ -1,3 +1,21 @@
+debian-games (4) unstable; urgency=medium
+
+  * Update the blacklist
+  * New games:
+- puzzle: chroma
+- console,toys: cbonsai
+  * Removed games or tools: (removed from Debian)
+- adanaxisgpl
+- aajm
+- jmdlx
+- fretsonfire
+- kiki-the-nano-bot
+- jerry
+- ninja-ide
+- python3-pyqt4.qtopengl
+
+ -- Markus Koschany   Sun, 04 Jul 2021 08:50:03 +0200
+
 debian-games (3.3) unstable; urgency=medium
 
   * arcade: Remove fofix from Suggests.
@@ -15,7 +33,7 @@
 - board: kgames
 - rpg: openmw
 - rpg: openmw-cs
-- arcarde: pinball-table-gnu
+- arcade: pinball-table-gnu
 - arcade: pinball-table-hurd
 - puzzle: puzzle-jigsaw
 - puzzle: sudoku-solver
diff -Nru debian-games-3.3/debian/control debian-games-4/debian/control
--- debian-games-3.3/debian/control 2021-02-19 01:29:47.0 +0100
+++ debian-games-4/debian/control   2021-07-04 08:50:03.0 +0200
@@ -495,6 +495,7 @@
 trader,
 vitetris
 Suggests: aajm,
+  cbonsai,
   termtris
 Description: Debian's console games
  This metapackage will install text console games designed to be used via a
@@ -872,6 +873,7 @@
 freesweep,
 gbrainy,
 gcompris,
+gfpoken,
 glpeces,
 gmult,
 gnome-mahjongg,
@@ -923,7 +925,7 @@
 xsok,
 xye,
 zaz
-Suggests: gfpoken,
+Suggests: chroma,
   gnome-games,
   gweled,
   kdegames,
@@ -1283,7 +1285,8 @@
 xplanet-images,
 xsnow,
 xteddy
-Suggests: fortunate.app
+Suggests: cbonsai,
+  fortunate.app
 Description: Debian's toy games
  This metapackage will install a collection of desktop toys and console
  programs that often modify the appearance of your computer and text in a
diff -Nru debian-games-3.3/src/blacklist debian-games-4/src/blacklist
--- debian-games-3.3/src/blacklist  2021-02-19 01:29:47.0 +0100
+++ debian-games-4/src/blacklist2021-07-04 08:50:03.0 +0200
@@ -679,3 +679,7 @@
 xscreensaver-screensaver-dizzy
 xye-data
 zaz-data
+openmw-data
+openmw-launcher
+pinball-table-gnu-data
+pinball-table-hurd-data
diff -Nru debian-games-3.3/tasks/arcade debian-games-4/tasks/arcade
--- debian-games-3.3/tasks/arcade   2021-02-19 01:29:47.0 +0100
+++ debian-games-4/tasks/arcade 2021-07-04 08:50:03.0 +0200
@@ -6,8 +6,6 @@
 
 Depends: abe
 
-Depends: adanaxisgpl
-
 Depends: airstrike
 
 Depends: alienblaster
@@ -62,8 +60,6 @@
 
 Depends: freegish
 
-Depends: fretsonfire
-
 Depends: funguloids
 
 Depends: funnyboat
@@ -94,8 +90,6 @@
 
 Depends: ii-esu
 
-Depends: jmdlx
-
 Depends: jumpnbump
 
 Depends: jumpnbump-levels
diff -Nru debian-games-3.3/tasks/chess debian-games-4/tasks/chess
--- debian-games-3.3/tasks/chess2021-02-19 01:29:47.0 +0100
+++ debian-games-4/tasks/chess  2021-07-04 08:50:03.0 +0200
@@ -36,8 +36,6 @@
 
 Depends: hoichess
 
-Depends: jerry
-
 Depends: pgn-extract
 
 Depends: pgn2web
diff -Nru debian-games-3.3/tasks/console debian-games-4/tasks/console
--- debian-games-3.3/tasks/console  2021-02-19 01:29:47.0 +0100
+++ debian-games-4/tasks/console2021-07-04 08:50:03.0 +0200
@@ -5,8 +5,6 @@
 
 Depends: 2048
 
-Depends: aajm
-
 Depends: an
 
 Depends: angband
@@ -23,6 +21,8 @@
 
 Depends: cavezofphear
 
+Depends: cbonsai
+
 Depends: colossal-cave-adventure
 
 Depends: crawl
diff -Nru debian-games-3.3/tasks/finest debian-games-4/tasks/finest
--- debian-games-3.3/tasks/finest   2021-02-19 01:29:47.0 +0100
+++ debian-games-4/tasks/finest 2021-07-04 08:50:03.0 +0200
@@ -82,8 +82,6 @@
 
 Depends: freeorion
 
-Depends: fretsonfire
-
 Depends: frozen-bubble
 
 Depends:

Bug#990710: unblock: jetty9/9.4.39-1

[Markus Koschany]

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

Please unblock package jetty9

[ Reason ]

Fixing CVE-2021-28169 and CVE-2021-34428

[ Impact ]

Version of Jetty 9 in Debian 11 is vulnerable

[ Tests ]

Integrated tests pass successfully

[ Risks ]

None, since all tests pass.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock jetty9/9.4.39-1
diff -Nru jetty9-9.4.39/debian/changelog jetty9-9.4.39/debian/changelog
--- jetty9-9.4.39/debian/changelog  2021-04-12 00:11:03.0 +0200
+++ jetty9-9.4.39/debian/changelog  2021-07-03 19:09:58.0 +0200
@@ -1,3 +1,23 @@
+jetty9 (9.4.39-2) unstable; urgency=high
+
+  * Team upload.
+  * Fix CVE-2021-28169:
+It is possible for requests to the ConcatServlet with a doubly encoded path
+to access protected resources within the WEB-INF directory. For example a
+request to `/concat?/%2557EB-INF/web.xml` can retrieve the web.xml file.
+This can reveal sensitive information regarding the implementation of a web
+application.
+  * Fix CVE-2021-34428:
+If an exception is thrown from the SessionListener#sessionDestroyed()
+method, then the session ID is not invalidated in the session ID manager.
+On deployments with clustered sessions and multiple contexts this can
+result in a session not being invalidated. This can result in an
+application used on a shared computer being left logged in.
+
+Thanks to Salvatore Bonaccorso for the report. (Closes: #98, #990578)
+
+ -- Markus Koschany   Sat, 03 Jul 2021 19:09:58 +0200
+
 jetty9 (9.4.39-1) unstable; urgency=high
 
   * New upstream release
diff -Nru jetty9-9.4.39/debian/patches/CVE-2021-28169.patch 
jetty9-9.4.39/debian/patches/CVE-2021-28169.patch
--- jetty9-9.4.39/debian/patches/CVE-2021-28169.patch   1970-01-01 
01:00:00.0 +0100
+++ jetty9-9.4.39/debian/patches/CVE-2021-28169.patch   2021-07-03 
19:09:58.0 +0200
@@ -0,0 +1,520 @@
+From: Markus Koschany 
+Date: Sat, 3 Jul 2021 19:01:20 +0200
+Subject: CVE-2021-28169
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=98
+Origin: 
https://github.com/eclipse/jetty.project/commit/1c05b0bcb181c759e98b060bded0b9376976b055
+---
+ .../org/eclipse/jetty/server/ResourceService.java  |   4 +-
+ .../org/eclipse/jetty/servlets/ConcatServlet.java  |   4 +-
+ .../org/eclipse/jetty/servlets/WelcomeFilter.java  |   8 +-
+ .../eclipse/jetty/servlets/ConcatServletTest.java  |  83 
+ .../eclipse/jetty/servlets/WelcomeFilterTest.java  | 143 +
+ .../jetty/webapp/WebAppDefaultServletTest.java | 142 
+ 6 files changed, 353 insertions(+), 31 deletions(-)
+ create mode 100644 
jetty-servlets/src/test/java/org/eclipse/jetty/servlets/WelcomeFilterTest.java
+ create mode 100644 
jetty-webapp/src/test/java/org/eclipse/jetty/webapp/WebAppDefaultServletTest.java
+
+diff --git 
a/jetty-server/src/main/java/org/eclipse/jetty/server/ResourceService.java 
b/jetty-server/src/main/java/org/eclipse/jetty/server/ResourceService.java
+index 1edfd83..c908e8d 100644
+--- a/jetty-server/src/main/java/org/eclipse/jetty/server/ResourceService.java
 b/jetty-server/src/main/java/org/eclipse/jetty/server/ResourceService.java
+@@ -240,7 +240,7 @@ public class ResourceService
+ // Find the content
+ content = _contentFactory.getContent(pathInContext, 
response.getBufferSize());
+ if (LOG.isDebugEnabled())
+-LOG.info("content={}", content);
++LOG.debug("content={}", content);
+ 
+ // Not found?
+ if (content == null || !content.getResource().exists())
+@@ -430,7 +430,7 @@ public class ResourceService
+ return;
+ }
+ 
+-RequestDispatcher dispatcher = 
context.getRequestDispatcher(welcome);
++RequestDispatcher dispatcher = 
context.getRequestDispatcher(URIUtil.encodePath(welcome));
+ if (dispatcher != null)
+ {
+ // Forward to the index
+diff --git 
a/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/ConcatServlet.java 
b/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/ConcatServlet.java
+index f6dde94..55700b4 100644
+--- 
a/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/ConcatServlet.java
 
b/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/ConcatServlet.java
+@@ -61,6 +61,7 @@ import org.eclipse.jetty.util.URIUtil;
+  * appropriate. This means that when not in development mode, the servlet 
must be
+  * restarted before changed content will be served.
+  */
++@Deprecated
+ public class ConcatServlet extends HttpServlet
+ {
+ private boolean _development;
+@@ -125,7 +126,8 @@ public class ConcatServlet extends HttpServlet
+ }
+ }
+ 
+-