Bug#981089: tracker-miner-fs: Tracker miners are started for (some?) system users

[Matijs van Zuijlen]

Package: tracker-miner-fs
Version: 2.3.5-2
Severity: normal

Dear maintainer,

I'm getting the following lines in my log:

  tracker-miner-f[1783345]: Unable to get XDG user directory path for special 
directory  Ignoring this location.
  tracker-miner-f[1783345]: Unable to get XDG user directory path for special 
directory  Ignoring this location.
  tracker-miner-f[1783345]: Unable to get XDG user directory path for special 
directory  Ignoring this location.
  tracker-miner-f[1783345]: Unable to get XDG user directory path for special 
directory  Ignoring this location.
  tracker-miner-f[1783345]: Unable to get XDG user directory path for special 
directory  Ignoring this location.

This seems to happen because the miner is started for some system user,
probably postgres. I don't think tracker miners should be started for
such users.

Kind regards,
Matijs

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

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

Versions of packages tracker-miner-fs depends on:
ii  init-system-helpers  1.60
ii  libc62.31-9
ii  libglib2.0-0 2.66.4-1
ii  libtracker-miner-2.0-0   2.3.6-2
ii  libtracker-sparql-2.0-0  2.3.6-2
ii  libupower-glib3  0.99.11-2
ii  procps   2:3.3.16-5
ii  tracker  2.3.6-2
ii  tracker-extract  2.3.5-2

tracker-miner-fs recommends no packages.

tracker-miner-fs suggests no packages.

-- no debconf information

Bug#950516: file: Does not detect python3.8 byte-compiled files

[Christoph Biedl]

[ re-visiting my backlog ]

Felix Lechner wrote...

> Given the passage of time, it is okay if Lintian detects Python3 files
> only in unstable. Unfortunately, the file(1) program in unstable does
> not detect files byte-compiled by the Python3 version in unstable,
> which is 3.8. (file 1:5.38-5 detects only 3.7.) Would you please
> provide a version that does? Thanks!

This has eventually happened in 1:5.39-3, uploaded in November.

Since this bug here was also about a backport: I have requested
according upload rights and await the response. Then this will
eventually happen as well.

Christoph


signature.asc
Description: PGP signature

Bug#851875: atop not installable if process accounting is stopped

[Marc Haber]

On Thu, Jan 19, 2017 at 02:33:04PM +0100, Jan Niehusmann wrote:
> The process accounting didn't run because I actively stopped it.
> (echo "99 99 30" >/proc/sys/kernel/acct means that process accounting
> stops whenever less then 99% of the target fs are free.)
> 
> So that's not surprising. But I think that atop still should be
> upgradable cleanly, in such a situation.

Hi,

can you verify that this issue still applies to the current version of
atop, 2.6.0? I would appreciate that.

Greetings
Marc

Bug#981088: pacemaker: crm shell can't be executed due to a library error

[Thorsten Rehm]

Package: pacemaker
Version: 1.1.24-0+deb9u1
Severity: normal

Dear Maintainer,

thank you for the effort and the update.
Unfortunately there are still some problems with the updated version.

I've just updated the pacemaker package from 1.1.16-1+deb9u2 to
1.1.24-0+deb9u1. Afterwards parts of the Cluster Resource Manager
(crm) can't be executed due to a library error. TL;DR:
libpe_status.so.10 != libpe_status.so.16 and libpengine.so.10 !=
libpengine.so.16

In Detail:
$ /usr/sbin/crm_mon --version
Pacemaker 1.1.16
Written by Andrew Beekhof

$ apt policy pacemaker
pacemaker:
  Installed: 1.1.16-1+deb9u2
  Candidate: 1.1.24-0+deb9u1
[...]

$ apt install pacemaker
[...]
The following packages will be upgraded:
  libcib4 libcrmcluster4 libcrmcommon3 libcrmservice3 liblrmd1
libpe-rules2 libpe-status10 libpengine10 libstonithd2
  libtransitioner2 pacemaker
[...]

$ apt policy pacemaker
pacemaker:
  Installed: 1.1.24-0+deb9u1
  Candidate: 1.1.24-0+deb9u1
[...]

$ crm_mon --version
crm_mon: error while loading shared libraries: libpe_status.so.10:
cannot open shared object file: No such file or directory

$ crm status
/usr/sbin/crm_mon: error while loading shared libraries:
libpe_status.so.10: cannot open shared object file: No such file or
directory
/usr/sbin/crm_mon: error while loading shared libraries:
libpe_status.so.10: cannot open shared object file: No such file or
directory
ERROR: status: crm_mon (rc=127):

$ ldd /usr/sbin/crm_mon | grep "not found"
libpe_status.so.10 => not found
libpengine.so.10 => not found

$ dpkg -L libpe-status10 | grep so
/usr/lib/x86_64-linux-gnu/libpe_status.so.16.1.0
/usr/lib/x86_64-linux-gnu/libpe_status.so.16

$ dpkg -L libpengine10 | grep so
/usr/lib/x86_64-linux-gnu/libpengine.so.16.1.0
/usr/lib/x86_64-linux-gnu/libpengine.so.16

Can you please investigate again?

I've already made a reply to bug #974563, but I've realized only
after it's resolved.


Thank you.

Best regards,
Thorsten Rehm



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

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

Versions of packages pacemaker depends on:
ii  corosync   2.4.2-3+deb9u1
ii  dbus   1.10.32-0+deb9u1
ii  init-system-helpers1.48
ii  libc6  2.24-11+deb9u4
ii  libcfg62.4.2-3+deb9u1
ii  libcib41.1.16-1+deb9u2
ii  libcmap4   2.4.2-3+deb9u1
ii  libcorosync-common42.4.2-3+deb9u1
ii  libcpg42.4.2-3+deb9u1
ii  libcrmcluster4 1.1.16-1+deb9u2
ii  libcrmcommon3  1.1.16-1+deb9u2
ii  libcrmservice3 1.1.16-1+deb9u2
ii  libglib2.0-0   2.50.3-2+deb9u2
ii  libgnutls303.5.8-5+deb9u5
ii  liblrmd1   1.1.16-1+deb9u2
ii  libpam0g   1.1.8-3.6
ii  libpe-rules2   1.1.16-1+deb9u2
ii  libpe-status10 1.1.16-1+deb9u2
ii  libpengine10   1.1.16-1+deb9u2
ii  libqb0 1.0.1-1
ii  libquorum5 2.4.2-3+deb9u1
ii  libstonithd2   1.1.16-1+deb9u2
ii  libtransitioner2   1.1.16-1+deb9u2
ii  lsb-base   9.20161125
ii  pacemaker-common   1.1.16-1+deb9u2
ii  pacemaker-resource-agents  1.1.16-1+deb9u2
ii  perl   5.24.1-3+deb9u7

Versions of packages pacemaker recommends:
pn  fence-agents 
ii  pacemaker-cli-utils  1.1.16-1+deb9u2

Versions of packages pacemaker suggests:
ii  cluster-glue  1.0.12-5
ii  crmsh 2.3.2-4

-- no debconf information

Bug#981087: getting rid of false positive firmware warnings?

[Marc Haber]

Package: initramfs-tools-core
Version: 0.139
Severity: wishlist

Hi,

when my initramfs is built, the radeon module complains about a
truckload of "Possible missing firmware". Since my system is running
finr without them, I guess those are false positives for my graphics
card, so the warnings should not be there (their sheer volume hides real
issues).

Would you be willing to accept a patch to
/usr/share/initramfs-tools/hook-functions reading a list of
possibly-missing-but-not-necessary firmware files and not emitting the
"Possible missing firmware" warning for firmware files that are listed
in the file?

If so, can you please help me with a language issue and suggest a better
name and a probable location for the file? Thank you very much.

Greetings
Marc


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

Kernel: Linux 5.10.9-zgws1 (SMP w/12 CPU threads)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages initramfs-tools-core depends on:
ii  coreutils8.32-4+b1
ii  cpio 2.13+dfsg-4
ii  e2fsprogs1.45.6-1
ii  klibc-utils  2.0.8-1
ii  kmod 28-1
ii  logsave  1.45.6-1
ii  udev 247.2-5

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.30.1-6+b1
ii  pigz 2.5-1

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.11-2

-- no debconf information

Bug#978636: move to merged-usr-only?

[Bastian Blank]

On Mon, Jan 25, 2021 at 09:22:29PM +, Simon McVittie wrote:
> Some developers seem to be using "merged /usr" to refer to multiple
> concrete layouts:
> 1. an arrangement where all regular files that have traditionally been
>in /bin, /sbin, /lib and /lib64 are physically located in /usr,
>with symlinks /bin -> usr/bin, /sbin -> usr/sbin, /lib -> usr/lib,
>/lib64 -> usr/lib64
>(this is what usrmerge, debootstrap --merged-usr and Fedora do; dpkg
>maintainer Guillem Jover refers to this as "merged /usr via aliased
>directories" which seems like a good unambiguous term)

Aren't there two sub-solutions?

1a. with packages shipping files both in /bin und /usr/bin.
1b. with packages shipping files only in /usr/bin.

Bastian

-- 
Klingon phaser attack from front!
100% Damage to life support

Bug#980727: RFS: grap/1.46-1 [QA] -- program for typesetting graphs

[Leandro Cunha]

Control: owner -1 !

On Thursday, January 21 2021, Leandro Cunha wrote:

> Changes since the last upload:
>
>  grap (1.46-1) unstable; urgency=medium
>  .
>* QA upload.
>* New upstream release.
>* Added debian/gbp.conf.
>
> I don't see a reason to add a gbp.conf given that the package is not
> maintained in git.  Moreover, the settings you're proposing seem
> personal choices more suitable for a local ~/.gbp.conf than for a
> project one.

Removed.

>* Added debian/upstream/metadata.
>* Added debian/docs.
>
> While at it, please add a newline at the end of d/docs.

Done.

>* debian/copyright:
>  - Added Upstream-Contact optional field according DEP-5.

> Thanks,
>
> --
> Sergio
> GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
> Please send encrypted e-mail if possible
> https://sergiodj.net/

Please send me a copy by e-mail. I didn't even see the message if I
hadn't accessed
this bug. Thanks!

[1] https://salsa.debian.org/leandrocunha/grap
[2] https://mentors.debian.net/package/grap

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.
-BEGIN PGP PUBLIC KEY BLOCK-

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

Bug#981086: Needs versioned build-depends on spdlog

[Martin Michlmayr]

Package: waybar
Version: 0.9.5-1

I tried to build waybar on stable but got this error:

> Dependency spdlog found: NO found 1.3.1 but need: '>=1.8.0'

You need versioned build-depends on spdlog.
-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#981085: gkrellm: Crashes after suspend

[Nicolas Patrois]

Package: gkrellm
Version: 2.3.11-1
Severity: normal

Dear Maintainer,

When I wake the machine up, gkrellm crashes.
I run XFCE.
Here is systemd’s coredump report:

systemd-coredump[22992]: [] Process 13829 (gkrellm) of user 1000 dumped core.

Stack trace of thread
13829:
#0  0xb7fb51cd
__kernel_vsyscall (linux-gate.so.1 + 0x11cd)
#1  0xb70ade02
__libc_signal_restore_set (libc.so.6 + 0x34e02)
#2  0xb7096306
__GI_abort (libc.so.6 + 0x1d306)
#3  0x004bd2da
n/a (gkrellm + 0x302da)
#4  0xb7fb51d8
__kernel_sigreturn (linux-gate.so.1 + 0x11d8)
#5  0xb78d79f9
g_type_check_instance_is_fundamentally_a (libgobject-2.0.so.0 + 0x309f9)
#6  0xb78c02d1
g_object_get_data (libgobject-2.0.so.0 + 0x192d1)
#7  0xb7c5b429
n/a (libgtk-x11-2.0.so.0 + 0x20d429)
#8  0xb7c9bf4d
n/a (libgtk-x11-2.0.so.0 + 0x24df4d)
#9  0xb7c9e42d
n/a (libgtk-x11-2.0.so.0 + 0x25042d)
#10 0xb7ca138e
n/a (libgtk-x11-2.0.so.0 + 0x25338e)
#11 0xb7ca8e33
gtk_widget_set_parent (libgtk-x11-2.0.so.0 + 0x25ae33)
#12 0xb7abd150
n/a (libgtk-x11-2.0.so.0 + 0x6f150)
#13 0x004ec27c
n/a (gkrellm + 0x5f27c)
#14 0x004ee9f5
n/a (gkrellm + 0x619f5)
#15 0x004beee9
n/a (gkrellm + 0x31ee9)
#16 0xb77a5331
n/a (libglib-2.0.so.0 + 0x4f331)
#17 0xb77a46e4
g_main_context_dispatch (libglib-2.0.so.0 + 0x4e6e4)
#18 0xb77a4aa9
n/a (libglib-2.0.so.0 + 0x4eaa9)
#19 0xb77a4e01
g_main_loop_run (libglib-2.0.so.0 + 0x4ee01)
#20 0xb7b72af5
gtk_main (libgtk-x11-2.0.so.0 + 0x124af5)
#21 0x004bc027
main (gkrellm + 0x2f027)
#22 0xb7097e46
__libc_start_main (libc.so.6 + 0x1ee46)
#23 0x004bc601
_start (gkrellm + 0x2f601)



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

Kernel: Linux 5.7.0-1-686-pae (SMP w/3 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=fr_FR:fr:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gkrellm depends on:
ii  libc62.31-9
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.4-1
ii  libgnutls-openssl27  3.7.0-5
ii  libgnutls30  3.7.0-5
ii  libgtk2.0-0  2.24.33-1
ii  libice6  2:1.0.10-1
ii  libntlm0 1.6-3
ii  libpango-1.0-0   1.46.2-3
ii  libsensors5  1:3.6.0-6
ii  libsm6   2:1.2.3-1
ii  libx11-6 2:1.7.0-2

gkrellm recommends no packages.

gkrellm suggests no packages.

-- no debconf information

Bug#981071: RFP: luksman -- A CLI frontend for cryptsetup for managing LUKS containers.

[Andrei POPESCU]

Control: reassign -1 wnpp

On Lu, 25 ian 21, 23:30:34, 2board.admin wrote:
> Package: luksman
> Version: 1.0.0
> Severity: wishlist
> System: Ubuntu 20.04
> Upstream Author: "emanresu" <2board.ad...@protonmail.com>
> Main Repo URL: https://codeberg.org/emanresu/Luksman
> 1.0.0 Release URL: 
> https://codeberg.org/emanresu/Luksman/releases/tag/1.0.0_deb
> License: GPL
> Description:
> A CLI frontend for cryptsetup for managing LUKS containers written in python3.
> 
> Sent with [ProtonMail](https://protonmail.com) Secure Email.

Reassigning to correct (pseudo-)package.

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


signature.asc
Description: PGP signature

Bug#981081: kdbusaddons: reduce Build-Depends

[Norbert Preining]

Hi Helmut,

On Tue, 26 Jan 2021, Helmut Grohne wrote:
> annotated .  Please consider applying the attached patch.

graphviz is already gone, added the nocheck, committed to git.

Thanks a lot

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#981084: dh-elpa should provide dh-sequence-elpa

[Helmut Grohne]

Package: dh-elpa
Version: 2.0.6
Tags: patch

Please provide dh-sequence-elpa. Doing so allows using it declaratively.
Instead of adding "--with elpa" to the dh invocation, one can then add
dh-sequence-elpa to Build-Depends. Using the dependency technique, use
of the addon can be restricted to indep-only builds by moving it to
Build-Depends-Indep. Also the sequence can be conditionalized using
build profiles. (Though using build profiles requires fixing #981014.)

--- a/debian/control
+++ b/debian/control
@@ -27,6 +27,7 @@
  libtext-glob-perl,
  ${misc:Depends},
  ${perl:Depends},
+Provides: dh-sequence-elpa
 Description: Debian helper tools for packaging emacs lisp extensions
  This package provides a helper for packaging emacs lisp extensions
  in a way compatible with the GNU Emacs 'elpa' package repository.

Helmut

Bug#981083: protobuf: support build profiles

[Helmut Grohne]

Source: protobuf
Version: 3.12.4-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: block -1 by 981014

protobuf participates in dependency loops relevant to architecture
bootstrap. I noticed that protobuf's Build-Depends are well organized.
Thank you! There is not much room for trimming them, but using build
profiles one can cut certain cycles. The most useful profile likely is
nocheck. Beyond that, I'm proposing profiles nopython and noruby. Please
consider applying the attached patch. Note that #981014 needs to before
you can ship the nopython and noruby profiles.

Helmut
diff --minimal -Nru protobuf-3.12.4/debian/changelog 
protobuf-3.12.4/debian/changelog
--- protobuf-3.12.4/debian/changelog2021-01-16 23:12:54.0 +0100
+++ protobuf-3.12.4/debian/changelog2021-01-25 14:24:12.0 +0100
@@ -1,3 +1,10 @@
+protobuf (3.12.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support build profiles nocheck, nopython and noruby. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 25 Jan 2021 14:24:12 +0100
+
 protobuf (3.12.4-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru protobuf-3.12.4/debian/control 
protobuf-3.12.4/debian/control
--- protobuf-3.12.4/debian/control  2021-01-16 23:12:54.0 +0100
+++ protobuf-3.12.4/debian/control  2021-01-25 14:24:12.0 +0100
@@ -8,21 +8,22 @@
  , dh-elpa
 # C/C++
  , zlib1g-dev
- , libgmock-dev
- , libgtest-dev
+ , libgmock-dev 
+ , libgtest-dev 
 # Python
- , dh-python
- , python3-all:any
- , libpython3-all-dev
- , python3-setuptools
- , python3-six
+ , dh-python 
+ , dh-sequence-python3 
+ , python3-all:any 
+ , libpython3-all-dev 
+ , python3-setuptools 
+ , python3-six 
 # Manpage generator
  , xmlto
 # Tests
- , unzip
+ , unzip 
 # Ruby
- , rake-compiler
- , gem2deb
+ , rake-compiler 
+ , gem2deb 
 Build-Depends-Indep:
 # Java
ant
@@ -41,6 +42,7 @@
 Package: ruby-google-protobuf
 Architecture: any
 Multi-Arch: same
+Build-Profiles: 
 Section: ruby
 X-DhRuby-Root: ruby
 XB-Ruby-Versions: ${ruby:Versions}
@@ -191,6 +193,7 @@
 
 Package: python3-protobuf
 Architecture: any
+Build-Profiles: 
 Section: python
 Depends: ${shlibs:Depends}, ${python3:Depends}, ${misc:Depends}
 Description: Python 3 bindings for protocol buffers
diff --minimal -Nru protobuf-3.12.4/debian/rules protobuf-3.12.4/debian/rules
--- protobuf-3.12.4/debian/rules2021-01-16 23:12:54.0 +0100
+++ protobuf-3.12.4/debian/rules2021-01-25 14:24:06.0 +0100
@@ -21,7 +21,7 @@
 API_VERSION=$(SONAME)-0
 
 %:
-   dh $@ --with autoreconf,elpa,python3
+   dh $@ --with autoreconf,elpa
 
 ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
 override_dh_auto_configure:
@@ -57,14 +57,18 @@
# Generate the manpage
xmlto man debian/protoc.xml
 
+ifeq (,$(filter nopython,$(DEB_BUILD_PROFILES)))
# Python3 build
cp -rv python python3
set -e; cd python3 && for pv in $(shell py3versions -vr); do \
$(PYTHON_CROSS_VARS) python$$pv setup.py build 
--cpp_implementation; \
done
+endif
 
+ifeq (,$(filter noruby,$(DEB_BUILD_PROFILES)))
# Ruby build
cd ruby && rake package genproto
+endif
 
 override_dh_auto_build-indep:
dh_auto_build --indep
@@ -74,7 +78,9 @@
 
 override_dh_clean:
$(RM) -rv gmock
+ifeq (,$(filter noruby,$(DEB_BUILD_PROFILES)))
cd ruby && rake clobber
+endif
dh_clean
$(RM) config.h config.log config.status
$(RM) *.pc
@@ -94,7 +100,7 @@
 override_dh_auto_test-arch:
dh_auto_test --arch
 
-ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))$(filter 
nopython,$(DEB_BUILD_PROFILES)))
 # Python3 test
set -e; \
export LD_LIBRARY_PATH=$(CURDIR)/src/.libs; \
@@ -122,6 +128,7 @@
 override_dh_auto_install-arch:
dh_auto_install --arch
 
+ifeq (,$(filter nopython,$(DEB_BUILD_PROFILES)))
# Python3 install
set -e; \
cd python3 && for pv in $(shell py3versions -vr); do \
@@ -130,13 +137,16 @@
--root=$(CURDIR)/debian/python3-protobuf; \
done
find $(CURDIR)/debian/python3-protobuf -name 'protobuf-*-nspkg.pth' 
-delete
+endif
 
+ifeq (,$(filter noruby,$(DEB_BUILD_PROFILES)))
# Ruby install
 sed 's|ext/|ruby/ext/|' $(CURDIR)/ruby/google-protobuf.gemspec \
 >$(CURDIR)/google-protobuf.gemspec
dh_auto_install -O--buildsystem=ruby -O--package=ruby-google-protobuf 
--destdir=$(CURDIR)/debian/ruby-google-protobuf
find $(CURDIR)/debian/ruby-google-protobuf/usr/lib/ \
-name well_known_types.rb -exec chmod a+x {} \;
+endif
 
 override_dh_auto_install-indep:
dh_auto_install --indep

Bug#981081: kdbusaddons: reduce Build-Depends

[Helmut Grohne]

Source: kdbusaddons
Version: 5.78.0-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

kdbusaddons participates in dependency loops relevant to architecture
bootstrap. Instead of looking into such a difficult problem, I looked
for easily droppable dependencies. I think Norbert already committed the
dropping of graphviz also included here for completeness and
confirmation. Beyond that, dbus-x11 is only used for testing and can be
annotated .  Please consider applying the attached patch.

Helmut
diff --minimal -Nru kdbusaddons-5.78.0/debian/changelog 
kdbusaddons-5.78.0/debian/changelog
--- kdbusaddons-5.78.0/debian/changelog 2021-01-17 04:02:20.0 +0100
+++ kdbusaddons-5.78.0/debian/changelog 2021-01-26 06:45:06.0 +0100
@@ -1,3 +1,12 @@
+kdbusaddons (5.78.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop unused graphviz.
++ Annotate test dependency dbus-x11 .
+
+ -- Helmut Grohne   Tue, 26 Jan 2021 06:45:06 +0100
+
 kdbusaddons (5.78.0-2) unstable; urgency=medium
 
   * Release to unstable.
diff --minimal -Nru kdbusaddons-5.78.0/debian/control 
kdbusaddons-5.78.0/debian/control
--- kdbusaddons-5.78.0/debian/control   2021-01-17 03:54:33.0 +0100
+++ kdbusaddons-5.78.0/debian/control   2021-01-26 06:45:05.0 +0100
@@ -5,11 +5,10 @@
 Uploaders: Maximiliano Curia ,
Norbert Preining 
 Build-Depends: cmake (>= 3.5~),
-   dbus-x11,
+   dbus-x11 ,
debhelper-compat (= 13),
doxygen,
extra-cmake-modules (>= 5.78.0~),
-   graphviz,
libqt5sql5-sqlite:native,
libqt5x11extras5-dev (>= 5.14.0~),
pkg-kde-tools (>= 0.15.15ubuntu1~),

Bug#981082: libgphoto2: reduce Build-Depends

[Helmut Grohne]

Source: libgphoto2
Version: 2.5.26-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libgphoto2 participates in dependency loops relevant to architecture
bootstrap. Instead of looking into such a difficult problem, I looked
for easily droppable dependencies. It turns out that the doxygen
documentation is entirely contained in arch:all packages and that the
build systems handles its absence well. As such, it can be moved to
Build-Depends-Indep. The libdbus-1-dev was at some point added
(according to d/changelog), but I couldn't find any reason for that. Nor
could I find any use. Building libgphoto2 with Build-Conflicts:
libdbus-1-dev results in the exact same binary artifacts, so I think it
can be dropped without replacement. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru libgphoto2-2.5.26/debian/changelog 
libgphoto2-2.5.26/debian/changelog
--- libgphoto2-2.5.26/debian/changelog  2020-10-24 13:50:39.0 +0200
+++ libgphoto2-2.5.26/debian/changelog  2021-01-26 06:42:19.0 +0100
@@ -1,3 +1,12 @@
+libgphoto2 (2.5.26-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Demote doxygen to Build-Depends-Indep.
++ Drop unused libdbus-1-dev.
+
+ -- Helmut Grohne   Tue, 26 Jan 2021 06:42:19 +0100
+
 libgphoto2 (2.5.26-2) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --minimal -Nru libgphoto2-2.5.26/debian/control 
libgphoto2-2.5.26/debian/control
--- libgphoto2-2.5.26/debian/control2020-10-24 13:50:39.0 +0200
+++ libgphoto2-2.5.26/debian/control2021-01-26 06:42:17.0 +0100
@@ -6,10 +6,8 @@
Frederic Peters ,
   Ferenc Wágner ,
 Build-Depends: debhelper-compat (= 12),
-   doxygen,
graphviz,
libcurl4-openssl-dev,
-   libdbus-1-dev,
libexif-dev (>= 0.5.9),
libgd-dev,
libgpmg1-dev [linux-any],
@@ -22,6 +20,7 @@
rdfind,
symlinks,
zlib1g-dev
+Build-Depends-Indep: doxygen,
 Build-Conflicts: liblockdev1-dev
 Rules-Requires-Root: no
 Standards-Version: 4.5.0

Bug#981080: ruby2.7: reduce Build-Depends

[Helmut Grohne]

Source: ruby2.7
Version: 2.7.2-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ruby2.7 participates in dependency loops relevant to architecture
bootstrap. Rather than looking into such a difficult problem, I looked
for easily droppable dependencies. chrpath is entirely unused and can be
dropped with no replacement. netbase, openssl, procps and
rubygems-integration are only required for testing. A nocheck build with
all of these turned into Build-Conflicts reproduces the build artifacts
or a regular build. Please consider applying the attached patch.

Helmut
diff --minimal -Nru ruby2.7-2.7.2/debian/changelog 
ruby2.7-2.7.2/debian/changelog
--- ruby2.7-2.7.2/debian/changelog  2020-10-30 20:04:41.0 +0100
+++ ruby2.7-2.7.2/debian/changelog  2021-01-25 18:19:34.0 +0100
@@ -1,3 +1,12 @@
+ruby2.7 (2.7.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop unused chrpath dependency.
++ Annotate netbase, openssl, procps and rubygems-integration .
+
+ -- Helmut Grohne   Mon, 25 Jan 2021 18:19:34 +0100
+
 ruby2.7 (2.7.2-3) unstable; urgency=medium
 
   * d/p/0013-Enable-arm64-optimizations-that-exist-for-power-x86-.patch:
diff --minimal -Nru ruby2.7-2.7.2/debian/control ruby2.7-2.7.2/debian/control
--- ruby2.7-2.7.2/debian/control2020-10-30 20:04:41.0 +0100
+++ ruby2.7-2.7.2/debian/control2021-01-25 18:19:31.0 +0100
@@ -7,7 +7,6 @@
Lucas Kanashiro ,
Utkarsh Gupta 
 Build-Depends: bison,
-   chrpath,
coreutils (>= 7.5),
debhelper-compat (= 12),
file,
@@ -19,11 +18,11 @@
libreadline6-dev,
libssl-dev,
libyaml-dev,
-   netbase,
-   openssl,
-   procps,
+   netbase ,
+   openssl ,
+   procps ,
ruby:native ,
-   rubygems-integration (>= 1.6),
+   rubygems-integration (>= 1.6) ,
systemtap-sdt-dev [linux-any],
tzdata,
zlib1g-dev

Bug#981070: e2fsprogs: (Possibly) e2fsck sometimes enables ext4 features on ext2 filesystems?

[Theodore Ts'o]

On Tue, Jan 26, 2021 at 12:10:20AM +0100, Christoph Biedl wrote:
> Package: e2fsprogs
> Version: 1.44.5-1+deb10u3
> Severity: normal
> 
> Dear Maintainer,
> 
> at first, I am sorry to tell I cannot provide the raw data. I was quite
> in a hurry and overwrote it before realizing its high value for
> debugging.
> 
> Story: An ext2 file system, actually a boot partition, suffered severe
> damage for whatever reason, possibly controller issues. After massive
> repair done by e2fsck (on amd64, from Debian testing), the file system
> was clean and usable again (also, no damage to the important files but a
> lot of garbage in lost+found), *but* the kernel no longer recognizes it
> as ext2:
> 
>   EXT4-fs (sdf3): mounted filesystem without journal. Opts: (null)
> 
> Expected:
> 
>   EXT4-fs (sdf3): mounting ext2 file system using the ext4 subsystem

That's just a matter of how it was mounted.  If you mount with -t
ext2, you'll get:

# mke2fs -t ext2 /tmp/foo.img  2M
# mount -t ext2 /tmp/foo.img /mnt
[39916.330690] EXT4-fs (loop0): mounting ext2 file system using the ext4 
subsystem

If you mount the same file system with ext4, you'll get:

# mount -t ext4 /tmp/foo.img /mnt

[39880.180962] EXT4-fs (loop0): mounted filesystem without journal. Opts: 
(null). Quota mode: none.

> Therefore I assume e2fsck, while repairing the damage, by accident
> enabled some feature bits that made the kernel think it is dealing with
> an ext4
> 
> As I said, the raw image is destroyed. However I kept the output of
> "tune2fs -l" (again, from testing), possibly this provides enough hint
> to investigate?

You didn't actually include the output of tune2fs -l in your bug
report.  Given that you named them "broken" and "okay" I assume you
meant to attach them, but forgot to do so?

That being said, I'm pretty sure e2fsck enabled file system features;
in general, it doesn't do that, and certainly not with any of the
features added since the ext4 era.

My best guess is that I/O errors resulted in garbage getting written
to the inode table, and e2fsck wasn't clearly the fscrypt inode flag
when the fscrypt feature flag was not set; that would explain the
fscrypt kernel error message that you saw.

Cheers,

- Ted

Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries

[Michael Tokarev]

26.01.2021 02:33, Thorsten Glaser wrote:


Hi, what’s the status on this? It is still broken in sid.
Could we please get the fix?


Mmm. Is there a fix? If there is, I for one don't know it.

Thanks,

/mjt

Bug#981022: RFS: ticker/1.13 [QA] -- configurable text scroller

[Leandro Cunha]

Em ter., 26 de jan. de 2021 às 01:39, Sergio Durigan Junior
 escreveu:
>
> On Monday, January 25 2021, Leandro Cunha wrote:
>
> > Em seg., 25 de jan. de 2021 às 21:16, Sergio Durigan Junior <
> > sergi...@debian.org> escreveu:
> >
> >> On Monday, January 25 2021, Leandro Cunha wrote:
> >>
> >> >  ticker (1.13) unstable; urgency=medium
> >> >  .
> >> >* QA upload.
> >> >* FTCBFS: uses the build architecture compiler. (Closes: #979732)
> >> >* ticker.spec: updated version to 1.13.
> >> >* debian/control:
> >> >  - Bumped Standards-Version to 4.5.1.
> >> >  - Removed Vcs in Salsa nonexistent.
> >> >* debian/copyright:
> >> >  - Updated contribution year.
> >>
> >> The package was uploaded before I could review it, but in your previous
> >> upload you added Vcs-* fields to d/control.  In this one, you removed
> >> them.  Why didn't you push the repository to salsa?
> >>
> >> --
> >> Sergio
> >> GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
> >> Please send encrypted e-mail if possible
> >> https://sergiodj.net/
> >>
> >
> > This can be resolved with gbp import-dscs --debsnap ticker after creating
> > the
> > repository in the Debian group on Salsa with permission.
>
> I know that.  My question was why didn't you do it?

I am not allowed to send to the Debian group on Salsa that was inserted and
as the migration was not done and there was an error in the tracker I decided
to remove it to solve this problem. I am suggesting migrating to Salsa
to facilitate
future contributions by other people and other benefits. If you create the Salsa
repository I will run this command to migrate so I quoted it. With
permission I do
it myself or if you want you can do it too and you would be helping me. Another
possibility is that I create and you migrate to the Debian group.

> --
> Sergio
> GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
> Please send encrypted e-mail if possible
> https://sergiodj.net/

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.
-BEGIN PGP PUBLIC KEY BLOCK-

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

Bug#981022: RFS: ticker/1.13 [QA] -- configurable text scroller

[Sergio Durigan Junior]

On Monday, January 25 2021, Leandro Cunha wrote:

> Em seg., 25 de jan. de 2021 às 21:16, Sergio Durigan Junior <
> sergi...@debian.org> escreveu:
>
>> On Monday, January 25 2021, Leandro Cunha wrote:
>>
>> >  ticker (1.13) unstable; urgency=medium
>> >  .
>> >* QA upload.
>> >* FTCBFS: uses the build architecture compiler. (Closes: #979732)
>> >* ticker.spec: updated version to 1.13.
>> >* debian/control:
>> >  - Bumped Standards-Version to 4.5.1.
>> >  - Removed Vcs in Salsa nonexistent.
>> >* debian/copyright:
>> >  - Updated contribution year.
>>
>> The package was uploaded before I could review it, but in your previous
>> upload you added Vcs-* fields to d/control.  In this one, you removed
>> them.  Why didn't you push the repository to salsa?
>>
>> --
>> Sergio
>> GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
>> Please send encrypted e-mail if possible
>> https://sergiodj.net/
>>
>
> This can be resolved with gbp import-dscs --debsnap ticker after creating
> the
> repository in the Debian group on Salsa with permission.

I know that.  My question was why didn't you do it?

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

Bug#981071: RFP: luksman -- A CLI frontend for cryptsetup for managing LUKS containers.

[2board.admin]

Package: luksman
Version: 1.0.0
Severity: wishlist
System: Ubuntu 20.04
Upstream Author: "emanresu" <2board.ad...@protonmail.com>
Main Repo URL: https://codeberg.org/emanresu/Luksman
1.0.0 Release URL: https://codeberg.org/emanresu/Luksman/releases/tag/1.0.0_deb
License: GPL
Description:
A CLI frontend for cryptsetup for managing LUKS containers written in python3.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Bug#981022: RFS: ticker/1.13 [QA] -- configurable text scroller

[Leandro Cunha]

Em seg., 25 de jan. de 2021 às 21:16, Sergio Durigan Junior <
sergi...@debian.org> escreveu:

> On Monday, January 25 2021, Leandro Cunha wrote:
>
> >  ticker (1.13) unstable; urgency=medium
> >  .
> >* QA upload.
> >* FTCBFS: uses the build architecture compiler. (Closes: #979732)
> >* ticker.spec: updated version to 1.13.
> >* debian/control:
> >  - Bumped Standards-Version to 4.5.1.
> >  - Removed Vcs in Salsa nonexistent.
> >* debian/copyright:
> >  - Updated contribution year.
>
> The package was uploaded before I could review it, but in your previous
> upload you added Vcs-* fields to d/control.  In this one, you removed
> them.  Why didn't you push the repository to salsa?
>
> --
> Sergio
> GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
> Please send encrypted e-mail if possible
> https://sergiodj.net/
>

This can be resolved with gbp import-dscs --debsnap ticker after creating
the
repository in the Debian group on Salsa with permission.

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.

Bug#978636: move to merged-usr-only?

[Keith Packard]

Simon McVittie  writes:

> Should we be more specific than this in what we vote on, to avoid
> later having to adjudicate between developers who say that a particular
> implementation is or isn't merged-usr?

I think that and a transition plan are both key to this project. I
recently installed Debian from scratch on my HiFive unmatched board and
it got merged / and /usr. When I built packages on this device, they
created invalid packages as the shared library dependencies all listed
/lib instead of /usr/lib. That seems like a non-starter to me.

Any plan where a transitioning system cannot be used for ongoing Debian
development seems unworkable to me -- it leaves all active Debian
developers working on un-transitioned systems, which greatly reduces
test coverage from people in the best position to help fix things.

I do use a separate cowbuilder when creating packages to upload, and
that could be configured in un-transitioned mode, but I also regularly
debug packages on my native system as that offers much faster
development times.

> Guillem considers layout 1 to be broken and a mess. I don't agree,
> but I'm not a dpkg maintainer. We should be aware that mandating this
> implementation is likely to require some overruling.

From an architectural purity perspective, layout 1 'looks nicer'. As
that also matches what other distros are doing, it would make us more
consistent across the Linux ecosystem (I believe that's a good thing).

However, I believe only layout 2a would make it possible to build Debian
packages on transitioned systems. That seems necessary to me. We could,
in future, then transition from layout 2a to layout 1 once /lib (and
/bin?)  were no longer in the default search paths to cause invalid
packages to be created.

I don't understand the value of 2b; it's functionally similar to layout
1, but makes for additional work to create the shadow links, along with
consuming space for them. It also doesn't resolve the problem of
building packages.

> Sorry to derail this but I think we should be clear about what we're
> resolving.

I think you've added helpful clarification to the conversation, thanks!

-- 
-keith


signature.asc
Description: PGP signature

Bug#981079: request-tracker4: RT4 does not ship with real ckeditor source

[Dominic Hargreaves]

Package: request-tracker4
Version: 4.4.4-2
Severity: serious
Justification: DFSG

During packaging of RT5 it was noticed that the ckeditor source
shipped in third-party does not correspond to the preferred form
of modification - it is still minified (like that shipped in the main
tarball). This is due to a change of upstream practice since the
third-party tarball setup was originally introduced.

This is fixed in RT5 by repacking the third-party-source to add
additional sources - see[1]. We should do something similar for RT4,
at least if we will keep RT4 around in bullseye.

[1] 

Bug#981055: O: john -- active password cracking tool

[Axel Beckert]

Hi,

Baptiste Beauplat wrote:
> The current maintainer of john, Ruben Molina ,
> is apparently not active anymore.  Therefore, I orphan this package now.

I assume that the listed Uploader (who did the last maintainer upload
in 2014) is also fine with that. Cc'ed.

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

I do not intent to adopt the package, but I will do an QA upload to
fix at least the RC bug since testing autoremoval is imminent and I do
want to see john in bullseye even if its this rather old version. See
https://bugs.debian.org/979054 for details.

I've imported the whole packaging history from snapshots.debian.org
into Salsa at https://salsa.debian.org/debian/john, so anyone who
wants to take over can simply start there.

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

Bug#981078: transition: libxmlb (freeze exception)

[Matthias Klumpp]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: mario.limoncie...@dell.com
Severity: normal

Hi!
As we are already in transition freeze for bullseye, I would like to
request permission to do a transition of libxmlb1 --> libxmlb2 which
unfortunately missed the deadline by accident.
The only packages impacted by this transition are fwupd and
gnome-software, which are handled by the same people who also handle
libxmlb.

The updated version includes multiple performance and robustness fixes
as well as reduced memory requirements, which will be very beneficial
for users of gnome-software and fwupd and are inherently tied to the
API break.
Updating libxmlb now would greatly simplify future backports and also
would be great for supporting fwupd updates in the stable Debian
release for robust firmware updates (so ideally we could just update
fwupd and wouldn't be hindered by an old version of libxmlb that
gnome-software also depends on).

GNOME Software and fwupd should already support the new API and just
need a rebuild.

Summary of the libxmlb changes:

Important:
- This release breaks API and ABI and bumps the version of libxmlb.so and so
packages that depend on this library (e.g. fwupd or gnome-software) will need
to be rebuilt at the same time.

New Features:
- Add the missing TEXT:INTE XPath support (Richard Hughes)
- Add variant of xb_silo_query_with_root() avoiding XbNode creation
(Philip Withnall)
- Add XB_BUILDER_SOURCE_FLAG_WATCH_DIRECTORY flag (Philip Withnall)
- Allow specifying the node cache behaviour for the query (Richard Hughes)

Bugfixes:
- Avoid recursion when setting flags if possible (Philip Withnall)
- Avoid using weak pointers when building the silo (Philip Withnall)
- Change the default value for the node cache (Richard Hughes)
- Do not allocate opcodes individually (Philip Withnall)
- Do not show a critical warning for invalid XML (Richard Hughes)
- Do not unconditionally create GTimer objects (Philip Withnall)
- Do not use the node cache when building indexes (Richard Hughes)
- Lazy load more arrays to reduce RSS usage (Philip Withnall)
- Report silo versions when versions mismatch (Robert Ancell)
- Do not assume g_content_type_guess() always returns valid results
(Richard Hughes)
- Make the build reproducible (Richard Hughes)
- Revert "Do not show a critical warning for invalid XML" (Richard Hughes)
- Update the header location to reflect the new API (Richard Hughes)

Thank you for considering!
Cheers,
Matthias

Ben file:

title = "libxmlb";
is_affected = .depends ~ "libxmlb1" | .depends ~ "libxmlb2";
is_good = .depends ~ "libxmlb2";
is_bad = .depends ~ "libxmlb1";

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit

[Adam Borowski]

On Mon, Jan 25, 2021 at 06:05:24PM +0100, Giulio Paci wrote:
> I am looking for a sponsor for an updated version of the package "sctk"
> 
>  * Package name: sctk
>Version : 2.4.10-20151007-1312Z+dfsg2-4

A lot of text, eg in debian/copyright_hints, is seriously garbled.

-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `

Bug#980901: python-scrapy: FTBFS in pbuilder without --use-network=yes due to tests in test_command_check.py

[Paul Wise]

Control: retitle -1 python-scrapy: FTBFS without network access due to 
test_command_check.py
Control: severity -1 serious

On Sun, 24 Jan 2021 11:52:53 +0800 Paul Wise wrote:

> When I rebuild python-scrapy in pbuilder, I get a FTBFS due to the
> tests in tests/test_command_check.py failing unless I enable the use of
> the network using the --use-network=yes option.

I'm told the test in question uses contracts, which is scrapy's way of
testing that downloads the webpage live and checks if it is able to
scrape expected fields and links from that webpage, so, passing the
test-suite would definitely need network access.

   https://scrapy2.readthedocs.io/en/latest/topics/contracts.html

The Debian Policy about network access during build is fairly clear, it
isn't allowed except to things started by the build itself:

   
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

   For packages in the main archive, no required targets may attempt
   network access, except, via the loopback interface, to services on the
   build host that have been started by the build.

Since the upstream pytest configuration just runs all tests in the
tests directory I think a simple way of solving this will be to delete
the offending test file before the tests run, via PYBUILD_BEFORE_TEST:

   $ grep -A3 pytest pytest.ini | grep py
   [pytest]
   python_files=test_*.py __init__.py
   
   $ grep -i test debian/rules 
   export PYBUILD_BEFORE_TEST=cd {dir}/tests/keys; cat example-com.key.pem 
example-com.cert.pem >cert.pem

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#976404: mpi4py: flaky ppc64el autopkgtest on ci.debian.net: regularly times out

[Drew Parsons]

Source: mpi4py
Followup-For: Bug #976404

mpi4py tests seem to have started passing stably on ppc64el after the
upgrade of libpmix2 from 3.2.0-1 to 3.2.1-1

(other test errors after that are other known openmpi problems,
recently fixed, not these timeout errors)

Tests are now passing reliably in both unstable and testing.

Looks like ppc64el performance has been fixed in pmix.

I think we can close this bug now.

Bug#981075: reportbug: Simple to-do list with a timer that keeps focus on the task.

[leandroembu]

I'm sorry, Sandro. I reported the bug following up the RFP, But I
forgot to mention the upstream program:

https://github.com/JMoerman/Go-For-It


On Mon, 25 Jan 2021 19:25:04 -0500 Sandro Tosi  wrote:
> > Package: wnpp
> > Followup-For: Bug #979275
> > Owner: Leandro Ramos 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> >
> > Hi. I want to package the program because I have been using it since 2014. I
> > intend to finish the packaging and look for a sponsor.
> 
> and what program would that be? definitely not reportbug
> 
> -- 
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
> 
> 

Bug#976811: transition: php8.0

[Thorsten Glaser]

block 976811 by 980567
thanks

On Sat, 12 Dec 2020, Ondřej Surý wrote:

> And let me restate that it’s not my intent to make anyone’s life hell and
> I am willing to help with any package (as usual). I am just trying to do
> the most sane thing to do security and maintainer wise.

You probably should have communicated this with maintainers of PHP
packages. I was taken completely by surprise (via #980567) that
PHP 8 is even available in Debian now, and back when I asked you
to provide a release candidate via experimental, so that we could
test software with it before the release, some months ago, you
denied that, so colour me surprised to get a bugreport from it now.

As things are, I won’t upgrade php-react-promise now. If I find
the time I may backport the two commits mentioned to fix the one
issue reported, but… it’s already tight. (Upgrading is completely
out of the picture, as this involves multiple packages, and there
is a dependency chain reaching as far as composer. By the way, if
the composer maintainers with to take over the reactphp packages,
that could be arranged.)

I also had to actively search for this, wondering which PHP version
we’d be having with bullseye then… and this was not obvious to find.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Bug#981073: dolphin: Dolphin uses 100% CPU

[Norbert Preining]

Hi Steve,

> After upgrading from buster to bullseye, Dolphin now uses 100% CPU
> whenever it is running.

I cannot reproduce this. Can you strace dolphin or somehow find out what
it is doing when at 100%?

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#979187: 977694 & 979187 fixed-upstream but remain in Debian :-

[Ryutaroh Matsumoto]

I found that
CONFIG_RESET_RASPBERRYPI=y
is enough to fix #979187, while
CONFIG_RESET_RASPBERRYPI=m
is not.

I will submit an MR to salsa. Ryutaroh

Bug#981077: ITP: request-tracker5 -- extensible trouble-ticket tracking system

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: request-tracker5
  Version : 5.0.0
  Upstream Author : Best Practical Solutions, LLC >
* URL : https://bestpractical.com/rt/
* License : GPL-2
  Programming Lang: Perl
  Description : extensible trouble-ticket tracking system

 Request Tracker (RT) is a ticketing system which
 enables a group of people to intelligently and efficiently manage
 tasks, issues, and requests submitted by a community of users. It
 features web, email, and command-line interfaces (see the package
 rt5-clients).
 .
 RT manages key tasks such as the identification, prioritization,
 assignment, resolution, and notification required by
 enterprise-critical applications, including project management, help
 desk, NOC ticketing, CRM, and software development.
 .
 This package provides the 5 series of RT. It can be installed alongside
 the 3.8 and 4 series without any problems.
 .
 This package provides the core of RT.
 .
 This package supports three database types out of the box: MySQL,
 PostgreSQL and SQLite. In order to support a zero-configuration install,
 SQLite will be used by default, but is not recommended for production
 use. Please see /usr/share/doc/request-tracker5/NOTES.Debian for more
 details and consider installing rt5-db-postgresql or rt5-db-mysql at
 the same time as this package.

This package is the next major release of the software currently
packaged as request-tracker4, and the packaging is a branch of that.

It will be mainted by the RT packaging team,
.

Bug#980480: [pkg-go] Bug#980480: autopkgtest always fail

[Dmitry Smirnov]

On Wednesday, 20 January 2021 2:46:07 AM AEDT Shengjing Zhu wrote:
> What's the purpose of this line?
> https://salsa.debian.org/debian/libpod/-/blob/debian/2.1.1+dfsg1-4/debian/rules#L21

The purpose should be self-explanatory: it prints auto-populated
DH_GOLANG_INSTALL_EXTRA so we'd know what exactly have been found
by wildcard patterns and so we'd have records of that in the build
log.

Valid Makefile syntax should not confuse autopkgtest.

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Censorship is always cause for celebration. It is always an opportunity
because it reveals fear of reform. It means that the power position is so
weak that you have got to care what people think.
-- Julian Assange

---

And how long a lockdown is enough? If we open now, will lockdown recur in
autumn? Next year? Whenever authoritarianism so wishes? No dictatorship
could imagine a better precedent for absolute control.
-- https://www.bmj.com/content/369/bmj.m1924.long
:: BMJ 2020;369:m1924 "Should governments continue lockdown to slow the 
spread of covid-19?"


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

Bug#973196: monero: FTBFS: optional.hpp:1591:3: error: static assertion failed: If you want to output boost::optional, include header

[Jonas Smedegaard]

Control: tags -1 +help

Quoting Lucas Nussbaum (2020-10-27 18:00:12)
> Source: monero
> Version: 0.16.0.0-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201027 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> > /usr/include/boost/optional/optional.hpp:1591:3: error: static assertion 
> > failed: If you want to output boost::optional, include header 
> > 
> >  1591 |   BOOST_STATIC_ASSERT_MSG(sizeof(CharType) == 0, "If you want to 
> > output boost::optional, include header ");
> >   |   ^~~
> > make[4]: *** [tests/unit_tests/CMakeFiles/unit_tests.dir/build.make:917: 
> > tests/unit_tests/CMakeFiles/unit_tests.dir/wipeable_string.cpp.o] Error 1

Possibly an independent bug, but while the above is seemingly easy to 
fix, the build of 0.17.1.9 then fails later.  Build log attached, and 
draft packaging of 0.17.1.9 is at 
https://salsa.debian.org/cryptocoin-team/monero

Help solving these bugs is much appreciated.

 - Jonas

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

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

signature.asc
Description: signature

Bug#940625: diskcache: ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found

[Sandro Tosi]

> I injected a new tarball drained from Github.  It seems to need lots of
> not yet packaged - I have no idea how to cope with this.

i dont understand what you're trying to say here; if it's that
diskcache requires modules/packages not present in debian yet, it's
simple: you need to package those packages first or find someone else
to do that.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#981075: reportbug: Simple to-do list with a timer that keeps focus on the task.

[Sandro Tosi]

> Package: wnpp
> Followup-For: Bug #979275
> Owner: Leandro Ramos 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> Hi. I want to package the program because I have been using it since 2014. I
> intend to finish the packaging and look for a sponsor.

and what program would that be? definitely not reportbug

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#981022: RFS: ticker/1.13 [QA] -- configurable text scroller

[Sergio Durigan Junior]

On Monday, January 25 2021, Leandro Cunha wrote:

>  ticker (1.13) unstable; urgency=medium
>  .
>* QA upload.
>* FTCBFS: uses the build architecture compiler. (Closes: #979732)
>* ticker.spec: updated version to 1.13.
>* debian/control:
>  - Bumped Standards-Version to 4.5.1.
>  - Removed Vcs in Salsa nonexistent.
>* debian/copyright:
>  - Updated contribution year.

The package was uploaded before I could review it, but in your previous
upload you added Vcs-* fields to d/control.  In this one, you removed
them.  Why didn't you push the repository to salsa?

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#932456: Is there any progress on this bug

[Mark - Syminet]

On Fri, 01 Jan 2021 23:06:07 + "Rajko Albrecht"  
wrote:

> I have the same problems since upgraded to 10.x - and it is frustrating that 
> I cannot do automated VM backups because I don't want to (temporary) shutdown 
> AA in a script. So I start the backup script by hand every time.

> 

> Is this due a change by maintainer or is this an upstream bug (with fedora 
> and selinux I don't see such problems). I'm asking because nothing happens on 
> this bug but I think this is urgent for one using debian as KVM host.

> 

> R



We are also effected - and, same behavior in bullseye too.  

Bullseye is about to enter freeze.  Could use a little help here... 

Bug#978065: lxc: After upgrade lxc to 4.0.5-1, cannot start with lxc.cap.drop sys_admin

[Andras Korn]

Hi,

I hit the same issue.

I upgraded from 1:4.0.4-6 to 1:4.0.5-2, and from kernel 5.9.0-4-amd64 to 
5.10.0-2-amd64, and some of my containers that used to work before don't work 
anyomre. The ones that still work don't drop sys_admin.

stracing lxc-start I see this:

openat2(33, "/sys/fs/cgroup", 
{flags=O_RDONLY|O_CLOEXEC|O_PATH, 
resolve=RESOLVE_NO_XDEV|RESOLVE_NO_MAGICLINKS|RESOLVE_NO_SYMLINKS|RESOLVE_BENEATH},
 24) = -1 EXDEV (Invalid cross-device link)

The corresponding message from lxc-start with loglevel debug is:

lxc-start unifiadmin 20210125231743.129 ERRORconf - 
conf.c:lxc_mount_auto_mounts:727 - Invalid cross-device link - Failed to mount 
"/sys/fs/cgroup"

Some context from lxc-start log output:

lxc-start unifiadmin 20210125231742.854 INFO start - start.c:lxc_init:837 - 
Container "unifiadmin" is initialized
lxc-start unifiadmin 20210125231742.876 WARN cgfsng - 
cgroups/cgfsng.c:mkdir_eexist_on_last:1152 - File exists - Failed to create 
directory "/sys/fs/cgroup/cpuset//lxc.monitor.unifiadmin"
lxc-start unifiadmin 20210125231742.886 INFO cgfsng - 
cgroups/cgfsng.c:cgfsng_monitor_create:1368 - The monitor process uses 
"lxc.monitor.unifiadmin" as cgroup
lxc-start unifiadmin 20210125231742.904 WARN cgfsng - 
cgroups/cgfsng.c:mkdir_eexist_on_last:1152 - File exists - Failed to create 
directory "/sys/fs/cgroup/cpuset//lxc.payload.unifiadmin"
lxc-start unifiadmin 20210125231742.916 INFO cgfsng - 
cgroups/cgfsng.c:cgfsng_payload_create:1471 - The container process uses 
"lxc.payload.unifiadmin" as cgroup
lxc-start unifiadmin 20210125231742.944 INFO start - start.c:lxc_spawn:1700 
- Cloned CLONE_NEWNS
lxc-start unifiadmin 20210125231742.944 INFO start - start.c:lxc_spawn:1700 
- Cloned CLONE_NEWPID
lxc-start unifiadmin 20210125231742.945 INFO start - start.c:lxc_spawn:1700 
- Cloned CLONE_NEWUTS
lxc-start unifiadmin 20210125231742.945 INFO start - start.c:lxc_spawn:1700 
- Cloned CLONE_NEWIPC
lxc-start unifiadmin 20210125231742.945 INFO start - start.c:lxc_spawn:1700 
- Cloned CLONE_NEWNET
lxc-start unifiadmin 20210125231742.945 DEBUGstart - 
start.c:lxc_try_preserve_namespaces:166 - Preserved mnt namespace via fd 31
lxc-start unifiadmin 20210125231742.945 DEBUGstart - 
start.c:lxc_try_preserve_namespaces:166 - Preserved pid namespace via fd 32
lxc-start unifiadmin 20210125231742.946 DEBUGstart - 
start.c:lxc_try_preserve_namespaces:166 - Preserved uts namespace via fd 33
lxc-start unifiadmin 20210125231742.946 DEBUGstart - 
start.c:lxc_try_preserve_namespaces:166 - Preserved ipc namespace via fd 34
lxc-start unifiadmin 20210125231742.946 DEBUGstart - 
start.c:lxc_try_preserve_namespaces:166 - Preserved net namespace via fd 35
lxc-start unifiadmin 20210125231742.949 INFO cgfsng - 
cgroups/cgfsng.c:cgfsng_setup_limits_legacy:2881 - Limits for the legacy cgroup 
hierarchies have been setup
lxc-start unifiadmin 20210125231742.955 WARN cgfsng - 
cgroups/cgfsng.c:cgfsng_setup_limits:2942 - Invalid argument - Ignoring cgroup2 
limits on legacy cgroup system
lxc-start unifiadmin 20210125231743.315 INFO network - 
network.c:instantiate_veth:285 - Retrieved mtu 1500 from intra
lxc-start unifiadmin 20210125231743.666 INFO network - 
network.c:instantiate_veth:333 - Attached "veth-unifi" to bridge "intra"
lxc-start unifiadmin 20210125231743.687 DEBUGnetwork - 
network.c:instantiate_veth:449 - Instantiated veth tunnel "veth-unifi <--> 
vethv7jzuF"
lxc-start unifiadmin 20210125231743.699 WARN start - start.c:do_start:1166 
- Using /dev/null from the host for container init's standard file descriptors. 
Migration will not work
lxc-start unifiadmin 20210125231743.704 INFO start - start.c:do_start:1198 
- Unshared CLONE_NEWCGROUP
lxc-start unifiadmin 20210125231743.731 DEBUGstorage - 
storage/storage.c:get_storage_by_name:211 - Detected rootfs type "dir"
lxc-start unifiadmin 20210125231743.734 DEBUGconf - 
conf.c:lxc_mount_rootfs:1259 - Mounted rootfs "/var/lib/lxc/unifiadmin/rootfs" 
onto "/usr/lib/x86_64-linux-gnu/lxc/rootfs" with options "(null)"
lxc-start unifiadmin 20210125231743.738 INFO conf - 
conf.c:setup_utsname:751 - Set hostname to "unifiadmin"
lxc-start unifiadmin 20210125231743.740 DEBUGnetwork - 
network.c:lxc_network_setup_in_child_namespaces_common:3510 - Network device "" 
has been setup
lxc-start unifiadmin 20210125231743.977 DEBUGnetwork - 
network.c:setup_hw_addr:3360 - Mac address "00:16:3e:11:22:33" on "eth0" has 
been setup
lxc-start unifiadmin 20210125231743.103 DEBUGnetwork - 
network.c:lxc_network_setup_in_child_namespaces_common:3510 - Network device 
"eth0" has been setup
lxc-start unifiadmin 20210125231743.103 INFO network - 
network.c:lxc_setup_network_in_child_namespaces:3532 - Network has been setup
lxc-start unifiadmin 20210125231743.116 DEBUGconf - conf.c:mount_entry:1943 
- Remounting "/shared/cache/apt/lists" on 

Bug#979301: namazu2-index-tools: contains namazu.1 manpage after separate arch-indep build

[Andreas Beckmann]

Followup-For: Bug #979301
Control: tag -1 patch pending

Hi,

I've uploaded the attached NMU to DELAYED/5. It updates the package to
debhelper-compat (= 13) and sanitizes the debhelper usage.


Andreas
diff -Nru namazu2-2.0.21/debian/changelog namazu2-2.0.21/debian/changelog
--- namazu2-2.0.21/debian/changelog 2021-01-03 16:43:47.0 +0100
+++ namazu2-2.0.21/debian/changelog 2021-01-26 00:54:07.0 +0100
@@ -1,3 +1,13 @@
+namazu2 (2.0.21-22.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to debhelper-compat (= 13).
+  * Sanitize debhelper usage.  (Closes: #979301, #980776)
+  * Don't skip the tests, but ignore failures for now.
+  * Minor cleanups.
+
+ -- Andreas Beckmann   Tue, 26 Jan 2021 00:54:07 +0100
+
 namazu2 (2.0.21-22.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
@@ -22,7 +32,7 @@
 namazu2 (2.0.21-20) unstable; urgency=medium
 
   * debian/emacsen-*: Update from new deb-make template.
-  * debian/patches/0001-fix-old-backquote.patch: Remove ancienct backquote
+  * debian/patches/0001-fix-old-backquote.patch: Remove ancient backquote
 
  -- NOKUBI Takatsugu   Thu, 05 Jan 2017 07:18:32 +
 
@@ -321,7 +331,7 @@
 
 namazu2 (2.0.13-4) unstable; urgency=low
 
-  * Moved "dh_movefiles -pnamazu2-common" from binary-indep target to 
+  * Moved "dh_movefiles -pnamazu2-common" from binary-indep target to
 install target, closes Bug#260745.
 
  -- NOKUBI Takatsugu   Thu, 22 Jul 2004 09:16:55 +0900
@@ -489,7 +499,7 @@
   * changed package structure
  Added namazu2-index-tools (separated from namazu2)
  Removed libfile-mmagic-perl, it is going it's own package, ITPed.
-  
+
  -- Takuo KITAME   Thu,  6 Apr 2000 10:00:57 +0900
 
 namazu2 (2.0-2) unstable; urgency=low
@@ -503,5 +513,3 @@
   * Initial Release.
 
  -- Takuo KITAME   Mon, 21 Feb 2000 10:35:05 +0900
-
-
diff -Nru namazu2-2.0.21/debian/compat namazu2-2.0.21/debian/compat
--- namazu2-2.0.21/debian/compat2019-04-17 09:29:57.0 +0200
+++ namazu2-2.0.21/debian/compat1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru namazu2-2.0.21/debian/control namazu2-2.0.21/debian/control
--- namazu2-2.0.21/debian/control   2019-04-17 09:29:57.0 +0200
+++ namazu2-2.0.21/debian/control   2021-01-26 00:54:03.0 +0100
@@ -2,12 +2,27 @@
 Section: text
 Priority: optional
 Maintainer: NOKUBI Takatsugu 
-Build-Depends: debhelper (>= 9), perl, kakasi, chasen, libnkf-perl, 
libfile-mmagic-perl, libtext-kakasi-perl, tk, lynx, file, dh-autoreconf
+Build-Depends:
+ debhelper-compat (= 13),
+ perl,
+ kakasi,
+ chasen,
+ libnkf-perl,
+ libfile-mmagic-perl,
+ libtext-kakasi-perl,
+ tk,
+ lynx,
+ file,
+Rules-Requires-Root: no
 Standards-Version: 3.9.7
 
 Package: namazu2
 Architecture: any
-Depends: ${shlibs:Depends}, namazu2-common, ${misc:Depends}
+Depends:
+ ${perl:Depends},
+ ${shlibs:Depends},
+ namazu2-common (= ${source:Version}),
+ ${misc:Depends}
 Suggests: www-browser, apache2, namazu2-index-tools, emacsen-common, tk
 Conflicts: namazu (<< 2.0), namazu-el, tknamazu
 Provides: namazu
@@ -50,6 +65,7 @@
  This package including only document files, also message catalogue.
 
 Package: libnmz7
+Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: full text search engine - shared library
@@ -61,10 +77,10 @@
  and/or another utilities.
 
 Package: libnmz7-dev
+Section: libdevel
 Architecture: any
 Depends: libnmz7 (= ${binary:Version}), ${misc:Depends}
 Conflicts: libnmz3-dev
-Section: libdevel
 Description: full text search engine - header files and static libraries
  Namazu is a full text search engine which is usable via CGI. It features
  a simple and easy setup, and is written in C and Perl. Namazu uses the
diff -Nru namazu2-2.0.21/debian/copyright namazu2-2.0.21/debian/copyright
--- namazu2-2.0.21/debian/copyright 2019-04-17 09:29:57.0 +0200
+++ namazu2-2.0.21/debian/copyright 2021-01-26 00:23:28.0 +0100
@@ -20,4 +20,4 @@
 GNU General Public License for more details.
 
 On Debian GNU/Linux systems, the complete text of the GNU General
-Public License can be found in `/usr/share/common-licenses/GPL'.
+Public License can be found in `/usr/share/common-licenses/GPL-2'.
diff -Nru namazu2-2.0.21/debian/dirs namazu2-2.0.21/debian/dirs
--- namazu2-2.0.21/debian/dirs  2019-04-17 09:29:57.0 +0200
+++ namazu2-2.0.21/debian/dirs  1970-01-01 01:00:00.0 +0100
@@ -1,4 +0,0 @@
-etc/namazu
-var/lib/namazu/index
-usr/share/doc/namazu2-common
-usr/share/emacs/site-lisp/namazu
diff -Nru namazu2-2.0.21/debian/docs namazu2-2.0.21/debian/docs
--- namazu2-2.0.21/debian/docs  2019-04-17 09:29:57.0 +0200
+++ namazu2-2.0.21/debian/docs  1970-01-01 01:00:00.0 +0100
@@ -1,6 +0,0 @@
-INSTALL
-NEWS
-README
-README-ja
-TODO
-ChangeLog.1
diff -Nru namazu2-2.0.21/debian/libfile-mmagic-perl.files 
namazu2-2.0.21/debian/libfile-mmagic-perl.files
--- 

Bug#981076: bridge-utils: clarify bridge_hw situation

[Thorsten Glaser]

Package: bridge-utils
Version: 1.6-5+b1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de, n...@naturalnet.de

I’m shocked to read this in apt-listchanges so shortly before a release:

bridge-utils (1.6-4) unstable; urgency=low

  Linux kernel has changed bridge MAC address selection.

  In older Linux kernels the MAC of the bridge was the lower mac of the
  devices attached to it, this is no longer the case now at Bullseye. The
  kernel now makes up a completely new MAC address.

  This means that if you rely on your bridge's MAC address for something
  like DHCP leases or similar stuff you'll loose this feature. The only way
  to go back to your old macc address is to assign it to the bridge
  explicitly using bridge_hw followed by the wanted MAC address on your
  bridge definition.

The bridge_hw documentation does *not* endear me to using that option:

   bridge_hw MAC_address|interface
  set the Ethernet MAC address of the bridge to the specified  one
  or  to  the address of the specified interface.  There were some
  concerns of how this was done in the past, see:  http://bugs.de‐
  bian.org/271406  but  we  are  doing  it  on  a new way now that
  shouldn't be as bad, see: http://bugs.debian.org/725786  however
  you should know what you are doing before using this option.

Reading #725786 also doesn’t make it better. Plus there’s…

   7) #980856  bridge-utils: ignores bridge_hw

… which is also not very trust-inducing.

And indeed, I believe bridge_hw didn’t work right for me ever; on a
virtualisation host, I’m using this:

# The primary network interface
auto br0
iface br0 inet static
bridge_ports em0 rl0
bridge_stp off   
bridge_waitport 5
bridge_fd 0
post-up echo 2048 >/sys/class/net/br0/bridge/hash_max
post-up ifconfig br0 hw ether xx:xx:xx:xx:xx:xx
address 172.2x.xxx.xxx
netmask 255.255.0.0
broadcast 172.2x.255.255
gateway 172.2x.0.1

I believe the reason I needed that ifconfig invocation was
because when adding a device (VM) the bridge address changed
(even if bridge_hw was used!), but I can’t remember whether
that predated the changes mentioned in #725786… nobody in
the bug uses ifconfig, and I’m not used to the ip command still
with some small exceptions.

All in all, I’m…

• not sure this is wise so shortly before the freeze
• unimpressed by bridge_hw, especially given the remarks
  in its documentation
• not sure whether “ifconfig br0 hw ether” is still the best option
• if so, why this is not documented… or even mentioned anywhere…
• which of the various ip commands in that bugreport would work
  (if at all) and in which situations… or when I’d choose that
  instead of ifconfig…

Please clarify, and consider reverting this until after the
bullseye release, so there will be enough time for a *proper*
working solution to be both implemented and documented.


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

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages bridge-utils depends on:
ii  libc6  2.31-9

bridge-utils recommends no packages.

Versions of packages bridge-utils suggests:
ii  ifupdown  0.8.36

-- no debconf information

Bug#981075: reportbug: Simple to-do list with a timer that keeps focus on the task.

[Leandro Ramos]

Package: wnpp
Followup-For: Bug #979275
Owner: Leandro Ramos 
X-Debbugs-Cc: debian-de...@lists.debian.org

Hi. I want to package the program because I have been using it since 2014. I
intend to finish the packaging and look for a sponsor.

Bug#981074: ITP: golang-github-muesli-reflow -- Collection of ANSI-aware methods

[Joao Paulo Lima de Oliveira]

Package: wnpp
Severity: wishlist
Owner: Joao Paulo Lima de Oliveira 
X-Debbugs-Cc: debian-de...@lists.debian.org, jlima.oliveir...@gmail.com

* Package name: golang-github-muesli-reflow
  Version : 0.2.0-1
  Upstream Author : Christian Muehlhaeuser 
* URL : https://github.com/muesli/reflow
* License : MIT
  Programming Lang: Go
  Description : Collection of ANSI-aware methods

 glamour help you to transform blocks of text. This means you can
 still style your terminal output with ANSI escape sequences without
 them affecting the reflow operations & algorithms.

Bug#980803: The examples don't show up in Qt Creator

[Lisandro Damián Nicanor Pérez Meyer]

severity 980803 normal
thanks

Hi!

El vie., 22 ene. 2021 14:23, Limon Kiwi  escribió:

> Package: qtbase5-examples
> Version: 5.15.2+dfsg-2
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> Qt Creator 4.14.0 doesn't show the examples after installing the package
> qtbase5-examples. Trying workarounds that are circulating on the internet
> also don't work, like installing the additional following packages:
> qtbase5-doc-html, qt5-doc and qt5-doc-html.
>

I haven't yet checked this, but for sure it's not a grave bug :-)

Examples are meant to be copied from their installation place into
somewhere a user can modify them if needed. If they don't show un in Qt
creator it's at most a normal bug, so downgrading severity now.

>

Bug#981073: dolphin: Dolphin uses 100% CPU

[Steve Russell]

Package: dolphin
Version: 4:20.12.1-2
Severity: important
X-Debbugs-Cc: steve.russe...@mail.com

Dear Maintainer,

After upgrading from buster to bullseye, Dolphin now uses 100% CPU
whenever it is running.

When I first start Dolphin, the CPU usage is minimal. But after
clicking a few different folders the CPU ramps up to 100% and stays
there regardless of what I do in dolphin. This occurs every time I run
Dolphin. Once the CPU usage hits 100% it never drops. I have left my
machine for a few hours and come back to see dolphin is still using
100% CPU.


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

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

Versions of packages dolphin depends on:
ii  baloo-kf5 5.78.0-2
ii  kinit 5.78.0-2
ii  kio   5.78.0-2
ii  libc6 2.31-9
ii  libdolphinvcs54:20.12.1-2
ii  libkf5activities5 5.78.0-2
ii  libkf5baloo5  5.78.0-2
ii  libkf5baloowidgets5   4:20.12.0-1
ii  libkf5bookmarks5  5.78.0-2
ii  libkf5codecs5 5.78.0-2
ii  libkf5completion5 5.78.0-2
ii  libkf5configcore5 5.78.0-3
ii  libkf5configgui5  5.78.0-3
ii  libkf5configwidgets5  5.78.0-2
ii  libkf5coreaddons5 5.78.0-2
ii  libkf5crash5  5.78.0-3
ii  libkf5dbusaddons5 5.78.0-2
ii  libkf5filemetadata3   5.78.0-2
ii  libkf5i18n5   5.78.0-2
ii  libkf5iconthemes5 5.78.0-2
ii  libkf5itemviews5  5.78.0-2
ii  libkf5jobwidgets5 5.78.0-2
ii  libkf5kcmutils5   5.78.0-3
ii  libkf5kiocore55.78.0-2
ii  libkf5kiofilewidgets5 5.78.0-2
ii  libkf5kiogui5 5.78.0-2
ii  libkf5kiowidgets5 5.78.0-2
ii  libkf5newstuff5   5.78.0-2
ii  libkf5notifications5  5.78.0-2
ii  libkf5parts5  5.78.0-2
ii  libkf5service-bin 5.78.0-2
ii  libkf5service55.78.0-2
ii  libkf5solid5  5.78.0-2
ii  libkf5textwidgets55.78.0-2
ii  libkf5widgetsaddons5  5.78.0-2
ii  libkf5windowsystem5   5.78.0-2
ii  libkf5xmlgui5 5.78.0-2
ii  libkuserfeedbackcore1 1.0.0-3
ii  libkuserfeedbackwidgets1  1.0.0-3
ii  libpackagekitqt5-11.0.2-1
ii  libphonon4qt5-4   4:4.11.1-3
ii  libqt5core5a  5.15.2+dfsg-2
ii  libqt5dbus5   5.15.2+dfsg-2
ii  libqt5gui55.15.2+dfsg-2
ii  libqt5widgets55.15.2+dfsg-2
ii  libqt5xml55.15.2+dfsg-2
ii  libstdc++610.2.1-6
ii  phonon4qt54:4.11.1-3

Versions of packages dolphin recommends:
ii  kimageformat-plugins  5.78.0-4
ii  kio-extras4:20.12.0-1

Versions of packages dolphin suggests:
pn  dolphin-plugins  

-- no debconf information

Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries

[Thorsten Glaser]

Package: qemu-user
Version: 1:5.2+dfsg-3
Followup-For: Bug #970460
X-Debbugs-Cc: t...@mirbsd.de

Hi, what’s the status on this? It is still broken in sid.
Could we please get the fix?


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

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages qemu-user depends on:
ii  libc6 2.31-9
ii  libcapstone4  4.0.2-3
ii  libgcc-s1 10.2.1-6
ii  libglib2.0-0  2.66.4-1
ii  libgnutls30   3.7.0-5
ii  libstdc++610.2.1-6
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages qemu-user recommends:
ii  qemu-user-static [qemu-user-binfmt]  1:5.2+dfsg-3

qemu-user suggests no packages.

-- no debconf information

Bug#978636: move to merged-usr-only?

[Marco d'Itri]

On Jan 25, Simon McVittie  wrote:

> 2. an arrangement where all regular files that have traditionally been
>in /bin, /sbin, /lib and /lib64 are physically located in /usr,
>with /bin etc. becoming "symlink farms" containing symlinks like
>/bin/sh -> /usr/bin/sh, /lib/ld-linux.so.2 -> /usr/lib/ld-linux.so.2
>and so on
>2a. in one version of this, only those files that traditionally
>existed in the rootfs have symlinks, so that /bin/sh -> /usr/bin/sh
>exists but /bin/perl -> /usr/bin/perl does not
>2b. in another version of this, every file in /usr/bin, /usr/sbin,
>/usr/lib is represented in the symlink farm, so that
>/bin/perl -> /usr/bin/perl exists
This would severely reduce the usefulness of sharing /usr between 
different systems (or doing snapshots, etc...), so it would require 
a lot of work for no significant benefits.
Also, as is has been discussed, if the /usr/doc/ transition was 
representative then this would probably take many years.
Also, this would have to deal (in maintainer scripts?) with the fact 
that most systems installed in the last few years have alraedy 
implemented option 1. More complexity for little benefits.
Also, no other distribution considered this.

> I think we should choose wording to vote on such that if we vote yes,
> it is clear which of these layouts are consistent with that resolution,
> and which are not.
This is a good idea.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#981057: network-manager does not verify server certificate name on EAP-TLS WIFI connections

[IB Development Team]

Package: network-manager
Version: 1.14.6-2+deb10u1


network manager configured for EAP-TLS verification in WIFI connection 
config ignores server certificate verifiaction parameters other than CA 
ca-cert.


With example wifi connection config...

[connection]
id=myssid
uuid=----
type=wifi
read-only=TRUE

[wifi]
mode=infrastructure
ssid=myssid

[wifi-security]
key-mgmt=wpa-eap

[802-1x]
ca-cert=/etc/ssl/certs/myca.pem
client-cert=/etc/ssl/client-wifi-cert.pem
eap=tls;
identity=myclient
private-key=/etc/ssl/client-wifi-key.pem
private-key-password=notused
system-ca-certs=false
subject-match=anywrongname
altsubject-matches=DNS:anywrongname
domain-suffix-match=anywrongname

[ipv4]
method=auto

[ipv6]
method=ignore

...network manager connects successfully to AP that use tls server cert with

Subject: CN = myssid
Subject Alternative Name:
DNS:myssid

but it should not because of "match" requirements.

Please verify and consider fixing.

--
Regards,
Paweł Bogusławski

IB Development Team
E: d...@ib.pl

Bug#975693: mirror submission for mirrors.hostico.ro

[Awesome Projects]

  Hello,

modified.


-
  Regards,
  Sebastian Bobriuc

On 1/25/21 8:21 PM, Julien Cristau wrote:

Hi,

On Wed, Nov 25, 2020 at 08:50:16AM +, Awesome Projects wrote:

Submission-Type: new
Site: mirrors.hostico.ro
Type: leaf
Archive-architecture: amd64
Archive-http: /debian/
Maintainer: Awesome Projects 
Country: RO Romania
Location: Bucharest
Sponsor: Hostico https://hostico.ro
Comment: Resubmission as suggested in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959038 .


I was checking some things in the Debian mirror universe and noticed
a problem with your mirror:

o we recommend mirrors not sync directly from service aliases such as
   ftp..debian.org (only http is guaranteed to be available at
   ftp..d.o sites).  Maybe change your config to sync from
   the site currently backing the ftp..debian.org service you sync
   from?

You can use ftp.halifax.rwth-aachen.de instead of ftp2.de.debian.org as
rsync source.

Cheers,
Julien

Bug#980974: apparmor blocks cups backend outgoing network connections

[Brian Potkin]

user pkg-apparmor-t...@lists.alioth.debian.org
usertags #980974 help-needed
thanks



On Sun 24 Jan 2021 at 22:53:00 +, Chris Bainbridge wrote:

> Package: cups
> Version: 2.3.3op1-7
> 
> After upgrading to bullseye, TCP connections from cupsd to localhost
> appeared to be blocked:
> 
> Jan 23 23:39:29 debian audit[2172]: AVC apparmor="DENIED"
> operation="capable" profile="/usr/sbin/cupsd" pid=2172 comm="cupsd"
> capability=12  capname="net_admin"
> Jan 23 23:39:29 debian systemd[1]: Started CUPS Scheduler.
> Jan 23 23:39:29 debian kernel: kauditd_printk_skb: 10 callbacks suppressed
> Jan 23 23:39:29 debian kernel: audit: type=1400 audit(1611445169.589:22):
> apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=2172
> comm="cupsd" capability=12>
> Jan 23 23:39:29 debian systemd[1]: Started Make remote CUPS printers
> available locally.
> Jan 23 23:39:29 debian audit[2174]: AVC apparmor="DENIED"
> operation="capable" profile="/usr/sbin/cups-browsed" pid=2174
> comm="cups-browsed" capability=23  capname="sys_nice"
> 
> I worked around this with `aa-complain cupsd`, `aa-complain cups-browsed`,
> but I would guess that this should work without modifications, unless this
> (TCP connections from cupsd to backend driver) is considered non-standard
> usage?

Triaging this report, Chris, but my knowledge of apparmor is very
limited. However, I have a minimal unstable installation (base
system plus only cups) and can reproduce this behaviour. The last
line (but not the first) disappears when cups-browsed is purged.

Regards,

Brian/

Bug#980785: patch applied upstream

[Ryutaroh Matsumoto]

Control: tags -1 + fixed-upstream

The patch attached to this report was merged upstream (drm-misc-fixes branch)
as
https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/vc4?h=drm-misc-fixes=f6b57101a6b31277a4bde1d8028c46e898bd2ff2
https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/vc4?h=drm-misc-fixes=78e5330329ee206d6aa4593a90320fd837f7966e

This seems to satisfy the condition for Debian kernel patch
at
https://kernel-team.pages.debian.net/kernel-handbook/ch-bugs.html#s9.1.7

> 9.1.7. Applying patches
> Patches should normally be reviewed and accepted by the relevant upstream 
> maintainer
> (aside from necessary adjustments for an older kernel version) before being 
> applied.

Best regards, Ryutaroh Matsumoto

Bug#981070: e2fsprogs: (Possibly) e2fsck sometimes enables ext4 features on ext2 filesystems?

[Christoph Biedl]

Package: e2fsprogs
Version: 1.44.5-1+deb10u3
Severity: normal

Dear Maintainer,

at first, I am sorry to tell I cannot provide the raw data. I was quite
in a hurry and overwrote it before realizing its high value for
debugging.

Story: An ext2 file system, actually a boot partition, suffered severe
damage for whatever reason, possibly controller issues. After massive
repair done by e2fsck (on amd64, from Debian testing), the file system
was clean and usable again (also, no damage to the important files but a
lot of garbage in lost+found), *but* the kernel no longer recognizes it
as ext2:

  EXT4-fs (sdf3): mounted filesystem without journal. Opts: (null)

Expected:

  EXT4-fs (sdf3): mounting ext2 file system using the ext4 subsystem

There are additional message about fscrypt, not anything that was actually used.

  fscrypt (sdf3, inode 41995): Error -61 getting encryption context

Therefore I assume e2fsck, while repairing the damage, by accident
enabled some feature bits that made the kernel think it is dealing with
an ext4. This wouldn't have been a big problem if the bootloader of that
box had ext4 support, but well, it's yaboot on powerpc, dinosaur, dodo,
all that stuff.

As I said, the raw image is destroyed. However I kept the output of
"tune2fs -l" (again, from testing), possibly this provides enough hint
to investigate?

The first ("broken") is from the broken blockdev. It used to work for
many year (note the creation timestamp). The second one ("okay") is
from a newly created file system.

If all this provides enough input to validate my assumption, I'd be
glad to see a fix. If you cannot proceed without looking into the raw
data, well, all we could hope this happens again some day. I wouldn't
hold my breath, though.

Christoph

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

Kernel: Linux 5.10.10 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages e2fsprogs depends on:
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcom-err2  1.44.5-1+deb10u3
ii  libext2fs2   1.44.5-1+deb10u3
ii  libss2   1.44.5-1+deb10u3
ii  libuuid1 2.33.1-0.1

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
ii  e2fsck-static  1.44.5-1+deb10u3
pn  fuse2fs
pn  gpart  
pn  parted 

-- Configuration Files:
/etc/mke2fs.conf changed [not included]

-- no debconf information



signature.asc
Description: PGP signature

Bug#981033: segfault in dtc -I fs

[Héctor Orón Martínez]

Hello,

El dl., 25 de gen. 2021, 18:15, Uwe Kleine-König  va
escriure:

> Package: device-tree-compiler
> Version: 1.4.7-3
> Severity: important
> Tags: upstream, fixed-upstream
> Control: fixed -1 1.5.0-1
>
> Hello,
>

Since 1.6.0 is available via backports and this issue only happens in
stable, is this a common operation that must be fixed in stable?


[...]
> Segmentation fault (core dumped)
>
> The problem was introduced by upstream commit
> 32b9c61307629ac76c6ac0bead6f926d579b3d2c. So v1.4.7 is first release that
> is affected by this bug.
>
> It was fixed upstream by commit
> 9619c8619c37b9aea98100bcc15c51a5642e877e and so v1.5.0 is the first
> fixed commit.
>

Thanks

>

Bug#978636: move to merged-usr-only?

[Adam Borowski]

On Mon, Jan 25, 2021 at 11:45:55AM -0700, Sean Whitton wrote:
> Dear Technical Committee members,
> 
> I call for votes on the following ballot to resolve #978636.  The voting
> period starts immediately and lasts for up to one week, or until the
> outcome is no longer in doubt (§6.3.1).
> 
> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.

You did not even address, or even mention, that this idea has been vetoed by
dpkg maintainers.

And as that, it's a complete non-starter.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `

Bug#971093: closed by Debian FTP Masters (reply to Jonas Meurer ) (Bug#971093: fixed in lazr.config 2.2.2-1)

[Colin Watson]

On Sat, Jan 02, 2021 at 12:24:05AM +, Debian Bug Tracking System wrote:
> Source: lazr.config
> Source-Version: 2.2.2-1
> Done: Jonas Meurer 
[...]
>[ Jonas Meurer ]
>* New upstream release. (Closes: #971093)
>* d/control:
>  - Add myself to Uploaders
>  - Remove Barry Warsaw from Uploaders
>  - Update standards version to 4.5.1, no changes needed.
>* Disable test `test_not_stackable` which fails for python3.9
>  (Closes: #970148)

Thanks for sorting out the immediate issue, but this should really have
been reported upstream for a proper fix.  I've proposed a better fix
just now:

  
https://code.launchpad.net/~cjwatson/lazr.config/zope.interface-5.0.0/+merge/396876

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#979686: mediawiki: Cannot skip installing mariadb & postgresql

[Kunal Mehta]

Hi,

On 1/25/21 2:35 PM, Sunil Mohan Adapa wrote:

I propose a different solution:

What if we add 'sqlite3' into the mix like this: 'default-mysql-server |
virtual-mysql-server | postgresql-contrib | sqlite3'? This way, people
wanting to use sqlite only (including FreedomBox) can run 'apt install
mediawiki php-sqlite3 sqlite3' and get all the other recommends too.
sqlite3 is, strictly speaking, not needed for functioning of MediaWiki
with the sqlite3 DB because the package php-sqlite3 is sufficient.
However, this 1.2MiB package is a (hackish) placeholder to avoid
installing the other databases when installing with recommends. Let me
know if this is acceptable.


I like this idea.

I wonder if we can do:
 default-mysql-server | virtual-mysql-server | postgresql-contrib
 | php-sqlite3

So we're not actually installing anything extra but still get an 
alternative in for sqlite. I don't know if apt will let us have 
php-sqlite3 be in both Depends and Recommends, but I'll give it a try 
and if not use your sqlite3 suggestion.


-- Kunal

Bug#897387: xfslibs-dev needs to include .la files

[Bastian Germann]

Tags: wontfix

On Tue, 1 May 2018 12:03:11 -0700 Matthew Wilcox  
wrote:

Package: xfslibs-dev
Version: 4.15.1-1

trying to build the latest from
git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git

[CC]t_truncate_self
/bin/bash ../libtool --quiet --tag=CC --mode=link gcc t_truncate_self.c -o 
t_truncate_self -g -O2 -g -O2 -DDEBUG  -I../include -DVERSION=\"1.1.1\" 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall 
-DHAVE_FALLOCATE   -lattr /usr/lib/libhandle.la -lacl -lpthread   ../lib/libtest.la
libtool:   error: cannot find the library '/usr/lib/libhandle.la' or unhandled 
argument '/usr/lib/libhandle.la'

I downloaded the debian package of xfslibs-dev, built it, then
manually copied libhandle/libhandle.la into /lib and then I could build
xfstests-dev.


Please see https://wiki.debian.org/ReleaseGoals/LAFileRemoval for a 
reason not to include the .la file. In fact, it is explicitly removed 
during the Debian package build. Most probably, you can configure 
xfstests-dev not to require a libhandle.la file.

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Antoine Le Gonidec]

On Fri, 22 Jan 2021 21:00:52 +0100 Antoine Le Gonidec 
 wrote:

As I am affected too I am going to give it a try, and report the result here.


After a couple days using the packaged 13.5.7-1~fto+1 version of GitLab, I have 
no issue to report. None of the bugs I initially reported are still happening.
Thanks for the good work fixing this ;)



OpenPGP_signature
Description: OpenPGP digital signature

Bug#960454: chromium: Make Chromium ask before downloading and enabling DRM

[Charlemagne Lasse]

Completely disabling the autoupdater was an extremely bad idea. Now
even various autoupdater scripts to update the global version in
/usr/lib/chromium/WidevineCdm don't work anymore - so leaving users in
a broken state.

See also #981069

Bug#981018: pdf-presenter-console: LaTeX demo is not distributed and cannot be composed

[Barak A. Pearlmutter]

> In principle, it's possible to use URL instead of a local file in
> \movie, e.g.,
> .

That's an idea. Maybe as an option, guarded by latex \if tricks,
enabled by default.

> > Of course, they need pdfpc.sty in texlive-latex-extra.
>
> Actually, the demos currently do not need it.

Ah, right. Good point!

Bug#979686: mediawiki: Cannot skip installing mariadb & postgresql

[Sunil Mohan Adapa]

On Mon, 11 Jan 2021 14:51:38 -0800 Kunal Mehta  wrote:
[...]
> 
> The easiest and most foolproof way would be:
> 
> # apt install mediawiki --no-install-recommends

Joseph has proposed a patch to FreedomBox's MediaWiki app to do just
this. However, using --no-install-recommends is leading us to miss out
some nice-to-have packages from the recommends list. php-gmp, for
example, seems to be used on 32-bit machines for GUID generation and for
finding unused blobs. php-wikidiff2 seems to be better at generating
diffs than its built-in fallback.

So, we will need to explicitly install the recommends list to be safe
about not loosing some functionality. The problem with this is the
handling of updates when a newer version of MediaWiki recommends a
different list.

[...]

I propose a different solution:

What if we add 'sqlite3' into the mix like this: 'default-mysql-server |
virtual-mysql-server | postgresql-contrib | sqlite3'? This way, people
wanting to use sqlite only (including FreedomBox) can run 'apt install
mediawiki php-sqlite3 sqlite3' and get all the other recommends too.
sqlite3 is, strictly speaking, not needed for functioning of MediaWiki
with the sqlite3 DB because the package php-sqlite3 is sufficient.
However, this 1.2MiB package is a (hackish) placeholder to avoid
installing the other databases when installing with recommends. Let me
know if this is acceptable.

Thanks,

-- 
Sunil

Bug#981069: chromium: Doesn't load widevine from /usr/lib/chromium/WidevineCdm/

[Charlemagne Lasse]

Package: chromium
Version: 88.0.4324.96-0.1
X-Debbugs-CC: Olivier Tilloy 
X-Debbugs-CC: mimi8 

The changes for ticket #960454 removed the autoupdater for widevine.
And then mentions in the README.debian that
/usr/lib/chromium/WidevineCdm/ is the place to put the widevine
binaries.

But this is not working anymore with this chromium version (but worked
with older versions from May 2020). Also the patch to load it from
$HOME/.local/lib/libwidevinecdm.so doesn't have any effect at all
anymore.

The only file queried for widevine is now
$HOME/.config/chromium/WidevineCdm/latest-component-updated-widevine-cdm

And this definitely makes sense because Debian builds it without
BUNDLE_WIDEVINE_CDM and so the code (AddContentDecryptionModules's
bundled_widevine, ...) is completely disabled - thus disabling
$HOME/.local/lib/libwidevinecdm.so and /usr/lib/chromium/WidevineCdm/

Bug#969597: libzstd: Please correct version in symbol file

[Sebastian Andrzej Siewior]

On 2021-01-25 22:59:08 [+0100], Stephen Kitt wrote:
> Control: severity -1 normal
> 
> Hi Sebastian,
Hi,

> That was no doubt the intention, however in practice the symbol
> visibility wasn’t as expected: looking at the .so build in version
> 1.3.8, common/pool.c includes common/zstd_internal.h which defines
> ZSTD_STATIC_LINKING_ONLY before including zstd.h, and as a result the
> symbols are visible.
> 
> (It’s unfortunate that the build hides the exact commands used, so
> they’re not visible in the build logs, but that’s another issue. Easy
> enough to fix in a local build to see exactly what’s going on...)
> 
> So the cat is out of the bag, and the symbols are present and visible
> in the .so. The symbols file is generated and only reflects the
> reality of what is present in the file (apart from the version numbers
> which are added manually).

I opened the bug because I couldn't use these symbols in Buster's zstd
but had to use bpo instead. rsync is meanwhile available in bpo and
pulls-in the libzstd from bpo which is good.

I have no idea what should be done here to close this properly.

> Regards,
> 
> Stephen

Sebastian

Bug#981068: [arm64] ldconfig segfaults inside a qemu-aarch64-static chroot

[Domenico Andreoli]

Package: libc-bin
Version: 2.31-7

The issue is reproducible inside a arm64 chroot, on a amd64 host,
via qemu-aarch64-static. No problems on a native arm64.

Package upgrade fails with segmentation fault on post-installation,
it's ldconfig:

# dpkg -i libc-bin_2.31-7_arm64.deb
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
(Reading database ... 50524 files and directories currently installed.)
Preparing to unpack libc-bin_2.31-7_arm64.deb ...
Unpacking libc-bin (2.31-7) over (2.31-6) ...
Setting up libc-bin (2.31-7) ...
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
dpkg: error processing package libc-bin (--install):
 installed libc-bin package post-installation script subprocess returned error 
exit status 139
Processing triggers for man-db (2.9.3-2) ...
Errors were encountered while processing:
 libc-bin
#

# ldconfig -v
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
zsh: segmentation fault  ldconfig -v
#

The issue is introduced with --enable-static-pie on -7, downgrading to
-6 or rebuilding -9 without --enable-static-pie makes the problem go away.

qemu writes a coredump but I'm not yet able to make gdb digest it.

Thanks,
Domenico

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05

Bug#981018: pdf-presenter-console: LaTeX demo is not distributed and cannot be composed

[Evgeny Stambulchik]

On 2021-01-25 22:52, Barak A. Pearlmutter wrote:


Issue (a) is absolutely not ideal. I'm considering including them in
/usr/share/doc/pdf-presenter-console/examples/ but fiddling around to
have the Makefile just invoke latexmk, and adding a latexmkrc,


Don't the upstream Makefile's suffice?


and not
including the video files instead having the Makefile download them.
Including the video files seems like overkill.


In principle, it's possible to use URL instead of a local file in 
\movie, e.g., 
. 
Of course, one would need an Internet connection when opening the 
presentation.



Of course, they need pdfpc.sty in texlive-latex-extra.


Actually, the demos currently do not need it. Which is not to say that 
including pdfpc.sty in texlive-latex-extra is wrong, of course :).

Bug#969597: libzstd: Please correct version in symbol file

[Stephen Kitt]

Control: severity -1 normal

Hi Sebastian,

On Sat, Sep 05, 2020 at 09:03:20PM +0200, Sebastian Andrzej Siewior wrote:
> The symbol file records for instance the following symbols:
>   ZSTD_minCLevel
>   ZSTD_compressStream2
> 
> as present in 1.3.8. This isn't entirely correct.  Both symbols were
> present in 1.3.8 but they were hidden behind ZSTD_STATIC_LINKING_ONLY
> and only available for static linking.
> They are available for dynamic linking since 1.4.0, please see commit
>d7d89513d6a21 ("Stabilize advance API")

That was no doubt the intention, however in practice the symbol
visibility wasn’t as expected: looking at the .so build in version
1.3.8, common/pool.c includes common/zstd_internal.h which defines
ZSTD_STATIC_LINKING_ONLY before including zstd.h, and as a result the
symbols are visible.

(It’s unfortunate that the build hides the exact commands used, so
they’re not visible in the build logs, but that’s another issue. Easy
enough to fix in a local build to see exactly what’s going on...)

So the cat is out of the bag, and the symbols are present and visible
in the .so. The symbols file is generated and only reflects the
reality of what is present in the file (apart from the version numbers
which are added manually).

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#976697: #976697: webext-umatrix: no longer developed upstream, remove or switch to LibreMatrix or?

[Vagrant Cascadian]

Control: severity 976697 serious

On 2021-01-25, Vagrant Cascadian wrote:
> The severity was accidentally not set during the original report.

The typo daemons are clearly at work here...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#979993: [Pkg-javascript-devel] Bug#979993: closed by Debian FTP Masters (reply to Jonas Smedegaard ) (Bug#979993: fixed in node-jquery 3.5.1+dfsg+~

[Veiko Aasa]

On Mon, 2021-01-25 at 18:42 +0100, Jonas Smedegaard wrote:
> Quoting Veiko Aasa (2021-01-25 17:25:21)
> > On Mon, 2021-01-25 at 17:17 +0100, Jonas Smedegaard wrote:
> > > Quoting Veiko Aasa (2021-01-25 16:25:11)
> > > > Still I see that jquery files are missing (after upgrading 
> > > > libjs-jquery package).
> > > 
> > > This bug and its fix is tied to exact versions involved in
> > > package 
> > > updates, so it is of little help to only talk about "after
> > > upgrading".
> > > 
> > > Please share the before and after versions of recent upgrades by 
> > > providing the output of this command (all on one line):
> > > 
> > >   sudo grep -hPo 'libjs-jquery:\S*\s*\(\K[^)]*'
> > > /var/log/apt/history.log
> > > 
> > > 
> > >  - Jonas
> > > 
> > 
> > $ sudo grep -hPo 'libjs-jquery:\S*\s*\(\K[^)]*'
> > /var/log/apt/history.log
> > 3.5.1+dfsg+~3.5.4-3, automatic
> > 3.5.1+dfsg+~3.5.4-3, 3.5.1+dfsg+~3.5.5-7
> 
> Thanks.  Unfortunately that wasn't enough - please try this:
> 
>   sudo zgrep -hPo '^Upgrade: .* libjs-jquery:\S*\s*\(\K[^)]*'
> /var/log/apt/history.log* | sort -V
> 
> 
>  - Jonas
> 

$ sudo zgrep -hPo '^Upgrade: .* libjs-jquery:\S*\s*\(\K[^)]*'
/var/log/apt/history.log* | sort -V
3.5.1+dfsg+~3.5.4-3, 3.5.1+dfsg+~3.5.5-7



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

Bug#976697: #976697: webext-umatrix: no longer developed upstream, remove or switch to LibreMatrix or?

[Vagrant Cascadian]

Control: severuty 976697 serious

The severity was accidentally not set during the original report.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#981017: Acknowledgement (whipper: Whipper throws tracebacks)

[Martin Dosch]

Trying to rip a CD (by just setting an offset of "6" which is the one 
that morituri/whipper alwas detected for any of my former CD drives) 
some tracks where ripped successfully but some fail:


INFO:whipper.command.cd:ripping track 16 of 17 (try 2): 16 - Don't Give Up 
(original radio edit).flac
WARNING:whipper.program.cdparanoia:file size 0 did not match expected size 
66027740
WARNING:whipper.program.cdparanoia:non-integral amount of frames difference
Traceback (most recent call last):   
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 197, in getTrackQuality

return min(frames * 2.0 / reads, 1.0)
ZeroDivisionError: float division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/whipper/extern/task/task.py", line 518, 
in c
callable_task(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 
312, in _read
self._done()
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 
388, in _done
self.quality = self._parser.getTrackQuality()
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 
199, in getTrackQuality
raise RuntimeError("cdparanoia couldn't read any frames "
RuntimeError: cdparanoia couldn't read any frames for the current track
INFO:whipper.command.cd:ripping track 16 of 17 (try 3): 16 - Don't Give Up 
(original radio edit).flac
WARNING:whipper.program.cdparanoia:file size 0 did not match expected size 
66027740
WARNING:whipper.program.cdparanoia:non-integral amount of frames difference
Traceback (most recent call last):   
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 197, in getTrackQuality

return min(frames * 2.0 / reads, 1.0)
ZeroDivisionError: float division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/whipper/extern/task/task.py", line 518, 
in c
callable_task(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 
312, in _read
self._done()
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 
388, in _done
self.quality = self._parser.getTrackQuality()
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 
199, in getTrackQuality
raise RuntimeError("cdparanoia couldn't read any frames "
RuntimeError: cdparanoia couldn't read any frames for the current track
INFO:whipper.command.cd:ripping track 16 of 17 (try 4): 16 - Don't Give Up 
(original radio edit).flac
WARNING:whipper.program.cdparanoia:file size 0 did not match expected size 
66027740
WARNING:whipper.program.cdparanoia:non-integral amount of frames difference
Traceback (most recent call last):   
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 197, in getTrackQuality

return min(frames * 2.0 / reads, 1.0)
ZeroDivisionError: float division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/whipper/extern/task/task.py", line 518, 
in c
callable_task(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 
312, in _read
self._done()
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 
388, in _done
self.quality = self._parser.getTrackQuality()
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 
199, in getTrackQuality
raise RuntimeError("cdparanoia couldn't read any frames "
RuntimeError: cdparanoia couldn't read any frames for the current track
INFO:whipper.command.cd:ripping track 16 of 17 (try 5): 16 - Don't Give Up 
(original radio edit).flac
WARNING:whipper.program.cdparanoia:file size 0 did not match expected size 
66027740
WARNING:whipper.program.cdparanoia:non-integral amount of frames difference
Traceback (most recent call last):   
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 197, in getTrackQuality

return min(frames * 2.0 / reads, 1.0)
ZeroDivisionError: float division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/whipper/extern/task/task.py", line 518, 
in c
callable_task(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 
312, in _read
self._done()
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 
388, in _done
self.quality = self._parser.getTrackQuality()
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 
199, in getTrackQuality
raise RuntimeError("cdparanoia couldn't read any frames "
RuntimeError: cdparanoia couldn't read any 

Bug#981025: network-manager-gnome: depends on transitional libgdk-pixbuf2.0-0 package

[Simon McVittie]

On Mon, 25 Jan 2021 at 18:28:30 +0100, Michael Biebl wrote:
> Am 25.01.21 um 18:22 schrieb Martin-Éric Racine:
> > In that case, a massive bin-NMU of GNOME packages might be in order.

You're welcome to ask the release team to binNMU packages that depend on
libgdk-pixbuf2.0-0, but I don't know whether they will be willing to do
so at this stage in the freeze process. This isn't a "real transition"
in the sense that the SONAME being depended on actually changes, but it
does cause a lot of packages to change, and might break non-binNMU-safe
dependencies.

I have no intention of removing libgdk-pixbuf-xlib-2.0-0 or
libgdk-pixbuf2.0-0 before bullseye, and I have no intention of even
*trying* to remove them before binNMUing dependent packages.

These are not "important"-severity bugs: I don't think we can claim that
an unneeded (indirect) dependency on libgdk-pixbuf-xlib-2.0-0 is
"a bug which has a major effect on the usability of a package", when it
doesn't put the package at any realistic risk of being removed.

As noted in devref[1], please check with debian-devel before
mass-bug-filing.

smcv

[1] 
https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.en.html#reporting-lots-of-bugs-at-once-mass-bug-filing

Bug#978079: heads up: rapid-photo-downloader might not make it to bullseye

[Antoine Beaupré]

On 2021-01-25 22:20:38, Dr. Tobias Quathamer wrote:
> Am 25.01.21 um 16:35 schrieb Antoine Beaupré:
>> On 2021-01-24 23:53:20, Damon Lynch wrote:
>>> On Sun, Jan 24, 2021 at 8:44 PM Antoine Beaupré  wrote:
>>>
  Maybe then there is an easy fix to keep RPD in Debian if
 rawkit disappears.


>>> There is no need for any kind of fix in the code itself. Just remove the
>>> mention of rawkit from the Rapid Photo Downloader Debian package. Rapid
>>> Photo Downloader will run without rawkit, without any changes to its code.
>>> If rawkit is present and working, Rapid Photo Downloader will use it. If
>>> rawkit is either not working or not present, Rapid Photo Downloader won't
>>> use it.
>> 
>> This still requires a fix to the Debian package "code" in that the
>> dependency needs to be changed.
>> 
>> Thanks for the clarification!
>
> Hi Antoine and Damon,
>
> I've just taken the time to update RPD to its latest upstream release.
> Also, the dependency on libraw is now downgraded to a recommendation. I
> think that the Debian package of RPD should now be in a good condition
> for the next stable release.
>
> Thanks to both of you for sorting this out and making me aware of the
> situation!

Good job, Tobias, thanks!

Bug#981067: ITP: python-mockito -- Spying framework for Python

[Fabrice BAUZAC-STEHLY]

Package: wnpp
Owner: Fabrice BAUZAC-STEHLY 
Severity: wishlist

* Package name: python-mockito
  Version : 1.2.2
  Upstream Author : Szczepan Faber, Serhiy Oplakanets, Herr Kaste, Justin Hopper
* URL or Web page : https://github.com/kaste/mockito-python
* License : Expat
  Description : Spying framework for Python

--
Fabrice Bauzac-Stehly
PGP 01EEACF8244E9C14B551C5256ADA5F189BD322B6
old PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Bug#978079: heads up: rapid-photo-downloader might not make it to bullseye

[Dr. Tobias Quathamer]

Am 25.01.21 um 16:35 schrieb Antoine Beaupré:
> On 2021-01-24 23:53:20, Damon Lynch wrote:
>> On Sun, Jan 24, 2021 at 8:44 PM Antoine Beaupré  wrote:
>>
>>>  Maybe then there is an easy fix to keep RPD in Debian if
>>> rawkit disappears.
>>>
>>>
>> There is no need for any kind of fix in the code itself. Just remove the
>> mention of rawkit from the Rapid Photo Downloader Debian package. Rapid
>> Photo Downloader will run without rawkit, without any changes to its code.
>> If rawkit is present and working, Rapid Photo Downloader will use it. If
>> rawkit is either not working or not present, Rapid Photo Downloader won't
>> use it.
> 
> This still requires a fix to the Debian package "code" in that the
> dependency needs to be changed.
> 
> Thanks for the clarification!

Hi Antoine and Damon,

I've just taken the time to update RPD to its latest upstream release.
Also, the dependency on libraw is now downgraded to a recommendation. I
think that the Debian package of RPD should now be in a good condition
for the next stable release.

Thanks to both of you for sorting this out and making me aware of the
situation!

Regards,
Tobias



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981066: aerc: Cannot Render HTML Emails After Latest w3m Update in bullseye

[Solya. Reka]

Package: aerc
Version: 0.3.0-2+b1
Severity: important

Dear Maintainer,

After I did a apt upgrade today (which upgraded w3m from 0.5.3+git20210102-1 to 
0.5.3+git20210102-2), I am no longer able to display either plaintext or HTML 
emails. The message viewer simply display a empty screen instead of email 
content.

Yours sincerely
Solya. Reka

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

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/8 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages aerc depends on:
ii  libc62.31-9
ii  libnotmuch5  0.31.3-2

Versions of packages aerc recommends:
ii  dante-client  1.4.2+dfsg-7
ii  w3m   0.5.3+git20210102-2

Versions of packages aerc suggests:
ii  notmuch  0.31.3-2

-- no debconf information

Bug#981065: RFP: gede -- Graphical frontend to GDB

[Johan Henriksson]

Package: wnpp
Severity: wishlist

Gede is a graphical frontend (GUI) to GDB written in C++ and using the Qt5 or 
Qt4 toolkit.

Licensed according to the BSD license.
Downloadable from http://gede.dexar.se.

Files for creating a deb is included in the source.

Bug#978636: move to merged-usr-only?

[Simon McVittie]

On Mon, 25 Jan 2021 at 11:46:35 -0700, Sean Whitton wrote:
> > The Technical Committee resolves that Debian 'bookworm' should support
> > only the merged-usr root filesystem layout, dropping support for the
> > non-merged-usr layout.

Should we be more specific than this in what we vote on, to avoid
later having to adjudicate between developers who say that a particular
implementation is or isn't merged-usr?

Some developers seem to be using "merged /usr" to refer to multiple
concrete layouts:

1. an arrangement where all regular files that have traditionally been
   in /bin, /sbin, /lib and /lib64 are physically located in /usr,
   with symlinks /bin -> usr/bin, /sbin -> usr/sbin, /lib -> usr/lib,
   /lib64 -> usr/lib64
   (this is what usrmerge, debootstrap --merged-usr and Fedora do; dpkg
   maintainer Guillem Jover refers to this as "merged /usr via aliased
   directories" which seems like a good unambiguous term)

2. an arrangement where all regular files that have traditionally been
   in /bin, /sbin, /lib and /lib64 are physically located in /usr,
   with /bin etc. becoming "symlink farms" containing symlinks like
   /bin/sh -> /usr/bin/sh, /lib/ld-linux.so.2 -> /usr/lib/ld-linux.so.2
   and so on
   2a. in one version of this, only those files that traditionally
   existed in the rootfs have symlinks, so that /bin/sh -> /usr/bin/sh
   exists but /bin/perl -> /usr/bin/perl does not
   2b. in another version of this, every file in /usr/bin, /usr/sbin,
   /usr/lib is represented in the symlink farm, so that
   /bin/perl -> /usr/bin/perl exists

I think we should choose wording to vote on such that if we vote yes,
it is clear which of these layouts are consistent with that resolution,
and which are not.

Guillem considers layout 1 to be broken and a mess. I don't agree,
but I'm not a dpkg maintainer. We should be aware that mandating this
implementation is likely to require some overruling.

I don't consider 2a to be merged /usr: it only does half the job of making
the directories in the rootfs equivalent to the directories in /usr.
For example, we would be able to run (for example) /usr/bin/sh scripts
developed on distros that don't distinguish, but not /bin/perl scripts.
However, it does do half the job, and I think Guillem might be considering
2a to be an implementation of the general concept of merged /usr?

I'm not sure whether *I* consider 2b to be merged /usr or not. It makes
the directories on the rootfs exactly equivalent to those in /usr, but
retains a lot of complexity. I would personally be willing to tolerate
that as a stepping-stone to reach layout 1, if the people who do the
work consider it to be less bad than doing the equivalent of usrmerge,
but I don't like it as a post-bullseye end goal in its own right.

If we're voting for layout 1 / status quo / FD, then that could be worded as:

The Technical Committee resolves that Debian 'bookworm' should support
only the "merged-usr via aliased directories" root filesystem layout
in which /bin, /sbin and /lib are symbolic links to the corresponding
directories in /usr, dropping support for the non-merged-usr layout.

Or if we're saying "either 1 or 2b":

The Technical Committee resolves that Debian 'bookworm' should support
only a merged-usr root filesystem layout in which /bin, /sbin and
/lib are either symbolic links to the corresponding files in /usr,
or directories containing such symbolic links, with every file
/usr/bin/foo also available via the path /bin/foo and so on.

Or if we're saying "either 1 or 2a or 2b":

The Technical Committee resolves that Debian 'bookworm' should support
only a merged-usr root filesystem layout in which /bin, /sbin and
/lib are either symbolic links to the corresponding files in /usr,
or directories containing such symbolic links.

(I'm assuming that nobody will try to argue that /lib64, /libx32 and other
libQUAL directories should be treated differently from /lib, even if I
don't explicitly enumerate them.)

Sorry to derail this but I think we should be clear about what we're
resolving.

I think this is consistent with not recommending any particular
implementation of the migration path, which I'm taking to mean we don't
mind how existing unmerged installations reach the desired state - e.g.
if we recommend layout 1, you could get there by installing usrmerge.deb,
or via a special-case in dpkg, or any other mechanism that arrives at
layout 1.

smcv

Bug#599884: speed-dreams

[Fabio Pedretti]

I uploaded the package in my Ubuntu PPA:
https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers/+packages?field.name_filter=speed-dreams

Note that non amd64 builds fail with:
/<>/src/modules/graphic/osggraph/Utils/OsgAtomic.h:51:4:
error: #error
   51 | #  error
  |^

Bug#980965: pdns-recursor: flaky autopkgtest on ppc64el

[Paul Gevers]

Hi

On 24-01-2021 22:31, Chris Hofstaedtler wrote:
> Also: it would be great if I could get email for test failures.

We have RSS feeds on ci.d.n that can be used for that purpose.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980964: pdns: flaky autopkgtest on s390x

[Paul Gevers]

Hi Chris,

On 25-01-2021 09:33, Chris Hofstaedtler wrote:
> * Chris Hofstaedtler  [210125 09:30]:
>> Lets see what the pdns-recursor 4.4.2-4 test run brings.
>   ^^^
> 
> That should have been 4.4.2-3.
> 
>> Paul, can you expedite that test run? Possibly in a way it runs on
>> the problematic worker?
> 
> Actually it already ran, but succeeded. Paul, can you reschedule it
> for the problematic worker?

I don't have easy control over on which worker a job gets run. Unless I
start it manually on the worker, but then there are no logs.

I went ahead and did that anyways, find the data attached.

Paul


pdns-recursor.tar.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#963025: firmware-iwlwifi: Microcode SW error detected / 9000-pu-b0-jf-b0-46.ucode

[Stefan Pietsch]

On 22.01.21 20:48, maximilian attems wrote:

Firmware 9000-pu-b0-jf-b0-46.ucode stops working when used with
hostapd as soon as a wireless client connects.


Is that still happening with latest 5.10 linux and newer
firmware-iwlwifi version >= 202011?



The problem still exists with firmware-iwlwifi 20201218-2.

# cat /proc/version
Linux version 5.10.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-5) 10.2.1 20210108, GNU ld (GNU 
Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.5-1 (2021-01-09)



# dmesg output #


[81668.281626] iwlwifi :00:14.3: Queue 9 is active on fifo 3 and stuck for 1 ms. SW [0, 2] HW [0, 0] FH 
TRB=0x0baef4f74

[81668.281924] iwlwifi :00:14.3: Microcode SW error detected. Restarting 
0x0.
[81668.282306] iwlwifi :00:14.3: Start IWL Error Log Dump:
[81668.282313] iwlwifi :00:14.3: Status: 0x0040, count: 6
[81668.282319] iwlwifi :00:14.3: Loaded firmware version: 46.4d093a30.0 
9000-pu-b0-jf-b0-46.ucode
[81668.282325] iwlwifi :00:14.3: 0x0084 | NMI_INTERRUPT_UNKNOWN
[81668.282330] iwlwifi :00:14.3: 0x22F0 | trm_hw_status0
[81668.282335] iwlwifi :00:14.3: 0x | trm_hw_status1
[81668.282339] iwlwifi :00:14.3: 0x00488876 | branchlink2
[81668.282344] iwlwifi :00:14.3: 0x00478E36 | interruptlink1
[81668.282348] iwlwifi :00:14.3: 0x00478E36 | interruptlink2
[81668.282352] iwlwifi :00:14.3: 0x00011526 | data1
[81668.282356] iwlwifi :00:14.3: 0xFF00 | data2
[81668.282360] iwlwifi :00:14.3: 0xF008 | data3
[81668.282365] iwlwifi :00:14.3: 0x | beacon time
[81668.282369] iwlwifi :00:14.3: 0x00A556BB | tsf low
[81668.282373] iwlwifi :00:14.3: 0x | tsf hi
[81668.282377] iwlwifi :00:14.3: 0x | time gp1
[81668.282381] iwlwifi :00:14.3: 0x00A556BC | time gp2
[81668.282386] iwlwifi :00:14.3: 0x0001 | uCode revision type
[81668.282390] iwlwifi :00:14.3: 0x002E | uCode version major
[81668.282395] iwlwifi :00:14.3: 0x4D093A30 | uCode version minor
[81668.282399] iwlwifi :00:14.3: 0x0312 | hw version
[81668.282403] iwlwifi :00:14.3: 0x18C89008 | board version
[81668.282407] iwlwifi :00:14.3: 0x0049011C | hcmd
[81668.282412] iwlwifi :00:14.3: 0x00022000 | isr0
[81668.282416] iwlwifi :00:14.3: 0x | isr1
[81668.282420] iwlwifi :00:14.3: 0x08001802 | isr2
[81668.282424] iwlwifi :00:14.3: 0x00417CC0 | isr3
[81668.282428] iwlwifi :00:14.3: 0x | isr4
[81668.282433] iwlwifi :00:14.3: 0x00490191 | last cmd Id
[81668.282437] iwlwifi :00:14.3: 0x00011526 | wait_event
[81668.282441] iwlwifi :00:14.3: 0x4208 | l2p_control
[81668.282445] iwlwifi :00:14.3: 0x0020 | l2p_duration
[81668.282450] iwlwifi :00:14.3: 0x033F | l2p_mhvalid
[81668.282454] iwlwifi :00:14.3: 0xA000 | l2p_addr_match
[81668.282458] iwlwifi :00:14.3: 0x000D | lmpm_pmg_sel
[81668.282462] iwlwifi :00:14.3: 0x01102344 | timestamp
[81668.282466] iwlwifi :00:14.3: 0xB0D0 | flow_handler
[81668.282614] iwlwifi :00:14.3: Start IWL Error Log Dump:
[81668.282619] iwlwifi :00:14.3: Status: 0x0040, count: 7
[81668.282624] iwlwifi :00:14.3: 0x2066 | NMI_INTERRUPT_HOST
[81668.282628] iwlwifi :00:14.3: 0x | umac branchlink1
[81668.282633] iwlwifi :00:14.3: 0xC0088BBE | umac branchlink2
[81668.282637] iwlwifi :00:14.3: 0xC0084458 | umac interruptlink1
[81668.282641] iwlwifi :00:14.3: 0xC0084458 | umac interruptlink2
[81668.282646] iwlwifi :00:14.3: 0x0100 | umac data1
[81668.282650] iwlwifi :00:14.3: 0xC0084458 | umac data2
[81668.282654] iwlwifi :00:14.3: 0xDEADBEEF | umac data3
[81668.282658] iwlwifi :00:14.3: 0x002E | umac major
[81668.282662] iwlwifi :00:14.3: 0x4D093A30 | umac minor
[81668.282667] iwlwifi :00:14.3: 0x00A556AA | frame pointer
[81668.282671] iwlwifi :00:14.3: 0xC088627C | stack pointer
[81668.282675] iwlwifi :00:14.3: 0x00490191 | last host cmd
[81668.282679] iwlwifi :00:14.3: 0x | isr status reg
[81668.282699] iwlwifi :00:14.3: Fseq Registers:
[81668.282709] iwlwifi :00:14.3: 0xAF493BFB | FSEQ_ERROR_CODE
[81668.282720] iwlwifi :00:14.3: 0x | FSEQ_TOP_INIT_VERSION
[81668.282730] iwlwifi :00:14.3: 0x58B74E41 | FSEQ_CNVIO_INIT_VERSION
[81668.282740] iwlwifi :00:14.3: 0xA384 | FSEQ_OTP_VERSION
[81668.282751] iwlwifi :00:14.3: 0x7A29D869 | FSEQ_TOP_CONTENT_VERSION
[81668.282761] iwlwifi :00:14.3: 0x46FAB991 | FSEQ_ALIVE_TOKEN
[81668.282771] iwlwifi :00:14.3: 0x901A6683 | FSEQ_CNVI_ID
[81668.282781] iwlwifi :00:14.3: 0xC545CE1C | FSEQ_CNVR_ID
[81668.282792] iwlwifi :00:14.3: 0x01000100 | CNVI_AUX_MISC_CHIP
[81668.282805] iwlwifi :00:14.3: 0x01300202 | CNVR_AUX_MISC_CHIP
[81668.282818] iwlwifi :00:14.3: 0x485B | 
CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[81668.282861] iwlwifi :00:14.3: 0xA5A5A5A2 | 

Bug#981063: offlineimap3: traceback when using "remotepassfile" option

[Vagrant Cascadian]

Control: tags 981063 patch

On 2021-01-25, Vagrant Cascadian wrote:
> When I use the remotepassfile feature, where the specified
> remotepassfile is a single-line plain text file, it fails with a
> traceback.

This attached patch fixes the issue for me. I haven't done extensive
testing for other use-cases, though it only changes the remotepassfile
codepath.

live well,
  vagrant
From d04e63080359b2926a9b8e4582f3387f4e09528c Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 25 Jan 2021 12:46:01 -0800
Subject: [PATCH] Add patch to fix remotepassfile by not encoding into UTF-8.
 (Closes: #981063)

---
 ...ssword-in-UTF-8-when-reading-from-re.patch | 28 +++
 debian/patches/series |  1 +
 2 files changed, 29 insertions(+)
 create mode 100644 debian/patches/0001-Do-not-encode-password-in-UTF-8-when-reading-from-re.patch

diff --git a/debian/patches/0001-Do-not-encode-password-in-UTF-8-when-reading-from-re.patch b/debian/patches/0001-Do-not-encode-password-in-UTF-8-when-reading-from-re.patch
new file mode 100644
index 000..228cee5
--- /dev/null
+++ b/debian/patches/0001-Do-not-encode-password-in-UTF-8-when-reading-from-re.patch
@@ -0,0 +1,28 @@
+From 4f5d97e91e6c0b732120a1c02b6e728068c77e23 Mon Sep 17 00:00:00 2001
+From: Vagrant Cascadian 
+Date: Mon, 25 Jan 2021 12:44:06 -0800
+Subject: [PATCH] Do not encode password in UTF-8 when reading from
+ "remotepassfile".
+
+https://bugs.debian.org/981063
+
+---
+ offlineimap/repository/IMAP.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/offlineimap/repository/IMAP.py b/offlineimap/repository/IMAP.py
+index b732243..6fb7f4a 100644
+--- a/offlineimap/repository/IMAP.py
 b/offlineimap/repository/IMAP.py
+@@ -590,7 +590,7 @@ class IMAPRepository(BaseRepository):
+  encoding='utf-8')
+ password = file_desc.readline().strip()
+ file_desc.close()
+-return password.encode('UTF-8')
++return password
+ # 4. Read password from ~/.netrc.
+ try:
+ netrcentry = netrc.netrc().authenticators(self.gethost())
+-- 
+2.29.2
+
diff --git a/debian/patches/series b/debian/patches/series
index a3648df..c736d39 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 Revert-implement-Happy-Eyeballs.patch
 Do-not-use-the-Internet-to-fetch-DTD.patch
+0001-Do-not-encode-password-in-UTF-8-when-reading-from-re.patch
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#981018: pdf-presenter-console: LaTeX demo is not distributed and cannot be composed

[Barak A. Pearlmutter]

Thanks for the report.

I think there are really two issues here.

(a) the demo/ source directory is not included in the package

(b) you're having trouble LaTeXing the demos

Issue (a) is absolutely not ideal. I'm considering including them in
/usr/share/doc/pdf-presenter-console/examples/ but fiddling around to
have the Makefile just invoke latexmk, and adding a latexmkrc, and not
including the video files instead having the Makefile download them.
Including the video files seems like overkill. Of course, they need
pdfpc.sty in texlive-latex-extra. Maybe the package should Suggest:
them? That seems like overkill. Maybe this stuff should be in a
separate -doc or -demo package? That seems a bit silly. I suppose
adding a check to the Makefile that issues a warning if those packages
are not installed might be the best compromise.

Which brings us to (b). Both the demos work fine for me (using plain
old "latexmk --pdf"). Under debian testing. Do you have
texlive-latex-extra installed? If so, please install latexmk and send
a full transcript of

$ cd demo
$ latexmk --pdf -gg pdfpc-demo.tex
$ cd pdfpc-video-example
$ latexmk --pdf -gg video-example.tex

and I'll see if I can diagnose the problem.

Bug#940625: diskcache: ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found

[Andreas Tille]

On Mon, Jan 25, 2021 at 12:45:08PM -0500, Sandro Tosi wrote:
> and that's because
> https://github.com/grantjenks/python-diskcache/blob/master/tox.ini is
> not included in the pypi package (and, independently, the reason i
> start packaging tarballs from github, it's just easier than getting
> half baked pypi tarballs).

I injected a new tarball drained from Github.  It seems to need lots of
not yet packaged - I have no idea how to cope with this.
 
Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#980766: Acknowledgement (fetchmail: Loaded OpenSSL library 0x1010104f newer than headers 0x1010101f, trying to continue.)

[Matthias Andree]

+ László

Am 22.01.21 um 21:46 schrieb Erich Wälde:
> Hello,
>
> I found the problem:
>
> The fetchmail config said "tls1" instead of "tls1+", and
> apparently the email hoster enforces tls1.2 now.
> Which is good.
>
> So this bug may be closed.
> Sorry for the noise.
>
> Erich
>
Erich,

Glad you've got that sorted, however this looks like an instance of

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928916

which was apparently only fixed in 6.4.0~rc1-1.

This patch fixed the issue at the time:

https://gitlab.com/fetchmail/fetchmail/blob/080d4632298636a9a1b21c3419c059b95fb3cd37/socket.c#L1225

and it added some code to trap the error and print

    Server shut down connection prematurely during SSL_connect().

gcs@ please see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928916#43 and #53.

Regards,
Matthias

Bug#981064: ITP: xrprof -- External sampling profiler for R

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: xrprof
  Version : 0.3.1
  Upstream Author : Aaron Jacobs
* URL or Web page : https://github.com/atheriel/xrprof
* License : GPL-2
  Description : External sampling profiler for R

This (still fairly small) tool permits profiling of R code alongside with
compiled code extensions to R which sets it apart from other profiling
solution from R (though Google perftools can help).

Dirk

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

Bug#981007: systemd: default syscall-filter list is incomplete for i386 and breaks tar

[Michael Biebl]

Am 25.01.21 um 18:23 schrieb Michael Biebl:

Am 25.01.21 um 15:49 schrieb Raphaël Hertzog:

But it would still be nice if this could be fixed via a point release.


Good timing. I was about to prepare a pu request for buster 10.8 and we 
could include this one as well.

Do you have a minimal test case?



Or to put it differently: Have you verified that PR#13975 fixes the 
issue you are seeing?


Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#904098: Timidity is blocking alsa plughw

[ael]

After a little further investigation, I found that timidity
was being started by systemd by falling back to /etc/rc*.d/ SYSV
files.

Note that I had removed timidity-daemon, but I did not purge
the package. As a result, it seems that timidity was being
started:

# systemctl list-units "timidity*"
  UNIT LOAD   ACTIVE SUB DESCRIPTION
  timidity.service loaded active running LSB: start and stop timidity

So if you have had timidity-daemon installed at some point, then
be sure to purge the package.

I see that timidity "Suggests" timidity-daemon, although it is not
needed in desktop installations. I imagine that it how it got installed
here some years ago.

The other issue is why timidity is locking out other sound applications
from using plughw:. Perhaps that would be reasonable when
timidity is actively playing sound, although I think most sound
aplications are not so antisocial. I have not looked at that aspect so
far.

Bug#979993: [Pkg-javascript-devel] Bug#979993: closed by Debian FTP Masters (reply to Jonas Smedegaard ) (Bug#979993: fixed in node-jquery 3.5.1+dfsg+~

[Veiko Aasa]

On Mon, 2021-01-25 at 17:17 +0100, Jonas Smedegaard wrote:
> Quoting Veiko Aasa (2021-01-25 16:25:11)
> > Still I see that jquery files are missing (after upgrading 
> > libjs-jquery package).
> 
> This bug and its fix is tied to exact versions involved in package 
> updates, so it is of little help to only talk about "after upgrading".
> 
> Please share the before and after versions of recent upgrades by 
> providing the output of this command (all on one line):
> 
>   sudo grep -hPo 'libjs-jquery:\S*\s*\(\K[^)]*'
> /var/log/apt/history.log
> 
> 
>  - Jonas
> 

$ sudo grep -hPo 'libjs-jquery:\S*\s*\(\K[^)]*' /var/log/apt/history.log
3.5.1+dfsg+~3.5.4-3, automatic
3.5.1+dfsg+~3.5.4-3, 3.5.1+dfsg+~3.5.5-7



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

Bug#981017: whipper: Whipper throws tracebacks

[Martin Dosch]

Package: whipper
Version: 0.9.0-4+b1
Severity: normal

Dear Maintainer,

I connected my newly bought external USB CD drive to my laptop and wanted to
determine the offset to be able to rip CDs to my laptop.
Whipper throws a lot of tracebacks when trying to determine the offset and
eventually I aborted the process as I'm not sure I'll get
any meaningful results if there are so many errors:

whipper offset find:(
INFO:whipper.command.offset:checking device /dev/sr0
Track 1 finished, found 67 Q sub-channels with CRC errors
Track 2 finished, found 30 Q sub-channels with CRC errors
Track 3 finished, found 50 Q sub-channels with CRC errors
Track 4 finished, found 32 Q sub-channels with CRC errors
Track 5 finished, found 74 Q sub-channels with CRC errors
Track 6 finished, found 58 Q sub-channels with CRC errors
Track 7 finished, found 60 Q sub-channels with CRC errors
Track 8 finished, found 43 Q sub-channels with CRC errors
Track 9 finished, found 103 Q sub-channels with CRC errors
Track 10 finished, found 113 Q sub-channels with CRC errors
Track 11 finished, found 82 Q sub-channels with CRC errors
Track 12 finished, found 51 Q sub-channels with CRC errors
Track 13 finished, found 104 Q sub-channels with CRC errors
Track 14 finished, found 79 Q sub-channels with CRC errors
Track 15 finished, found 130 Q sub-channels with CRC errors
INFO:whipper.command.offset:trying read offset 6...
INFO:whipper.command.offset:trying read offset 667...
WARNING:whipper.program.cdparanoia:file size 0 did not match expected size
37831964
WARNING:whipper.program.cdparanoia:non-integral amount of frames difference
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line
197, in getTrackQuality
return min(frames * 2.0 / reads, 1.0)
ZeroDivisionError: float division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/whipper/extern/task/task.py", line 518,
in c
callable_task(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line
312, in _read
self._done()
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line
388, in _done
self.quality = self._parser.getTrackQuality()
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line
199, in getTrackQuality
raise RuntimeError("cdparanoia couldn't read any frames "
RuntimeError: cdparanoia couldn't read any frames for the current track
WARNING:whipper.command.offset:unknown task exception for offset 667:
(RuntimeError("cdparanoia couldn't read any frames for the current track"),
'exception RuntimeError at /usr/lib/python3/dist-
packages/whipper/program/cdparanoia.py:199: getTrackQuality(): cdparanoia
couldn\'t read any frames for the current track\nTraceback (most recent call
last):\n  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py",
line 197, in getTrackQuality\nreturn min(frames * 2.0 / reads,
1.0)\nZeroDivisionError: float division by zero\n\nDuring handling of the above
exception, another exception occurred:\n\nTraceback (most recent call last):\n
File "/usr/lib/python3/dist-packages/whipper/extern/task/task.py", line 518, in
c\ncallable_task(*args, **kwargs)\n  File "/usr/lib/python3/dist-
packages/whipper/program/cdparanoia.py", line 312, in _read\nself._done()\n
File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 388,
in _done\nself.quality = self._parser.getTrackQuality()\n  File
"/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line 199, in
getTrackQuality\nraise RuntimeError("cdparanoia couldn\'t read any frames
"\nRuntimeError: cdparanoia couldn\'t read any frames for the current track\n')
WARNING:whipper.command.offset:cannot rip with offset 667...
INFO:whipper.command.offset:trying read offset 48...
INFO:whipper.command.offset:trying read offset 102...
INFO:whipper.command.offset:trying read offset 12...
INFO:whipper.command.offset:trying read offset 30...
INFO:whipper.command.offset:trying read offset 103...
INFO:whipper.command.offset:trying read offset 618...
WARNING:whipper.program.cdparanoia:file size 0 did not match expected size
37831964
WARNING:whipper.program.cdparanoia:non-integral amount of frames difference
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line
197, in getTrackQuality
return min(frames * 2.0 / reads, 1.0)
ZeroDivisionError: float division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/whipper/extern/task/task.py", line 518,
in c
callable_task(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/whipper/program/cdparanoia.py", line
312, in _read
self._done()
  File 

Bug#981004: Cannot configure IUCODE_TOOL_SCANCPUS=no before installation

[Trent W. Buck]

Thanks for the prompt reply; discussion follows.

Henrique de Moraes Holschuh wrote:
> On Tue, 26 Jan 2021, Trent W. Buck wrote:
>> A minimum recipe to reproduce this is:
>>
>> $ mmdebstrap sid sid.tar.zst \
>>   --components='main contrib non-free' \
>>   --include=intel-microcode \
>>   --essential-hook='>$1/etc/default/intel-microcode echo 
>> IUCODE_TOOL_INITRAMFS=yes IUCODE_TOOL_SCANCPUS=no' \
>>   --verbose
>> [...]
>> Setting up intel-microcode (3.20201118.1) ...
>>
>> Configuration file '/etc/default/intel-microcode'
>>  ==> File on system created by you or by a script.
>>  ==> File also in package provided by package maintainer.
>>What would you like to do about it ?  Your options are:
>> Y or I  : install the package maintainer's version
>> N or O  : keep your currently-installed version
>>   D : show the differences between the versions
>>   Z : start a shell to examine the situation
>>  The default action is to keep your current version.
>
> That is a DPKG prompt, about a changed "conffile".  You need to tell
> dpkg what it should do when it detects that a "conffile" has been
> changed [prior to installation of a package].  Keep in mind dpkg also
> prompts for this when a package upgrade changes a conffile that has been
> locally modified.
>
>> ALLEGEDLY when DEBIAN_FRONTEND=noninteractive (which mmdebstrap does),
>> that prompt should not appear, and method [A] should Just Work.
>
> dpkg is not debconf (which responds to DEBIAN_FRONTEND), it is far more
> low-level / basic.
>
>> I can't see anything in /var/lib/dpkg/info/*microcode*inst that
>> looks relevant, so maybe this is a dpkg issue?
>
> It is an issue on how mmdebstrap and other such utilities interact with
> dpkg and user-modified conffiles, yes.  And it affects every package
> that uses conffiles.

Thanks, I did not realize DEBIAN_FRONTEND= only affected debconf.

> Your options are in the dpkg manpage, and I don't know how you'd tell
> mmdebstrap how to specify them.

OK, I think you are referring to --force-{confold,confnew,confdef}.

If I add force-confold to /etc/dpkg.cfg.d/blah it does indeed bypass this 
issue.[0]

(force-confold feels a bit brute-force -- since there's only a single
"apt-get install" call, it applies to everything -- but I guess it's
no worse than DEBIAN_FRONTEND=noninteractive.)

I'll move this over to the mmdebstrap package so the mmdebstrap
maintainer can set dpkg force-confXXX next to
DEBIAN_FRONTEND=noninteractive --- or at least document the issue in
the mmdebstrap manpage.

(Maybe this is already documented for debootstrap in
installation-guide-amd64 and I just never found it?)


[0]

twb@not-omega:~$ mmdebstrap sid sid.tar.zst --components='main contrib 
non-free' --include=amd64-microcode 
'--essential-hook=>$1/etc/default/amd64-microcode echo 
AMD64UCODE_INITRAMFS=yes' --verbose --dpkgopt=force-confold 
--customize-hook='cat $1/etc/default/amd64-microcode'
[...]
I: running --essential-hook in shell: sh -c 
'>$1/etc/default/amd64-microcode echo AMD64UCODE_INITRAMFS=yes' exec 
/tmp/mmdebstrap._D0TIGFL66
[...]
Setting up amd64-microcode (3.20191218.1) ...

Configuration file '/etc/default/amd64-microcode'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
 ==> Using current old file as you requested.
[...]
I: running --customize-hook in shell: sh -c 'cat 
$1/etc/default/amd64-microcode' exec /tmp/mmdebstrap._D0TIGFL66
AMD64UCODE_INITRAMFS=yes
[...]
I: success in 36.8867 seconds

Bug#981063: offlineimap3: traceback when using "remotepassfile" option

[Vagrant Cascadian]

Package: offlineimap3
Version: 0.0~git20210105.00d395b+dfsg-2
Severity: important
X-Debbugs-Cc: Vagrant Cascadian 

Thanks for the work porting and maintaining offlineimap for python3!


When I use the remotepassfile feature, where the specified
remotepassfile is a single-line plain text file, it fails with a
traceback.

If I use the default ui interface and comment out the remotepassfile
option for that account, it works fine.


  $ offlineimap -u quiet -q -a ACCOUNT
  ERROR: While attempting to sync account 'ACCOUNT'
sequence item 2: expected str instance, bytes found
  ERROR: Exceptions occurred during the run!
  ERROR: While attempting to sync account 'ACCOUNT'
sequence item 2: expected str instance, bytes found
  
  Traceback:
File "/usr/share/offlineimap3/offlineimap/accounts.py", line 298, in
syncrunner
  self.__sync()
File "/usr/share/offlineimap3/offlineimap/accounts.py", line 374, in
__sync
  remoterepos.getfolders()
File "/usr/share/offlineimap3/offlineimap/repository/IMAP.py", line
648, in getfolders
  imapobj = self.imapserver.acquireconnection()
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 592, in
acquireconnection
  self.__authn_helper(imapobj)
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 449, in
__authn_helper
  if func(imapobj):
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 375, in
__authn_plain
  imapobj.authenticate('PLAIN', self.__plainhandler)
File "/usr/lib/python3/dist-packages/imaplib2.py", line 691, in
authenticate
  typ, dat = self._simple_command('AUTHENTICATE', mechanism.upper())
File "/usr/lib/python3/dist-packages/imaplib2.py", line 1684, in
_simple_command
  return self._command_complete(self._command(name, *args), kw)
File "/usr/lib/python3/dist-packages/imaplib2.py", line 1404, in
_command
  literal = literator(data, rqb)
File "/usr/lib/python3/dist-packages/imaplib2.py", line 2247, in
process
  ret = self.mech(self.decode(data))
File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 217, in
__plainhandler
  retval = NULL.join((authz, authc, passwd))


live well,
  vagrant

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (12, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, arm64

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

Versions of packages offlineimap3 depends on:
ii  python3   3.9.1-1
ii  python3-distro1.5.0-1
ii  python3-imaplib2  2.57-5.2

offlineimap3 recommends no packages.

offlineimap3 suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Sebastian Andrzej Siewior]

On 2021-01-25 19:57:18 [+0100], Cyril Brulebois wrote:
> Not really *much* easier, to be honest. I can definitely build a package
> locally given a source debdiff, or slightly better, given a source
> package I can run dget against (since we're talking about new upstream
> releases, by the looks of it), and do whatever testing with the
> generated packages built into d-i and/or fetched from the network as
> required (similarly to what's done for the various kernel udebs).
> 
> IOW that can be tested before even having to make a decision regarding a
> possible acceptance into p-u.

in case it helps, I uploaded
  https://breakpoint.cc/openssl-pu.tar

| $ sha512sum openssl-pu.tar 
| 
1a3df2e37aa9312a378046691794bf7d7d72570ed9ade7ffbf50f87c8c8a7dd5e671a7f704fc4f1ebdbada1dda3007a5db24b426deefd33fff39b81e7be38aa3
  openssl-pu.tar

containing the source package and amd64 packages.

> Cheers,

Sebastian


signature.asc
Description: PGP signature

Bug#981062: RFS: swami/2.2.2-1 -- MIDI instrument editor application

[Dennis Braun]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name    : swami
   Version : 2..2.2-1
   Upstream Author : Joshua Element Green 
 * URL : https://github.com/swami/swami
 * License : GPL-2+, LGPL-2, GPL-2, CC0-1.0
 * Vcs : https://salsa.debian.org/multimedia-team/swami
   Section : sound

It builds those binary packages:

  libswami-dev - MIDI instrument editor - development files
  libswamigui1 - MIDI instrument editor - shared GUI library
  libswami1 - MIDI instrument editor - shared library
  swami - MIDI instrument editor application

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


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

It needs the latest version of libinstpatch (1.1.6), which you can find 
here:


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/swami/swami_2.2.2-1.dsc


Changes since the last upload:

 swami (2.2.2-1) unstable; urgency=medium
 .
   * New upstream version 2.2.2
   * Bump S-V to 4.5.1
   * Bump libinstpatch-dev B-D version to 1.1.6
   * Bump d/copyright year
   * Update the symbols files with new functions
   * Remove unnecessary LDFLAGS from d/rules
   * Refresh patch

Regards,
Dennis

Bug#981057: [Pkg-utopia-maintainers] Bug#981057: network-manager does not verify server certificate name on EAP-TLS WIFI connections

[Michael Biebl]

Am 25.01.21 um 20:20 schrieb IB Development Team:


Please verify and consider fixing.



I have no setup to verify this so it would be best if you file this 
directly upstream as this doesn't seem to be a downstream issue.





OpenPGP_signature
Description: OpenPGP digital signature

Bug#980902: [R-pkg-team] Bug#980902: r-cran-tmb: prints warning when rmatrix is upgraded

[Dirk Eddelbuettel]

On 25 January 2021 at 21:39, Graham Inggs wrote:
| Thanks again for your input on this issue!
 
Always a pleasure :)

Best, Dirk

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

Bug#981010: rxvt-unicode: urxvt segfaults at exit

[Ryan Kavanagh]

Control: tags -1 + moreinfo unreproducible

Hi Christian,

I can't reproduce this using an empty urxvt configuration. Could you
please share whatever resources you've set?

$ xrdb -query | grep -i rxvt

Thanks,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#981061: src:iwyu: fails to migrate to testing for too long: FTBFS everywhere except amd64/i386

[Paul Gevers]

Source: iwyu
Version: 8.0-4
Severity: serious
Control: close -1 8.15-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 976486

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:iwyu in its
current version in unstable has been trying to migrate for 60 days [2].
Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=iwyu




OpenPGP_signature
Description: OpenPGP digital signature