Bug#991536: RFS: runit/2.1.2-41 [RC] -- system-wide service supervision

2021-07-26 Thread Lorenzo Puliti
Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Dear mentors,

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

this upload has already been approved by the release team,
see bug #991491
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991491

 * Package name: runit
   Version : 2.1.2-41
   Upstream Author : Gerrit Pape 
 * URL : http://smarden.org/runit/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/debian/runit
   Section : admin

It builds those binary packages:

  runit - system-wide service supervision
  runit-run - service supervision (systemd and sysv integration)
  runit-systemd - transitional package for runit-systemd users
  getty-run - runscripts to supervise getty processes
  runit-init - system-wide service supervision (as init system)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-41.dsc

Git repo:

  https://salsa.debian.org/Lorenzo.ru.g-guest/runit/-/tree/bullseye-support

Changes since the last upload:

 runit (2.1.2-41) unstable; urgency=medium
 .
   * Cherry-pick shutdown.c fixes from experimental
 for incoming stable release:
 - fix broken switch from SysVinit due to wrong
   command line parsing logic (Closes: #991227)
 - reboot the system with -r flag instead of poweroff
   (Closes: #990774)
 - Update shutdown(8) manpage

Regards,
-- 
  Lorenzo Puliti



Bug#991540: wget2: Wget2 dumps core on ctrl-c instead of exiting cleanly

2021-07-26 Thread Anders Andersson
Package: wget2
Version: 1.99.1-2.2
Severity: normal

I can't abort wget2 even for trivial error cases. Example:

$ wget2 http://doesntexist/nope
Failed to resolve doesntexist (Name or service not known)
Failed to resolve doesntexist (Name or service not known)
^C^CAborted (core dumped)

If wget2 can not find the server it keeps retrying (forever?), and when trying
to abort by sending a CTRL-C it just stops, but it doesn't exit. If I then
send another CTRL-C it dumps core.

   * What outcome did you expect instead?

A network tool that can handle network issues grafeully.



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

Versions of packages wget2 depends on:
ii  libc6 2.31-13
ii  libgpgme111.14.0-1+b2
ii  libpcre2-8-0  10.36-2
ii  libwget0  1.99.1-2.2

Versions of packages wget2 recommends:
ii  ca-certificates  20210119

wget2 suggests no packages.

-- no debconf information



Bug#989777: Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

2021-07-26 Thread andrew
Hello Nobuhiro,

> Could you confirm that the combination of the latest firmware and the
> 5.10 kernel solves this problem?

Unfortunately, I can't. Freshly updated Bullseye:

* linux-image-amd64: 5.10.46-2
* firmware-misc-nonfree: 20210315-2
* bluez-firmware: 1.2-4

Is there any additional information that might be helpful?


-- 
With regards,
A



Bug#991539: iwd: Segfaults on AX210 unless start is delayed

2021-07-26 Thread Andrew Savchenko
Package: iwd
Version: 1.14-3
Severity: normal
X-Debbugs-Cc: and...@lists.savchenko.net

Dear Maintainer,

iwd throws warning in the kernel ring buffer unless its start is delayed
with `ExecStartPre=ip link set wlan0 up` in `iwd.service` unit.

With the line above the warning is gone, however iwd can't be
stopped/started after the boot. `systemctl restart` works though.

Trace below:

kern  :warn  : [  +0.008344] [ cut here ]
kern  :warn  : [  +0.27] WARNING: CPU: 5 PID: 1384 at 
net/wireless/nl80211.c:7579 nl80211_get_reg_do+0x1f6/0x230 [cfg80211]
kern  :warn  : [  +0.00] Modules linked in: ccm pcc_cpufreq(-) 
acpi_cpufreq(-) algif_aead cbc des_generic libdes ecb algif_skcipher cmac 
sha512_ssse3 snd_soc_skl_hda_dsp(+) snd_soc_hdac_hdmi sha512_generic md4 
algif_hash snd_soc_dmic af_alg mei_hdcp mei_wdt binfmt_misc intel_rapl_msr 
x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi ipt_REJECT 
nf_reject_ipv4 kvm_intel snd_hda_codec_realtek snd_hda_codec_generic nft_limit 
kvm irqbypass intel_cstate snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc 
snd_sof_intel_hda_common snd_sof_xtensa_dsp snd_sof iwlmvm snd_sof_intel_hda 
snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi 
snd_intel_dspcfg soundwire_intel soundwire_generic_allocation snd_soc_core 
mac80211 snd_compress soundwire_cadence uvcvideo snd_hda_codec 
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 xt_limit snd_hda_core joydev 
intel_uncore serio_raw efi_pstore pcspkr libarc4 xt_addrtype videobuf2_common 
nls_ascii snd_hwdep iwlwifi iTCO_wdt xt_tcpudp soundwire_bus
kern  :warn  : [  +0.35]  intel_pmc_bxt nls_cp437 videodev 
iTCO_vendor_support wmi_bmof mei_me snd_pcm xt_conntrack ee1004 watchdog vfat 
nf_conntrack i915 cfg80211 snd_timer fat mei nf_defrag_ipv6 mc evdev 
nf_defrag_ipv4 thinkpad_acpi nft_compat nvram drm_kms_helper ledtrig_audio snd 
nft_counter processor_thermal_device ucsi_acpi cec typec_ucsi intel_rapl_common 
soundcore i2c_algo_bit intel_soc_dts_iosf typec rfkill int3403_thermal ac 
int340x_thermal_zone int3400_thermal intel_hid intel_pmc_core acpi_thermal_rel 
sparse_keymap acpi_pad acpi_tad button nf_tables drm libcrc32c nfnetlink 
pkcs8_key_parser coretemp i2c_dev fuse configfs efivarfs ip_tables x_tables 
autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt dm_mod hid_generic 
usbhid hid crc32_pclmul crc32c_intel ghash_clmulni_intel tpm_crb nvme 
aesni_intel psmouse xhci_pci libaes crypto_simd xhci_hcd nvme_core cryptd 
e1000e glue_helper t10_pi crc_t10dif thunderbolt usbcore ptp i2c_i801 tpm_tis 
pps_core tpm_tis_core i2c_smbus tpm crct10dif_generic
kern  :warn  : [  +0.43]  rng_core crct10dif_pclmul crct10dif_common 
usb_common wmi battery video
kern  :warn  : [  +0.04] CPU: 5 PID: 1384 Comm: iwd Not tainted 
5.10.0-8-amd64 #1 Debian 5.10.46-2
kern  :warn  : [  +0.01] Hardware name: LENOVO 20W0CTO1WW/20W0CTO1WW, BIOS 
N34ET40W (1.40 ) 06/25/2021
kern  :warn  : [  +0.09] RIP: 0010:nl80211_get_reg_do+0x1f6/0x230 [cfg80211]
kern  :warn  : [  +0.02] Code: 24 0c 01 00 00 00 e8 d9 b4 45 fb 85 c0 0f 84 
fc fe ff ff eb a6 48 89 ef 48 89 04 24 e8 73 10 67 fb 48 8b 04 24 e9 43 ff ff 
ff <0f> 0b 48 89 ef e8 60 10 67 fb b8 ea ff ff ff e9 2f ff ff ff b8 97
kern  :warn  : [  +0.01] RSP: 0018:b4a5808b7b60 EFLAGS: 00010202
kern  :warn  : [  +0.00] RAX:  RBX: 0001 RCX: 

kern  :warn  : [  +0.01] RDX: 91b671808008 RSI:  RDI: 
91b671808300
kern  :warn  : [  +0.00] RBP: 91b8db18ce00 R08: 0014 R09: 
91b6719dc014
kern  :warn  : [  +0.01] R10: 001c R11: 91b8bcda1e00 R12: 
b4a5808b7bb8
kern  :warn  : [  +0.00] R13:  R14: 91b6719dc014 R15: 
91b671808300
kern  :warn  : [  +0.01] FS:  703c998cc640() 
GS:91bcff74() knlGS:
kern  :warn  : [  +0.01] CS:  0010 DS:  ES:  CR0: 80050033
kern  :warn  : [  +0.00] CR2: 703c9968f4e0 CR3: 0003b6916002 CR4: 
00770ee0
kern  :warn  : [  +0.01] PKRU: 5554
kern  :warn  : [  +0.00] Call Trace:
kern  :warn  : [  +0.05]  ? _cond_resched+0x16/0x40
kern  :warn  : [  +0.04]  genl_family_rcv_msg_doit+0xea/0x150
kern  :warn  : [  +0.02]  genl_rcv_msg+0xde/0x1d0
kern  :warn  : [  +0.18]  ? nl80211_vendor_cmd_dump+0x5d0/0x5d0 [cfg80211]
kern  :warn  : [  +0.14]  ? nl80211_send_regdom.constprop.0+0x1a0/0x1a0 
[cfg80211]
kern  :warn  : [  +0.01]  ? genl_get_cmd+0xd0/0xd0
kern  :warn  : [  +0.00]  netlink_rcv_skb+0x50/0xf0
kern  :warn  : [  +0.01]  genl_rcv+0x24/0x40
kern  :warn  : [  +0.01]  netlink_unicast+0x201/0x2c0
kern  :warn  : [  +0.01]  netlink_sendmsg+0x243/0x480
kern  :warn  : [  +0.02]  sock_sendmsg+0x5e/0x60
kern  :warn  : [  +0.01]  __sys_sendto+0xee/0x150
kern  :warn  : [  +0.02]  __x64_sys_sendto+0x25/0x30
kern  :warn  : [  

Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

2021-07-26 Thread Felix Lechner
Hi,

On Mon, Jul 26, 2021 at 7:08 PM Cyril Brulebois  wrote:
>
> It doesn't have to
> follow the letter of Policy, does it?

The Lintian maintainers are happy to participate in a discussion, but
they do not implement their personal policy stances in defiance of the
project's authoritative documentation. As noted, the use of
Standard-Version is, in my view, a packaging error everywhere—and not
just in udebs. To that extent we are allies; otherwise Lintian is not
the right place for you (or I) to address concerns about that
pestering and unnecessary field. Thanks for copying -policy!

Kind regards,
Felix Lechner



Bug#991269: guymager: "AvoidEncaseProblems" is set to off in config file

2021-07-26 Thread Zack Lau
Hi Mika,

Yeah, I agree with your approach and think it makes more sense. Learned
something new from you. Thanks again!

Regards,
Zack

On 26/7/21 5:58 pm, Michael Prokop wrote:
> * Zack Lau [Mon Jul 26, 2021 at 09:49:16AM +]:
>
>> Thanks for looking into this.
>> I understand this option is well explained in the configuration file.
>> However, in most situations, forensic practitioners run the forensic
>> imaging process using Guymager in forensics mode booted up from Live
>> CD. In order words, the configuration file needs to be updated after
>> every boot up. It would be great if this can be enabled by default.
> I talked to the upstream author in the meanwhile, and upstream
> agreed to my suggestion, to use output of `uname -r` for the kernel
> version information, and keep the strings below the limit that's
> known to be needed for EnCase. So there shouldn't be any need for
> changing this option, once a new upstream version with the new
> behavior is there.
>
>> Enabling this option in the configuration file does not prevent a
>> Guymager created forensic image to load properly in other forensic
>> software (i.e. FTK, Autopsy or X-Ways). Instead, it resolves the
>> error issue when people try to load a Guymager created E01 in EnCase.
> ACK, but I don't like diverging from upstream defaults, as there's
> usually a good reason behind it. :)
>
>> I find this topic interesting. I saw comments in different forums
>> think the EnCase error issue was caused by other settings, or what
>> people put in the case data fields. There were only a few people
>> mentioned this option, so I think this "AvoidEncaseProblems" option
>> is not widely aware of among the forensics community.
> Thanks for your input!
>
> regards
> -mika-




smime.p7s
Description: S/MIME cryptographic signature


Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

2021-07-26 Thread Cyril Brulebois
Hi,

Felix Lechner  (2021-07-26):
> Control: forcemerge 988911 -1
> 
> Hi Cyril,
> 
> On Mon, Jul 26, 2021 at 5:36 PM Cyril Brulebois  wrote:
> >
> > That's one example where all binaries are udebs so there's no need for
> > such a field.
> 
> As you pointed out and—as was noted in the other bug [1]—the tag was
> not issued for your udebs but your dsc. At least from the letter of
> the policy, it seems to be required there. [2]

cc-ing debian-policy@ for some possible feedback.

I'm not sure why we should be spending time tracking down Policy changes
in (source for) udeb packages… so adding then updating this field to all
our packages doesn't seem to do us any good.

Whatever happens on the debian-policy front (if anything), I'd prefer if
lintian would stop emitting those errors on its own. It doesn't have to
follow the letter of Policy, does it?


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


signature.asc
Description: PGP signature


Bug#991537: libp8-platform2 - 'illegal instruction' when running cec-client

2021-07-26 Thread simon



Package: libp8-platform2
Version: 2.1.0.1+dfsg1-2

Attempting to run cec-client on a (offline) Pi Zero, but get error 
'illegal instruction'.

Using GDB it appears to be caused by libp8-platform.

Happens on both minimal and X based distro.

pi@raspberrypi:~/cec $ gdb cec-client
GNU gdb (Raspbian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cec-client...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/cec-client
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/arm-linux-gnueabihf/libthread_db.so.1".


Program received signal SIGILL, Illegal instruction.
0xb6f9105c in ?? () from /lib/arm-linux-gnueabihf/libp8-platform.so.2
(gdb) bt
#0  0xb6f9105c in ?? () from 
/lib/arm-linux-gnueabihf/libp8-platform.so.2

#1  0xb6fde2e8 in call_init (l=, argc=argc@entry=1,
argv=argv@entry=0xbefff3e4, env=env@entry=0xbefff3ec) at 
dl-init.c:72

#2  0xb6fde3ec in call_init (env=, argv=,
argc=, l=) at dl-init.c:30
#3  _dl_init (main_map=0xb6fff978, argc=1, argv=0xbefff3e4, 
env=0xbefff3ec)

at dl-init.c:119
#4  0xb6fcea74 in _dl_start_user () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt 
stack?)

(gdb)


Basic Raspbian install...
48ce9cf1a6781600d10dee46228920ef  
2021-05-07-raspios-buster-armhf-lite.zip

or
b89314053308d03d1a9b48057e035588  2021-05-07-raspios-buster-armhf.zip

Plus...
4b9c978447e0c944495e35969f7c4abf  cec-utils_4.0.4+dfsg1-2_armhf.deb
ca9c81dffae3aa2a672bd87f3fadca59  libcec4_4.0.4+dfsg1-2_armhf.deb
32b044852428290ab71b23d24f36c597  
libp8-platform2_2.1.0.1+dfsg1-2_armhf.deb




Bug#991535: unblock: developers-reference/11.0.21

2021-07-26 Thread Holger Levsen
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package developers-reference 11.0.21, which is a documentation
and translation only update:

developers-reference (11.0.21) unstable; urgency=medium

  * best-pkging-practices: replace 'atter' with 'other', with thanks to
Jeremy Bicha. Closes: #991291
  * pkgs: update releases used in examples for the time when bullseye is
stable.
  * resources: update 'dak ls evince' example output.
  * Update all .po files for changed strings in the English original.

 -- Holger Levsen   Tue, 20 Jul 2021 15:20:35 +0200

debdiff developers-reference_11.0.20.dsc developers-reference_11.0.21.dsc 
|diffstat
 debian/changelog   |   17 -
 source/best-pkging-practices.rst   |2 
 source/locales/de/LC_MESSAGES/best-pkging-practices.po |5 -
 source/locales/de/LC_MESSAGES/pkgs.po  |   14 ++--
 source/locales/fr/LC_MESSAGES/best-pkging-practices.po |   57 -
 source/locales/fr/LC_MESSAGES/pkgs.po  |   14 ++--
 source/locales/it/LC_MESSAGES/best-pkging-practices.po |   15 +++-
 source/locales/it/LC_MESSAGES/pkgs.po  |   34 --
 source/locales/ja/LC_MESSAGES/best-pkging-practices.po |   15 +++-
 source/locales/ja/LC_MESSAGES/pkgs.po  |   34 --
 source/locales/ru/LC_MESSAGES/best-pkging-practices.po |   15 +++-
 source/locales/ru/LC_MESSAGES/pkgs.po  |   34 --
 source/pkgs.rst|4 -
 source/resources.rst   |   16 ++--
 14 files changed, 198 insertions(+), 78 deletions(-)

The full debdiff is attached.

unblock developers-reference/11.0.21

Thanks for your work on bullseye!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Bottled water companies don't produce water, they produce plastic bottles.
diff -Nru developers-reference-11.0.20/debian/changelog developers-reference-11.0.21/debian/changelog
--- developers-reference-11.0.20/debian/changelog	2021-06-18 23:50:52.0 +0200
+++ developers-reference-11.0.21/debian/changelog	2021-07-20 15:20:35.0 +0200
@@ -1,12 +1,23 @@
+developers-reference (11.0.21) unstable; urgency=medium
+
+  * best-pkging-practices: replace 'atter' with 'other', with thanks to
+Jeremy Bicha. Closes: #991291
+  * pkgs: update releases used in examples for the time when bullseye is
+stable.
+  * resources: update 'dak ls evince' example output.
+  * Update all .po files for changed strings in the English original.
+
+ -- Holger Levsen   Tue, 20 Jul 2021 15:20:35 +0200
+
 developers-reference (11.0.20) unstable; urgency=medium
 
   [ Judit Foglszinger ]
-  * removing freenode and moving reference to cloaks to Debian wiki.
-Closes: 990054.
+  * ressources: Remove freenode and move reference to cloaks to Debian wiki.
+Closes: #990054.
 
   [ Holger Levsen ]
   * Update all .po files for changed strings in the English original.
-  * fix typo in previous d/changelog entry
+  * Fix typo in previous d/changelog entry.
 
  -- Holger Levsen   Fri, 18 Jun 2021 23:50:52 +0200
 
diff -Nru developers-reference-11.0.20/source/best-pkging-practices.rst developers-reference-11.0.21/source/best-pkging-practices.rst
--- developers-reference-11.0.20/source/best-pkging-practices.rst	2021-01-17 22:22:11.0 +0100
+++ developers-reference-11.0.21/source/best-pkging-practices.rst	2021-07-20 14:58:54.0 +0200
@@ -1466,7 +1466,7 @@
point).
 
 4. **may** use *packagename*\ ``-``\ *upstream-version*\ ``+dfsg``
-   (or any atter suffix which is added to the tarball name) as
+   (or any other suffix which is added to the tarball name) as
the name of the top-level directory in its tarball. This makes it
possible to distinguish pristine tarballs from repackaged ones.
 
diff -Nru developers-reference-11.0.20/source/locales/de/LC_MESSAGES/best-pkging-practices.po developers-reference-11.0.21/source/locales/de/LC_MESSAGES/best-pkging-practices.po
--- developers-reference-11.0.20/source/locales/de/LC_MESSAGES/best-pkging-practices.po	2021-01-17 23:28:02.0 +0100
+++ developers-reference-11.0.21/source/locales/de/LC_MESSAGES/best-pkging-practices.po	2021-07-20 15:01:41.0 +0200
@@ -3,7 +3,7 @@
 msgstr ""
 "Project-Id-Version:  developers-reference\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2021-01-17 22:27+\n"
+"POT-Creation-Date: 2021-07-20 13:01+\n"
 "PO-Revision-Date: 2020-03-02 19:51+0100\n"
 "Last-Translator: Carsten Schoenert \n"
 "Language: de\n"
@@ -2760,9 +2760,10 @@
 "Originaldistribution zu suchen)."
 
 #: ../best-pkging-practices.rst:1468
+#, fuzzy
 msgid ""
 "**may** use *packagename*\\ ``-``\\ *upstream-version*\\ ``+dfsg`` (or "
-"any atter suffix which 

Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

2021-07-26 Thread Felix Lechner
Control: forcemerge 988911 -1

Hi Cyril,

On Mon, Jul 26, 2021 at 5:36 PM Cyril Brulebois  wrote:
>
> That's one example where all binaries are udebs so there's no need for
> such a field.

As you pointed out and—as was noted in the other bug [1]—the tag was
not issued for your udebs but your dsc. At least from the letter of
the policy, it seems to be required there. [2]

As a side note, I believe the Standards-Version field should be
dropped altogether. Whenever possible, I try to reduce Lintian's
never-ending reminders to update it. The other bug has more on that.

Kind regards,
Felix Lechner

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988911#10
[2] 
https://www.debian.org/doc/debian-policy/ch-controlfields.html#debian-source-control-files-dsc



Bug#991534: unblock: therion/5.5.7ds1-2

2021-07-26 Thread Wookey
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package therion

RC bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991064 fixed

diff -Nru therion-5.5.7ds1/debian/changelog therion-5.5.7ds1/debian/changelog
--- therion-5.5.7ds1/debian/changelog   2021-02-06 16:24:25.0 +
+++ therion-5.5.7ds1/debian/changelog   2021-07-27 00:27:47.0 +0100
@@ -1,3 +1,10 @@
+therion (5.5.7ds1-2) unstable; urgency=medium
+
+* Allow build with new secure imagemagik (Closes: #991064)
+  Thanks to Dennis Filder for the patch
+
+ -- Wookey   Mon, 26 Jul 2021 23:27:47 +
+
 therion (5.5.7ds1-1) unstable; urgency=medium
 
   * New upstream release, including below bugfixes
diff -Nru therion-5.5.7ds1/debian/rules therion-5.5.7ds1/debian/rules
--- therion-5.5.7ds1/debian/rules   2021-01-04 02:47:31.0 +
+++ therion-5.5.7ds1/debian/rules   2021-07-27 00:27:06.0 +0100
@@ -2,6 +2,9 @@
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow future=+lfs
 export DH_VERBOSE=1
+
+POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: 
ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml"
+
 %:
dh $@
 
@@ -11,7 +14,10 @@
# We need therion itself to build the samples
$(MAKE) therion
# create HTML documentation for samples
-   faketime "$(dpkg-parsechangelog -S Date)" $(MAKE) samples
+   mkdir -p debian/tmp/ImageMagick
+   sed -e '//s@"none"@"read|write"@' "$(POLFILE)" > debian/tmp/ImageMagick/policy.xml
+   faketime "$(dpkg-parsechangelog -S Date)" $(MAKE) 
XDG_CONFIG_HOME="$(shell pwd)/debian/tmp" samples
+   rm -Rf debian/tmp/ImageMagick
 endif
$(MAKE) thbook
 
Binary files /tmp/Y2PQbhQpnB/therion-5.5.7ds1/samples/survex/cave.3d and 
/tmp/9YK3y5DEz8/therion-5.5.7ds1/samples/survex/cave.3d differ
Binary files /tmp/Y2PQbhQpnB/therion-5.5.7ds1/samples/survex/create/create.3d 
and /tmp/9YK3y5DEz8/therion-5.5.7ds1/samples/survex/create/create.3d differ
Binary files /tmp/Y2PQbhQpnB/therion-5.5.7ds1/samples/survex/ignore/ignore.3d 
and /tmp/9YK3y5DEz8/therion-5.5.7ds1/samples/survex/ignore/ignore.3d differ
Binary files /tmp/Y2PQbhQpnB/therion-5.5.7ds1/samples/survex/use/use.3d and 
/tmp/9YK3y5DEz8/therion-5.5.7ds1/samples/survex/use/use.3d differ

(the build-time generated sample .3d files have an embedded timestamp
and they differ by 4 bytes (at least on my local build) despite my
best efforts to make them match using faketime. Bad for
reproducability but otherwise of no significance)

unblock therion/5.5.7ds1-2

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

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



Bug#990426: www.debian.org: Clarify status of list of old TC decisions

2021-07-26 Thread Calum McConnell
On Thu, 2021-07-08 at 18:08 -0700, Sean Whitton wrote:
> Hello,
> 
> On Thu 08 Jul 2021 at 09:12AM +02, Raphael Hertzog wrote:
> 
> > Hi,
> > 
> > On Mon, 28 Jun 2021, Sean Whitton wrote:
> > > -NB that decisions from before the 1st of April 2002 are not yet
> > > -recorded here.
> > > +NB that no decisions from before the 1st of April 2002 are yet
> > > recorded
> > > +here yet.
> > 
> > That wording doesn't seem correct for me. Maybe:
> > « Note that no decisions from before the 1st of April 2002 are
> > recorded
> > here. »
> > or
> > « Note that decisions from before the 1st of April 2002 have not been
> > recorded here. »
> 
> There should not be two 'yet's, indeed.  Thanks.
> 
> > >  Formal nontechnical and procedural decisions
> > > 
> > > @@ -337,8 +337,8 @@ recorded here.
> > > 
> > >  
> > > 
> > > -NB that decisions from before the 31st of January 2002 are not
> > > yet
> > > -recorded here.
> > > +NB that no decisions from before the 31st of January 2002 are
> > > recorded here
> > > +yet.
> 
> This one doesn't have the same problem and I think is fine.
> 

I think I understand Raphael's point: the wording felt a bit awkward to me
as well on a first read.  The "no" should go with the verb, not the
subject, and it's a mile away.  Plus, I think there's tense weirdness
going on with the 'yet' as well: 'yet' indicates past actions, and 'are'
indicates the present tense.  

It should probably be:

+NB that all decisions from before the 31st of January 2002 have yet to
be recorded here   

Alternatively, since I think you're trying specifically to remove the "not
yet" in the original, try just getting rid of the 'yet': it doesn't add
much.

+NB that no decisions from before the 31st of January 2002 have been
recorded here 

Or, (and this is the option I personally will be taking), simply ignore
this tiny bit of subjectively awkward english, stop being overly pedantic
about a tiny phrase that doesn't matter, thank the person adding a much
needed note to an out of date page, and take a nap while contemplating the
silliness of language.

Looking forward to his nap,
Calum M


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


Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

2021-07-26 Thread Cyril Brulebois
Package: lintian
Version: 2.104.0
Severity: important
X-Debbugs-Cc: debian-b...@lists.debian.org

Hi,

lintian in bullseye is emitting this, e.g. while building the hw-detect
source package:

E: hw-detect source: required-field debian/control@source Standards-Version
E: hw-detect source: required-field hw-detect_1.145.dsc Standards-Version

That's one example where all binaries are udebs so there's no need for
such a field.

It'd be best to avoid popping up errors for that; they're distracting
and serve no purposes. (Once that's fixed, and other possible issues are
ironed out, I wouldn't be against getting that into bullseye, so that
anyone preparing d-i packages from then-stable doesn't have to worry
about those.)

Thanks for considering!


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



Bug#990974: ds2490: Driver seems broken (worked in 4.19.0)

2021-07-26 Thread Nobuhiro Iwamatsu
Source: linux
Followup-For: Bug #990974

Hi,

> Driver ds2490 For Dallas 1-wire bus driver DS9490R seems broken.
> No devices on 1-wire bus are detected and reading most files from
> /sys/bus/w1/drivers/w1_master_driver/w1_bus_master1 causes process
> to hang in uninterruptible wait.

Is this the same issue as this URL [0][1]?
If so, it has been fixed with the following commit[2].

Best regards,
  Nobuhiro 

[0]: https://github.com/raspberrypi/linux/issues/3491
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1873694
[2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-testing=e3fe0e89fec6965342434e7acae7ed6e6f021d08



Bug#989777: Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

2021-07-26 Thread Nobuhiro Iwamatsu
Hi,

> Greetings,
>
> With the most recent weekly build, situation is following:
>
> 1. AX210 *WiFI* functions after removing the corresponding .pnvm file. 
> Details are in the Arch FS #70071 [1]
> 2. Bluetooth does not work at all and indeed floods kernel ring buffer at the 
> rate of >1 msg/sec. Message:
>
> ```
> kern  :info  : [  +0.437457] usb 3-10: new full-speed USB device number 91 
> using xhci_hcd
> kern  :info  : [  +0.150615] usb 3-10: New USB device found, idVendor=8087, 
> idProduct=0032, bcdDevice= 0.00
> kern  :info  : [  +0.04] usb 3-10: New USB device strings: Mfr=0, 
> Product=0, SerialNumber=0
> kern  :err   : [  +0.004324] Bluetooth: hci0: Reading Intel version 
> information failed (-22)
> kern  :err   : [  +0.06] Bluetooth: hci0: Intel Read version failed (-22)
> kern  :info  : [  +0.40] Bluetooth: hci0: Intel reset sent to retry FW 
> download
> kern  :info  : [  +0.000540] usb 3-10: USB disconnect, device number 91
> ```
>
> Given that Arch FS link mentions issue as being resolved in 5.12.X, is there 
> a chance to backport `linux-firmware` into 5.10.X LTS / Bullseye? AX210 is 
> destined to be one of the most popular modules out there and this bug might 
> cause some unnecessary bad press after the release.
>
> [1] https://bugs.archlinux.org/task/70071

Could you confirm that the combination of the latest firmware and the
5.10 kernel solves this problem?

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6



Bug#969264: Bug#989863: debian-installer: Firmware problems in bullseye

2021-07-26 Thread Cyril Brulebois
Hi Salvatore,

Salvatore Bonaccorso  (2021-07-26):
> On Mon, Jul 26, 2021 at 06:14:09AM +0200, Cyril Brulebois wrote:
> > @KT:
> > 
> > I haven't uploaded it since I'm seeing iwlwifi requesting what appears
> > to be a debug-only firmware (iwl-debug-yoyo.bin), that's even requested
> > via an aptly-named firmware_request_nowarn() function in linux.git; I'd
> > like to check with the kernel maintainers whether it's expected for this
> > message to show up in dmesg still (given the name and comments in
> > linux.git, I'm not sure it should). In any cases, it's slightly sad to
> > pause and prompt users from firmware files we don't ship anywhere
> > (AFAICT), that they don't actually need.
> > 
> > Therefore, I'm tempted to blacklist this firmware file in hw-detect
> > (i.e. pretend it was never requested).
> 
> This reminds me of the long(ish) standing bug report #969264 and
> #966218.

I must confess I didn't spend time checking the BTS, only the source
code, woops. Thanks for the pointer, I think I'll consider this a “known
issue” (for it to be requested while it's neither needed nor to be found
anywhere), and blacklist that file in hw-detect.

For the avoidance of doubt, I don't recall any major problems with my
wireless connection, at least during all installation tests: one full
GNOME installation at the beginning, and many no-desktop installation
tests after that. I haven't used the installed systems much though,
since I'm working on the installer side. :)

Adding #969264 in cc to chime in: that's still current as of
linux-image-5.10.0-8-amd64 (version 5.10.46-2), both in the Debian
Installer context, and within the installed system.

I'm seeing this in a current Dell G3 15 machine (DELL G3 15-3500 –
3500-1294 if my notes are correct).


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


signature.asc
Description: PGP signature


Bug#991532: vmdb2: Should deprecate/remove qemu-debootstrap step bc it's deprecated

2021-07-26 Thread Diederik de Haas
Package: vmdb2
Version: 0.22-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: pkg-raspi-maintain...@lists.alioth.debian.org

"deprecate qemu-debootstrap" is the primary commit message of:
https://salsa.debian.org/qemu-team/qemu/-/commit/9899b1723119e57354c5d8e6f68f15ed762bd570
And it change the call to 'debootstrap' itself.
I haven't tried whether that would succeed or not.

So I'd guess that vmdb2 should deprecate it as well.
http://git.liw.fi/vmdb2/commit/vmdb/plugins?id=bc42e2a8e94713dafb4de4546352749354bc80e0
is an upstream commit which does (seem to) add the needed functionality
to the debootstrap call and adds a not to the *documentation*, but
afaict the qemu-debootstrap plugin is still available and doesn't alert
the user of its deprecation.
And I think it should, by at least outputting/logging a warning and
possibly switching to error/fail (over time?).
As I don't think it's actually/fully fixed upstream, I omitted that tag.

CC-ing RPi maintainers as I know it uses a qemu-debootstrap step.

Cheers,
  Diederik

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

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

Versions of packages vmdb2 depends on:
ii  cmdtest 0.32.14.gcdfe14e-2
ii  debootstrap 1.0.123
ii  e2fsprogs   1.46.2-2
ii  kpartx  0.8.5-2
ii  parted  3.4-1
ii  python3 3.9.2-3
ii  python3-jinja2  2.11.3-1
ii  python3-yaml5.3.1-5
ii  qemu-utils  1:6.0+dfsg-2exp

Versions of packages vmdb2 recommends:
ii  ansible   2.10.7+merged+base+2.10.8+dfsg-1
ii  dosfstools4.2-1
ii  qemu-user-static  1:6.0+dfsg-2exp

vmdb2 suggests no packages.

-- no debconf information



Bug#991531: unblock: nvidia-graphics-drivers/470.57.02-2 et.al. (pre-approval)

2021-07-26 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

I'd like to upgrade the "current" nvidia driver in sid from the 460 to
the 470 series. The 470 series was promoted to release state with the
CVE fixes last week.

The 460 series is a production branch with update support for 1 year.
The 470 series is (supposed to be) a long term support branch with
updates for 3 years.
https://www.phoronix.com/scan.php?page=news_item=NVIDIA-470-Ends-Kepler
So we will be switching to 470 during the lifetime of bullseye anyway,
therefore let's better start there right away.
Post-470 nvidia plans to drop support for some ancient cards, so it is
very unlikely that we will switch to a post-470 driver in bullseye.
In previous stable releases we also sticked to such a long term support
branch once we had reached it (390 in stretch, 418 in buster)

nvidia-graphics-drivers and nvidia-settings (and an older 470 version of
nvidia-modprobe) are already available in experimental. The other ones
are quickly uploadable to sid, too. The packages need to be kept in sync
at the major version to avoid confusion.

Anyway, I'd like to see 460.91.03-1 migrate first before I upload 470.*
to sid.

(there are intentionally no diffs attached, yet)

unblock nvidia-graphics-drivers/470.57.02-2
unblock nvidia-settings/470.57.02-2
unblock nvidia-modprobe/470.57.02-1
unblock nvidia-persistenced/470.57.02-1
unblock nvidia-xconfig/470.57.02-1

Andreas



Bug#991530: unblock: nvidia-graphics-drivers/460.91.03-1

2021-07-26 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock the nvidia package stack.

I've just finished uploading a bunch of new upstream releases of the
nvidia driver packages to non-free (and supporting packages to contrib)
fixing CVE-2021-1093, CVE-2021-1094, CVE-2021-1095.

Further packaging changes:
* adding Recommends on the libnvidia*-encode1 library. Several
  multimedia applications are built with nvidia encode support and can
  dlopen the library at runtime (if available) to use hardware
  acceleration for video encoding
* computing the Vcs-Git branch while generating debian/control,
  something I usually forgot to update when forking off a new driver
  source package

The nvidia-settings updates are mostly version bumps.

I'm only attaching git diffs for nvidia-graphics-drivers/460.91.03-1 and
nvidia-settings/460.91.03-1, the other ones are very similar.

unblock nvidia-graphics-drivers/460.91.03-1
unblock nvidia-settings/460.91.03-1

unblock nvidia-graphics-drivers-tesla-460/460.91.03-1
unblock nvidia-settings-tesla-460/460.91.03-1

unblock nvidia-graphics-drivers-tesla-450/450.142.00-1

unblock nvidia-graphics-drivers-tesla-418/418.211.00-1

unblock nvidia-graphics-drivers-legacy-390xx/390.144-1
unblock nvidia-settings-legacy-390xx/390.144-1

Andreas
diff --git a/debian/changelog b/debian/changelog
index 1d10198f..28614181 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,55 @@
+nvidia-graphics-drivers (460.91.03-1) unstable; urgency=medium
+
+  * New upstream production branch release 460.91.03 (2021-07-20).
+* Fixed CVE-2021-1093, CVE-2021-1094, CVE-2021-1095.  (Closes: #991351)
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5211
+- Added support for the following GPUs: GeForce RTX 3070 Ti, CMP 50HX.
+* Fixed crash with certain DisplayPort devices.  (Closes: #989069)
+
+  [ Andreas Beckmann ]
+  * Update nv-readme.ids.
+  * Drop manually added Depends: libcuda1 from libraries not referencing it.
+  * nvidia-driver-libs: Add Recommends: libnvidia-encode1.  (Closes: #989885)
+  * debian/gen-control.pl: Support substitutions in the Vcs-Git field.
+  * Compute and substitute the Git branch instead of hardcoding it.
+
+ -- Andreas Beckmann   Sat, 24 Jul 2021 01:25:40 +0200
+
+nvidia-graphics-drivers (460.84-1) unstable; urgency=medium
+
+  * New upstream production branch release 460.84 (2021-06-03).
+- Added support for the following GPU: GeForce RTX 3080 Ti.
+
+  [ Andreas Beckmann ]
+  * Update nv-readme.ids.
+  * Update lintian overrides.
+
+ -- Andreas Beckmann   Sat, 05 Jun 2021 03:30:17 +0200
+
+nvidia-graphics-drivers (460.80-1) unstable; urgency=medium
+
+  * New upstream production branch release 460.80 (2021-05-11).
+- Fixed a bug that could cause AddressSanitizer to report a
+  heap-buffer-overflow during initialization of the OpenGL and Vulkan
+  libraries.
+- Added support for the following GPUs: GeForce RTX 3050 Ti Laptop GPU,
+  GeForce RTX 3050 Laptop GPU, T600 Laptop GPU, T1200 Laptop GPU,
+  RTX A5000 Laptop GPU, RTX A4000 Laptop GPU, RTX A3000 Laptop GPU,
+  RTX A2000 Laptop GPU.
+- Fixed a bug that could prevent a system from resuming from suspend
+  when DisplayPort activity occurred while the system was suspended.
+- Fixed a regression that prevented eglQueryDevicesEXT from correctly
+  enumerating GPUs on systems with multiple GPUs where access to the
+  GPU device files was restricted for some GPUs.
+- Fixed a regression that could cause system hangs when changing display
+  resolution on SLI Mosaic configurations.
+
+  [ Luca Boccassi ]
+  * Update nv-readme.ids.
+  * Refresh kmods patches to remove fuzz.
+
+ -- Andreas Beckmann   Fri, 21 May 2021 22:21:31 +0200
+
 nvidia-graphics-drivers (460.73.01-1) unstable; urgency=medium
 
   * New upstream production branch release 460.73.01 (2021-04-14).
@@ -27,8 +79,8 @@ nvidia-graphics-drivers (460.67-1) unstable; urgency=medium
 
 nvidia-graphics-drivers (460.56-2) unstable; urgency=medium
 
-  * Add libnvidia-ml.so slave alternative if libnvidia-ml-dev is installed.
-(Closes: #984881)
+  * nvidia-alternative: Add libnvidia-ml.so slave alternative if
+libnvidia-ml-dev is installed.  (Closes: #984881)
 
  -- Andreas Beckmann   Wed, 10 Mar 2021 21:03:59 +0100
 
@@ -275,6 +327,25 @@ nvidia-graphics-drivers (455.23.04-1) experimental; 
urgency=medium
 
  -- Andreas Beckmann   Thu, 24 Sep 2020 21:52:54 +0200
 
+nvidia-graphics-drivers (450.142.00-1) UNRELEASED; urgency=medium
+
+  * New upstream Tesla release 450.142.00 (2021-07-20).
+* Fixed CVE-2021-1093, CVE-2021-1094, CVE-2021-1095.
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5211
+- Fixed a bug that could result in blank displays when driving multiple
+  displays at the same resolution using active DisplayPort dongles.
+
+  [ Andreas Beckmann ]
+  * Refresh patches.
+
+ -- Andreas 

Bug#991491: unblock: runit/2.1.2-41 (pre-approval)

2021-07-26 Thread Sebastian Ramacher
Control: tags -1 moreinfo confirmed

On 2021-07-25 20:31:25 +0200, Lorenzo Puliti wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: plore...@disroot.org
> 
> Dear release team,
> this is a pre-approval request for a runit upload.
> 
> [ Reason ]
> The switch for SysVinit users is broken, the current code works
> only if a user types 'reboot', then login into the emergency shell
> and types 'reboot' again (see #991227).
> With the attached patch:
>  * the -f and -r flags work as expected
>  * the shutdown interface is documented in the manpage. 
> 
> [ Impact ]
> Without this patch SysVinit users will likely need to press the reset button 
> (see #991227),
> which is a regression compared to the runit's version in Buster - the bug was 
> introduced
> in runit 2.1.2-27 (#919699).
> Poweroff instead of reboot when the -r flag is passed (#990774) can be bad if 
> one
> does 'shutdown -r now' on a remote machine expecting to be able to login 
> again..
> 
> [ Tests ]
> I've manually run the qemu autopkgtest to ensure that there is no regression
> for the systemd-->runit-init switch.
> I've tested in Virtualbox that the patch fixes the SysVinit-->runit-init 
> switch,
> which is currently broken in unstable/testing.
> I'm using the runit package from experimental that include the proposed
> fix and shutdown or reboot works as expected.
> 
> [ Risks ]
> This change affects runit-init users (popcon ~ 20) and users of
> other init systems but only when they perform the switch to runit.
> 
> [ 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 runit/2.1.2-41
> 
> Lorenzo
> 
> diff -Nru ./runit/debian/changelog ./runit-bullseye/debian/changelog
> --- ./runit/debian/changelog  2021-07-25 15:48:55.494007628 +0200
> +++ ./runit-bullseye/debian/changelog 2021-07-25 17:03:59.122707529 +0200
> @@ -1,3 +1,14 @@
> +runit (2.1.2-41) unstable; urgency=medium
> +
> +  * Cherry-pick shutdown.c fixes from experimental
> +for incoming stable release:
> +- fix broken switch from SysVinit due to wrong
> +  command line parsing logic
> +- reboot the system with -r flag instead of poweroff
> +- Update shutdown(8) manpage

Is this missing some Closes: #NN?

In any case, please go ahead and remove the moreinfo tag once the new
version is available in unstable.

Cheers

> +
> + -- Lorenzo Puliti   Sun, 25 Jul 2021 16:35:08 +0200
> +
>  runit (2.1.2-40) unstable; urgency=medium
>  
>* Ack previous NMU, thanks Boyuan Yang for the upload
> diff -Nru ./runit/debian/contrib/shutdown.8 
> ./runit-bullseye/debian/contrib/shutdown.8
> --- ./runit/debian/contrib/shutdown.8 2021-07-25 15:48:55.494007628 +0200
> +++ ./runit-bullseye/debian/contrib/shutdown.82021-07-25 
> 16:23:23.731732301 +0200
> @@ -1,15 +1,66 @@
> -.TH SHUTDOWN 8 "Oct 10, 2016" "" "GNU/Linux System Adminstrator's manual"
> +.TH SHUTDOWN 8 "July 16, 2021" "" "GNU/Linux System Adminstrator's manual"
>  .SH NAME
> -shutdown, reboot, poweroff \- stop the system
> +shutdown, reboot, poweroff \- poweroff or reboot the system
>  .SH SYNOPSIS
> -.B /sbin/shutdown
> +.B /sbin/shutdown [-w] [-f] [-r]
>  .br
> -.B /sbin/reboot
> +.B /sbin/reboot [-w] [-f] [-r]
>  .br
> -.B /sbin/halt
> +.B /sbin/halt [-w] [-f] [-r]
> +.br
> +.B /sbin/poweroff [-w] [-f] [-r]
>  .SH DESCRIPTION
> -SysV-init compatibility scripts, that just invokes
> -.BR /sbin/init ,
> -which are expected by graphical desktop environments.
> +.BR Shutdown
> +is a program to poweroff or reboot the system that maintains some 
> compatibility with
> +original SysV-init halt, poweroff, reboot and shutdown programs.
> +These programs are expected by some initscripts, graphical desktop 
> environments and tools like acpi.
> +.RE
> +When called as shutdown, halt or poweroff without options,
> +.BR runit(8)
> +is told to shutdown the system and poweroff.
> +.RE
> +When called as reboot
> +.BR runit(8)
> +is told to reboot the system.
> +.RE
> +When
> +.BR runit(8)
> +is not the current init system this program sends data in the appropriate 
> format to perform the requested action to the initctl pipe, if it exists.
> +.SH OPTIONS
> +
> +.TP
> +.B \-f, \-\-force
> +Force unsafe reboot or poweroff immediately without signaling the init 
> system.
> +This will likely result in an unclean shutdown an can cause data loss or 
> corruption.
> +
> +.TP
> +.B \-w, \-\-wtmp\-only
> +No-Op, maintained for compatibility with initscripts. See #919699
> +
> +.TP
> +.B \-r
> +Reboot the system regardless of how the command is called.
> +.SH SWITCHING FORM OTHER INIT SYSTEMS
> +This program maintains a compatibility layer with SysV-init's initctl pipe 
> according to the spec described in SysV-init's initctl(5). This allow one to 
> reboot the system when switching from another init to 

Bug#991529: ITP: maliit-keyboard -- Maliit Keyboard

2021-07-26 Thread Norbert Preining
Package: wnpp
Severity: wishlist
Owner: Norbert Preining 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-kde-t...@alioth-lists.debian.net

* Package name: maliit-keyboard
  Version : 2.0.0
  Upstream Author : Maliit Team
* URL : https://maliit.github.io/
* License : LGPL-2.1
  Programming Lang: C++
  Description : Maliit Keyboard

Touch Keyboard for Wayland based on Maliit Framework.


The package will be maintained in the Qt/KDE Team.



Bug#991528: ITP: maliit-framework -- Maliit Input Method Framework

2021-07-26 Thread Norbert Preining
Package: wnpp
Severity: wishlist
Owner: Norbert Preining 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-kde-t...@alioth-lists.debian.net

* Package name: maliit-framework
  Version : 2.0.0
  Upstream Author : Maliit Team
* URL : https://maliit.github.io/
* License : LGPL-2.1
  Programming Lang: C++
  Description : Maliit Input Method Framework

Maliit provides a flexible and cross-platform input method framework. It has a
plugin-based client-server architecture where applications act as clients and
communicate with the Maliit server via input context plugins. The communication
link currently uses D-Bus. Maliit is an open source framework (LGPL 2) with
open source plugins (BSD).


The package will be maintained in the Qt/KDE Team.



Bug#989080: cifs-utils: diff for NMU version 2:6.11-3.1

2021-07-26 Thread Sebastian Ramacher
Dear maintainer,

I've prepared an NMU for cifs-utils (versioned as 2:6.11-3.1). The diff
is attached to this message.

Regards.
-- 
Sebastian Ramacher
diff -Nru cifs-utils-6.11/debian/changelog cifs-utils-6.11/debian/changelog
--- cifs-utils-6.11/debian/changelog	2021-05-06 21:24:29.0 +0200
+++ cifs-utils-6.11/debian/changelog	2021-07-26 23:16:25.0 +0200
@@ -1,3 +1,13 @@
+cifs-utils (2:6.11-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Hideki Yamane ]
+  * debian/patches
+- Add 0011-fix-regression-for-CVE-2021-20208.patch (Closes: #989080)
+
+ -- Sebastian Ramacher   Mon, 26 Jul 2021 23:16:25 +0200
+
 cifs-utils (2:6.11-3) unstable; urgency=high
 
   * CVE-2021-20208: cifs.upcall kerberos auth leak in container
diff -Nru cifs-utils-6.11/debian/patches/0011-fix-regression-for-CVE-2021-20208.patch cifs-utils-6.11/debian/patches/0011-fix-regression-for-CVE-2021-20208.patch
--- cifs-utils-6.11/debian/patches/0011-fix-regression-for-CVE-2021-20208.patch	1970-01-01 01:00:00.0 +0100
+++ cifs-utils-6.11/debian/patches/0011-fix-regression-for-CVE-2021-20208.patch	2021-07-26 23:16:21.0 +0200
@@ -0,0 +1,490 @@
+From 4ca235223d948fe4f3392da28b1471bce36e88d4 Mon Sep 17 00:00:00 2001
+From: Aurelien Aptel 
+Date: Wed, 21 Apr 2021 16:22:15 +0200
+Subject: [PATCH v4] cifs.upcall: fix regression in kerberos mount
+
+The fix for CVE-2021-20208 in commit e461afd ("cifs.upcall: try to use
+container ipc/uts/net/pid/mnt/user namespaces") introduced a
+regression for kerberos mounts when cifs-utils is built with
+libcap-ng. It makes mount fail with ENOKEY "Required key not
+available".
+
+Current state:
+
+mount.cifs
+ '---> mount() ---> kernel
+   	   negprot, session setup (need security blob for krb)
+   request_key("cifs.spnego",  payload="pid=%d;username=...")
+   upcall
+  /sbin/request-key <--'
+   reads /etc/request-keys.conf
+   dispatch cifs.spnego request
+   calls /usr/sbin/cifs.upcall 
+   - drop privileges (capabilities)
+   - fetch keyid
+   - parse payload
+   - switch to mount.cifs namespaces
+   - call krb5_xxx() funcs
+   - generate security blob
+   - set key value to security blob
+  '---> kernel
+ put blob in session setup packet
+     continue auth
+     open tcon
+     get share root
+     setup superblock
+mount.cifs mount() returns<---'
+
+By the time cifs.upcall tries to switch to namespaces, enough
+capabilities have dropped in trim_capabilities() that it makes setns()
+fail with EPERM.
+
+setns() requires CAP_SYS_ADMIN.
+
+With libcap trim_capabilities() is a no-op.
+
+This fix:
+
+- moves the namespace switch earlier so that operations like
+  setgroups(), setgid(), scanning of pid environment, ... happens in the
+  contained namespaces.
+- moves trim_capabilities() after the namespace switch
+- moves the string processing to decode the key request payload in a
+  child process with minimum capabilities. the decoded data is shared
+  with the parent process via shared memory obtained with mmap().
+
+Fixes: e461afd ("cifs.upcall: try to use container ipc/uts/net/pid/mnt/user namespaces")
+Signed-off-by: Aurelien Aptel 
+---
+ cifs.upcall.c | 214 --
+ 1 file changed, 139 insertions(+), 75 deletions(-)
+
+Index: cifs-utils/cifs.upcall.c
+===
+--- cifs-utils.orig/cifs.upcall.c
 cifs-utils/cifs.upcall.c
+@@ -52,6 +52,9 @@
+ #include 
+ #include 
+ #include 
++#include 
++#include 
++#include 
+ 
+ #include "data_blob.h"
+ #include "spnego.h"
+@@ -777,6 +780,25 @@ handle_krb5_mech(const char *oid, const
+ 	return retval;
+ }
+ 
++
++
++struct decoded_args {
++	int ver;
++	char hostname[NI_MAXHOST + 1];
++	char ip[NI_MAXHOST + 1];
++
++/* Max user name length. */
++#define MAX_USERNAME_SIZE 256
++	char username[MAX_USERNAME_SIZE + 1];
++
++	uid_t uid;
++	uid_t creduid;
++	pid_t pid;
++	sectype_t sec;
++
++/*
++ * Flags to keep track of what was provided
++ */
+ #define DKD_HAVE_HOSTNAME	0x1
+ #define DKD_HAVE_VERSION	0x2
+ #define DKD_HAVE_SEC		0x4
+@@ -786,23 +808,13 @@ handle_krb5_mech(const char *oid, const
+ #define DKD_HAVE_CREDUID	0x40
+ #define DKD_HAVE_USERNAME	0x80
+ #define DKD_MUSTHAVE_SET (DKD_HAVE_HOSTNAME|DKD_HAVE_VERSION|DKD_HAVE_SEC)
+-
+-struct decoded_args {
+-	int ver;
+-	char *hostname;
+-	char *ip;
+-	char *username;
+-	uid_t uid;
+-	uid_t creduid;
+-	pid_t pid;
+-	sectype_t sec;
++	int have;
+ };
+ 
+ static unsigned int
+-decode_key_description(const char *desc, struct decoded_args *arg)
++__decode_key_description(const char *desc, struct decoded_args *arg)
+ {
+-	int len;
+-	int retval = 0;
++	size_t len;
+ 	char *pos;
+ 	const char *tkn = desc;
+ 
+@@ -816,13 +828,13 @@ decode_key_description(const char *desc,
+ len = pos 

Bug#973599: nvidia-graphics-drivers-legacy-340xx: EoL driver should not be released with bullseye

2021-07-26 Thread Andreas Beckmann

On Wed, 05 May 2021 09:38:25 +0300 jim_p  wrote:

Because the package will remain in sid, I would like to ask if you will accept
patches for future versions of the kernel, or, in a few words, if the package
will continue to be upgraded.


I'll try to keep the package updated in sid for supporting newer kernel 
versions as long as this is possible with reasonable effort. So only 
packaged Debian kernels in sid/experimental will be tested. And patches 
must not regress on any (ancient) Debian kernel where the module 
previously built.


Once Xorg bumps its ABI again the driver will only work with the older 
Xorg in (old)stable.


Andreas



Bug#991088: librda: diff for NMU version 0.0.5-1.1

2021-07-26 Thread Sebastian Ramacher
Control: tags 991088 + patch
Control: tags 991088 + pending

Dear maintainer,

I've prepared an NMU for librda (versioned as 0.0.5-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru librda-0.0.5/debian/changelog librda-0.0.5/debian/changelog
--- librda-0.0.5/debian/changelog	2019-02-03 23:16:11.0 +0100
+++ librda-0.0.5/debian/changelog	2021-07-26 22:53:33.0 +0200
@@ -1,3 +1,10 @@
+librda (0.0.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Build with dh gir sequence (Closes: #991088)
+
+ -- Sebastian Ramacher   Mon, 26 Jul 2021 22:53:33 +0200
+
 librda (0.0.5-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru librda-0.0.5/debian/rules librda-0.0.5/debian/rules
--- librda-0.0.5/debian/rules	2018-11-09 23:56:13.0 +0100
+++ librda-0.0.5/debian/rules	2021-07-26 22:52:40.0 +0200
@@ -7,7 +7,7 @@
 include /usr/share/dpkg/buildflags.mk
 
 %:
-	dh $@ --with autoreconf
+	dh $@ --with autoreconf,gir
 
 override_dh_auto_configure:
 	dh_auto_configure $(DHFLAGS) --		\


signature.asc
Description: PGP signature


Bug#991053: ftgl: diff for NMU version 2.4.0-2.1

2021-07-26 Thread Sebastian Ramacher
Dear maintainer,

I've prepared an NMU for ftgl (versioned as 2.4.0-2.1). The diff
is attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru ftgl-2.4.0/debian/changelog ftgl-2.4.0/debian/changelog
--- ftgl-2.4.0/debian/changelog	2019-02-26 16:52:23.0 +0100
+++ ftgl-2.4.0/debian/changelog	2021-07-26 22:41:23.0 +0200
@@ -1,3 +1,14 @@
+ftgl (2.4.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ William Grant ]
+  * Don't try to convert PNG to EPS for latex, as our imagemagick has EPS
+disabled for security reasons and it seems to work without them. (Closes:
+#991053)
+
+ -- Sebastian Ramacher   Mon, 26 Jul 2021 22:41:23 +0200
+
 ftgl (2.4.0-2) unstable; urgency=medium
 
   * Install ftgl.pdf file again, the external problem generating PDF file
diff -Nru ftgl-2.4.0/debian/patches/no-eps.patch ftgl-2.4.0/debian/patches/no-eps.patch
--- ftgl-2.4.0/debian/patches/no-eps.patch	1970-01-01 01:00:00.0 +0100
+++ ftgl-2.4.0/debian/patches/no-eps.patch	2021-07-26 22:40:30.0 +0200
@@ -0,0 +1,13 @@
+Index: ftgl-2.4.0/docs/Makefile.am
+===
+--- ftgl-2.4.0.orig/docs/Makefile.am
 ftgl-2.4.0/docs/Makefile.am
+@@ -26,7 +26,7 @@ endif
+ 	touch $@
+ 
+ html/doxygen.css: stamp-doxygen
+-stamp-doxygen: doxygen.cfg stamp-eps
++stamp-doxygen: doxygen.cfg
+ 	$(DOXYGEN) $^
+ 	for file in html/*html; do \
+ 	  $(SED) -e 's/%FTGL/FTGL/' < $$file > $$file.tmp; \
diff -Nru ftgl-2.4.0/debian/patches/series ftgl-2.4.0/debian/patches/series
--- ftgl-2.4.0/debian/patches/series	2019-02-26 16:28:55.0 +0100
+++ ftgl-2.4.0/debian/patches/series	2021-07-26 22:40:30.0 +0200
@@ -1 +1,2 @@
 fix-doc-projects-eman2.patch
+no-eps.patch


signature.asc
Description: PGP signature


Bug#991526: libpdfbox2-java: CVE-2021-31811 CVE-2021-31812

2021-07-26 Thread Salvatore Bonaccorso
Source: libpdfbox2-java
Version: 2.0.23-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:libpdfbox-java 1:1.8.16-2
Control: retitle -2 libpdfbox-java: CVE-2021-31811 CVE-2021-31812

Hi,

The following vulnerabilities were published for libpdfbox2-java.

CVE-2021-31811[0]:
| In Apache PDFBox, a carefully crafted PDF file can trigger an
| OutOfMemory-Exception while loading the file. This issue affects
| Apache PDFBox version 2.0.23 and prior 2.0.x versions.


CVE-2021-31812[1]:
| In Apache PDFBox, a carefully crafted PDF file can trigger an infinite
| loop while loading the file. This issue affects Apache PDFBox version
| 2.0.23 and prior 2.0.x versions.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-31811
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31811
[1] https://security-tracker.debian.org/tracker/CVE-2021-31812
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31812

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#991493: telegram-desktop: CVE-2021-36769

2021-07-26 Thread Moritz Mühlenhoff
Am Mon, Jul 26, 2021 at 11:13:10PM +0300 schrieb Nicholas Guriev:
> Hello!
> 
> I skimmed the paper you pointed out and commit history in the upstream
> Git repository, and I came to conclusion that to address the issue, it
> is simpler and safer to upload the latest upstream release rather than
> collecting and backporting targeted fixes despite of the final stage of
> freezing in Debian. I would prefer to upload an update of the telegram-
> desktop package and its satellites, libtgowt and libtgvoip, if the
> release team does not mind.
> 
> There were a lot of changes since 2.6.1 version currently available in
> unstable. Fixes of the security issue were not isolated, and it is too
> burdensome splitting them now.

You can file an advance unblock request against release.debian.org, so
that they can chime in before uploading to unstable.

Cheers,
 Moritz



Bug#991493: telegram-desktop: CVE-2021-36769

2021-07-26 Thread Nicholas Guriev
Hello!

I skimmed the paper you pointed out and commit history in the upstream
Git repository, and I came to conclusion that to address the issue, it
is simpler and safer to upload the latest upstream release rather than
collecting and backporting targeted fixes despite of the final stage of
freezing in Debian. I would prefer to upload an update of the telegram-
desktop package and its satellites, libtgowt and libtgvoip, if the
release team does not mind.

There were a lot of changes since 2.6.1 version currently available in
unstable. Fixes of the security issue were not isolated, and it is too
burdensome splitting them now.



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


Bug#991525: golang-github-containernetworking-plugin-dnsname should depend on dnsmasq-base

2021-07-26 Thread Dan Nicholson
Package: golang-github-containernetworking-plugin-dnsname
Version: 1.1.1+ds1-4+b7

This plugin works by invoking dnsmasq and will immediately fail if it
can't be found:
https://github.com/containers/dnsname/blob/main/plugins/meta/dnsname/service.go#L19.
As such, it should depend on dnsmasq-base since it's entirely
non-functional without it.

--
Dan Nicholson  |  +1.206.437.0833  |  Endless



Bug#991524: unblock: node-jszip/3.5.0+dfsg-2

2021-07-26 Thread Yadd
Le 26/07/2021 à 22:01, Yadd a écrit :
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package node-jszip
> 
> [ Reason ]
> node-jszip is vulnerable to a prototype pollution: rafting a new zip file
> with filenames set to Object prototype values (e.g __proto__, toString,
> etc) results in a returned object with a modified prototype instance.

Ref: CVE-2021-23413



Bug#991524: unblock: node-jszip/3.5.0+dfsg-2

2021-07-26 Thread Yadd
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package node-jszip

[ Reason ]
node-jszip is vulnerable to a prototype pollution: rafting a new zip file
with filenames set to Object prototype values (e.g __proto__, toString,
etc) results in a returned object with a modified prototype instance.

[ Impact ]
Little security issue.

[ Tests ]
Sadly test are not launched for this package.

[ Risks ]
No risk, patch 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

Cheers,
Yadd

unblock node-jszip/3.5.0+dfsg-2
diff --git a/debian/changelog b/debian/changelog
index 7994aaf..bbfd736 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-jszip (3.5.0+dfsg-2) unstable; urgency=medium
+
+  * Team upload
+  * Fix GitHub tags regex
+  * Fix a null prototype object for this.files (Closes: CVE-2021-23413)
+
+ -- Yadd   Mon, 26 Jul 2021 21:54:02 +0200
+
 node-jszip (3.5.0+dfsg-1) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2021-23413.patch 
b/debian/patches/CVE-2021-23413.patch
new file mode 100644
index 000..7f3e672
--- /dev/null
+++ b/debian/patches/CVE-2021-23413.patch
@@ -0,0 +1,43 @@
+Description: fix: Use a null prototype object for this.files
+Author: Michael Aquilina 
+Bug: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23413
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-07-26
+
+--- a/lib/index.js
 b/lib/index.js
+@@ -19,7 +19,10 @@
+ //   "folder/" : {...},
+ //   "folder/data.txt" : {...}
+ // }
+-this.files = {};
++// NOTE: we use a null prototype because we do not
++// want filenames like "toString" coming from a zip file
++// to overwrite methods and attributes in a normal Object.
++this.files = Object.create(null);
+ 
+ this.comment = null;
+ 
+--- a/lib/object.js
 b/lib/object.js
+@@ -179,16 +179,16 @@
+  */
+ forEach: function(cb) {
+ var filename, relativePath, file;
++/* jshint ignore:start */
++// ignore warning about unwanted properties because this.files is a 
null prototype object
+ for (filename in this.files) {
+-if (!this.files.hasOwnProperty(filename)) {
+-continue;
+-}
+ file = this.files[filename];
+ relativePath = filename.slice(this.root.length, filename.length);
+ if (relativePath && filename.slice(0, this.root.length) === 
this.root) { // the file is in the current root
+ cb(relativePath, file); // TODO reverse the parameters ? need 
to be clean AND consistent with the filter search fn...
+ }
+ }
++/* jshint ignore:end */
+ },
+ 
+ /**
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..b0d53b4
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2021-23413.patch
diff --git a/debian/watch b/debian/watch
index 46895cc..4525548 100644
--- a/debian/watch
+++ b/debian/watch
@@ -4,4 +4,4 @@ repacksuffix=+dfsg,\
 repack,compression=xz,\
 dversionmangle=auto,\
 filenamemangle=s/.*\/v?([\d\.-]+)\.tar\.gz/node-jszip-$1.tar.gz/ \
- https://github.com/Stuk/jszip/tags .*/archive/v?([\d\.]+).tar.gz
+ https://github.com/Stuk/jszip/tags .*/archive/.*/v?([\d\.]+).tar.gz


Bug#989863: debian-installer: Firmware problems in bullseye

2021-07-26 Thread Salvatore Bonaccorso
HI Cyril,

On Mon, Jul 26, 2021 at 06:14:09AM +0200, Cyril Brulebois wrote:
> @KT:
> 
> I haven't uploaded it since I'm seeing iwlwifi requesting what appears
> to be a debug-only firmware (iwl-debug-yoyo.bin), that's even requested
> via an aptly-named firmware_request_nowarn() function in linux.git; I'd
> like to check with the kernel maintainers whether it's expected for this
> message to show up in dmesg still (given the name and comments in
> linux.git, I'm not sure it should). In any cases, it's slightly sad to
> pause and prompt users from firmware files we don't ship anywhere
> (AFAICT), that they don't actually need.
> 
> Therefore, I'm tempted to blacklist this firmware file in hw-detect
> (i.e. pretend it was never requested).

This reminds me of the long(ish) standing bug report #969264 and
#966218.

Regards,
Salvatore



Bug#991254: golang-google-genproto-dev: Outdated package

2021-07-26 Thread Peymaneh Nejad


Hi,

just letting you know that I am adding a debian/experimental branch with an 
updated version to salsa and for a team-upload to experimental.


kind regards,
Peymaneh



OpenPGP_signature
Description: OpenPGP digital signature


Bug#991523: unblock: mariadb-10.5/1:10.5.11-1

2021-07-26 Thread Otto Kekäläinen
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mariadb-10.5 to allow new upstream maintenance
release into Bullseye.

[ Motivation ]

The new upstream version 10.5.11 is a maintenance release that only
fixes bugs. Among them two severe regressions introduced in 10.5.10:

* Table alias from previous statement interferes later commands (MDEV-25672)
* Join using derived with aggregation returns incorrect results (MDEV-25714)

(https://mariadb.com/kb/en/mariadb-10511-release-notes/)

Occasionally new MariaDB versions are uploaded to stable updates and
they have a good track record of not causing (Debian packaging)
regressions. It is worthwhile to include this package in Bullseye so
that we don't need to upload it as a stable update later.

MariaDB 10.3 and 10.5 in Debian have a good track record of
high-quality stable and security releases, they use extensive Salsa-CI
and autopkgtests and have a low number of bugs in Debian
(https://qa.debian.org/data/bts/graphs/m/mariadb-10.5.png). Making
this release addiotionally dropped mariadb-10.5 bug count in Debian
from 35 to 26.

In addition to the new upstream version, this release also has
Bullseye-tailored fixes in documentation and testing and adds one
patch that makes MariaDB 10.5 build in a reproducible way in Debian.
It is very unlikely to cause any regressions since it only modifies a
build-time timestamp and is based on a patch cherry-picked from
RocksDB where it has been in a production release for over 6 months.

This release also fixes debian/control metadata that fixes Bullseye
upgrades for apt users (it was detected that apt-get and apt resolves
upgrades differently, see Bugs#990992).

[ 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

[ changelog ]
mariadb-10.5 (1:10.5.11-1) unstable; urgency=medium

  * New upstream version 10.5.11. Includes several important bug fixes,
including a replication hang (Closes: #991399, Closes: #989400)
  * Cleanup, documentation and testing:
* Drop backported patch for armfh build now in 10.5.11 from upstream.
* Drop patch no longer needed with latest gcc-10 (Closes: #972564)
* Save autopkgtests results as JUnit-compatible XML-report
* Salsa-CI: Verify wrap-and-sort usage and correctness of patches/series
  * Remove rocksdb_build_git_date from RocksDB binaries to make them
build in a reproducible way, thus making the entire MariaDB finally
reproducible (Closes: #976985)

  [ Andreas Beckmann ]
  * Ease switching from galera-3 to galera-4 on upgrades from buster
(Closes: #990708, Closes: #976147, Closes: #977137)

[debdiff]
The attached debdiff only has the changes in debian/ as it would
otherwise be so big.
To view a full diff please visit
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/compare/916d02055c70372621c463043387e1367e20cb12...022b4af7387f7f111050a0e7a642d8dd9f56619d

[migration delay]
The Current version has been in experimental since July 18th and in
unstable since July 26th and will migrate to testing/Bullseye earliest
on July 31th.

unblock: mariadb-10.5/1:10.5.11-1


mariadb-10.5_1%10.5.11-1.debdiff.xz
Description: application/xz


Bug#991522: ITP: golang-github-antlr-antlr4 -- Golang runtime library for ANTLR4

2021-07-26 Thread Peymaneh Nejad
Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-antlr-antlr4
  Version : 4.9.2-1
  Upstream Author : Antlr Project
* URL : https://github.com/antlr/antlr4
* License : TODO
  Programming Lang: Go
  Description : Golang runtime library for ANTLR4

This is a dependency of github.com/google/cel-go (#991159)



Bug#990954: kodi: crashes on older hardware

2021-07-26 Thread Vasyl Gello
Hi Sven!

Just a very wild guess: make sure your user is in "audio", "video" and "render" 
groups:

usermod -a -G audio,render,video user

For me, having "kodi" user out of these groups resulted in fallback VDPAU 
turned instead of proper VAAPI.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#990678: budgie-desktop: Various problems with the display of software windows.

2021-07-26 Thread Pascal
Package: budgie-desktop
Version: 10.5.2-4
Followup-For: Bug #990678
X-Debbugs-Cc: pascal.mart...@gmx.fr

Dear Maintainer,

I must again bring some rectification to what I said from the 21th of July.

For compositing windows, I thought that I had brought Mutter as a replacement
to Compton/Picom in Openbox. In fact I hadn't. As everything worked fine, I
thought it was thanks to Mutter. Not at all, it was thanks to Feh, the famous
background chooser that must have some X11 dependencies that take in charge the
handling of the windows.

I discovered all this by launching Openbox without its ~/.config/openbox/
directory and launching programs in autostart(.sh) one by one. The launching of
Mutter in a terminal returned an error (in fact I don't know how to properly
handle Mutter) that went unnoticed during every Openbox starting.

There was just one problem at every fresh Openbox start, a wrong launching of
"Kupfer" (had to click on it for key capture) or "Emacs --maximized" (was not
maximized) for instance. After a restart from Openbox itself it then worked
properly. That must have "washed" in some way the internal error from Mutter as
autostart(.sh) is not relaunched by restart from Openbox. That slight Openbox
bad working led me into this little inquiry that took me several days or search
and trying. I am just an amateur.

I wanted to rectify this, so the possible reader would not be induced into
error. Maybe there is a way to bring Mutter into Openbox, but maybe it would
end up being heavy and complex instead of light and simple as we like it.

And so, regarding budgie-desktop, the good working of MPV and other software in
Openbox has nothing to do with Mutter.

Cordially,
Pascal.

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

Kernel: Linux 5.10.0-8-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-4
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-budgie-1.010.5.2-4
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#991521: unblock: galera-3/25.3.33-1

2021-07-26 Thread Otto Kekäläinen
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package galera-3 to allow new upstream maintenance
release into Bullseye.

unblock: galera-3/25.3.33-1

[ Motivation ]

The new upstream version 25.3.33 is a maintenance release that only
fixes bugs. Occasionally new Galera versions are uploaded to stable
updates and they have a good track record of not causing regressions.
It is worthwhile to include this package in Bullseye so that we don't
need to upload it as a stable update later.

This package is also needed into Bullseye in order to ship updates to
buster-backports and stretch-backports, as backports are capped to the
latest release version in a later distro release (=Bullseye).

Package galera-3 is a leaf package (nothing depends on it in Debian
Bullseye) so risks are low.

Galera 3 also has an excellent track records of using Salsa-CI,
autopkgtests and has had zero bugs filed against it for a long time:
https://qa.debian.org/data/bts/graphs/g/galera-3.png

It does also have changes in packaging, but only the necessary ones to
adapt to upstream changes and the changes are identical with what was
done upstream and what has been out there (by upstream outside of
Debian) for several months now without any reported regressions.

[ 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

[ changelog ]
galera-3 (25.3.33-1) unstable; urgency=low
  * New upstream version 25.3.33
  * Follow upstream change and switch from SCons to CMake. This
is necessary, otherwise building from sources would fail.
  * Remove patches applied upstream or obsoleted by SCons->CMake change
  * Add Lintian overrides for libgalera_smm.so changes that are intentional

Sorry for not filing this unblock request 2 months ago. I somehow
forgot about galera-3 while focusing on galera-4 and mariadb-10.5...


galera-3_25.3.33-1.debdiff.xz
Description: application/xz


Bug#988456: atftp packaging on salsa

2021-07-26 Thread Andreas B. Mundt
Hi everybody,

the atftp packaging is now available on salsa:

  https://salsa.debian.org/debian/atftp

Hopefully the issues mentioned in this bug report can be addressed soon.
So far I updated the sources and fixed some lintian warnigs.

The next step is the integration with systemd.  Any help is appreciated.

Best regards,

  Andi



Bug#757356: Apple keyboard: Scan code event (EV_MSC) not generated when the EV_KEY event is generated by hid-apple.c

2021-07-26 Thread Vincent Lefevre
On 2021-07-21 18:28:44 -0400, Daniel Lin wrote:
> Yes, I haven't used a machine with hid_apple in many years, but the
> patch sign-off is OK with me.

Thanks. For the reference of my patch submission a few days ago:

  https://www.spinics.net/lists/linux-input/msg74111.html

  https://lore.kernel.org/patchwork/project/lkml/list/?series=509091

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



Bug#981113: ITP: root-framework -- data analysis framework

2021-07-26 Thread Stephan Lachnit
For everyone who is interested in the topic: Initial packaging for 
v6.24.02 is

now on Salsa [1]. Let me know if you have issues with building.

The following things still need to be done, orderd after importance:
- write a DEP-5 copyright
- remove builtins from the source tarball
- split the package sanely
- understand linking of libRInside.so
- package UNU.RAN [2]
- package VDT [3]
- package VecGeom [4]
- update Pythia8 [5, 6]

Some notes: the usual library splitting is basically impossible for ROOT.
There are several reasons for this, one being the insane amount of 
libraries,
142 to be precise. Some of them also have very general names like 
"libGui.so".

The other reason is that ROOT works less like boost, which also has a lot of
libraries, and more like one interwoven network of libraries where you 
want to

have all (or at least most) of them.
For these two reasons, libraries are installed to 
lib/multi-arch-triplet/root
instead of lib/multi-arch-triplet, and a config for ld.so is added to 
pick the

libraries up. This isn't ideal of course, but better than the alternative.
Splitting thus will be more centered around additional dependencies, 
like for

example the Python interface of ROOT. But I haven't started with that yet.

The most important and still missing work is the DEP-5 copyright file. ROOT
has tons of files, and looking through them will take a significant 
amount of
time. ROOT also includes some thirdparty dependencies which we don't 
want and
need to remove from the source tarball. Since I'm wiriting my Bachelor 
thesis

at the moment, I don't have time for this anytime soon. If someone wants to
help with that, I would appreciate it.

Besides this, I'll still have to figure out how to properly link against 
the R
library, one mail to the R team is probably enough but I haven't done it 
yet.


All important dependencies are already packaged in Debian, but there are 
some
features that require additional dependencies. UNU.RAN can be used for 
random

number generation, but I haven't looked at the code yet at all. VDT can be
used for fast vectorized function, but the CMake build file require some 
heavy
modification to be actually usable. VecGeom is relatively straight 
forward to

package and I will probably upload it in the near future, it is used for
vectorized geometry. Pythia8 is a Monte-Carlo event generator, the 
package is

in Debian, but completely outdated and unmaintained.

- Stephan

[1] https://salsa.debian.org/science-team/root
[2] http://statistik.wu-wien.ac.at/unuran/
[3] https://github.com/dpiparo/vdt
[4] https://bugs.debian.org/988526
[5] https://tracker.debian.org/pkg/pythia8
[6] https://pythia.org/



Bug#991273: acng: for testing dist fails to download by-hash translations

2021-07-26 Thread Eduard Bloch
Hallo,
* Václav Ovsík [Mon, Jul 19 2021, 03:05:39PM]:
> Package: apt-cacher-ng
> Version: 3.3.1-2~bpo10+1
> Severity: normal

That's an ancient version in backports. Sorry for not having updated
this for a long time.

> Dear Maintainer,
> I tried to install bullseye machine and it fails to download some
> translations and installation fails:
>
>  Jul 19 10:29:53 in-target: E: Failed to fetch 
> http://debian.i.cz:/debian/dists/bullseye/non-free/i18n/by-hash/SHA256/1719a3a7f5c969d9780aec600763314a8b55aaaed3016a76fa9a7a020c1e584c
>   File has unexpected size (50436 != 91475). Mirror sync in progress? [IP: 
> 10.0.156.66 ]
>  Jul 19 10:29:53 in-target:Hashes of expected file:
>  Jul 19 10:29:53 in-target: - Filesize:91475 [weak]
>  Jul 19 10:29:53 in-target: - 
> SHA256:1719a3a7f5c969d9780aec600763314a8b55aaaed3016a76fa9a7a020c1e584c
>  Jul 19 10:29:53 in-target: - MD5Sum:c3ad4b048f3df02478a64b33ef776008 
> [weak]

That kind of corruption is supposed to be fixed in the Testing version.
I started the backport process but I am waiting for additionial
dependency to be accepted as backport in the archive
(https://buildd.debian.org/status/package.php?p=c-ares=buster-backports).

> Its obvious from the curl output:
>
>  zito@ser1:~/admin$ curl --head 
> http://debian.i.cz:/debian/dists/bullseye/non-free/i18n/by-hash/SHA256/1719a3a7f5c969d9780aec600763314a8b55aaaed3016a76fa9a7a020c1e584c
>  HTTP/1.1 200 OK
>  Content-Length: 50436
>  Last-Modified: Tue, 15 Jun 2021 01:57:32 GMT

This looks very wrong and indicates a file truncation in the cache. I
suggest to go to the admin webpage and run a cleanup operation
(Expiration task, with "check sizes and checksums" and "consider
incomplete files as damaged" checkboxes checked).

Best regards,
Eduard.



Bug#991520: checkrestart: "lsof: WARNING: can't stat() fuse.gvfsd-fuse file system..."

2021-07-26 Thread Vincent Lefevre
Package: debian-goodies
Version: 0.87
Severity: minor

When running checkrestart, I get the following warnings from lsof:

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/118/gvfs
  Output information may be incomplete.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
  Output information may be incomplete.

or only the second one.

It seems that the owner can stat such a directory, but not root:

cventin:~> /usr/bin/stat /run/user/1000/gvfs
  File: /run/user/1000/gvfs
  Size: 0   Blocks: 0  IO Block: 4096   directory
Device: 2ch/44d Inode: 1   Links: 2
Access: (0500/dr-x--)  Uid: ( 1000/vlefevre)   Gid: ( 1000/vlefevre)
Access: 2021-07-26 13:55:22.0 +0200
Modify: 2021-07-26 13:55:22.0 +0200
Change: 2021-07-26 13:55:22.0 +0200
 Birth: -

root@cventin:~# /usr/bin/stat /run/user/1000/gvfs
/usr/bin/stat: cannot statx '/run/user/1000/gvfs': Permission denied

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

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

debian-goodies depends on no packages.

Versions of packages debian-goodies recommends:
ii  apt2.2.4
ii  curl   7.74.0-1.3+b1
ii  dctrl-tools2.24-3+b1
ii  dialog 1.3-20201126-1
ii  elfutils   0.183-3
ii  equivs 2.3.1
ii  libfile-slurper-perl   0.012-2
ii  libfile-which-perl 1.23-1
ii  libipc-system-simple-perl  1.30-1
ii  man-db 2.9.4-2
ii  perl   5.32.1-4
ii  popularity-contest 1.71
ii  procps 2:3.3.17-5
ii  python33.9.2-3
ii  sensible-utils 0.0.14
ii  whiptail   0.52.21-4+b3
ii  zenity 3.32.0-7

Versions of packages debian-goodies suggests:
ii  apt-file   3.2.2
ii  elinks [www-browser]   0.13.2-1+b1
ii  firefox [www-browser]  88.0.1-1
hi  firefox-esr [www-browser]  52.9.0esr-1~deb9u1
pn  konqueror  
ii  links [www-browser]2.21-1+b1
ii  links2 [www-browser]   2.21-1+b1
ii  lsb-release11.1.0
ii  lsof   4.93.2+dfsg-1.1
ii  lynx [www-browser] 2.9.0dev.6-2
ii  openssh-client 1:8.4p1-5
ii  sudo   1.9.5p2-3
ii  w3m [www-browser]  0.5.3+git20210102-6
ii  xdg-utils  1.1.3-4.1

-- no debconf information

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



Bug#991518: cups: CUPS web interface is not available due to missing settings

2021-07-26 Thread Didier 'OdyX' Raboud
Control: tags -1 +moreinfo

26 juillet 2021 13:03 "Anthony Gaudino"  a écrit:
> Package: cups
> Version: 2.3.3op2-3+deb11u1
> Severity: normal
> X-Debbugs-Cc: anthonygaudin...@gmail.com
> 
> Dear Maintainer,
> 
> After installing CUPS, I could not access the web interface, trying to
> access localhost:631 showed a page not found error in the browser.

Hi again Anthony,

I'm very surprised by this, as this has been working reliably for a long time, 
and no recent changes have happened at all. So I just pulled a Debian Bullseye 
install and installed CUPS on it; the cupsd.conf file had this in, which makes 
for a working webinterface:

# Only listen for connections from the local machine.
Listen localhost:631
Listen /run/cups/cups.sock

# …

# Web interface setting...
WebInterface Yes

# Restrict access to the server...

  Order allow,deny


> I figured that I would need to add some settings in the CUPS
> configuration file (/etc/cups/cupsd.conf).
> 
> If I remember correctly I added:
> ```
> 
> Order Deny,Allow
> Deny From All
> Allow From 127.0.0.1
> 
> ```
> 
> After the changes I could access the CUPS web interface.

Is your machine really just a Debian Bullseye host? (It feels like it could 
have been cross-graded from Ubuntu…).

I'd be really curious to hear how you got in this situation, as a default 
Debian Bullseye with CUPS clearly has working print jobs and an accessible 
webinterface.

Best,
OdyX



Bug#991517: cups: CUPS cant access library files because they have different names

2021-07-26 Thread Didier 'OdyX' Raboud
Control: tags -1 +moreinfo

26 juillet 2021 12:36 "Anthony Gaudino"  a écrit:
> Package: cups
> Version: 2.3.3op2-3+deb11u1
> Severity: important
> X-Debbugs-Cc: anthonygaudin...@gmail.com
> 
> Dear Maintainer,
> 
> When I try to print anything with CUPS I had the following 2 errors on
> the CUPS log:
> 
> ```
> E [23/Jul/2021:17:37:03 +0100] [Job 27] libcups.so load failure
> E [23/Jul/2021:17:37:03 +0100] [Job 27] Unable to open raster stream - : 
> Broken pipe
> ```
> 
> The printer would not print anything.
> 
> After investigating, I found out that CUPS is trying to access
> `/usr/lib/x86_64-linux-gnu/libcups.so` and 
> `/usr/lib/x86_64-linux-gnu/libcupsimage.so`
> but Debian has these files named as `libcups.so.2` and
> `libcupsimage.so.2` instead.

Hello Anthony, and thanks for your report.

It seems you're trying to use a proprietary driver looking for the libcups.so 
filename. What driver are you trying to use?

> I solved the problem for myself by just copying those files and saving
> with the names CUPS was looking for.

.so files are not meant to be files, but symlinks, and these are shipped by 
libcups2-dev.

Isn't your issue solved by merely installing libcups2-dev ?

Best,

Didier


> -- System Information:
> Debian Release: 11.0
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
> Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages cups depends on:
> ii cups-client 2.3.3op2-3+deb11u1
> ii cups-common 2.3.3op2-3+deb11u1
> ii cups-core-drivers 2.3.3op2-3+deb11u1
> ii cups-daemon 2.3.3op2-3+deb11u1
> ii cups-filters 1.28.7-1
> ii cups-ppdc 2.3.3op2-3+deb11u1
> ii cups-server-common 2.3.3op2-3+deb11u1
> ii debconf [debconf-2.0] 1.5.77
> ii ghostscript 9.53.3~dfsg-7
> ii libavahi-client3 0.8-5
> ii libavahi-common3 0.8-5
> ii libc6 2.31-13
> ii libcups2 2.3.3op2-3+deb11u1
> ii libgcc-s1 10.2.1-6
> ii libstdc++6 10.2.1-6
> ii libusb-1.0-0 2:1.0.24-3
> ii poppler-utils 20.09.0-3.1
> ii procps 2:3.3.17-5
> 
> Versions of packages cups recommends:
> ii avahi-daemon 0.8-5
> ii colord 1.4.5-3
> 
> Versions of packages cups suggests:
> pn cups-bsd 
> pn cups-pdf 
> pn foomatic-db-compressed-ppds | foomatic-db 
> pn smbclient 
> ii udev 247.3-6
> 
> -- debconf information:
> cupsys/raw-print: true
> cupsys/backend: lpd, socket, usb, snmp, dnssd



Bug#991509: linux-image-amd64: marking TSC unstable due to check_tsc_sync_source failed (AMD Ryzen)

2021-07-26 Thread Salvatore Bonaccorso
Control: tags -1 + moreinfo

On Mon, Jul 26, 2021 at 02:35:55AM -0500, nelson g wrote:
> Package: linux-image-amd64
> Version: 5.10.46-2
> Severity: normal
> X-Debbugs-Cc: ledu...@hotmail.com
> 
> Hello,
> 
> My system is stuck with HPET clocksource
> 
> dmesg | egrep -i 'tsc|hpet|clocksource'
> [0.00] tsc: Fast TSC calibration using PIT
> [0.00] tsc: Detected 2096.096 MHz processor
> [0.004968] ACPI: HPET 0xB90A3000 38 (v01 LENOVO TP-R11
> 1210 PTEC 0002)
> [0.005018] ACPI: Reserving HPET table memory at [mem 
> 0xb90a3000-0xb90a3037]
> [0.014115] ACPI: HPET id: 0x43538210 base: 0xfed0
> [0.014183] clocksource: refined-jiffies: mask: 0x max_cycles:
> 0x, max_idle_ns: 7645519600211568 ns
> [0.059588] clocksource: hpet: mask: 0x max_cycles: 0x,
> max_idle_ns: 133484873504 ns
> [0.079620] clocksource: tsc-early: mask: 0x max_cycles:
> 0x1e36c89f085, max_idle_ns: 440795235573 ns
> [0.199622] TSC synchronization [CPU#0 -> CPU#1]:
> [0.199622] Measured 5479288407 cycles TSC warp between CPUs, turning off
> TSC clock.
> [0.199622] tsc: Marking TSC unstable due to check_tsc_sync_source failed
> [0.216551] clocksource: jiffies: mask: 0x max_cycles: 0x,
> max_idle_ns: 764504178510 ns
> [0.373390] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
> [0.373393] hpet0: 3 comparators, 32-bit 14.318180 MHz counter
> [0.375642] clocksource: Switched to clocksource hpet
> [0.392540] clocksource: acpi_pm: mask: 0xff max_cycles: 0xff,
> max_idle_ns: 2085701024 ns
> [1.137978] rtc_cmos 00:01: alarms up to one month, y3k, 114 bytes nvram,
> hpet irqs
> 
> 
> Sorry to bother but I'd like to report to debian this known bug in
> bugzilla.kernel = https://bugzilla.kernel.org/show_bug.cgi?id=202525 and 
> Lenovo
> = https://forums.lenovo.com/t5/Other-Linux-Discussions/Clocksource-falling-
> back-to-HPET-bec-TSC-is-unstable-ThinkPad-E14-Gen-2-maybe-others/m-p/5036464

If I did follow correctly the bugzilla entry then this is actually
something which needs to be fixed in firmware.

So I would tend to close this one again. 

Regards,
Salvatore



Bug#991518: cups: CUPS web interface is not available due to missing settings

2021-07-26 Thread Anthony Gaudino
Package: cups
Version: 2.3.3op2-3+deb11u1
Severity: normal
X-Debbugs-Cc: anthonygaudin...@gmail.com

Dear Maintainer,

After installing CUPS, I could not access the web interface, trying to
access localhost:631 showed a page not found error in the browser.

I figured that I would need to add some settings in the CUPS
configuration file (/etc/cups/cupsd.conf).

If I remember correctly I added:
```

Order Deny,Allow
Deny From All
Allow From 127.0.0.1

```

After the changes I could access the CUPS web interface.

I'm also attaching the whole configuration file.


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

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

Versions of packages cups depends on:
ii  cups-client2.3.3op2-3+deb11u1
ii  cups-common2.3.3op2-3+deb11u1
ii  cups-core-drivers  2.3.3op2-3+deb11u1
ii  cups-daemon2.3.3op2-3+deb11u1
ii  cups-filters   1.28.7-1
ii  cups-ppdc  2.3.3op2-3+deb11u1
ii  cups-server-common 2.3.3op2-3+deb11u1
ii  debconf [debconf-2.0]  1.5.77
ii  ghostscript9.53.3~dfsg-7
ii  libavahi-client3   0.8-5
ii  libavahi-common3   0.8-5
ii  libc6  2.31-13
ii  libcups2   2.3.3op2-3+deb11u1
ii  libgcc-s1  10.2.1-6
ii  libstdc++6 10.2.1-6
ii  libusb-1.0-0   2:1.0.24-3
ii  poppler-utils  20.09.0-3.1
ii  procps 2:3.3.17-5

Versions of packages cups recommends:
ii  avahi-daemon  0.8-5
ii  colord1.4.5-3

Versions of packages cups suggests:
pn  cups-bsd   
pn  cups-pdf   
pn  foomatic-db-compressed-ppds | foomatic-db  
pn  smbclient  
ii  udev   247.3-6

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: lpd, socket, usb, snmp, dnssd
LogLevel warn
PageLogFormat 
MaxLogSize 0
ErrorPolicy retry-job
Listen /run/cups/cups.sock
Listen /run/cups/cups.sock
Browsing On
BrowseLocalProtocols dnssd
DefaultAuthType Basic
WebInterface Yes

  Order allow,deny


  Order allow,deny


  AuthType Default
  Require user @SYSTEM
  Order allow,deny


  AuthType Default
  Require user @SYSTEM
  Order allow,deny


Order Deny,Allow
Deny From All
Allow From 127.0.0.1

Port 631
Listen 127.0.0.1:631

  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  
Order deny,allow
  
  
Require user @OWNER @SYSTEM
Order deny,allow
  
  
AuthType Default
Require user @SYSTEM
Order deny,allow
  
  
AuthType Default
Require user @SYSTEM
Order deny,allow
  
  
Require user @OWNER @SYSTEM
Order deny,allow
  
  
Order deny,allow
  


  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  
AuthType Default
Order deny,allow
  
  
AuthType Default
Require user @OWNER @SYSTEM
Order deny,allow
  
  
AuthType Default
Require user @SYSTEM
Order deny,allow
  
  
AuthType Default
Require user @SYSTEM
Order deny,allow
  
  
AuthType Default
Require user @OWNER @SYSTEM
Order deny,allow
  
  
Order deny,allow
  


  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  
AuthType Negotiate
Order deny,allow
  
  
AuthType Negotiate
Require user @OWNER @SYSTEM
Order deny,allow
  
  
AuthType Default
Require user @SYSTEM
Order deny,allow
  
  
AuthType Default
Require user @SYSTEM
Order deny,allow
  
  
AuthType Negotiate
Require user @OWNER @SYSTEM
Order deny,allow
  
  
Order deny,allow
  

JobPrivateAccess default
JobPrivateValues default
SubscriptionPrivateAccess default
SubscriptionPrivateValues default


Bug#991517: cups: CUPS cant access library files because they have different names

2021-07-26 Thread Anthony Gaudino
Package: cups
Version: 2.3.3op2-3+deb11u1
Severity: important
X-Debbugs-Cc: anthonygaudin...@gmail.com

Dear Maintainer,

When I try to print anything with CUPS I had the following 2 errors on
the CUPS log:

```
E [23/Jul/2021:17:37:03 +0100] [Job 27] libcups.so load failure
E [23/Jul/2021:17:37:03 +0100] [Job 27] Unable to open raster stream - : Broken 
pipe
```

The printer would not print anything.

After investigating, I found out that CUPS is trying to access
`/usr/lib/x86_64-linux-gnu/libcups.so` and 
`/usr/lib/x86_64-linux-gnu/libcupsimage.so`
but Debian has these files named as `libcups.so.2` and
`libcupsimage.so.2` instead.

I solved the problem for myself by just copying those files and saving
with the names CUPS was looking for.


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

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

Versions of packages cups depends on:
ii  cups-client2.3.3op2-3+deb11u1
ii  cups-common2.3.3op2-3+deb11u1
ii  cups-core-drivers  2.3.3op2-3+deb11u1
ii  cups-daemon2.3.3op2-3+deb11u1
ii  cups-filters   1.28.7-1
ii  cups-ppdc  2.3.3op2-3+deb11u1
ii  cups-server-common 2.3.3op2-3+deb11u1
ii  debconf [debconf-2.0]  1.5.77
ii  ghostscript9.53.3~dfsg-7
ii  libavahi-client3   0.8-5
ii  libavahi-common3   0.8-5
ii  libc6  2.31-13
ii  libcups2   2.3.3op2-3+deb11u1
ii  libgcc-s1  10.2.1-6
ii  libstdc++6 10.2.1-6
ii  libusb-1.0-0   2:1.0.24-3
ii  poppler-utils  20.09.0-3.1
ii  procps 2:3.3.17-5

Versions of packages cups recommends:
ii  avahi-daemon  0.8-5
ii  colord1.4.5-3

Versions of packages cups suggests:
pn  cups-bsd   
pn  cups-pdf   
pn  foomatic-db-compressed-ppds | foomatic-db  
pn  smbclient  
ii  udev   247.3-6

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: lpd, socket, usb, snmp, dnssd



Bug#989958: libopencv-*-dev: Missing pkg-config file (.pc)

2021-07-26 Thread Alejandro Colomar (man-pages)
Hi Nicolas,

I'm adding you to this thread, as you commented on opencv's thread about
pkg-config files.

I'd like to know if you forked opencv's .pc file and are maintaining it,
or if you just renamed it to opencv.pc, or what you decided to do at all.

I've had a lot of problems with their .pc file.  The last one being that
it uses -I instead of -isystem so I have a lot of warnings from their code.

I'd like to patch opencv with a correct pc file, but they want it
autogenerated and I don't know cmake...  So I'm considering all options
available.

Thanks,

Alex

On 7/25/21 11:31 PM, Jochen Sprickerhof wrote:
> * Alejandro Colomar (man-pages)  [2021-07-25
> 21:38]:
>>> I think that would be to big of a patch.
>>
>> Yes.  What is Fedora doing?  Do you know?
> 
> They provide a opencv.pc:
> 
> https://fedora.pkgs.org/rawhide/fedora-x86_64/opencv-devel-4.5.3-1.fc35.x86_64.rpm.html
> 
> 
> The opencv4.pc is a symbolic link:
> 
> https://src.fedoraproject.org/rpms/opencv/blob/rawhide/f/opencv.spec#_350
> 
> Cheers Jochen

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/



Bug#991269: guymager: "AvoidEncaseProblems" is set to off in config file

2021-07-26 Thread Michael Prokop
* Zack Lau [Mon Jul 26, 2021 at 09:49:16AM +]:

> Thanks for looking into this.

> I understand this option is well explained in the configuration file.
> However, in most situations, forensic practitioners run the forensic
> imaging process using Guymager in forensics mode booted up from Live
> CD. In order words, the configuration file needs to be updated after
> every boot up. It would be great if this can be enabled by default.

I talked to the upstream author in the meanwhile, and upstream
agreed to my suggestion, to use output of `uname -r` for the kernel
version information, and keep the strings below the limit that's
known to be needed for EnCase. So there shouldn't be any need for
changing this option, once a new upstream version with the new
behavior is there.

> Enabling this option in the configuration file does not prevent a
> Guymager created forensic image to load properly in other forensic
> software (i.e. FTK, Autopsy or X-Ways). Instead, it resolves the
> error issue when people try to load a Guymager created E01 in EnCase.

ACK, but I don't like diverging from upstream defaults, as there's
usually a good reason behind it. :)

> I find this topic interesting. I saw comments in different forums
> think the EnCase error issue was caused by other settings, or what
> people put in the case data fields. There were only a few people
> mentioned this option, so I think this "AvoidEncaseProblems" option
> is not widely aware of among the forensics community.

Thanks for your input!

regards
-mika-


signature.asc
Description: Digital signature


Bug#991269: guymager: "AvoidEncaseProblems" is set to off in config file

2021-07-26 Thread Zack Lau
Hi Mika,

Thanks for looking into this.

I understand this option is well explained in the configuration file.
However, in most situations, forensic practitioners run the forensic
imaging process using Guymager in forensics mode booted up from Live CD.
In order words, the configuration file needs to be updated after every
boot up. It would be great if this can be enabled by default.

Enabling this option in the configuration file does not prevent a
Guymager created forensic image to load properly in other forensic
software (i.e. FTK, Autopsy or X-Ways). Instead, it resolves the error
issue when people try to load a Guymager created E01 in EnCase.

I find this topic interesting. I saw comments in different forums think
the EnCase error issue was caused by other settings, or what people put
in the case data fields. There were only a few people mentioned this
option, so I think this "AvoidEncaseProblems" option is not widely aware
of among the forensics community.

Regards,
Zack

On 23/7/21 10:49 pm, Michael Prokop wrote:
> Hi,
>
> * Zack Lau [Mon Jul 19, 2021 at 10:11:44AM +]:
>
>> Tags: patch
> I don't see any patch in the BTS nor a MR at
> https://salsa.debian.org/pkg-security-team/guymager/, so I'll
> remove this tag
>
>> * What led up to the situation?
>> I believe the root cause is the default config file "guymager.cfg" from the
>> offical repo does not have the option "AvoidEncaseProblems" enabled. The
>> majority of forensic images created using the latest Guymager with
>> "AvoidEncaseProblems" disabled causes error. Thus, cannot be be added to a 
>> case
>> in EnCase v8 or up.
>> * What exactly did you do (or not do) that was effective (or
>>   ineffective)?
>> As I use Guymager from live CD, I have to change the "AvoidEncaseProblems"
>> option in line 426 of "/etc/guymager/guymager.cfg" from "off" to "on" 
>> everytime
>> I launch Guymager.
>> * What was the outcome of this action?
>> After setting the "AvoidEncaseProblems" option to "on", forensic images 
>> created
>> by Guymager can be loaded in EnCase v8 or up with no issue.
>> * What outcome did you expect instead?
>> I expect the "AvoidEncaseProblems" option can be set to "on" by default.
>> Suprisingly, this option is not known by a lot of people.
> Well, the configuration option is clearly documented in the
> configuration file and also explains the situation:
>
> | REM AvoidEncaseProblems  Encase produces strange error messages if the 
> EWF internal fields "Imager Version" and
> | REM  "OS Version" contain more than 11 or 23 
> characters, respectively. Leave this flag OFF
> | REM  if you don't work with Encase (default 
> setting). Set it to ON if ever you work with
> | REM  Encase and want to avoid the Encase problems.
>
> So I don't see how this could be enabled by default, given that not
> everybody uses Encase by default. But I'll ask upstream, whether
> they are aware of any possible better solutions.
>
> regards
> -mika-




smime.p7s
Description: S/MIME cryptographic signature


Bug#991455: gitolite3: underscore in username causes corruption and incorrect behaviour

2021-07-26 Thread Luke Kenneth Casson Leighton
well, i just checked after upgrading to 3.6.11-2 and the repository
in question has now *entirely disappeared* from the config!

i've had to downgrade to 3.6.6-1 to get things functional
(it's a live-running server)

this does actually work, so during scheduled downtime
moments i can switch to the broken version (3.6.11-2)
and find out what the heck is going on.

l.



Bug#991516: buster-pu: package nvidia-graphics-drivers/418.211.00-1

2021-07-26 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

this is a new upstream release fixing some CVEs.
Further packaging changes (as in all driver variants in sid):
* adding Recommends on the libnvidia*-encode1 library. Several
  multimedia applications are built with nvidia encode support and can
  dlopen the library at runtime (if available) to use hardware
  acceleration for video encoding
* computing the Vcs-Git branch while generating debian/control,
  something I usually forgot to update when forking off a new driver
  source package
This package is functionally equivalent (i.e. using the same upstream
.run blobs) to src:nvidia-graphics-drivers-tesla-418 in sid.
The package is already uploaded.

Andreas
diff --git a/debian/changelog b/debian/changelog
index 44f096f5..1a56ab2c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+nvidia-graphics-drivers (418.211.00-1) buster; urgency=medium
+
+  * New upstream Tesla release 418.211.00 (2021-07-20).
+* Fixed CVE-2021-1093, CVE-2021-1094, CVE-2021-1095.  (Closes: #991351)
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5211
+
+  [ Andreas Beckmann ]
+  * Refresh patches.
+  * nvidia-driver-libs: Add Recommends: libnvidia-encode1
+(470.42.01-1).  (Closes: #989885)
+  * debian/gen-control.pl: Support substitutions in the Vcs-Git field
+(470.57.02-1).
+  * Compute and substitute the Git branch instead of hardcoding it
+(470.57.02-1).
+  * Upload to buster.
+
+ -- Andreas Beckmann   Wed, 21 Jul 2021 22:06:09 +0200
+
 nvidia-graphics-drivers (418.197.02-1) buster; urgency=medium
 
   * New upstream Tesla release 418.197.02 (2021-04-19).
@@ -620,6 +638,19 @@ nvidia-graphics-drivers (396.18-1) experimental; 
urgency=medium
 
  -- Andreas Beckmann   Sun, 22 Apr 2018 13:59:45 +0200
 
+nvidia-graphics-drivers (390.144-1) UNRELEASED; urgency=medium
+
+  * New upstream legacy branch release 390.144 (2021-07-20).
+* Fixed CVE-2021-1093, CVE-2021-1094, CVE-2021-1095.
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5211
+- Worked around a bug in Meson builds of libglvnd 1.3.0 that caused the
+  nvidia_icd.json file to be installed in the wrong location.
+
+  [ Andreas Beckmann ]
+  * Refresh patches.
+
+ -- Andreas Beckmann   Wed, 21 Jul 2021 18:15:32 +0200
+
 nvidia-graphics-drivers (390.143-1) UNRELEASED; urgency=medium
 
   * New upstream legacy branch release 390.143 (2021-04-19).
@@ -631,7 +662,7 @@ nvidia-graphics-drivers (390.143-1) UNRELEASED; 
urgency=medium
   candidates, where the NVIDIA kernel module failed to build with error
   "fatal error: asm/kmap_types.h: No such file or directory".
 
- -- Andreas Beckmann   Mon, 19 Apr 2021 22:38:56 +0200
+ -- Andreas Beckmann   Tue, 20 Apr 2021 02:04:19 +0200
 
 nvidia-graphics-drivers (390.141-1) UNRELEASED; urgency=medium
 
diff --git a/debian/control b/debian/control
index c059de22..8e3c4372 100644
--- a/debian/control
+++ b/debian/control
@@ -312,6 +312,7 @@ Recommends:
  libgles-${nvidia-}1 (= ${binary:Version}),
  libgles-${nvidia-}2 (= ${binary:Version}),
  lib${nvidia}-cfg1 (= ${binary:Version}) [${nvidia:arch:has-driver}],
+ lib${nvidia}-encode1 (= ${binary:Version}),
  ${nvidia}-vulkan-icd (= ${binary:Version}) [amd64 i386],
 Provides:
  nvidia-driver-libs-any,
@@ -1005,12 +1006,12 @@ Pre-Depends:
  ${misc:Pre-Depends}
 Depends:
  ${shlibs:Depends}, ${misc:Depends}
-Description: NVIDIA PTX JIT Compiler${nvidia:VariantDesc}
+Description: NVIDIA PTX JIT Compiler library${nvidia:VariantDesc}
  The Compute Unified Device Architecture (CUDA) enables NVIDIA
  graphics processing units (GPUs) to be used for massively parallel
  general purpose computation.
  .
- This package contains the runtime PTX JIT compiler library.
+ This package contains the runtime PTX JIT Compiler library.
 
 Package: libnvcuvid1
 Architecture: i386 amd64
diff --git a/debian/control.in b/debian/control.in
index 423ba6a1..73672dd8 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -6,7 +6,7 @@ Uploaders:
  Andreas Beckmann ,
  Luca Boccassi ,
 Vcs-Browser: https://salsa.debian.org/nvidia-team/nvidia-graphics-drivers
-Vcs-Git: https://salsa.debian.org/nvidia-team/nvidia-graphics-drivers.git
+Vcs-Git: 
https://salsa.debian.org/nvidia-team/nvidia-graphics-drivers.git${Vcs-Git:Branch}
 Build-Depends:
  debhelper-compat (= 12),
  dpkg-dev (>= 1.18.8),
@@ -311,6 +311,7 @@ Recommends:
  libgles-${nvidia-}1 (= ${binary:Version}),
  libgles-${nvidia-}2 (= ${binary:Version}),
  lib${nvidia}-cfg1 (= ${binary:Version}) [${nvidia:arch:has-driver}],
+ lib${nvidia}-encode1 (= ${binary:Version}),
  ${nvidia}-vulkan-icd (= ${binary:Version}) [amd64 i386],
 Provides:
  nvidia-driver-libs-any,
@@ -1173,12 +1174,12 @@ Pre-Depends:
  ${misc:Pre-Depends}
 Depends:
  ${shlibs:Depends}, ${misc:Depends}
-Description: NVIDIA PTX JIT Compiler${nvidia:VariantDesc}
+Description: NVIDIA PTX JIT Compiler 

Bug#991515: ITP: wgrib2 -- Utility to read and write grib2 files

2021-07-26 Thread Magnus Hagdorn
Package: wnpp
Severity: wishlist
Owner: Magnus Hagdorn 

* Package name: wgrib2
  Version : 3.0.2
  Upstream Author : Wesley Ebisuzaki 
* URL : http://www.cpc.ncep.noaa.gov/products/wesley/wgrib2/
* License : GPL
  Programming Lang: C, Fortran, python
  Description : Utility to read and write grib2 files

Wgrib2 is a swiss army knife for grib2 files. You can use it inventory or
extract data. You can do basic database operations and other nifty things.
 

wgrib2 will be used in the School of GeoSciences, Uni of Edinburgh. I
am happy to maintain this package as part of my job. I do hope to get
some help from the Science team. I will need a sponsor.



Bug#991514: buster-pu: package nvidia-graphics-drivers-legacy-390xx/390.144-1~deb10u1

2021-07-26 Thread Andreas Beckmann
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

this is a new upstream release fixing some CVEs.
Further packaging changes (as in all driver variants in sid):
* adding Recommends on the libnvidia*-encode1 library. Several
  multimedia applications are built with nvidia encode support and can
  dlopen the library at runtime (if available) to use hardware
  acceleration for video encoding
* computing the Vcs-Git branch while generating debian/control,
  something I usually forgot to update when forking off a new driver
  source package
This is a rebuild of the package in sid with no further changes.
The package is already uploaded.

Andreas
diff --git a/debian/changelog b/debian/changelog
index 4f625b6c..dd03e4e3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,28 @@
+nvidia-graphics-drivers-legacy-390xx (390.144-1~deb10u1) buster; urgency=medium
+
+  * Rebuild for buster.
+
+ -- Andreas Beckmann   Mon, 26 Jul 2021 10:50:49 +0200
+
+nvidia-graphics-drivers-legacy-390xx (390.144-1) unstable; urgency=medium
+
+  * New upstream legacy branch release 390.144 (2021-07-20).
+* Fixed CVE-2021-1093, CVE-2021-1094, CVE-2021-1095.  (Closes: #991353)
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5211
+- Worked around a bug in Meson builds of libglvnd 1.3.0 that caused the
+  nvidia_icd.json file to be installed in the wrong location.
+
+  [ Andreas Beckmann ]
+  * Refresh patches.
+  * nvidia-legacy-390xx-driver-libs: Add Recommends:
+libnvidia-legacy-390xx-encode1 (460.91.03-1).  (Closes: #989885)
+  * debian/gen-control.pl: Support substitutions in the Vcs-Git field
+(460.91.03-1).
+  * Compute and substitute the Git branch instead of hardcoding it
+(460.91.03-1).
+
+ -- Andreas Beckmann   Wed, 21 Jul 2021 18:15:32 +0200
+
 nvidia-graphics-drivers-legacy-390xx (390.143-1~deb10u1) buster; urgency=medium
 
   * Rebuild for buster.
diff --git a/debian/control b/debian/control
index 0a5e7ed2..d5d11358 100644
--- a/debian/control
+++ b/debian/control
@@ -280,6 +280,7 @@ Recommends:
  libgles-${nvidia-}1 (= ${binary:Version}),
  libgles-${nvidia-}2 (= ${binary:Version}),
  lib${nvidia}-cfg1 (= ${binary:Version}),
+ lib${nvidia}-encode1 (= ${binary:Version}),
  ${nvidia}-vulkan-icd (= ${binary:Version}) [amd64 i386],
 Provides:
  nvidia-driver-libs-any,
@@ -816,12 +817,12 @@ Pre-Depends:
  ${misc:Pre-Depends}
 Depends:
  ${shlibs:Depends}, ${misc:Depends}
-Description: NVIDIA PTX JIT Compiler${nvidia:VariantDesc}
+Description: NVIDIA PTX JIT Compiler library${nvidia:VariantDesc}
  The Compute Unified Device Architecture (CUDA) enables NVIDIA
  graphics processing units (GPUs) to be used for massively parallel
  general purpose computation.
  .
- This package contains the runtime PTX JIT compiler library.
+ This package contains the runtime PTX JIT Compiler library.
 
 Package: libnvidia-legacy-390xx-nvcuvid1
 Architecture: i386 amd64 armhf
diff --git a/debian/control.in b/debian/control.in
index e5808800..4578ee3c 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -6,7 +6,7 @@ Uploaders:
  Andreas Beckmann ,
  Luca Boccassi ,
 Vcs-Browser: https://salsa.debian.org/nvidia-team/nvidia-graphics-drivers
-Vcs-Git: https://salsa.debian.org/nvidia-team/nvidia-graphics-drivers.git -b 
390xx/master
+Vcs-Git: 
https://salsa.debian.org/nvidia-team/nvidia-graphics-drivers.git${Vcs-Git:Branch}
 Build-Depends:
  debhelper-compat (= 12),
  dpkg-dev (>= 1.18.8),
@@ -279,6 +279,7 @@ Recommends:
  libgles-${nvidia-}1 (= ${binary:Version}),
  libgles-${nvidia-}2 (= ${binary:Version}),
  lib${nvidia}-cfg1 (= ${binary:Version}),
+ lib${nvidia}-encode1 (= ${binary:Version}),
  ${nvidia}-vulkan-icd (= ${binary:Version}) [amd64 i386],
 Provides:
  nvidia-driver-libs-any,
@@ -984,12 +985,12 @@ Pre-Depends:
  ${misc:Pre-Depends}
 Depends:
  ${shlibs:Depends}, ${misc:Depends}
-Description: NVIDIA PTX JIT Compiler${nvidia:VariantDesc}
+Description: NVIDIA PTX JIT Compiler library${nvidia:VariantDesc}
  The Compute Unified Device Architecture (CUDA) enables NVIDIA
  graphics processing units (GPUs) to be used for massively parallel
  general purpose computation.
  .
- This package contains the runtime PTX JIT compiler library.
+ This package contains the runtime PTX JIT Compiler library.
 
 Package: lib${nvidia-if-variant}nvcuvid1
 Architecture: i386 amd64 armhf
diff --git a/debian/control.md5sum b/debian/control.md5sum
index 577ad1e6..2d97cbc9 100644
--- a/debian/control.md5sum
+++ b/debian/control.md5sum
@@ -1,5 +1,5 @@
-a1db8e174e35b30f771fffdf4690ea8b  debian/control
-0a204645020c143be44b04bd5daf7b85  debian/control.in
-db12f898b07cdaf431ad34bd68a1662e  debian/gen-control.pl
-e0a6daa55d2509f44d21bbb591ccbad1  debian/rules
+ccb4a54a66486aa141901ef3093865aa  debian/control
+fae2dc9728a38fc5ded69c9bc53a5d07  debian/control.in
+8489c83cfe0171c9de6d052c01a6d19b  debian/gen-control.pl
+8dc9440f4cfc0543f6aa774bf181e3c0  

Bug#861553: Please enable numa support

2021-07-26 Thread Laurent Bigonville

reopen 861553
thanks

Le 26/07/21 à 01:10, Otto Kekäläinen a écrit :

Version: 1:10.5.5-1

The Numa support for MariaDB 10.5 was added in
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/2039c2755d0c642718dcc8be852174205577542b

I don't know how to test Numa support/use, so I'll assume it just
works unless somebody reports otherwise.

Thus closing issue.


Looking in the build logs, I see the following message:

-- WITH_NUMA=OFF: NUMA memory allocation policy disabled

The resulting binary packages are also not depending against libnuma.

I would add a WITH_NUMA=auto configure options in debian/rules

Kind regards,

Laurent Bigonville



Bug#991513: postfix: /etc/postfix/main.cf.proto is not updated on upgrade

2021-07-26 Thread Vincent Lefevre
Package: postfix
Version: 3.4.14-0+deb10u1
Severity: minor

In bug 838528, it was chosen to install /etc/postfix/main.cf.proto,
but this file is not updated from /usr/share/postfix/main.cf.dist
on upgrade (assuming that the user hasn't modified it).

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

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

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.12+dfsg-9
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  e2fsprogs  1.44.5-1+deb10u3
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libicu63   63.1-6+deb10u1
ii  libsasl2-2 2.1.27+dfsg-1+deb10u1
ii  libssl1.1  1.1.1d-0+deb10u6
ii  lsb-base   10.2019051400
ii  netbase5.6
ii  ssl-cert   1.0.39

Versions of packages postfix recommends:
ii  python3  3.7.3-1

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]  8.1.2-0.20180807cvs-1
ii  emacs-nox [mail-reader]  1:26.1+1-3.2+deb10u2
ii  libsasl2-modules 2.1.27+dfsg-1+deb10u1
ii  mailutils [mail-reader]  1:3.5-4
ii  mutt [mail-reader]   1.10.1-2.1+deb10u5
pn  postfix-cdb  
ii  postfix-doc  3.4.14-0+deb10u1
pn  postfix-ldap 
pn  postfix-lmdb 
pn  postfix-mysql
ii  postfix-pcre 3.4.14-0+deb10u1
pn  postfix-pgsql
ii  postfix-sqlite   3.4.14-0+deb10u1
ii  procmail 3.22-26
pn  resolvconf   
ii  sasl2-bin2.1.27+dfsg-1+deb10u1
pn  ufw  

-- debconf information:
* postfix/chattr: true
  postfix/relayhost:
  postfix/tlsmgr_upgrade_warning:
* postfix/mailbox_limit: 1073741824
  postfix/dynamicmaps_conversion_warning:
  postfix/sqlite_warning:
* postfix/protocols: all
* postfix/destinations: joooj.vinc17.net, vinc17.net, joooj, 
localhost.localdomain, localhost
* postfix/procmail: true
  postfix/relay_restrictions_warning:
  postfix/rfc1035_violation: false
* postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
  postfix/retry_upgrade_warning:
* postfix/recipient_delim: -
  postfix/lmtp_retired_warning: true
* postfix/mailname: vinc17.net
  postfix/bad_recipient_delimiter:
  postfix/main_cf_conversion_warning: true
* postfix/main_mailer_type: Internet Site
  postfix/compat_conversion_warning: true
  postfix/not_configured:
* postfix/root_address:
  postfix/newaliases: false
  postfix/kernel_version_warning:
  postfix/mydomain_warning:

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



Bug#991480: unblock: calamares-settings-debian/11.0.5

2021-07-26 Thread Jonathan Carter
Hi Paul

On 2021/07/26 09:52, Paul Wise wrote:
> FTR: the original bug report (#969930 AFAICT) correctly suggested
> bullseye-security, so the wrong sources.list entry wasn't caused by
> the original bug.

Ah yes, quite right, I misunderstood the conversation on IRC yesterday,
didn't mean to impart blame in your direction!

> I would suggest this instead:
> 
>> +  * New upstream release
>> +Corrects the apt sources for security updates (Closes: #991474)

Since this is already in unstable, I made another upload to add that
information to the changelog entry, here's the updated debdiff from
11.0.4-1 to 11.0.5-2:

"""
diff -Nru calamares-settings-debian-11.0.4/debian/changelog
calamares-settings-debian-11.0.5/debian/changelog
--- calamares-settings-debian-11.0.4/debian/changelog   2020-11-11
14:54:50.0 +0200
+++ calamares-settings-debian-11.0.5/debian/changelog   2021-07-26
10:27:12.0 +0200
@@ -1,3 +1,16 @@
+calamares-settings-debian (11.0.5-2) unstable; urgency=medium
+
+  * Add supplimental information to previous changelog entry
+
+ -- Jonathan Carter   Mon, 26 Jul 2021 10:27:12 +0200
+
+calamares-settings-debian (11.0.5-1) unstable; urgency=medium
+
+  * New upstream release
+- Corrects the apt sources for security updates (Closes: #991474)
+
+ -- Jonathan Carter   Sun, 25 Jul 2021 14:10:24 +0200
+
 calamares-settings-debian (11.0.4-1) unstable; urgency=medium

   * New upstream release
diff -Nru calamares-settings-debian-11.0.4/scripts/sources-final
calamares-settings-debian-11.0.5/scripts/sources-final
--- calamares-settings-debian-11.0.4/scripts/sources-final  2020-11-11
14:52:51.0 +0200
+++ calamares-settings-debian-11.0.5/scripts/sources-final  2021-07-25
14:07:03.0 +0200
@@ -14,8 +14,8 @@
 deb http://deb.debian.org/debian $RELEASE-updates main
 deb-src http://deb.debian.org/debian $RELEASE-updates main

-deb http://security.debian.org/debian-security/ $RELEASE-updates main
-deb-src http://security.debian.org/debian-security/ $RELEASE-updates main
+deb http://security.debian.org/debian-security/ $RELEASE-security main
+deb-src http://security.debian.org/debian-security/ $RELEASE-security main
 EOF

 exit 0
"""

thanks!

-Jonathan



Bug#991512: unblock: flatpak/1.10.2-3 (pre-approval)

2021-07-26 Thread Simon McVittie
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

[ Reason ]
Apply the same bug fixes that are likely to be in upstream stable release
1.10.3.

[ Impact ]
Maintenance: If we have these changes, it'll be more straightforward to
review a potential future stable update to the final 1.10.3 release.

d/p/system-helper-Fix-deploys-of-local-remotes.patch:
If missing, flatpak and GNOME Software might fail to upgrade some Flatpak
apps. It isn't 100% clear whether this can affect pure bullseye systems, or
only systems with an upgraded (experimental or bookworm) version of GLib.

d/p/create-usb-Skip-copying-extra-data-flatpaks.patch:
If missing, `flatpak create-usb` will create USB media on which not
everything can be installed while offline, which slightly defeats the
purpose of copying Flatpak apps to USB media.

[ Tests ]
Smoke-tested manually, and tested in autopkgtest on qemu. Most of the
autopkgtest coverage is skipped on ci.debian.net because bubblewrap and
lxc are incompatible, but it runs in qemu.

d/p/system-helper-Fix-deploys-of-local-remotes.patch is also in Ubuntu
(to fix the tests with an upgraded GLib), and Fedora developers reported
that applying this patch solves a similar upgrade failure in GNOME Software.

Both patches are backported from the development release 1.11.1, which is
getitng more real-world testing than most development releases because it's
required for some Steam use-cases (I intend to make that version available
in bullseye-backports as soon as that suite is open).

[ Risks ]
It's a key package, but I think these changes have low regression risk.

d/p/system-helper-Fix-deploys-of-local-remotes.patch is quite
straightforward. c8b9069a-ignore-space-change.diff is an easier-to-review
version, from `git show --ignore-space-change c8b9069a`.

d/p/create-usb-Skip-copying-extra-data-flatpaks.patch changes the
implementation of a rarely-used command, so even if it breaks completely,
few Debian users will notice. The change came from endlessOS, which is
one of the few environments where `flatpak create-usb` is actively used.

[ 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 ]
We should have a 1.10.3 release soon, but the primary upstream maintainer
is currently on vacation, so it might miss the deadline for bullseye.
I would like to track the 1.10.x branch in bullseye stable/security updates.

unblock flatpak/1.10.2-3
diffstat for flatpak-1.10.2 flatpak-1.10.2

 changelog  |   26 +
 patches/create-usb-Skip-copying-extra-data-flatpaks.patch  |  112 
 patches/portal-Don-t-leak-fd-used-for-serialized-environment.patch |1 
 patches/portal-Remap-env-fd-into-child-process-s-fd-space.patch|1 
 patches/portal-Use-a-GArray-to-store-fds.patch |1 
 patches/series |4 
 patches/system-helper-Fix-deploys-of-local-remotes.patch   |  132 ++
 patches/tests-Remove-hard-coded-references-to-x86_64.patch |1 
 8 files changed, 277 insertions(+), 1 deletion(-)

diff -Nru flatpak-1.10.2/debian/changelog flatpak-1.10.2/debian/changelog
--- flatpak-1.10.2/debian/changelog	2021-06-22 10:10:38.0 +0100
+++ flatpak-1.10.2/debian/changelog	2021-07-25 20:44:58.0 +0100
@@ -1,3 +1,29 @@
+flatpak (1.10.2-3) unstable; urgency=medium
+
+  * d/patches: Align with upstream flatpak-1.10.x branch, making this
+effectively a release candidate for upstream stable release 1.10.3
+- d/patches: Update metadata to reflect upstream flatpak-1.10.x branch.
+  All the patches we apply in Debian are expected to be released in
+  1.10.3 upstream, but not all were annotated to reflect this.
+- d/p/system-helper-Fix-deploys-of-local-remotes.patch:
+  Fix some failures to update in GNOME Software and the unit tests.
+  This change was previously applied in Ubuntu's flatpak_1.10.2-1ubuntu1
+  to fix a unit test failure, possibly triggered by a newer version of
+  GLib. It has also been reported to fix a failure to upgrade Flatpak
+  apps using GNOME Software, this time in Fedora.
+- d/p/create-usb-Skip-copying-extra-data-flatpaks.patch:
+  Skip flatpaks with "extra-data" when using `flatpak create-usb`.
+  This command is intended to create USB drives that can be
+  used to install Flatpak apps and/or runtimes while offline,
+  but the "extra-data" feature downloads extra content for an app
+  or runtime at install time, as a way to automate installation of
+  data that can be re-downloaded by end users but is not licensed
+  for redistribution by Flatpak repositories. Such apps and runtimes
+  would fail to install while offline.
+- d/p/series: Re-order patches to match 

Bug#991511: fontmanager.app: Font size change has no effect

2021-07-26 Thread Matthias Urlichs
Package: fontmanager.app
Version: 0.1-3
Severity: important
X-Debbugs-Cc: sm...@smurf.noris.de

Changing the font size doesn't do anything.

As the default size is rather small, this makes many fonts literally
indistinguishable.


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'stable'), (500, 'unstable'), (450, 
'focal'), (350, 'oldstable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
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 fontmanager.app depends on:
ii  gnustep-back0.28  0.28.0-3
ii  gnustep-base-runtime  1.27.0-3
ii  gnustep-gui-runtime   0.28.0-3
ii  libc6 2.31-13
ii  libgnustep-base1.27   1.27.0-3
ii  libgnustep-gui0.280.28.0-3
ii  libobjc4  10.2.1-6

fontmanager.app recommends no packages.

fontmanager.app suggests no packages.

-- debconf-show failed



Bug#991341: guake: apt progress bar distorted on Guake after hide/unhide

2021-07-26 Thread Awtul
Package: guake
Version: 3.6.3-2
Followup-For: Bug #991341

'needrestart' advise (text mode) also gets distorted.



Bug#991480: unblock: calamares-settings-debian/11.0.5

2021-07-26 Thread Paul Wise
On Sun, Jul 25, 2021 at 12:24 PM Jonathan Carter wrote:

> It has been found today that when the sources.list were updated for the
> updated sources.list URI in bullseye, that the original bug for this contained
> an incorrect suggestion for the sources.list entry that is now present in the
> sources.list generated by calamares-settings-debian. This patch corrects that.

FTR: the original bug report (#969930 AFAICT) correctly suggested
bullseye-security, so the wrong sources.list entry wasn't caused by
the original bug.

> +  * New upstream release
> +(Closes: #991474)

I would suggest this instead:

> +  * New upstream release
> +Corrects the apt sources for security updates (Closes: #991474)

--
bye,
pabs

https://wiki.debian.org/PaulWise



Bug#991510: RM: tomcat8/experimental -- RoQA; obsoleted by tomcat9

2021-07-26 Thread Paul Wise
Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: tomc...@packages.debian.org

Please remove tomcat8 from experimental, it has been obsoleted by
tomcat9 and the maintainer has acked its removal from experimental:

https://lists.debian.org/msgid-search/ccef864c-141f-05dc-7f03-36c993164...@apache.org

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#991504: fcitx: Double Paste in Chrome when using logitech mouse (closing fcitx fixes it)

2021-07-26 Thread Jaali Naam
Package: fcitx
Version: 1:4.2.9.8-3
Severity: normal
X-Debbugs-Cc: jaali.n...@protonmail.com

Dear Maintainer,

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

   * What led up to the situation?
Logitech G602 Mouse custom button configured for paste ( CTR+V)
paste everything twice in Google Chrome.
Evrywhere else in the system the functions works as intended.
 
Running the commands
fcitx-remote -e
fcitx5-remote -e
solves the problem till next restart.



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

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

Versions of packages fcitx depends on:
ii  fcitx-bin  1:4.2.9.8-3
ii  fcitx-data 1:4.2.9.8-3
ii  fcitx-modules  1:4.2.9.8-3

Versions of packages fcitx recommends:
ii  fcitx-config-gtk0.4.10-3
ii  fcitx-frontend-all  1:4.2.9.8-3
ii  fcitx-ui-classic1:4.2.9.8-3
ii  im-config   0.46-1
ii  kde-config-fcitx0.5.6-2

Versions of packages fcitx suggests:
ii  fcitx-m17n   0.2.4-2
pn  fcitx-tools  

-- no debconf information



Bug#991509: linux-image-amd64: marking TSC unstable due to check_tsc_sync_source failed (AMD Ryzen)

2021-07-26 Thread nelson g
Package: linux-image-amd64
Version: 5.10.46-2
Severity: normal
X-Debbugs-Cc: ledu...@hotmail.com

Hello,

My system is stuck with HPET clocksource

dmesg | egrep -i 'tsc|hpet|clocksource'
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 2096.096 MHz processor
[0.004968] ACPI: HPET 0xB90A3000 38 (v01 LENOVO TP-R11
1210 PTEC 0002)
[0.005018] ACPI: Reserving HPET table memory at [mem 0xb90a3000-0xb90a3037]
[0.014115] ACPI: HPET id: 0x43538210 base: 0xfed0
[0.014183] clocksource: refined-jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 7645519600211568 ns
[0.059588] clocksource: hpet: mask: 0x max_cycles: 0x,
max_idle_ns: 133484873504 ns
[0.079620] clocksource: tsc-early: mask: 0x max_cycles:
0x1e36c89f085, max_idle_ns: 440795235573 ns
[0.199622] TSC synchronization [CPU#0 -> CPU#1]:
[0.199622] Measured 5479288407 cycles TSC warp between CPUs, turning off
TSC clock.
[0.199622] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[0.216551] clocksource: jiffies: mask: 0x max_cycles: 0x,
max_idle_ns: 764504178510 ns
[0.373390] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
[0.373393] hpet0: 3 comparators, 32-bit 14.318180 MHz counter
[0.375642] clocksource: Switched to clocksource hpet
[0.392540] clocksource: acpi_pm: mask: 0xff max_cycles: 0xff,
max_idle_ns: 2085701024 ns
[1.137978] rtc_cmos 00:01: alarms up to one month, y3k, 114 bytes nvram,
hpet irqs


Sorry to bother but I'd like to report to debian this known bug in
bugzilla.kernel = https://bugzilla.kernel.org/show_bug.cgi?id=202525 and Lenovo
= https://forums.lenovo.com/t5/Other-Linux-Discussions/Clocksource-falling-
back-to-HPET-bec-TSC-is-unstable-ThinkPad-E14-Gen-2-maybe-others/m-p/5036464




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

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-5.10.0-8-amd64  5.10.46-2

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.



Bug#535183: [kopete] Notification window too much annoying

2021-07-26 Thread Paul Wise
On Tue, 30 Jun 2009 16:52:12 +0200 Dario Fiumicello wrote:

> The notification window is too much annoying! If a contact sends me 4 or 5 
> messages I have 4 or 5 cascading notification which turns my desktop 
> unusable. 
> Due to this behaviour I had to disable the kopete notification window. I 
> think 
> that the behaviour of kopete 3.x was better because only one baloon appears 
> even if a contact sends many messages. I wish to have this behaviour in the 
> new kopete.

Please retry this issue with the latest kopete versions in Debian
buster and Debian experimental and report the results here and in the
upstream KDE bug report:

https://bugs.kde.org/show_bug.cgi?id=191024

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#991508: unblock: samtools-legacy/0.1.19+dfsg-2

2021-07-26 Thread Nilesh Patra
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: nil...@debian.org

Please unblock package samtools-legacy

[ Reason ]
This package misses a depends on zlib1g-dev rendering it unusable

[ Impact ]
The package will be broken for the user, and they will have to fetch the
dependencies by themselves

[ Tests ]
Autopkgtests have been added in this release

[ Risks ]
Low risk, no change in any installations -- just one dep added w/
autopkgtests
IMO, this is safe

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

unblock samtools-legacy/0.1.19+dfsg-2
diff -Nru samtools-legacy-0.1.19+dfsg/debian/changelog 
samtools-legacy-0.1.19+dfsg/debian/changelog
--- samtools-legacy-0.1.19+dfsg/debian/changelog2020-11-16 
23:20:39.0 +0530
+++ samtools-legacy-0.1.19+dfsg/debian/changelog2021-07-25 
20:41:17.0 +0530
@@ -1,3 +1,11 @@
+samtools-legacy (0.1.19+dfsg-2) unstable; urgency=medium
+
+  * Team Upload.
+  * Add Depends on zlib1g-dev
+  * Add autopkgtests
+
+ -- Nilesh Patra   Sun, 25 Jul 2021 20:41:17 +0530
+
 samtools-legacy (0.1.19+dfsg-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru samtools-legacy-0.1.19+dfsg/debian/control 
samtools-legacy-0.1.19+dfsg/debian/control
--- samtools-legacy-0.1.19+dfsg/debian/control  2020-11-16 23:20:39.0 
+0530
+++ samtools-legacy-0.1.19+dfsg/debian/control  2021-07-25 20:39:14.0 
+0530
@@ -16,7 +16,8 @@
 Architecture: any
 Section: libdevel
 Depends: ${shlibs:Depends},
- ${misc:Depends}
+ ${misc:Depends},
+ zlib1g-dev
 Description: manipulates nucleotide sequence alignments in BAM or SAM format
  The BAM library provides I/O and various operations on manipulating nucleotide
  sequence alignments in the BAM (Binary Alignment/Mapping) or SAM (Sequence
diff -Nru samtools-legacy-0.1.19+dfsg/debian/tests/control 
samtools-legacy-0.1.19+dfsg/debian/tests/control
--- samtools-legacy-0.1.19+dfsg/debian/tests/control1970-01-01 
05:30:00.0 +0530
+++ samtools-legacy-0.1.19+dfsg/debian/tests/control2021-07-24 
22:33:24.0 +0530
@@ -0,0 +1,3 @@
+Tests: run-unit-test
+Depends: @, build-essential, samtools
+Restrictions: allow-stderr
diff -Nru samtools-legacy-0.1.19+dfsg/debian/tests/run-unit-test 
samtools-legacy-0.1.19+dfsg/debian/tests/run-unit-test
--- samtools-legacy-0.1.19+dfsg/debian/tests/run-unit-test  1970-01-01 
05:30:00.0 +0530
+++ samtools-legacy-0.1.19+dfsg/debian/tests/run-unit-test  2021-07-24 
22:43:39.0 +0530
@@ -0,0 +1,34 @@
+#!/bin/bash
+set -e
+
+pkg=cppnumericalsolvers
+CUR_DIR=`pwd`
+
+export LC_ALL=C.UTF-8
+if [ "${AUTOPKGTEST_TMP}" = "" ] ; then
+  AUTOPKGTEST_TMP=$(mktemp -d /tmp/${pkg}-test.XX)
+  trap "rm -rf ${AUTOPKGTEST_TMP}" 0 INT QUIT ABRT PIPE TERM
+fi
+
+cd "${AUTOPKGTEST_TMP}"
+cp ${CUR_DIR}/examples/* .
+
+samtools view -S -b toy.sam > toy.bam
+
+echo "Test 1 -- calDepth"
+gcc calDepth.c -o calDepth -I/usr/include/samtools -lbam -lm -lz -lpthread
+./calDepth toy.bam
+echo "=== PASS "
+
+echo "Test 2 -- chk_indel"
+gcc chk_indel.c -o chk_indel -I/usr/include/samtools -lbam -lm -lz -lpthread
+./chk_indel toy.bam
+echo "=== PASS "
+
+
+echo "Test 3 -- bam2bed"
+gcc bam2bed.c -o bam2bed -I/usr/include/samtools -lbam -lm -lz -lpthread
+./bam2bed toy.bam
+echo "=== PASS "
+
+rm -f toy.bam


Bug#682872: kopete: Inproper Hungarian sentence for partner gone away

2021-07-26 Thread Paul Wise
On Mon, 26 Jul 2021 13:27:21 +0800 Paul Wise wrote:
> On Thu, 26 Jul 2012 16:15:15 +0200 Braun Gábor wrote:
> 
> > By a status change in chat window, the following message appears
> > in Hungarian
> ...
> > The sentence is not correct in Hungarian.
> 
> Please check this issue with the latest kopete versions in Debian
> buster and Debian experimental and report the results here.

The submitters mail bounces, so someone else will need to check this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#991451: redis breaks python-fakeredis autopkgtest: AssertionError

2021-07-26 Thread Jochen Sprickerhof

* Chris Lamb  [2021-07-25 16:37]:

Chris Lamb wrote:


Sure thing -- I've forwarded this upstream here:

  https://github.com/redis/redis/issues/9273


Okay, so the latest reply there suggests that this is (now) the
expected and behaviour of Redis going forward.

I still don't quite grasp what it is that fakeredis is testing though,
so I can't state with any authority whether it definitely is fakeredis
that needs to be addressed, but reverting this behavioural change in
Redis does not seem the right way to go at all (!).


I have no idea about Redis/Fakeredis, adding Ondřej as he did all the 
uploads, lately.


What I got from looking at the code was that Hypothesis is a library to 
do extensive testing, so testing with 0 or empty strings sounds like a 
common way. I haven't looked how much work it would be to adopt 
Fakeredis to the new Redis behavior, but in case we want to only silence 
the tests for bullseye this would be a minimal change:


--- test/test_hypothesis.py.org 2021-07-26 07:54:36.151227815 +0200
+++ test/test_hypothesis.py 2021-07-26 07:54:38.599225613 +0200
@@ -257,8 +257,8 @@
 set_commands = (
 commands(st.just('sadd'), keys, st.lists(fields,))
 | commands(st.just('scard'), keys)
-| commands(st.sampled_from(['sdiff', 'sinter', 'sunion']), st.lists(keys))
-| commands(st.sampled_from(['sdiffstore', 'sinterstore', 'sunionstore']),
+| commands(st.sampled_from(['sdiff', 'sunion']), st.lists(keys))
+| commands(st.sampled_from(['sdiffstore', 'sunionstore']),
keys, st.lists(keys))
 | commands(st.just('sismember'), keys, fields)
 | commands(st.just('smembers'), keys)


Cheers Jochen


signature.asc
Description: PGP signature


Bug#674533: kopete: LaTeX formulas are not displayed

2021-07-26 Thread Paul Wise
On Mon, 26 Jul 2021 13:25:33 +0800 Paul Wise wrote:
> On Fri, 25 May 2012 12:26:33 +0200 Braun Gábor wrote:
> 
> > Typing ^L to display any formula just displays the source,
> > but not the typeset formula, and kopete gives no information
> > what went wrong.
> 
> Please retry this issue with the latest kopete versions in Debian
> buster and Debian experimental and report the results here.

The submitters mail bounces, so someone else will need to check this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#493459: kopete: XMPP DNS SRV lookups

2021-07-26 Thread Paul Wise
On Mon, 26 Jul 2021 13:46:51 +0800 Paul Wise wrote:
> On Sat, 02 Aug 2008 22:08:35 +0300 Remi Denis-Courmont wrote:
> 
> > Kopete will only try A/ DNS lookups to connect to a Jabber/XMPP
> > server. If the domain uses SRV records, the only way to connect is to
> > lookup the server manually, e.g. with dig, and hard-code it in the
> > Kopete configuration. This is not very convenient. Pidgin has no such
> > problem.
> 
> Please retry this issue with the latest kopete versions in Debian

The submitters mail bounces, so someone else will need to check this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#538688: improve metacontact ergonomy like pidgin

2021-07-26 Thread Paul Wise
On Sun, 26 Jul 2009 09:52:59 + Bastien ROUCARIES wrote:

> Meta contact management is not really easy on kopete. Pidgin use an 
> extend right button command then drag and drop. Please implement.

Please retry this issue with the latest kopete versions in Debian
buster and Debian experimental and report the results here and in the
upstream KDE bug report:

https://bugs.kde.org/show_bug.cgi?id=201010

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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