Bug#986027: Fwd: [Bug 1706594] 100% CPU usage on WebExtensions process

2021-11-02 Thread Paul Wise
On Tue, 12 Oct 2021 14:43:38 +0200 Erich Schubert wrote:

> A fix is scheduled for Firefox 95 apparently.

Since this issue also affects Firefox ESR,
a backport to Firefox ESR 91 would be nice.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#998361: pam FTBFS

2021-11-02 Thread Helmut Grohne
Control: tags -1 + patch

On Tue, Nov 02, 2021 at 10:11:40PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> our CI runs for the DPKG_ROOT tests failed today because pam FTBFS. I
> rebuilt pam locally in a fresh sbuild chroot without any modifications
> and arrived at the same build failure. I attached the log. I also put
> the error message at the end of this mail. Some investigation suggests
> that for some reason PAM_USERTYPE_UIDMIN is set to the empty string by
> configure. Also interestingly I was not able to reproduce this problem
> by building the package outside of a chroot nor when building it under
> mmdebstrap. The problem only shows when building it inside an sbuild
> chroot. I thus suspect that it will also FTBFS on the buildds and mark
> this bug as serious.

I think this should be reproducible elsewhere. rebootstrap encounters
it. It's a behaviour change in dash:

if test x == x; then echo I am no longer executed with the new version; fi

In any case, using == is never worked on dash. The attached patch fixes
that bashism.

Helmut
--- pam-1.4.0.orig/configure.ac
+++ pam-1.4.0/configure.ac
@@ -658,19 +658,19 @@
 dnl Get values for default uid ranges in login.defs used in pam_usertype
 dnl
 AC_ARG_WITH([uidmin], AS_HELP_STRING([--with-uidmin=],[default value for regular user min uid (1000)]), opt_uidmin=$withval)
-if test x"$opt_uidmin" == x; then
+if test x"$opt_uidmin" = x; then
 opt_uidmin=1000
 fi
 AC_DEFINE_UNQUOTED(PAM_USERTYPE_UIDMIN, $opt_uidmin, [Minimum regular user uid.])
 
 AC_ARG_WITH([sysuidmin], AS_HELP_STRING([--with-sysuidmin=],[default value for system user min uid (101)]), opt_sysuidmin=$withval)
-if test x"$opt_sysuidmin" == x; then
+if test x"$opt_sysuidmin" = x; then
 opt_sysuidmin=101
 fi
 AC_DEFINE_UNQUOTED(PAM_USERTYPE_SYSUIDMIN, $opt_sysuidmin, [Minimum system user uid.])
 
 AC_ARG_WITH([kerneloverflowuid], AS_HELP_STRING([--with-kernel-overflow-uid=],[kernel overflow uid, default (uint16_t)-2=65534]), opt_kerneloverflowuid=$withval)
-if test x"$opt_kerneloverflowuid" == x; then
+if test x"$opt_kerneloverflowuid" = x; then
 opt_kerneloverflowuid=65534
 fi
 AC_DEFINE_UNQUOTED(PAM_USERTYPE_OVERFLOW_UID, $opt_kerneloverflowuid, [Kernel overflow uid.])


Bug#995392: ghostscript: ps2pdf trashes some characters

2021-11-02 Thread Vincent Lefevre
On 2021-11-03 03:29:43 +0100, Vincent Lefevre wrote:
> On 2021-11-02 16:25:27 +0100, Vincent Lefevre wrote:
> > With commit 8f62213019bc682eeb0ed9467d8841f3770cfda6 upstream,
> > I can no longer reproduce any issue, even when
> > /usr/share/texlive/texmf-dist/tex/generic/pdftex/glyphtounicode.tex
> > from Tex Live 2020 is included and \pdfgentounicode=1 is used.
> 
> Hmm... I didn't check carefully. On one of my files, there is
> actually one place where the quoteright (used for the apostrophe)
> is replaced by "Š" (checked with pdftotext, xpdf and atril). The
> cause may be that the paragraph in question is in a smaller font.

I have an explanation: it seems that in this smaller font,
no ligatures (ff, ffi, fl...) are used.

In a recent fix, Ghostscript no longer generates a ToUnicode CMap
when there are \pdfglyphtounicode with more than 2 bytes (such as
those used for the ligatures). So this fix made the bug disappear
when ligatures are used. Bug the bug was still there, and visible
when ligatures are not used.

> So the issue is still visible in practice.
> 
> I'll try to produce a simple testcase.

Here is it:

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\pdfglyphtounicode{Scaron}{0160}
\pdfgentounicode=1
\begin{document}
\thispagestyle{empty}
'ê
\end{document}

(Tested on the PDF generated by pdflatex from TeX Live 2020.)

My new upstream bug report:

  https://bugs.ghostscript.com/show_bug.cgi?id=704681

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



Bug#998371: gnome resets and start from login when typing two random letters in search bar

2021-11-02 Thread Claudio
Package: gnome
Version: 1:3.30+1
Severity: important
Tags: a11y

Dear Maintainer,

When I type 2 letters in the search bar of apps gnome closes all the windows
and my user session and start from login. It happens frequently but not all the
time and not with the same letters, sometimes is with "st", "te", "rs", "te" or
a combination of those.



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

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

Versions of packages gnome depends on:
ii  avahi-daemon 0.7-4+deb10u1
ii  cheese   3.31.90-1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 10.0.2
ii  evolution3.30.5-1.1
ii  evolution-plugins3.30.5-1.1
ii  file-roller  3.30.1-2+deb10u1
ii  gedit-plugins3.30.1-3
ii  gnome-calendar   3.30.1-2
ii  gnome-clocks 3.30.1-2
ii  gnome-color-manager  3.30.0-2
ii  gnome-core   1:3.30+1
ii  gnome-documents  3.31.92-1
ii  gnome-getting-started-docs   3.30.0-1
ii  gnome-maps   3.30.3.1-0+deb10u1
ii  gnome-music  3.30.2-1
ii  gnome-screenshot 3.30.0-2
ii  gnome-sound-recorder 3.28.2-2~deb10u1
ii  gnome-todo   3.28.1-2
ii  gnome-tweaks 3.30.2-1
ii  gnome-weather3.26.0-6~deb10u1
ii  gstreamer1.0-libav   1.15.0.1+git20180723+db823502-2+deb10u1
ii  gstreamer1.0-plugins-ugly1.14.4-1+deb10u1
ii  libgsf-bin   1.14.45-1
ii  libproxy1-plugin-networkmanager  0.4.15-5+deb10u1
ii  libreoffice-calc 1:6.1.5-3+deb10u7
ii  libreoffice-gnome1:6.1.5-3+deb10u7
ii  libreoffice-impress  1:6.1.5-3+deb10u7
ii  libreoffice-writer   1:6.1.5-3+deb10u7
ii  nautilus-sendto  3.8.6-3
ii  network-manager-gnome1.8.20-1.1
ii  orca 3.30.1-1
ii  rhythmbox3.4.3-2
ii  rhythmbox-plugin-cdrecorder  3.4.3-2
ii  rhythmbox-plugins3.4.3-2
ii  rygel-playbin0.36.2-4
ii  rygel-tracker0.36.2-4
ii  seahorse 3.30.1.1-1
ii  shotwell 0.30.1-1
ii  simple-scan  3.30.1.1-1+b1
ii  totem-plugins3.30.0-4
ii  vinagre  3.22.0-6
ii  vino 3.22.0-5
ii  xdg-user-dirs-gtk0.10-3

Versions of packages gnome recommends:
ii  gnome-games 1:3.30+1
ii  nautilus-extension-brasero  3.12.2-5
ii  transmission-gtk2.94-2+deb10u2

Versions of packages gnome suggests:
pn  alacarte 
pn  empathy  
pn  firefox-esr-l10n-all | firefox-l10n-all  
pn  gnome-remote-desktop 
pn  goobox | sound-juicer
pn  polari   
pn  webext-ublock-origin 

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.30.1-1
ii  at-spi2-core  2.30.0-7
ii  baobab3.30.0-2
ii  caribou   0.4.21-7
ii  chromium  90.0.4430.212-1~deb10u1
ii  dconf-cli 0.30.1-2
ii  dconf-gsettings-backend   0.30.1-2
ii  eog   3.28.4-2+b1
ii  evince3.30.2-3+deb10u1
ii  evolution-data-server 3.30.5-1+deb10u1
ii  firefox-esr   78.15.0esr-1~deb10u1
ii  fonts-cantarell   0.111-2
ii  gdm3  3.30.2-3
ii  gedit 3.30.2-2
ii  gkbd-capplet  3.26.1-1
ii  glib-networking   2.58.0-2+deb10u2
ii  gnome-backgrounds 3.30.0-1
ii  gnome-bluetooth   3.28.2-4~deb10u1
ii  gnome-calculator  3.30.1-2
ii  gnome-characters  3.30.0-2
ii  gnome-contacts3.30.2-1
ii  gnome-control-center  1:3.30.3-2~deb10u1
ii  gnome-disk-utility3.30.2-3
ii  gnome-font-viewer 3.30.0-2
ii  gnome-keyring 3.28.2-5
ii  gnome-logs3.30.0-2
ii  gnome-menus   3.31.4-3
ii  gnome-online-accounts 3.30.1-2
ii  gnome-online-miners   3.30.0-2
ii  gnome-session 3.30.1-2
ii  gnome-settings-daemon 3.30.2-3
ii  gnome-shell   3.30.2-11~deb10u2
ii  

Bug#998370: ITP: qt6-svg -- Qt 6 SVG module

2021-11-02 Thread Patrick Franz
Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: qt6-svg
  Version : 6.2.0
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : LGPL-3 or GPL-2+
  Programming Lang: C++
  Description : Qt 6 SVG module

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

This package contains classes for displaying the contents of SVG files.



Bug#995894: Acknowledgement (linux-image-5.10.0-8-amd64: Debian Bullseye: hard freeze on AMD GPU when turned on monitor)

2021-11-02 Thread piorunz

Caught it again today. Same Debian Bullseye with latest updates, same
hardware.

I logged in via ssh to find Xorg dead, killing it didn't changed
anything. Killed sddm too, no change. Tried to "sudo reboot", no
reaction. Had to use SysRq key combination to kill Linux.

dmesg:

[22780.068010] general protection fault, probably for non-canonical
address 0x100:  [#1] SMP NOPTI
[22780.068014] CPU: 12 PID: 1368 Comm: Xorg Not tainted 5.10.0-9-amd64
#1 Debian 5.10.70-1
[22780.068015] Hardware name: ASUS System Product Name/PRIME B550-PLUS,
BIOS 2423 08/09/2021
[22780.068066] RIP: 0010:dc_plane_state_retain+0x11/0x40 [amdgpu]
[22780.068067] Code: 5d 4c 89 e0 41 5c 41 5d 41 5e c3 45 31 e4 eb bc 66
0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 4c 8d 87 90 03 00 00 b8 01 00 00
00  0f c1 87 90 03 00 00 85 c0 74 15 78 06 83 c0 01 78 01 c3 be 01
[22780.068068] RSP: 0018:c07001f5fbe0 EFLAGS: 00010206
[22780.068070] RAX: 0001 RBX: 9f48d3d58840 RCX:

[22780.068070] RDX: 0dc0 RSI: 9f48d3d59dd8 RDI:
0100
[22780.068071] RBP: 9f4be0b9a800 R08: 01000390 R09:
9f48d3d58840
[22780.068071] R10:  R11:  R12:
9f48d3d59d40
[22780.068072] R13: 9f48d3d58840 R14: 9f484250cc00 R15:
9f4740df1000
[22780.068073] FS:  7f5a81bffa40() GS:9f562ed0()
knlGS:
[22780.068074] CS:  0010 DS:  ES:  CR0: 80050033
[22780.068074] CR2: 7f2090737000 CR3: 000103b92000 CR4:
00750ee0
[22780.068075] PKRU: 5554
[22780.068075] Call Trace:
[22780.068126]  dm_drm_plane_duplicate_state+0x5a/0x90 [amdgpu]
[22780.068137]  drm_atomic_get_plane_state+0x90/0x160 [drm]
[22780.068145]  __drm_atomic_helper_set_config+0x55/0x320 [drm]
[22780.068150]  drm_atomic_helper_set_config+0x32/0xb0 [drm_kms_helper]
[22780.068157]  drm_mode_setcrtc+0x1d3/0x6f0 [drm]
[22780.068160]  ? tomoyo_init_request_info+0x8f/0xb0
[22780.068162]  ? tomoyo_path_number_perm+0x66/0x1d0
[22780.068168]  ? drm_mode_getcrtc+0x180/0x180 [drm]
[22780.068173]  drm_ioctl_kernel+0xaa/0xf0 [drm]
[22780.068180]  drm_ioctl+0x220/0x3c0 [drm]
[22780.068185]  ? drm_mode_getcrtc+0x180/0x180 [drm]
[22780.068216]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[22780.068219]  __x64_sys_ioctl+0x83/0xb0
[22780.068222]  do_syscall_64+0x33/0x80
[22780.068224]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[22780.068225] RIP: 0033:0x7f5a8206acc7
[22780.068226] Code: 00 00 00 48 8b 05 c9 91 0c 00 64 c7 00 26 00 00 00
48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 99 91 0c 00 f7 d8 64 89 01 48
[22780.068227] RSP: 002b:7fff36ff32d8 EFLAGS: 0246 ORIG_RAX:
0010
[22780.068228] RAX: ffda RBX: 7fff36ff3310 RCX:
7f5a8206acc7
[22780.068228] RDX: 7fff36ff3310 RSI: c06864a2 RDI:
000f
[22780.068229] RBP: c06864a2 R08:  R09:

[22780.068229] R10:  R11: 0246 R12:
555f6130d220
[22780.068230] R13: 000f R14:  R15:
555f619212e0
[22780.068231] Modules linked in: snd_seq_dummy snd_seq snd_seq_device
sr_mod cdrom uas usb_storage xt_state macvlan bnep xt_CHECKSUM
xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp
nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 nft_counter nf_tables nfnetlink bridge stp llc bluetooth
jitterentropy_rng drbg ansi_cprng ecdh_generic ecc crc16 binfmt_misc
snd_hda_codec_realtek snd_hda_codec_generic amd64_edac_mod ledtrig_audio
edac_mce_amd snd_hda_codec_hdmi kvm_amd snd_hda_intel nls_ascii
snd_intel_dspcfg soundwire_intel nls_cp437 soundwire_generic_allocation
vfat fat kvm snd_soc_core irqbypass snd_compress soundwire_cadence
ghash_clmulni_intel uvcvideo snd_hda_codec videobuf2_vmalloc
videobuf2_memops videobuf2_v4l2 snd_hda_core videobuf2_common
aesni_intel snd_hwdep eeepc_wmi videodev libaes soundwire_bus asus_wmi
crypto_simd cryptd snd_pcm battery glue_helper sparse_keymap mc
cdc_ether rfkill snd_timer usbnet rapl snd video mii wmi_bmof efi_pstore
[22780.068258]  sp5100_tco soundcore joydev pcspkr k10temp watchdog ccp
sg tpm_crb tpm_tis tpm_tis_core tpm evdev acpi_cpufreq rng_core
parport_pc ppdev lp parport fuse configfs sunrpc efivarfs ip_tables
x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov
async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c
crc32c_generic raid1 raid0 multipath linear md_mod hid_generic usbhid
hid sd_mod amdgpu gpu_sched i2c_algo_bit ttm drm_kms_helper xhci_pci cec
ahci xhci_hcd libahci nvme libata drm nvme_core r8169 usbcore t10_pi
realtek mdio_devres crc_t10dif crc32_pclmul crc32c_intel scsi_mod libphy
crct10dif_generic i2c_piix4 crct10dif_pclmul usb_common crct10dif_common
wmi gpio_amdpt gpio_generic button
[22780.068283] ---[ end trace a5f7bf6383af10af ]---
[22780.206479] RIP: 

Bug#995392: ghostscript: ps2pdf trashes some characters

2021-11-02 Thread Vincent Lefevre
Control: tags -1 - fixed-upstream

On 2021-11-02 16:25:27 +0100, Vincent Lefevre wrote:
> With commit 8f62213019bc682eeb0ed9467d8841f3770cfda6 upstream,
> I can no longer reproduce any issue, even when
> /usr/share/texlive/texmf-dist/tex/generic/pdftex/glyphtounicode.tex
> from Tex Live 2020 is included and \pdfgentounicode=1 is used.

Hmm... I didn't check carefully. On one of my files, there is
actually one place where the quoteright (used for the apostrophe)
is replaced by "Š" (checked with pdftotext, xpdf and atril). The
cause may be that the paragraph in question is in a smaller font.
So the issue is still visible in practice.

I'll try to produce a simple testcase.

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



Bug#998368: pulseaudio: Pulseaudio disabling auto-mute mode

2021-11-02 Thread Gert van de Kraats

Package: pulseaudio
Version: 15.0+dfsg1-2
Severity: normal
Tags: upstream

Dear Maintainer,

Recently I installed new updates, including pulseaudio:

2021-10-19 23:32:51 upgrade pulseaudio:i386 14.2-2 15.0+dfsg1-2
2021-10-19 23:47:37 status installed pulseaudio:i386 15.0+dfsg1-2

After these update(s) the internal speaker of the laptop is not going
automatically to mute,
if the headphone is plugged in.

If I enable auto-mute, the internal speaker is going to mute, as wished.

As soon as I remove the headphone-plug,
auto-mute is immediately disabled  at alsamixer.

If I plug-in the headphone again, the internal speaker is not going to 
mute, as

wished.

File /usr/share/pulseaudio/alsa-mixer/paths/speaker.conf contains the next
extra lines,
if I compare with version 14.2.2 :

; Make sure the internal speakers are not auto-muted once the system has
speakers
[Element Auto-Mute Mode]
enumeration = select

[Option Auto-Mute Mode:Disabled]
name = analog-output-speaker


If I comment out these lines, auto-mute is not disabled anymore by 
pulseaudio,

and Auto-Mute works as designed.

Probably this "fix" is coming from
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/433/diffs?commit_id=19e34d8d5bb9380ed70607b3f661c26df6d4836c 


.
 It is a strange "fix" . because it completely destroys the 
functionality of

Auto-Mute.

I reported about almost the same problem at Bullseye Testing at February 
2021

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



My laptop is a simple DELL D620, without any additional audiocard.
If the internal speakers can not become  mute independent of the headphone
it cannot be used anymore at video-conference and at a shared office.


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 5.14.0-2-686-pae (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.5.1-1
ii  libasound2-plugins   1.2.5-2
ii  libc6    2.32-4
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-3
ii  libfftw3-single3 3.3.8-2
ii  libgcc-s1    11.2.0-10
ii  libglib2.0-0 2.70.0-3
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse0    15.0+dfsg1-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.31-2
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   11.2.0-10
ii  libsystemd0  249.5-1
ii  libtdb1  1.4.3-1+b1
ii  libudev1 249.5-1
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb1  1.14-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 15.0+dfsg1-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session    1.12.20-3
ii  libpam-systemd [logind]  249.5-1
ii  rtkit    0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  5.0-2
pn  pavumeter    
ii  udev 249.5-1

-- no debconf information

--===0103428592==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="client.conf"

# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as 
published by

# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or 
# for

## commenting.

; default-sink =

Bug#998200: transition: bibutils

2021-11-02 Thread Sebastian Ramacher
Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-bibutils.html

On 2021-10-31 22:32:05, Pierre Gruet wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> I am preparing the transition from libbibutils7 to libbibutils8, which is in 
> experimental and builds well.
> This change is needed as the ABI has encountered many changes by upstream.

Please go ahead

Cheers

> 
> Ben file:
> 
> title = "bibutils";
> is_affected = .depends ~ "libbibutils7" | .depends ~ "libbibutils8";
> is_good = .depends ~ "libbibutils8";
> is_bad = .depends ~ "libbibutils7";
> 
> The auto-transitioner page [1] is fine.
> 
> Here are the results of the test builds of the 5 reverse dependencies:
> 
> * bibutils  build OK in experimental (same source package 
> as libbibutils8)
> * haskell-hs-bibutils   build OK, binNMU needed for the dependencies 
> list of libghc-hs-bibutils-dev
> * haskell-pandoc-citeproc   build OK
> * haskell-blogliteratelybuild OK
> * haskell-hakyllbuild OK
> 
> Best regards,
> Pierre
> 
> [1] https://release.debian.org/transitions/html/auto-bibutils.html
> 

-- 
Sebastian Ramacher



Bug#997929: transition: yaml-cpp

2021-11-02 Thread Sebastian Ramacher
On 2021-11-03 00:26:07, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> 
> On 2021-10-29 00:24:37, Adrian Bunk wrote:
> > On Thu, Oct 28, 2021 at 09:50:10PM +0200, Sebastian Ramacher wrote:
> > > Control: forwarded -1 
> > > https://release.debian.org/transitions/html/auto-yaml-cpp.html
> > > 
> > > On 2021-10-27 05:05:57 -0500, Simon Quigley wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > > Usertags: transition
> > > > 
> > > > Dear Release Team,
> > > > 
> > > > I would like to upload yaml-cpp 0.7.0 to unstable which includes an ABI 
> > > > bump
> > > > and a package name change (libyaml-cpp0.6 -> libyaml-cpp0.7). It has 
> > > > already
> > > > been uploaded to Experimental and cleared NEW. Since the package now 
> > > > depends
> > > > on googletest instead of including its own embedded copy, the package 
> > > > now
> > > > builds on less architectures.
> > > 
> > > Are builds on releases acrchitectures affected by this change?
> > 
> > sh4 (in ports) is the only affected Linux architecture:
> > https://buildd.debian.org/status/package.php?p=yaml-cpp=experimental
> 
> Please go ahead

… but please without the Breaks+Replaces on the old binary packages.
They are unnecessary

Cheers
-- 
Sebastian Ramacher



Bug#998367: perlcritic: "Code not tidy' after perltidy

2021-11-02 Thread Felix Lechner
Package: libperl-critic-perl
Severity: normal

Hi,

Perlcritic does not appear to use the latest version of perltidy, or
perhaps invokes it with different settings. In unstable, perlcritic
complains that files are not tidy even though perltidy just ran over
them.

Due to the large number of contributors to Lintian, Lintian's
testsuite enforces a project-wide style in Salsa CI (but not in Deb
CI). Your help would be very much appreciated.

I also mentioned it briefly on the Perl team's mailing list [1] but
have not received any replies yet. Thanks!

Kind regards
Felix Lechner

[1] https://lists.debian.org/debian-perl/2021/10/msg00025.html

* * *

Seen in Lintian on unstable:

root@6b71b0282ea8:~/lintian# perlcritic lib/Lintian/Index/Item.pm
lib/Lintian/Index/Item.pm:1:1:Code is not tidy

root@6b71b0282ea8:~/lintian# perltidy -b lib/Lintian/Index/Item.pm

root@6b71b0282ea8:~/lintian# perlcritic lib/Lintian/Index/Item.pm
lib/Lintian/Index/Item.pm:1:1:Code is not tidy



Bug#998169: transition: unixodbc

2021-11-02 Thread Sebastian Ramacher
Control: tags -1 moreinfo
Control: https://release.debian.org/transitions/html/auto-unixodbc.html

On 2021-10-31 22:30:26, Hugh McMaster wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Due to various changes, unixodbc's libraries, libodbc, libodbccr and libodbccr
> have a new soversion.

Why do the binary packages have Breaks + Replaces on binary packages
with the old SONAME?

Cheers

> 
> Test results after rebuilding all reverse dependencies and reverse-build
> dependencies:
> 
> The following packages FTBFS for reasons unrelated to unixodbc:
>   * asterisk; see #997136
>   * libghc-hdbc-odbc-dev (src:hdbc-odbc); not in testing
>   * libmyodbc (src:myodbc); not in testing
>   * pike8.0-odbc (src:pike8.0); not in testing
>   * w1retap-odbc (src:w1retap); not in testing
> 
> tdbcodbc will require a source or NMU upload; see #997057, where the 
> maintainer
> says he will take care of this.
> 
> grass, vtk7, mysql-workbench and saga all require rebuilds once gdal is
> rebuilt.
> 
> 
> Ben file:
> 
> title = "unixodbc";
> is_affected = .depends ~ "libodbc1" | .depends ~ "odbcinst1debian2" | .depends
> ~ "libodbc2" | .depends ~ "libodbccr2" | .depends ~ "libodbcinst2";
> is_good = .depends ~ "libodbc2" | .depends ~ "libodbccr2" | .depends ~
> "libodbcinst2";
> is_bad = .depends ~ "libodbc1" | .depends ~ "odbcinst1debian2";
> 

-- 
Sebastian Ramacher



Bug#998088: why bugs involving systemd are so hard to get fixed ...

2021-11-02 Thread Ron
On Tue, 02 Nov 2021 15:34:01 +0100 Michael Biebl  wrote:
> I tried to explain this to Ron on IRC, but he decided to ignore my advice.

Oh Please Michael, now you're just sounding like a child whose lolly has
fallen in the dirt ...

I did run the issue with (some) socket units and circular dependencies
past #systemd hoping for some sensible analysis of the problem, but all
I got was the same penchant to just sweep it under the nearest handy
rug.  What you seem to call "advice" was the same as here, just an
apparently willful effort to completely ignore everything I actually
wrote about the (several) problems here, and instead invent your own
problem that fit the answers in your standard divert blame kit ...

If you genuinely want to help here, actually read what I wrote, and
actually address the problems which should be very clear from the
analysis I wrote of it (or if they are not, I'll gladly clarify).

None of what I reported for libvirt or ifupdown are problems which
depend the bit-babbler udev rules to occur.  A quick search will find
you many people whose systems fell into the same holes these problems
create.  The problem space that each is separately subject to is created
in the domain of those packages.  There is no "one problem with one
quick answer" here (unless you count how easy it appears to still be
for people to accidentally create problems with systemd units, but I'm
not ranting about that, I'm trying to get concrete instances fixed).

I'm not going to give a long list of links here because I'm not
interested in rolling in the mud with you, I'm interested in making
packages I use a lot as robust and bug free as possible.  Except I
will highlight https://bugs.debian.org/899002 ...  In which you
showed the same complete lack of understanding of the problem - and
amusingly even argued *against* the very change to ifupdown, which
I've pointed out the one small rough edge that needs polishing, that
you now have flipped your position to say "Is perfect, don't touch it".

So can we please stop this side-show and actually look at the bugs
which I *did* report, not the invented one which I didn't ...

  Thanks,
  Ron



Bug#997929: transition: yaml-cpp

2021-11-02 Thread Sebastian Ramacher
Control: tags -1 confirmed

On 2021-10-29 00:24:37, Adrian Bunk wrote:
> On Thu, Oct 28, 2021 at 09:50:10PM +0200, Sebastian Ramacher wrote:
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/auto-yaml-cpp.html
> > 
> > On 2021-10-27 05:05:57 -0500, Simon Quigley wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > 
> > > Dear Release Team,
> > > 
> > > I would like to upload yaml-cpp 0.7.0 to unstable which includes an ABI 
> > > bump
> > > and a package name change (libyaml-cpp0.6 -> libyaml-cpp0.7). It has 
> > > already
> > > been uploaded to Experimental and cleared NEW. Since the package now 
> > > depends
> > > on googletest instead of including its own embedded copy, the package now
> > > builds on less architectures.
> > 
> > Are builds on releases acrchitectures affected by this change?
> 
> sh4 (in ports) is the only affected Linux architecture:
> https://buildd.debian.org/status/package.php?p=yaml-cpp=experimental

Please go ahead

Cheers
-- 
Sebastian Ramacher



Bug#998366: Please update golang-github-blang-semver: 3.5.1-1 to new version

2021-11-02 Thread Diane Trout
Source: golang-github-blang-semver
Version: 3.5.1-1
Severity: wishlist

Dear Maintainer,

I was attempting to build a new singularity-container package and it wanted a
v4 version of
golang-github-blang-semver.

"../vendor/github.com/sylabs/scs-library-client/client/version.go:12:2: cannot
find package "github.com/blang/semver/v4" in any of:"

It looks like upstream has the original API in the base directory and a "v4"
API in a subdirectory.

Thanks,
Diane Trout


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500,
'oldstable-debug'), (500, 'testing'), (500, 'stable'), (110, 'unstable'), (100,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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



Bug#998365: libstdc++-arm-none-eabi-newlib: Version of libstdc++-arm-none-eabi-newlib and gcc-arm-none-eabi must match or the C++ libraries can't be found

2021-11-02 Thread David Given
Ah, I've just spotted (via the automatically reported bug data...) that
there is such a constraint but it's only at a Recommends level. I think
this should be upgraded to a Depends.

On Tue, 2 Nov 2021 at 23:57, David Given  wrote:

> Package: libstdc++-arm-none-eabi-newlib
> Version: 15:8-2019-q3-1+13
> Severity: important
> X-Debbugs-Cc: d...@cowlark.com
>
> Dear Maintainer,
>
> Currently the testing/unstable version of gcc-arm-none-eabi is
> 15:10.3-2021.07-2 (a.k.a. 10.3.1) and the version of
> libstdc++-arm-none-eabi-
> newlib is 15:8-2019-q3-1+13 (a.k.a. 8.3.1).
>
> The problem is that gcc looks for the newlib include files using the
> compiler
> internal version, which makes newlib unusable --- the compiler is looking
> for
> /usr/include/newlib/c++/10.3.1 and failing to find the files in
> /usr/include/newlib/c++/8.3.1.
>
> The solution for me was to downgrade gcc to the same version as newlib,
> which
> lets it find the library, but that's not very satisfactory. As it stands
> newlib
> is unusable on testing or unstable systems.
>
> I would suggest adding a constraint to newlib to ensure that the version of
> gcc-arm-none-eabi is the same as that of libstdc++-arm-none-eabi-newlib.
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers oldoldstable
>   APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'),
> (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages libstdc++-arm-none-eabi-newlib depends on:
> ii  libnewlib-arm-none-eabi  3.3.0-1
> ii  libnewlib-dev3.3.0-1
>
> Versions of packages libstdc++-arm-none-eabi-newlib recommends:
> ii  binutils-arm-none-eabi  2.37-7+15
> ii  gcc-arm-none-eabi   15:8-2019-q3-1+b1
>
> libstdc++-arm-none-eabi-newlib suggests no packages.
>
> -- no debconf information
>


Bug#998310: mpd: fails to start with "Assertion `sockets.empty()' failed."

2021-11-02 Thread Benjamin Francois
On Tue, 2 Nov 2021 13:53:20 +0100 Max Kellermann wrote:
> TLDR: it's complicated, and we can't see the real error just yet.

Hello! I am having the same issue so I thought I'd give it a go.
❯ sudo gdb --args mpd --stderr --no-daemon --verbose
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from mpd...
(No debugging symbols found in mpd)
(gdb) catch throw
Catchpoint 1 (throw)
(gdb) run
Starting program: /usr/bin/mpd --stderr --no-daemon --verbose
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
config_file: loading file /etc/mpd.conf
path: SetFSCharset: fs charset is
libsamplerate: libsamplerate converter 'Fastest Sinc Interpolator'
vorbis: Xiph.Org libVorbis 1.3.7
opus: libopus 1.3.1
sndfile: libsndfile-1.0.31
adplug: adplug 2.3.3
simple_db: reading DB

Catchpoint 1 (exception thrown), 0x736a6322 in __cxa_throw () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0 0x736a6322 in __cxa_throw () at /lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x5559e71f in ()
#2 0x5565fa6c in ()
#3 0x55660721 in ()
#4 0x555a4aed in ()
#5 0x555a4d4d in ()
#6 0x555a302a in ()
#7 0x732dde4a in __libc_start_main (main=
0x555a3010, argc=4, argv=0x7fffe5f8, init=, 
fini=, rtld_fini=, stack_end=0x7fffe5e8) at 
../csu/libc-start.c:314
#8 0x555a33da in ()
(gdb) cont
Continuing.
exception: Tag list mismatch, discarding database file
curl: version 7.74.0
curl: with GnuTLS/3.7.2

Catchpoint 1 (exception thrown), 0x736a6322 in __cxa_throw () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0 0x736a6322 in __cxa_throw () at /lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x5558ba6e in ()
#2 0x555a44ed in ()
#3 0x555a4d4d in ()
#4 0x555a302a in ()
#5 0x732dde4a in __libc_start_main (main=
0x555a3010, argc=4, argv=0x7fffe5f8, init=, 
fini=, rtld_fini=, stack_end=0x7fffe5e8) at 
../csu/libc-start.c:314
#6 0x555a33da in ()
(gdb) cont
Continuing.
mpd: ../src/event/Loop.cxx:60: EventLoop::~EventLoop(): Assertion 
`sockets.empty()' failed.

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1 0x732dc536 in __GI_abort () at abort.c:79
#2 0x732dc41f in __assert_fail_base
(fmt=0x734436b0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
assertion=0x5569afa2 "sockets.empty()", file=0x5569af5c 
"../src/event/Loop.cxx", line=60, function=) at assert.c:92
#3 0x732eb7f2 in __GI___assert_fail
(assertion=0x5569afa2 "sockets.empty()", file=0x5569af5c 
"../src/event/Loop.cxx", line=60, function=0x5569af44 
"EventLoop::~EventLoop()") at assert.c:101
#4 0x555e5458 in ()
#5 0x555b7c56 in ()
#6 0x555867a1 in ()
#7 0x555a4d4d in ()
#8 0x555a302a in ()
#9 0x732dde4a in __libc_start_main (main=
0x555a3010, argc=4, argv=0x7fffe5f8, init=, 
fini=, rtld_fini=, stack_end=0x7fffe5e8) at 
../csu/libc-start.c:314
#10 0x555a33da in ()
(gdb) cont
Continuing.

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb)

Hope this helps!
Cheers,
Ben.



Bug#998358: Subject: grepmail: autopkgtest doesn't do anything

2021-11-02 Thread Eriberto
Thanks a lot Paul.

Really, in our machines the package is built and Makefile  exists. I
need to check some packages of mine. I think there are some tests
around grepmail in upstream source. However, don't worry because this
upload was a first work. Now, Marcos will package the new upstream
release and he will fix this mistake. In a final action, he will send
a SPU to fix a specific issue.

Regards,

Eriberto



Bug#998365: libstdc++-arm-none-eabi-newlib: Version of libstdc++-arm-none-eabi-newlib and gcc-arm-none-eabi must match or the C++ libraries can't be found

2021-11-02 Thread David Given
Package: libstdc++-arm-none-eabi-newlib
Version: 15:8-2019-q3-1+13
Severity: important
X-Debbugs-Cc: d...@cowlark.com

Dear Maintainer,

Currently the testing/unstable version of gcc-arm-none-eabi is
15:10.3-2021.07-2 (a.k.a. 10.3.1) and the version of libstdc++-arm-none-eabi-
newlib is 15:8-2019-q3-1+13 (a.k.a. 8.3.1).

The problem is that gcc looks for the newlib include files using the compiler
internal version, which makes newlib unusable --- the compiler is looking for
/usr/include/newlib/c++/10.3.1 and failing to find the files in
/usr/include/newlib/c++/8.3.1.

The solution for me was to downgrade gcc to the same version as newlib, which
lets it find the library, but that's not very satisfactory. As it stands newlib
is unusable on testing or unstable systems.

I would suggest adding a constraint to newlib to ensure that the version of
gcc-arm-none-eabi is the same as that of libstdc++-arm-none-eabi-newlib.


-- System Information:
Debian Release: bookworm/sid
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libstdc++-arm-none-eabi-newlib depends on:
ii  libnewlib-arm-none-eabi  3.3.0-1
ii  libnewlib-dev3.3.0-1

Versions of packages libstdc++-arm-none-eabi-newlib recommends:
ii  binutils-arm-none-eabi  2.37-7+15
ii  gcc-arm-none-eabi   15:8-2019-q3-1+b1

libstdc++-arm-none-eabi-newlib suggests no packages.

-- no debconf information



Bug#998347: librust-bindgen+env-logger-dev: uninstallable - depends on non-existing package librust-env-logger-0.7+default-dev

2021-11-02 Thread Ximin Luo
Source: rust-bindgen
Followup-For: Bug #998347

That is not how rust Debian packaging works; your patch will get lost with the
next upload of the autogenerated package.

If you want your patch to not get lost, do it via the normal process:

https://salsa.debian.org/rust-team/debcargo-conf/

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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



Bug#998156: contains non-DFSG-free files

2021-11-02 Thread Matthew Fluet
Henry is correct that the MLton compiler (the runtime, basis library
implementation, and compiler proper) do not depend on ckit (or any of the
(re)distributed SML/NJ libraries), the benchmarks, or on mlnlffigen, nor
are those components required for using MLton (unless, of course, the
program being compiled explicitly references them).  If Debian wants to
carve up the packages for MLton in a different way, then that seems fine,
but I'm not inclined to do serious rearrangements of the GitHub repository
or of the source releases that we (upstream) package.  I appreciate the
licensing issue, but consider it fairly low stakes for decades old code.

Florian is correct that MLton has packaged mlnlffigen both out of
convenience (as we have packaged mllex and mlyacc) for users and because
MLton requires the tool to generate slightly different code.


On Mon, Nov 1, 2021 at 3:55 PM Henry Cejtin  wrote:

> Your right, but I think (not on the basis of real knowledge) that
> ml-nlffigen isn't used in either the compilation
> of the MLton compiler, nor by the MLton compiler in compiling user
> code.  I thought that it was
> for a MLton compiler user to use, and had been tweaked so that the
> output was usable by MLton.
>
> I certainly could be wrong about this.
>


Bug#997772: python-cogent: FTBFS: You must configure the bibtex_bibfiles setting

2021-11-02 Thread Stuart Prescott
Hi Andreas

> > > Extension error:
> > > You must configure the bibtex_bibfiles setting
> > > make[2]: *** [Makefile:40: html] Error 2

this is sphinxcontrib-bibtex saying that you need to add the following to 
doc/conf.py:

bibtex_bibfiles = "path/to/references.bib"

However I can't see a .bib file anywhere in the source. I also can't see any 
code in the rst files or the docstrings that would actually use sphinxcontrib-
bibtex so I'm not sure how this extension is actually used in these documents. 
Perhaps it isn't actually needed at all.

cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7



Bug#998364: ruby-async-rspec: autopkgtest failures on armhf and i386

2021-11-02 Thread Sebastian Ramacher
Source: ruby-async-rspec
Version: 1.16.1-2
Severity: serious

ruby-async-rspec is unable to migrate to testing due to autopkgtest
failures on armhf and i386:

Failures:

| 1) RSpec::Memory on supported platform should not exceed specified size limit
|Failure/Error:
|  expect do
|   "a" * 100_000
|  end.to limit_allocations.of(String, size: 100_001)
|
|  exceeded allocation limit: allocated 2 String instances, 99961 bytes, 
expected exactly 11 bytes

See 
https://ci.debian.net/data/autopkgtest/testing/i386/r/ruby-async-rspec/16143499/log.gz

Cheers
-- 
Sebastian Ramacher



Bug#998363: certbot: Too many flags setting configurators/installers/authenticators

2021-11-02 Thread Kingsley G. Morse Jr.
Package: certbot
Version: 1.18.0-1
Severity: normal

Dear Maintainer,

Thank you very much for generously sharing your
time and skill.


It's not a crisis, but I humbly suggest improving
a certain error message to lead users to faster
fixes.

When I do

root$ certbot certonly --apache --manual --dry-run 

certbot complains with

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Too many flags setting configurators/installers/authenticators 'apache' -> 
'manual'
Ask for help or search for solutions at https://community.letsencrypt.org. 
See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v 
for more details.

The fix appears to be

root$ certbot certonly -i apache -a manual --dry-run


Maybe certbot's error message could be improved from

Too many flags setting configurators/installers/authenticators 'apache' -> 
'manual'

to something more helpful like

Try rep[acing "--apache --manual" with "-i apache -a manual".


So it is said.

So it is done.

Reporting bugs may be fun, but

thanking maintainers is number one!

Thanks,
Kingsley


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

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages certbot depends on:
ii  cdebconf [debconf-2.0]  0.253
ii  debconf [debconf-2.0]   1.5.74
ii  python3-certbot 1.18.0-1
pn  python3:any 

certbot recommends no packages.

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

-- Configuration Files:
/etc/letsencrypt/cli.ini changed [not included]

-- debconf information excluded



Bug#997166: libcdio: FTBFS: cdda-player.c:301:28: error: format not a string literal and no format arguments [-Werror=format-security]

2021-11-02 Thread Rocky Bernstein
That link is the correct one. I was comparing to
https://sources.debian.org/patches/libcdio/2.1.0-2/ncursesw.diff/  which is
different so I may have this wrong.

On Tue, Nov 2, 2021 at 5:47 PM Gabriel F. T. Gomes <
gabr...@inconstante.net.br> wrote:

> Hi, Rocky,
>
> On Tue, 2 Nov 2021 13:11:07 -0400
> Rocky Bernstein  wrote:
> >
> > Hmm - as best as I can tell this patches things a little differently than
> > what was done in the git codebase.
>
> That was not my intention.
>
> Actually, I don't understand why you say that.
>
> The patch that I backported to Debian is the one you mentioned in a
> previous message, i.e.:
>
> https://savannah.gnu.org/patch/index.php?10130
>
> What did I get wrong?
>
> Cheers,
> Gabriel
>


Bug#998362: rss2email: AttributeError: module 'feedparser' has no attribute 'zlib'

2021-11-02 Thread Jakub Wilk

Package: rss2email
Version: 1:3.12.2-2

I got this after upgrading python3-feedparser to 6.0.8-1:

   Traceback (most recent call last):
 File "/usr/bin/r2e", line 5, in 
   rss2email.main.run()
 File "/usr/lib/python3/dist-packages/rss2email/main.py", line 186, in run
   args.func(feeds=feeds, args=args)
 File "/usr/lib/python3/dist-packages/rss2email/command.py", line 90, in run
   feed.run(send=args.send)
 File "/usr/lib/python3/dist-packages/rss2email/feed.py", line 912, in run
   for (guid, state, sender, message) in self._process(parsed):
 File "/usr/lib/python3/dist-packages/rss2email/feed.py", line 381, in 
_process
   self._check_for_errors(parsed)
 File "/usr/lib/python3/dist-packages/rss2email/feed.py", line 436, in 
_check_for_errors
   elif isinstance(exc, _feedparser.zlib.error):
   AttributeError: module 'feedparser' has no attribute 'zlib'


-- System Information:
Architecture: arm64 (aarch64)

Versions of packages rss2email depends on:
ii  python3 3.9.2-3
ii  python3-feedparser  6.0.8-1
ii  python3-html2text   2020.1.16-1

Versions of packages rss2email recommends:
ii  python3-bs4  4.10.0-2

--
Jakub Wilk



Bug#990224: [Pkg-pascal-devel] Bug#990224: leaves diversion after upgrade from sid to experimental

2021-11-02 Thread Paul Gevers
Hi Abou,

On 02-11-2021 22:37, Abou Al Montacir wrote:
> On Tue, 2021-11-02 at 21:22 +0100, Paul Gevers wrote:
>> I don't follow at all.
> Sorry, I don't catch what do you mean here, probably due to my non
> native English.

It means that I didn't understand everything you were saying as the
problem at hand looked much simpler than your solution. I didn't
understand why you needed the current or future solution, I am just
trying to solve the actual bug in this report.

> Did you not accept the new solution, or is my explanation above not
> clear at all and confusing? 

I didn't try extremely hard to understand the real problem, but ...

> If you don't like the new solution, it is fine with me. We can try to
> fix the current one. Otherwise, please let me know and I can try to
> explain it a bit more.

If you come with a more elegant solution for the problem you try to
tackle, I think we *still* need to solve this particular bug report as
the problem is embedded in the package currently in testing.

>>  We're doing diversions in maintainer scripts and
>> we forget to properly keep track of our diversions.
> The list of diverted files is created automatically during the build
> process in  lazarus-src.preinst.[1]

I know.

> The very same list is created for lazarus-src.postrm.[2]

Yes, but the list for 2.0.12 is apparently not the same and missing
files compared to 2.0.10.

>>  With the new
>> upstream version, apparently some files got dropped and the knowledge of
>> the diversions got lost in the process.
> This means that somehow, the lazarus-src.postrm was not called.

Because 2.0.10 was upgraded to 2.0.12 and then 2.0.12 was removed.

>>  I think we can easily manually
>> drop the diversions now by adding them here [1], while contemplating a
>> saner and automated way of handling the underlying problem.

> In the current case,  lazarus-src.postrm is not called or is called but
> does not fall in the list of tests we are doing (called with upgrade?).

I understand the problem is that we first upgrade and then remove. The
embedded list in 2.0.12 is not listing all files we had in 2.0.10.

> However, in the past we did not remove the old lazarus when the new one
> is installed (we were able to have 2.0.10 and 2.0.12). Now we allow this
> only for major releases, not maintenance ones.

You're confusing me.

> So next time, soon, when
> 2.2 will be there, the upgrade will not happen in the same way.
> So if upgrading from 2.0.10 to 2.0.x we should remove diversions, but
> not if we go to from 2.0.10 to 2.y with y > 0.

> That was why I proposed to completely replace this mechanism with an
> other one that let it handled automatically with dpkg, but maybe we can
> just fix the logic in [3].

My point is that even if we replace the mechanism, we still need to
remove the existing diversions from the version in testing, when
upgrading to the version in unstable.

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Bug#997166: libcdio: FTBFS: cdda-player.c:301:28: error: format not a string literal and no format arguments [-Werror=format-security]

2021-11-02 Thread Gabriel F. T. Gomes
Hi, Rocky,

On Tue, 2 Nov 2021 13:11:07 -0400
Rocky Bernstein  wrote:
>
> Hmm - as best as I can tell this patches things a little differently than
> what was done in the git codebase.

That was not my intention.

Actually, I don't understand why you say that.

The patch that I backported to Debian is the one you mentioned in a
previous message, i.e.:

https://savannah.gnu.org/patch/index.php?10130

What did I get wrong?

Cheers,
Gabriel



Bug#998341: qemu-system-common: qemu in bullseye-backports is incompatible with bullseye libvirt

2021-11-02 Thread Marcin Juszkiewicz

W dniu 02.11.2021 o 22:26, Michael Tokarev pisze:


What do you want us to do here?
I know full well that libvirt in buster is too old for new qemu.

I don't have enough experience to backport libvirt (I never ever
used it myself). Even if I had such experience, what I should do
with this bugreport?


You are right. I am forgetting that there are people using qemu directly.


Should I maybe remove the qemu backport and hence close this bugreport?
More recent qemu is definitely useful on buster - for me and for some
other people as well, so I don't quite want to remove it from bpo.

So I don't see a way to deal with this bugreport.


Close it please. Sorry for that.



Bug#990224: leaves diversion after upgrade from sid to experimental

2021-11-02 Thread Abou Al Montacir
Hi Paul,

On Tue, 2021-11-02 at 21:22 +0100, Paul Gevers wrote:
> ...
> I don't follow at all.
Sorry, I don't catch what do you mean here, probably due to my non native
English.
Did you not accept the new solution, or is my explanation above not clear at all
and confusing? 
If you don't like the new solution, it is fine with me. We can try to fix the
current one. Otherwise, please let me know and I can try to explain it a bit
more.
>  We're doing diversions in maintainer scripts and
> we forget to properly keep track of our diversions.
The list of diverted files is created automatically during the build process in
 lazarus-src.preinst.[1]
The very same list is created for lazarus-src.postrm.[2]
>  With the new
> upstream version, apparently some files got dropped and the knowledge of
> the diversions got lost in the process.
This means that somehow, the lazarus-src.postrm was not called.
>  I think we can easily manually
> drop the diversions now by adding them here [1], while contemplating a
> saner and automated way of handling the underlying problem.
In the current case,  lazarus-src.postrm is not called or is called but does not
fall in the list of tests we are doing (called with upgrade?).
However, in the past we did not remove the old lazarus when the new one is
installed (we were able to have 2.0.10 and 2.0.12). Now we allow this only for
major releases, not maintenance ones. So next time, soon, when 2.2 will be
there, the upgrade will not happen in the same way.
So if upgrading from 2.0.10 to 2.0.x we should remove diversions, but not if we
go to from 2.0.10 to 2.y with y > 0.

That was why I proposed to completely replace this mechanism with an other one
that let it handled automatically with dpkg, but maybe we can just fix the logic
in [3].

[1] https://salsa.debian.org/pascal-team/lazarus/-/blob/master/debian/rules#L411
[2] https://salsa.debian.org/pascal-team/lazarus/-/blob/master/debian/rules#L423
[3] 
https://salsa.debian.org/pascal-team/lazarus/-/blob/master/debian/lazarus-src.postrm.in#L7
-- 
Cheers,
Abou Al Montacir


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


Bug#998341: qemu-system-common: qemu in bullseye-backports is incompatible with bullseye libvirt

2021-11-02 Thread Michael Tokarev

Control: tag -1 + moreinfo

02.11.2021 19:47, Marcin Juszkiewicz wrote:

Package: qemu-system-common
Version: 1:5.2+dfsg-11
Severity: normal
X-Debbugs-Cc: marcin.juszkiew...@linaro.org

I am maintaining Debian support in OpenStack Kolla project. We are
building container images with OpenStack components and provide way to
deploy whole OpenStack from them.

As we have new release cycle now I looked into possible package
upgrades. Newer QEMU in bullseye-backports got my intention.

Then I tried to install it:

root@puchatek /]# apt-get install --no-install-recommends libvirt-clients 
libvirt-daemon-system qemu-block-extra qemu-system -t bullseye-backports 
libvirt-daemon
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  qemu-system-common : Breaks: libvirt-daemon (< 7.2.0-1) but 7.0.0-3 is to be 
installed
E: Unable to correct problems, you have held broken packages.


What do you want us to do here?
I know full well that libvirt in buster is too old for new qemu.

I don't have enough experience to backport libvirt (I never ever
used it myself). Even if I had such experience, what I should do
with this bugreport?

Should I maybe remove the qemu backport and hence close this bugreport?
More recent qemu is definitely useful on buster - for me and for some
other people as well, so I don't quite want to remove it from bpo.

So I don't see a way to deal with this bugreport.

Thanks,

/mjt



Bug#998341: qemu-system-common: qemu in bullseye-backports is incompatible with bullseye libvirt

2021-11-02 Thread Michael Tokarev

03.11.2021 00:26, Michael Tokarev wrote:


02.11.2021 19:47, Marcin Juszkiewicz wrote:

Package: qemu-system-common
Version: 1:5.2+dfsg-11

...

What do you want us to do here?


And *especially* with this version which IS compatible with buster libvirt.

I fail to see why did you file this bugreport.  Please enlighten me.

/mjt



Bug#998148: transition: libavif

2021-11-02 Thread Sebastian Ramacher
On 2021-11-02 21:22:35, Norbert Preining wrote:
> Hi Boyuan
> 
> 
> > I plan to start another libavif transition as shown in the following
> 
> Great, actually it would be great going straight to 0.9.3-2 with libaom v3
> support, so that writing of avif files also works.

For the future: we prefer to not entangle transitions in general and
especially when they have already been started. Please let us know
before uploading if you want to entangle them.

And the general recommendation for all packages involved in a transition
still applies: please only upload if the upload is required to finish a
transition - otherwise wait until its done.

Best
Sebastian
-- 
Sebastian Ramacher



Bug#998360: trydiffoscope: waits forever if website is down or unreachable

2021-11-02 Thread Paul Gevers
Package: trydiffoscope
Version: 67.0.5
Severity: normal
Tags: upstream

Dear maintainer(s),

The latest testing run of trydiffoscope on ci.d.n timed out on all
arches [1]. I checked what the test is doing and all it does is run
trydiffoscope. I take it that trydiffoscope don't time out if the site
is unreachable. Maybe you want to add a time out.

Paul

[1] https://ci.debian.net/packages/t/trydiffoscope/

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

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

Versions of packages trydiffoscope depends on:
ii  python3   3.9.2-3
ii  python3-requests  2.25.1+dfsg-2

trydiffoscope recommends no packages.

trydiffoscope suggests no packages.



OpenPGP_signature
Description: OpenPGP digital signature


Bug#998359: age fails reading passphrase-protected key files

2021-11-02 Thread Kai Katze
Package: age
Version: 1.0.0~rc1-2+b3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

this is how you can reproduce the bug:
$ age-keygen | age -p > tmp/key.age
Public key: age17sxjygr9yuvv7s5yd657gfw6v2c9597938ur2smug4u9fysrxdms2p9h0y
Enter passphrase (leave empty to autogenerate a secure one):
Using the autogenerated passphrase 
"dolphin-coffee-erase-table-denial-remain-orphan-gym-debris-episode".
$ age -r age17sxjygr9yuvv7s5yd657gfw6v2c9597938ur2smug4u9fysrxdms2p9h0y -o 
/tmp/passwd.age /etc/passwd
$ age -d -i tmp/key.age -o /tmp/passwd /tmp/passwd.age
Error reading "tmp/key.age": failed to read "tmp/key.age": error at line 1: 
malformed secret key: separator '1' at
invalid position: pos=20, len=21
[ Did age not do what you expected? Could an error be more useful? Tell us: 
https://filippo.io/age/report ]

Being unable to use passphrase-protected key files renders this package 
unusable.

This bug is not present in upstream v1.0.0. 

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

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

Versions of packages age depends on:
ii  libc6  2.31-13+deb11u2

age recommends no packages.

age suggests no packages.

-- no debconf information



Bug#998357: mrtg: Czech PO debconf template translation

2021-11-02 Thread Eriberto Mota
Thank you Michal.

Regards,

Eriberto



Bug#996878: python3-prelude: python3 import prelude throws an ImportError exception

2021-11-02 Thread François Poirotte

Hi,

I tracked the issue down to 
https://sources.debian.org/patches/libprelude/5.2.0-4/025-Fix-PyIOBase_Type.patch


Although the patch changes the content of 
bindings/python/libpreludecpp-python.i, swig is never called during the 
build to recreate _prelude.cxx.
The final package therefore acts as if the patch had never been there in 
the first place.


The attached patch for debian/rules ensures that the file gets 
regenerated. After applying the patch, the module can be imported.


Due to the difference between the swig version initially used to build 
_prelude.cxx (4.0.1) and the one in Debian testing/sid (4.0.2), the diff 
output between both versions of _prelude.cxx is quite long (730 lines). 
However, I have been running with the patch for 24h and haven't seen any 
problem so far.


Best regards,
François


--- debian/rules.bak	2021-08-25 20:53:39.0 +0200
+++ debian/rules	2021-11-02 21:19:43.102093735 +0100
@@ -53,7 +53,7 @@
 	ln -s /usr/share/gtk-doc/html/libprelude $(CURDIR)/debian/tmp/usr/share/doc/libprelude-doc/html
 
 install-python%:
-	cd bindings/python && python$* setup.py install --root $(CURDIR)/debian/tmp
+	cd bindings/python && make _prelude.cxx && python$* setup.py install --root $(CURDIR)/debian/tmp
 
 %:
 	dh $@ $(DH_ADDONS)


Bug#998358: Subject: grepmail: autopkgtest doesn't do anything

2021-11-02 Thread Paul Gevers
Source: grepmail
X-Debbugs-Cc: mar...@talau.info, eribe...@debian.org
Version: 5.3104-1
Severity: serious
Justification: RC policy

Dear Marcos, Joao,

I appreciate your attention to the orphaned package grepmail and the
fact that you try to save it from removal from testing, but in the
process you added and autopkgtest that doesn't do anything at all.

I played around with it a tiny bit, and the reason it doesn't run
anything is because dh_auto_test doesn't detect a known framework. Why
dh_auto_test works during building is that during build a Makefile is
generated in one of the steps before testing and dh_auto_test executes
the test target in that. For this to work, the autopkgtest at least
needs more of the Build-Depends, otherwise the test fails. I ran the
following manually in the testbed after checking what code
was actually run during the test on the buildd and it currently fails
all tests:

PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM"
"-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(1,
'inc', 'blib/lib', 'blib/arch')" t/*.t

Before fixing this, please ensure you're testing the as-installed
binary instead of the code in the source tree, as the intention of
autopkgtest is to test the package, not the source, as I believe you're
not testing /usr/bin/grepmail

Paul

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

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



OpenPGP_signature
Description: OpenPGP digital signature


Bug#864402: Info received (lxde "No session for pid ...." on screen after login.)

2021-11-02 Thread MichaIng



Adding another information:

I retested it on Debian Buster and Stretch and the same error prompt 
appears when LXDE is not started from the actual screen/console but when 
calling "startx" from e.g. an SSH session, which then start LXDE on the 
main screen. The solution/workaround is the same.


Interestingly there is not a single lxpolkit process running then, so it 
is not a conflict between multiple lxpolkit. I'm not sure whether 
disabling it completely is the right thing, respectively of any negative 
impact when doing so. Probably there is something missing or lxpolkit 
needs to be actively configured to work fine with LXDE?


I hope this helps to track down the issue.

Best regards,

Micha



Bug#998357: mrtg: Czech PO debconf template translation

2021-11-02 Thread Michal Simunek
Package: mrtg
Version: 2.17.8+git20211022.f52e91e-1
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

In attachment there is initial Czech translation of PO debconf
template (cs.po) for package mrtg, please include it.


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

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

Versions of packages mrtg depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  libc6  2.31-13+deb11u2
ii  libgd3 2.3.0-2
pn  libsnmp-session-perl   
ii  perl   5.32.1-4+deb11u2

mrtg recommends no packages.

Versions of packages mrtg suggests:
ii  firefox-esr [www-browser]  78.15.0esr-1~deb11u1
# Czech PO debconf template translation of mrtg.
# Copyright (C) 2021 Michal Simunek 
# This file is distributed under the same license as the mrtg package.
# Michal Simunek , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: mrtg 2.17.8+git20211022.f52e91e-1\n"
"Report-Msgid-Bugs-To: m...@packages.debian.org\n"
"POT-Creation-Date: 2021-10-25 19:27-0300\n"
"PO-Revision-Date: 2021-11-02 20:15+0100\n"
"Last-Translator: Michal Simunek \n"
"Language-Team: Czech \n"
"Language: cs\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../mrtg.templates:1001
msgid "Fix owner, group and permissions for /var/www/html/mrtg?"
msgstr "Opravit vlastníka, skupinu a oprávnění pro /var/www/html/mrtg?"

#. Type: boolean
#. Description
#: ../mrtg.templates:1001
msgid ""
"By default MRTG writes all graphics in /var/www/html/mrtg/ directory. This "
"directory is present at this moment, but it is insecure. Is needed to make "
"this directory owned by 'mrtg' user and 'www-data' group. The recommended "
"permission is 0750."
msgstr ""
"Ve výchozím nastavení ukládá MRTG veškerou grafiku do adresáře /var/www/html/"
"mrtg/. Tento adresář nyní existuje, ale není zabezpečený. Je třeba, aby jej "
"vlastnil uživatel 'mrtg' a skupina 'www-data'. Doporučené oprávnění je 0750."

#. Type: boolean
#. Description
#: ../mrtg.templates:2001
msgid "Create /var/www/html/mrtg?"
msgstr "Vytvořit /var/www/html/mrtg?"

#. Type: boolean
#. Description
#: ../mrtg.templates:2001
msgid ""
"By default MRTG writes all graphics in /var/www/html/mrtg/ directory. "
"However, at this moment, this directory doesn't exist. Is also needed to "
"make this directory owned by 'mrtg' user and 'www-data' group. The "
"recommended permission is 0750."
msgstr ""
"Ve výchozím nastavení ukládá MRTG veškerou grafiku do adresáře /var/www/html/"
"mrtg/. Tento adresář však nyní neexistuje. Je také třeba, aby jej vlastnil "
"uživatel 'mrtg' a skupina 'www-data'. Doporučené oprávnění je 0750."

#. Type: boolean
#. Description
#: ../mrtg.templates:2001
msgid ""
"Alternatively, you can use another path for generated graphics. Note that "
"keeping this directory empty when using another path is not a problem."
msgstr ""
"Případně můžete pro generovanou grafiku použít jinou cestu. Pamatujte, že "
"při použití jiné cesty není problém ponechat tento adresář prázdný."


Bug#990224: lazarus-src-2.0: leaves diversion after upgrade from sid to experimental

2021-11-02 Thread Paul Gevers
Hi Abou,

On 30-10-2021 12:25, Abou Al Montacir wrote:
> The issue here is that LPK files are needed by binary libs (pascal units
> / ppu) and source packages.
> The right solution would be probably to move them into a separate
> packages that is used by both source and binaries.
> However, that ppu files are distributed not as a unique packages but
> split into several ones. So this solution will require to double the
> number or packages required to install full Lazarus installation.
> 
> Another easier solution would be to make sources depend on binary or
> binary depend on sources, but this is not something I like, even if, it
> is true, that in order for Lazarus to show its all power, it needs the
> sources to be installed.

I don't follow at all. We're doing diversions in maintainer scripts and
we forget to properly keep track of our diversions. With the new
upstream version, apparently some files got dropped and the knowledge of
the diversions got lost in the process. I think we can easily manually
drop the diversions now by adding them here [1], while contemplating a
saner and automated way of handling the underlying problem.

Paul

[1]
https://salsa.debian.org/pascal-team/lazarus/-/blob/master/debian/lazarus-src.postrm.in#L9



OpenPGP_signature
Description: OpenPGP digital signature


Bug#998352: libdbd-sqlite3-perl uses a vendored copy of SQLite

2021-11-02 Thread gregor herrmann
On Tue, 02 Nov 2021 22:13:20 +0200, Adrian Bunk wrote:

> > > libdbd-sqlite3-perl should use libsqlite3-dev instead of
> > > the vendored copy.
> > Unless I'm mistaken, it does.
> Ups, sorry for the noise.

No worries, and …
 
> I saw that libdbd-sqlite2-perl escaped the SQLite 2 removal in bullseye 
> due to not doing it, 

… thanks for catching this issue.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature


Bug#998356: jami: No line-break in chat

2021-11-02 Thread rv
Package: jami
Version: 20210112.2.b757bac~ds1-1
Severity: important
X-Debbugs-Cc: riveravaldezm...@gmail.com

Dear Maintainer, hi,

I reported this issue to the Jami developers there:

https://git.jami.net/savoirfairelinux/jami-project/-/issues/1336

In the chat/conversation window when a message is long instead of line-breaks
the text goes out of the bubble and even out of the window (even in maximized
window).

There are a couple of screen-captures in the link above.

The response from Jami-devs has been:

> Hi,
> 20210112 is not from our team and very old.
> We provide a repo for debian and snap repo: 
> https://jami.net/download-jami-linux/
> Regards,

, so, I'm not sure if this requires upgrading/updating the version or what...
(considering that in Stable that's uncommon, maybe this serves some purpose
for the Testing version?).

Let me know if I can help providing any info.

Kind regards!


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

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

Versions of packages jami depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  jami-daemon  20210112.2.b757bac~ds1-1
ii  libayatana-appindicator3-1   0.5.5-2
ii  libc62.30-8
ii  libcairo21.16.0-5
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libclutter-1.0-0 1.26.4+dfsg-2
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libnm0   1.30.0-2
ii  libnotify4   0.7.9-3
ii  libpango-1.0-0   1.46.2-3
ii  libqrencode4 4.1.1-1
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5dbus5  5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5sql5   5.15.2+dfsg-9
ii  libqt5sql5-sqlite5.15.2+dfsg-9
ii  libstdc++6   10.2.1-6
ii  libwebkit2gtk-4.0-37 2.34.1-1~deb11u1
ii  libx11-6 2:1.7.2-1

jami recommends no packages.

jami suggests no packages.

-- no debconf information



Bug#998355: samba: Access Time of File is set to the far future: 30828-09-14 04:48:05.477580700 +0200

2021-11-02 Thread Georg Gast
Package: samba
Version: 2:4.13.5+dfsg-2
Severity: normal
X-Debbugs-Cc: ge...@schorsch-tech.de

Dear Maintainer,

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

   * What led up to the situation?
I upgraded from buster to bullseye. With buster i used a .NET program on 
windows called "Mein Geld 365". The database is on the NAS running samba. With 
buster, the accesstime was normal adjusted but with bullseye, the accesstime is 
set far to the future.

This shows the outout of stat when the error is there:
stat Georg_2016.mgz
 Datei: Georg_2016.mgz
 Größe: 20905984Blöcke: 40808  EA Block: 4096   reguläre Datei
 Gerät: 2bh/43d Inode: 452839  Verknüpfungen: 1
Zugriff: (0660/-rw-rw)  Uid: ( 1000/   georg)   Gid: ( 1000/   georg)
Zugriff: 30828-09-14 04:48:05.477580700 +0200
Modifiziert: 2021-11-02 17:18:23.581530067 +0100
Geändert: 2021-11-02 17:18:23.577239537 +0100
Geburt: 2021-11-02 17:16:31.709703003 +0100

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I reverted my machine to buster (snapshot on btrfs) and the application worked 
correctly. With the wrong accesstime the application complains about
"Invalid Win32-FileTime". After the rollback to bullseye the application 
complained again about the wront "Win32-FileTime".
Even a touch on the nas to the file corrects the accesstime. 

   * What outcome did you expect instead?
The accesstime of the file should be correct.

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

I wanted to pin the old samba version to see, if its samba or the kernel, but 
the pin did not work as it conflicts on libldb2/libldb1.

-- Package-specific info:
* /etc/samba/smb.conf present, and attached
* /var/lib/samba/dhcp.conf present, and attached

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

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

Versions of packages samba depends on:
ii  adduser  3.118
ii  dpkg 1.20.9
ii  init-system-helpers  1.60
ii  libbsd0  0.11.3-1
ii  libc62.31-13+deb11u2
ii  libgnutls30  3.7.1-5
ii  libldb2  2:2.2.0-3.1
ii  libpam-modules   1.4.0-9+deb11u1
ii  libpam-runtime   1.4.0-9+deb11u1
ii  libpopt0 1.18-2
ii  libpython3.9 3.9.2-1
ii  libtalloc2   2.3.1-2+b1
ii  libtasn1-6   4.16.0-2
ii  libtdb1  1.4.3-1+b1
ii  libtevent0   0.10.2-1
ii  libwbclient0 2:4.13.5+dfsg-2
ii  lsb-base 11.1.0
ii  procps   2:3.3.17-5
ii  python3  3.9.2-3
ii  python3-dnspython2.0.0-1
ii  python3-samba2:4.13.5+dfsg-2
ii  samba-common 2:4.13.5+dfsg-2
ii  samba-common-bin 2:4.13.5+dfsg-2
ii  samba-libs   2:4.13.5+dfsg-2
ii  tdb-tools1.4.3-1+b1

Versions of packages samba recommends:
ii  attr1:2.4.48-6
ii  logrotate   3.18.0-2
ii  python3-markdown3.3.4-1
ii  samba-dsdb-modules  2:4.13.5+dfsg-2
ii  samba-vfs-modules   2:4.13.5+dfsg-2

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
pn  ntp | chrony   
pn  smbldap-tools  
pn  ufw
pn  winbind

-- no debconf information
[global]
#workgroup = dahoam2
#min protocol = NT1
#max protocol = smb2
netbios name = NAS-DSM
ntlm auth = yes

#vfs objects = full_audit
#full_audit:prefix = %u|%I|%m|%S
#full_audit:success = mkdir rename unlink rmdir pwrite
#full_audit:failure = none
#full_audit:facility = local7
#full_audit:priority = NOTICE

# this is important to join the workgroup
domain master = no

# allow to execute from the share
acl allow execute always = True

server role = standalone server
realm = nas-dsm

#name resolve order = wins lmhosts bcast
name resolve order = wins bcast

# %v prints the version of Samba being used.
server string = Samba Server %v
load printers = no

## # This line enables the log file and limits its size to less than 50kb.
log file = /var/log/samba/log.%m
log level = 3
max log size = 50

## # We are going to set some options for our interfaces...
socket options = TCP_NODELAY

## # This is a good idea, what we are doing is binding the
# samba server to our local network.
# For example, if eth0 is the local network interface:
interfaces = eth0
# bind interfaces only = yes

## # Specifies which IP address range is allowed to access Samba
hosts allow = 127.0.0.1 192.168.160.0/24 192.168.177.0/24
hosts deny = 0.0.0.0/0

## # Other options for this are USER, DOMAIN, ADS, and SERVER
# The default is user
security = user
map to guest = Bad Password

## # 

Bug#998352: libdbd-sqlite3-perl uses a vendored copy of SQLite

2021-11-02 Thread gregor herrmann
On Tue, 02 Nov 2021 21:53:59 +0200, Adrian Bunk wrote:

> libdbd-sqlite3-perl should use libsqlite3-dev instead of
> the vendored copy.

Unless I'm mistaken, it does.

Cf. debian/control and more importantly
debian/patches/use_system_sqlite.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature


Bug#998354: plasma-wayland-protocols FTCBFS: missing Build-Depends: qt5-qmake

2021-11-02 Thread Helmut Grohne
Source: plasma-wayland-protocols
Version: 1.4.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

plasma-wayland-protocols fails to cross build from source, because it
uses qmake to query for paths via ECM without the relevant dependency on
qt5-qmake. As a consequence, running qmake as part of the build fails.
Please apply the attached patch to fix the missing dependency.

Helmut
diff --minimal -Nru plasma-wayland-protocols-1.4.0/debian/changelog 
plasma-wayland-protocols-1.4.0/debian/changelog
--- plasma-wayland-protocols-1.4.0/debian/changelog 2021-09-05 
10:22:42.0 +0200
+++ plasma-wayland-protocols-1.4.0/debian/changelog 2021-11-02 
21:01:11.0 +0100
@@ -1,3 +1,10 @@
+plasma-wayland-protocols (1.4.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Missing Build-Depens: qt5-qmake. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 02 Nov 2021 21:01:11 +0100
+
 plasma-wayland-protocols (1.4.0-1) unstable; urgency=medium
 
   [ Norbert Preining ]
diff --minimal -Nru plasma-wayland-protocols-1.4.0/debian/control 
plasma-wayland-protocols-1.4.0/debian/control
--- plasma-wayland-protocols-1.4.0/debian/control   2021-09-05 
10:21:53.0 +0200
+++ plasma-wayland-protocols-1.4.0/debian/control   2021-11-02 
21:00:29.0 +0100
@@ -7,6 +7,7 @@
 Build-Depends: cmake (>= 3.5~),
debhelper-compat (= 13),
extra-cmake-modules (>= 5.69.0~),
+   qt5-qmake,
 Standards-Version: 4.6.0
 Rules-Requires-Root: no
 Homepage: https://invent.kde.org/libraries/plasma-wayland-protocols


Bug#998353: src:win32-loader: fails to migrate to testing for too long

2021-11-02 Thread Paul Gevers
Source: win32-loader
Version: 0.10.4
Severity: serious
Control: close -1 0.10.5
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The following template feels a bit weird for the somewhat special
package that win32-loader is, but I leave it in this report nevertheless
for some background. Can somebody please judge if win32-loader should
migrate in the current state and take appropriate actions if so: contact
ftp to process the package on their side and update bug 982838 (I
wouldn't close it, but reuse it after migration) with the right meta
info such that the bug doesn't block migration? If help is needed,
please reach out to the Release Team.

 Template =

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:win32-loader has been trying to migrate
for 62 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 bookworm, 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=win32-loader




OpenPGP_signature
Description: OpenPGP digital signature


Bug#998352: libdbd-sqlite3-perl uses a vendored copy of SQLite

2021-11-02 Thread Adrian Bunk
Package: libdbd-sqlite3-perl
Severity: normal

libdbd-sqlite3-perl should use libsqlite3-dev instead of
the vendored copy.



Bug#998351: Should libdbd-sqlite2-perl be shipped in bookworm?

2021-11-02 Thread Adrian Bunk
Package: libdbd-sqlite2-perl
Severity: serious
Tags: bookworm sid

libdbd-sqlite2-perl uses a vendored copy of SQLite 2.

SQLite 3 was released in 2004, and the the regular
SQLite 2 package is no longer shipped since bullseye (see #607969).



Bug#998350: libposix-atfork-perl FTCBFS: missing Build-Depends: perl-xs-dev

2021-11-02 Thread Helmut Grohne
Source: libposix-atfork-perl
Version: 0.04-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libposix-atfork-perl fails to cross build from source, because it builds
a perl extension without depending on perl-xs-dev. Please apply the
attached patch to add the missing dependency.

Helmut
diff --minimal -Nru libposix-atfork-perl-0.04/debian/changelog 
libposix-atfork-perl-0.04/debian/changelog
--- libposix-atfork-perl-0.04/debian/changelog  2021-09-12 13:24:20.0 
+0200
+++ libposix-atfork-perl-0.04/debian/changelog  2021-11-02 20:31:15.0 
+0100
@@ -1,3 +1,10 @@
+libposix-atfork-perl (0.04-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Missing Build-Depends: perl-xs-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 02 Nov 2021 20:31:15 +0100
+
 libposix-atfork-perl (0.04-1) unstable; urgency=medium
 
   [ upstream ]
diff --minimal -Nru libposix-atfork-perl-0.04/debian/control 
libposix-atfork-perl-0.04/debian/control
--- libposix-atfork-perl-0.04/debian/control2021-09-12 13:23:38.0 
+0200
+++ libposix-atfork-perl-0.04/debian/control2021-11-02 20:31:14.0 
+0100
@@ -4,6 +4,7 @@
 Build-Depends:
  debhelper-compat (= 13),
  libtest-sharedfork-perl ,
+ perl-xs-dev,
 Maintainer: Debian Perl Group 
 Uploaders: Jonas Smedegaard 
 Standards-Version: 4.6.0


Bug#997740: [Python-modules-team] Bug#997740: python-pkginfo: FTBFS: There is a syntax error in your configuration file: invalid syntax (conf.py, line 176)

2021-11-02 Thread Emmanuel Arias
HI,

This bugs is fixed in the new upstream release [0]

[0] https://bugs.launchpad.net/pkginfo/+bug/1933322

Cheers,
Arias Emmanuel
@eamanu
yaerobi.com


On Sun, Oct 24, 2021 at 9:34 AM Lucas Nussbaum  wrote:

> Source: python-pkginfo
> Version: 1.4.2-3
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20211023 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_auto_build --buildsystem=pybuild
> > I: pybuild base:232: /usr/bin/python3 setup.py build
> > running build
> > running build_py
> > creating /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo
> > copying pkginfo/develop.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo
> > copying pkginfo/__init__.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo
> > copying pkginfo/_compat.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo
> > copying pkginfo/index.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo
> > copying pkginfo/commandline.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo
> > copying pkginfo/sdist.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo
> > copying pkginfo/bdist.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo
> > copying pkginfo/distribution.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo
> > copying pkginfo/installed.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo
> > copying pkginfo/utils.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo
> > copying pkginfo/wheel.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo
> > creating
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo/tests
> > copying pkginfo/tests/__init__.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo/tests
> > copying pkginfo/tests/test_index.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo/tests
> > copying pkginfo/tests/test_utils.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo/tests
> > copying pkginfo/tests/test_wheel.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo/tests
> > copying pkginfo/tests/test_develop.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo/tests
> > copying pkginfo/tests/test_commandline.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo/tests
> > copying pkginfo/tests/test_installed.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo/tests
> > copying pkginfo/tests/test_sdist.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo/tests
> > copying pkginfo/tests/test_bdist.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo/tests
> > copying pkginfo/tests/test_distribution.py ->
> /<>/.pybuild/cpython3_3.9_pkginfo/build/pkginfo/tests
> > python3 setup.py build_sphinx
> > running build_sphinx
> > Running Sphinx v4.2.0
> >
> > Configuration error:
> > There is a syntax error in your configuration file: invalid syntax
> (conf.py, line 176)
> >
> > make[1]: *** [debian/rules:11: override_dh_auto_build] Error 1
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2021/10/23/python-pkginfo_1.4.2-3_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> If you reassign this bug to another package, please marking it as
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>
> If you fail to reproduce this, please provide a build log and diff it with
> mine
> so that we can identify if something relevant changed in the meantime.
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
>


Bug#991788: xfce4-settings: black screen after suspend when laptop lid is closed and re-opened

2021-11-02 Thread Chris Dellin
I have also had the same issue consistently. Happens occasionally, but is
quite annoying. I can fix it by switching to a virtual terminal (which
works), scheduling "DISPLAY=:0 xrandr --auto" to run in the near future,
and then switching back to the X VT, and waiting for the command to run.

My stats:

OS: Debian GNU/Linux 11 (bullseye)
Hardware: Lenovo Thinkpad T460s
Graphics: Intel Corporation Skylake GT2 [HD Graphics 520]
Kernel: 5.10.0-9-amd64 (with i915 driver)
Packages: xfce4 4.16
Packages: upower 0.99.11-2
Packages: light-locker 1.8.0-3

Cheers,
- Chris


Bug#998347: rust-bindgen: diff for NMU version 0.59.1-1.1

2021-11-02 Thread Jonas Smedegaard
Control: tags 998347 + patch
Control: tags 998347 + pending

Dear maintainer,

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

Regards,

 - Jonas

diff -Nru rust-bindgen-0.59.1/debian/cargo-checksum.json 
rust-bindgen-0.59.1/debian/cargo-checksum.json
--- rust-bindgen-0.59.1/debian/cargo-checksum.json  2021-08-22 
17:37:34.0 +0200
+++ rust-bindgen-0.59.1/debian/cargo-checksum.json  2021-11-02 
19:36:53.0 +0100
@@ -1 +1 @@
-{"package":"Could not get crate checksum","files":{}}
+{"package":"fcc1d4fdeaab48c213b8e18298928319326670fa2b6d0509e785b248fbfe49f1","files":{}}
diff -Nru rust-bindgen-0.59.1/debian/changelog 
rust-bindgen-0.59.1/debian/changelog
--- rust-bindgen-0.59.1/debian/changelog2021-08-22 17:37:34.0 
+0200
+++ rust-bindgen-0.59.1/debian/changelog2021-11-02 19:36:53.0 
+0100
@@ -1,3 +1,13 @@
+rust-bindgen (0.59.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * add patch to relax dependency on Rust library env_logger,
+and update (build-)dependencies on librust-env-logger-*-dev;
+this closes: bug#998347
+  * fix Cargo.toml checksum hint file
+
+ -- Jonas Smedegaard   Tue, 02 Nov 2021 19:36:53 +0100
+
 rust-bindgen (0.59.1-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru rust-bindgen-0.59.1/debian/control rust-bindgen-0.59.1/debian/control
--- rust-bindgen-0.59.1/debian/control  2021-08-22 17:37:34.0 +0200
+++ rust-bindgen-0.59.1/debian/control  2021-11-02 19:35:53.0 +0100
@@ -11,7 +11,7 @@
  librust-clang-sys-1+clang-6-0-dev,
  librust-clang-sys-1+default-dev,
  librust-clap-2+default-dev,
- librust-env-logger-0.7+default-dev,
+ librust-env-logger-0.9+default-dev,
  librust-lazy-static-1+default-dev,
  librust-lazycell-1+default-dev,
  librust-log-0.4+default-dev,
@@ -134,7 +134,7 @@
 Depends:
  ${misc:Depends},
  librust-bindgen-dev (= ${binary:Version}),
- librust-env-logger-0.7+default-dev
+ librust-env-logger-0.9+default-dev
 Provides:
  librust-bindgen-0+env-logger-dev (= ${binary:Version}),
  librust-bindgen-0.59+env-logger-dev (= ${binary:Version}),
@@ -164,7 +164,7 @@
 Depends:
  ${misc:Depends},
  librust-bindgen-dev (= ${binary:Version}),
- librust-env-logger-0.7+default-dev,
+ librust-env-logger-0.9+default-dev,
  librust-log-0.4+default-dev
 Provides:
  librust-bindgen-0+logging-dev (= ${binary:Version}),
diff -Nru rust-bindgen-0.59.1/debian/patches/env_logger.patch 
rust-bindgen-0.59.1/debian/patches/env_logger.patch
--- rust-bindgen-0.59.1/debian/patches/env_logger.patch 1970-01-01 
01:00:00.0 +0100
+++ rust-bindgen-0.59.1/debian/patches/env_logger.patch 2021-11-02 
19:35:18.0 +0100
@@ -0,0 +1,21 @@
+Description: relax dependency on env_logger
+ Debian has only a newer release of env_logger,
+ which apparently works just fine.
+ .
+ This patch relaxes dependency from only release 0.7.0
+ to accept any 0.7.x through 0.9.x releases.
+Author: Jonas Smedegaard 
+Last-Update: 2021-11-02
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/Cargo.toml
 b/Cargo.toml
+@@ -49,7 +49,7 @@
+ optional = true
+ 
+ [dependencies.env_logger]
+-version = "0.7"
++version = ">= 0.7, < 0.10"
+ optional = true
+ 
+ [dependencies.lazy_static]
diff -Nru rust-bindgen-0.59.1/debian/patches/series 
rust-bindgen-0.59.1/debian/patches/series
--- rust-bindgen-0.59.1/debian/patches/series   2021-08-22 17:37:34.0 
+0200
+++ rust-bindgen-0.59.1/debian/patches/series   2021-11-02 19:33:53.0 
+0100
@@ -1,2 +1,3 @@
 disable-runtime.diff
 lower-dep.diff
+env_logger.patch



Bug#998345: rust-quickcheck: diff for NMU version 0.9.2-1.1

2021-11-02 Thread Jonas Smedegaard
Control: tags 998345 + patch
Control: tags 998345 + pending

Dear maintainer,

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

Regards,

 - Jonas

diff -Nru rust-quickcheck-0.9.2/debian/cargo-checksum.json 
rust-quickcheck-0.9.2/debian/cargo-checksum.json
--- rust-quickcheck-0.9.2/debian/cargo-checksum.json2020-04-05 
18:33:58.0 +0200
+++ rust-quickcheck-0.9.2/debian/cargo-checksum.json2021-11-02 
19:18:33.0 +0100
@@ -1 +1 @@
-{"package":"a44883e74aa97ad63db83c4bf8ca490f02b2fc02f92575e720c8551e843c945f","files":{}}
+{"package":"694e95e04622ce811f75b6fe1c13da70fd5b98a9cbc4c55855cbb4a2e93879e1","files":{}}
diff -Nru rust-quickcheck-0.9.2/debian/changelog 
rust-quickcheck-0.9.2/debian/changelog
--- rust-quickcheck-0.9.2/debian/changelog  2020-04-05 18:33:58.0 
+0200
+++ rust-quickcheck-0.9.2/debian/changelog  2021-11-02 19:18:33.0 
+0100
@@ -1,3 +1,13 @@
+rust-quickcheck (0.9.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * add patch to relax dependency on Rust library env_logger,
+update Cargo.toml checksum hint file,
+and update (build-)dependencies on librust-env-logger-*-dev;
+this closes: bug#998345
+
+ -- Jonas Smedegaard   Tue, 02 Nov 2021 19:18:33 +0100
+
 rust-quickcheck (0.9.2-1) unstable; urgency=medium
 
   * Package quickcheck 0.9.2 from crates.io using debcargo 2.4.2
diff -Nru rust-quickcheck-0.9.2/debian/control 
rust-quickcheck-0.9.2/debian/control
--- rust-quickcheck-0.9.2/debian/control2020-04-05 18:33:58.0 
+0200
+++ rust-quickcheck-0.9.2/debian/control2021-11-02 19:18:33.0 
+0100
@@ -6,8 +6,8 @@
  cargo:native ,
  rustc:native ,
  libstd-rust-dev ,
- librust-env-logger-0.7+regex-dev ,
- librust-env-logger-0.7-dev ,
+ librust-env-logger-0.9+regex-dev ,
+ librust-env-logger-0.9-dev ,
  librust-log-0.4+default-dev ,
  librust-rand-0.7+default-dev ,
  librust-rand-core-0.5+default-dev 
@@ -68,7 +68,7 @@
 Depends:
  ${misc:Depends},
  librust-quickcheck-dev (= ${binary:Version}),
- librust-env-logger-0.7-dev
+ librust-env-logger-0.9-dev
 Provides:
  librust-quickcheck-0+env-logger-dev (= ${binary:Version}),
  librust-quickcheck-0.9+env-logger-dev (= ${binary:Version}),
@@ -98,7 +98,7 @@
 Depends:
  ${misc:Depends},
  librust-quickcheck-dev (= ${binary:Version}),
- librust-env-logger-0.7+regex-dev
+ librust-env-logger-0.9+regex-dev
 Provides:
  librust-quickcheck-0+regex-dev (= ${binary:Version}),
  librust-quickcheck-0.9+regex-dev (= ${binary:Version}),
@@ -113,7 +113,7 @@
 Depends:
  ${misc:Depends},
  librust-quickcheck-dev (= ${binary:Version}),
- librust-env-logger-0.7-dev,
+ librust-env-logger-0.9-dev,
  librust-log-0.4+default-dev
 Provides:
  librust-quickcheck-0+use-logging-dev (= ${binary:Version}),
diff -Nru rust-quickcheck-0.9.2/debian/patches/env_logger.patch 
rust-quickcheck-0.9.2/debian/patches/env_logger.patch
--- rust-quickcheck-0.9.2/debian/patches/env_logger.patch   1970-01-01 
01:00:00.0 +0100
+++ rust-quickcheck-0.9.2/debian/patches/env_logger.patch   2021-11-02 
19:18:33.0 +0100
@@ -0,0 +1,21 @@
+Description: relax dependency on env_logger
+ Debian has only a newer release of env_logger,
+ which apparently works just fine.
+ .
+ This patch relaxes dependency from only release 0.7.0
+ to accept any 0.7.x through 0.9.x releases.
+Author: Jonas Smedegaard 
+Last-Update: 2021-11-02
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/Cargo.toml
 b/Cargo.toml
+@@ -28,7 +28,7 @@
+ [lib]
+ name = "quickcheck"
+ [dependencies.env_logger]
+-version = "0.7.0"
++version = ">= 0.7, < 0.10"
+ optional = true
+ default-features = false
+ 
diff -Nru rust-quickcheck-0.9.2/debian/patches/series 
rust-quickcheck-0.9.2/debian/patches/series
--- rust-quickcheck-0.9.2/debian/patches/series 1970-01-01 01:00:00.0 
+0100
+++ rust-quickcheck-0.9.2/debian/patches/series 2021-11-02 19:18:33.0 
+0100
@@ -0,0 +1 @@
+env_logger.patch



Bug#998348: please drop libncurses5-dev dep in favor of libncurses-dev

2021-11-02 Thread Joseph Carter
Package: ghc
Version: 8.8.4-3
Severity: minor

Just a request to drop libncurses5-dev (a dummy/transitional package) in
favor of libncurses-dev.

Thanks!

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

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

Versions of packages ghc depends on:
ii  dpkg  1.20.9
ii  gcc   4:11.2.0-2
ii  libbsd-dev0.11.3-1
ii  libc6 2.32-4
ii  libc6-dev 2.32-4
ii  libffi-dev3.4.2-3
ii  libffi8   3.4.2-3
ii  libgmp-dev2:6.2.1+dfsg-2
ii  libgmp10  2:6.2.1+dfsg-2
ii  libncurses-dev [libncurses5-dev]  6.2+20210905-1
ii  libncurses5-dev   6.2+20210905-1
ii  libtinfo6 6.2+20210905-1

ghc recommends no packages.

Versions of packages ghc suggests:
pn  ghc-doc  
pn  ghc-prof 
pn  haskell-doc  
ii  llvm-11  1:11.1.0-4
ii  perl 5.32.1-6

-- no debconf information



Bug#998345: librust-quickcheck+env-logger-dev: uninstallable - depends on non-existing package librust-env-logger-0.7-dev

2021-11-02 Thread Ximin Luo
Source: rust-quickcheck
Followup-For: Bug #998345
Control: close -1

> Correction: It is the binary package librust-quickcheck+env-logger-dev 
> which depends on librust-env-logger-0.7-dev.

env-logger-0.7 is sitting in NEW. There is no action to take on this package, 
therefore closing.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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



Bug#864082: fontconfig: please make the cache files reproducible

2021-11-02 Thread Andres Pavez
Hello,
I would like to send another gentle ping about this.

This bug is affecting the deployment upgrade of a current reproducible iso.

Thank you very much,
--
Andrés Pavez

On Wed, Jan 6, 2021 at 2:51 AM Johannes Schauer Marin Rodrigues
 wrote:
>
> Dear maintainers,
>
> On Sun, 13 Sep 2020 08:13:06 - "Chris Lamb"  wrote:
> > Friendly ping on this?
>
> I'd like to send another ping about this.
>
> This bug is affecting my package mmdebstrap so I'd love to see it fixed.
>
> Thanks!
>
> cheers, josch



Bug#998345: rust-quickcheck: invalid bug report

2021-11-02 Thread Ximin Luo
Source: rust-quickcheck
Followup-For: Bug #998345

Control: notfound -1 0.9.2-1
Control: close -1

Not sure how you came to this conclusion.

Package: librust-rand+std-dev
Provides:
 librust-rand-0.7+default-dev (= ${binary:Version}),

$ sudo aptitude install librust-quickcheck-dev
[sudo] password for infinity0: 
The following NEW packages will be installed:
  librust-aho-corasick+std-dev{a} librust-aho-corasick-dev{a} 
librust-atty-dev{a} librust-bitflags-dev{a} librust-cfg-if-0.1-dev{a} 
librust-cloudabi+default-dev{a} librust-cloudabi-dev{a} 
librust-env-logger+default-dev{a} 
  librust-env-logger+regex-dev{a} librust-env-logger-dev{a} 
librust-getrandom-dev{a} librust-humantime-dev{a} librust-libc-dev{a} 
librust-lock-api-dev{a} librust-log-dev{a} librust-memchr-dev{a} 
librust-once-cell-dev{a} 
  librust-parking-lot-core-dev{a} librust-parking-lot-dev{a} 
librust-ppv-lite86+default-dev{a} librust-ppv-lite86-dev{a} 
librust-quickcheck+default-dev{a} librust-quickcheck+regex-dev{a} 
librust-quickcheck+use-logging-dev{a} 
  librust-quickcheck-dev librust-rand+alloc-dev{a} 
librust-rand+getrandom-dev{a} librust-rand+std-dev{a} 
librust-rand-chacha+default-dev{a} librust-rand-chacha+std-dev{a} 
librust-rand-chacha-dev{a} 
  librust-rand-core+getrandom-dev{a} librust-rand-core+std-dev{a} 
librust-rand-core-dev{a} librust-rand-dev{a} librust-rand-hc-dev{a} 
librust-redox-syscall-dev{a} librust-regex+default-dev{a} 
librust-regex+perf-cache-dev{a} 
  librust-regex+perf-dev{a} librust-regex+perf-literal-dev{a} 
librust-regex+unicode-age-dev{a} librust-regex+unicode-bool-dev{a} 
librust-regex+unicode-case-dev{a} librust-regex+unicode-dev{a} 
librust-regex+unicode-gencat-dev{a} 
  librust-regex+unicode-perl-dev{a} librust-regex+unicode-script-dev{a} 
librust-regex+unicode-segment-dev{a} librust-regex-dev{a} 
librust-regex-syntax+unicode-dev{a} librust-regex-syntax-dev{a} 
librust-scopeguard-dev{a} 
  librust-smallvec-dev{a} librust-termcolor-dev{a} librust-thread-local-dev{a} 
librust-winapi-dev{a} librust-winapi-i686-pc-windows-gnu-dev{a} 
librust-winapi-util-dev{a} librust-winapi-x86-64-pc-windows-gnu-dev{a} 
0 packages upgraded, 60 newly installed, 0 to remove and 220 not upgraded.
Need to get 1,394 kB/2,216 kB of archives. After unpacking 16.8 MB will be used.
Do you want to continue? [Y/n/?] ^C
exit code 130

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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



Bug#998345: librust-quickcheck-dev: uninstallable - depends on non-existing package librust-rand-0.7+default-dev

2021-11-02 Thread Jonas Smedegaard
Control: reassign -1 librust-quickcheck+env-logger-dev
Control: retitle -1 librust-quickcheck+env-logger-dev: uninstallable - depends 
on non-existing package librust-env-logger-0.7-dev

Quoting Jonas Smedegaard (2021-11-02 21:19:38)
> The package librust-quickcheck-dev is uninstallable: It depends on 
> non-existing package librust-rand-0.7+default-dev.

Correction: It is the binary package librust-quickcheck+env-logger-dev 
which depends on librust-env-logger-0.7-dev.

Reassigining and retitling accordingly.

 - 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#998347: librust-bindgen+env-logger-dev: uninstallable - depends on non-existing package librust-env-logger-0.7+default-dev

2021-11-02 Thread Jonas Smedegaard
Package: librust-bindgen+env-logger-dev
Version: 0.59.1-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The package librust-bindgen+env-logger-dev is uninstallable: It depends
on non-existing package librust-env-logger-0.7+default-dev.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmGBhtIACgkQLHwxRsGg
ASHCNhAAhf8jim3wLxYeB+MKWtPeSJioYi/3UwnsZYlcRhs1IFfTnVml+HdmyDqb
2VnqMD7zOTOFfdphZFdVSlDrmyYpYz4kF1Mpp53NWMsIlRNfKPLHjlSg75gSqO10
/3P5TJFHI64XXXmVSSU/7OcGeeqRkzypEERlRVLvSABK4vjsoS9c0AIcEKTPhyiY
5bCxyVRPYxaB49EGswvOXrmbeZ0bvF5GS4/sRoZYRiKNNrBvxBRf997efxhlKRfo
ZOqx95PfP/n1UktGjZbXlR2JJlqLn9hcGWSyVqzTcfwVaba9xbO3bJrCEeA6BhXG
9/s+Agz3RjTVydDkvW027M7oPXQM1bfTMNxehp3i06/A4XZIMHZeSZExa02LqLdv
/EcdIpakiby8Om02sFCErk4KDAC4uFTqpE/V9y5HRpMdlN5h7+Xl/v6f2IL4lDru
nuIV8ZwqfsVWZwE2NC2S8hCcAa0dvzyoH9hXyiw9cjL4OdL8jRbRtxla2c2XDhKW
wepxW13e07VITHO2UeysysyeHTfOcLRgQzpeLsuHs6JcmI230mOplYwIM9c1lRRN
8Cu18h7/fVEAFjoCa8xDnnzFX+RqPlKo0GXO6AB9MPDWxzaSyuRBWN/r0wVDdff7
4tJCbYovoyGf+razDoez36eBlhNz8Twg74Zoxz+CDcoKME+Hz8s=
=WdW1
-END PGP SIGNATURE-



Bug#997232: netperfmeter: FTBFS: cpustatus.cc:33:10: fatal error: sys/sysctl.h: No such file or directory

2021-11-02 Thread Bastian Germann

On Sat, 23 Oct 2021 21:18:54 +0200 Lucas Nussbaum  wrote:

Source: netperfmeter
Version: 1.8.6~rc2-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> cd "/<>/obj-x86_64-linux-gnu/src" && /usr/bin/c++ -DHAVE_DCCP -DHAVE_IEEE_FP -DHAVE_KERNEL_SCTP -DHAVE_MPTCP -DHAVE_NETINET_SCTP_H 
-I"/<>/obj-x86_64-linux-gnu/src" -I"/<>/src" -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wno-unused-function -Wno-unused-parameter -Wno-overlength-strings -Wno-array-bounds 
-Wno-address-of-packed-member   -D_DEFAULT_SOURCE -DLINUX -MD -MT src/CMakeFiles/netperfmeter.dir/cpustatus.cc.o -MF CMakeFiles/netperfmeter.dir/cpustatus.cc.o.d -o 
CMakeFiles/netperfmeter.dir/cpustatus.cc.o -c "/<>/src/cpustatus.cc"
> /<>/src/cpustatus.cc:33:10: fatal error: sys/sysctl.h: No such 
file or directory
>33 | #include 
>   |  ^~
> compilation terminated.
> make[3]: *** [src/CMakeFiles/netperfmeter.dir/build.make:233: 
src/CMakeFiles/netperfmeter.dir/cpustatus.cc.o] Error 1




This should be fixed with 
https://github.com/dreibh/netperfmeter/commit/6f0a0864ca0d59960f12a1ad044b48ff532a1c4b.

The maintainer provided a package for the latest version including that commit 
at
https://mentors.debian.net/package/netperfmeter/



Bug#998346: apt assigns priority 500 to package versions from debian-security

2021-11-02 Thread Sylvain BOILARD
Package: apt
Version: 2.2.4
Severity: normal


Dear maintainer,

APT does not consider package versions from debian-security for updates
unless I change the priority assigned to these package versions to a
more appropriate value with a preference configuration file (see the
preferences.d/debian-security.disabled file below).

After adding this file I could easily install the security updates I
had missed untill then by running `aptitude upgrade` as I usually do.

At some point APT was proposing to upgrade firefox-esr to the version
found in unstable while ignoring the version in debian-security. I was
recently in the process of upgrading from oldstable to stable which
might have caused this particular behavior, and found out about the
debian-security issue while trouble-shooting this.

I remain available should you need any further information.

Cheers,


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-image-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-headers-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-modules-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-tools-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-5\.10\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-source-4\.19\.0-17-amd64$";
APT::NeverAutoRemove:: "^linux-source-5\.10\.0-9-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Default-Release "bullseye";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";

Bug#998343: Black upstream fork

2021-11-02 Thread Neil Williams
This is my work-in-progress fork of black containing the affected
upstream.

Currently, I've patched out the sphinx-copybutton requirement from
docs/conf.py to allow the rest of the build to proceed and fix the
other problems.

This fork may at least help reproduce the failure.

https://salsa.debian.org/codehelp/black


-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpUh9RucPk7q.pgp
Description: OpenPGP digital signature


Bug#997630: pygithub: FTBFS: error in PyGithub setup command: use_2to3 is invalid.

2021-11-02 Thread Romain Porte

Control: tag -1 patch
From: Romain Porte 
Date: Tue, 2 Nov 2021 15:19:51 +0100
Subject: setup.py: remove 2to3

Should be dropped when package is updated, because latest upstream
releases are not using this flag anymore.

Forward: not-needed
---
 setup.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/setup.py b/setup.py
index 47f3bf5..ce6d239 100755
--- a/setup.py
+++ b/setup.py
@@ -97,7 +97,6 @@ if __name__ == "__main__":
 "Topic :: Software Development",
 ],
 test_suite="tests.AllTests",
-use_2to3=True,
 python_requires=">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*",
 install_requires=[
 "deprecated",


Bug#996578: gsmlib: diff for NMU version 1.10+20120414.gita5e5ae9a-1

2021-11-02 Thread Boyuan Yang
Control: tags 996578 + patch
Control: tags 996578 + pending

Dear maintainer,

I've prepared an NMU for gsmlib (versioned as 1.10+20120414.gita5e5ae9a-1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru gsmlib-1.10+20120414.gita5e5ae9a/debian/changelog gsmlib-
1.10+20120414.gita5e5ae9a/debian/changelog
--- gsmlib-1.10+20120414.gita5e5ae9a/debian/changelog   2021-10-12
13:48:24.0 -0400
+++ gsmlib-1.10+20120414.gita5e5ae9a/debian/changelog   2021-11-02
13:55:54.0 -0400
@@ -1,3 +1,9 @@
+gsmlib (1.10+20120414.gita5e5ae9a-1) unstable; urgency=medium
+
+  * Take over package maintenance via ITS process. (Closes: #996578)
+
+ -- Boyuan Yang   Tue, 02 Nov 2021 13:55:54 -0400
+
 gsmlib (1.10+20120414.gita5e5ae9a-0.5) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru gsmlib-1.10+20120414.gita5e5ae9a/debian/control gsmlib-
1.10+20120414.gita5e5ae9a/debian/control
--- gsmlib-1.10+20120414.gita5e5ae9a/debian/control 2021-10-12
13:47:09.0 -0400
+++ gsmlib-1.10+20120414.gita5e5ae9a/debian/control 2021-11-02
13:55:53.0 -0400
@@ -1,7 +1,7 @@
 Source: gsmlib
 Section: comm
 Priority: optional
-Maintainer: Mark Purcell 
+Maintainer: Boyuan Yang 
 Build-Depends: debhelper (>= 9), dh-autoreconf, autotools-dev, autoconf-
archive
 Standards-Version: 3.9.4
 Homepage: https://github.com/vbouchaud/gsmlib


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


Bug#998345: librust-quickcheck-dev: uninstallable - depends on non-existing package librust-rand-0.7+default-dev

2021-11-02 Thread Jonas Smedegaard
Package: librust-quickcheck-dev
Version: 0.9.2-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The package librust-quickcheck-dev is uninstallable: It depends on
non-existing package librust-rand-0.7+default-dev.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmGBnVoACgkQLHwxRsGg
ASH7HA//c8tHgNDkxlXoZnpiYPMO3LNhe/SGPIoS3Z/fPBYZtP6BnVMzQgiR9yNh
3bfRJDJXVWc8GNWjF6erA5u2qXdcRfb3UdTvcHGUJb31HWS+QuCZAJG0mLiQC8PV
zNe6cHSe0kVONl1ffDttNpWDOgXDUzD1yXzYBAtQ/jkN2WM1v/h5eByGGbaqL/nD
bdJJGeinQVRIx9HHZDCCgpEJICcHWy9UyyI3pvnYgw0+CdBQzKld45XslRi3iDxs
LoGhF8LrPI6R6O3gsVxTCAZ26DdARyjRSMoiF7Op+ZDrlxwy+Bxt9NBigau8p8VT
TM57/7oI1EWgg6mW//uieVJABvC/dXUKQMowhwCqyQxLIBfnSGgyhLU1xGkdDGlV
Pi/BHJr7FF9xEYeZOxKiTIaE0AVgzQm4VQ/Z1hhsRoYReFGzWXQpLaD1bojvlpgu
lzGx/vBp1EF8ijGBwb1U0YAw+bQC/rJ/N8KJldnv7HB5hBX0HeFBK2WpILvX8vg2
sw97EiAxLeYCjLL79TwyQgwYXY2rxm64QY4fNzjdWhj0ZW/9D5e/shbbgIabFQPF
JB7W4/Hy9q8zJOrzymkqEoaqi7KKD8QFFzrkOdZi21PK9ZxRImb4PjdOIa7RryTV
wXcU4lKE2McFA0VCShjzBBq07if8ShFPYINAe23/iSKUl7H2VWg=
=9KVa
-END PGP SIGNATURE-



Bug#998191: lxmusic: diff for NMU version 0.4.7-1.1

2021-11-02 Thread Boyuan Yang
Control: tags 998191 + patch
Control: tags 998191 + pending
X-Debbugs-CC: and...@rep.kiev.ua dreamerwolf...@gmail.com

Dear maintainer,

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

Regards.

diff -Nru lxmusic-0.4.7/debian/changelog lxmusic-0.4.7/debian/changelog
--- lxmusic-0.4.7/debian/changelog  2016-02-21 09:06:08.0 -0500
+++ lxmusic-0.4.7/debian/changelog  2021-11-02 13:47:25.0 -0400
@@ -1,3 +1,11 @@
+lxmusic (0.4.7-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop manual -dbg package in favor of automatic dbgsym package.
+(Closes: #998191)
+
+ -- Boyuan Yang   Tue, 02 Nov 2021 13:47:25 -0400
+
 lxmusic (0.4.7-1) unstable; urgency=low
 
   * Merging upstream version 0.4.7.
diff -Nru lxmusic-0.4.7/debian/control lxmusic-0.4.7/debian/control
--- lxmusic-0.4.7/debian/control2016-02-21 09:05:00.0 -0500
+++ lxmusic-0.4.7/debian/control2021-11-02 13:46:20.0 -0400
@@ -28,14 +28,3 @@
  It is a minimalist music player based on xmms2 and has server/client design.
  The user interface is quite simple, clean, and intuitive. At first glance,
it
  looks similar to one of the famous players on Windows - foobar 2000.
-
-Package: lxmusic-dbg
-Section: debug
-Priority: extra
-Architecture: any
-Depends: ${misc:Depends}, lxmusic (= ${binary:Version})
-Description: LXDE music player (debug)
- LXMusic is a GUI application for the Lightweight X11 Desktop Environment
- (LXDE).
- .
- This package contains the debugging symbols.
diff -Nru lxmusic-0.4.7/debian/rules lxmusic-0.4.7/debian/rules
--- lxmusic-0.4.7/debian/rules  2016-02-21 09:03:38.0 -0500
+++ lxmusic-0.4.7/debian/rules  2021-11-02 13:47:20.0 -0400
@@ -11,4 +11,4 @@
dh_auto_install -- DESTDIR=$(CURDIR)/debian/lxmusic
 
 override_dh_strip:
-   dh_strip --dbg-package=lxmusic-dbg
+   dh_strip --dbgsym-migration='lxmusic-dbg (<< 0.4.7-2~)'


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


Bug#998335: debsums: fails to handle files with spaces

2021-11-02 Thread Tom
Hi Axel

> Thanks for the example. But from where is that package? Doesn't seem
> to be an official Debian package. Am I right, that the package is
> from
> https://apt.homegear.eu/

That's right. I have the following repo in my sources.list.d/:
deb https://apt.homegear.eu/Debian/ bullseye/

If the package itsself is responsible for the entries in
/var/lib/dpkg/status and if there is a way to escape a space, then the
bug should be filed against the package.

> > --- /usr/bin/debsums.orig   2021-11-02 15:34:32.689829644 +0100
> > +++ /usr/bin/debsums2021-11-02 16:49:18.669901591 +0100
> > @@ -264,7 +264,7 @@
> >  $package_name{$field{"Package"}} =
> > $field{"binary:Package"};
> >  }
> >  $installed{$field{"binary:Package"}}{Conffiles} = {
> > -map m!^\s*/(\S+)\s+([\da-f]+)!,
> > +map m!^\s*/(.+)\s+([\da-f]+)!,
> >  grep { not ($ignore_obsolete and / obsolete$/) }
> >  split /\n/, $field{Conffiles}
> >  } if $field{Conffiles};
> 
> Not sure from a first glance either. This \S looks as if was there on
> purpose. Will need a closer look.

I'm not sure either. But if this regex is greedy, it will stop at the
first space. My version stops before the last space before the md5sum.
That being said, my version will also fail (as will the current version
of debsums) if:
- the name contains spaces and
- the last portion after a space contains digits and a-f
- there is no md5sum (which probably should not happen)

Cheers
Tom



Bug#998344: buster-pu: package llvm-toolchain-11/1:11.0.1-2~deb10u1

2021-11-02 Thread Roberto C. Sanchez
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello release managers,

In order to support the update of rustc in buster, which in turn is
needed to support the updates of firefox-esr and thunderbird, I am
proposing an update of llvm-toolchain-11 in buster.  The attached diff
represents the change from the current package in the buster-backports
repository.

As a result of mips build failures with the backport package, I am
running a test build on a mips porter box to verify that the mips
changes result in a successfully built package.

Please advise on when I can proceed with upload.

Regards,

- -Roberto

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEz9ERzDttUsU/BH8iLNd4Xt2nsg8FAmGBdTEACgkQLNd4Xt2n
sg86zA/9HB/c+D/pi9eUvh8hcw/TsQXSElpbncK0rCmIx1V7TFFPSuysVONXDjgk
RMuz8ZVuNd5NRlhlgF45wNivL9TgOXCdARH60J+hdEXFgAgPbsRDkRNlMy6muMSY
RJEmInlK+h3s6BDs8TpMw6DVjfKw1Tj7DAcGv/lZezyCoBZsnVGq6u/SSF+qHrRf
7oV0u5rc5Q8sS0hwe12LMzR8SSWiY+B4LFc7MALuFAuhcoroEjiLHqNceq4IP1mc
zQcBPANUa7PE8KHVgyDWY6RgTJXWlQWP6macFyCUYvYjfc9gzIpXHgI/REocH1QY
9MyZ/lzqhQZbukcZS5kXJw6IelQmQ7kFQk4eLbAy03ipf5bMiI2zWPSvsCqTChra
U87crvx1HnBg5yZsknWMBPocUsh9VYLH1WU+IZx6ZlH9N24Z+QU0mzmyLl834Vju
XjnPY+VYJpU3jDzrlMrzRbmeFvqtDElycPJrFe9ZChajjM3ojJvkutWiaZu0Xc8s
clyqcX9TDfeTM0P1g29uIJgYXfWJdsA21yFS4C1qlpQS7rEEux7f4cKRP/SWGJ/9
nPrtZFjD6W2QRUVaA50VEDLCYqnL82bb3wpPoz87xspJRBGh01P0WnlhmCUAC2iq
ezG1ByC3q26cgjjs8Mi1WfUdrVjwQyLbOUeJECXAdp1wl4PnCyU=
=XlZX
-END PGP SIGNATURE-
commit b3d946dff1649aeba70269aaf68c0323439559c8 (HEAD -> master)
Author: Roberto C. Sánchez 
Date:   Sat Oct 30 13:22:03 2021 -0400

Backport to buster.

* Backport to buster.
  - Disable tests on (big endian) mips due to timeout (i.e., test runtime
exceeds 10h).

diff --git a/debian/changelog b/debian/changelog
index c74466b96..1ffd5c65d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+llvm-toolchain-11 (1:11.0.1-2~deb10u1) buster; urgency=medium
+
+  * Backport to buster.
+- Disable tests on (big endian) mips due to timeout (i.e., test runtime
+  exceeds 10h).
+
+ -- Roberto C. Sánchez   Sat, 30 Oct 2021 13:14:49 -0400
+
 llvm-toolchain-11 (1:11.0.1-2~bpo10+1) buster-backports; urgency=medium
 
   * Rebuild for buster-backports.
diff --git a/debian/clang-tools-11.install b/debian/clang-tools-11.install
index 194e30f5d..a89d42227 100755
--- a/debian/clang-tools-11.install
+++ b/debian/clang-tools-11.install
@@ -32,7 +32,7 @@ usr/lib/llvm-11/bin/pp-trace
 usr/lib/llvm-11/bin/clang-move
 usr/lib/llvm-11/bin/clang-offload-wrapper
 
-[!armel !armhf !ppc64el !hurd-any !s390x !powerpc !ppc64 !mipsel !mips64el 
!sparc64 !riscv64] usr/lib/llvm-11/lib/clang/11.0.1/bin/hwasan_symbolize
+[!armel !armhf !ppc64el !hurd-any !s390x !powerpc !ppc64 !mips !mipsel 
!mips64el !sparc64 !riscv64] 
usr/lib/llvm-11/lib/clang/11.0.1/bin/hwasan_symbolize
 
 clang/tools/scan-build-11  usr/share/clang/
 clang/tools/scan-build-py-11  usr/share/clang/
diff --git a/debian/rules b/debian/rules
index 5aedc9b06..2532a80e2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -196,7 +196,7 @@ endif
 endif
 
 # llvm tests timeout, disable it on mipsel
-ifeq (mipsel,$(DEB_HOST_ARCH))
+ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
RUN_TEST=no
 endif
 


Bug#998343: python3-sphinx-copybutton: clipboard.min.js is missing - causes new black upstream release to fail to build

2021-11-02 Thread Neil Williams
Package: python3-sphinx-copybutton
Version: 0.4.0-1
Severity: normal

I'm not sure if this is the right diagnosis of the problem
but the latest black upstream release (21.9b0) is failing to build
locally for multiple reasons, one of which (after patching out the
others) is:

dh_sphinxdoc: error: 
debian/python-black-doc/usr/share/doc/python-black-doc/html/_static/clipboard.min.js
 is missing

The copybutton package in buster contains clipboard.min.js:
/usr/lib/python3/dist-packages/sphinx_copybutton/_static/clipboard.min.js

https://packages.debian.org/bullseye/all/python3-sphinx-copybutton/filelist

However, this file is missing in the version in bookworm and sid.

Looks like the file is meant to be part of the python3-sphinx-copybutton 
package?
https://salsa.debian.org/python-team/packages/sphinx-copybutton/-/blob/master/sphinx_copybutton/_static/clipboard.min.js

(New upstream version of black also needs yet another sphinx module but
that's a different problem.)

Thanks.


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

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

Versions of packages python3-sphinx-copybutton depends on:
ii  python3 3.9.2-3
ii  python3-sphinx  3.4.3-2

python3-sphinx-copybutton recommends no packages.

Versions of packages python3-sphinx-copybutton suggests:
pn  python-sphinx-copybutton-doc  



Bug#998342: libdevel-nytprof-perl FTCBFS: uses the build architecture ARCHLIB

2021-11-02 Thread Helmut Grohne
Source: libdevel-nytprof-perl
Version: 6.11+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libdevel-nytprof-perl fails to cross build from source, because
debian/rules sets ARCHLIB such that it contains DEB_BUILD_MULTIARCH, but
it operates on he host arch file system tree. Please consider applying
the attached to correctly compute ARCHLIB.

Helmut
--- libdevel-nytprof-perl-6.11+dfsg/debian/changelog
+++ libdevel-nytprof-perl-6.11+dfsg/debian/changelog
@@ -1,3 +1,10 @@
+libdevel-nytprof-perl (6.11+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Set ARCHLIB for the host architecture. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 02 Nov 2021 16:16:44 +0100
+
 libdevel-nytprof-perl (6.11+dfsg-1) unstable; urgency=medium
 
   * Import upstream version 6.11+dfsg.
--- libdevel-nytprof-perl-6.11+dfsg/debian/rules
+++ libdevel-nytprof-perl-6.11+dfsg/debian/rules
@@ -2,7 +2,10 @@
 
 PACKAGE = $(shell dh_listpackages)
 TMP = $(CURDIR)/debian/$(PACKAGE)
-ARCHLIB := $(shell perl -MConfig -e 'print $$Config{vendorarch}')
+include /usr/share/dpkg/architecture.mk
+PERLVER := $(shell perl -MConfig -e 'print $$Config{version}')
+ARCHLIB := $(shell perl 
-I/usr/lib/$(DEB_HOST_MULTIARCH)/perl/cross-config-$(PERLVER) -MConfig -e 
'print $$Config{vendorarch}')
+
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 


Bug#997166: libcdio: FTBFS: cdda-player.c:301:28: error: format not a string literal and no format arguments [-Werror=format-security]

2021-11-02 Thread Rocky Bernstein
Hmm - as best as I can tell this patches things a little differently than
what was done in the git codebase.

It looks like this changes to use library ncursesw whereas change in git
changes the source code and adjusts the source code so that  the previous
curses library is okay to use.

I don't have an opinion on which is preferable, but I note that the
mismatch might cause a problem down the line.


On Tue, Nov 2, 2021 at 12:49 PM Gabriel F. T. Gomes <
gabr...@inconstante.net.br> wrote:

> Hi, Rocky, Lucas,
>
> Thanks for doing all the hard work of reporting and fixing the bug.
> I have just uploaded a new version o libcdio with the fix.
>
> Cheers,
> Gabriel
>


Bug#997089: libreoffice: FTBFS: segfault in '/<>/instdir/sdk/examples/java/Inspector'

2021-11-02 Thread Rene Engelhard
Hi,

Am Thu, Oct 28, 2021 at 07:18:19PM +0200 schrieb Rene Engelhard:
> And interestingly, (after rm'ing the stale unopkg lockfile..) it passed.
> 
> Also after a new attempt with manual
> 
> $ make clean && make subsequencheck
> 
> in odk worked, too.
> 
> 
> Just looks like a flaky test... (Even though I saw it the first time
> here with this report..)

And since then various test build on my laptop, both 7.3 and 7.2 worked,
as did it on the buildd:

https://buildd.debian.org/status/logs.php?pkg=libreoffice=all
(alpha1-1 was a other breakage fixed in -2, -2 failed for an other
reason)
https://buildd.debian.org/status/logs.php?pkg=libreoffice=amd64
https://buildd.debian.org/status/logs.php?pkg=libreoffice=arm64

Can we close this?

Regards,
 
Rene



Bug#998337: Acknowledgement (KeyError: 'setuptools' when using pyproject-build (build))

2021-11-02 Thread Marcin Szewczyk
I couldn't run reportbug on the target machine, forgot to take a look on
bugs of the source package and missed the 994953[1]. Sorry for a
duplicate.


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

-- 
Marcin Szewczyk
http://wodny.org



Bug#997166: libcdio: FTBFS: cdda-player.c:301:28: error: format not a string literal and no format arguments [-Werror=format-security]

2021-11-02 Thread Gabriel F. T. Gomes
Hi, Rocky, Lucas,

Thanks for doing all the hard work of reporting and fixing the bug.
I have just uploaded a new version o libcdio with the fix.

Cheers,
Gabriel



Bug#998341: qemu-system-common: qemu in bullseye-backports is incompatible with bullseye libvirt

2021-11-02 Thread Marcin Juszkiewicz
Package: qemu-system-common
Version: 1:5.2+dfsg-11
Severity: normal
X-Debbugs-Cc: marcin.juszkiew...@linaro.org

I am maintaining Debian support in OpenStack Kolla project. We are
building container images with OpenStack components and provide way to
deploy whole OpenStack from them.

As we have new release cycle now I looked into possible package
upgrades. Newer QEMU in bullseye-backports got my intention.

Then I tried to install it:

root@puchatek /]# apt-get install --no-install-recommends libvirt-clients 
libvirt-daemon-system qemu-block-extra qemu-system -t bullseye-backports 
libvirt-daemon
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 qemu-system-common : Breaks: libvirt-daemon (< 7.2.0-1) but 7.0.0-3 is to be 
installed
E: Unable to correct problems, you have held broken packages.


So it looks like I have to stay with previous version (libvirt maintainer was
never fan of backporting libvirt).

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.14.0-0.bpo.2-arm64 (SMP w/16 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qemu-system-common depends on:
ii  libaio10.3.112-9
ii  libc6  2.31-13+deb11u2
ii  libcap-ng0 0.7.9-2.2+b1
ii  libgbm120.3.5-1
ii  libglib2.0-0   2.66.8-1
ii  libgnutls303.7.1-5
ii  libnettle8 3.7.3-1
ii  libpixman-1-0  0.40.0-1
ii  libseccomp22.5.1-1
pn  liburing1  
pn  libvirglrenderer1  
ii  zlib1g 1:1.2.11.dfsg-2

qemu-system-common recommends no packages.

qemu-system-common suggests no packages.

-- no debconf information



Bug#998109: python3-numpy: numpy.typing is missing

2021-11-02 Thread Sandro Tosi
control: severity -1 important

> This bug is blocking other python packages which require numpy 1.20,
> (and use numpy.typing) so raising severity to serious.

sorry but that's not how RC severity works, that's for policy
violations, which in this case there are none.

I understand you may want to see this fixed sooner rather than later,
so maybe you can submit an MR against the numpy salsa repo to fix
this? i'll then review, merge and upload as needed.

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



Bug#998340: Please take over rsyslog init script

2021-11-02 Thread Michael Biebl
Package: orphan-sysvinit-scripts
Severity: normal

Hi,

I intend to remove the SysV init script from the rsyslog package with the
next upload.

Maybe you are interested in taking maintainership for the file.

I'll possibly also switch over rsyslog from using imuxsock to imjournal,
so rsyslog is able to capture early boot up and late shut down.
Not sure if that falls into the scope of orphan-sysvinit-scripts,
nonetheless I felt it prudent to give you a heads up.

Michael



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

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

Versions of packages orphan-sysvinit-scripts depends on:
ii  ucf  3.0043

orphan-sysvinit-scripts recommends no packages.

orphan-sysvinit-scripts suggests no packages.



Bug#998338: transition: urdfdom

2021-11-02 Thread Sebastian Ramacher
Control: tags -1 moreinfo

On 2021-11-02 16:25:17, Jose Luis Rivero wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team:
> 
> urdfdom library bumped the SOVERSION from 1.x to 3.x. I've run ratt in
> the Open Robotics buildfarm: 
> https://build.osrfoundation.org/job/debian-ratt-builder/123/
> 
> 2021/10/29 11:58:02 Build results:
> 2021/10/29 11:58:02 PASSED: ros-kdl-parser
> 2021/10/29 11:58:02 PASSED: ros-urdf
> 2021/10/29 11:58:02 PASSED: gazebo
> 2021/10/29 11:58:02 PASSED: sdformat
> 2021/10/29 11:58:02 PASSED: ros-rviz
> 2021/10/29 11:58:02 PASSED: ros-robot-state-publisher
> 2021/10/29 11:58:02 PASSED: ros-collada-urdf
> 2021/10/29 11:58:02 PASSED: dart
> 
> results seems fine.
> 
> Ben file:
> 
> title = "urdfdom";
> is_affected = .depends ~ 
> /\b(liburdfdom\-model\-state3\.0|liburdfdom\-model3\.0|liburdfdom\-sensor3\.0|liburdfdom\-tools3\.0|liburdfdom\-world3\.0|liburdfdom\-model|liburdfdom\-model\-state|liburdfdom\-sensor|liburdfdom\-tools|liburdfdom\-world)\b/
> is_good = .depends ~ 
> /\b(liburdfdom\-model\-state3\.0|liburdfdom\-model3\.0|liburdfdom\-sensor3\.0|liburdfdom\-tools3\.0|liburdfdom\-world3\.0)\b/
> is_bad = .depends ~ 
> /\b(liburdfdom\-model|liburdfdom\-model\-state|liburdfdom\-sensor|liburdfdom\-tools|liburdfdom\-world)\b.depends
>  ~ 
> /\b(liburdfdom\-model|liburdfdom\-model\-state|liburdfdom\-sensor|liburdfdom\-tools|liburdfdom\-world)\b//

Why is liburdfom-tools  being renamed? This packages does not contain a
shared library.

Cheers

> 
> Could you please proceed with the transition?
> Thanks!
> 

-- 
Sebastian Ramacher



Bug#998339: nmu: xmlsec1_1.2.32-2

2021-11-02 Thread Rene Engelhard
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

[ nss maintainer X-Debbugs-Cc'ed ]

Hi,

nss 2:3.72-1 uploaded this morning did:

 nss (2:3.72-1) unstable; urgency=medium
[...]
   * debian/libnss3-dev.links.in: Remove xulrunner-nss.pc.
[...]

Without any coordination whatsoever.

This now results in stuff using libxmlsec1-dev (the nss variant) to
FTBFS:

$ pkg-config --libs xmlsec1-nss
Package xulrunner-nss was not found in the pkg-config search path.
Perhaps you should add the directory containing `xulrunner-nss.pc'
to the PKG_CONFIG_PATH environment variable
Package 'xulrunner-nss', required by 'xmlsec1-nss', not found

cf. also the libreoffice autopkgtest which runs ./configure and needs
the build-deps for this:
https://ci.debian.net/data/autopkgtest/testing/amd64/libr/libreoffice/16373758/log.gz
https://ci.debian.net/data/autopkgtest/testing/armhf/libr/libreoffice/16373879/log.gz
https://ci.debian.net/data/autopkgtest/testing/i386/libr/libreoffice/16373931/log.gz
https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/16377878/log.gz
https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/16349711/log.gz

Thankfully libxmlsec seems to write into that file what it detects at
configure stage (in current sid nss.pc) and thus a bin-NMU should
suffice.

So please

nmu xmlsec1_1.2.32-2 . ANY . unstable . -m "rebuild against nss 3.72-1 to fix 
xmlsec1-nss.pc"

Regards,

Rene



Bug#998338: transition: urdfdom

2021-11-02 Thread Jose Luis Rivero
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear release team:

urdfdom library bumped the SOVERSION from 1.x to 3.x. I've run ratt in
the Open Robotics buildfarm: 
https://build.osrfoundation.org/job/debian-ratt-builder/123/

2021/10/29 11:58:02 Build results:
2021/10/29 11:58:02 PASSED: ros-kdl-parser
2021/10/29 11:58:02 PASSED: ros-urdf
2021/10/29 11:58:02 PASSED: gazebo
2021/10/29 11:58:02 PASSED: sdformat
2021/10/29 11:58:02 PASSED: ros-rviz
2021/10/29 11:58:02 PASSED: ros-robot-state-publisher
2021/10/29 11:58:02 PASSED: ros-collada-urdf
2021/10/29 11:58:02 PASSED: dart

results seems fine.

Ben file:

title = "urdfdom";
is_affected = .depends ~ 
/\b(liburdfdom\-model\-state3\.0|liburdfdom\-model3\.0|liburdfdom\-sensor3\.0|liburdfdom\-tools3\.0|liburdfdom\-world3\.0|liburdfdom\-model|liburdfdom\-model\-state|liburdfdom\-sensor|liburdfdom\-tools|liburdfdom\-world)\b/
is_good = .depends ~ 
/\b(liburdfdom\-model\-state3\.0|liburdfdom\-model3\.0|liburdfdom\-sensor3\.0|liburdfdom\-tools3\.0|liburdfdom\-world3\.0)\b/
is_bad = .depends ~ 
/\b(liburdfdom\-model|liburdfdom\-model\-state|liburdfdom\-sensor|liburdfdom\-tools|liburdfdom\-world)\b.depends
 ~ 
/\b(liburdfdom\-model|liburdfdom\-model\-state|liburdfdom\-sensor|liburdfdom\-tools|liburdfdom\-world)\b//

Could you please proceed with the transition?
Thanks!



Bug#998337: KeyError: 'setuptools' when using pyproject-build (build)

2021-11-02 Thread Marcin Szewczyk
Package: python3-virtualenv
Version: 20.4.0+ds-2

An attempt to invoke pyproject-build (build v0.7.0) ends up with:
#v+
* Creating virtualenv isolated environment...

Traceback (most recent call last):
  File "/home/mszewczyk/.local/lib/python3.9/site-packages/build/__main__.py", 
line 372, in main
built = build_call(
  File "/home/mszewczyk/.local/lib/python3.9/site-packages/build/__main__.py", 
line 229, in build_package_via_sdist
sdist = _build(isolation, builder, outdir, 'sdist', config_settings, 
skip_dependency_check)
  File "/home/mszewczyk/.local/lib/python3.9/site-packages/build/__main__.py", 
line 140, in _build
return _build_in_isolated_env(builder, outdir, distribution, 
config_settings)
  File "/home/mszewczyk/.local/lib/python3.9/site-packages/build/__main__.py", 
line 104, in _build_in_isolated_env
with _IsolatedEnvBuilder() as env:
  File "/home/mszewczyk/.local/lib/python3.9/site-packages/build/env.py", line 
101, in __enter__
executable, scripts_dir = _create_isolated_env_virtualenv(self._path)
  File "/home/mszewczyk/.local/lib/python3.9/site-packages/build/env.py", line 
226, in _create_isolated_env_virtualenv
result = virtualenv.cli_run(cmd, setup_logging=False)
  File "/usr/lib/python3/dist-packages/virtualenv/run/__init__.py", line 32, in 
cli_run
of_session.run()
  File "/usr/lib/python3/dist-packages/virtualenv/run/session.py", line 47, in 
run
self._seed()
  File "/usr/lib/python3/dist-packages/virtualenv/run/session.py", line 60, in 
_seed
self.seeder.run(self.creator)
  File 
"/usr/lib/python3/dist-packages/virtualenv/seed/embed/via_app_data/via_app_data.py",
 line 43, in run
with self._get_seed_wheels(creator) as name_to_whl:
  File "/usr/lib/python3.9/contextlib.py", line 117, in __enter__
return next(self.gen)
  File 
"/usr/lib/python3/dist-packages/virtualenv/seed/embed/via_app_data/via_app_data.py",
 line 131, in _get_seed_wheels
if name_to_whl['setuptools'].path.is_relative_to(BUNDLE_FOLDER):
KeyError: 'setuptools'

ERROR 'setuptools'
#v-

It looks like `include-pkg_resources.patch` is the culprit and two
things conflict with each other:

- virtualenv (Debian version)


/usr/lib/python3/dist-packages/virtualenv/seed/embed/via_app_data/via_app_data.py:130,
`if name_to_whl['setuptools'].path.is_relative_to(BUNDLE_FOLDER):`

- build (v0.7.0 from pypi)

…/python3.9/site-packages/build/env.py:224
`--no-setuptools`, probably since:

https://github.com/pypa/build/blame/6cdcdc1f3d7124ed8f8a11d5974a6c0b1c07cc7b/src/build/env.py#L163

Adding `"setuptools" in name_to_whl` or removing `--no-setuptools`
respectively solves the problem (not sure if properly).

-- 
Marcin Szewczyk
http://wodny.org



Bug#990834: ufw: Please set TimeoutStartUSec=infinity to some timedout limit.

2021-11-02 Thread Gera Zoltán
I can confirm that your changes fixed the issue. I did several 10-20
restarts entering my password in different ways, quickly and also very
slowly... all boots were done without a problem.
Thanks a lot Jamie!

2021. 11.  2, kedd keltezéssel 09.07-kor Jamie Strandboge ezt írta:
> On Tue, 02 Nov 2021, Jamie Strandboge wrote:
> 
> > On Mon, 01 Nov 2021, Gera Zoltán wrote:
> > 
> > > It is the ufw oneshot service hanging indefinitely.
> > > 
> > > If you are using disk encryption, there is a high chance you
> > > cannot
> > > input your password fast enough, and around 50% of the time, ufw
> > > startjob hangs. Probably being on a slower wifi network also
> > > helps in
> > > reproduction as some people reported this happening only when
> > > being on
> > > a public wifi.
> > > 
> > > I guess, there is a dependency problem which does not come up
> > > when
> > > everything runs down smoothly and without delay. Probably finding
> > > it
> > > would be the best.
> > > 
> > > I am on Debian bullseye with disk encryption and hit this daily,
> > > so
> > > tell me what info to send! There are also many others affected:
> > > https://unix.stackexchange.com/questions/665144/ufw-not-allowing-to-boot-debian-11
> > 
> > I tried to reproduce this in a VM with LVM encryption and could
> > not. The
> > other thread mentioned that firewalld was not affected by this, so
> > I
> > took a look at its systemd unit. Can you edit
> > /lib/systemd/system/ufw.service to have:
> > 
> > #Before=network.target
> > Before=network-pre.target
> > Wants=network-pre.target
> > 
> > (ie, comment out 'Before=network.target' and then add Before and
> > Wants
> > for network-pre.target). Everything else should be the same.
> > 
> > After making this change, run:
> > 
> > $ sudo systemctl daemon-reload
> > 
> > Then reboot and see if it resolves the issue for you.
> 
> Actually, since you mentioned encrypted partitions, can you also make
> sure that DefaultDependencies=no is commented out? The complete file
> should look like:
> 
> [Unit]
> Description=Uncomplicated firewall
> Documentation=man:ufw(8)
> #DefaultDependencies=no
> #Before=network.target
> Before=network-pre.target
> Wants=network-pre.target
> 
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/lib/ufw/ufw-init start quiet
> ExecStop=/lib/ufw/ufw-init stop
> 
> [Install]
> WantedBy=multi-user.target
> 
> Thanks!
> 



Bug#998335: debsums: fails to handle files with spaces

2021-11-02 Thread Axel Beckert
Hi Tom,

Tom wrote:
> I get a false positive in debsums on a file with a space in the filename:

Thanks for the bug report!

> # debsums -a homegear-zigbee | grep bbaa
> debsums: missing file /etc/homegear/devices/26/bbaaPlug (from homegear-zigbee 
> package)
> # grep bbaa /var/lib/dpkg/info/homegear-zigbee.list 
> /etc/homegear/devices/26/bbaaPlug 013.xml
> # grep bbaa /var/lib/dpkg/info/homegear-zigbee.conffiles
> /etc/homegear/devices/26/bbaaPlug 013.xml
> # ll /etc/homegear/devices/26/bbaaPlug*
> -rw-r--r-- 1 root root 12178 Okt  9 17:14 '/etc/homegear/devices/26/bbaaPlug 
> 013.xml'
> # dpkg-query -L homegear-zigbee |grep bbaa
> /etc/homegear/devices/26/bbaaPlug 013.xml

Thanks for the example. But from where is that package? Doesn't seem
to be an official Debian package. Am I right, that the package is from
https://apt.homegear.eu/?

(Yes, I can construct a package with that characteristica, but being
able to work on the exactly same package might be easier.)

> I tried to fix it myself, but I'm not sure if this is correct:
> 
> --- /usr/bin/debsums.orig 2021-11-02 15:34:32.689829644 +0100
> +++ /usr/bin/debsums  2021-11-02 16:49:18.669901591 +0100
> @@ -264,7 +264,7 @@
>  $package_name{$field{"Package"}} = $field{"binary:Package"};
>  }
>  $installed{$field{"binary:Package"}}{Conffiles} = {
> -map m!^\s*/(\S+)\s+([\da-f]+)!,
> +map m!^\s*/(.+)\s+([\da-f]+)!,
>  grep { not ($ignore_obsolete and / obsolete$/) }
>  split /\n/, $field{Conffiles}
>  } if $field{Conffiles};

Not sure from a first glance either. This \S looks as if was there on
purpose. Will need a closer look.

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#998336: freeglut3-dev: depends on the transitional dummy package libgl1-mesa-dev

2021-11-02 Thread Vincent Lefevre
Package: freeglut3-dev
Version: 2.8.1-6
Severity: normal

freeglut3-dev depends on the transitional dummy package libgl1-mesa-dev
(made transitional on 09 Dec 2019). Its dependencies should be updated.

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

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

Versions of packages freeglut3-dev depends on:
ii  freeglut3 2.8.1-6
ii  libgl1-mesa-dev   21.2.4-1
ii  libglu1-mesa-dev  9.0.1-1
ii  libxext-dev   2:1.3.4-1
ii  libxt-dev 1:1.2.0-1

freeglut3-dev recommends no packages.

freeglut3-dev suggests no packages.

-- no debconf information

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



Bug#995846: FTBFS: Fatal TYPE-ERROR and tests incompatible with PG14

2021-11-02 Thread Christoph Berg
Re: Sébastien Villemot
> I am going to package cl-uax-15 and cl-global-vars (ITPs are marked as
> blocking the present bug), and then upgrade cl-postmodern.

That sounds excellent, merci!

Christoph



Bug#973313: lintian: Salsa CI jobs fail for many sources hosted there

2021-11-02 Thread Shengjing Zhu
On Tue, Nov 2, 2021 at 11:45 PM Colin Watson  wrote:
>
> On Tue, Nov 02, 2021 at 11:18:34PM +0800, Shengjing Zhu wrote:
> > On Tue, Nov 2, 2021 at 10:04 PM Colin Watson  wrote:
> > > Ah yes, thanks for finding that.  So I guess the plausible choices
> > > (without having checked feasibility) are:
> > >
> > >  * cherry-pick the docker-default profile into buster's docker.io
> > >package as a stable update
> > >  * backport the docker.io package wholesale from bullseye to
> > >buster-backports
> > >  * ask Salsa admins to upgrade our runners to bullseye
> > >
> > > Does anyone have opinions on this?  I've CCed the docker.io package
> > > maintainers in case they have any preferences.
> >
> > For the docker.io package part, I'm not aware that salsa infra is
> > using this package.
> > The shared runners are created by docker-machine and the base vm is
> > also provisioned by docker-machine, which doesn't install the
> > docker.io package.
>
> Interesting, thanks.  Is it possibly just a matter of configuring
> docker-machine to use bullseye, then, something like this?
>
> diff --git a/roles/gitlab-runner/templates/gitlab-runner.toml.j2 
> b/roles/gitlab-runner/templates/gitlab-runner.toml.j2
> index 173975c..adec15e 100644
> --- a/roles/gitlab-runner/templates/gitlab-runner.toml.j2
> +++ b/roles/gitlab-runner/templates/gitlab-runner.toml.j2
> @@ -35,7 +35,7 @@ listen_address = ":9252"
>"google-project={{ instance.machine_google_project }}",
>"google-zone={{ instance.machine_google_zone }}",
>"google-machine-type={{ instance.machine_google_machine_type }}",
> -  "google-machine-image=debian-cloud/global/images/family/debian-10",
> +  "google-machine-image=debian-cloud/global/images/family/debian-11",
>"google-disk-size=30",
>"google-disk-type=pd-ssd",
>"google-network=build",
>
> (I'm not deluding myself that I know what I'm doing here, though.)
>

(I'm not salsa admin)

I think the diff only changes the base packages to debian 11, e.g. the
kernel, apparmor packages.
However docker in the vm should always be latest,
https://gitlab.com/gitlab-org/ci-cd/docker-machine/-/blob/main/libmachine/provision/utils.go#L27

It's better that salsa admin could check what happens on the runner vm.

-- 
Shengjing Zhu



Bug#997023: sakura: Incorrect usage of PRIMARY and CLIPBOARD selections

2021-11-02 Thread Andreas Ronnquist
Thanks for your report (and patch) -

As you might have seen, the patch is now included in the git repo
upstream - If a new upstream version takes a longer time, I'll prepare
an updated Debian package including the patch.

best regards, and thank you!
/Andreas Rönnquist
gus...@debian.org



Bug#998335: debsums: fails to handle files with spaces

2021-11-02 Thread Tom
Package: debsums
Version: 3.0.2
Severity: normal

Dear Maintainer,

I get a false positive in debsums on a file with a space in the filename:

# debsums -a homegear-zigbee | grep bbaa
debsums: missing file /etc/homegear/devices/26/bbaaPlug (from homegear-zigbee 
package)
# grep bbaa /var/lib/dpkg/info/homegear-zigbee.list 
/etc/homegear/devices/26/bbaaPlug 013.xml
# grep bbaa /var/lib/dpkg/info/homegear-zigbee.conffiles
/etc/homegear/devices/26/bbaaPlug 013.xml
# ll /etc/homegear/devices/26/bbaaPlug*
-rw-r--r-- 1 root root 12178 Okt  9 17:14 '/etc/homegear/devices/26/bbaaPlug 
013.xml'
# dpkg-query -L homegear-zigbee |grep bbaa
/etc/homegear/devices/26/bbaaPlug 013.xml

Note that debsums reports a missing file "bbaaPlug", not "bbaaPlug 013.xml".
dpkg-query, on the other hand, correctly lists the filename.
Next, I tried to check it it is really the space that causes the problem:

# cp /etc/homegear/devices/26/bbaaPlug\ 013.xml 
/etc/homegear/devices/26/bbaaPlug
# debsums -a homegear-zigbee | grep bbaa
dpkg-query: no path found matching pattern /etc/homegear/devices/26/bbaaPlug

That's strange, I cannot explain that output. After some digging, I found 
/var/lib/dpkg/status.
And there we have:
# grep /etc/homegear/devices/26/bbaaPlug /var/lib/dpkg/status
 /etc/homegear/devices/26/bbaaPlug 013.xml 77462256c1635499de5b2ba4498243ad

I then altered the .list and .conffile

# grep bbaa /var/lib/dpkg/info/homegear-zigbee.list 
/var/lib/dpkg/info/homegear-zigbee.conffiles
/var/lib/dpkg/info/homegear-zigbee.list:/etc/homegear/devices/26/bbaaPlug
/var/lib/dpkg/info/homegear-zigbee.conffiles:/etc/homegear/devices/26/bbaaPlug

# dpkg-query -L homegear-zigbee |grep bbaa
/etc/homegear/devices/26/bbaaPlug

# /usr/bin/debsums -ex homegear-zigbee 
debsums: changed file /etc/homegear/devices/26/bbaaPlug 
(observed:77462256c1635499de5b2ba4498243ad expected:013) (from homegear-zigbee 
package)

It seems that debsums does not process the status file correctly. It is 
confused by the space
in the filename and takes the part after the space as md5sum. In order to 
verify, I tried to
escape the space in the status file. I tried to quote the whole filename with " 
or ', or
escape the space with "\ " but to no avail. It really seems that debsums cannot 
handle spaces
while processing the status file.

I tried to fix it myself, but I'm not sure if this is correct:

--- /usr/bin/debsums.orig   2021-11-02 15:34:32.689829644 +0100
+++ /usr/bin/debsums2021-11-02 16:49:18.669901591 +0100
@@ -264,7 +264,7 @@
 $package_name{$field{"Package"}} = $field{"binary:Package"};
 }
 $installed{$field{"binary:Package"}}{Conffiles} = {
-map m!^\s*/(\S+)\s+([\da-f]+)!,
+map m!^\s*/(.+)\s+([\da-f]+)!,
 grep { not ($ignore_obsolete and / obsolete$/) }
 split /\n/, $field{Conffiles}
 } if $field{Conffiles};


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

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

Versions of packages debsums depends on:
ii  libdpkg-perl  1.20.9
ii  libfile-fnmatch-perl  0.02-2+b8
ii  perl  5.32.1-4+deb11u2
ii  ucf   3.0043

debsums recommends no packages.

Versions of packages debsums suggests:
ii  bash-completion  1:2.11-2

-- debconf information:
* debsums/croncheck: never
* debsums/apt-autogen: true



Bug#997159: burp: FTBFS: src/client/monitor/status_client_ncurses.c:350:9: error: format not a string literal and no format arguments [-Werror=format-security]

2021-11-02 Thread Calogero Lo Leggio

I've temporarily disabled the format-security error:
https://salsa.debian.org/debian/burp/-/commit/625692bd42884fbb97f132967e3c4e70430aaddf


I will contact the developer to raise the issue.



Thanks!


On 23/10/21 21:05, Lucas Nussbaum wrote:

Source: burp
Version: 2.2.18-8
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):

gcc -DHAVE_CONFIG_H -I. -I./src  -fno-strict-aliasing -DSYSCONFDIR=\"/etc/burp\"  
-Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -D_DEFAULT_SOURCE 
-D_XOPEN_SOURCE=600 -DHAVE_NCURSES_H=1 -c -o src/client/protocol2/main-backup_phase2.o `test -f 
'src/client/protocol2/backup_phase2.c' || echo './'`src/client/protocol2/backup_phase2.c
src/client/monitor/status_client_ncurses.c: In function ‘screen_header_ncurses’:
src/client/monitor/status_client_ncurses.c:350:9: error: format not a string 
literal and no format arguments [-Werror=format-security]
   350 | mvprintw(0, col-l-1, date);
   | ^~~~
src/client/monitor/status_client_ncurses.c: In function 
‘update_screen_view_log’:
src/client/monitor/status_client_ncurses.c:752:24: warning: ISO C forbids 
‘return’ with expression, in function returning void [-Wpedantic]
   752 | return update_screen_live_counters_w(sel, x, col);
   |^~
src/client/monitor/status_client_ncurses.c:738:13: note: declared here
   738 | static void update_screen_view_log(struct sel *sel, int *x, int col,
   | ^~
gcc -DHAVE_CONFIG_H -I. -I./src  -fno-strict-aliasing -DSYSCONFDIR=\"/etc/burp\"  
-Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -D_DEFAULT_SOURCE 
-D_XOPEN_SOURCE=600 -DHAVE_NCURSES_H=1 -c -o src/client/protocol2/main-rabin_read.o `test -f 
'src/client/protocol2/rabin_read.c' || echo './'`src/client/protocol2/rabin_read.c
gcc -DHAVE_CONFIG_H -I. -I./src  -fno-strict-aliasing -DSYSCONFDIR=\"/etc/burp\"  
-Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -D_DEFAULT_SOURCE 
-D_XOPEN_SOURCE=600 -DHAVE_NCURSES_H=1 -c -o src/client/protocol2/main-restore.o `test -f 
'src/client/protocol2/restore.c' || echo './'`src/client/protocol2/restore.c
gcc -DHAVE_CONFIG_H -I. -I./src  -fno-strict-aliasing -DSYSCONFDIR=\"/etc/burp\"  
-Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -D_DEFAULT_SOURCE 
-D_XOPEN_SOURCE=600 -DHAVE_NCURSES_H=1 -c -o src/protocol1/main-handy.o `test -f 
'src/protocol1/handy.c' || echo './'`src/protocol1/handy.c
gcc -DHAVE_CONFIG_H -I. -I./src  -fno-strict-aliasing -DSYSCONFDIR=\"/etc/burp\"  
-Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -D_DEFAULT_SOURCE 
-D_XOPEN_SOURCE=600 -DHAVE_NCURSES_H=1 -c -o src/protocol1/main-msg.o `test -f 'src/protocol1/msg.c' 
|| echo './'`src/protocol1/msg.c
gcc -DHAVE_CONFIG_H -I. -I./src  -fno-strict-aliasing -DSYSCONFDIR=\"/etc/burp\"  
-Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -D_DEFAULT_SOURCE 
-D_XOPEN_SOURCE=600 -DHAVE_NCURSES_H=1 -c -o src/protocol1/main-rs_buf.o `test -f 
'src/protocol1/rs_buf.c' || echo './'`src/protocol1/rs_buf.c
cc1: some warnings being treated as errors
make[1]: *** [Makefile:4162: src/client/monitor/main-status_client_ncurses.o] 
Error 1


The full build log is available from:
http://qa-logs.debian.net/2021/10/23/burp_2.2.18-8_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.





OpenPGP_signature
Description: OpenPGP digital signature


Bug#998331: r-cran-tzdb: Embedded Howard Hinnant Date library

2021-11-02 Thread Dirk Eddelbuettel


On 2 November 2021 at 16:09, Andrea Pappacoda wrote:
| Control: close -1
| 
| Thanks for your fast response.
| 
| As you might have guessed I'm not really experienced in Debian 
| packaging, and I didn't know this was acceptable.
| 
| I have no complaints then, I'm closing this :)
| 
| Thanks again for your explanation!

It was more of a hand-wave :)

"In theory" what you suggest is preferable.

"In practice" we also found that having (technically unneccessary) "diffs"
again upstream has its own set of issues, so we tolerate it. In short, we
have bigger issues to solve and the "80/20" rule holds. We're better off
having you package Date, and having it in Debian, and having other things
rounded off, than chasing these small imperfections. At least that what I
think after 25 years here :)  But there are so many of us that someone will
possibly say the opposite.  Just don't listen to them :)

Thanks for your work on Debian,  Dirk

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



Bug#980627: ruby-databojects-mysql

2021-11-02 Thread Daniel Leidert
Am Dienstag, dem 02.11.2021 um 13:36 +0100 schrieb Daniel Leidert:
> Am Mittwoch, dem 27.10.2021 um 11:02 -0300 schrieb Lucas Kanashiro:
> 
> [..]
> > * ruby-databojects-mysql
> [..]

Digging some more: This project has been archived upstream and the homepage
points to https://rom-rb.org/ now, which has active repositories. 

These packages:

* ruby-dataobjects
* ruby-dataobjects-mysql
* ruby-dataobjects-postgres
* ruby-dataobjects-sqlite3

only relate to and depend on each other. They seem to be unused otherwise. I
wonder if we should remove (RoM) them altogether.

Regards, Daniel

-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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


Bug#973313: lintian: Salsa CI jobs fail for many sources hosted there

2021-11-02 Thread Colin Watson
On Tue, Nov 02, 2021 at 11:18:34PM +0800, Shengjing Zhu wrote:
> On Tue, Nov 2, 2021 at 10:04 PM Colin Watson  wrote:
> > Ah yes, thanks for finding that.  So I guess the plausible choices
> > (without having checked feasibility) are:
> >
> >  * cherry-pick the docker-default profile into buster's docker.io
> >package as a stable update
> >  * backport the docker.io package wholesale from bullseye to
> >buster-backports
> >  * ask Salsa admins to upgrade our runners to bullseye
> >
> > Does anyone have opinions on this?  I've CCed the docker.io package
> > maintainers in case they have any preferences.
> 
> For the docker.io package part, I'm not aware that salsa infra is
> using this package.
> The shared runners are created by docker-machine and the base vm is
> also provisioned by docker-machine, which doesn't install the
> docker.io package.

Interesting, thanks.  Is it possibly just a matter of configuring
docker-machine to use bullseye, then, something like this?

diff --git a/roles/gitlab-runner/templates/gitlab-runner.toml.j2 
b/roles/gitlab-runner/templates/gitlab-runner.toml.j2
index 173975c..adec15e 100644
--- a/roles/gitlab-runner/templates/gitlab-runner.toml.j2
+++ b/roles/gitlab-runner/templates/gitlab-runner.toml.j2
@@ -35,7 +35,7 @@ listen_address = ":9252"
   "google-project={{ instance.machine_google_project }}",
   "google-zone={{ instance.machine_google_zone }}",
   "google-machine-type={{ instance.machine_google_machine_type }}",
-  "google-machine-image=debian-cloud/global/images/family/debian-10",
+  "google-machine-image=debian-cloud/global/images/family/debian-11",
   "google-disk-size=30",
   "google-disk-type=pd-ssd",
   "google-network=build",

(I'm not deluding myself that I know what I'm doing here, though.)

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



Bug#998333: RFS: lebiniou/3.63.0-1 -- user-friendly, powerful music visualization / VJing tool

2021-11-02 Thread Olivier Girondel



Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: lebiniou
Version : 3.63.0-1
Upstream Author : Olivier Girondel 
  * URL : https://biniou.net
  * License : GPL-2+
Section : graphics

It builds this binary package:

   lebiniou - user-friendly, powerful music visualization / VJing tool

The package appears to be lintian-clean.

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

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

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

   dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.63.0-1.dsc

Changes since the last upload:

  * New upstream release 3.63.0.

Regards,

--
Olivier Girondel



Bug#998334: RFS: lebiniou-data/3.63.0-1 -- datafiles for Le Biniou

2021-11-02 Thread Olivier Girondel



Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lebiniou-data":

  * Package name: lebiniou-data
Version : 3.63.0-1
Upstream Author : Olivier Girondel 
  * URL : https://biniou.net
  * License : GPL-2+
Section : graphics

It builds this binary package:

 lebiniou-data - datafiles for Le Biniou

The package appears to be lintian-clean.

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

   https://mentors.debian.net/package/lebiniou-data

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

   dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou-data/lebiniou-data_3.63.0-1.dsc

Changes since the last upload:

  * New upstream release 3.63.0.
  * debian/source/lintian-overrides: Updated.

Regards,

--
Olivier Girondel



Bug#998332: ITP: qt6-imageformats -- Qt 6 Image Formats module

2021-11-02 Thread Patrick Franz
Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, delta...@debian.org, 
debian-qt-...@lists.debian.org

* Package name: qt6-imageformats
  Version : 6.2.0
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : LGPL-3 or GPL-2+
  Programming Lang: C++
  Description : Qt 6 Image Formats module

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

This package contains additional Image Format plugins for Qt 6.



Bug#995392: ghostscript: ps2pdf trashes some characters

2021-11-02 Thread Vincent Lefevre
On 2021-11-02 16:25:27 +0100, Vincent Lefevre wrote:
> With commit 8f62213019bc682eeb0ed9467d8841f3770cfda6 upstream,
> I can no longer reproduce any issue, even when
> /usr/share/texlive/texmf-dist/tex/generic/pdftex/glyphtounicode.tex
> from Tex Live 2020 is included and \pdfgentounicode=1 is used.
[...]

To be clear, both commit 8f62213019bc682eeb0ed9467d8841f3770cfda6
and the older commit b4e8434defb8e05ea05bb130b92217290efd2fba
should be needed and be sufficient to solve all the issues.

Commit b4e8434defb8e05ea05bb130b92217290efd2fba fixed

  https://bugs.ghostscript.com/show_bug.cgi?id=704478

triggered by the first simple testcase in this bug (the full story
is that by reducing my testcase, I inadvertently found this other
related issue).

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



Bug#995392: ghostscript: ps2pdf trashes some characters

2021-11-02 Thread Vincent Lefevre
Control: found -1 9.55.0~~rc1~dfsg-1
Control: tags -1 fixed-upstream

With commit 8f62213019bc682eeb0ed9467d8841f3770cfda6 upstream,
I can no longer reproduce any issue, even when
/usr/share/texlive/texmf-dist/tex/generic/pdftex/glyphtounicode.tex
from Tex Live 2020 is included and \pdfgentounicode=1 is used.
However, note that:
  * Yesterday, I could still find an issue, though I could have made
a mistake in my test (e.g. looking at an old file): I've just
tested the same .tex file (with the same included files), and
the issue no longer appears.
  * The upstream bug is still open as an enhancement. Apparently,
Ghostscript no longer generates a (buggy) ToUnicode CMap, and
this could yield issues, but in practice on my files, everything
seems fine with xpdf, atril and pdftotext (not sure what happens,
but if they are using heuristics, they are working fine).

So I'm tagging this as fixed-upstream (the upstream bug should be
sufficient for the enhancement). Note that 9.55.0~~rc1~dfsg-1 from
experimental does not have the commit mentioned above, and I've
checked that this version is still incorrect.

I haven't tested with PDF generated by TeX Live 2021 yet, but I don't
expect any issue.

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



Bug#966141: Please retest with current version

2021-11-02 Thread Diego Roversi
On Thu, 21 Oct 2021 16:10:58 +0100
Neil Williams  wrote:

> Version 18.9 is now only in oldstable - buster.
> 
> Stable has version 20.8 and testing/unstable have 21.4
> 
> Please can you retest with, preferably, 21.4 as the relevant code has
> changed substantially compared to 18.9
> 
 
I confirm that there is no problem with the new stable:

 Preparing to unpack .../black_20.8b1-4_all.deb ...
 Unpacking black (20.8b1-4) ...
 Setting up black (20.8b1-4) ...
 Processing triggers for man-db (2.9.4-2) ...


Thanks,
  Diego.

-- 
Diego Roversi 



Bug#973313: lintian: Salsa CI jobs fail for many sources hosted there

2021-11-02 Thread Shengjing Zhu
On Tue, Nov 2, 2021 at 10:04 PM Colin Watson  wrote:
>
> On Tue, Nov 02, 2021 at 05:21:12PM +0800, xiao sheng wen(肖盛文) wrote:
> > 在 2021/11/2 上午10:01, Colin Watson 写道:
> > > Interestingly, a bullseye VM does *not* exhibit the same issue, which
> > > suggests that it may be possible to track down a change to the kernel,
> > > AppArmor userspace, or Docker that fixed this (I'm guessing as to
> > > plausible packages).  I haven't tried that yet since it's 2am here, but
> > > maybe somebody else can run with this.
> >
> > It's new version Docker in bullseye that fixed this.
> >
> > In bullseye, Docker has a docker-default profile for AppArmor[1], but
> > this profile don't exist in buster.
>
> Ah yes, thanks for finding that.  So I guess the plausible choices
> (without having checked feasibility) are:
>
>  * cherry-pick the docker-default profile into buster's docker.io
>package as a stable update
>  * backport the docker.io package wholesale from bullseye to
>buster-backports
>  * ask Salsa admins to upgrade our runners to bullseye
>
> Does anyone have opinions on this?  I've CCed the docker.io package
> maintainers in case they have any preferences.
>

For the docker.io package part, I'm not aware that salsa infra is
using this package.
The shared runners are created by docker-machine and the base vm is
also provisioned by docker-machine, which doesn't install the
docker.io package.

--
Shengjing Zhu



  1   2   >