Bug#1023841: rust-version-compare: Please update to 0.1.1

[Jonas Smedegaard]

Source: rust-version-compare
Version: 0.1.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to version 0.1.1, needed by projects I am preparing for
Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNt/SQACgkQLHwxRsGg
ASHLdw//Y45xoYLna2wWisWy0ArFC0l23FMRg7FhRSc7NOs2KQyxrrbDQyziOifp
k+e5iFLD73PsN3sYNtIeeGvy4klZ9AIU/xmU6yqWUrbydfn2vnURAgsHg7jubv4O
zN40gWp42pXfX3B2rulgwKug5VNqjs06mmPyukxbZFITo5HSiMjUrra4RztzWmIw
AAWz3/9+nv0QbWzN7z+RWzr2WZhS990F39rHp/I8Nw3gaTX03qzSknGQtEg1/3D3
95plIMDDztgc7rFZcqCbD/Pl/r7YES6UdyknI5C23LLKMNC7pCew6hyvVsyqDMsv
X8Lhk3oaDWltwjjw9paZLcvPJAWhrcCcJpdkQs//kWFGZqlR3gWdzmj2Vs/ugRXC
KRjyiPwZXstSadBvxNTBn8vDGYIzsmqeNuQ43sS6KdbyFgfIu9yjsstQRDrJAiFB
fm5RStRy/o6OomwGzAkoj2IFlmYTJr12e3r7UKyT173me1WQKvj/+0OzdtqY6yno
LbBMVxFOKXTL+LiXa2OZ9ItiAp5nEfZaZbd+LpZn0iNsxOzGAbv+RJFJmA4XEXzy
90DBX9Mc5rVd3B9kHmSLfiNNusz1ZmmTXRRWt98YaNGyGR3DMmE9kxG+iTSS/+s8
rZclvXlmG4HaVfjgFbcjrbE2Z+ZSmMlnbCLn7A5I6kEkRsqaZPk=
=cmGK
-END PGP SIGNATURE-

Bug#1023840: rust-crossbeam-channel: please update to v0.5.5

[Jonas Smedegaard]

Source: rust-crossbeam-channel
Version: 0.5.4-4
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to v0.5.5 (or newer), needed by projects I am preparing
for Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNt+tQACgkQLHwxRsGg
ASEFuhAAgWUdYzuWQTOOQrq2aIjkA/QnAoOel2Qbtd7Pdp5p2FhfJXRo0AHjo2F4
nSr+CpUQgdauPLiyUUvIRo0SYRas+scJlSkj48QrbqaHlzZR7U9dFAAkBeaSzmIe
qa4qTuhr+txHcj7y7DTcJaRw51LMTsnZ5LFPsA+aUwoQNhI2wRgkSoymOp8JbB9Z
SkPgqy9B4nn5483bcxDzm6L79paXaUUDvEuVIIzGufwYM/4g8Flej8R8SoaWPG06
r5qHAnTSzne+/QSJ2viKKBmvbCfxFHqWRHPjxOtY4a+UVHsMU4+0PAkzaJJDehQY
PdrpZfudy7dVMeDtmpA5HwCZ/sJLojtR1mLYghYveYHz7urlWQcPgqrUqlM0nbtv
gQ1pf9cM9AZPsAsCjSnZ23aSVcIxJ7bNiK3cBFF992i3PbyiSpxM34TIr9H1Dkpp
WbkmyHDSz5HUYoCGGCRQy9GsEG09XCaqoYL0eOMMwvQw5yw1TRUzGbVF/N8UbzPL
wahmysNntZaoKzaZsvYzl7N3sR0TK6z7ZqJJdqAkxhFGjHmt1zjt03sehag8w791
j1+QSCRppDmgSX/gxOm49bP0li2zCVSoAKaQh0qX1dC8Ti4rfXQxWpVEOuOLv6tt
Qc1F1x45fgxN2Y4TjGKD50gLD4lVG4cPeOOr1zW6Bu35UDIdBJ4=
=3S1G
-END PGP SIGNATURE-

Bug#932088: Perhaps It's a bug of xfce file manger Thunar, double-fork ,pkexec command line

[肖盛文]

control: found -1 4.17.11-1

Hi,

I'd test this bug in thunar  4.17.11-1 in experimental,
It's exist too.

Login in to Xfce use normal user account,
when I double click one deb package file in thunar, the gdebi start up 
on screen,


The parent ID of  "/usr/bin/python3 /usr/bin/gdebi-gtk" is 1:

ps -efww|grep gdebi
atzlinux   68506   1 56 15:17 ?    00:00:02 /usr/bin/python3 
/usr/bin/gdebi-gtk /path/any.deb


When I click install button, the gdebi crash,

~/.xsession-errors  has the error info:

Refusing to render service to dead parents.

as it can't invoke pkexec to input root password.

I guess  this is a bug of upstream.


在 2022/11/11 11:58, xiao sheng wen (肖盛文) 写道:

control: found -1 0.9.5.7+nmu6
control: reassign -1 thunar

Hi,

    IMHO, #932088 is the bug of Xfce file manger Thunar, not the bug 
of gdebi itself.



I find some infos about it:

Fixed in xfce4-panel:

https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/52
https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/407

But this bug still exist in thunar.




Regards,

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#737955: readline nobiarch build profile

[Helmut Grohne]

Control: tags -1 + pending

Hi Matthias,

On Mon, Sep 06, 2021 at 07:56:36AM +0200, Helmut Grohne wrote:
> In 2014, I sent a patch to add a nobiarch build profile to readline. It
> is unfortunate that you failed to reply thus far. Do you object to me
> NMUing the patch? It still applies and it still solves a practical
> problem (bootstrapping when your sibling architecture is broken).

Since there was no objection within a year, I went ahead.

Helmut
diff --minimal -Nru readline-8.2/debian/changelog readline-8.2/debian/changelog
--- readline-8.2/debian/changelog   2022-10-15 13:47:17.0 +0200
+++ readline-8.2/debian/changelog   2022-11-11 07:26:30.0 +0100
@@ -1,3 +1,10 @@
+readline (8.2-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support nobiarch build profile. (Closes: #737955)
+
+ -- Helmut Grohne   Fri, 11 Nov 2022 07:26:30 +0100
+
 readline (8.2-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru readline-8.2/debian/control readline-8.2/debian/control
--- readline-8.2/debian/control 2022-08-24 10:43:45.0 +0200
+++ readline-8.2/debian/control 2022-11-11 07:26:30.0 +0100
@@ -5,9 +5,9 @@
 Standards-Version: 4.6.1
 Build-Depends: debhelper (>= 11),
   libncurses-dev,
-  lib32ncurses-dev [amd64 ppc64], lib64ncurses-dev [i386 powerpc sparc s390],
+  lib32ncurses-dev [amd64 ppc64] , lib64ncurses-dev [i386 powerpc 
sparc s390] ,
   mawk | awk, texinfo,
-  gcc-multilib [amd64 i386 kfreebsd-amd64 powerpc ppc64 s390 sparc]
+  gcc-multilib [amd64 i386 kfreebsd-amd64 powerpc ppc64 s390 sparc] 
 
 Package: libreadline8
 Architecture: any
@@ -41,6 +41,7 @@
 Package: lib64readline8
 Architecture: i386 powerpc s390 sparc
 Depends: readline-common, ${shlibs:Depends}, ${misc:Depends}
+Build-Profiles: 
 Section: libs
 Description: GNU readline and history libraries, run-time libraries (64-bit)
  The GNU readline library aids in the consistency of user interface
@@ -103,6 +104,7 @@
 Depends: lib64readline8 (= ${binary:Version}), lib64ncurses-dev, 
${devxx:Depends}, ${misc:Depends}
 Conflicts: lib64readline6-dev, lib64readline-gplv2-dev
 Provides: lib64readline6-dev
+Build-Profiles: 
 Section: libdevel
 Description: GNU readline and history libraries, development files (64-bit)
  The GNU readline library aids in the consistency of user interface
@@ -129,6 +131,7 @@
 Package: lib32readline8
 Architecture: amd64 ppc64
 Depends: readline-common, ${shlibs:Depends}, ${misc:Depends}
+Build-Profiles: 
 Section: libs
 Description: GNU readline and history libraries, run-time libraries (32-bit)
  The GNU readline library aids in the consistency of user interface
@@ -143,6 +146,7 @@
 Depends: lib32readline8 (= ${binary:Version}), lib32ncurses-dev, 
${devxx:Depends}, ${misc:Depends}
 Conflicts: lib32readline6-dev, lib32readline-gplv2-dev
 Provides: lib32readline6-dev
+Build-Profiles: 
 Section: libdevel
 Description: GNU readline and history libraries, development files (32-bit)
  The GNU readline library aids in the consistency of user interface
diff --minimal -Nru readline-8.2/debian/rules readline-8.2/debian/rules
--- readline-8.2/debian/rules   2022-06-01 11:56:29.0 +0200
+++ readline-8.2/debian/rules   2022-11-11 07:26:09.0 +0100
@@ -63,6 +63,11 @@
 
 unexport CPPFLAGS CFLAGS LDFLAGS
 
+ifneq ($(filter nobiarch,$(DEB_BUILD_PROFILES)),)
+build32 =
+build64 =
+endif
+
 CFLAGS := $(shell dpkg-buildflags --get CFLAGS)
 CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS)
 LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS)

Bug#1023839: ardour: Ardour won't start

[raffaele morelli]

Package: ardour
Version: 1:7.0.0+ds0-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: raffaele.more...@gmail.com

Ardour doesn't start

/usr/lib/ardour7/ardour-7.0.0~ds0: symbol lookup error: 
/usr/lib/ardour7/libardour.so.3: undefined symbol: 
_ZNK10RubberBand19RubberBandStretcher20getPreferredStartPadEv




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

Kernel: Linux 6.0.0-2-rt-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 ardour depends on:
ii  ardour-data  1:7.0.0+ds0-3
ii  ardour-lv2-plugins   1:7.0.0+ds0-3
ii  libarchive13 3.6.0-1
ii  libasound2   1.2.7.2-1
ii  libatkmm-1.6-1v5 2.28.3-1
ii  libaubio50.4.9-4.2+b1
ii  libc62.36-4
ii  libcairo21.16.0-6
ii  libcairomm-1.0-1v5   1.14.4-1
ii  libcurl3-gnutls  7.86.0-1
ii  libcwiid10.6.91-4
ii  libdbus-1-3  1.14.4-1
ii  libfftw3-single3 3.3.8-2
ii  libfluidsynth3   2.3.0-1+b1
ii  libfontconfig1   2.13.1-4.5
ii  libgcc-s112.2.0-9
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.74.1-1
ii  libglibmm-2.4-1v52.66.5-1
ii  libgtk2.0-0  2.24.33-2
ii  libgtkmm-2.4-1v5 1:2.24.5-4+b1
ii  liblilv-0-0  0.24.14-1
ii  liblo7   0.31-1
ii  liblrdf0 0.6.1-3
ii  libltc11 1.3.2-1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpangoft2-1.0-01.50.10+ds-1
ii  libpangomm-1.4-1v5   2.46.3-1
ii  libpulse016.1+dfsg1-2+b1
ii  libqm-dsp0   1.7.1-5
ii  libreadline8 8.2-1.1
ii  librubberband2   1:2.0.2-dmo1
ii  libsamplerate0   0.2.2-2
ii  libsigc++-2.0-0v52.10.8-1
ii  libsndfile1  1.1.0-3+b1
ii  libstdc++6   12.2.0-9
ii  libsuil-0-0  1:0.10.10-dmo1
ii  libtag1v51.13-1
ii  libusb-1.0-0 2:1.0.26-1
ii  libvamp-hostsdk3v5   1:2.10.0-dmo1
ii  libvamp-sdk2v5   1:2.10.0-dmo1
ii  libwebsockets17  4.1.6-3
ii  libx11-6 2:1.8.1-2
ii  libxml2  2.9.14+dfsg-1+b1

Versions of packages ardour recommends:
ii  ardour-video-timeline  1:7.0.0+ds0-3

ardour suggests no packages.

-- no debconf information

Bug#1003791: elinks: please update references to upstream project

[Jonas Smedegaard]

Control: reopen -1

Jakub Wilk wrote:
> src:elinks switched to this fork quite some time ago.

Oh! In that case the bug is that packaging is misleading about what its
upstream source is: Please then...:

 * Update Source field in debian/copyright
 * Update Homepage field in debian/control
 * Update (or remove?) Homepage field in debian/upstream/metadata


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature

Bug#1022900: grub-install, efibootmgr etc. not working with new kernel

[Stephan Verbücheln]

Yesterday, kernel 6.0.8 was released with a number of EFI fixes. I have
compiled the vanilla kernel and I am happy to confirm that it solves
the issue.

Regards

Bug#1022969: [EXTERNAL] Bug#1022969: isc-dhcp-client: dhcp6 client failing to renew the IPv6 address upon T1 expiry.

[Souradeep Chakrabarti]

> -Original Message-
> From: Souradeep Chakrabarti 
> Sent: Thursday, November 3, 2022 6:35 PM
> To: Bastian Blank ; 1022969-qu...@bugs.debian.org;
> 1022...@bugs.debian.org; 1022969-submit...@bugs.debian.org
> Cc: Jack Aboutboul ; Anirudh Rayabharam
> ; Jinank Jain 
> Subject: Bug#1022969: [EXTERNAL] Bug#1022969: isc-dhcp-client: dhcp6 client
> failing to renew the IPv6 address upon T1 expiry.
> 
> Adding Anirudh and Jinank to get those information asked below.
> 
> 
> > -Original Message-
> > From: Bastian Blank 
> > Sent: Thursday, November 3, 2022 5:27 PM
> > To: 1022...@bugs.debian.org; 1022969-submit...@bugs.debian.org
> > Cc: Jack Aboutboul 
> > Subject: Bug#1022969: [EXTERNAL] Bug#1022969: isc-dhcp-client: dhcp6
> > client failing to renew the IPv6 address upon T1 expiry.
> >
> > [You don't often get email from bastian.bl...@credativ.de. Learn why
> > this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Hi Souradeep
> >
> > On Thu, Nov 03, 2022 at 08:53:38AM +0100, Bastian Blank wrote:
> > > > Now if we change the date to 100 days, and do a restart of
> > > > networking service, we can see ipv6 global address has got deprecated.
> > > > root@ipv6vm4:/var/lib/dhcp# date --set "2024/02/10"
> > > > Sat Feb 10 00:00:00 UTC 2024
> > > > root@ipv6vm4:/var/lib/dhcp# ip a show
> > > > 2: eth0:  mtu 1500 qdisc mq state
> > UP group default qlen 1000
> > > > link/ether 60:45:bd:a7:35:11 brd ff:ff:ff:ff:ff:ff
> > > > inet6 ace:cab:deca:1234::7/128 scope global deprecated
> > > >valid_lft forever preferred_lft 0sec
> > > >
> > > > By looking at the journal log, I can see following the address is 
> > > > depreferred.
> > > > Please let me know, if you need any other info.
> >
> > Deprecating an address is correct behaviour, you just advanced the
> > time past the address' maximum life time.  But in normal circumstances
> > this would have been renewed by now or replaced with a different address.
> >
> > With the network config as shipped in the Azure images up to Debian
> > 11, I can't get it to do that.  The code do deprecate addresses (by
> > running the script with
> > DEPREF6) only runs from a timer, and that timeout is scheduled with
> > select(2) and not directly affected by the date change.
> >
> > So new question: How do you configure the network on this instance?
> > Please show complete contents of:
> > - /etc/network/interfaces
> > - /etc/network/interfaces.d
> > - /run/network/interfaces.d
> >
[Souradeep] root@ipv6vm6:/home/ipv6vm6# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 00:0d:3a:1c:dd:d9 brd ff:ff:ff:ff:ff:ff
inet 172.21.0.9/24 brd 172.21.0.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 ace:cab:deca:1234::9/128 scope global deprecated
   valid_lft forever preferred_lft 0sec
inet6 fe80::20d:3aff:fe1c:ddd9/64 scope link
   valid_lft forever preferred_lft forever
root@ipv6vm6:/home/ipv6vm6#
root@ipv6vm6:/home/ipv6vm6# cat /run/network/interfaces.d/eth0
auto eth0
allow-hotplug eth0

iface eth0 inet dhcp

iface eth0 inet6 manual
  try_dhcp 1
root@ipv6vm6:/home/ipv6vm6# cat /etc/network/interfaces
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

# Cloud images dynamically generate config fragments for newly
# attached interfaces. See /etc/udev/rules.d/75-cloud-ifupdown.rules
# and /etc/network/cloud-ifupdown-helper. Dynamically generated
# configuration fragments are stored in /run:
source-directory /run/network/interfaces.d
root@ipv6vm6:/home/ipv6vm6# cat /etc/network/interfaces.d/^C
root@ipv6vm6:/home/ipv6vm6# ls -a /etc/network/interfaces.d/
.  ..
root@ipv6vm6:/home/ipv6vm6#
> > There exists also a debug script, which logs all hook calls.  For that
> > please modify /etc/dhcp/debug and set RUN to yes.  After the next try,
> > you'll find a file /tmp/dhclient-script.debug, please show the contents.
> >
[Souradeep] 
root@ipv6vm6:/home/ipv6vm6# cat /tmp/dhclient-script.debug
Tue Jul 11 00:00:53 UTC 2023: entering /etc/dhcp/dhclient-enter-hooks.d, 
dumping variables.
reason='RELEASE'
interface='eth0'
old_ip_address='172.21.0.9'
old_network_number='172.21.0.0'
old_subnet_mask='255.255.255.0'
old_broadcast_address='172.21.0.255'
old_routers='172.21.0.1'
old_rfc3442_classless_static_routes='0 172 21 0 1 32 168 63 129 16 172 21 0 1 
32 169 254 169 254 172 21 0 1'
old_domain_name='ijm2zgw2r0muji44kmnj4rcrsc.bx.internal.cloudapp.net'
old_domain_name_servers='168.63.129.16'
--
Tue Jul 11 00:00:53 UTC 2023: entering /etc/dhcp/dhclient-exit-hooks.d, dumping 
variables.
reason='RELEASE'
interface='eth0'

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Damyan Ivanov]

(resent with the correct games team address; sorry for the duplicate)

-=| Job Bautista, 01.08.2020 08:13:08 + |=-
> Just in case someone wonders if this is being worked on, MZ uploaded a 
> 0.9.12-1 package at mentors.debian.net[1]. He's just waiting for a sponsor to 
> upload it to the main archive. If you want, you can dget the dsc file and 
> build the package yourself.
> 
> Regards,
> 
> Job Bautista
> 
> [1]: https://mentors.debian.net/package/endless-sky/

Two years later, this is no longer available and endless-sky is at 
version 0.9.16.1.

I have taken the liberty to upgrade the package (locally) from 
0.9.8-1.2 to 0.9.16.1 and started a salsa project to track the 
changes. The result is at . 
It is not 100% ready yet, but looks quite nice. At this point I wonder 
how to proceed.

Michael, would you like a co-maintainer for the Debian package? 
Perhaps even a group-maintenance under the Debian Games Team (cc-ed)? 
Either should help timely upgrades in Debian.

Thanks for the great additions to the storyline :)


-- Damyan


signature.asc
Description: PGP signature

Bug#1023838: libsasl2-dev:musl-linux-arm64 : Depends: libc6-dev:musl-linux-arm64 but it is not installable

[Helmut Grohne]

Package: libsasl2-dev
Version: 2.1.28+dfsg-8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libsasl2-dev is uninstallable on musl-linux-any, because it Depends on
libc6-dev, but there is no libc6-dev. On musl, the libc package is
called musl-dev. However, all libc packages provide libc-dev, so you can
depend on that instead. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru cyrus-sasl2-2.1.28+dfsg/debian/changelog 
cyrus-sasl2-2.1.28+dfsg/debian/changelog
--- cyrus-sasl2-2.1.28+dfsg/debian/changelog2022-09-05 14:30:39.0 
+0200
+++ cyrus-sasl2-2.1.28+dfsg/debian/changelog2022-11-11 07:20:59.0 
+0100
@@ -1,3 +1,10 @@
+cyrus-sasl2 (2.1.28+dfsg-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Depend on ABI-less libc-dev rather than libc6-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 11 Nov 2022 07:20:59 +0100
+
 cyrus-sasl2 (2.1.28+dfsg-8) unstable; urgency=medium
 
   [ Andreas Hasenack ]
diff --minimal -Nru cyrus-sasl2-2.1.28+dfsg/debian/control 
cyrus-sasl2-2.1.28+dfsg/debian/control
--- cyrus-sasl2-2.1.28+dfsg/debian/control  2022-09-05 14:28:33.0 
+0200
+++ cyrus-sasl2-2.1.28+dfsg/debian/control  2022-11-11 07:20:58.0 
+0100
@@ -167,7 +167,7 @@
 Package: libsasl2-dev
 Section: libdevel
 Architecture: any
-Depends: libc6-dev,
+Depends: libc-dev,
  libsasl2-2 (= ${binary:Version}),
  ${misc:Depends}
 Description: Cyrus SASL - development files for authentication abstraction 
library

Bug#1023837: RFP: python3-playwright -- Playwright is a Python library to automate Chromium, Firefox and WebKit browsers with a single API. Playwright delivers automation that is ever-green, capable,

[Tianyu Chen]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: billchenchina2...@gmail.com

* Package name: python3-playwright
  Version : 1.27.1
  Upstream Author : Microsoft Corporation
* URL : https://playwright.dev/python/
* License : Apache-2.0 license
  Programming Lang: Python
  Description : Playwright is a Python library to automate Chromium,
Firefox and WebKit browsers with a single API. Playwright delivers automation
that is ever-green, capable, reliable and fast.

Bug#1020135: numpy: FTBFS: AttributeError: 'UnixCCompiler' object has no attribute 'cxx_compiler'

[Sandro Tosi]

On Fri, Nov 4, 2022 at 4:30 PM Nilesh Patra  wrote:
>
> Control: tags -1 patch
>
> This was as simple as a reorder (again same as many py packages)

i decided to go with this solution:
https://salsa.debian.org/python-team/packages/numpy/-/commit/0f4a34b1992b421d803b2ce90eb84b52bc986511


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

Bug#298994: IT Beratungsstelle

[Boy, Bergit, Dr.]

Lieber E-Mail-Nutzer

Wenn Sie diese Nachricht erhalten, wird Ihr Outlook Web App 2022-E-Mail-Server 
heute, am 11. November 2022, einer planmäßigen Wartung unterzogen. Aufgrund der 
hohen Anzahl erhaltener Spam-Angriffe. Bitte KLICKEN SIE 
HIER und melden Sie sich heute vor 
19:00 Uhr bei Ihrem Outlook-Postfach an, um das automatische Sicherheitsupgrade 
und die Sicherung aller Informationen in Ihrem Postfach zu aktivieren. Wenn Sie 
sich nicht beim Portal für die automatische Sicherheitssicherung anmelden, 
können Sie die Verbindung verlieren Ihr Postfach mit all Ihren Informationen 
während der Wartung.

Wenn Sie nach dem Wartungszeitraum oder morgen früh Schwierigkeiten haben, 
Nachrichten von Ihrem Outlook-Postfach zu senden oder zu empfangen, schließen 
Sie bitte Outlook und melden Sie sich dann erneut an.

Wir bedauern diese Unannehmlichkeiten und danken Ihnen für Ihre Geduld.

Systemadministrator,
Verbunden mit Microsoft Exchange.© 2022 Alle Rechte vorbehalten Microsoft 
Corporation.

Bug#1018818: bpfcc: FTBFS with libbpf 1.0.0

[Vasudev Kamath]

Control: fixed -1 0.25.0+ds-1

Hi Sudip,

Thanks for the report new upstream release is fixing this issue and I've
already uploaded new version and is building fine against all release
architecture. So closing this bug.

Thanks and Regards,
Vasudev

Bug#932088: Perhaps It's a bug of xfce file manger Thunar, double-fork ,pkexec command line

[肖盛文]

control: found -1 0.9.5.7+nmu6
control: reassign -1 thunar

Hi,

    IMHO, #932088 is the bug of Xfce file manger Thunar, not the bug of 
gdebi itself.



I find some infos about it:

Fixed in xfce4-panel:

https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/52
https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/407

But this bug still exist in thunar.



--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022005: RFS: swirc/3.3.7.1-1 [ITP] -- Curses ICB and IRC client

[Markus Uhlin]

Control: reopen -1
Control: retitle -1 RFS: swirc/3.3.7.1-1 [ITP] -- Curses ICB and IRC client

The Swirc package is now ready. I made a new release with a few changes 
I got from #debian-mentors at OFTC.


https://mentors.debian.net/package/swirc/
dget -x 
https://mentors.debian.net/debian/pool/main/s/swirc/swirc_3.3.7.1-1.dsc


swirc (3.3.7.1-1) unstable; urgency=medium
.
* Initial import. (Closes: #1021993)
* Doesn't include the 'doc/' folder

Markus

Bug#1020937: libgtk-3-0: fix gl on GLES-only platforms

[Dominique Martinet]

Hi,

Dominique Martinet wrote on Thu, Sep 29, 2022 at 08:42:40AM +0900:
> when using GTK on platforms with a GLES-only GL implementation like some
> raspberry pi or iMX platforms with vivante driver, GTK fails to
> initialize its GL stack because it tries to bind to regular GL first
> anyway before using the correct API as configured.
> 
> This can be tested by running gtk3-demo and the OpenGL area demo, which
> will show nothing as no GL implementation could be found -- but it also
> affects real GTK applications like epiphany (gnome web).
> 
> This was reported upstream a couple of years ago:
> https://gitlab.gnome.org/GNOME/gtk/-/issues/3028
> and I submitted a patch yesterday:
> https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5062

This merge request has been merged, so I'd like to move this bug forward:
https://gitlab.gnome.org/GNOME/gtk/-/commit/0e5fe45ea20cce074a128911949dbedf4f8265bf

Is there any opposition to backporting it to debian stable (eventually
on next point update as this isn't a security fix, I'm not sure what the
exact process is here) ?


I'll be happy to do the actual package update work (adding the patch,
verifying it applies etc) but I don't want to step on any toes, so any
input is appreciated :)

Thanks!
-- 
Dominique Martinet

Bug#1023836: Maintainer scripts should use /bin/sh unless Bash features are required

[Jason Franklin]

Package: adduser
Version: 3.129
Severity: minor

Greetings:

One user requested that our maintainer scripts be refactored to use
syntax that is compatible with /bin/sh.

Since only minor changes are needed to satisfy the request, I figured we
could simply go ahead with it.

I will send up a merge request shortly. :)

Best,

-- 
Jason Franklin

Bug#1000955: libkf5globalaccel-bin: /usr/bin/kglobalaccel5 eats up huge amount of CPU after suspend

[Patrick Franz]

Hi Filippo,

I have noticed a similar behaviour. However, the behaviour has improved 
significantly (at least for me) and in recent versions of 
libkf5globalaccel-bin the CPU bursts after connecting e.g. a mouse with 
a USB connector are only relatively short (a couple of seconds maybe 
depending on your machine).

Could you try to run a recent KDE stack with testing or unstable and see 
if the issue is still as bad ?

For some people, the issue was apparently caused by ~/.Xmodmap. Can you 
check whether you have such a file ? Thank you.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1023835: wolfssl: FTBFS because of amd64-only symbols in symbols file

[Felix Lechner]

Hi,

On Thu, Nov 10, 2022 at 4:06 PM Bastian Germann  wrote:
>
> Please keep the three symbols out of the symbols file or make them optional.

Thanks. We are aware of the issue.

Unfortunately, your suggestion will likely cause a build failure on
amd64. How do you make the symbols "optional" please? Thanks!

Kind regards,
Felix Lechner

Bug#1023795: Additional

[James Cameron]

Hello Debian Developers!  Thanks for your work.

I'm the developer responsible for upgrading the instrument software
referenced by https://github.com/sso-aat/libpgplot-perl/wiki

On porting to Giza, here are the regressions I found and my analysis;

1.  plot window not staying on display is because Giza does not
implement the PGPLOT /xs or /xserve device, instead collapsing it into
the same as the /xw or /xwindow device.

https://github.com/danieljprice/giza/blob/a6cefc4c0b1e2060ed40ff6f0a46525365952674/src/giza-drivers.c#L897

2.  content rendering - background; our existing plot scripts showed a
black background, but on using Giza the background changed to white;
not investigated, probably requires effort porting the script from
PGPLOT to Giza,

3.  content rendering - curve colours; this also changed, not
investigated,

4.  content rendering - fonts; the size of text changed, not
investigated,

5.  content rendering - overall dimensions; the width and height of
the plot changed, not investigated.

It was cheaper in developer time to undo #869135 and create a local
derivative package.

In discussions with astronomers, they've told me Giza is not a drop-in
replacement, but rather a poor substitute.  Until this week, I had no
idea.  Hope you can do something about it.  Let me know if you have
any questions.

Bug#1023835: wolfssl: FTBFS because of amd64-only symbols in symbols file

[Bastian Germann]

Source: wolfssl
Version: 5.5.3-1
Severity: serious
Tags: ftbfs

The build fails because of

--- debian/libwolfssl35.symbols (libwolfssl35_5.5.3-2_armhf)
+++ dpkg-gensymbolsjJzBRh   2022-11-10 20:32:48.418173057 +
@@ -48,9 +48,9 @@
  WOLFSSL_ERROR_LINE@Base 5.2.0
  WOLFSSL_ERROR_MSG@Base 5.2.0
  WOLFSSL_EVP_CIPHER_mode@Base 5.2.0
- cpuid_clear_flag@Base 5.5.3
- cpuid_select_flags@Base 5.5.3
- cpuid_set_flag@Base 5.5.3
+#MISSING: 5.5.3-2# cpuid_clear_flag@Base 5.5.3
+#MISSING: 5.5.3-2# cpuid_select_flags@Base 5.5.3
+#MISSING: 5.5.3-2# cpuid_set_flag@Base 5.5.3
  get_digit@Base 5.2.0
  get_digit_count@Base 5.2.0
  get_rand_digit@Base 5.2.0

Please keep the three symbols out of the symbols file or make them optional.

Bug#1023834: shared-mime-info: update-mime-database takes 30-40 minutes to run

[Ross Boylan]

Package: shared-mime-info
Version: 2.0-1
Severity: important
Tags: upstream
X-Debbugs-Cc: rossboy...@stanfordalumni.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Steps to Reproduce
==
1. btrfs on top of encrypted partition on a spinning disk. btrfs subvolumes in
use.
2. sources.list.d includes entry for Visual Studio code (deb [arch=amd64
signed-by=/usr/share/keyrings/microsoft-archive-keyring.gpg]
https://packages.microsoft.com/repos/vscode stable main).
3. aptitude shows an update to code is available.
4. apply update and wait, as much as 45 minutes.  Most of the time update-mime-
database is consuming 50-90% of one CPU.

This happens every time, even for the most minor update.

I often am recording TV shows to the disk at the same time, but this morning I
was not and it took 30 minutes.  Other times it has been 40-45 minutes.

Comments


I have opened a bug against vscode upstream
(https://github.com/microsoft/vscode/issues/163690), and it seems likely their
settings are not optimal.  In particular, their postinst script invokes update-
mime-database without the -n option.  I do not usually experience such long
delays when installing/upgrading other packages.

I believe -n causes update-mime-database to skip scanning entirely if nothing
seems new--the man page is a bit unclear.  So perhaps that one fix would take
care of most of my problems.

However, when update-mime-database does a real run, it seems to me it should be
much faster.  This appears to be a long-standing problem:

https://bugs.freedesktop.org/show_bug.cgi?id=70366 (also
https://bugs.gentoo.org/487504, https://bugs.archlinux.org/task/66687,
https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1816674).

Some of the bugs have been closed, but I think in all cases that was because a
facility to disable fsync() via an environment variable was added and the build
or package installation system was modified to use it.  In contrast, the
performance I'm seeing strongly suggests it remains enabled on Debian.

I spent some time trying to figure out how set the PKGSYSTEM_ENABLE_FSYNC
environment variable so that it would be applied whenever update-mime-database
ran.  The answer is not obvious to me.  The man page mentions no configuration
files, and a quick look at main() in the source doesn't seem to show any being
read in.  main() does check the environment variable.  I also looked for ways
to set the variable in dpkg or apt, but didn't find anything (probably there is
a way).

Desired Solutions
=

In increasing order of difficulty/impact:

1. Document the PKGSYSTEM_ENABLE_FSYNC environment variable in the man page.
2. Describe how the user can disable the fsync during upgrades, bearing in mind
that the invocation of update-mime-database is indirect.
3. Turn fsync off for update-mime-database as a default.

I completely agree with Chantziaras's argument
(https://bugs.freedesktop.org/show_bug.cgi?id=70366#c10) that using fsync on a
database that can easily be rebuilt if things go wrong is unjustified.  And, as
noted above, disabling the fsync has been the common response across the
various forms of packaging and build systems.

Coda


The extremely poor performance I'm seeing is likely the result of failings in
both the code packaging--not an official Debian package--and some weaknesses in
btrfs.  But problems with fsync in update-mime-database are widely reported,
and it would be good if Debian could do something to mitigate them.



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

Kernel: Linux 5.10.0-19-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 shared-mime-info depends on:
ii  libc6 2.31-13+deb11u4
ii  libglib2.0-0  2.66.8-1
ii  libxml2   2.9.10+dfsg-6.7+deb11u3

shared-mime-info recommends no packages.

shared-mime-info suggests no packages.


-BEGIN PGP SIGNATURE-

iQFSBAEBCgA8FiEEreS674/HIyV9gBfdnAYPmOsbK2AFAmNtjPgeHHJvc3Nib3ls
YW5Ac3RhbmZvcmRhbHVtbmkub3JnAAoJEJwGD5jrGytg37cIAJWqFm4HkUfw6AX+
vlAR5gsFIxZ3qeCJFHqTx4GIXWvXNIIHx9SpKTbQmDFw9QbqRp9se/zTVfFshUde
v5hxyQ+1AF8iYH+OkbLKsDGNnyoDW15DzKY35ZTbnzLBNtKQ7E31fBah9icr6Asx
Unj3aXSjxWxqH6alGOVu2Sr7jA5QH5tsUU99uSTYreUGQuXUqk0UnNv4DdCIZzLi
o47U9gDGXLSL2tSWK3TTaFeUv97w/eaGzd0/FnUQGWnvfWcIKCZWyNOsFDkhFhgw
Dk3UPTkgFesAM8fAF2zUW3nMbCuuoaVmtYizJdizO9XPB83L9KN18RHO3Lt6AAmO
64PabuU=
=qsw3
-END PGP SIGNATURE-

Bug#1020560: diffutils: Missing LGPL-2.1+, GPL-2+ in d/copyright

[Bastian Germann]

Am 10.11.22 um 21:38 schrieb Santiago Vila:

For example, your proposed copyright file has this:

Files: *Makefile.in

I guess this means "anything including the 'Makefile.in' string, which includes a file called Makefile.in at any 
directory depth but also something called this-is-not-really-a-Makefile.in-file".


The documentation about this I'm reading:

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

suggests */Makefile.in. Am I right to think that this includes the Makefile.in 
file in the root directory of the package?


Yes, you could have a this-is-not-really-a-Makefile.in that also matches, but 
there is none.
Sure you can match */... to get around that.


Also: What would be the easiest way to put debian/* files in public-domain?

Docs say that when I use "public-domain" string I have to explain exactly "what exemption the corresponding files for 
that paragraph have from default copyright restrictions". What would be an example of this?


If you are the only copyright holder for debian/* you can easily do that. There is not really a standard way to put a 
file in the public domain and there seems to be no such thing in some jurisdictions. A plain English sentence expressing 
that should be enough. A good way to do it in my opinion is to use a public domain statement with some fallback license 
like Unlicense or CC0. CC0 is available in Debian's common-licenses, so you just need to reference that file instead of 
carrying the whole text in your copyright file.


The reason that the standard has this explanation requirement is that many people mistake being freely licensed or "has 
no copyright statement" for "public domain" and will put "public domain" on things that were never released into the 
public domain.

Bug#1023833: FTBFS with OpenJDK 17

[Olek Wojnar]

Source: bazel-bootstrap
Version: 4.2.2+ds-1
Severity: serious
Tags: ftbfs upstream
Forwarded: https://github.com/bazelbuild/bazel/issues/15831

The default use of OpenJDK 17 causes bazel-bootstrap to FTBFS. This is an
upstream issue and upstream's fix[1] should be cherry-picked as soon as
possible.

[1] https://github.com/bazelbuild/bazel/pull/16706

Bug#749603: ITP: libjs-dygraphs -- fast and flexible JavaScript charting library

[Thorsten Glaser]

tags 749603 + pending
thanks

I managed to solve the last remaining problem tonight, to port it and
make it build using node-babel 7, which we have in Debian. I expect to
upload a package soonish, although a lot of testing is needed still…

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


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1018922: kbibtex crashes on startup

[Arnout Boelens]

Hi Adrian,

I rebuilt kbibtex using Qt 5.15.6 in unstable, but this did not resolve the
issue. I was not able to install Qt 5.15.7 from experimental due to
dependency issues.

Thanks,

Arnout

On Thu, Nov 10, 2022 at 7:55 AM Adrian Bunk  wrote:

> On Sat, Sep 03, 2022 at 07:05:46PM -0700, Arnout Boelens wrote:
> > Looks like it might be a QT bug:
> >
> > https://bugs.kde.org/show_bug.cgi?id=433084
>
> Is this fixed in Qt 5.15.6 in unstable or in Qt 5.15.7 in experimental?
>
> Thanks
> Adrian
>

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[brian m. carlson]

On 2022-11-10 at 16:37:53, Tollef Fog Heen wrote:
> ]] Robie Basak 
> 
> > But are you in essence saying that libpam-tmpdir requires that *every
> > maintainer script* that runs things as non-root, or starts processes
> > that do that, unset TMPDIR first?
> 
> I think it's more wide than that: If you change UID, you need to
> sanitise the environment.  Your HOME is likely to be wrong.  PATH might
> very well be pointing at directories which are not appropriate for the
> user you're changing the UID to, etc.

I believe this is the best practice.  For example, sudo typically passes
through only a handful of environment variables, such as TERM, to avoid
things like insecure PATH entries.  For example, if MySQL invoked a
binary in PATH and I had a custom script named the same thing that had
insecure behaviour when invoked as another user, that would be bad.
OpenSSH also sanitizes the environment passed over the connection.

Without getting into a debate about systemd, this is one the pieces of
functionality it provides, since it runs binaries in a clean
environment.  You can probably get most of that in a sysvinit script by
using `env -i` with a handful of environment variables specifically
overridden if necessary.  Then it would be very obvious what
dependencies the binary had on the outside environment.

> > I think the answer to this should probably be established by the
> > libpam-tmpdir maintainer and documented first, for fear of someone else
> > later coming along and saying that the maintainer script incorrectly
> > ignores TMPDIR because we started ignoring it to resolve this bug. So I
> > copied debian-devel@ for comment.
> 
> I'm not sure this is libpam-tmpdir specific, but rather a bit more
> general: what are the expectations that maintainer scripts can have
> about the environment they're running in, and how do we make those
> expectations hold?  This should probably then be documented in policy.

I agree documentation here is helpful.  For reference, this was an
invocation from `sudo aptitude` as part of a normal package upgrade,
which I think is a relatively common situation to be in.

Possibly also an initscript helper which enables developers to do the
right thing automatically, or a flag to start-stop-daemon, or other
tooling would be beneficial to help people easily solve this problem
without thinking too much about it.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA


signature.asc
Description: PGP signature

Bug#1023832: sysstat: CVE-2022-39377: sysstat overflow on 32-bit systems

[Salvatore Bonaccorso]

Source: sysstat
Version: 12.5.6-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 12.5.2-2

Hi,

The following vulnerability was published for sysstat.

CVE-2022-39377[0]:
| sysstat is a set of system performance tools for the Linux operating
| system. On 32 bit systems, in versions 9.1.16 and newer but prior to
| 12.7.1, allocate_structures contains a size_t overflow in sa_common.c.
| The allocate_structures function insufficiently checks bounds before
| arithmetic multiplication, allowing for an overflow in the size
| allocated for the buffer representing system activities. This issue
| may lead to Remote Code Execution (RCE). This issue has been patched
| in version 12.7.1.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-39377
https://www.cve.org/CVERecord?id=CVE-2022-39377
[1] https://github.com/sysstat/sysstat/security/advisories/GHSA-q8r6-g56f-9w7x

Regards,
Salvatore

Bug#1023535: transition: protobuf

[Sebastian Ramacher]

Control: block -1 by 1022248 1018945

On 2022-11-06 09:08:57 +0100, László Böszörményi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi RMs,
> 
> There's a long awaited transition of Protobuf. It clashes with the
> ruby3.1-default transition, but as I know its rebuilds are just
> starting[1].
> On the other hand I'm done with the rebuilds and patched all issues,
> this transition may start immediately at your decision. The only
> downside is that the Sid version of cura-engine is FTBFS and to fix
> it, the libarcus transition (only affecting this package) will need to
> be done.
> 
> Failing packages and fixes in detail.
> Level 2:
> android-platform-frameworks-base has my patch already applied [2] for
> experimental (not Sid!).
> libarcus builds in Sid, but not the version in experimental for which
> I provided a fix [3].
> target-factory changed library symbols [4], maintainer will need to update 
> that.
> 
> Level 3:
> cura-engine fails with the Sid version [5], with the libarcus
> transition done it compiles fine.
> grpc-java for which I provided the fix [6], the maintainer noted he
> will be ready to update the package.
> llvm-toolchain-13 for which I provided the fix [7], other problems
> seem to be fixed with the upload just happened.
> llvm-toolchain-14 for which I also provided the fix [8], its other
> problem [9] might be wrongly closed by cross referenced
> llvm-toolchain-15 package - but Sylvestre Ledru seems to be aware of
> issues anyway.

Let's wait until icu and libbpf are done.

Cheers

> 
> Thanks for considering,
> Laszlo/GCS
> [1] https://bugs.debian.org/1023495#5
> [2] https://bugs.debian.org/1012572
> [3] https://bugs.debian.org/1023497
> [4] https://bugs.debian.org/1023496
> [5] https://bugs.debian.org/1023498
> [6] https://bugs.debian.org/1023500
> [7] https://bugs.debian.org/1023532
> [8] https://bugs.debian.org/1023532
> [9] https://bugs.debian.org/1023444
> 

-- 
Sebastian Ramacher

Bug#994540: transition: imagemagick

[Sebastian Ramacher]

On 2022-09-03 15:59:44 +0200, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> 
> On 2022-07-15 14:03:24 +0200, Johannes Schauer Marin Rodrigues wrote:
> > Hi Sebastian,
> > 
> > Quoting Sebastian Ramacher (2022-07-13 22:52:52)
> > > On 2021-09-29 10:38:07 +0200, jo...@mister-muffin.de wrote:
> > > > > Do all reverse dependencies build fine with the new Imagemagick 
> > > > > version?
> > > > > If not, have bugs been filed?
> > > > 
> > > > I have rebuilt all 399 source packages that have at least one binary 
> > > > produced
> > > > by src:imagemagick in their build dependency installation closure. Of 
> > > > those, 16
> > > > packages FTBFS with the imagemagick version form experimental but 
> > > > succeed with
> > > > the version from unstable. Of those, only one package (src:wand) is in 
> > > > the list
> > > > from https://release.debian.org/transitions/html/auto-imagemagick.html 
> > > > I filed
> > > > this failure as #995290 and will investigate the other 15 instances as 
> > > > well.
> > > > But since those source packages are not part of the transition, they 
> > > > should
> > > > probably not block this bug.
> > > 
> > > This transition completly dropped off my radar, sorry!
> > > 
> > > What's the current status of the preparations? Have the bugs been filed?
> > 
> > we had one build failure in src:wand which I fixed in imagemagick upload of
> > 8:6.9.12.20+dfsg1-1.2 to experimental. See also #995290
> 
> Please go ahead

This upload did not happen. Was the status here?

Cheers
-- 
Sebastian Ramacher

Bug#1023609: smbclient does not work with kerberos ccache of KEYRING: type

[Michael Tokarev]

07.11.2022 18:45, Vincent Danjean пишет:

Package: smbclient
Version: 2:4.16.6+dfsg-5~bpo11+1
Severity: normal

   Hi,

   I'm trying to use smbclient with kerberos login, for example to
get the list of shares with somthing like:

smbclient -N --use-kerberos=required -gL samba-server.example.org

If using the FILE: ccache, it works.
If using a KEYRING: ccache, it does not work.

...

This is #963899 "Build smbclient against MIT krb5", fwiw.

/mjt

Bug#1023550: transition: qcustomplot

[Sebastian Ramacher]

Control: tags -1 moreinfo
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-qcustomplot.html

Hi Filippo

On 2022-11-06 15:29:32 +0100, Filippo Rusconi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: lopi...@debian.org, gl...@debian.org, 
> debian-science-maintain...@lists.alioth.debian.org
> 
> (please explain about the transition: impacted packages, reason, ...
>  for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions)
> 
> Greetings,
> 
> Fundamental reason: Qt5 and Qt6 are in the archive.
> 
> I am requesting a transition from package libqcustomplot2.0 to
> libqcustomplot2.1. Source package is qcustomplot. The change involves a change
> in the library name itself, from libqcustomplot2.0 to both libQCustomPlot2.1 
> and
> libQCustomPlotQt6.so.2.1.0 (see below).
> 
> I have prepared the packaging in the following git repos branch:
> 
> https://salsa.debian.org/science-team/qcustomplot/-/tree/qt5-and-qt6
> 
> Reason is a new upstream version with soname change and also the fact that the
> source package creates two library packages:  one with the lib built against 
> Qt5
> and one with the same lib built against Qt6. My own projects (libpappsomspp,
> minexpert2) will need to depend on the Qt6-based qcustomplot library.
> 
> The new library names are thus:
> 
> - libQCustomPlot.so.2.1.0 (Qt5)
> - libQCustomPlotQt6.so.2.1.0 (Qt6)
> 
> The reverse dependencies:
> 
> % apt-cache rdepends libqcustomplot2.0
> 
> libqcustomplot2.0
> 
> Reverse Depends:
>   libqcustomplot-dev
>   xtpcpp (under my control)
>   minexpert2 (under my control)
>   libqcustomplot2.1-qt6
>   libqcustomplot2.1-qt6
>   libqcustomplot2.1-qt5
>   libqcustomplot2.1
>   libqcustomplot2.1
>   wsjtx
>   wfview
>   traceshark
>   js8call
>   polyphone
>   nageru
>   xtrx-fft
>   libpappsomspp-widget0 (under my control)
> 
> For the libs under my control, the transition is already prepared and these
> projects are going to be linking against the Qt6-built library, contrary to 
> all
> the other packages detailed below.
> 
> For the other libs listed above, I have already checked that they would build 
> if
> some modifications were performed. I have already git branches ready for the
> packages under git VCS. For the others (source deb), I have patches available.
> 
> The modifications are lean: change -lqcustomplot to -lQCustomPlot for many and
> also sometimes use the CMake-based configuration involving first
> find_package(QCustomPlot) and second the QCustomPlot::QCustomPlot formalism 
> for
> the linker.
> 
> That is: almost one- or two-liner patches.

Could you please file bugs for those so that maintainers are aware?

Cheers

> 
> I am eager to help providing patches (ready).
> 
> This is my first transition experience, I'll be happy to comply to any
> requirement that you may have for me.
> 
> Ben file:
> 
> title = "qcustomplot";
> is_affected = .depends ~ "libqcustomplot2.0" | .depends ~ "libqcustomplot2.1";
> is_good = .depends ~ "libqcustomplot2.1";
> is_bad = .depends ~ "libqcustomplot2.0";
> 
> Sincerely,
> Filippo
> 
> -- 
> 
> ⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
> ⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
> ⢿⡄⠘⠷⠚⠋⠀   Debian Developer
> ⠈⠳⣄  http://msxpertsuite.org
>   http://www.debian.org
> 



-- 
Sebastian Ramacher

Bug#1022130: tsdecrypt: NMU fixing reproducible builds bugs

[Vagrant Cascadian]

Control: tags 1022130 pending
Control: tags 829713 pending

I've uploaded an NMU fixing these two bugs to DELAYED/10:

diff -Nru tsdecrypt-10.0/debian/changelog tsdecrypt-10.0/debian/changelog
--- tsdecrypt-10.0/debian/changelog 2014-02-24 06:52:11.0 -0800
+++ tsdecrypt-10.0/debian/changelog 2022-11-10 13:54:44.0 -0800
@@ -1,3 +1,15 @@
+tsdecrypt (10.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Reiner Herrmann ]
+  * strip build date to enable reproducible building (Closes: #829713)
+
+  [ Vagrant Cascadian ]
+  * debian/rules: Pass default CFLAGS. (Closes: #1022130)
+
+ -- Vagrant Cascadian   Thu, 10 Nov 2022 
13:54:44 -0800
+
 tsdecrypt (10.0-2) unstable; urgency=low
 
   [ Peter Michael Green ]
diff -Nru tsdecrypt-10.0/debian/patches/series 
tsdecrypt-10.0/debian/patches/series
--- tsdecrypt-10.0/debian/patches/series2014-02-24 06:48:10.0 
-0800
+++ tsdecrypt-10.0/debian/patches/series2022-11-10 13:54:44.0 
-0800
@@ -1 +1,2 @@
 avoid-inappropriate-compiler-flags
+strip-build-date-to-enable-reproducible-.patch
diff -Nru 
tsdecrypt-10.0/debian/patches/strip-build-date-to-enable-reproducible-.patch 
tsdecrypt-10.0/debian/patches/strip-build-date-to-enable-reproducible-.patch
--- 
tsdecrypt-10.0/debian/patches/strip-build-date-to-enable-reproducible-.patch
1969-12-31 16:00:00.0 -0800
+++ 
tsdecrypt-10.0/debian/patches/strip-build-date-to-enable-reproducible-.patch
2022-11-10 13:54:44.0 -0800
@@ -0,0 +1,35 @@
+From: Reiner Herrmann 
+Date: Tue, 5 Jul 2016 16:30:30 +0200
+X-Dgit-Generated: 10.0-2.1 49e1f21bd0c38dda987a7157ce5a7b0e0cc7e986
+Subject: strip build date to enable reproducible building (Closes: #829713)
+
+
+---
+
+diff --git a/Makefile b/Makefile
+index 4e659f8..b1785ab 100644
+--- a/Makefile
 b/Makefile
+@@ -19,8 +19,7 @@ CFLAGS ?= -O2 -ggdb \
+  -W -Wall -Wextra \
+  -Wshadow -Wformat-security -Wstrict-prototypes
+ 
+-DEFS = -DBUILD_ID=\"$(BUILD_ID)\" \
+- -DVERSION=\"$(VERSION)\" -DGIT_VER=\"$(GIT_VER)\"
++DEFS = -DVERSION=\"$(VERSION)\" -DGIT_VER=\"$(GIT_VER)\"
+ DEFS += -D_FILE_OFFSET_BITS=64
+ 
+ PREFIX ?= /usr/local
+diff --git a/tsdecrypt.c b/tsdecrypt.c
+index cd55f48..178084a 100644
+--- a/tsdecrypt.c
 b/tsdecrypt.c
+@@ -40,7 +40,7 @@
+ #define FIRST_REPORT_SEC 3
+ 
+ #define PROGRAM_NAME "tsdecrypt"
+-static const char *program_id = PROGRAM_NAME " v" VERSION " (" GIT_VER ", 
build " BUILD_ID " " DLIB ")";
++static const char *program_id = PROGRAM_NAME " v" VERSION " (" GIT_VER ", " 
DLIB ")";
+ 
+ int keep_running = 1;
+ static FILE *log_file = NULL;
diff -Nru tsdecrypt-10.0/debian/rules tsdecrypt-10.0/debian/rules
--- tsdecrypt-10.0/debian/rules 2014-02-24 06:48:20.0 -0800
+++ tsdecrypt-10.0/debian/rules 2022-11-10 13:54:44.0 -0800
@@ -10,11 +10,11 @@
 override_dh_auto_build:
 override_dh_auto_install:
# Build with FFdecsa
-   $(MAKE) ffdecsa
+   $(MAKE) CFLAGS="$(shell dpkg-buildflags --get CFLAGS)" ffdecsa
mv tsdecrypt tsdecrypt_ffdecsa
$(MAKE) distclean
# Build against libdvbcsa
-   $(MAKE) dvbcsa
+   $(MAKE) CFLAGS="$(shell dpkg-buildflags --get CFLAGS)" dvbcsa
mv tsdecrypt tsdecrypt_dvbcsa
# Install binaries
mkdir -p $(DESTDIR)$(PREFIX)/bin


signature.asc
Description: PGP signature

Bug#1023831: elinks: zlib support

[Jakub Wilk]

Package: elinks
Version: 0.13.2-1+b4

elinks is built against libbz2 and liblzma, but not against zlib, which 
would be much more useful. In the build log, I see:


checking for zlib support... yes
checking for zlib.h... no


-- System Information:
Architecture: i386

Versions of packages elinks depends on:
ii  libbz2-1.01.0.8-5+b1
ii  libc6 2.36-4
ii  libev41:4.33-1
ii  libexpat1 2.5.0-1
ii  libfsplib00.14-5
ii  libgcrypt20   1.10.1-2
ii  libgnutls30   3.7.8-4
ii  libgpm2   1.20.7-10+b1
ii  libgssapi-krb5-2  1.20-1+b1
ii  libidn12  1.41-1
ii  liblua5.1-0   5.1.5-9
ii  liblzma5  5.2.7-0.1
ii  libperl5.36   5.36.0-4
ii  libtinfo6 6.3+20220423-2
ii  libtre5   0.8.0-6+b1
ii  elinks-data   0.13.2-1

--
Jakub Wilk

Bug#1022573: transition: procps

[Sebastian Ramacher]

Control: tags -1 moreinfo
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-procps.html

Hi Craig

On 2022-10-24 20:04:22 +1100, Craig Small wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> The procps library is now finally changing. Over 20 years ago there was
> a library to assist with the procps binaries but the API wasn't very
> good nor not really intentioned for use outside procps.
> 
> The Bad: This change is a major API change. Basically nothing is like
> what was before as far as the API is concerned. The library is still
> about parsing the /proc filesystem but that's about it.
> All packages will need patching and/or updating.
> 
> The Good: Upstream/me is able to provide patches as we've done these
> fixes already.
> 
> Upstream has an issue tracking the dependent packages at[1]
> 
> The impacted packages are:
>  * apitrace - Untested patches available
>  * cpu-x - Upstream updated to new (interim API) minor fixes to get it
>working
>  * deepin-screen-recorder - Embeds old pointers into functions, needs
>work
>  * intel-gpu-tools - Patches available, upstream working on issue
>  * obs-advanced-scene-switches - Have patches for 4.0.0, minor fix to
>get them to new API
>  * openscap - Have patches for 4.0.0, minor fix for new API
>  * veyon - No patches but a way forward
> 
> I can work with the relevant developers to get the API changed.

Adding the moreinfo tag for now. Please let us know once the bugs for
these issues have been filed.

Cheers

> 
>  - Craig
> 
> 1: https://gitlab.com/procps-ng/procps/-/issues/239
> 
> Ben file:
> 
> title = "procps";
> is_affected = .depends ~ 
> /libproc2\-0|libproc\-dev|libprocps[0-9]|libprocps\-dev/;
> is_good = .depends ~ /libproc2\-0|libproc\-dev/;
> is_bad = .depends ~ /libprocps[0-9]|libprocps\-dev/;
> 

-- 
Sebastian Ramacher

Bug#1018945: transition: libbpf

[Sebastian Ramacher]

On 2022-11-06 11:36:16 +, Sudip Mukherjee wrote:
> On Sat, Nov 5, 2022 at 8:14 PM Sebastian Ramacher  
> wrote:
> >
> > Control: tags -1 confirmed
> >
> > On 2022-11-05 00:11:07 +, Sudip Mukherjee wrote:
> > > Control: tags -1 - moreinfo
> > > --
> > >
> > > On Mon, Oct 24, 2022 at 10:22:32PM +0100, Sudip Mukherjee wrote:
> > > > As of today only v4l-utils and bpfcc still fails to build with libbpf
> > > > in experimental.
> > > >
> > > > v4l-utils is a key package, I will look into its fix and request the
> > > > libbpf transition after that.
> > >
> > > All the packages except bpfcc (#1018818) now builds fine with 
> > > libbpf/1.0.1-1
> > > from experimental. I can help bpfcc maintainers with the porting to new 
> > > libbpf
> > > but they have not replied to the bug report or to my mails.
> > >
> > > Please consider libbpf for transition.
> >
> > Please go ahead
> 
> Thanks. Has been uploaded.

The autopkgtests of dpdk regressed on amd64:
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dpdk/28081847/log.gz
Could you please take a look?

Best
Sebastian
-- 
Sebastian Ramacher

Bug#1023830: widelands: FTBFS on s390x

[Sebastian Ramacher]

Source: widelands
Version: 2:1.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=widelands=s390x=2%3A1.1-1=1668005308=0

Running testcase ./src/base/test/test_string.cc:174
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/tree.cc:244] unrecognized 
format type character 'q'
[00:00:00.000 real] ERROR: String: %q
Running testcase ./src/base/test/test_string.cc:175
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/tree.cc:222] invalid 
format type character 'f' after '%l'
[00:00:00.000 real] ERROR: String: %lf
Running testcase ./src/base/test/test_string.cc:176
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/tree.cc:244] unrecognized 
format type character '|'
[00:00:00.000 real] ERROR: String: %|1$d|
Running testcase ./src/base/test/test_string.cc:177
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/tree.cc:244] unrecognized 
format type character '
[00:00:00.000 real] ERROR: String: %02.7
Running testcase ./src/base/test/test_string.cc:178
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/tree.cc:314] index 1 is 
unused
[00:00:00.000 real] ERROR: String: %2% %3$i
Running testcase ./src/base/test/test_string.cc:179
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/tree.cc:94] duplicate use 
of index 1
[00:00:00.000 real] ERROR: String: %1% %1$d
Running testcase ./src/base/test/test_string.cc:180
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/tree.cc:102] Cannot mix 
positional and unpositional placeholders
[00:00:00.000 real] ERROR: String: %4d %2%
Running testcase ./src/base/test/test_string.cc:181
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/tree.h:134] Too many 
arguments provided (expected only 3)
[00:00:00.000 real] ERROR: String: %u %li %lld
Running testcase ./src/base/test/test_string.cc:182
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/tree.h:269] Too few 
arguments provided: 3 required but only 2 passed
[00:00:00.000 real] ERROR: String: %lu %llu %lli
Running testcase ./src/base/test/test_string.cc:183
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/string_node.h:40] Wrong 
argument type: expected string, found int
[00:00:00.000 real] ERROR: String: %s
Running testcase ./src/base/test/test_string.cc:184
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/number_node.h:64] Wrong 
argument type: expected int, found string
[00:00:00.000 real] ERROR: String: %i
Running testcase ./src/base/test/test_string.cc:185
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/float_node.h:82] Floating 
point value too large: 12345679395506094080.00
[00:00:00.000 real] ERROR: String: %f
Running testcase ./src/base/test/test_string.cc:186
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/number_node.h:51] Unsigned 
integral value too large: 9756277977048271785
[00:00:00.000 real] ERROR: String: %ld
Running testcase ./src/base/test/test_string.cc:187
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/number_node.h:35] '-' and 
'0' can not be combined
[00:00:00.000 real] ERROR: String: %-05d
Running testcase ./src/base/test/test_string.cc:188
[00:00:00.000 real] ERROR: format error: A string contains invalid printf 
placeholders
[00:00:00.000 real] ERROR: Error: [./src/base/format/tree.cc:75] Repeated flag 
'+'
[00:00:00.000 real] ERROR: String: %+0+5d
Running strings::trim_split_replace
Running testcase ./src/base/test/test_string.cc:86
Running testcase ./src/base/test/test_string.cc:88
Running testcase ./src/base/test/test_string.cc:90
Running testcase ./src/base/test/test_string.cc:92
Running testcase ./src/base/test/test_string.cc:96
Running testcase ./src/base/test/test_string.cc:97
Running testcase 

Bug#973823: lvmlockd fails to create sanlock lock space with 1g extents

[corubba]

Hi,

this has been fixed upstream in v2.03.17.


As a workaround you can create the shared VG with an extent size that is
a) less or equals to 256M and b) a divisible of your target extent size.
Then extent the lvmlock LV so it is also a whole number of extents with
your target extent size. And finally change the extent size of the VG.
Obviously all the caveats of changing the extent size of a VG still apply.

root@node1:~# vgcreate --shared --physicalextentsize 256M my-shared-test-vg 
/dev/sdb1
  Enabling sanlock global lock
  Physical volume "/dev/sdb1" successfully created.
  Logical volume "lvmlock" created.
  Volume group "my-shared-test-vg" successfully created
  VG my-shared-test-vg starting sanlock lockspace
  Starting locking.  Waiting until locks are ready...
root@node1:~# vgs -o 
vg_name,vg_shared,vg_size,vg_extent_size,vg_extent_count,vg_free,vg_free_count
  VGShared  VSize Ext #Ext VFree Free
  my-shared-test-vg  shared 4.00g 256.00m   16 3.75g   15

root@node1:~# lvextend --size 1G /dev/mapper/my--shared--test--vg-lvmlock
  Size of logical volume my-shared-test-vg/lvmlock changed from 256.00 MiB (1 
extents) to 1.00 GiB (4 extents).
  Logical volume my-shared-test-vg/lvmlock successfully resized.
root@node1:~# vgchange --physicalextentsize 1G my-shared-test-vg
  Volume group "my-shared-test-vg" successfully changed
root@node1:~# vgs -o 
vg_name,vg_shared,vg_size,vg_extent_size,vg_extent_count,vg_free,vg_free_count
  VGShared  VSize Ext   #Ext VFree Free
  my-shared-test-vg  shared 4.00g 1.00g4 3.00g3
root@node1:~# lvs -a
  LVVGAttr   LSize Pool Origin Data%  Meta%  Move 
Log Cpy%Sync Convert
  [lvmlock] my-shared-test-vg -wi-ao 1.00g

This can still be a bit finicky because you have to get the size of the
PV right, so the initial extent count is a multiple of the final extent
count. In the above example /dev/sdb1 is 4200MiB, which is 16 and 4
extents respectively. It does not work with 4300MiB, because that would
be 17 and 4; vgchange will show the error "New extent size is not a
perfect fit".


---
Greetings

Corubba

Bug#831031: boolector: please make the build reproducible

[Vagrant Cascadian]

Uploaded an NMU fixing this issue, with an additional change to build
with the C.UTF-8 locale (otherwise the embedded timestamp varied in some
locales).

diff -Nru boolector-1.5.118.6b56be4.121013/debian/changelog 
boolector-1.5.118.6b56be4.121013/debian/changelog
--- boolector-1.5.118.6b56be4.121013/debian/changelog   2021-12-27 
11:53:28.0 -0800
+++ boolector-1.5.118.6b56be4.121013/debian/changelog   2022-11-10 
13:35:53.0 -0800
@@ -1,3 +1,16 @@
+boolector (1.5.118.6b56be4.121013-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Chris Lamb ]
+  * Do not embed kernel version and hostname. Use SOURCE_DATE_EPOCH for
+timestamp.  (Closes: #8311031)
+
+  [ Vagrant Cascadian ]
+  * debian/rules: Use C.UTF-8 locale for building to ensure reproducible 
builds.
+
+ -- Vagrant Cascadian   Thu, 10 Nov 2022 
13:35:53 -0800
+
 boolector (1.5.118.6b56be4.121013-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru 
boolector-1.5.118.6b56be4.121013/debian/patches/do-not-embed-kernel-version-and-hostname.patch
 
boolector-1.5.118.6b56be4.121013/debian/patches/do-not-embed-kernel-version-and-hostname.patch
--- 
boolector-1.5.118.6b56be4.121013/debian/patches/do-not-embed-kernel-version-and-hostname.patch
  1969-12-31 16:00:00.0 -0800
+++ 
boolector-1.5.118.6b56be4.121013/debian/patches/do-not-embed-kernel-version-and-hostname.patch
  2022-11-10 13:35:53.0 -0800
@@ -0,0 +1,39 @@
+From: Chris Lamb 
+Date: Wed, 13 Jul 2016 21:26:55 +0200
+X-Dgit-Generated: 1.5.118.6b56be4.121013-1.2 
ec9d419225ed99c456b0972362c0ee13281fac57
+Subject: Do not embed kernel version and hostname. Use SOURCE_DATE_EPOCH for
+
+timestamp.  (Closes: #8311031)
+
+---
+
+diff --git a/lingeling/mkconfig b/lingeling/mkconfig
+index 0e356f3..5f99590 100755
+--- a/lingeling/mkconfig
 b/lingeling/mkconfig
+@@ -13,8 +13,8 @@ cat<

signature.asc
Description: PGP signature

Bug#831585: tcpreen: please make the build reproducible

[Vagrant Cascadian]

I have uploaded an NMU fixing this issue:

diff -Nru tcpreen-1.4.4/debian/changelog tcpreen-1.4.4/debian/changelog
--- tcpreen-1.4.4/debian/changelog  2012-01-11 10:06:17.0 -0800
+++ tcpreen-1.4.4/debian/changelog  2022-11-10 13:00:17.0 -0800
@@ -1,3 +1,13 @@
+tcpreen (1.4.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Chris Lamb ]
+  * reproducible builds: Use lsb_release short description instead of
+hostname (Closes: #831585)
+
+ -- Vagrant Cascadian   Thu, 10 Nov 2022 13:00:17 -0800
+
 tcpreen (1.4.4-2) unstable; urgency=low
 
   * Enable hardened build flags. Closes: #655250.
diff -Nru tcpreen-1.4.4/debian/control tcpreen-1.4.4/debian/control
--- tcpreen-1.4.4/debian/control2012-01-11 18:22:36.0 -0800
+++ tcpreen-1.4.4/debian/control2022-11-10 13:00:17.0 -0800
@@ -6,7 +6,9 @@
 Build-Depends: 
  debhelper (>= 9), 
  gettext, 
- autotools-dev
+ autotools-dev,
+ lsb-release,
+ dh-autoreconf
 Standards-Version: 3.9.2
 Homepage: http://www.remlab.net/tcpreen/
 
diff -Nru tcpreen-1.4.4/debian/patches/reproducible_build.patch 
tcpreen-1.4.4/debian/patches/reproducible_build.patch
--- tcpreen-1.4.4/debian/patches/reproducible_build.patch   1969-12-31 
16:00:00.0 -0800
+++ tcpreen-1.4.4/debian/patches/reproducible_build.patch   2022-11-10 
13:00:17.0 -0800
@@ -0,0 +1,14 @@
+Author: Chris Lamb 
+Last-Update: 2016-07-17
+
+--- tcpreen-1.4.4.orig/m4/hostname.m4
 tcpreen-1.4.4/m4/hostname.m4
+@@ -5,7 +5,7 @@ dnl From Remi Denis-Courmont
+ AC_DEFUN([RDC_BUILD_HOSTNAME],
+ [AC_CACHE_CHECK([for build hostname],
+ rdc_cv_build_hostname,
+-[rdc_cv_build_hostname=`hostname -f 2>/dev/null || uname -n 2>/dev/null || 
hostname 2>/dev/null || echo "unknown"`
++[rdc_cv_build_hostname=`lsb_release --short --description`
+ ])
+ AC_DEFINE_UNQUOTED(PACKAGE_BUILD_HOSTNAME, "$rdc_cv_build_hostname",
+   [Define to the hostname of the host who builds the package.])
diff -Nru tcpreen-1.4.4/debian/patches/series 
tcpreen-1.4.4/debian/patches/series
--- tcpreen-1.4.4/debian/patches/series 1969-12-31 16:00:00.0 -0800
+++ tcpreen-1.4.4/debian/patches/series 2022-11-10 13:00:17.0 -0800
@@ -0,0 +1 @@
+reproducible_build.patch
diff -Nru tcpreen-1.4.4/debian/rules tcpreen-1.4.4/debian/rules
--- tcpreen-1.4.4/debian/rules  2010-08-27 06:49:10.0 -0700
+++ tcpreen-1.4.4/debian/rules  2022-11-10 13:00:17.0 -0800
@@ -1,3 +1,3 @@
 #!/usr/bin/make -f
 %:
-   dh $@
+   dh $@ --with autoreconf


signature.asc
Description: PGP signature

Bug#1023829: liferea: "WebKitWebProces" consumes up to 20% CPU while Liferea is minimized in the task bar

[Paul Gevers]

Control: tag -1 unreproducible

Hi Christian,

Thanks for reporting issues you encounter.

On 10-11-2022 21:43, Christian Henz wrote:

I frequently notice that a WebKitWebProces spawned by Liferea is consuming CPU
(up to 20%) even when the Liferea UI is closed (only task bar icon visible).
This seems to happen after Liferea has been running for a couple of hours.


This is a bit limited information to go on. For what it's worth, I don't 
reproduce this (albeit on bookworm). I've never noticed high CPU 
consumption this way, but I'll keep an eye out.


It would be good if you could figure out under which conditions this 
happens (and under which conditions it doesn't). E.g. what feed are you 
having open, do you view videos in the internal browser, etc. Do your 
feeds have JavaScript and do you have that enabled?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023829: liferea: "WebKitWebProces" consumes up to 20% CPU while Liferea is minimized in the task bar

[Christian Henz]

Package: liferea
Version: 1.13.5-3
Severity: normal

Dear Maintainer,

I frequently notice that a WebKitWebProces spawned by Liferea is consuming CPU
(up to 20%) even when the Liferea UI is closed (only task bar icon visible).
This seems to happen after Liferea has been running for a couple of hours.

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

Kernel: Linux 5.10.0-19-rt-amd64 (SMP w/2 CPU threads; PREEMPT)
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 liferea depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.24-0+deb11u1
ii  dbus-x11 [dbus-session-bus]   1.12.24-0+deb11u1
ii  dconf-gsettings-backend [gsettings-backend]   0.38.0-2
ii  gir1.2-freedesktop1.66.1-1+b1
ii  gir1.2-gtk-3.03.24.24-4+deb11u2
ii  gir1.2-peas-1.0   1.28.0-2+b1
ii  libc6 2.31-13+deb11u5
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1+deb11u1
ii  libgirepository-1.0-1 1.66.1-1+b1
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4+deb11u2
ii  libjson-glib-1.0-01.6.2-1
ii  libpango-1.0-01.46.2-3
ii  libpeas-1.0-0 1.28.0-2+b1
ii  libsoup2.4-1  2.72.0-2
ii  libsqlite3-0  3.34.1-3
ii  libwebkit2gtk-4.0-37  2.38.2-1~deb11u1
ii  libxml2   2.9.10+dfsg-6.7+deb11u3
ii  libxslt1.11.1.34-4+deb11u1
ii  liferea-data  1.13.5-3
ii  python3   3.9.2-3
ii  python3-cairo 1.16.2-4+b2
ii  python3-gi3.38.0-2
ii  python3-notify2   0.3-4
ii  python3.9 3.9.2-1

Versions of packages liferea recommends:
ii  gir1.2-gstreamer-1.0  1.18.4-2.1
ii  gir1.2-notify-0.7 0.7.9-3

Versions of packages liferea suggests:
pn  kget 
ii  network-manager  1.30.6-1+deb11u1

Bug#1020560: diffutils: Missing LGPL-2.1+, GPL-2+ in d/copyright

[Santiago Vila]

El 23/9/22 a las 11:34, Bastian Germann escribió:

Source: diffutils
Severity: important
Version: 1:3.8-1

Hi,

diffutils has an incomplete copyright file. At least LGPL-2.1+ and 
GPL-2+ licenses are missing even though they are applicable to some 
files. While they can be distributed as GPL-3+, it is not the correct 
license for those files to record in d/copyright.


I have attached a d/copyright file in the machine-readable format for v3.8.


Thanks for the report and the revised file.

I have a lot of copyright files to convert in other packages, so there 
are a few things I still don't understand in full. Hope you don't mind 
if I ask you about them.


For example, your proposed copyright file has this:

Files: *Makefile.in

I guess this means "anything including the 'Makefile.in' string, which 
includes a file called Makefile.in at any directory depth but also 
something called this-is-not-really-a-Makefile.in-file".


The documentation about this I'm reading:

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

suggests */Makefile.in. Am I right to think that this includes the 
Makefile.in file in the root directory of the package?


Also: What would be the easiest way to put debian/* files in public-domain?

Docs say that when I use "public-domain" string I have to explain 
exactly "what exemption the corresponding files for that paragraph have 
from default copyright restrictions". What would be an example of this?


Thanks.

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Damyan Ivanov]

-=| Job Bautista, 01.08.2020 08:13:08 + |=-
> Just in case someone wonders if this is being worked on, MZ uploaded a 
> 0.9.12-1 package at mentors.debian.net[1]. He's just waiting for a sponsor to 
> upload it to the main archive. If you want, you can dget the dsc file and 
> build the package yourself.
> 
> Regards,
> 
> Job Bautista
> 
> [1]: https://mentors.debian.net/package/endless-sky/

Two years later, this is no longer available and endless-sky is at 
version 0.9.16.1.

I have taken the liberty to upgrade the package (locally) from 
0.9.8-1.2 to 0.9.16.1 and started a salsa project to track the 
changes. The result is at . 
It is not 100% ready yet, but looks quite nice. At this point I wonder 
how to proceed.

Michael, would you like a co-maintainer for the Debian package? 
Perhaps even a group-maintenance under the Debian Games Team (cc-ed)? 
Either should help timely upgrades in Debian.

Thanks for the great additions to the storyline :)


-- Damyan


signature.asc
Description: PGP signature

Bug#835672: xfce4-power-manager: If installed without xfce4-session, fails to lock screen due to missing xflock4 script

[Philip Hands]

Akbarkhon Variskhanov  writes:

...
> If you check your ~/.xsession-errors there should be a warning about
> setting a LockCommand. The simplest fix is to actually set it via
> `xfconf`:

I switched from Xmonad/X to Sway/Wayland in the last couple of months,
so I'm not able to confirm this, I'm afraid.

There's therefore no need to keep the bug open for my benefit, but
perhaps you want to leave it open to give others the hint if they
stumble across the same behaviour.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#1023734: linux-image-6.0.0-2-amd64: No network connection, no pulseaudio server connection

[Salvatore Bonaccorso]

Hi Guy, 

[Thanks to Diederik for taking time as well to contribute!]

On Thu, Nov 10, 2022 at 06:22:48PM +0100, Guy Durrieu wrote:
> Hi Salvatore,
> 
> I did the test using the kernel image you built for me. After reactivating
> rasdaemon (and rebooting), all apparently work fine.

Good news, thanks for your testing! So it's the same as #1023726.

> I have a last question: Do I keep this version, and what will happen when
> the next kernel update occurs ? And what about the 6.0.0.2 one ?

As it is an unofficial build, please do revert back to an official
one. I plan to upload 6.0.8-1 based on the today's released 6.0.8
"soonish" which will contain the fix as well.

Hope this helps so far,

Regards,
Salvatore

Bug#998950: mailsync: diff for NMU version 5.2.7-3.1

[Tomas Pospisek]

On Thu, 3 Nov 2022, Marcos Talau wrote:


Control: tags 998950 + patch
Control: tags 998950 + pending


Dear maintainer,

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


Many, many thanks Marcos!
*t

Bug#726459: MIT instead of Heimdal in Debian

[Andrew Bartlett]

On Thu, 2022-11-10 at 17:04 +0300, Michael Tokarev wrote:
> On Sat, 7 Apr 2018 11:37:18 +0200 Mathieu Parent  
> wrote:
> > Hi,
> > 
> > Most of this was done in Samba 4.8, but we still build with Heimdal in 
> > Debian.
> > 
> > There are two reasons:
> > - missing features [1]
> 
> The missing features needs to be evaluated really, - how relevant these 
> actually
> are these days.  For example, "Computer GPO's are not applied" listed in that
> wiki pages seems to work fine.

This is good to hear.  That one scared me, not because breakage was
unexpected, but because we couldn't tell why or how.

We now have a much, much better testsuite that covers things pretty
well, and know what tests the MIT KDC still fails.  

> > - fear to break things (especially on upgrade)
> 
> Things are easy to break indeed.  But from the same wiki page it
> *seems* a switch is
> actually easy - the only thing needed is to create
> /var/lib/samba/private/kdc.conf
> file.  I dunno how much this is true.

I don't really expect much breakage honestly, given the testsuite. 

That testsuite is why we were happy to upgrade the Heimdal version,
which was just as much of a change and risk.

> > I hope that the feature gap will decrease in 4.9 and later, but we
> > probably won't migrate before buster+1 (i.e next-next stable)

There is no particular effort to address the lack of RODC support for
the MIT KDC, and efforts to close the gaps shown by the testsuite are
sporadic.  

It is also much harder to develop for the MIT KDC, as there isn't a
standard vendored copy we can apply patches to and then filter to
upstream (which is the process for Heimdal).

> How about buster+4? :))
> 
> Anyway, I implemented a build profile, pkg.samba.mitkrb5, to build whole samba
> (with the experimental ad-dc support) with mit-krb5.  Dunno how it will go..
> 
> Thanks,
> 
> /mjt
> 
> > [1]: Samba DCs with MIT Kerberos KDC currently do not support:
> > - PKINIT support required for using smart cards
> > - Service for User to Self-service (S4U2self)
> > - Service for User to Proxy (S4U2proxy)

These are fixed.

> > - Running as a Read only domain controller (RODC)
> > (https://wiki.samba.org/index.php/Running_a_Samba_AD_DC_with_MIT_Ke
> > rberos_KDC)

This is the big one.  Plus just other differences that may or may not
matter as much.

Andrew Bartlett

-- 
Andrew Bartlett (he/him)https://samba.org/~abartlet/
Samba Team Member (since 2001)  https://samba.org
Samba Developer, Catalyst IThttps://catalyst.net.nz/services/samba

Bug#963899: Build smbclient against MIT krb5

[Andrew Bartlett]

On Thu, 2022-11-10 at 16:44 +0300, Michael Tokarev wrote:
> 
> But samba-libs needs to be split further, into something like 
> samba-common-libs,
> samba-client-libs, and so on. This way, we may have some of them independent 
> on
> the kerberos implementation used - say, samba-common-libs, whicih can be used
> by both heimdal-using samba server packages and mitkrb5-using smbclient.

The Samba Team will never support an install of Samba that is built up
of parts built with different options. 

> Or alternatively, another set of samba-libs - ie, another package of 
> samba-libs,
> say, samba-libs-mitkrb5 - needs to be created.  This quickly becomes rather
> ugly and unmanageable.
> 
> I think the only more or less realistic way to go is to split samba-libs into
> subcomponents.  Actually, samba-common-bin and samba packages also needs to
> be split further into multiple pieces.  For example, that needs to be
> samba-ad-dc, samba-ad-dc-provision (for /usr/share/samba/setup/*), maybe
> samba-krb5-printing, maybe python3-samba-ad-dc (from python3-samba) and
> so on.  This is not a huge work really, but it needs to be done in order
> to allow to mix and match things.

I can only strongly advise against mix and match.

> Besides, I implemented pkg.samba.mitkrb5 build profile for samba package,
> maybe this one will help somehow. But it builds everything with mit-krb5,
> including the experimental ad-dc code.

This is the only approach, a separate build profile.  If there is the
motivation, the user could be allowed to install one suite or the other
I guess.

Andrew Bartlett

-- 
Andrew Bartlett (he/him)https://samba.org/~abartlet/
Samba Team Member (since 2001)  https://samba.org
Samba Developer, Catalyst IThttps://catalyst.net.nz/services/samba

Bug#1023828: fontconfig: Manual fontconfig reconfigure to avoid helvetica bitmap font.

[Raúl Sánchez Siles]

Package: fontconfig
Version: 2.13.1-4.2
Severity: normal

Dear Maintainer,

TLDR: I needed to manually run dpkg-reconfigure to properly be able to print a 
github page 
from firefox

I run into trouble when I tried printing from firefox a github page. After some 
investigation I 
discovered that font-family was resolved to helvetica and that helvetica was a 
bitmap font in 
my bullseye system (upgraded from buster long time ago).

Before the dpkg-reconfigure, fc-match resolved like this:

```
$ fc-match -s helvetica
helvR12-ISO8859-1.pcf.gz: "Helvetica" "Regular"
helvR12.pcf.gz: "Helvetica" "Regular"
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
n019003l.pfb: "Nimbus Sans L" "Regular"
texgyreheros-regular.otf: "TeX Gyre Heros" "Regular"
LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
...
```

After this I manually run `sudo dpkg-reconfigure fontconfig fontconfig-config` 
and I 
remember one of the options was related to bitmap fonts. These are the debconf 
values 
now:

Name: fontconfig/enable_bitmaps
Template: fontconfig/enable_bitmaps
Value: false
Owners: fontconfig-config
Flags: seen

Name: fontconfig/hinting_style
Template: fontconfig/hinting_style
Value: hintslight
Owners: fontconfig-config
Flags: seen

Name: fontconfig/hinting_type
Template: fontconfig/hinting_type
Value: Native
Owners: fontconfig-config
Flags: seen

Name: fontconfig/subpixel_rendering
Template: fontconfig/subpixel_rendering
Value: Automatic
Owners: fontconfig-config
Flags: seen

After this, fc-match resolves like this:
```
$ fc-match -s helvetica 
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
n019003l.pfb: "Nimbus Sans L" "Regular"
texgyreheros-regular.otf: "TeX Gyre Heros" "Regular"
LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
...
```

Now firefox resolves its font-family `font-family: 
-apple-system,BlinkMacSystemFont,"Segoe 
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";` to 
sans-serif and printing 
to PDF is nice and readable.

I had to learn some things to get to this conclusion and I hope this bug report 
can make life 
easier for anyone facing a similar problem. I wonder if it is possible to 
include some kind of fix 
in fontconfig packages in order to avoid the problem.

After taking a look at current reported bugs I found that the following may be 
related:
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783609[1] 
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776801[2] 

Unfortunately I found these after having solved the problem so I cannot point 
to them 
directly. If you agree I can merge all these.

Note: On my other laptop running sid, I have not found this problem.

Regards,

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

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

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

fontconfig recommends no packages.

fontconfig suggests no packages.

-- no debconf information


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

Bug#1023811: golang-github-grpc-ecosystem-go-grpc-middleware_1.3.0-1 sources changed in the archive?

[Cyril Brulebois]

Adrian Bunk  (2022-11-10):
> Package: ftp.debian.org
> Severity: grave
> X-Debbugs-Cc: debian-wb-t...@lists.debian.org, Thomas Goirand 
> 

Yeah, the dsc seems to have changed, deb.debian.org returns the old version
(due to corporate-grade caching or whatever), while my local mirror (standard
apache2 serving files synced by ftpsync via syncproxy2.eu.debian.org and
debian.ethz.ch) shows the new version (which matches the Sources file and
downloads fine accordingly).

> Get:1 https://deb.debian.org/debian experimental/main 
> golang-github-grpc-ecosystem-go-grpc-middleware 1.3.0-1 (dsc) [2857 B]
> Err:1 https://deb.debian.org/debian experimental/main 
> golang-github-grpc-ecosystem-go-grpc-middleware 1.3.0-1 (dsc)
>   Hash Sum mismatch
>   Hashes of expected file:
>- SHA256:8e86e0a9cc31461c0f564e8feefb2e1e9ec05c265ab06e96fd32b7de787bc504
>- Filesize:2857 [weak]
>- MD5Sum:c4d33ab09e4f4a95c819dd1de88d0876 [weak]
>   Hashes of received file:
>- SHA256:8bbee530bbdb11a58a275c34878c372558223c294384897822eba1338b84db82
>- MD5Sum:8d6eee1b2b773c9be12536396ba949a6 [weak]
>- Filesize:2857 [weak]
>   Last modification reported: Wed, 26 Oct 2022 14:32:16 +

An extra check can be done by querying snapshot.debian.org, and `debsnap
golang-github-grpc-ecosystem-go-grpc-middleware 1.3.0-1` downloads
the old version as well.

An extra hint is obtained by clicking the 1.3.0-1 link on

and getting an error page, I suppose because of a different lookup
implementation.

Adding `-v` to the debsnap line above, I'm getting this URL:
  
https://snapshot.debian.org/mr/package/golang-github-grpc-ecosystem-go-grpc-middleware/1.3.0-1/srcfiles?fileinfo=1

which indeed has two `fileinfo` entries for the .dsc:

"0feb631739624059c1db234338e87a57d33f4d5f": [
  {
"archive_name": "debian",
"first_seen": "20221027T213940Z",
"name": "golang-github-grpc-ecosystem-go-grpc-middleware_1.3.0-1.dsc",
"path": "/pool/main/g/golang-github-grpc-ecosystem-go-grpc-middleware",
"size": 2857
  }
],
"48d5553979d3de93b05587668ce30305d3ad9141": [
  {
"archive_name": "debian",
"first_seen": "20221103T151306Z",
"name": "golang-github-grpc-ecosystem-go-grpc-middleware_1.3.0-1.dsc",
"path": "/pool/main/g/golang-github-grpc-ecosystem-go-grpc-middleware",
"size": 2857
  }
],

Maybe that'll help pinpoint what happened and/or when.


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


signature.asc
Description: PGP signature

Bug#1023811: golang-github-grpc-ecosystem-go-grpc-middleware_1.3.0-1 sources changed in the archive?

[Adam D. Barratt]

On Thu, 2022-11-10 at 15:53 +0200, Adrian Bunk wrote:
> 
Get:1 https://deb.debian.org/debian experimental/main golang-github-
> grpc-ecosystem-go-grpc-middleware 1.3.0-1 (dsc) [2857 B]
> Err:1 https://deb.debian.org/debian experimental/main golang-github-
> grpc-ecosystem-go-grpc-middleware 1.3.0-1 (dsc)
>   Hash Sum mismatch
>   Hashes of expected file:
>-
> SHA256:8e86e0a9cc31461c0f564e8feefb2e1e9ec05c265ab06e96fd32b7de787bc5
> 04
>- Filesize:2857 [weak]
>- MD5Sum:c4d33ab09e4f4a95c819dd1de88d0876 [weak]
>   Hashes of received file:
>-
> SHA256:8bbee530bbdb11a58a275c34878c372558223c294384897822eba1338b84db
> 82
>- MD5Sum:8d6eee1b2b773c9be12536396ba949a6 [weak]
>- Filesize:2857 [weak]
>   Last modification reported: Wed, 26 Oct 2022 14:32:16 +
> Get:2 https://deb.debian.org/debian experimental/main golang-github-
> grpc-ecosystem-go-grpc-middleware 1.3.0-1 (tar) [104 kB]
> Get:3 https://deb.debian.org/debian experimental/main golang-github-
> grpc-ecosystem-go-grpc-middleware 1.3.0-1 (diff) [2652 B]
> E: Failed to fetch 
> https://deb.debian.org/debian/pool/main/g/golang-github-grpc-ecosystem-go-grpc-middleware/golang-github-grpc-ecosystem-go-grpc-middleware_1.3.0-1.dsc
>   Hash Sum mismatch
>Hashes of expected file:
> -
> SHA256:8e86e0a9cc31461c0f564e8feefb2e1e9ec05c265ab06e96fd32b7de787bc5
> 04
> - Filesize:2857 [weak]
>Fetched 109 kB in 0s (416 kB/s)
>  - MD5Sum:c4d33ab09e4f4a95c819dd1de88d0876 [weak]
>Hashes of received file:
> -
> SHA256:8bbee530bbdb11a58a275c34878c372558223c294384897822eba1338b84db
> 82
> - MD5Sum:8d6eee1b2b773c9be12536396ba949a6 [weak]
> - Filesize:2857 [weak]
>Last modification reported: Wed, 26 Oct 2022 14:32:16 +
> E: Failed to fetch some archives.
> E: apt-get for sources failed
> ...
> 
> 
> I can reproduce the problem locally with
> $ apt-get source golang-github-grpc-ecosystem-go-grpc-
> middleware/experimental
> 
> This is not supposed to happen, and I haven't seen this before.

So far as I can tell, the timeline is:

- 2022-10-26 package is uploaded
- 2022-10-31 package is removed as obsolete
- 2022-11-03 the same package is re-uploaded, with a different GPG
signature

The file in the archive matches the "expected" hashes, whereas deb.d.o
is returning the original file.

Regards,

Adam

Bug#1023827: unifont: Include upper planes into the package

[Michael Krylov]

Package: xfonts-unifont
Version: 1:13.0.06-1
Severity: wishlist
File: unifont

Dear Maintainer,

I would like to suggest you to add Unifont's upper plane which is
now available https://unifoundry.com/unifont/index.html here into the
unifont packages. Or maybe make it a separate package, it doesn't matter
much.


-- System Information:
Debian Release: 11.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-18-686 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xfonts-unifont depends on:
ii  xfonts-utils  1:7.7+6

xfonts-unifont recommends no packages.

Versions of packages xfonts-unifont suggests:
pn  ttf-unifont  

-- no debconf information

Bug#1008953: libarchive: CVE-2022-26280

[Christian Göttsche]

Kindly ping.

Upstream released a new version (3.6.1) with the fix included 7 month ago.

Bug#1023734: linux-image-6.0.0-2-amd64: No network connection, no pulseaudio server connection

[Guy Durrieu]

Hi Salvatore,

I did the test using the kernel image you built for me. After 
reactivating rasdaemon (and rebooting), all apparently work fine.


I have a last question: Do I keep this version, and what will happen 
when the next kernel update occurs ? And what about the 6.0.0.2 one ?


Thanks for your help !

Best regards.

-- Guy.

Le 09/11/2022 à 19:21, Salvatore Bonaccorso a écrit :

Hi Guy,

On Wed, Nov 09, 2022 at 06:05:58PM +0100, Guy Durrieu wrote:

Hi Salvatore,

OK, I will try that as soon as possible. Am I supposed to re-enable the
rasdeamon once the patch applied ? Anyway I will report you the result (f I
don't make any mistake).

Yes right, the idea would be to boot the new kernel with rasdeamon
enabled again and see if the system is stable again.

Be aware though that rasdaemon itself might segfault, there is a
second issue, where rasdaemon needs fixing as well, see #1023725.

Regards,
Salvatore

Bug#1023443: u-boot: Add colibri_imx6 configuration

[Vagrant Cascadian]

On 2022-11-10, Manuel Traut wrote:
> I tested it with my hardware:
...
> Commercial temperature grade DDR3 timings, 32bit bus width.
> Trying to boot from MMC1
>
>
> U-Boot 2022.04+dfsg-2 (Apr 10 2022 - 23:28:14 +)
...
> Can you pick the patch for sid?

That's not the verison in sid, though. If you can test it on 2022.10
(currently in sid) and 2023.01-rc1 (currently in git), that would be
great!

Generally ask people to test new versions periodically:

  https://wiki.debian.org/U-boot/Status

Preferrably at least each new upstream version as it's uploaded to
debian sid and/or experimental.

> Shall I also test with the new version found in experimental?

Haven't yet uploaded to experiemental, but in git I've updated to
2023.01-rc1 recently, maybe will upload that shortly.

I might upload 2023.01-rc1 before another unstable upload, in either
case, I'll try to include your patch, thanks!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016505: patch: Fix `Incorrect netdev->dev_addr` errors in linux-5.17+ patch

[Diego Escalante Urrelo]

Package: broadcom-sta-dkms
Version: 6.30.223.271-22
Followup-For: Bug #1016505
X-Debbugs-Cc: die...@gnome.org

Bump.

I have pushed this and other fixes as a branch in salsa:
  https://salsa.debian.org/diegoe/broadcom-sta/-/commits/2022-various-fixes

At least the patch in this bug report is important, the other stuff is
mostly lintian warnings and nitpicks.

Thanks!

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

Kernel: Linux 6.0.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, 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 broadcom-sta-dkms depends on:
ii  dkms  3.0.6-4

Versions of packages broadcom-sta-dkms recommends:
ii  wireless-tools  30~pre9-13.1

broadcom-sta-dkms suggests no packages.

-- no debconf information

Bug#1023622: [EXT] Re: Bug#1023622: glusterfs-server: glusterfs-cli is only Recommends instead of Requires

[Alexander Ruddick]

On Thu, Nov 10, 2022 at 2:30 AM Patrick Matthäi 
wrote:

>
> Am 07.11.2022 um 19:38 schrieb Alex Ruddick:
> > Package: glusterfs-server
> > Version: 10.1-1
> > Severity: normal
> > X-Debbugs-Cc: a.rudd...@numat-tech.com
> >
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991383
> > In 9.3.2 the 'gluster' binary was moved out to a new 'gluster-cli'
> package.
> > Part of the rationale given was to match Fedora.
> >
> https://fedora.pkgs.org/37/fedora-updates-testing-aarch64/glusterfs-server-10.3-1.fc37.aarch64.rpm.html
> > However, the new package is only Recommended in Debian/Ubuntu, but
> Required in Fedora.
> In default setups recommends are installed like dependencies (I also
> deactivate this always).
> > This means that the server package is basically broken (in a patch
> release, no less!)
> > since the 'gluster' binary is critical to actually setting up or running
> a server.
> > Refer to e.g. the upstream Quick Start Guide which references 'gluster'
> left and right.
> > https://docs.gluster.org/en/main/Quick-Start-Guide/Quickstart/
> >
> So why is it broken? If you also require the cli package you can simply
> install it.
>
> --
> /*
> Mit freundlichem Gruß / With kind regards,
>   Patrick Matthäi
>   GNU/Linux Debian Developer
>
>Blog: https://www.linux-dev.org/
> E-Mail: pmatth...@debian.org
>  patr...@linux-dev.org
> */
>

Patrick,
vielen Dank für Ihre Arbeit!

I had a usable glusterFS install, and then upgraded and no longer had a
usable glusterFS install.  I don't know what to call that other than
"broken."  The CLI is required - without it one cannot setup, change, or
monitor the daemon.  Would it make sense to package systemD without
/usr/bin/systemctl?

Upstream ships the CLI with the server (combined package).
The PPA ships the CLI with the server (combined package).
Fedora ships the CLI with the server (Install-Requires)
Arch ships the CLI with the server (combined package).
CentOS ships the CLI with the server. (Install-Requires)
Gentoo ships the CLI with the server (combined)

As far as I can tell only Debian ships a split package without Requiring
the CLI.

MfG,
Alex Ruddick

Bug#1023826: libnvme: Fails to build on big endian systems (e.g. s390x)

[Benjamin Drung]

Package: libnvme
Version: 1.2-1
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
X-Debbugs-Cc: bdr...@debian.org

Dear Maintainer,

libnvme fails to build on big endian systems (e.g. s390x). I forwarded
the bug upstream and they fixed. Please apply the fix (see attachement).

Thanks for considering the patch.

-- 
Benjamin Drung
Debian & Ubuntu Developer
diff -Nru libnvme-1.2/debian/patches/mi-endian-fixes.patch 
libnvme-1.2/debian/patches/mi-endian-fixes.patch
--- libnvme-1.2/debian/patches/mi-endian-fixes.patch1970-01-01 
01:00:00.0 +0100
+++ libnvme-1.2/debian/patches/mi-endian-fixes.patch2022-11-10 
16:24:08.0 +0100
@@ -0,0 +1,61 @@
+From ac657355bc86b71e1d2d8dd6079d5d69332dedaa Mon Sep 17 00:00:00 2001
+From: Jeremy Kerr 
+Date: Thu, 10 Nov 2022 12:20:37 +0800
+Subject: [PATCH] mi: endian fixes
+
+We have a couple of endian issues in the mi code: one where we're not
+converting cdw0 for MI commands, and one where we're using the wrong
+byte length for an existing conversion. There is also an error in the
+test suite, where we should be converting the nsze field of a
+nvme_id_ns.
+
+This change fixes those, so that the test suite passes on a BE platform
+(ppc64 in my case).
+
+Fixes: https://github.com/linux-nvme/libnvme/issues/524
+Signed-off-by: Jeremy Kerr 
+Bug-Ubuntu: https://launchpad.net/bugs/1995935
+Origin: https://github.com/linux-nvme/libnvme/pull/529
+---
+ src/nvme/mi.c | 4 ++--
+ test/mi.c | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/nvme/mi.c b/src/nvme/mi.c
+index cd86e41..1a34208 100644
+--- a/src/nvme/mi.c
 b/src/nvme/mi.c
+@@ -139,7 +139,7 @@ int nvme_mi_scan_ep(nvme_mi_ep_t ep, bool force_rescan)
+   struct nvme_mi_ctrl *ctrl;
+   __u16 id;
+ 
+-  id = le32_to_cpu(list.identifier[i]);
++  id = le16_to_cpu(list.identifier[i]);
+   if (!id)
+   continue;
+ 
+@@ -985,7 +985,7 @@ static int nvme_mi_read_data(nvme_mi_ep_t ep, __u32 cdw0,
+   req_hdr.hdr.nmp = (NVME_MI_ROR_REQ << 7) |
+   (NVME_MI_MT_MI << 3); /* we always use command slot 0 */
+   req_hdr.opcode = nvme_mi_mi_opcode_mi_data_read;
+-  req_hdr.cdw0 = cdw0;
++  req_hdr.cdw0 = cpu_to_le32(cdw0);
+ 
+   memset(, 0, sizeof(req));
+   req.hdr = _hdr.hdr;
+diff --git a/test/mi.c b/test/mi.c
+index 102cea9..4c7f1f2 100644
+--- a/test/mi.c
 b/test/mi.c
+@@ -1287,7 +1287,7 @@ static void test_admin_ns_mgmt_create(struct nvme_mi_ep 
*ep)
+   assert(!rc);
+   assert(ns == 0x01020304);
+ 
+-  nsid.nsze = 42;
++  nsid.nsze = cpu_to_le64(42);
+   rc = nvme_mi_admin_ns_mgmt_create(ctrl, , 0, );
+   assert(rc);
+ }
+-- 
+2.37.2
+
diff -Nru libnvme-1.2/debian/patches/series libnvme-1.2/debian/patches/series
--- libnvme-1.2/debian/patches/series   1970-01-01 01:00:00.0 +0100
+++ libnvme-1.2/debian/patches/series   2022-11-10 16:20:16.0 +0100
@@ -0,0 +1 @@
+mi-endian-fixes.patch

Bug#1019291: yarnpkg: depends on incompatible version of commander

[Adrien Samson]

Dear maintainer,

I experience a similar issue with yarn and the commander version: command 
options are ignored.
For example: `yarn add -D typescript` saves the dependency to dependencies 
instead of devDependencies. The -D is simply ignored.

I've found that you have a patch for commander >= 8 where you replace most 
occurrences of commander by commanderOpts. It's missing the same replacement on 
line 306:

--- a/src/cli/index.js
+++ b/src/cli/index.js
@@ -303,7 +303,7 @@ export async function main({
   reporter.warn(reporter.lang('dashDashDeprecation'));
 }
 
-return command.run(config, reporter, commander, 
commander.args).then(exitCode => {
+return command.run(config, reporter, commanderOpts, 
commander.args).then(exitCode => {
   if (shouldWrapOutput) {
 reporter.footer(false);
   }

This fixes my issue but I can't tell whether it also fixes the original 
reporter's issue.

Best regards
Adrien

Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]

[Tollef Fog Heen]

]] Robie Basak 

> But are you in essence saying that libpam-tmpdir requires that *every
> maintainer script* that runs things as non-root, or starts processes
> that do that, unset TMPDIR first?

I think it's more wide than that: If you change UID, you need to
sanitise the environment.  Your HOME is likely to be wrong.  PATH might
very well be pointing at directories which are not appropriate for the
user you're changing the UID to, etc.

> I think the answer to this should probably be established by the
> libpam-tmpdir maintainer and documented first, for fear of someone else
> later coming along and saying that the maintainer script incorrectly
> ignores TMPDIR because we started ignoring it to resolve this bug. So I
> copied debian-devel@ for comment.

I'm not sure this is libpam-tmpdir specific, but rather a bit more
general: what are the expectations that maintainer scripts can have
about the environment they're running in, and how do we make those
expectations hold?  This should probably then be documented in policy.

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1023825: btrbk: don't put example config in /etc

[Christoph Anton Mitterer]

Package: btrbk
Version: 0.32.5-1
Severity: wishlist


Hey.

Typically, most package seem to put example configuration
like /etc/btrbk/btrbk.conf.example rather into
/usr/share/doc//examples

Cheers,
Chris.

Bug#1023824: crmsh: WARNING: crmadmin -S unexpected output

[Guillem Jover]

Package: crmsh
Version: 4.4.0-2
Severity: important
Tags: upstream patch
Forwarded: https://github.com/ClusterLabs/crmsh/issues/970

Hi!

The output from pacemaker changed from what crmsh expects, which makes
certain commands now fail (in addition to causing WARNING and INFO output).

This is affecting us on our HA setup.

The (merged) upstream commit fixing this is
,
which I'm attaching here for your convenience.

Thanks,
Guillem
From f83aa41185dbc71a25a3def39d42356e503b1f96 Mon Sep 17 00:00:00 2001
From: liangxin1300 
Date: Wed, 11 May 2022 11:09:28 +0800
Subject: [PATCH] Fix: utils: wait4dc: Make change since output of 'crmadmin
 -S' changed(bsc#1199412)

---
 crmsh/utils.py | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/crmsh/utils.py b/crmsh/utils.py
index 9f2603a1..9ebce28f 100644
--- a/crmsh/utils.py
+++ b/crmsh/utils.py
@@ -895,15 +895,10 @@ def wait4dc(what="", show_progress=True):
 return False
 cmd = "crmadmin -S %s" % dc
 rc, s = get_stdout(add_sudo(cmd))
-if not s.startswith("Status"):
-logger.warning("%s unexpected output: %s (exit code: %d)", cmd, s, rc)
-return False
-try:
-dc_status = s.split()[-2]
-except:
-logger.warning("%s unexpected output: %s", cmd, s)
+if rc != 0:
+logger.error("Exit code of command {} is {}".format(cmd, rc))
 return False
-if dc_status == "S_IDLE":
+if re.search("S_IDLE.*ok", s):
 if output_started:
 sys.stderr.write(" done\n")
 return True
-- 
2.38.1

Bug#1018922: kbibtex crashes on startup

[Adrian Bunk]

On Sat, Sep 03, 2022 at 07:05:46PM -0700, Arnout Boelens wrote:
> Looks like it might be a QT bug:
> 
> https://bugs.kde.org/show_bug.cgi?id=433084

Is this fixed in Qt 5.15.6 in unstable or in Qt 5.15.7 in experimental?

Thanks
Adrian

Bug#1023595: Mention End Of Life in package Description

[Santiago Ruano Rincón]

Control: tags -1 pending

El 07/11/22 a las 03:56, Dan Jacobson escribió:
> Package: isc-dhcp-client
> Version: 4.4.3-P1-1
> 
> In the package Description mention something about End Of Life.
> Yes, it's mentioned in /usr/share/doc/isc-dhcp-client,
> but it should also be mentioned in the package Description section,
> so e.g.,
> 
> $ apt show isc-dhcp-client
> ...
> Priority: important
> ...
> Description: 
> 
> will warn potential users that all is not sunny.
> 

Done in https://salsa.debian.org/debian/isc-dhcp/-/merge_requests/5

This will be part of the next release.

Thanks,

 -- S


signature.asc
Description: PGP signature

Bug#1023823: primer3: broken d/t/run-unit-tests handling of big-endian archs

[Lukas Märdian]

Package: primer3
Version: 2.6.1-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com

Dear Maintainer,

The primer3 package contains code in debian/tests/run-unit-test whose
purpose is to monkeypatch the testsuite on big-endian architectures to
disable certain tests.

Instead, it mangles the files under test/ completely on big-endian archs,
causing the autopkgtest testsuite to fail to be run.

Attached is a patch that fixes the sed commands being used to mangle the
testsuite, which would let the package run autopkgtests on s390x again.

Related to: https://bugs.debian.org/1014626


Thanks for considering the patch.

Cheers, Lukas


-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-50-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru primer3-2.6.1/debian/tests/run-unit-test 
primer3-2.6.1/debian/tests/run-unit-test
--- primer3-2.6.1/debian/tests/run-unit-test2022-07-09 10:50:59.0 
+0200
+++ primer3-2.6.1/debian/tests/run-unit-test2022-07-09 07:20:30.0 
+0200
@@ -30,9 +30,8 @@
   cp -a test/Makefile test/Makefile~
   # exclude tests known to fail on big endian
   # See README.source for further explanation.
-  for tst in $P3CORE_FAILED_TESTS ; do sed -i "/$tst/d" test/p3test.pl ; done
-  sed -i "0,/$FAILED_TESTS/s///" test/Makefile
-  sed -i "/$FAILED_TESTS/,/endif/d" test/Makefile
+  for tst in $P3CORE_FAILED_TESTS ; do sed -i "/${tst}.,/d" test/p3test.pl ; 
done
+  for tst in $FAILED_TESTS; do sed -i "/^test:/s/$tst//" test/Makefile; done
 fi
 
 cd test/;

Bug#1023822: orphan-sysvinit-scripts: firewalld sysvinit script is missing from firewalld package, can it be added?

[Craig]

Package: orphan-sysvinit-scripts
Version: orphan-sysvinit-scripts_0.07_all , orphan-sysvinit-scripts_0.11_all
Severity: important
X-Debbugs-Cc: nc...@hotmail.com

Dear Maintainer,

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

   * What led up to the situation?
I installed firewalld with "apt install firewalld" and it did not start with
"service firewalld start".  It reported as not found.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I did a web search yesterday and I found a working version of a firewalld
sysvinit start script inside an ubuntu package for version 20.04 LTS.  The link
is here ( https://ubuntu.pkgs.org/20.04/ubuntu-universe-
arm64/firewalld_0.8.2-1_all.deb.html ) and a copy and paste of the script is
below:

### Begin quote #

#! /bin/sh
### BEGIN INIT INFO
# Provides:  firewalld
# Required-Start:$remote_fs dbus
# Required-Stop: $remote_fs dbus
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: dynamic firewall daemon
# Description:   firewalld is a dynamically managed firewall daemon
#with support for network/firewall zones to define
#the trust level of network connections or interfaces.
#It provides a D-Bus interface for services or
#applications to add and apply firewall rules on-the-fly.
### END INIT INFO

#
# Author: Michael Biebl 
#

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="dynamic firewall daemon"
NAME=firewalld

DAEMON=/usr/sbin/firewalld
PIDFILE=/var/run/firewalld.pid

SCRIPTNAME=/etc/init.d/$NAME

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Define LSB log_* functions.
. /lib/lsb/init-functions

do_start()
{
# Return
#   0 if daemon has been started
#   1 if daemon was already running
#   other if daemon could not be started or a failure occured
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON
}

do_stop()
{
# Return
#   0 if daemon has been stopped
#   1 if daemon was already stopped
#   other if daemon could not be stopped or a failure occurred
start-stop-daemon --stop --quiet --retry 5 --pidfile $PIDFILE --name
$NAME
}

do_reload()
{
start-stop-daemon --stop --signal HUP --quiet --pidfile $PIDFILE --name
$NAME
}

case "$1" in
  start)
log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_progress_msg "already started"
   log_end_msg 0 ;;
*) log_end_msg 1 ;;
esac
;;
  stop)
log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0) log_end_msg 0 ;;
1) log_progress_msg "already stopped"
   log_end_msg 0 ;;
*) log_end_msg 1 ;;
esac
;;
  reload|force-reload)
log_daemon_msg "Reloading $DESC" "$NAME"
do_reload
log_end_msg $?
;;
  restart)
$0 stop
$0 start
;;
  status)
status_of_proc -p $PIDFILE $DAEMON $NAME && exit 0 || exit $?
;;
  *)
echo "Usage: $SCRIPTNAME {start|stop|restart|force-
reload|reload|status}" >&2
exit 3
;;
esac

:

### /End quote #


   * What was the outcome of this action?
I placed this script into the correct location at  /etc/init.d/firewalld , made
it executable, updated the rc.d defaults, and started using it with:

service firewalld status/start/stop/restart/reload

   * What outcome did you expect?
It has worked fine.  I made no changes at all to this script.  It just worked.

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

Can this script be included in the "orphan-sysvinit-scripts" package?  It seems
to be orphaned now... (-;


-- System Information:
Debian Release: bookworm/sid
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

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

orphan-sysvinit-scripts recommends no packages.

orphan-sysvinit-scripts suggests no packages.

Bug#1023821: Compile with -DZFP_BIT_STREAM_WORD_SIZE=8 ?

[Enrico Zini]

Source: zfp
Version: 1.0.0-2
Severity: normal

Hello, and thanks for packaging zfp!

I've been trying to build hdf5-zfp[1] in Debian, and it requires[2] zfp
to be built with BIT_STREAM_WORD_SIZE=8. Indeed, while CMakeLists.txt
defaults it to 64, the FAQ recommends setting it to 8 to have portable
files[3].

I did verify that after adding -DZFP_BIT_STREAM_WORD_SIZE=8 to
dh_auto_configure in zfp's debian/rules and rebuilding the package,
tests for hdf5-zfp pass.

Would it make sense to change the default to 8?


Enrico

[1] https://github.com/LLNL/H5Z-ZFP
[2] https://github.com/LLNL/H5Z-ZFP/blob/master/src/H5Zzfp.c#L155
[3] https://github.com/LLNL/zfp/blob/develop/docs/source/faq.rst?plain=1#L391

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

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

Bug#1023820: python3-h5py: Dependencies not tight enough

[Matthias Urlichs]

Package: python3-h5py
Version: 3.7.0-2
Severity: normal

Needs to depend on libhdf5 >= 1.10.7.

>>> import h5py
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/h5py/__init__.py", line 21, in 
from . import _debian_h5py_serial as _h5py
  File "/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/__init__.py", 
line 33, in 
from . import version
  File "/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/version.py", 
line 15, in 
from . import h5 as _h5
  File "h5py/_debian_h5py_serial/h5.pyx", line 1, in init 
h5py._debian_h5py_serial.h5
ImportError: /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.103: version 
`HDF5_SERIAL_1.10.7' not found (required by 
/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/defs.cpython-310-x86_64-linux-gnu.so)
>>> 



-- System Information:
Debian Release: 11.5
  APT prefers stable
  APT policy: (750, 'stable'), (700, 'oldstable'), (600, 'unstable'), (550, 
'oldoldstable'), (550, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-10-amd64 (SMP w/24 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 python3-h5py depends on:
ii  python3-h5py-serial  3.7.0-2

python3-h5py recommends no packages.

Versions of packages python3-h5py suggests:
pn  python-h5py-doc  

-- no debconf information

Bug#1023819: ITP: django-iconify -- Iconify API implementation and tools for Django projects

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: django-iconify
  Version : 0.3
  Upstream Author : Dominik George 
* URL : https://edugit.org/AlekSIS/libs/django-iconify
* License : Apache-2.0
  Programming Lang: Python
  Description : Iconify API implementation and tools for Django projects

  Iconify is a unified icons framework, providing access to 40,000+ icons
  from different icon sets.
  .
  This re-usable app helps integrating Iconify into Django projects.
  .
  Iconify replaces classical icon fonts, claiming that such fonts would
  get too large for some icon sets out there. Instead, it provides an API
  to add icons in SVG format from its collections.
 
I plan to maintain this package as part of the Python team.

This is a dependancy of AlekSIS [1]

   1: https://edugit.org/AlekSIS/official/AlekSIS-Core

Bug#1023790: (no subject)

[Daniel Swarbrick]

The email template was split out of default.tmpl by upstream commit 
https://github.com/prometheus/alertmanager/commit/c0a7b75c9cfb0772bdf5ec7362775f5f7798a3a0, 
into email.tmpl.


The Debian package does not install email.tmpl, and even if that file is 
copied manually into the /usr/share/prometheus/alertmanager, it does not 
resolve the issue. Concatenating the contents of email.tmpl to 
default.tmpl restores the former functionality, and can be considered a 
workaround for now.


I guess the behaviour of 02-Do_not_embed_blobs.patch is going to need to 
be refactored to handle multiple templates, or alternatively the package 
build process will need to concatenate the email.tmpl into default.tmpl.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023443: Acknowledgement (u-boot: Add colibri_imx6 configuration)

[Manuel Traut]

I was able to build a package with the attached patch that shall apply
to the package in sid.

I tested it with my hardware:

--8<--

Commercial temperature grade DDR3 timings, 32bit bus width.
Trying to boot from MMC1


U-Boot 2022.04+dfsg-2 (Apr 10 2022 - 23:28:14 +)

CPU:   Freescale i.MX6SOLO rev1.4 996 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 47C
Reset cause: POR
DRAM:  256 MiB
PMIC:  device id: 0x10, revision id: 0x21, programmed
Core:  65 devices, 15 uclasses, devicetree: separate
MMC:   FSL_SDHC: 1, FSL_SDHC: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

auto-detected panel vga-rgb
Display: vga-rgb (640x480)
In:serial
Out:   serial
Err:   serial
Model: Toradex Colibri iMX6 Solo 256MB V1.1A, Serial# 10673915
Net:   eth0: ethernet@2188000
Hit any key to stop autoboot:  0

--8<--

Can you pick the patch for sid?

Shall I also test with the new version found in experimental?

Regards,
Manuel
>From beca702860ef7b9ce60b5c314efff44dce9dcc24 Mon Sep 17 00:00:00 2001
From: Manuel Traut 
Date: Fri, 4 Nov 2022 09:16:35 +0100
Subject: [PATCH] u-boot-imx: Add colibri_imx6

(Closes: #1023443)

Signed-off-by: Manuel Traut 
---
 debian/targets.mk | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/targets.mk b/debian/targets.mk
index 235d745277..6e9de55f52 100644
--- a/debian/targets.mk
+++ b/debian/targets.mk
@@ -295,6 +295,10 @@ else ifeq (${DEB_HOST_ARCH},armhf)
 
 # u-boot-imx
 
+  # Manuel Traut 
+  u-boot-imx_platforms += colibri_imx6
+  colibri_imx6_targets := SPL u-boot.img uboot.elf
+
   # Marek Vasut 
   u-boot-imx_platforms += dh_imx6
   dh_imx6_targets := u-boot-with-spl.imx uboot.elf
-- 
2.35.1

Bug#1003974: Screenshot of missing icons in Impress

[Tomas Pospisek]

see previous email in this bugreport for context

Bug#1023790: (no subject)

[Daniel Swarbrick]

I am able to reproduce the reported error with 0.24.0-4.

A vanilla upstream build does not exhibit the error. It appears to be 
caused by 02-Do_not_embed_blobs.patch, as omitting that also results in 
a working build.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003974: libreoffice-impress: Some icons do not get displayed in Impress

[Tomas Pospisek]

Hello Nicolas and Libre Office maintainers,

(Not sure what's going on, I'm submitting this bug report for the third 
time since for unknown reason it doesn't make it into the BTS)


My Libre Office Impress is not displaying some icons - see attached
screenshot that I will send in the next email.

I think this *might* be the same problem as Nicolas reported.

I also have XFCE as a desktop, like Nicolas does.

I have the libreoffice-gtk3 (1:7.4.1-1~bpo11+2) integration library
installed.

My libreoffice package is from bullseye-backports running on a
bullseye system.

I did not have the problems with the icons with the package from
the bullseye distro (that is with the 1:7.0.4-4+deb11u4 packages).

Thank you for the libreoffice packages dear maintainers!
*t

-- Package-specific info:

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

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

Versions of packages libreoffice-impress depends on:
ii  libbox2d2.3.02.3.1+ds-7
ii  libc62.31-13+deb11u4
ii  libepoxy01.5.5-1
ii  libetonyek-0.1-1 0.1.9-4
ii  libgcc-s110.2.1-6
ii  libodfgen-0.1-1  0.1.8-2
ii  libreoffice-common   1:7.4.1-1~bpo11+2
ii  libreoffice-core 1:7.4.1-1~bpo11+2
ii  libreoffice-draw 1:7.4.1-1~bpo11+2
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstaroffice-0.0-0  0.0.7-1
ii  libstdc++6   10.2.1-6
ii  libuno-cppu3 1:7.0.4-4+deb11u4
ii  libuno-cppuhelpergcc3-3  1:7.4.1-1~bpo11+2
ii  libuno-sal3  1:7.4.1-1~bpo11+2
ii  libuno-salhelpergcc3-3   1:7.0.4-4+deb11u4
ii  ucf  3.0043
ii  uno-libs-private 1:7.4.1-1~bpo11+2

libreoffice-impress recommends no packages.

Versions of packages libreoffice-impress suggests:
ii  bluez  5.55-3.1

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-4.2
ii  fonts-opensymbol2:102.12+LibO7.4.1-1~bpo11+2
ii  libabsl20200923 0~20200923.3-2
ii  libboost-filesystem1.74.0   1.74.0-9
ii  libboost-iostreams1.74.01.74.0-9
ii  libboost-locale1.74.0   1.74.0-9
ii  libc6   2.31-13+deb11u4
ii  libcairo2   1.16.0-5
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
ii  libcups22.3.3op2-3+deb11u2
ii  libcurl3-gnutls 7.74.0-1.3+deb11u3
ii  libdbus-1-3 1.12.24-0+deb11u1
ii  libdconf1   0.38.0-2
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.5-1
ii  libexpat1   2.2.10-2+deb11u5
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1+deb11u1
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.8-1
ii  libgpgmepp6 1.14.0-1+b2
ii  libgraphite2-3  1.3.14-1
ii  libgstreamer-plugins-base1.0-0  1.18.4-dmo1
ii  libgstreamer1.0-0   1.18.4-2.1
ii  libharfbuzz-icu02.7.4-1
ii  libharfbuzz0b   2.7.4-1
ii  libhunspell-1.7-0   1.7.0-3
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.10-1
ii  libicu6767.1-7
ii  libjpeg62-turbo 1:2.0.6-4
ii  liblcms2-2  2.12~rc1-2
ii  libldap-2.4-2   2.4.57+dfsg-3+deb11u1
ii  libmythes-1.2-0 2:1.2.4-3+b1
ii  libnspr42:4.29-1
ii  libnss3 2:3.61-1+deb11u2
ii  libopenjp2-72.4.0-3
ii  libpng16-16 1.6.37-3
ii  libpoppler102   20.09.0-3.1+deb11u1
ii  libraptor2-02.0.14-1.2
ii  librdf0 1.0.17-1.1+b1
ii  libreoffice-common  1:7.4.1-1~bpo11+2
ii  librevenge-0.0-00.0.4-6+b1
ii  libsm6  2:1.2.3-1
ii  libstdc++6  10.2.1-6
ii  libtiff54.2.0-1+deb11u1
ii  libuno-cppu31:7.0.4-4+deb11u4
ii  libuno-cppuhelpergcc3-3 1:7.4.1-1~bpo11+2
ii  libuno-sal3 1:7.4.1-1~bpo11+2
ii  libuno-salhelpergcc3-3  1:7.0.4-4+deb11u4
ii  libwebp60.6.1-2.1
ii  libx11-62:1.7.2-1
ii  libx11-xcb1 2:1.7.2-1
ii  libxext62:1.3.3-1.1
ii  libxinerama12:1.1.4-2
ii  libxml2 

Bug#1018102: idle detection failure

[Antoine Beaupré]

On 2022-09-14 21:41:52, Antoine Beaupré wrote:
> That seems to say that this command is supposed to trigger a lock:
>
> loginctl lock-session
>
> and it does *not* work here. Does it work for you?

So, interestingly, this issue has mostly gone away from my workstations
now, after a general cleanup of old packages.

In particular, the above command *does* work now, which makes me believe
that this is a systemd/logind issue, where some service (which?! who
knows!) might be inhibiting lock. How to tell *what* that is is beyond
me right now, but it's a heck of a tell, i think...

-- 
Quis custodiet ipsos custodes?
Who watches the watchmen?
Qui police la police?
Tu. You. Toi.

Bug#726459: MIT instead of Heimdal in Debian

[Michael Tokarev]

On Sat, 7 Apr 2018 11:37:18 +0200 Mathieu Parent  wrote:

Hi,

Most of this was done in Samba 4.8, but we still build with Heimdal in Debian.

There are two reasons:
- missing features [1]


The missing features needs to be evaluated really, - how relevant these actually
are these days.  For example, "Computer GPO's are not applied" listed in that
wiki pages seems to work fine.


- fear to break things (especially on upgrade)


Things are easy to break indeed.  But from the same wiki page it *seems* a 
switch is
actually easy - the only thing needed is to create 
/var/lib/samba/private/kdc.conf
file.  I dunno how much this is true.


I hope that the feature gap will decrease in 4.9 and later, but we
probably won't migrate before buster+1 (i.e next-next stable)


How about buster+4? :))

Anyway, I implemented a build profile, pkg.samba.mitkrb5, to build whole samba
(with the experimental ad-dc support) with mit-krb5.  Dunno how it will go..

Thanks,

/mjt


[1]: Samba DCs with MIT Kerberos KDC currently do not support:
- PKINIT support required for using smart cards
- Service for User to Self-service (S4U2self)
- Service for User to Proxy (S4U2proxy)
- Running as a Read only domain controller (RODC)
(https://wiki.samba.org/index.php/Running_a_Samba_AD_DC_with_MIT_Kerberos_KDC)

Bug#1023818: vim: buffer overflow in block_insert

[Helmut Grohne]

Package: vim
Version: 2:8.1.0875-5
Severity: serious
Tags: security upstream fixed-upstream
X-Debbugs-Cc: Debian Security Team 
Control: fixed -1 vim/2:8.2.3455-1
Control: close -1

Hi,

while looking into vim source, I stumbled into
https://github.com/vim/vim/commit/4067bd3604215b48e4b4201e28f9e401b08418e4

Among other things, this change adds "if (spaces < 0) spaces = 0" to
block_insert. While this has been fixed in bookworm and later, it is
missing from bullseye and earlier. If spaces happens to be < 0, bad
things happen when we later vim_memset(..., ' ', (size_t)spaces).

A prospective stable update should probably fix this.

Helmut

Bug#1023817: rust-num-cpus: Please update to 1.14.0

[Jonas Smedegaard]

Source: rust-num-cpus
Version: 1.13.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to 1.14.0, needed by projects I am preparing for Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNtBS0ACgkQLHwxRsGg
ASFxfRAAqZ/BIVkK9ztHZmguhefqOxKsPuE52n2H4xsti5o8g0ZM0pqo598FjNAX
zdHNKLr5al6r8ZbpA/rRfciIcq2TPgmMXH7N8+VKXbxEcv4rCm1sz2JhPPOw74vR
NkiIHk5UcQgU+A49R8ZUN5kKm8bNxByMfD9c263JXvNb5OioNEsF8HnRiAbnX8RL
6nfqZe6zyQL4NVkXx5LhaKbKHbnHUjffG/A883NVYr46wfK6AvBnjin5IbM4E82z
RqHBUR8ABeu1ieikFtM/WEcyN92T8uupFm0NBsgeYN8xY7hMjVEIeZ9HLPBX/4Mg
TmjAn7Ra8vW0yAJa0sUdAYCRNA/rHf1qieK1vsOFkRLtG7+Ez6aiUnfMPfyklfI0
KpTE/uHhwXw/f3CoJXZD2JyHYfUm0TxDoaGwIqcn7BbiIcQdvKW8ATQVH1fhU/NK
DvaNw7sBRUDclHBev/VpyeLTOIlFSregEwJAyjzUZa/uMYS6HpeYC8kisZZrg1ez
Rf6XTIalFGdLxSuO3msEOaobk7kt5YY5MmbhDOHtaoVrQ6LCiNgFU0cgjmBYpsu1
yCKW53UtX8AVdy1088nN+FEP4VfJcvjX3rwt3BD96GLTPV8liE1fzfEItG6CnTF8
D9ab6bmwr4U4bK82QKtB+MgQDR3gVtImTEWx2aCWPhaaRJTRgPQ=
=7Wte
-END PGP SIGNATURE-

Bug#1023816: usrmerge: doesn't want to work if /usr is a separate btrfs volume

[Matthias Urlichs]

Package: usrmerge
Version: 33
Severity: important
X-Debbugs-Cc: sm...@smurf.noris.de

> Preparing to unpack .../archives/usrmerge_33_all.deb ...
> /usr is a standalone filesystem, this requires using an initramfs.

No it is not. It's a separate BTRFS subvolume, but one that is already
located at /usr. It doesn't need to be mounted or anything. Thus there's no
requirement for any sort of initramfs.

I assume that the test checks whether linking from root to /usr works.
This should be replaced by directly checking whether /usr is a
mountpoint.

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

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

Versions of packages usrmerge depends on:
ii  libfile-find-rule-perl  0.34-2
ii  perl5.36.0-4

usrmerge recommends no packages.

usrmerge suggests no packages.

-- debconf-show failed

Bug#1023815: rust-httparse: Please update to v1.8.0

[Jonas Smedegaard]

Source: rust-httparse
Version: 1.7.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to v1.8.0, needed by projects I am preparing for Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNtBKAACgkQLHwxRsGg
ASGJeQ//Zjb9jLplk59l5aBJwaVGo8cY6NZVOln3nXuHnBDjEh3zHpygXKCiNJ3r
Nid5XrojgPZEpT7tLHMaMwHYp8rWbt8hiI1cig+VxNutUP3ff+zJ7r0N54kJiOWA
V7yKftBUqW0QWzw4RPo9CRS9A/GwgHtCcdf3QirkpxhgoCV3yP8eBaNv/RkmwXts
6sxiGutTaXOlzWnqumJQzPaqDzPdcv1FAZj7EzmdWqsR/qOlXOKe4n9ihLx6/K8S
f77PSH5yqILHzAm51YZX5+rvkkl58JJHIo20QbWnqgfz1H9fYuvieNmhSgaUUgwn
amPrxHtiehc2QYs4zaumphv1846ReYm32p/fpr41SRxs0p+hi+eeNDa+iiyyOG0w
EWYFIcKr3RzDSPm7RT+UqIW0lqS2QUk5JlxzuZ5G3MRauYfk+ayYL7MTqpaVPUKW
YtXmCiKl6TqydObeM52cogQM5qJn5CNo1QYPpA6u272a/P90wHJzCAFyFz74so12
8RgEorLjvMNC0RbhNitSXOhJPeuAO8Rj4owloOYav9zkyiBXW8nwpoeKel8pxLxW
y2XbuwIKIKY2kQ+eQwh8DAIYRTPZ3azWdsoSAu7m1u4HRt+R8kl2zO2mKeCkg7v7
J6ukz/WcEu+Dw4uYjOsRRGkOmf40BbI4L1sgag6obYjc08HXDDo=
=QEY+
-END PGP SIGNATURE-

Bug#1023814: rust-regex: Please update to 1.7.0

[Jonas Smedegaard]

Source: rust-regex
Version: 1.6.0-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to v1.7.0, needed by projects I am preparing for Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNtBEEACgkQLHwxRsGg
ASEwkA//RNAlu7YHPz2oF/t/sHILcBG/zUC8GstT0XQcBTbPGDtxZ5IGw+xThAgt
4OmDOBk/3Vm7QuIF6LFl+y8qvyiOZOxzVxZ8QM4LvaeFRxUF1MZHHDXjWcygA6hb
1xXe/JQLTMVZKyzrpnXjW1Uee19alvWpEmHEmGQQNLZXPcmdzpvN4UbMDwS7/XVo
N/lPqw7Sar6s0JRFC6env452JbONBX0mY0jj8bJfNXGF3f6O06EXYyc5/nionacI
7bT/Pw+/SbSJ/Dvfinm+yJRkZX2/posZ/lVyDzz6Q4/rTCMnyKR0ur5qMO13JBOf
yKFtLEp/f7XPxMmQ3pFWsPfN5PFXcZ6Xbeoa88Rtr+i0Yg7MV2CUcJM/sO/o0Dqx
5szVs0sl+KuV6pI/YM+rVHEuV4NUWOjEdl2wfI8zD/1MLzQwOgzrVladiljb6zXT
BdZj1D6b2TZ8AkxV3kgyR0ky4OP/vG3mzuR+asVwZmAjdNDarWl0ncXcsZO/y5us
W/k4oUSs1bJ/c1LT5ld/JJrCgRTOMb560YmmsaRwqfW2E1OUc3nFhQncsUaEWafv
1uEZ4t1RXXaTQ9A+d3BB6Vwimr1Uvl6QUyH6I0OBXmfa/Zqirk7d7McdpyPhCGxM
SxXCq3bxpbDIzrWHiM3O2N85pu8y230Xg7NN4HAo6LtcnIPfTOY=
=QR21
-END PGP SIGNATURE-

Bug#1023813: rust-once-cell: please update to 1.16.0

[Jonas Smedegaard]

Source: rust-once-cell
Version: 1.14.0-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to v1.16.0, needed by projects I am preparing for Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNtA8MACgkQLHwxRsGg
ASERqQ/9H/4Go9MSZW2Oi0RNBMbzzIhTzp2TPeQ7HUv6I/XiIzXwdxI0J+uLUWHo
jtsqtqMILZtPeqB3We6+D8NEEhjcFT5tXQ9UFRj84ySR2eAwhkQxaProaitox3hc
N19XWKfsaGjOsN4c9FWJF7B7rMQ/9ck5+zWeuLsFbgtUy/Ueh2/r8sIiGP8ZO4wn
0V5qkuV86Rmo4wNyOJIf3PEL+49J/BaLxSZfLEdaod0ox4+kourU+/o0fpTaQV5x
xO0BvlLpoV1ogR/1QT4oPtOnfcu3fM/Lb2Y5WrJn0JkEli1s6MNIeOachxgART1W
ZygYcD1XpCP7re3rgfr5Rwx2YRFTl8VpBJcBu1QZd+fQR+SpVvAz5NnodLFA743h
GvK168ODw/vQvnnCALMa7QoA+eVFkkxveu8IAcZLGj7dGQMGBkhHUzfco4BslMtJ
yNsSIvCS6dWacZZ3ID2zCJG+vDJjjOAwQzpMO9jT2kUryIihn1uxW7aGJiI/LZzQ
N2Fac7X/Cg+3Mt/ztEUqok5FtYDSzPdp2J2tgCV8y+aBmt+8y4BIyHEl5ZPYXcY1
r5vwBBgNepbQj9/C+66W+YJNEeK/N3hCEMJS6oJxNwBD7kpQMX6BQE8HnjlFOpQb
87DDuyY+NHzf6lR0gmKv7f1D0PFQAmHTw3aDrqvPNFrxRKsoFTU=
=Ym5r
-END PGP SIGNATURE-

Bug#1023770: chroma: Game status bar vanishes on first exit from fullscreen until window is resized

[Simon Tatham]

Alex Brett  wrote:
> To reproduce:
> 1(a) launch chroma (from the GUI menu or via CLI with command
>  "chroma")
>  (b) enter the Display Options menu and toggle the "Fullscreen" display 
>  option to "No"
>  (c) load a game level
>  (d) observe that the status bar is not present
>  (e) resize the chroma window (maximised vs not; manual resize via click
>  + drag)
>  (f) observe that the status bar reappears

Thanks for this report. Unfortunately I wasn't able to reproduce it in a
quick test of my own: whenever the window was not fullscreened, it had a
status bar just as I expected.

Before I make a more serious effort, can you provide a couple more
details, please? I suspect this behaviour might vary with display size /
resolution, so to begin with:

1. what's your display size in pixels?

2. what is Chroma's own display size configured to, in the Display
Options setting just above 'Fullscreen'?

Also, when you say 'status bar is not present', can you describe in more
detail what _is_ present? I'm guessing you mean that you can see all
four edges of the non-fullscreen window frame, and the main game display
extends right to the bottom frame edge?

(Another possibility is that the whole of the bottom part of the window
extends off the bottom of the screen, including the lower frame edge and
enough pixels above that to contain the status bar. But I'm sure you'd
have tried dragging the window upwards to reveal the status bar, if that
were the case.)

Assuming I guessed right there: what happens if you begin resizing the
window _horizontally_, not changing its height? When the status bar
reappears, does the rest of the window suddenly ping upwards slightly to
make space?

Cheers,
Simon

-- 
import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1(
m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r
and s%q!=0 and m)(12342649995480866419, 2278082317364501, 1670428356600652640,
5398151833726432125, 645223105888478, 1916678356240619, ""))

Bug#1023812: git: Source package misses dependency to libssl-dev package

[doak]

Package: git
Version: 1:2.30.2-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: doak+...@posteo.net

Dear Maintainer,

The source package of `git` seems not to specify the dependency to
`libssl-dev`.

Steps to reproduce:
Compiling Git on a Debian live CD fails. These are the steps to
reproduce:
# apt build-dep git
git$ make

Make complains about missing OpenSSL header. Installing `libssl-dev`
fixes this.

Expected:
I would that after installing build dependencies for Git, it is built
successfully.


Best regards,
doak



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

Kernel: Linux 5.10.0-18-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)
LSM: AppArmor: enabled

Versions of packages git depends on:
ii  git-man  1:2.30.2-1
ii  libc62.31-13+deb11u4
ii  libcurl3-gnutls  7.74.0-1.3+deb11u3
ii  liberror-perl0.17029-1
ii  libexpat12.2.10-2+deb11u3
ii  libpcre2-8-0 10.36-2+deb11u1
ii  perl 5.32.1-4+deb11u2
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages git recommends:
ii  ca-certificates  20210119
ii  less 551-2
ii  openssh-client [ssh-client]  1:8.4p1-5+deb11u1
ii  patch2.7.6-7

Versions of packages git suggests:
ii  gettext-base  0.21-4
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information

Bug#1023811: golang-github-grpc-ecosystem-go-grpc-middleware_1.3.0-1 sources changed in the archive?

[Adrian Bunk]

Package: ftp.debian.org
Severity: grave
X-Debbugs-Cc: debian-wb-t...@lists.debian.org, Thomas Goirand 

https://buildd.debian.org/status/logs.php?pkg=golang-github-grpc-ecosystem-go-grpc-middleware=1.3.0-1=all=experimental

The three Maybe-Failed until November 3rd at the bottom are normal FTBFS.

But the Maybe-Given-back since yesterday are:

...
Get:1 https://deb.debian.org/debian experimental/main 
golang-github-grpc-ecosystem-go-grpc-middleware 1.3.0-1 (dsc) [2857 B]
Err:1 https://deb.debian.org/debian experimental/main 
golang-github-grpc-ecosystem-go-grpc-middleware 1.3.0-1 (dsc)
  Hash Sum mismatch
  Hashes of expected file:
   - SHA256:8e86e0a9cc31461c0f564e8feefb2e1e9ec05c265ab06e96fd32b7de787bc504
   - Filesize:2857 [weak]
   - MD5Sum:c4d33ab09e4f4a95c819dd1de88d0876 [weak]
  Hashes of received file:
   - SHA256:8bbee530bbdb11a58a275c34878c372558223c294384897822eba1338b84db82
   - MD5Sum:8d6eee1b2b773c9be12536396ba949a6 [weak]
   - Filesize:2857 [weak]
  Last modification reported: Wed, 26 Oct 2022 14:32:16 +
Get:2 https://deb.debian.org/debian experimental/main 
golang-github-grpc-ecosystem-go-grpc-middleware 1.3.0-1 (tar) [104 kB]
Get:3 https://deb.debian.org/debian experimental/main 
golang-github-grpc-ecosystem-go-grpc-middleware 1.3.0-1 (diff) [2652 B]
E: Failed to fetch 
https://deb.debian.org/debian/pool/main/g/golang-github-grpc-ecosystem-go-grpc-middleware/golang-github-grpc-ecosystem-go-grpc-middleware_1.3.0-1.dsc
  Hash Sum mismatch
   Hashes of expected file:
- SHA256:8e86e0a9cc31461c0f564e8feefb2e1e9ec05c265ab06e96fd32b7de787bc504
- Filesize:2857 [weak]
   Fetched 109 kB in 0s (416 kB/s)
 - MD5Sum:c4d33ab09e4f4a95c819dd1de88d0876 [weak]
   Hashes of received file:
- SHA256:8bbee530bbdb11a58a275c34878c372558223c294384897822eba1338b84db82
- MD5Sum:8d6eee1b2b773c9be12536396ba949a6 [weak]
- Filesize:2857 [weak]
   Last modification reported: Wed, 26 Oct 2022 14:32:16 +
E: Failed to fetch some archives.
E: apt-get for sources failed
...


I can reproduce the problem locally with
$ apt-get source golang-github-grpc-ecosystem-go-grpc-middleware/experimental

This is not supposed to happen, and I haven't seen this before.

Bug#963899: Build smbclient against MIT krb5

[Michael Tokarev]

On Sun, 28 Jun 2020 16:39:44 +0100 Sam Morris  wrote:
...

Since running Samba AD DC built with MIT Kerberos is still an
experimental feature, it's not a good idea to switch the whole source
package over wholesale. But I wonder if it would be possible to build
only smbcliennt with the system libkrb5, so that it can take advantage
of these features (in particular, credential cache types other than
FILE)?


Currently, this is not possible, because almost all binary packages built
from samba source in Debian depend on common samba-libs package, and the
dependency is strict (= exact binary version).

This is because samba-libs is a massive thing which contains everything,
all libraries needed by any other binary in samba, including all internal
libraries.

In particular, smbclient and libsmbclient both depends on samba-libs (of
the exact binary version of samba-libs).

And samba-libs package highly depends on the configuration.

In 4.16 I tried to move libraries which are only used in a single binary
package, to that package out of samba-libs. This way, for example, winbind
package got a few libs. Bit this is nothing really.

But samba-libs needs to be split further, into something like samba-common-libs,
samba-client-libs, and so on. This way, we may have some of them independent on
the kerberos implementation used - say, samba-common-libs, whicih can be used
by both heimdal-using samba server packages and mitkrb5-using smbclient.

Or alternatively, another set of samba-libs - ie, another package of samba-libs,
say, samba-libs-mitkrb5 - needs to be created.  This quickly becomes rather
ugly and unmanageable.

I think the only more or less realistic way to go is to split samba-libs into
subcomponents.  Actually, samba-common-bin and samba packages also needs to
be split further into multiple pieces.  For example, that needs to be
samba-ad-dc, samba-ad-dc-provision (for /usr/share/samba/setup/*), maybe
samba-krb5-printing, maybe python3-samba-ad-dc (from python3-samba) and
so on.  This is not a huge work really, but it needs to be done in order
to allow to mix and match things.

Besides, I implemented pkg.samba.mitkrb5 build profile for samba package,
maybe this one will help somehow. But it builds everything with mit-krb5,
including the experimental ad-dc code.

Thanks,

/mjt

Bug#835672: xfce4-power-manager: If installed without xfce4-session, fails to lock screen due to missing xflock4 script

[Akbarkhon Variskhanov]

Control: tags -1 upstream moreinfo
Control: wishlist -1 minor

That's how it's intended to be. See
https://bugzilla.xfce.org/show_bug.cgi?id=12603

If you check your ~/.xsession-errors there should be a warning about
setting a LockCommand. The simplest fix is to actually set it via
`xfconf`:

$ xfconf-query --channel xfce4-session --property /general/LockCommand
--set "lock_command_of_your_choice"

If it's not set, the following commands will be tried in the order specified:
xflock4
xdg-screensaver lock
xscreensaver-command -lock

If none succeed, the function xfce_screensaver_lock() returns FALSE,
which makes it look like it's useless.

Note that it's not supposed to work 100% outside Xfce4.

Bug#1023734: linux-image-6.0.0-2-amd64: No network connection, no pulseaudio server connection

[Guy Durrieu]

Hi Diederik,

Thanks for your useful answer, that is what I more or less understood 
after thinking about it, but it's better to have a confirmation :)


And don't worry, my emails were a bit messy anyway !

Best regards.

-- Guy Durrieu.

Le 10/11/2022 à 12:15, Diederik de Haas a écrit :

On donderdag 10 november 2022 11:54:59 CET Diederik de Haas wrote:

Perhaps I didn't understand what you meant... Does the linux image
6.0.0.3 (6.0.7.2) include the patch correcting my issue ? And in this
case, is it sufficient to download the linux image and the linux headers
in order to test the result ?

No. In order to test the patch, you do need to build a kernel.

Oh boy, I probably should've stayed out of it completely ...

In another response to this bug, Salvatore did provide an alternative means
and that is using the kernel package he build for you.

See this part:

On woensdag 9 november 2022 17:42:44 CET Salvatore Bonaccorso wrote:

Additionnally, I am not sure to know how to proceed in order to apply the
patch you sent. Could you give me some hint ?

There is our documentation at
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4
.2.2 . But would you be willing to test (but be aware, unsigned!) test
packages fetched byhttps://people.debian.org  ?

https://people.debian.org/~carnil/tmp/linux/6.0.7-2/

I have put a sha256sum file with signature on it with my gpg key to
have an additional verification on those.

https://db.debian.org/fetchkey.cgi?fingerprint=04A4407CB9142C23030C17AE789D6
F057FD863FE

So you have 2 options:
- build it yourself from source (with instructions from 4.2.2)
- Use the packages Salvatore build for you at the above location

Keep in mind that you normally shouldn't install programs ('deb' on Debian or
'exe' if on Windows) from "strangers on the internet". Salvatore did provide a
(gpg) signed file to provide some mitigation against the risks.
But you would still need to trust Salvatore.

If you build it yourself, then you don't download programs from "strangers on
the internet". But that obviously is more work. Which can be daunting if you
hadn't done that before.

HTH

(And now I'm really staying out of it ;-))

Bug#1023779: linux: deleting the kernel image package leaves back /lib/modules/ when a kernel package was built

[Christoph Anton Mitterer]

Hey Diederik and Bastian

On Thu, 2022-11-10 at 13:07 +0100, Bastian Blank wrote:
> Those symlinks are included in linux-headers-6.0.0-3-amd64, see
> https://packages.debian.org/sid/amd64/linux-headers-6.0.0-3-amd64/filelist
> 
> Did you remove that package as well?


You are both right, I have linux-headers-6.0.0-3-amd64 and totally
forgotten about that.

But nevertheless, shouldn't that then contain those files and dpkg not
print out an error then?
And indeed:
$ dpkg -L linux-headers-6.0.0-3-amd64 | grep '^/lib'
/lib
/lib/modules
/lib/modules/6.0.0-3-amd64
/lib/modules/6.0.0-3-amd64/build
/lib/modules/6.0.0-3-amd64/source

So I'm a bit surprised why I saw some error at all in that case.


Thanks,
Chris.

Bug#1023810: acct: Initscript complains about non-existant /var/lock/subsys/

[Hendrik Jaeger]

Package: acct
Version: 6.6.4-4
Severity: normal
X-Debbugs-Cc: debian-b...@henk.geekmail.org

Dear Maintainer,

   * What led up to the situation?

A mail from Anacron containing:
/etc/cron.daily/acct:
touch: cannot touch '/var/lock/subsys/acct': No such file or directory

Running the initscript manually gives the same error.

(Accounting needs to be enabled in /etc/default/acct or the error will
not occur)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

/var/lock/subsys/ does not exist on my sysvinit-based systems:
# namei -l '/var/lock/subsys/acct'
f: /var/lock/subsys/acct
drwxr-xr-x root root /
drwxr-xr-x root root var
lrwxrwxrwx root root lock -> /run/lock
drwxr-xr-x root root   /
drwxr-xr-x root root   run
drwxrwxrwt root root   lock
 subsys - No such file or directory

AFAIU this directory is created on systemd-based systems but does not
seem to get created on sysvinit-based systems.
Since it’s on a tmpfs, creating it manually would not help permanently:
# df -h /var/lock/
Filesystem  Size  Used Avail Use% Mounted on
tmpfs   5.0M 0  5.0M   0% /run/lock


I don’t know where this directory is supposed to be coming from on
sysvinit-based systems.
Maybe the acct initscript should check whether it exists and create it
if needed?

Thanks

Hendrik


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

Kernel: Linux 5.10.0-15-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages acct depends on:
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u3
ii  lsb-base 11.1.0

acct recommends no packages.

acct suggests no packages.

-- no debconf information

Bug#1023809: libtagsoup-java: make icedtea-netx unusable

[MAG4 Piemonte]

Package: libtagsoup-java
Version: 1.2.1+-1.1
Severity: normal
X-Debbugs-Cc: m...@aruba.it

Dear Maintainer,
investigating further on https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=993798 we discover that the workaround we applied
concerns your package (/usr/share/java/tagsoup-1.2.1.jar) and not icedtea-netx.
May be it is possible to correct the bug for Debian 12 (bookworm) ...
Regards!

Guido


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

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

libtagsoup-java depends on no packages.

libtagsoup-java recommends no packages.

Versions of packages libtagsoup-java suggests:
pn  libtagsoup-java-doc  

-- no debconf information

Bug#1023808: packaging gstreamer 1.22

[Johannes Schauer Marin Rodrigues]

Source: gstreamer1.0
Version: 1.20.3-1
Severity: wishlist

Hi gstreamer maintainers,

according to [1], gstreamer 1.22 is planned to be released on December
26 this year. This is 17 days before the transition and toolchain
freeze. Do you think it makes sense to aim for 1.22 in bookworm?

Independent of the above:

 - do you think it would make sense to have 1.21.x (and later 1.22) in
   experimental?
 - are you planning to follow the upstream move into a mono-repo for the
   individual source packages?
 - do you need any help?

My motivation: I own the MNT Reform laptop which runs on an IMX8MQ board
and uses Hantro G1 and G2 for hardware video decoding. But this needs
v4l2slh265dec from gst-plugins-bad...

Thanks!

cheers, josch

[1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/974

Bug#1017088: ITP: c4core -- library of low-level C++ utilities, written with low-latency projects in mind

[Daichi Fukui]

Hi all,

On Mon, 31 Oct 2022 21:46:18 +0900 Daichi Fukui <
a.dog.will.t...@akane.waseda.jp> wrote:
> Hi Punit-san,
>
> Thanks for a reply.
>
> On Tue, 25 Oct 2022 at 06:46, Punit Agrawal 
wrote:
>
> > Hi Fukui-san,
> >
> > Daichi Fukui  writes:
> >
> > > Hello Debian Developers,
> > >
> > > On Sat, 13 Aug 2022 13:03:16 + Fukui Daichi <
> > a.dog.will.t...@akane.waseda.jp> wrote:
> > >> Package: wnpp
> > >> Severity: wishlist
> > >> Owner: Fukui Daichi 
> > >> X-Debbugs-Cc: debian-de...@lists.debian.org,
> > a.dog.will.t...@akane.waseda.jp
> > >>
> > >> * Package name: c4core
> > >>   Version : 0.1.9
> > >>   Upstream Author : Joao Paulo Magalhaes 
> > >> * URL : https://github.com/biojppm/c4core
> > >> * License : MIT
> > >>   Programming Lang: C++
> > >>   Description : library of low-level C++ utilities, written with
> > low-latency projects in mind
> > >>
> > >> Rationale:
> > >>rapidyaml [0] depends on this utility.
> > >>Moreover, jsonnet [1] depends on rapidyaml.
> > >>
> > >>[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003397
> > >>[1] https://tracker.debian.org/pkg/jsonnet
> > >>
> > >> Maintenance plan:
> > >>Because I am a novice in debian packaging, I would like to
> > >>ask for someone who can review my upload. I need a sponsor too.
> > >>
> > >>
> > >
> > > As mentioned in a different bugreport [0], c4core depends on
> > biojppm/cmake, debugbreak, and fast_float.
> > > To meet the dependency, we're now preparing for uploading debugbreak
and
> > fast_float [1][2].
> > >
> > > As for biojppm/cmake, it looks like this software is used for the
> > author's project only.
> > > This makes me wonder if it is really reasonable to package
biojppm/cmake.
> > > It is technically possible to package it but it could end up with no
> > other packages depending on the packaged biojppm/cmake than c4core.
> > > To make a clear decision, I would like to ask for your opinion on this
> > issue.
> > >
> > > If you are interested, see also a discussion [3] similar to this one.
> >
> > I'm not familiar with Debian convention regarding this so please take
> > any comments here with a pinch of salt.
> >

I've been trying to use the newly added libfast-float-dev [0] and
debugbreak [1] packages to replace some embedded header files of c4core.

While looking at libfast-float-dev, I came up with the following issue.
Let me explain what's going on.

c4core uses fast_float.hpp and fast_float_all.h many times in its source
code,
so first I tried to simply replace them with the header files which the
libfast-float-dev package provides.
Note that the fast_float.hpp is effectively a wrapper for fast_float_all.h.
However, it seems a bit difficult to use the libfast-float-dev package for
replacing fast_float.hpp and fast_float_all.h.
This is because fast_float_all.h was apparently created with
fast_float/script/amalgamate.py as a single header file,
which the libfast-float-dev package does not provide as such.

Taking the situation above into account, I would like to propose the
following options to address this issue.

Options:

(a) Use fast_float.hpp and fast_float_all.hpp, both of which are already
embedded in c4core;
we don't use libfast-float-dev for replacing them.

(b) Use the fast_float pacakge - use amalgamate.py to generate a single
header like fast_float_all.hpp,
add it to the fast_float package, then replace fast_float_all.hpp with the
one which the package provides

I would appreciate it if you help me decide which option to take or if you
share other options, if any.
What do you think?

FYI, there are no issues when it comes to using debugbreak for c4core.

[0] https://packages.debian.org/bookworm/libfast-float-dev
[1] https://packages.debian.org/bookworm/debugbreak

Best,
Fukui

Bug#743335: Topli pozdravi!

[Avukat. Ferzi Karhan]

 Topli pozdravi!
Ja sam odvjetnik Ferzi Karhan, imam poruku za vas u vezi s nepotraživanim
nasljedstvom mog preminulog klijenta s kojim dijelite isto nacionalnost i
prezime. Ovaj fond vrijedi iznos od 6,450,000 U$D, ljubazno odgovorite za
dodatna pojašnjenja, ako ovo fond nije potraživan, banka će ga zaplijeniti,
pa mi treba vaša pomoć.

Lijepi pozdrav.
Av. Ferzi Karhan Esq.
Istanbul, Turska.

Bug#1013302: ntopng FTBFS /build/1st/ntopng-5.2.1+dfsg1/debian/missing-sources/gauge.coffee:179:3: error: Can't reference 'this' before calling super in derived class constructors

[Blair Noctis]

On Tue, 21 Jun 2022 09:08:56 +0100 Peter Green  wrote:> >
/build/1st/ntopng-5.2.1+dfsg1/debian/missing-sources/gauge.coffee:179:3: error:
Can't reference 'this' before calling super in derived class constructors
> > @value = 1 * @elem.innerHTML
> > ^
> > make[1]: *** [debian/rules:24: override_dh_auto_build] Error 1

Simply adding two lines of `super()` solves this, but I'm curious if we could
get rid of the coffee script. It's there supposedly because there were only
minimized JavaScript and we need a way to reproduce them. Now upstream has the
"original" JS file present. Original in quotes because it's still generated from
a coffee script, but *its upstream* distributes the coffee script together with
generated JS.

-- 
Sdrager,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014506: slurm-wlm: flaky autopkgtest: sbatch fails without

[Paul Gevers]

Control: tag -1 patch pending

Hi,

On Thu, 7 Jul 2022 11:22:44 +0200 Paul Gevers  wrote:
I looked at the results of the autopkgtest of you package on armhf 
because it was showing up as a regression for the upload of perl. I 
noticed that the test regularly fails and I saw failures on other 
architectures too.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.


I took a look how long the test needs if I let it run a bit longer, and 
on armhf it took 17 seconds in several attempts. Apparently 5 seconds is 
just a bit tight.


I am going to upload an NMU to DELAYED/10 with the changes in MR5 [1]. 
Please let me know if I should delay further or should cancel the upload.


Paul

[1] https://salsa.debian.org/hpc-team/slurm-wlm/-/merge_requests/5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023807: seqan-needle: /usr/bin/needle is already shipped by emboss

[Andreas Beckmann]

Package: seqan-needle
Version: 1.0.1.0.0.git.3011926+ds-1
Severity: serious

There is already a (unrelated?) /usr/bin/needle binary in the Debian
archive, provided by the emboss package.


Andreas

Bug#1023719: field3d FTBFS: OpenEXR/ImathBox.h: No such file or directory

[Andreas Beckmann]

Followup-For: Bug #1023719
Control: tag -1 sid bookworm

libilmbase-dev has been superseded by libimath-dev with a different file
layout.

Andreas