Bug#979020: Please replace mime-support with media-types and mailcap in Recommends.

[Charles Plessy]

Le Sat, Jan 02, 2021 at 10:13:09AM +0900, Charles Plessy a écrit :
> 
> Recently I have split the `mime-support` package into two: `media-types`
> supplies /etc/mime.types and `mailcap` supplies the mailcap system.
> `mime-support` remains as a transitional package for the moment.
> 
> I believe that `mutt` and `neomutt` recommend `mime-support` for both
> functionalities.
> 
> At your convenience, can you replace mime-support with media-types and
> mailcap in mutt and neomutt's Recommends ?

Hello,

now that Bullseye is released, it would be great if mutt and neomutt
could recommend media-types and mailcap directly, so that I can remove
mime-support.

Have a nice Sunday,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#980269: Please depend on media-types instead of mime-support

[Charles Plessy]

Le Sun, Jan 17, 2021 at 08:12:10AM +0900, Charles Plessy a écrit :
> 
> `mime-support` is now a transitional package, and it would be great if
> users could be able to remove it after the _Bookworm_ release.
> 
> Please Depend on `media-types` instead of `mime-support` if you only
> need the `/etc/mime.types` file.

Hello,

now that Bullseye is released, it would be great if you could depend on
media-types instead of mime-support!

Have a nice Sunday,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#980275: Please depend on media-types instead of mime-support

[Charles Plessy]

Le Sun, Jan 17, 2021 at 11:28:03AM +0900, Charles Plessy a écrit :
> 
> `mime-support` is now a transitional package, and it would be great if
> users could be able to remove it after the _Bookworm_ release.
> 
> Please Depend on `media-types` instead of `mime-support` if you only
> need the `/etc/mime.types` file.

Hello,

now that Bullseye is released, it would be great if you could depend on
media-types instead of mime-support.

Have a nice Sunday !

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#993232: lxc: Cannot add ipv4 gateway for network device "eth0" when not bringing up the interface.

[John Wong]

Attached lxc-net, lxc-config and ifconfig-lxcbr0.txt for reference, thanks.
(let me know, if need any/more information)

Regards,
John.

On 8/29/21 12:23 PM, John wrote:

Package: lxc
Version: 1:4.0.10-1
Severity: normal
X-Debbugs-Cc: jo...@wonghome.net

Dear Maintainer,

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

After upgraded lxc from 4.0.6-2 to 4.0.10-1. lxc container cannot start.
I find the error with "lxc-start -l trace" like below:

network.c:lxc_network_setup_in_child_namespaces_common:3894 - Cannot add ipv4 
gateway for network device "eth0" when not bringing up the interface
network.c:lxc_setup_network_in_child_namespaces:4038 - Function not 
implemented - Failed to setup netdev
conf.c:lxc_setup:4080 - Failed to setup network
start.c:do_start:1291 - Failed to setup container "vbox"

If I rollback to 4.0.6-2, everything work fine as before.
If I remove the line "lxc.net.0.ipv4.gateway = 10.0.3.1" in 
"/var/lib/lxc/vbox/config" (container config),
the container can start again, but result no network , only loopback 
interface (lo) in container (no eth0 in container).

Thanks.

* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
  ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?

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


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

Kernel: Linux 5.10.0-8-cloud-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 lxc depends on:
ii  bridge-utils 1.7-1
ii  debconf [debconf-2.0]1.5.77
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  iproute2 5.13.0-2
ii  iptables 1.8.7-1
ii  libc62.31-17
ii  libcap2  1:2.44-1
ii  libgcc-s111.2.0-3
ii  liblxc1  1:4.0.10-1
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-3
ii  lsb-base 11.1.0

Versions of packages lxc recommends:
ii  apparmor   2.13.6-10
pn  debootstrap
pn  dirmngr
pn  gnupg  
pn  libpam-cgfs
pn  lxc-templates  
ii  lxcfs  4.0.7-1
ii  openssl1.1.1l-1
pn  rsync  
pn  uidmap 
ii  wget   1.21-1+b1

Versions of packages lxc suggests:
pn  btrfs-progs  
pn  lvm2 
pn  python3-lxc  

-- Configuration Files:
/etc/default/lxc-net changed:
USE_LXC_BRIDGE="true"
LXC_BRIDGE="lxcbr0"
LXC_ADDR="10.0.3.1"
LXC_NETMASK="255.255.255.0"
LXC_NETWORK="10.0.3.0/24"
LXC_DHCP_RANGE="10.0.3.2,10.0.3.254"
LXC_DHCP_MAX="253"
LXC_DHCP_CONFILE=""
LXC_DOMAIN=""


-- debconf information:
   lxc/auto_update_config:



lxcbr0: flags=4099  mtu 1500
inet 10.0.3.1  netmask 255.255.255.0  broadcast 10.0.3.255
ether 00:16:3e:00:00:00  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# Template used to create this container: /usr/share/lxc/templates/lxc-download
# Parameters passed to the template:
# Template script checksum (SHA-1): 273c51343604eb85f7e294c8da0a5eb769d648f3
# For additional config options, please look at lxc.container.conf(5)

# Uncomment the following line to support nesting containers:
#lxc.include = /usr/share/lxc/config/nesting.conf
# (Be aware this has security implications)


# Distribution configuration
lxc.include = /usr/share/lxc/config/common.conf
lxc.include = /usr/share/lxc/config/userns.conf
lxc.arch = linux64
lxc.tty.dir =

# Container specific configuration
#lxc.apparmor.profile = lxc-container-default-cgns-local
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 0
lxc.rootfs.path = dir:/var/lib/lxc/vbox/rootfs
lxc.uts.name = vbox

# Container specific configuration
lxc.start.auto = 1
lxc.start.delay = 0
lxc.idmap = u 0 30 65536
lxc.idmap = g 0 30 65536
lxc.cap.drop = sys_module mac_admin mac_override sys_time mknod net_raw 
sys_rawio sys_admin
lxc.no_new_privs = 1

# Network configuration
lxc.net.0.flags = up
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.hwaddr = 00:16:3e:00:00:03
lxc.net.0.ipv4.address = 10.0.3.3/24
lxc.net.0.ipv4.gateway = 10.0.3.1

lxc.cgroup2.memory.max = 800M
lxc.hook.pre-start = /var/lib/lxc/vbox/pre-start.sh

lxc.mount.entry = proc proc proc 
rw,remount,nodev,nosuid,noexec,relatime,hidepid=2,gid=0 0 0
lxc.mount.entry = tmpfs run tmpfs 
rw,nosuid,nodev,noexec,relatime,mode=0755,size=100M,create=dir 0 0
lxc.mount.entry = tmpfs 

Bug#992656: python3-pyx: incorrect vertical alignment of text output when using the LatexEngine

[Stuart Prescott]

Dear Andre and Joerg,

Thanks for passing on the bug report and especially for the patch. I've 
uploaded the fixed package to Debian's 'unstable' distribution, which is the 
first step in getting it fixed in the bullseye release [1].

regards
Stuart


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#special-case-uploads-to-the-stable-and-oldstable-distributions


-- 
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#993071: kmail: symbol lookup error: /lib/x86_64-linux-gnu/libKF5Libkleo.so.5: undefined symbol: _ZN5GpgME6UserID9SignatureltERKS1_

[Norbert Preining]

On Sat, 28 Aug 2021, Johannes Rohr wrote:
> >> libgpgmepp.so.6 => /usr/local/lib/libgpgmepp.so.6 (0x7efde318f000)
> > That is a version you compiled yourself, and you cannot expect that this
> > is supported.
> 
> Yikes. Must have done that ages ago and forgotten about it.

Does it now work?

Best

Norbert

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

Bug#993231: gpsd-clients: Incorrect path to desktop icon

[Petter Reinholdtsen]

Package: gpsd-clients
Version: 3.22-4

According to
https://appstream.debian.org/sid/main/issues/gpsd-clients.html >,
the icon setting in the desktop files point to
/usr/local/share/gpsd/icons/gpsd-logo.png.  The problematic file is in
packaging/X11/xgps.desktop and packaging/X11/xgpsspeed.desktop in the
source.

-- 
Happy hacking
Petter Reinholdtsen

Bug#993230: mirror listing update for mirror.nju.edu.cn

[YAO Ge]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: mirror.nju.edu.cn
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: YAO Ge 
Country: CN China
Location: Nanjing
Sponsor: eScience Center, Nanjing University https://sci.nju.edu.cn
Comment: http/https/rsync
 ://mirror.nju.edu.cn/
 
 debian
 debian-archive
 debian-cd
 debian-nonfree
 debian-security
 




Trace Url: http://mirror.nju.edu.cn/debian/project/trace/
Trace Url: http://mirror.nju.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.nju.edu.cn/debian/project/trace/mirror.nju.edu.cn

Bug#993229: fontconfig: fclist FcPatternFormat(3) mismatch from documentation

[Thorsten Glaser]

Package: fontconfig
Version: 2.13.1-4.2
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

fc-list(1) refers to FcPatternFormat(3) for its -f parameter
(which, incidentally, is in a different, not installed by
default, package). The latter:

   fclist
  Expands to the output of the default output format of the
  fc-list command on the pattern, without the final newline.

This is however untrue:

tglase@tglase-nb:~ $ fc-list -f '%{=fclist}\n' | fgrep Umpush-Light.otf
/usr/share/fonts/opentype/tlwg/Umpush-Light.otf: 
Umpush:familylang=en:style=Light:stylelang=en:fullname=Umpush 
Light:fullnamelang=en:slant=0:weight=50:width=100:foundry=PfEd:index=0:outline=True:scalable=True:charset=20-7e
 a0-ff 131 152-153 237 2bc 2c6-2c7 2d7 2da 2dc 303 331 e01-e3b e3f-e5b 
2002-2003 200b-2010 2013-2015 2017-201e 2020-2022 2026 2030 2032-2033 2039-203a 
203c 203e 2044 207f 2122 25cc f700-f720 
fb00-fb04:lang=aa|ay|bi|br|ch|da|de|en|es|eu|fj|fo|fur|fy|gd|gl|gv|ho|ia|id|ie|io|is|it|lb|mg|nb|nds|nl|nn|no|nr|oc|om|pt|rm|sma|smj|so|sq|ss|st|sv|sw|th|tl|ts|uz|vo|wa|xh|yap|zu|an|fil|ht|jv|kj|kwm|li|ms|ng|pap-an|pap-aw|rn|rw|sc|sg|sn|su|za:fontversion=65667:capability=otlayout\:DFLT
 otlayout\:latn 
otlayout\:thai:fontformat=CFF:decorative=False:postscriptname=Umpush-Light:color=False:symbol=False:variable=False
tglase@tglase-nb:~ $ fc-list | fgrep Umpush-Light.otf
/usr/share/fonts/opentype/tlwg/Umpush-Light.otf: Umpush:style=Light

I’ve not checked whether the other ones are similarily untrue.


(Perhaps you also wish to move the FcPatternFormat(3) manpage,
and any others that are necessary for the section 1 manpages,
to the main package?)


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

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

Versions of packages fontconfig depends on:
ii  fontconfig-config  2.13.1-4.2
ii  libc6  2.31-13
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1

fontconfig recommends no packages.

fontconfig suggests no packages.

-- no debconf information

Bug#915541: [Debian-med-packaging] Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Étienne Mollier]

Good day,

Andreas Tille, on 2021-08-28:
> Thanks for the patch.  I'll upload this soon.

I noticed a CITATIONS file at the root of the source code, which
might contain information suitable for debian/upstream/metadata.
I suppose it would be fair to reference Ole's work appropriately
as we do for the other publications.

Hope this helps,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#993228: buster-pu: package gthumb/3:3.6.2-4+deb10u1

[Thorsten Alteholz]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu


The attached debdiff for gthumb fixes CVE-2019-20326 in Buster.
The additional patch fixes another non-security related bug and is 
needed to apply the upstream patch for the CVE.


The CVE is marked as no-dsa by the security team.

After upload of DLA-2066-1 to Jessie-LTS no one complained about 
something broken.


  Thorsten
diff -Nru gthumb-3.6.2/debian/changelog gthumb-3.6.2/debian/changelog
--- gthumb-3.6.2/debian/changelog   2019-02-24 22:17:43.0 +0100
+++ gthumb-3.6.2/debian/changelog   2021-08-26 21:03:02.0 +0200
@@ -1,3 +1,15 @@
+gthumb (3:3.6.2-4+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2019-20326 (Closes: #948197)
+A heap-based buffer overflow in _cairo_image_surface_create_from_jpeg()
+in extensions/cairo_io/cairo-image-surface-jpeg.c allows attackers to
+cause a crash and potentially execute arbitrary code via a crafted JPEG
+file.
+  * additional fix in case orientation swaps width and height
+
+ -- Thorsten Alteholz   Thu, 26 Aug 2021 21:03:02 +0200
+
 gthumb (3:3.6.2-4) unstable; urgency=medium
 
   * debian/control:
diff -Nru gthumb-3.6.2/debian/patches/CVE-2019-20326.patch 
gthumb-3.6.2/debian/patches/CVE-2019-20326.patch
--- gthumb-3.6.2/debian/patches/CVE-2019-20326.patch1970-01-01 
01:00:00.0 +0100
+++ gthumb-3.6.2/debian/patches/CVE-2019-20326.patch2021-08-24 
12:54:08.0 +0200
@@ -0,0 +1,105 @@
+Index: gthumb-3.6.2/extensions/cairo_io/cairo-image-surface-jpeg.c
+===
+--- gthumb-3.6.2.orig/extensions/cairo_io/cairo-image-surface-jpeg.c   
2021-08-24 12:54:05.412649431 +0200
 gthumb-3.6.2/extensions/cairo_io/cairo-image-surface-jpeg.c
2021-08-24 12:54:05.408649432 +0200
+@@ -171,6 +171,7 @@
+   unsigned char *surface_row;
+   JSAMPARRAY buffer;
+   intbuffer_stride;
++  intscanned_lines;
+   JDIMENSION n_lines;
+   JSAMPARRAY buffer_row;
+   intl;
+@@ -294,6 +295,7 @@
+   _cairo_metadata_set_has_alpha (metadata, FALSE);
+   surface_data = _cairo_image_surface_flush_and_get_data (surface);
+   surface_row = surface_data + line_start;
++  scanned_lines = 0;
+ 
+   switch (srcinfo.out_color_space) {
+   case JCS_CMYK:
+@@ -309,6 +311,8 @@
+   goto stop_loading;
+ 
+   n_lines = jpeg_read_scanlines (, 
buffer, srcinfo.rec_outbuf_height);
++  if (scanned_lines + n_lines > output_height)
++  n_lines = output_height - scanned_lines;
+ 
+   buffer_row = buffer;
+   for (l = 0; l < n_lines; l++) {
+@@ -345,6 +349,7 @@
+ 
+   surface_row += line_step;
+   buffer_row += buffer_stride;
++  scanned_lines += 1;
+   }
+   }
+   }
+@@ -357,6 +362,8 @@
+   goto stop_loading;
+ 
+   n_lines = jpeg_read_scanlines (, 
buffer, srcinfo.rec_outbuf_height);
++  if (scanned_lines + n_lines > output_height)
++  n_lines = output_height - scanned_lines;
+ 
+   buffer_row = buffer;
+   for (l = 0; l < n_lines; l++) {
+@@ -377,6 +384,7 @@
+ 
+   surface_row += line_step;
+   buffer_row += buffer_stride;
++  scanned_lines += 1;
+   }
+   }
+   }
+@@ -389,6 +397,8 @@
+   goto stop_loading;
+ 
+   n_lines = jpeg_read_scanlines (, 
buffer, srcinfo.rec_outbuf_height);
++  if (scanned_lines + n_lines > output_height)
++  n_lines = output_height - scanned_lines;
+ 
+   buffer_row = buffer;
+   for (l = 0; l < n_lines; l++) {
+@@ -411,6 +421,7 @@
+ 
+   surface_row += line_step;
+   buffer_row += buffer_stride;
++  scanned_lines += 1;
+   }
+   }
+   }
+@@ -436,6 +447,8 @@
+   goto stop_loading;
+ 
+   n_lines = 

Bug#993219: [debian-mysql] Bug#993219: mariadb-server-core: Akonadi database - mysql_upgrade fails always with "FATAL ERROR: Can't execute 'mysqlcheck'"

[Otto Kekäläinen]

Control: tags -1 moreinfo

Hello!

This is not a bug in the Debian packaging and not really an upstream bug either.

The error message seems pretty clear:
> [ERROR] InnoDB: Upgrade after a crash is not supported. The redo log was 
> created with MariaDB 10.3.27.

Before you upgrade, you need to ensure your database shuts down
correctly and cleanly. If it did not shut down cleanly on 10.3.27, you
need to start it again with 10.3.27, let the startup do the error
recovery, and then shut it down cleanly. Only after that can you
attempt to upgrade to 10.5 again.

Please do that and then tell me if you got the database started on 10.5.

Bug#993222: ffmpeg: Having libvpx 1.10.0-1 installed gives "ABI version mismatch" error

[Jan]

Package: ffmpeg
Version: 7:4.4-5
Severity: normal

Dear Maintainer,

A recent apt-upgrade installed the latest version of libvpx, 1.10.0-1,
on my system. The next time I tried to encode a video with VP8, it gave
the error message "Failed to initialize encoder: ABI version mismatch".
Downgrading to the previous version, 1.9.0-1, fixed the issue.
FFmpeg should declare its incompatibility with 1.10.0-1 so the package
gets kept back.
Besides that, no issues with the package. Thank you for maintaining it!

Sincerely,
Jan

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

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

Versions of packages ffmpeg depends on:
ii  libavcodec587:4.4-5
ii  libavdevice58   7:4.4-5
ii  libavfilter77:4.4-5
ii  libavformat58   7:4.4-5
ii  libavutil56 7:4.4-5
ii  libc6   2.31-17
ii  libpostproc55   7:4.4-5
ii  libsdl2-2.0-0   2.0.14+dfsg2-3
ii  libswresample3  7:4.4-5
ii  libswscale5 7:4.4-5

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

Bug#989453: Gentle ping

[Alexey Brodkin]

This is just a gentle reminder - we need this for ARC port for Debian.
As Vineet has mentioned Wiki was properly updated.

Is there anything else blocking this one?

-Alexey

X-Debbugs-CC: 
linux-snps-...@lists.infradead.org,guil...@debian.org,hel...@subdivi.de

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

[Tobias Frost]

Uploaded.

Bug#992277: protontricks: With any command, fails with "KeyError: 'LibraryFolders'"

[Stephan Lachnit]

Hi,


thanks for reporting. I can confirm this. I will fix it with the version 
1.6.0, which has been released 3 weeks ago.


Since I don't have much time right now, it will probably stay in this 
state for the next couple of weeks (sorry).



Regards

Stephan


On Mon, 16 Aug 2021 09:48:41 -0700 Brian Vaughan  
wrote:


> Package: protontricks
> Version: 1.5.0-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: bgvaug...@gmail.com
>
> Dear Maintainer,
>
> Simply executing 'protontricks' shows the usage instructions. 
Executing it with

> commands results in a Python error message.
>
> $ protontricks -s "No Man's Sky"
> Traceback (most recent call last):
> File "/usr/bin/protontricks", line 33, in 
> sys.exit(load_entry_point('protontricks==1.5.0', 'console_scripts',
> 'protontricks')())
> File "/usr/lib/python3/dist-packages/protontricks/cli.py", line 167, 
in main

> steam_lib_paths = get_steam_lib_paths(steam_path)
> File "/usr/lib/python3/dist-packages/protontricks/steam.py", line 613, in
> get_steam_lib_paths
> library_folders = parse_library_folders(folders_vdf_path.read_text())
> File "/usr/lib/python3/dist-packages/protontricks/steam.py", line 597, in
> parse_library_folders
> Path(value) for key, value in vdf_data["LibraryFolders"].items()
> KeyError: 'LibraryFolders'
>
> $ protontricks --gui
> Traceback (most recent call last):
> File "/usr/bin/protontricks", line 33, in 
> sys.exit(load_entry_point('protontricks==1.5.0', 'console_scripts',
> 'protontricks')())
> File "/usr/lib/python3/dist-packages/protontricks/cli.py", line 167, 
in main

> steam_lib_paths = get_steam_lib_paths(steam_path)
> File "/usr/lib/python3/dist-packages/protontricks/steam.py", line 613, in
> get_steam_lib_paths
> library_folders = parse_library_folders(folders_vdf_path.read_text())
> File "/usr/lib/python3/dist-packages/protontricks/steam.py", line 597, in
> parse_library_folders
> Path(value) for key, value in vdf_data["LibraryFolders"].items()
> KeyError: 'LibraryFolders'
>
> I had previously installed protontricks as a normal user, using pipx, 
following

> the instructions at https://github.com/Matoking/protontricks and used it
> successfully. I uninstalled it, using pipx, prior to installing the 
Debian

> package.
>
>
> -- System Information:
> Debian Release: 11.0
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE not

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

Bug#993221: RFS: lebiniou-data/3.61.1-1 -- datafiles for Le Biniou

[Tobias Frost]

Uploaded, thanks for your contribution!

Just a note: The changes were only debian package changes,
just bump the Debian revision to -2 ... no need to cut a new
upstream release...

--
tobi

Bug#993227: gramps: Error installing the PostgreSQL addon into Gramps

[Jeffry J. Smith]

Package: gramps
Version: 5.1.3-1
Severity: minor
X-Debbugs-Cc: jsmith+debb...@alum.mit.edu

Dear Maintainer,


   * What led up to the situation?
   Trying to install the PostgreSQL addon for Gramps

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Ran the Gramps Plugin manager, chose install for postgreSQL

   * What was the outcome of this action?
   "The following addon had errors: PostGreSQL"

   * What outcome did you expect instead?
   Installation of the addon


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
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 gramps depends on:
ii  gir1.2-gtk-3.03.24.30-2
ii  librsvg2-22.50.3+dfsg-1
ii  python3   3.9.2-3
ii  python3-bsddb36.2.9-1
ii  python3-gi3.40.1-2
ii  python3-gi-cairo  3.40.1-2
ii  xdg-utils 1.1.3-4.1

Versions of packages gramps recommends:
ii  gir1.2-geocodeglib-1.0  3.26.2-2
ii  gir1.2-gexiv2-0.10  0.12.1-1
ii  gir1.2-osmgpsmap-1.01.2.0-1
ii  graphviz2.42.2-5
ii  python3-icu 2.5-1+b2

Versions of packages gramps suggests:
ii  fonts-freefont-ttf20120503-10
ii  gir1.2-goocanvas-2.0  2.0.4-1+b1
ii  gir1.2-gtkspell3-3.0  3.0.10-1
ii  python3-numpy 1:1.19.5-1
ii  python3-pil   8.1.2+dfsg-0.3
ii  rcs   5.10.0-1

PostgreSQL installed:
ii  postgresql13+225   all
ii  postgresql-13 13.4-2   amd64
ii  postgresql-client 13+225   all
ii  postgresql-client-13  13.4-2   amd64
ii  postgresql-client-common  225  all
ii  postgresql-common 225  all
ii  postgresql-contrib13+225   all
ii  postgresql-doc13+225   all
ii  postgresql-doc-13 13.4-2   all
ii  postgresql-filedump   13.1-1   amd64


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
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 gramps depends on:
ii  gir1.2-gtk-3.03.24.30-2
ii  librsvg2-22.50.3+dfsg-1
ii  python3   3.9.2-3
ii  python3-bsddb36.2.9-1
ii  python3-gi3.40.1-2
ii  python3-gi-cairo  3.40.1-2
ii  xdg-utils 1.1.3-4.1

Versions of packages gramps recommends:
ii  gir1.2-geocodeglib-1.0  3.26.2-2
ii  gir1.2-gexiv2-0.10  0.12.1-1
ii  gir1.2-osmgpsmap-1.01.2.0-1
ii  graphviz2.42.2-5
ii  python3-icu 2.5-1+b2

Versions of packages gramps suggests:
ii  fonts-freefont-ttf20120503-10
ii  gir1.2-goocanvas-2.0  2.0.4-1+b1
ii  gir1.2-gtkspell3-3.0  3.0.10-1
ii  python3-numpy 1:1.19.5-1
ii  python3-pil   8.1.2+dfsg-0.3
ii  rcs   5.10.0-1

PostgreSQL installed:


-- no debconf information



-- no debconf information

Bug#992920: proftpd-mod-crypto: sftp connection aborts with "Corrupted MAC on input"

[Hilmar Preuße]

Am 25.08.2021 um 04:50 teilte Miguel Cruz mit:

Hi,


Since upgrading to bullseye, proftpd's sftp server fails with some MAC 
algorithms.


Could you check these packages and report if they work?

https://freeshell.de/hille42/992920/

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#878943: gnome-terminal: 3.38 regression: one-dimensional window maximize no longer possible

[Antos Andras]

Package: gnome-terminal
Version: 3.38.3-1
Followup-For: Bug #878943

Dear Maintainer,

I also confirm this annoying bug.
I run gnome-flashback and metacity.
Other windows work as expected with "toggle maximize vertically" and 
"toggle maximize horizontally", but gnome-terminal does not.

Now I have experienced it with gnome 3.38 (and gnome-tweak-tool 3.34) since
upgrading to bullseye (but perhaps I did also with buster, just found some 
workaround 2 years ago, which was broken by the upgrade).


I guess the original bug report meant version 3.26, not 2.26, everywhere, 
including the bug title.


Also, in gnome-tweak-tool the relevant tab is now "Window titlebars", not
"Windows".

Andras

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
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)

Versions of packages gnome-terminal depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.20-2
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gnome-terminal-data  3.38.3-1
ii  gsettings-desktop-schemas3.38.0-2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13
ii  libdconf10.38.0-2
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libpango-1.0-0   1.46.2-3
ii  libuuid1 2.36.1-8
ii  libvte-2.91-00.62.3-1
ii  libx11-6 2:1.7.2-1

Versions of packages gnome-terminal recommends:
ii  gvfs   1.46.2-1
pn  nautilus-extension-gnome-terminal  
pn  yelp   

gnome-terminal suggests no packages.

-- no debconf information

Bug#993226: ITP: r-other-virfinder -- identifying viral sequences from metagenomic data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-other-virfinder -- identifying viral sequences from metagenomic 
data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-other-virfinder
  Version : 1.1
  Upstream Author : Jie Ren, Nathan Ahlgren, Jed Fuhrman, Fengzhu Sun
* URL : https://github.com/jessieren/VirFinder
* License : GPL-2+
  Programming Lang: GNU R
  Description : identifying viral sequences from metagenomic data
 The package provides functions to predict viral sequences in a fasta file.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-other-virfinder

Bug#982626: autoconf: Ships identical NEWS and NEWS.Debian files

[Sven Joachim]

Control: tags -1 + patch

On 2021-02-12 17:35 +0100, Guillem Jover wrote:

> Package: autoconf
> Version: 2.69-14
> Severity: normal
>
> Hi!
>
> This package ships identical NEWS and NEWS.Debian file. This means no
> upstream NEWS file is shipped, where all new features are described
> in a concise way.

The simple attached patch works for me, fixing the problem where
dh_installdocs would install the upstream NEWS file as intended, only to
overwrite it with the one from the debian/ directory two lines later.

Cheers,
   Sven

diff -Nru autoconf-2.71/debian/autoconf.docs autoconf-2.71/debian/autoconf.docs
--- autoconf-2.71/debian/autoconf.docs	2020-12-20 11:16:50.0 +0100
+++ autoconf-2.71/debian/autoconf.docs	2021-08-28 23:01:10.0 +0200
@@ -1,3 +1,2 @@
 NEWS
 README
-debian/NEWS

Bug#993225: bullseye-pu: package ublock-origin/1.37.0+dfsg-1~deb11u1

[Markus Koschany]

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

[ Reason ]

Fixing CVE-2021-36773 in Bullseye and updating various filter lists.

[ Impact ]

CVE-2021-36773 would be unfixed.

[ Tests ]

I have tested the update on a Bullseye system and it works for me.

[ Risks ]

There are no risks involved since ublock-origin is only an addon for
Firefox and Chromium. Potential r-deps don't exist. We have
sucessfully updated ublock-origin in the past hence why I believe an
update is safe and it would benefit users in various ways.

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

Regards,

Markus

Bug#964284: guile-gnutls: update to use guile 3.0

[Vagrant Cascadian]

I talked to rlb breifly who thought recent versions of guile-3.0 in
Debian may work around and/or fix the triggering issue for
guile-gnutls. Would you be up for trying to switch guile-gnutls to
guile-3.0 again?

Thanks for considering!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#993128: libvpx6: Unable to use camera or share screen on WebRTC conferences

[François Revol]

Hi,

same here,
can't get my webcam to stream to Jitsi meet from Chromium 
90.0.4430.212-1 and libvpx6 1.10.0-1. Same error.


Downgrading to libvpx6 1.9.0-1 from 
http://snapshot.debian.org/archive/debian/20201210T025900Z fixes it.


François.

Bug#993224: buster-pu: package ublock-origin/1.37.0+dfsg-1~deb10u1

[Markus Koschany]

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

[ Reason ]

Fixing CVE-2021-36773 in Buster and updating various filter lists.

[ Impact ]

CVE-2021-36773 would be unfixed.

[ Tests ]

I have tested the update on a Buster system and it works for me.

[ Risks ]

There are no risks involved since ublock-origin is only an addon for
Firefox and Chromium. Potential r-deps don't exist. We have
sucessfully updated ublock-origin in the past hence why I believe an
update is safe and it would benefit users in various ways.

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

Regards,

Markus

Bug#984305: gcc 11 is currently not installable

[Julien Puydt]

Hi,

I apparently can't install g++ 11 at the moment:

# LANG=C apt-get -t experimental install g++
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:
 cpp-11 : Depends: gcc-11-base (= 11.2.0-1) but 11.2.0-3 is to be
installed
 g++-11 : Depends: gcc-11-base (= 11.2.0-1) but 11.2.0-3 is to be
installed
  Depends: libstdc++-11-dev (= 11.2.0-1) but it is not going to
be installed
 gcc-11 : Depends: gcc-11-base (= 11.2.0-1) but 11.2.0-3 is to be
installed
  Depends: libgcc-11-dev (= 11.2.0-1) but it is not going to be
installed
E: Unable to correct problems, you have held broken packages.


so I guess I'll work on it at a later point.

>From the look of it, we're missing #include  at some places, at
least, so it probably won't hurt too much.

Cheers,

J.Puydt

Bug#915541: [Debian-med-packaging] Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Andreas Tille]

On Sat, Aug 28, 2021 at 10:00:12PM +0200, Étienne Mollier wrote:
> Andreas Tille, on 2021-08-28:
> > Thanks for the patch.  I'll upload this soon.
> 
> I noticed a CITATIONS file at the root of the source code, which
> might contain information suitable for debian/upstream/metadata.
> I suppose it would be fair to reference Ole's work appropriately
> as we do for the other publications.
> 
> Hope this helps,  :)

Thanks for the good hint - done.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#993179: ncurses: enable format function attributes by default

[Thomas Dickey]

On Sat, Aug 28, 2021 at 03:47:37PM +0200, Christian Göttsche wrote:
> On Sat, 28 Aug 2021 at 15:27, Thomas Dickey  wrote:
> >
> > sure - they're conditioned on a nonstandard extension to C.
> > Debian can provide some patch which hardcodes that condition,
> > but as I recall it, there's no clean way to provide this in
> > standard C.
> >
> 
> Yes, these function attributes are GNU extensions.
> But GCC_PRINTFLIKE is defined via `__attribute__`[1], and if __GNUC__
> is not set, `__attribute__` is defined empty.
> So the attributes are only enabled if the compiler defines __GNUC__
> and then the compiler should support those.

I believe you're misreading the source-code.

The GCC_PRINTF symbol is defined if the (build-time) configure check decides
that the compiler supports the feature (i.e., while the compiler may accept
__attribute__, it may not accept a particular parameter).  Ditto for GCC_SCANF.

Configure check here:

https://github.com/ThomasDickey/my-autoconf-snapshots/blob/master/AcSplit/CF_GCC_ATTRIBUTES

Since ncurses does build and work with a far wider range of compilers than
Debian uses, it would be appropriate for Debian to use a patch to address
this issue, which sometime might be useful in upstream ncurses.
 
> [1]: 
> https://sources.debian.org/src/ncurses/6.2+20201114-4/include/curses.h.in/#L521
> [2]: 
> https://sources.debian.org/src/ncurses/6.2+20201114-4/include/curses.h.in/#L508

fwiw, I had a to-do item in this area based on my comments here
(I noticed some places where the attribute was not visible):

https://github.com/tmux/tmux/pull/2851 

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#981823: librust-alacritty-terminal-dev is not installable

[James McCoy]

On Sat, Aug 28, 2021, 15:39 Steve Langasek 
wrote:

> Note that although rust-alacritty-terminal may no longer need
> rust-terminfo,
> if it still depends on rust-vte, then the package is still not buildable
> because the only version of rust-vte in the archive is 0.3 and
> rust-alacritty-terminal requires 0.8.
>

Yeah, I'm working my way through the dependency stack.  Rust-vte and
rust-alacritty-terminal are going to be updated.

>

Bug#993223: gnome-screenshot: Capture of 3840x2160 screen limited to upper left 1920x1080 pixels

[J.D.]

Package: gnome-screenshot
Version: 3.38.0-1
Severity: important
X-Debbugs-Cc: j...@freeshell.org

Dear Maintainer,

After upgrading to Debian 11, gnome-screenshot could not capture an
entire 3840x2160 screen with Capture Area -> Screen.  Only the upper
left 1920x1080 pixels were captured correctly with the remaining pixels
black.

Version 40.0-1 from the testing distribution yielded the same result.

Installing the old version 3.30.0-2 from Debian 10 on the upgraded
system allowed the entire 3840x2160 screen to be captured again.


-- System Information:
Debian Release: 11.0
  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/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-screenshot depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  libc62.31-13
ii  libcairo21.16.0-5
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libhandy-1-0 1.0.3-2
ii  libx11-6 2:1.7.2-1
ii  libxext6 2:1.3.3-1.1

gnome-screenshot recommends no packages.

gnome-screenshot suggests no packages.

-- no debconf information

Bug#992917: grok: FTBFS due to RPC removal from glibc

[Stig Sandbeck Mathisen]

On Wed, Aug 25, 2021 at 12:46:40AM +0200, Aurelien Jarno wrote:
> Source: grok
> Version: 1.20110708.1-4.5
> Severity: serious
> Tags: patch ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> 
> The glibc SunRPC implementation has been marked obsolete for some time.
> It has been removed upstream from glibc 2.32, and it got disabled in the
> recent glibc uploads. The TI RPC implementation should be used instead,
> which also brings new features (IPv6, Kerberos support, ...).
> 
> For this reason grok now fails to build from source. You will find
> attached a patch to switch to the TI RPC implementation, fixing the
> FTBFS.
> 
> Regards,
> Aurelien

Hello,

Thank you for the bug report and patch.  I did a slight adjustment, adding the
parameters in debian/rules, and targeting the "gnu" libc, see
https://salsa.debian.org/debian/grok/-/commit/fe4c4b549ae2595007271df7502feb54115f4dda

-- 
Stig Sandbeck Mathisen

Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Andreas Tille]

Thanks for the patch.  I'll upload this soon.

On Sat, Aug 28, 2021 at 01:48:56PM -0400, Ian Turner wrote:
> Thanks Andreas.
> 
> On 8/28/21 12:57 PM, Andreas Tille wrote:
> > Patches are always welcome.
> 
> Attached is a patch that removes all mentions of the --bibtex or --citation
> parameters, or demands for 1 EUR, throughout the codebase. It includes
> the patch you already committed, so it should serve as a drop-in
> replacement.
> 
> I would also like to say to Ole that I hope you can understand that this is
> not personal in any way.
> 
> Ian
> 

> diff --git a/src/env_parallel.dash b/src/env_parallel.dash
> index 0674942..878edc6 100755
> --- a/src/env_parallel.dash
> +++ b/src/env_parallel.dash
> @@ -395,7 +395,7 @@ _parset_main() {
>   echo "Web site: https://www.gnu.org/software/parallel;
>   echo
>   echo "When using programs that use GNU Parallel to process data for 
> publication"
> - echo "please cite as described in 'parallel --citation'."
> + echo "please cite as described in the manpage."
>   echo
>   return 255
>  fi
> diff --git a/src/env_parallel.ksh b/src/env_parallel.ksh
> index 73dcf8b..746c989 100755
> --- a/src/env_parallel.ksh
> +++ b/src/env_parallel.ksh
> @@ -373,7 +373,7 @@ _parset_main() {
>   echo "Web site: https://www.gnu.org/software/parallel;
>   echo
>   echo "When using programs that use GNU Parallel to process data for 
> publication"
> - echo "please cite as described in 'parallel --citation'."
> + echo "please cite as described in the manpage."
>   echo
>   return 255
>  fi
> diff --git a/src/env_parallel.pod b/src/env_parallel.pod
> old mode 100644
> new mode 100755
> index 57c7d54..d67c7f4
> --- a/src/env_parallel.pod
> +++ b/src/env_parallel.pod
> @@ -800,9 +800,6 @@ When using GNU B for a publication please 
> cite:
>  O. Tange (2018): GNU Parallel 2018, March 2018, ISBN 9781387509881,
>  DOI: 10.5281/zenodo.1146014.
>  
> -This helps funding further development; and it won't cost you a cent.
> -If you pay 1 EUR you should feel free to use GNU Parallel without citing.
> -
>  Copyright (C) 2007-10-18 Ole Tange, http://ole.tange.dk
>  
>  Copyright (C) 2008-2010 Ole Tange, http://ole.tange.dk
> diff --git a/src/env_parallel.sh b/src/env_parallel.sh
> index 0f584ba..ba0e89d 100755
> --- a/src/env_parallel.sh
> +++ b/src/env_parallel.sh
> @@ -400,7 +400,7 @@ _parset_main() {
>   echo "Web site: https://www.gnu.org/software/parallel;
>   echo
>   echo "When using programs that use GNU Parallel to process data for 
> publication"
> - echo "please cite as described in 'parallel --citation'."
> + echo "please cite as described in the manpage."
>   echo
>   return 255
>  fi
> diff --git a/src/env_parallel.zsh b/src/env_parallel.zsh
> index 54001c6..a0592c9 100755
> --- a/src/env_parallel.zsh
> +++ b/src/env_parallel.zsh
> @@ -365,7 +365,7 @@ _parset_main() {
>   echo "Web site: https://www.gnu.org/software/parallel;
>   echo
>   echo "When using programs that use GNU Parallel to process data for 
> publication"
> - echo "please cite as described in 'parallel --citation'."
> + echo "please cite as described in the manpage."
>   echo
>   return 255
>  fi
> diff --git a/src/parallel b/src/parallel
> index d2f0396..d8288ed 100755
> --- a/src/parallel
> +++ b/src/parallel
> @@ -1607,7 +1607,7 @@ sub options_hash() {
># Before changing this line, please read
># 
> https://www.gnu.org/software/parallel/parallel_design.html#Citation-notice
># 
> https://git.savannah.gnu.org/cgit/parallel.git/tree/doc/citation-notice-faq.txt
> -  "bibtex|citation" => \$opt::citation,
> +# "bibtex|citation" => \$opt::citation,
>"wc|willcite|will-cite|nn|nonotice|no-notice" => \$opt::willcite,
># Termination and retries
>"halt-on-error|halt=s" => \$opt::halt,
> @@ -1764,10 +1764,10 @@ sub parse_options(@) {
>  # Before changing this line, please read
>  # 
> https://www.gnu.org/software/parallel/parallel_design.html#Citation-notice
>  # 
> https://git.savannah.gnu.org/cgit/parallel.git/tree/doc/citation-notice-faq.txt
> -if(defined $opt::citation) {
> - citation(\@argv_before,\@ARGV);
> - wait_and_exit(0);
> -}
> +#if(defined $opt::citation) {
> +#citation(\@argv_before,\@ARGV);
> +#wait_and_exit(0);
> +#}
>  # no-* overrides *
>  if($opt::nokeeporder) { $opt::keeporder = undef; }
>  
> @@ -2117,7 +2117,7 @@ sub parse_options(@) {
>  #
>  # If you want GNU Parallel to be maintained in the future you
>  # should keep this line.
> -citation_notice();
> +#citation_notice();
>  # Seriously: _YOU_ will be harming free software by removing the
>  # notice.  _YOU_ make it harder to justify spending time developing
>  # it. If you *do* remove the line, please email
> @@ -5058,9 +5058,9 @@ sub usage() {
># Before changing this 

Bug#981823: librust-alacritty-terminal-dev is not installable

[Steve Langasek]

Note that although rust-alacritty-terminal may no longer need rust-terminfo,
if it still depends on rust-vte, then the package is still not buildable
because the only version of rust-vte in the archive is 0.3 and
rust-alacritty-terminal requires 0.8.


-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

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

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: lebiniou
Version : 3.61.2-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.61.2-1.dsc

Changes since the last upload:

  * New upstream release 3.61.2.
  * Fix FTBFS on hurd-i386.

Regards,

--
Olivier Girondel

Bug#993221: RFS: lebiniou-data/3.61.1-1 -- datafiles for Le Biniou

[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.61.1-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.61.1-1.dsc

Changes since the last upload:

  * New upstream release 3.61.1.
  * debian/tests/control: Updated.

Regards,

--
Olivier Girondel

Bug#992666: /usr/bin/cut: -n ignored => mangles output ‒ more succinct test data

[наб]

Hi!

A better and more exhaustive test dataset can be as simple as:
-- >8 --
for i in $(seq 10); do
  echo "-$i;$((i+1))-" | paste - \
<(printf 'яйцо\nЯЙЦО' | cut -nb -$i) \
<(printf 'яйцо\nЯЙЦО' | cut -nb $((i+1))-)
done
-- >8 --

With a correct implementation, this yields:
-- >8 --
-1;2-   яйцо
ЯЙЦО
-2;3-   я   йцо
Я   ЙЦО
-3;4-   я   йцо
Я   ЙЦО
-4;5-   яй  цо
ЯЙ  ЦО
-5;6-   яй  цо
ЯЙ  ЦО
-6;7-   яйц о
ЯЙЦ О
-7;8-   яйц о
ЯЙЦ О
-8;9-   яйцо
ЯЙЦО
-9;10-  яйцо
ЯЙЦО
-10;11- яйцо
ЯЙЦО
-- >8 --

With the current coreutils implementation, this yields:
-- >8 --
-1;2-   �   �йцо
�   �ЙЦО
-2;3-   я   йцо
Я   ЙЦО
-3;4-   я�  �цо
Я�  �ЦО
-4;5-   яй  цо
ЯЙ  ЦО
-5;6-   яй� �о
ЯЙ� �О
-6;7-   яйц о
ЯЙЦ О
-7;8-   яйц��
ЯЙЦ��
-8;9-   яйцо
ЯЙЦО
-9;10-  яйцо
ЯЙЦО
-10;11- яйцо
ЯЙЦО
-- >8 --

Or, without replacement characters:
-- >8 --
  2d 31 3b 32 2d 09 d1 09  8f d0 b9 d1 86 d0 be 0a  |-1;2-...|
0010  09 d0 09 af d0 99 d0 a6  d0 9e 0a 2d 32 3b 33 2d  |...-2;3-|
0020  09 d1 8f 09 d0 b9 d1 86  d0 be 0a 09 d0 af 09 d0  ||
0030  99 d0 a6 d0 9e 0a 2d 33  3b 34 2d 09 d1 8f d0 09  |..-3;4-.|
0040  b9 d1 86 d0 be 0a 09 d0  af d0 09 99 d0 a6 d0 9e  ||
0050  0a 2d 34 3b 35 2d 09 d1  8f d0 b9 09 d1 86 d0 be  |.-4;5-..|
0060  0a 09 d0 af d0 99 09 d0  a6 d0 9e 0a 2d 35 3b 36  |-5;6|
0070  2d 09 d1 8f d0 b9 d1 09  86 d0 be 0a 09 d0 af d0  |-...|
0080  99 d0 09 a6 d0 9e 0a 2d  36 3b 37 2d 09 d1 8f d0  |...-6;7-|
0090  b9 d1 86 09 d0 be 0a 09  d0 af d0 99 d0 a6 09 d0  ||
00a0  9e 0a 2d 37 3b 38 2d 09  d1 8f d0 b9 d1 86 d0 09  |..-7;8-.|
00b0  be 0a 09 d0 af d0 99 d0  a6 d0 09 9e 0a 2d 38 3b  |.-8;|
00c0  39 2d 09 d1 8f d0 b9 d1  86 d0 be 09 0a 09 d0 af  |9-..|
00d0  d0 99 d0 a6 d0 9e 09 0a  2d 39 3b 31 30 2d 09 d1  |-9;10-..|
00e0  8f d0 b9 d1 86 d0 be 09  0a 09 d0 af d0 99 d0 a6  ||
00f0  d0 9e 09 0a 2d 31 30 3b  31 31 2d 09 d1 8f d0 b9  |-10;11-.|
0100  d1 86 d0 be 09 0a 09 d0  af d0 99 d0 a6 d0 9e 09  ||
0110  0a|.|
0111
-- >8 --

Best,
наб


signature.asc
Description: PGP signature

Bug#900808: python-pika: New version available

[Sergio Cipriano]

Hi all,

Recently I updated python-pika to 1.2.0-1~exp1.

> There is even 1.x.x available now, which broke API :( [1]

Is this problem still a thing?
I have rebuilt the rdependencies locally, but I haven't been able to reproduce 
this.
Here is an update of the existing reverse deps:

$ apt-rdepends -r python3-pika
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
python3-pika
Reverse Depends: python3-biomaj3-download (3.2.4-1)
Reverse Depends: python3-biomaj3-process (3.0.16-2)
Reverse Depends: python3-pika-pool (>= 0.1.3-4)
python3-biomaj3-download
Reverse Depends: python3-biomaj3 (3.1.18-2)
python3-biomaj3
Reverse Depends: python3-biomaj3-daemon (3.0.22-2)
python3-biomaj3-daemon
python3-biomaj3-process
Reverse Depends: python3-biomaj3 (3.1.18-2)
python3-pika-pool

> Should we introduce a new source package, python-pika1, to reflect that
> and preserve the old API for the existing reverse deps:

Is this option still necessary?
We need to upgrade python-pika in order to upgrade pagure to the latest version.
So, If this problem doesn't happen anymore, we intend to take the changes to 
unstable.

--
Cheers,
Sérgio Cipriano.

Bug#993211: inn2: ovdb_monitor/server can't start due to missing /run/news

[John Goerzen]

On Sat, Aug 28 2021, Russ Allbery wrote:


John Goerzen  writes:


Hi Russ!  It is good to visit with you again.  Thanks for what you 
do with inn.


I run an INN site for an ISP waaay back and am now getting back 
into it.


Given your good point about makehistory, I suspect the right 
answer here
is to create /run/news via /etc/tmpfiles.d.  That should handle 
all


I hadn't known about /etc/tmpfiles.d.  TIL - thanks.  Yes, that 
makes perfect sense.


systemd systems, and the init script should handle non-systemd 
systems
(with the edge case of not handling makehistory when the init 
script
hasn't run since the last reboot, but I'm not sure if that's 
worth

worrying about).


Agreed.  That's pretty obscure.

BTW, I am a little uncertain about the long-term future of ovdb. 
We don't
have an active maintainer of it upstream and BerkeleyDB itself 
is kind of
a mess for various reasons and on shaky ground inside Debian. 
The next
major release of INN will have a SQLite backend, which is 
probably the
most equivalent replacement, although tradindexed does fine for 
most

people.


Ah, interesting.  Sqlite makes sense for the future for sure.

So I should mention why I switched.  I was getting lines like this 
in the news.daily report:



innd: tradindexed: index inode mismatch for local.test
...

   expireover: tradindexed: index inode mismatch for control
   expireover: tradindexed: index inode mismatch for 
   control.cancel
   expireover: tradindexed: index inode mismatch for 
   control.checkgroups

...

I am running inn2 inside a Docker container atop zfs.  I believe 
inodes should be internally consistent (eg, tar can properly 
detect hardlinkes) but due to the bind mount (and possibility of 
running atop a zfs clone or whatnot), I suspect -- but have not 
verified -- that at least st_dev if not st_ino also (from stat(2)) 
are not guaranteed to be consistent across restarts.  I'd guess 
the most common reason for that would be st_dev changes due to the 
bind mount that Docker does.  However, looking at the code, I 
don't think it uses st_dev, so perhaps st_ino is also not stable 
across restarts.  (conjecture at this point)


I read a few comments in the code and thought "you know, the 
easiest way out of this is to just use ovdb".


- John

Bug#993219: mariadb-server-core: Akonadi database - mysql_upgrade fails always with "FATAL ERROR: Can't execute 'mysqlcheck'"

[Ulrich Beckmann]

Package: mariadb-server-core-10.5
Version: 1:10.5.11-1
Severity: normal
File: mariadb-server-core

Dear Maintainer,

   The redo log was corrupted before upgrade to Debian bullseye. Akonadi would 
not start.
   see 
https://debianforum.de/forum/viewtopic.php?f=29=181760=15#p1280104 
(German language)

   I invoked mysql_upgrade to check and repair the MariaDB system tables
-
bequimao@bullseye-kde:~$ mysql_upgrade 
--defaults-file=/home/bequimao/.local/share/akonadi/mysql.conf 
--socket=/run/user/1000/akonadi/mysql.socket -v
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Can't execute 'mysqlcheck'
-
  NB. I repeated the test in a fresh install of Debian 11 KDE Plasma in a VM 
(Qemu/KVM) and Debian testing.
  Always had the same error message.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 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 mariadb-server-core-10.5 depends on:
ii  libaio1 0.3.112-9
ii  libc6   2.31-13
ii  libcrypt1   1:4.4.18-4
ii  liblz4-11.9.3-2
ii  libpcre2-8-010.36-2
ii  libsnappy1v51.1.8-1
ii  libssl1.1   1.1.1k-1+deb11u1
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-6
ii  mariadb-common  1:10.5.11-1
ii  zlib1g  1:1.2.11.dfsg-2

mariadb-server-core-10.5 recommends no packages.

mariadb-server-core-10.5 suggests no packages.

-- no debconf information

Bug#993218: ITP: ruby-localhost -- Manage a local certificate authority for self-signed localhost

[Hideki Yamane]

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

* Package name: ruby-localhost
  Version : 1.1.8
  Upstream Author : 2018-2021 Samuel G. D. Williams 
* URL : https://github.com/socketry/localhost
* License : MIT
  Programming Lang: Ruby
  Description : Manage a local certificate authority for self-signed 
localhost

 This provides a convenient API for generating per-user self-signed root
 certificates, is useful for development. 


 1. Introduce ruby-async-rspec   (ITPed)
 2. Introduce ruby-async-process (ITPed)
 3. Introduce ruby-localhost   <-- here
 4. Update ruby-async-http

Bug#993179: ncurses: enable format function attributes by default

[Christian Göttsche]

On Sat, 28 Aug 2021 at 15:27, Thomas Dickey  wrote:
>
> sure - they're conditioned on a nonstandard extension to C.
> Debian can provide some patch which hardcodes that condition,
> but as I recall it, there's no clean way to provide this in
> standard C.
>

Yes, these function attributes are GNU extensions.
But GCC_PRINTFLIKE is defined via `__attribute__`[1], and if __GNUC__
is not set, `__attribute__` is defined empty.
So the attributes are only enabled if the compiler defines __GNUC__
and then the compiler should support those.


[1]: 
https://sources.debian.org/src/ncurses/6.2+20201114-4/include/curses.h.in/#L521
[2]: 
https://sources.debian.org/src/ncurses/6.2+20201114-4/include/curses.h.in/#L508

Bug#992790: Severity: High / Bug on Debian 11 Bullseye - Boot problem - Failed to start Load/Save RF Kill Switch Status

[pham...@bluewin.ch]

Hello,
After a clean reinstall the problem is persistent.
It is very difficult to use Debian 11 on a production machine due to this 
problem.
Debian 10 does not have this problem, but it seems to be present in some 
versions of Ubuntu.
It would have been wise to postpone the release of the final version in view of 
this very big bug...
Hope you will release a fix very soon, I cannot continue like this for x months.
Regards.
Philippe

Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Ian Turner]

Thanks Andreas.

On 8/28/21 12:57 PM, Andreas Tille wrote:

Patches are always welcome.


Attached is a patch that removes all mentions of the --bibtex or 
--citation parameters, or demands for 1 EUR, throughout the 
codebase. It includes the patch you already committed, so it should 
serve as a drop-in replacement.


I would also like to say to Ole that I hope you can understand that this 
is not personal in any way.


Ian

diff --git a/src/env_parallel.dash b/src/env_parallel.dash
index 0674942..878edc6 100755
--- a/src/env_parallel.dash
+++ b/src/env_parallel.dash
@@ -395,7 +395,7 @@ _parset_main() {
 	echo "Web site: https://www.gnu.org/software/parallel;
 	echo
 	echo "When using programs that use GNU Parallel to process data for publication"
-	echo "please cite as described in 'parallel --citation'."
+	echo "please cite as described in the manpage."
 	echo
 	return 255
 fi
diff --git a/src/env_parallel.ksh b/src/env_parallel.ksh
index 73dcf8b..746c989 100755
--- a/src/env_parallel.ksh
+++ b/src/env_parallel.ksh
@@ -373,7 +373,7 @@ _parset_main() {
 	echo "Web site: https://www.gnu.org/software/parallel;
 	echo
 	echo "When using programs that use GNU Parallel to process data for publication"
-	echo "please cite as described in 'parallel --citation'."
+	echo "please cite as described in the manpage."
 	echo
 	return 255
 fi
diff --git a/src/env_parallel.pod b/src/env_parallel.pod
old mode 100644
new mode 100755
index 57c7d54..d67c7f4
--- a/src/env_parallel.pod
+++ b/src/env_parallel.pod
@@ -800,9 +800,6 @@ When using GNU B for a publication please cite:
 O. Tange (2018): GNU Parallel 2018, March 2018, ISBN 9781387509881,
 DOI: 10.5281/zenodo.1146014.
 
-This helps funding further development; and it won't cost you a cent.
-If you pay 1 EUR you should feel free to use GNU Parallel without citing.
-
 Copyright (C) 2007-10-18 Ole Tange, http://ole.tange.dk
 
 Copyright (C) 2008-2010 Ole Tange, http://ole.tange.dk
diff --git a/src/env_parallel.sh b/src/env_parallel.sh
index 0f584ba..ba0e89d 100755
--- a/src/env_parallel.sh
+++ b/src/env_parallel.sh
@@ -400,7 +400,7 @@ _parset_main() {
 	echo "Web site: https://www.gnu.org/software/parallel;
 	echo
 	echo "When using programs that use GNU Parallel to process data for publication"
-	echo "please cite as described in 'parallel --citation'."
+	echo "please cite as described in the manpage."
 	echo
 	return 255
 fi
diff --git a/src/env_parallel.zsh b/src/env_parallel.zsh
index 54001c6..a0592c9 100755
--- a/src/env_parallel.zsh
+++ b/src/env_parallel.zsh
@@ -365,7 +365,7 @@ _parset_main() {
 	echo "Web site: https://www.gnu.org/software/parallel;
 	echo
 	echo "When using programs that use GNU Parallel to process data for publication"
-	echo "please cite as described in 'parallel --citation'."
+	echo "please cite as described in the manpage."
 	echo
 	return 255
 fi
diff --git a/src/parallel b/src/parallel
index d2f0396..d8288ed 100755
--- a/src/parallel
+++ b/src/parallel
@@ -1607,7 +1607,7 @@ sub options_hash() {
 	 # Before changing this line, please read
 	 # https://www.gnu.org/software/parallel/parallel_design.html#Citation-notice
 	 # https://git.savannah.gnu.org/cgit/parallel.git/tree/doc/citation-notice-faq.txt
-	 "bibtex|citation" => \$opt::citation,
+#	 "bibtex|citation" => \$opt::citation,
 	 "wc|willcite|will-cite|nn|nonotice|no-notice" => \$opt::willcite,
 	 # Termination and retries
 	 "halt-on-error|halt=s" => \$opt::halt,
@@ -1764,10 +1764,10 @@ sub parse_options(@) {
 # Before changing this line, please read
 # https://www.gnu.org/software/parallel/parallel_design.html#Citation-notice
 # https://git.savannah.gnu.org/cgit/parallel.git/tree/doc/citation-notice-faq.txt
-if(defined $opt::citation) {
-	citation(\@argv_before,\@ARGV);
-	wait_and_exit(0);
-}
+#if(defined $opt::citation) {
+#	citation(\@argv_before,\@ARGV);
+#	wait_and_exit(0);
+#}
 # no-* overrides *
 if($opt::nokeeporder) { $opt::keeporder = undef; }
 
@@ -2117,7 +2117,7 @@ sub parse_options(@) {
 #
 # If you want GNU Parallel to be maintained in the future you
 # should keep this line.
-citation_notice();
+#citation_notice();
 # Seriously: _YOU_ will be harming free software by removing the
 # notice.  _YOU_ make it harder to justify spending time developing
 # it. If you *do* remove the line, please email
@@ -5058,9 +5058,9 @@ sub usage() {
 	 # Before changing this line,  please read
  # https://www.gnu.org/software/parallel/parallel_design.html#Citation-notice
 	 # https://git.savannah.gnu.org/cgit/parallel.git/tree/doc/citation-notice-faq.txt
-	 "This helps funding further development; AND IT WON'T COST YOU A CENT.",
-	 "If you pay 1 EUR you should feel free to use GNU Parallel without citing.",
-	 "",
+#	 "This helps funding further development; AND IT WON'T COST YOU A CENT.",
+#	 "If you pay 1 EUR you should feel free to use GNU Parallel without citing.",
+#	 "",
 	 

Bug#993217: postgres-13: riscv64 doesn't support spinlocks

[Efraim Flashner]

Source: postgresql-13
Version: 13.4-2
Severity: important
Tags: ftbfs

postgresql-13.4 FTBFS on riscv64 since the '--disable-spinlocks' flag
was removed for this architecture.

https://buildd.debian.org/status/fetch.php?pkg=postgresql-13=riscv64=13.4-2=1629988401=0

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Bug#993216: [Pkg-rust-maintainers] Bug#993216: dh-cargo timestamp fix doesn't cover changelogs installed to /usr/share/doc

[Ximin Luo]

plugwash:
> package: dh-cargo
> 
> Recently a substantial number of upstream cargo packages started using 
> timestamps the ftpmasters
> consider reject-worthy, I believe this was done in the name of 
> reproducibility.
> 

On what basis are you forming your belief? Because I worked on reproducibility 
for a couple of years (and was advising the rustc guys about it), and this 
method is not suitable for that purpose.

>From what I gather during previous discussions, some overzealous FTP person 
>ages ago decided to add this over-reaching check, to reject other bad-quality 
>packages, without thinking about the long-term consequences of it. Now we must 
>all suffer the consequences.

The correct fix is to undo this injustice, not to leech volunteers' time with 
this sort of bullshit. Covid has killed several million people in the past 
couple years due to government incompetence and inaction, I don't want to care 
about fucking timestamps, ESPECIALLY when it has nothing to do with 
reproducibility.

> After it became clear that this was a larger-scale issue and we got sick of 
> working around this in individual packages, sylvestre implemented a 
> workaround in dh_cargo. Unfortunately this fix does not seem to be complete.
> 
> Specifically it seems that when an upstream changelog is installed by 
> dh_installchangelogs  to /usr/share/doc it doesn't get the timestamp fixing 
> treatment. Presumablly because dh_installchangelogs pulls it from the source 
> tree while the dh_cargo timestamp fixing happens on the output tree.
> 
> I've worked around it for now in crossbeam-deque, but I don't know how many 
> other packages are
> potentially effected (e.g. have changelogs with dodgy timestamps in their 
> upstream packaging) and whether this is something we need to deal with 
> centrally.
> 

-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#899246: runit-init: stage 3: using runit's own shutdown/reboot code

[Lorenzo]

On Mon, 21 May 2018 16:27:15 +0200 Lorenzo Puliti
 wrote:
> Package: runit-init
> Version: 2.1.2-13
> Severity: wishlist
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.15.12-van (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages runit-init depends on:
> ii  getty-run 2.1.2-13
> ii  initscripts   2.88dsf-59.10
> ii  libc6 2.27-3
> ii  runit 2.1.2-13
> ii  runit-helper  2.7.2
> ii  sysv-rc   2.88dsf-59.10
> 
> runit-init recommends no packages.
> 
> runit-init suggests no packages.
> 
> -- no debconf information
> 
> -- debsums errors found:
> debsums: changed file /sbin/shutdown (from runit-init package)
> 
> 
> Hi,
> I would like to share a setup that uses runit's code for
> reboot/shutdown: this way shutdown/reboot's external code is used
> only when switching init. Also, the /etc/init.d/rc script is no
> longer used for the shutdown sequence. I'm currently using this on my
> pc and i have tested the systemd-->runit-init sitch on Virtualbox and
> works for me. Sharing in case you want to use it or just take some
> ideas from it.
> 
> mv /sbin/shutdown /sbin/shutdown-sysv
> rm /sbin/reboot
> rm /sbin/halt
> 
> 
> /etc/runit/3
> --
> #!/bin/sh
> exec 2>&1
> 
> PATH=/sbin:/usr/sbin:/bin:/usr/bin
> 
> # LAST=0
> 
> # While test -x is more natural, it does not consider file with
> # executable bit set on 'noexec' filesystem as executable, and /run
> # often is mounted as 'noexec'.
> # [ $(stat -c %a /run/runit.reboot) = 100 ] && LAST=6

[replying to myself..]

Right now runit in Debian ships its own version of shutdown: the easiest
thing to do seems to make reboot/halt/poweroff '-f' option a noop when
runit is init, so that Stage 3 returns and runit can continue with its
own internal code.
hope that this doesn't break anything else

Bug#992927: mutt: Mutt 2.1.2 is available, fixing a potential data-loss IMAP bug

[Antonio Radici]

On Wed, Aug 25, 2021 at 10:20:17AM +0200, Vincent Lefevre wrote:
> Package: mutt
> Version: 2.0.5-4.1
> Severity: grave
> Justification: causes non-serious data loss
> 
> Mutt 2.1.2 is available. From the announce: "This is an important
> bug-fix release, fixing a potential data-loss IMAP bug. IMAP users
> are strongly advised to upgrade."
> 
> For stable and oldstable: "Packagers, please consider backporting
> commit 647efbd1 if at all possible."
> 
> See
> http://lists.mutt.org/pipermail/mutt-announce/Week-of-Mon-20210823/40.html
> for additional information.
> 
> Note also that there is a minor "mutt -v" output issue with the
> current Mutt and, in particular, GNU Autoconf 2.71, which is now
> in unstable. I fixed this issue in Mutt's repository yesterday
> and I'm going to report a second bug for that.

I'm going to have this fixed in the next few days (by Sep 1st)

Bug#993216: dh-cargo timestamp fix doesn't cover changelogs installed to /usr/share/doc

[plugwash]

package: dh-cargo

Recently a substantial number of upstream cargo packages started using 
timestamps the ftpmasters
consider reject-worthy, I believe this was done in the name of 
reproducibility.


After it became clear that this was a larger-scale issue and we got sick 
of working around this in individual packages, sylvestre implemented a 
workaround in dh_cargo. Unfortunately this fix does not seem to be complete.


Specifically it seems that when an upstream changelog is installed by 
dh_installchangelogs  to /usr/share/doc it doesn't get the timestamp 
fixing treatment. Presumablly because dh_installchangelogs pulls it from 
the source tree while the dh_cargo timestamp fixing happens on the 
output tree.


I've worked around it for now in crossbeam-deque, but I don't know how 
many other packages are
potentially effected (e.g. have changelogs with dodgy timestamps in 
their upstream packaging) and whether this is something we need to deal 
with centrally.

Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Andreas Tille]

On Sat, Aug 28, 2021 at 12:08:56PM -0400, Ian Turner wrote:
> My reading of bug 905674 is that the citation notice has been previously
> judged to be incompatible with the DFSG and that's why it was removed.
> 
> Also ultimately Debian developers will have to make their own decision,
> though if you are asking my personal opinion, I think it would be best to
> remove it. I am among those not persuaded by Ole's arguments to the
> contrary, in the specific context of the Debian project.

I'm also not convinced absolutely.  I was just mentioning that upstream
seems to have noticed our (may be other distributions) patch and added
extra comments.  So I felt it appropriate to trigger a short discussion
about it.
 
> One other thing — I note that the fix to 905674 did not remove these command
> line parameters from the manpage, so if you do decide to remove the citation
> notice, I would suggest removing it there as well. I am happy to submit a
> patch if that would be helpful.

Patches are always welcome.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Bug#993215: ITP: ruby-async-process -- asynchronous process spawning in Ruby

[Hideki Yamane]

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

* Package name: ruby-async-process
  Version : 1.3.1
  Upstream Author : Samuel G. D. Williams 
* URL : https://github.com/socketry/async-process
* License : MIT
  Programming Lang: Ruby
  Description : asynchronous process spawning in Ruby

 Implements Process.spawn and Process.capture for async.



 1. Introduce ruby-async-rspec (ITPed)
 2. Introduce ruby-async-process <-- here
 3. Introduce ruby-localhost
 4. Update ruby-async-http

Bug#993211: inn2: ovdb_monitor/server can't start due to missing /run/news

[Russ Allbery]

John Goerzen  writes:

> 3) /run/news somehow gets created.

> I notice that the debian/inn2.init file does do this.  However, on
> systemd systems, the debian/inn2.service file doesn't appear to.  Also
> in situations of needing to run makehistory and such, often innd will
> have not been running.

> I wonder if the code to handle this got dropped on the way to systemd?

Given your good point about makehistory, I suspect the right answer here
is to create /run/news via /etc/tmpfiles.d.  That should handle all
systemd systems, and the init script should handle non-systemd systems
(with the edge case of not handling makehistory when the init script
hasn't run since the last reboot, but I'm not sure if that's worth
worrying about).

BTW, I am a little uncertain about the long-term future of ovdb.  We don't
have an active maintainer of it upstream and BerkeleyDB itself is kind of
a mess for various reasons and on shaky ground inside Debian.  The next
major release of INN will have a SQLite backend, which is probably the
most equivalent replacement, although tradindexed does fine for most
people.

-- 
Russ Allbery (r...@debian.org)  

Bug#992087: libfonts-java: contains a file with a non-free "disparaging to Sun" license

[tony mancill]

On Sat, Aug 28, 2021 at 02:21:02PM +0200, Pierre Gruet wrote:
> Control: tags -1 pending
> 
> Hello,
> 
> After a deeper examination, I see the file with the non-free contents is
> useless anyway, none of the files it attempts to patch exists. I think this
> file got lost here as it obviously comes from itext, not libfonts.
> 
> I offer to team-upload the package soon.

Hi Pierre,

Thank you for helping us clean up some of the cruft that has
accumulated in these packages.

Cheers,
tony

Bug#993179: ncurses: enable format function attributes by default

[Christian Göttsche]

Source: ncurses
Version: 6.2+20201114-4
Tags: security

The interface functions mvprintw(3), mvwprintw(3), printw(3),
wprintw(3) and _tracef(3) take a format string as input.
Format string are prone for attacks[1].
To mitigate those modern compilers support format string
attributes[2,3] to warn at compile time on misuses, e.g. a specifier
mismatches.
In ncurses these function attributes are not enabled by default, they
are only enabled when defining the macros GCC_PRINTF and GCC_SCANF.
Please enable these function attributes by default, as every compiler
used with Debian Bookworm should support those and they can help
avoiding format string vulnerabilities, e.g. [4].

Best regards,
  Christian Göttsche



[1]: https://owasp.org/www-community/attacks/Format_string_attack
[2]: 
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
[3]: https://clang.llvm.org/docs/AttributeReference.html#format
[4]: 
https://github.com/htop-dev/htop/commit/bfcb8ca0196eef942e6363e2fd7faa80eddec644

Bug#993214: mpi4py: autopkgtest regression around 2021-08-25

[Graham Inggs]

Source: mpi4py
Version: 3.0.3-8
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
X-Debbugs-CC: debian...@lists.debian.org

Hi Maintainer

Some time around 2021-08-25, mpi4py's autopkgtests regressed in testing [1].
This seems to coincide with the migration of pmix/4.1.0-3 to testing,
but may be unrelated.

Regards
Graham


[1] https://ci.debian.net/packages/m/mpi4py/testing/amd64/

Bug#993178: libconfuse: enable hardening flags

[Christian Göttsche]

Source: libconfuse
Version: 3.3-2

Please enable hardening flags for libconfuse, e.g. by adding

export DEB_BUILD_MAINT_OPTIONS = hardening=+all

to debian/rules.

Bug#993213: lightdm-settings does not start if slick-greeter package is not installed

[Bruno Ramos]

Package: lightdm-settings
Version: 1.5.1-1
Severity: important
X-Debbugs-Cc: brunoramos...@gmail.com

Dear Maintainer,

when installing lightdm-settings package, with apt-get for example, the
application does not start.
We get the following error:
(lightdm-settings:6559): GLib-GIO-ERROR **: 18:12:47.757: Settings schema
'x.dm.slick-greeter' is not installed

Apparently the is a dependency on slick-greeter that is not installed.
Installing slick-greeter manually solves the issue and allows the application
to start properly.

It would be best to set a dependency on slick-greeter so that everything works
out of box after installing lightdm-settings.

Best Regards,

Bruno Ramos


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

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

Versions of packages lightdm-settings depends on:
ii  python3   3.9.2-3
ii  python3-setproctitle  1.2.2-1
ii  python3-xapp  2.0.2-2

lightdm-settings recommends no packages.

lightdm-settings suggests no packages.

Bug#993212: ITP: ruby-async-rspec -- helpers for writing specs against the async gem

[Hideki Yamane]

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

* Package name: ruby-async-rspec
  Version : 1.6.1
  Upstream Author : Samuel G. D. Williams 
* URL : https://github.com/socketry/async-rspec
* License : MIT
  Programming Lang: Ruby
  Description : helpers for writing specs against the async gem

 Provides useful RSpec.shared_contexts for testing code that builds
 on top of async.

 This package is needed to update other gem - ruby-async-http.
 ruby-async-rspec is necessary to introduce ruby-async-process, it is
 used to introduce ruby-localhost, and ruby-localhost is dependency
 for ruby-async-http update.

 1. Introduce ruby-async-rspec   <-- here
 2. Introduce ruby-async-process
 3. Introduce ruby-localhost
 4. Update ruby-async-http

Bug#993204: gnome-shell-timer: does not declare compatibility with GNOME Shell 40

[Raphael Hertzog]

Control: severity -1 serious

Hi,

On Sat, 28 Aug 2021, Simon McVittie wrote:
> When we do the GNOME 40 transition, hopefully soon, we will have to
> either update this extension or remove it from testing. It would be
> useful to get a fixed version into experimental.

This extension is effectively unmaintained upstream. I will likely
request its removal from Debian unless someone is willing to take it
over in Debian and as upstream. Let's get it removed from testing right
now as way to alert potential users.

FWIW I have switched to https://github.com/blackjackshellac/kitchenTimer
but I'm not sure that I have the time and willingness to package it.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Ian Turner]

On 8/28/21 7:41 AM, Andreas Tille wrote:

I updated the patch in Git[1] but did not yet activate it yet.  I'm fine
with uploading parallel with the patch activated if you really think we
should disrespect the wish of the author and insist on plain GPL text.


My reading of bug 905674 is that the citation notice has been previously 
judged to be incompatible with the DFSG and that's why it was removed.


Also ultimately Debian developers will have to make their own decision, 
though if you are asking my personal opinion, I think it would be best 
to remove it. I am among those not persuaded by Ole's arguments to the 
contrary, in the specific context of the Debian project.


One other thing — I note that the fix to 905674 did not remove these 
command line parameters from the manpage, so if you do decide to remove 
the citation notice, I would suggest removing it there as well. I am 
happy to submit a patch if that would be helpful.


Regards,

Ian Turner

Bug#993211: inn2: ovdb_monitor/server can't start due to missing /run/news

[John Goerzen]

Package: inn2
Version: 2.6.4-2
Severity: normal

Hello,

I was tracking down an odd problem with trying to get ovdb going:

news@news:/var/lib/news$ /usr/lib/news/bin/ovdb_init
ovdb_init: OVDB: can not open database unless ovdb_monitor is running
ovdb_init: database is active
ovdb_init: OVDB: can not open database unless ovdb_monitor is running
ovdb_init: starting ovdb monitor

ovdb_init: starting ovdb server

But this leaves off with no ovdb processes actually running.  Moreover, 
makehistory -O complained that it couldn't open overview due to "No such file 
or directory."

Upon investigating things further, I noticed that /etc/news/inn.conf listed 
pathrun as /run/news, which doesn't exist.

I did:

mkdir /run/news
chown news /run/news

and then the ovdb processes started up fine.

However, as run is often ephemeral, that isn't really a proper solution.

I suspect that one or more of these should happen:

1) pathrun should be something different in the default config

2) README.Debian should document this issue

3) /run/news somehow gets created.

I notice that the debian/inn2.init file does do this.  However, on systemd 
systems, the debian/inn2.service file doesn't appear to.  Also in situations of 
needing to run makehistory and such, often innd will have not been running.

I wonder if the code to handle this got dropped on the way to systemd?

-- John

-- System Information:
Debian Release: 11.0
  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/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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages inn2 depends on:
ii  cron [cron-daemon] 3.0pl1-137
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
pn  inn2-inews 
ii  libc6  2.31-13
ii  libcrypt1  1:4.4.18-4
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libmime-tools-perl 5.509-1
ii  libpam0g   1.4.0-9
ii  libperl5.325.32.1-4+deb11u1
ii  libpython3.9   3.9.2-1
ii  libsasl2-2 2.1.27+dfsg-2.1
ii  libssl1.1  1.1.1k-1+deb11u1
ii  libsystemd0247.3-6
ii  lsb-base   11.1.0
ii  perl   5.32.1-4+deb11u1
ii  perl-base [perlapi-5.32.1] 5.32.1-4+deb11u1
ii  procps 2:3.3.17-5
ii  time   1.9-0.1
ii  zlib1g 1:1.2.11.dfsg-2

inn2 recommends no packages.

Versions of packages inn2 suggests:
pn  gnupg1  
pn  libgd-perl  
ii  libkrb5-3   1.18.3-6
ii  wget1.21-1+b1

Bug#993210: mate-session-manager: mate-settings-daemon crashed

[Mihai Hanor]

Package: mate-session-manager
Version: 1.24.1-2
Severity: normal
X-Debbugs-Cc: quake2i...@gmail.com

Dear Maintainer,

   * What led up to the situation?
Before the problem occurred, I did the following:
- enabled Alt+shift key for switching to another layout.
- disabled New windows use active window's layout
I used the system for awhile, browsing mostly.
A Caps Lock key stuck problem appeared. Trying to press CTRL+C/CTRL+V to
copy a selection of a text in a page, didn't worked. I realized that left
CTRL+C didn't work (same in a Terminal).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
First I attempted to disconnect the keyboard by cycling through the USB
switch outputs. The key was still stuck after these attempts.
Then I accessed Keyboard Preferences - Layouts and performed Reset to
defaults, then opened Options to see if the options there have been
restored. At this point I think the window closed on its own.

   * What was the outcome of this action?
I think that the crash of the process made my Caps Lock issue go away.

   * What outcome did you expect instead?
No Caps Lock stuck key, no crash.


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

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

Versions of packages mate-session-manager depends on:
ii  dbus-x11 1.12.20-2
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  debian-mate-default-settings 1.24.1-2
ii  libc62.31-13
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libegl1  1.3.2-1
ii  libepoxy01.5.5-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgl1   1.3.2-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libice6  2:1.0.10-1
ii  libsm6   2:1.2.3-1
ii  libsystemd0  247.3-6
ii  libx11-6 2:1.7.2-1
ii  libxau6  1:1.0.9-1
ii  libxcomposite1   1:0.4.5-1
ii  libxext6 2:1.3.3-1.1
ii  libxrender1  1:0.9.10-1
ii  libxtst6 2:1.2.3-1
ii  mate-desktop-common  1.24.1-2

Versions of packages mate-session-manager recommends:
ii  caja  1.24.0-1+b1
ii  marco 1.24.1-3
ii  mate-panel1.24.1-1+b1
ii  mate-polkit   1.24.0-2+b1
ii  mate-settings-daemon  1.24.1-1+b1

mate-session-manager suggests no packages.

-- no debconf information

#0  0x7fec909d1ce1 in raise () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fec909bb537 in abort () at /lib/x86_64-linux-gnu/libc.so.6
#2  0x7fec90b99dcc in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fec90bf72fb in g_assertion_message_expr () at
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7fec91288c36 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
--Type  for more, q to quit, c to continue without paging--
#5  0x7fec9129748a in gtk_widget_realize () at
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#6  0x7fec91297668 in gtk_widget_map () at
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#7  0x7fec9101a5c0 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#8  0x7fec9106522f in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#9  0x7fec90cc0211 in  () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x7fec90cd8a48 in g_signal_emit_valist () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x7fec90cd8c3f in g_signal_emit () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x7fec91297610 in gtk_widget_map () at
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#13 0x7fec912add18 in  () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#14 0x7fec90cc02ee in  () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#15 0x7fec90cd8a48 in g_signal_emit_valist () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x7fec90cd8c3f in g_signal_emit () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x7fec91297610 in gtk_widget_map () at
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#18 0x7fec912a47de 

Bug#985421: Adding DEP8 tests for at package

[Jose M Calhariz]

Hi,

Now I have the repo full updated and I am preparing a new upstream
release of at, with many changes
and bug fixes.  Do you mind to do a MR at salsa?

Kind regards
Jose M Calhariz


On 17/03/2021 20:57, Utkarsh Gupta wrote:
> Source: at
> Version: 3.1.23-1.1
> Severity: normal
> Tags: patch
>
> Hello,
>
> Since at is missing DEP8 tests, I'd like to add them. I wanted to
> propose an MR on salsa but the git history isn't in sync with what's
> uploaded to the archive, so asking here.
>
> I've prepared the basic testing script to ensure that there's no
> regression. I initially submitted this in Ubuntu but want to get it
> merged and uploaded here.
>
> Attaching the debdiff here for your review. Let me know what you think
> about this. Can I proceed with the upload?
>
>
> - u

Bug#993209: mat2: autopkgtests fail with libimage-exiftool-perl >= 12.23

[gregor herrmann]

Package: mat2
Version: 0.12.1-3
Severity: serious
Tags: upstream sid bookworm fixed-upstream patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

mat2's autopkgtests fail with newer libimage-exiftool-perl:

https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/14885837/log.gz

>   self.assertEqual(v, case['expected_meta'][k])
E   AssertionError: 'MP4 Base Media v1 [IS0 14496-12:2003]' != 'MP4 
 Base Media v1 [IS0 14496-12:2003]'
E   - MP4 Base Media v1 [IS0 14496-12:2003]
E   + MP4  Base Media v1 [IS0 14496-12:2003]
E   ?+


This is caused by a typo fix in lib/Image/ExifTool/QuickTime.pm in
12.23:

- -'isom' => 'MP4  Base Media v1 [IS0 14496-12:2003]', # video/mp4
+'isom' => 'MP4 Base Media v1 [IS0 14496-12:2003]', # video/mp4 (or audio)


In mat2 there's this test for the "old" version of the string:

% grep -ri "mp4  base media"   
tests/test_libmat2.py:'MajorBrand': 'MP4  Base Media v1 [IS0 
14496-12:2003]',


Apparently this is already fixed in upstream git:
https://0xacab.org/jvoisin/mat2/-/commit/6df615281b2a649b85ff7670f6d87d3beed0b977


I'm attaching a slightly rebased quilt patch based on this commit.

(After this we still see a test failure during build and in
autopkgtests, but this is #992912 / 
https://0xacab.org/jvoisin/mat2/-/commit/c9be50f968212b01f8d8ad85e59e19c3e67d8578
)


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmEqWXJfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZ8Zg//VTv9wNcLrnV+vHZ0jVYaOVHZpJZzhc4XZbJKJxC5U6kWDZp4drTMR+tf
PXWYUlR4X+eklzQs5n+kZQiFNqZ+A6mgWzjCc6p7wkpfQcnZgjrGNFHLdWlZ++pg
hobTKm2rSXoo1zf3AlJpf2i8/6hWouDGSiLtR4se3YHDtH2HfVzhvGwOR/Z1JuCD
OG1Zxq/1j8CHEHX0Az/rL3hGUfWKo0G6P4y2yqlH7UeL0gfE+EDhCUGLkYjeFYqq
WasWosXTm5xO3vqNsf/8l1bpIbk7bUXsoBHO5FMs27vDBQ2VokYkPVLabLnXT+wY
2LcQkVjsAEZN9PkOfGpeNLQ1JiKHWlbwFqZ/VHoT+n1377DZj+Gcs3FzghwN9Hqd
vaQ5EXj9c3R7wCqGN+Ct92hKbdPTnsqX1UmM/FbkfOcMW5Xy9itTzZYMYnYsOeJv
iU5EyHrJNODcSzolPeJnn3fr3X69k1zD9Tf55oAVofP5xXAqPNU0RCN0B7gKK6nI
KDACC1I75noGvpFmoEkZAc3TxlZJyMTzMKoyDeXNWQjIt2gNwIUFaGz7xYIJyGp1
GNxHkPL98fiiTo3Y5nITEraekD4Gj3B8BFUelhdmssCVl2GO23KR5Bmq3fd6CtrS
hZdE4rz+dnBG3BWoMyao2lWZJ3yY/dU0+jI8CUc/R6zKJF70XMk=
=ROMt
-END PGP SIGNATURE-
>From 6df615281b2a649b85ff7670f6d87d3beed0b977 Mon Sep 17 00:00:00 2001
From: jvoisin 
Date: Sun, 6 Jun 2021 16:25:59 +0200
Subject: [PATCH] Fix the CI for recent exiftool versions

Always a joy to deal with withespaces
---
 tests/test_libmat2.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/tests/test_libmat2.py
+++ b/tests/test_libmat2.py
@@ -448,7 +448,7 @@
 'HandlerDescription': 'SoundHandler',
 'HandlerType': 'Metadata',
 'HandlerVendorID': 'Apple',
-'MajorBrand': 'MP4  Base Media v1 [IS0 14496-12:2003]',
+'MajorBrand': 'Base Media v1 [IS0 14496-12:2003]',
 'MediaDataOffset': 48,
 'MediaDataSize': 379872,
 'MediaHeaderVersion': 0,
@@ -502,7 +502,7 @@
 p2 = case['parser'](p1.output_filename)
 for k, v in p2.get_meta().items():
 self.assertIn(k, case['expected_meta'])
-self.assertEqual(v, case['expected_meta'][k])
+self.assertIn(str(case['expected_meta'][k]), str(v))
 self.assertTrue(p2.remove_all())
 
 os.remove(target)

Bug#993208: js8call: TX broken

[Levente Kovacs]

Package: js8call
Version: 2.2.0+ds-2
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: leventel...@gmail.com

Dear Maintainer,


   * What led up to the situation?
I isnstalled js8call, and tried to transmit.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I pressed the tune button.
   * What was the outcome of this action?
The waterfall was freezing, showing only one line of information. The
TX wasn't happening. Some application, including firefox wasn't able to play
videos. Can't exit JS8CALL. The GUI disappears, but the process remains there.
   * What outcome did you expect instead?
Stable transmit of audio signals, no other app to break.


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

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

Versions of packages js8call depends on:
ii  libc6  2.31-13
ii  libfftw3-single3   3.3.8-2
ii  libgcc-s1  10.2.1-6
ii  libgfortran5   10.2.1-6
ii  libgomp1   10.2.1-6
ii  libhamlib-utils4.0-7
ii  libhamlib4 4.0-7
ii  libqcustomplot2.0  2.0.1+dfsg1-4
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5multimedia5  5.15.2-3
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5serialport5  5.15.2-2
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libsqlite3-0   3.34.1-3
ii  libstdc++6 10.2.1-6
ii  wsjtx-data 2.3.0+repack-2

js8call recommends no packages.

js8call suggests no packages.

Bug#870058: xsane failing since stretch upgrade

[Jörg Frings-Fürst]

Hello,

please can you check if the bug this bug with  

 - sane-backends 1.0.32-4 (currently in testing)

still exists?

Thanks in advance

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#993164: proftpd-core: When upgrading from Buster to Bullseyes, the installation of ProFTPd fails

[Hilmar Preuße]

Am 28.08.2021 um 16:46 teilte Andreas Günther mit:

Hi,

please keep the bug in Cc.


here I have the output from systemctl status proftpd.service:
proftpd.service - ProFTPD FTP Server
  Loaded: loaded (/lib/systemd/system/proftpd.service; enabled; 
vendor preset: enabled)
  Active: failed (Result: exit-code) since Sat 2021-08-28 10:16:33 
CEST; 6h ago
     Process: 37982 ExecStartPre=/usr/sbin/proftpd --configtest -c 
$CONFIG_FILE (code=exited, status=1/FAILURE)

     CPU: 6ms

Aug 28 10:16:33 web systemd[1]: Starting ProFTPD FTP Server...
Aug 28 10:16:33 web proftpd[37982]: Checking syntax of configuration file
Aug 28 10:16:33 web proftpd[37982]: 2021-08-28 10:16:33,852 web 
proftpd[37982]: mod_dso/0.5: unable to load 'mod_tls.c'; check to see if 
'/usr/lib/proftpd/mod_tls.la' exists
Aug 28 10:16:33 web proftpd[37982]: 2021-08-28 10:16:33,852 web 
proftpd[37982]: fatal: LoadModule: error loading module 'mod_tls.c': 
Datei oder Verzeichnis nicht gefunden on line 16 o>
Aug 28 10:16:33 web proftpd[37982]: 2021-08-28 10:16:33,852 web 
proftpd[37982]: warning: unable to include '/etc/proftpd/modules.conf': 
Die Operation ist nicht erlaubt
Aug 28 10:16:33 web proftpd[37982]: 2021-08-28 10:16:33,853 web 
proftpd[37982]: mod_dso/0.5: unable to load 'mod_wrap.c'; check to see 
if '/usr/lib/proftpd/mod_wrap.la' exists
Aug 28 10:16:33 web proftpd[37982]: 2021-08-28 10:16:33,853 web 
proftpd[37982]: fatal: LoadModule: error loading module 'mod_wrap.c': 
Datei oder Verzeichnis nicht gefunden on line 8 o>
Aug 28 10:16:33 web systemd[1]: proftpd.service: Control process exited, 
code=exited, status=1/FAILURE
Aug 28 10:16:33 web systemd[1]: proftpd.service: Failed with result 
'exit-code'.

Aug 28 10:16:33 web systemd[1]: Failed to start ProFTPD FTP Server.



Hmm, weird: the modules in question should be provided by 
proftpd-mod-wrap & proftpd-mod-crypto, should should have installed. 
Could you check if the files /usr/lib/proftpd/mod_tls.so & 
/usr/lib/proftpd/mod_wrap.so do exist?


Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#993074: recommonmark: New upstream version 0.7.1 available.

[Emmanuel Arias]

> Possibly a good idea. With only 3 this might be indeed feasible...
> Do you want to file wishlist bugs to the packages?
>

Sure.

I'll do it today/tomorrow

Cheers,
Emmanuel

Bug#993207: regression: constant ~20% CPU usage + crackling sound since 15.0+dfsg1-2

[Christoph Anton Mitterer]

Source: pulseaudio
Version: 15.0+dfsg1-2
Severity: grave
Justification: renders package unusable



Hi

Since upgrading to 15.0+dfsg1-2, the pulseaudio daemon runs constantly at 
around ~20% CPU
on my system (even when no sound is played).

If sound is played it's constantly crackling.

Downgrading to the previous 14.2-2 from testing (and restarting the daemon) 
fixes the issue.

Any ideas?

Thanks,
Chris.


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


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

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

-- no debconf information
# 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 =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# 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 the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = speex-float-1
; avoid-resampling = false
; enable-remixing = yes
; remixing-use-all-sink-channels = yes
; remixing-produce-lfe = no
; remixing-consume-lfe = no
; lfe-crossover-freq = 0

; flat-volumes = no

; rescue-streams = yes

; rlimit-fsize = -1
; rlimit-data = -1
; rlimit-stack = -1
; rlimit-core = -1
; rlimit-as = -1
; rlimit-rss = -1
; rlimit-nproc = -1
; rlimit-nofile = 256
; rlimit-memlock = -1
; rlimit-locks = -1
; rlimit-sigpending = -1
; rlimit-msgqueue = -1
; rlimit-nice = 31
; rlimit-rtprio = 9
; rlimit-rttime = 20

; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
; default-sample-channels = 2
; default-channel-map = front-left,front-right

; default-fragments = 4
; default-fragment-size-msec = 25

; enable-deferred-volume = yes
; deferred-volume-safety-margin-usec = 8000
; deferred-volume-extra-delay-usec = 0
#!/usr/bin/pulseaudio -nF
#
# 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 

Bug#941038: sane-backends: /lib/udev/rules.d/60-libsane.rules seems incomplete

[Jörg Frings-Fürst]

tags 941038 - pending
notfixed 941038 1.0.31-3
--

Hello,

this bug was fixed with the stable version 1.0.31-3. So this bug can
closed.

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#993180: [Pkg-matrix-maintainers] Bug#993180: python3-matrix-nio: Please upgrade bookworm with sid version

[Jonas Smedegaard]

Quoting Mag. Dr. Karl Kashofer (2021-08-28 15:51:02)
> > Quoting Karl Kashofer (2021-08-28 15:11:26)
> > > matrix-mirage fails to start up due to improper message processing 
> > > in matrix- nio
> > 
> > Ah, right - thanks for reporting!
> > 
> > Newer NIO breaks older Matrix Mirage.  A newer Matrix Mirage is 
> > waiting for a few newly introduced libraries to get approved by 
> > ftpmaster.
> i run the current pinephone bookworm release. it uses matrix-mirage 
> 0.6.4-dsfg+hsluv1.0.0.4 and i now use python3- matrix-nio 0.18.6-1.
> 
> this seems to work OK, so i presume upgrading the bookworm release 
> should be safe ?

Thanks for the explicit confirmation - that is really helpful!

 - 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#993071: kmail: symbol lookup error: /lib/x86_64-linux-gnu/libKF5Libkleo.so.5: undefined symbol: _ZN5GpgME6UserID9SignatureltERKS1_

[Johannes Rohr]

Am 28.08.21 um 16:50 schrieb Norbert Preining:
>> libgpgmepp.so.6 => /usr/local/lib/libgpgmepp.so.6 (0x7efde318f000)
> That is a version you compiled yourself, and you cannot expect that this
> is supported.

Yikes. Must have done that ages ago and forgotten about it.

Sorry,

Johannes



>
> Please remove local version and retest.
>
> Best
>
> Norbert
>
> --
> PREINING Norbert  https://www.preining.info
> Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#993071: kmail: symbol lookup error: /lib/x86_64-linux-gnu/libKF5Libkleo.so.5: undefined symbol: _ZN5GpgME6UserID9SignatureltERKS1_

[Norbert Preining]

> libgpgmepp.so.6 => /usr/local/lib/libgpgmepp.so.6 (0x7efde318f000)

That is a version you compiled yourself, and you cannot expect that this
is supported.

Please remove local version and retest.

Best

Norbert

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

Bug#993206: libreoffice-gtk3: Not possible to auto-filter by colour in Calc with libreoffice-gtk3

[valeoak]

Package: libreoffice-gtk3
Version: 1:7.2.0-3
Severity: normal

Dear Maintainer,

It isn't possible to auto-filter by text or background colour in Calc using 
GNOME with libreoffice-gtk3 installed. Even
when cells in the column have a background colour applied, the colours do not 
appear
when clicking the appropriate auto-filter options (otherwise,
auto-filtering operates normally, e.g. a-z).

Uninstalling libreoffice-gtk3 allows the selection of colours in the
auto-filter options, but obviously makes Calc (and the other LibreOffice
programs) much less visually appealing / usable. Reinstalling
libreoffice-gtk3 reintroduces the inability to auto-filter by colour.

libreoffice-gnome is also installed: removing it did not seem to have an
effect one way or the other.

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

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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice-gtk3 depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-17
ii  libcairo21.16.0-5
ii  libepoxy01.5.8-1
ii  libgcc-s111.2.0-3
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.68.4-1
ii  libgtk-3-0   3.24.30-2
ii  libpango-1.0-0   1.46.2-3
ii  libreoffice-core 1:7.2.0-3
ii  libstdc++6   11.2.0-3
ii  libuno-cppu3 1:7.2.0-3
ii  libuno-cppuhelpergcc3-3  1:7.2.0-3
ii  libuno-sal3  1:7.2.0-3
ii  libx11-6 2:1.7.2-1
ii  uno-libs-private 1:7.2.0-3

Versions of packages libreoffice-gtk3 recommends:
ii  gstreamer1.0-gtk3  1.18.4-2

Versions of packages libreoffice-gtk3 suggests:
pn  libreofficekit-data  

-- no debconf information

Bug#990305: Introduce ARC support in Perl cross-compiling for Debian

[gregor herrmann]

On Sat, 28 Aug 2021 10:55:28 +0300, Niko Tyni wrote:

> For now, I'm leaning towards making a policy of only including config.sh
> files from native package builds rather than possibly broken handcrafted
> ones.

FWIW, this approach sounds reasonable to me.


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#993074: recommonmark: New upstream version 0.7.1 available.

[Tobias Frost]

On Fri, Aug 27, 2021 at 12:07:45PM -0300, Emmanuel Arias wrote:
> Hi,
> 
> On 8/27/21 5:06 AM, Tobias Frost wrote:
> > Source: recommonmark
> > Severity: wishlist
> >
> > Upstream has released 0.7.1 on Dec 17 2020.
> > Please consider updating it.
> >
> > PS: Upstream deprecates itself. However, there are reverse dependencies...
> > Maybe that needs to be tackled instead of updating..
> 
> I can take a look on the r-depends
> 
> * python3-seqcluster
> * formiko
> * python3-jupyter-sphinx-theme
> 
> Maybe it's a good idea ITP MyST-Parser? Should we try to remove
> recommonmark?

Possibly a good idea. With only 3 this might be indeed feasible...
Do you want to file wishlist bugs to the packages?

 
> -- 
> Emmanuel Arias
> @eamanu
> yaerobi.com
> 

Bug#993205: GCC trunk (12) ftbfs on armel

[Matthias Klose]

Package: src:gcc-snapshot
Version: 1:20210827-1
Severity: important
Tags: sid bullseye
X-Debbugs-CC: debian-...@lists.debian.org

GCC trunk (12.0) ftbfs on armel:

[...]
/<>/build/gcc/ada/rts/s-atopri.adb:80: undefined reference to
`__atomic_load_8'
collect2: error: ld returned 1 exit status
gnatlink: error when calling /<>/build/gcc/xg++
make[5]: *** [../gcc-interface/Makefile:451: common-tools] Error 4
make[5]: Leaving directory '/<>/build/gcc/ada/tools'

Bug#993183: gnome-shell-extension-autohidetopbar: does not declare compatibility with GNOME Shell 40

[Tobias Frost]

On Sat, Aug 28, 2021 at 02:35:49PM +0100, Simon McVittie wrote:
> Package: gnome-shell-extension-autohidetopbar
> Version: 20210104-1
> Severity: important
> Tags: patch fixed-upstream
> 
> The metadata.json for this extension doesn't declare compatibility with
> GNOME 40.
> 
> This is fixed in upstream git:
> https://github.com/mlutfy/hidetopbar/commit/72312520ce8628971a1edcd3a8340ada45c37f98
> https://github.com/mlutfy/hidetopbar/commit/341cd95a75264c781ec77b1e5e9a9cd98e40db18
> 
> In many versions of GNOME Shell this didn't matter much, because
> validation of extensions' metadata against the installed Shell version
> was disabled by default, but in GNOME 40 the default has changed back
> to enabling the version check by default, in an effort to avoid issues
> caused by outdated extensions remaining enabled.
> 
> When we do the GNOME 40 transition, hopefully soon, we will have to
> either update this extension or remove it from testing. It would be
> useful to get a fixed version into experimental.
> 
> Would you mind adding the GNOME team to Uploaders so we can "officially"
> do team-uploads? I think that'd be useful for future transitions.

Sure! I'd propse to have the Gnome team as maintainer and /me as Uploader?
Would that be ok for you?

Regarding the package, I'll upload a new version soon (its on my backlist); If 
I timeout,
just to an team upload yourself, it's in the salsa "debian" [1] group for a 
reason :)


[1] (as in 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group 
defined)

--
tobi

Bug#993204: gnome-shell-timer: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-timer
Version: 3.38.0-1
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993203: gnome-shell-mailnag: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-mailnag
Version: 3.38.1-1
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993202: gnome-shell-extension-weather: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-weather
Version: 0.0~git20201103.d8be50f-1
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993201: gnome-shell-extension-trash: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-trash
Version: 0.2.0-git20200326.3425fcf1-1
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993200: gnome-shell-extension-tilix-shortcut: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-tilix-shortcut
Version: 1.0.1-2
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993199: gnome-shell-extension-tilix-dropdown: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-tilix-dropdown
Version: 7-1
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993198: gnome-shell-extension-system-monitor: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-system-monitor
Version: 38+git20200414-32cc79e-1
Severity: important
Tags: fixed-upstream

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. This seems to have been fixed in upstream git, along with
preferences UI changes to make it work in GNOME 40.

In many versions of GNOME Shell this didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default, but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Would you mind adding the GNOME team to Uploaders so we can "officially"
do team-uploads? I think that'd be useful for future transitions.

Thanks,
smcv

Bug#993197: gnome-shell-extension-shortcuts: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-shortcuts
Version: 1.1.2-2
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993196: gnome-shell-extension-remove-dropdown-arrows: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-remove-dropdown-arrows
Version: 13-1
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993194: gnome-shell-extension-panel-osd: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-panel-osd
Version: 1.0.50.gc032923-1
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993195: gnome-shell-extension-pixelsaver: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-pixelsaver
Version: 1.24-1
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#981153:

[Sonia Franklin]

 Dear Sir/Madam,
I have important transaction to discuss with you and i need your urgent
attention.
Greetings.

Bug#993193: gnome-shell-extension-no-annoyance: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-no-annoyance
Version: 0+20170928-f21d09a-2
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993192: gnome-shell-extension-multi-monitors: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-multi-monitors
Version: 23-1
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993191: gnome-shell-extension-move-clock: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-move-clock
Version: 0.4.5-4
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993180: [Pkg-matrix-maintainers] Bug#993180: python3-matrix-nio: Please upgrade bookworm with sid version

[Mag. Dr. Karl Kashofer]

Hi Jonas !

> Quoting Karl Kashofer (2021-08-28 15:11:26)
> > matrix-mirage fails to start up due to improper message processing
> > in 
> > matrix- nio
> 
> Ah, right - thanks for reporting!
> 
> Newer NIO breaks older Matrix Mirage.  A newer Matrix Mirage is
> waiting 
> for a few newly introduced libraries to get approved by ftpmaster.
i run the current pinephone bookworm release. 
it uses matrix-mirage 0.6.4-dsfg+hsluv1.0.0.4 and i now use python3-
matrix-nio 0.18.6-1.

this seems to work OK, so i presume upgrading the bookworm release
should be safe ?

Cheers,
KK


> 
> I missed that NIO needs to declare that it breaks Mirage (won't help
> get 
> it to work, but will at least help recognize the issue).
> 
> 
>  - Jonas
> 


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

Bug#993190: gnome-shell-extension-impatience: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-impatience
Version: 0.4.5-4
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993189: gnome-shell-extension-hide-veth: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-hide-veth
Version: 1.0.2-1.1
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993188: gnome-shell-extension-hide-activities: discontinued upstream

[Simon McVittie]

Source: gnome-shell-extension-hide-activities
Version: 0.00~git20131024.1.6574986-2
Severity: important
Tags: upstream wontfix

https://github.com/shayelkin/gnome-hide-activities:
>  This repository has been archived by the owner. It is now read-only.

Bug#993187: gnome-shell-extension-hide-activities: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-hide-activities
Version: 0.00~git20131024.1.6574986-2
Severity: important
Tags: fixed-upstream

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993186: gnome-shell-extension-hamster: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-hamster
Version: 0.10.0+git20200509-2
Severity: important
Tags: fixed-upstream

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. There seem to be fixes in upstream git for the actual code,
but I haven't investigated in detail.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993185: gnome-shell-extension-desktop-icons: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-extension-desktop-icons
Version: 20.04.0+git20200908-8
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I'm not sure whether the actual code is compatible or not.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv