Bug#1001234: src:firefox-esr: fails to migrate to testing for too long: FTBFS on mipsel and unresolved RC bug

[Mike Hommey]

On Wed, Dec 08, 2021 at 09:07:24AM +0200, Martin-Éric Racine wrote:
> Package: firefox-esr
> Version: 78.15.0esr-1~deb11u1
> Followup-For: Bug #1001234
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> 91.4.0esr-1 was indeed uploaded. However, mipsel was not removed from the 
> list of architectures in the control file, so it attempted building. This 
> will likely prevent migration.

I don't think removing the architecture from the control file would
change anything wrt migration.

> Better care in maintaining this package would be appreciated. CVE fixes have 
> yet to trickle into Testing or be uploaded to Stable-Updates for over 60 
> days. That's not acceptable.

For stable, it's not under my control. AFAIK, the necessary rust
compiler is still not available yet.

Mike

Bug#1001312: kore: FTBFS with postgresql 14, with openssl 3

[Steve Langasek]

Package: kore
Version: 4.1.0-4
Severity: serious
Tags: patch
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Hi Shih-Yuan,

In Ubuntu, the kore source package is failing to build from source due to
incompatibilities with both openssl 3 (currently in Debian experimental) and
postgresql 14 (in Debian unstable):


[...]
src/config.c: In function ‘configure_tls_dhparam’:
src/config.c:810:9: error: ‘PEM_read_bio_DHparams’ is deprecated: Since OpenSSL 
3.0 [-Werror=deprecated-declarations]
  810 | tls_dhparam = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
  | ^~~
In file included from /usr/include/openssl/ssl.h:36,
 from include/kore/kore.h:35,
 from src/config.c:29:
/usr/include/openssl/pem.h:469:1: note: declared here
  469 | DECLARE_PEM_rw_attr(OSSL_DEPRECATEDIN_3_0, DHparams, DH)
  | ^~~
[...]

  (https://launchpad.net/ubuntu/+source/kore/4.1.0-4build1/+build/22583996)

(Other errors follow this one)

A patch to simply turn these errors back into warnings is sufficient to let
the package build, and I think is a reasonable solution until upstream
addresses these issues.  Please see attached.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru kore-4.1.0/debian/rules kore-4.1.0/debian/rules
--- kore-4.1.0/debian/rules 2020-09-25 08:41:16.0 -0700
+++ kore-4.1.0/debian/rules 2021-12-07 23:17:01.0 -0800
@@ -6,6 +6,8 @@
 export TASKS=1
 export PGSQL=1
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+export DEB_CFLAGS_MAINT_APPEND = -Wno-error=deprecated-declarations \
+   -Wno-error=discarded-qualifiers -Wno-error=switch
 
 %:
dh $@

Bug#1001234: src:firefox-esr: fails to migrate to testing for too long: FTBFS on mipsel and unresolved RC bug

[Martin-Éric Racine]

Package: firefox-esr
Version: 78.15.0esr-1~deb11u1
Followup-For: Bug #1001234

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

91.4.0esr-1 was indeed uploaded. However, mipsel was not removed from the list 
of architectures in the control file, so it attempted building. This will 
likely prevent migration.

Better care in maintaining this package would be appreciated. CVE fixes have 
yet to trickle into Testing or be uploaded to Stable-Updates for over 60 days. 
That's not acceptable.

Martin-Éric

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmGwWasACgkQrh+Cd8S0
17bKIA//QwVaZSjj17lL/tzje02i5CD1K4VNKTjSutNsQoJqa8YbBjSpbSl+qEsI
Wwo0lYYFWA6D7I6dyQsErsLEHlC4V0QI/LbHC1aY097OAQf1zj/yGPIYlDyFOpxW
oxOnWgSIXUwhNZbVdLm96kgjmHYPqZksJe9ZNqMwST8krtoRVnMdHlR0dqfZEYlq
sskO6WPS4q52HzC8mmgzUY8aLcUQB36G1SbR4laQJHVH7NJoimQWVf2IwG5YOyZn
A+OD0Gy8mN1E0dx4ALwxao8A6HrXik0uqiaSY2hbnxGy4tI+8JHgx5O1zq9fWvaI
t6Hdnq77izrp7f+s/vozYK+GJaliz0HAJ9dUlogns4aYnbVppKV0bUMe/cAVP6Y0
4kPWuanKc5fetoa9bAYv1mcdhfD/ff7wVKHYGGVIrE+yW45S1eWoZ3R+FWzAuHx0
vHV2tgy+K25p09M078FHWal1SZkyzkgRrWnPEtLA5xppE9iNoiycanX4jOskSG2i
58P/x3vUfk/QqeeEkPLbwZGKjxNqSkCqZGiAsBHJXA+674vaHzm5dddWQQd2buNz
iG67aB88yzfn0kcbZWlfoZWRqhDfXshnYA5pJ7jj0HC26Zc0C0uSC3ser/5KICtL
WZwAfouqAIJPREp8l5VTaoN4W/8A+TL2EwpDiS7ZT8VYCdvhTn4=
=HoFh
-END PGP SIGNATURE-

Bug#1001311: certmonger: FTBFS with openssl 3

[Steve Langasek]

Source: certmonger
Version: 0.79.14+git20211010-2
Severity: serious
Tags: experimental
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy

Hi Timo,

certmonger FTBFS against openssl 3 with an undefined symbol error:

[...]
gcc   -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
-isystem /usr/include/mit-krb5   -I/usr/include/uuid -g -O2 
-ffile-prefix-map=/<>/certmonger-0.79.14+git20211010=. -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-Wall -Wextra  -I/usr/include/libxml2 -I/usr/include/nss -I/usr/include/nspr 
-I/usr/include/x86_64-linux-gnu -g -O2 
-ffile-prefix-map=/<>/certmonger-0.79.14+git20211010=. -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-Wall -Wextra -fPIC  -fPIC -pie -Wl,-z,relro,-z,now -o scep-submit 
scep_submit-scep.o scep_submit-submit-h.o scep_submit-util-m.o 
scep_submit-util-o.o scep_submit-submit-u.o scep_submit-util.o 
scep_submit-log.o scep_submit-pkcs7.o scep_submit-store-gen.o scep_submit-tm.o 
scep_submit-prefs.o scep_submit-prefs-o.o scep_submit-scep-o.o 
scep_submit-env-system.o -lcurl -lxml2 -lnss3 -lnssutil3 -lsmime3 -lssl3 
-lplds4 -lplc4 -lnspr4 -lcrypto -ltalloc  -luuid  -lpopt
../../src/submit-h.c: In function ‘cm_submit_h_run’:
../../src/submit-h.c:257:17: warning: call to 
‘_curl_easy_setopt_err_write_callback’ declared with attribute warning: 
curl_easy_setopt expects a curl_write_callback argument for this option 
[-Wattribute-warning]
  257 | curl_easy_setopt(ctx->curl, CURLOPT_WRITEFUNCTION,
  | ^
/usr/bin/ld: /tmp/ccPXkLF2.ltrans0.ltrans.o: in function `main':
./build/src/../../src/util-o.c:54: undefined reference to `OPENSSL_init_ssl'
collect2: error: ld returned 1 exit status
[...]

  
(https://launchpad.net/ubuntu/+source/certmonger/0.79.14+git20211010-2/+build/22293176)

openssl 3 is currently in experimental, and is expected to ship with the
next version of Debian.  It is also the version of openssl to be used for
the upcoming Ubuntu 22.04 LTS release.

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


signature.asc
Description: PGP signature

Bug#1001310: ITP: golang-github-charmbracelet-lipgloss -- style definitions for nice terminal layouts

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-charmbracelet-lipgloss
  Version : 0.4.0-1
  Upstream Author : Charm
* URL : https://github.com/charmbracelet/lipgloss
* License : Expat
  Programming Lang: Go
  Description : style definitions for nice terminal layouts 

 Go package lipgloss provides style definitions for nice terminal layouts.
 Built with TUIs in mind.
 .
 Lip Gloss takes an expressive, declarative approach to terminal
 rendering.  Users familiar with CSS will feel at home with Lip Gloss.


Reason for packaging:
 Prerequsite for e.g. github.com/muesli/gitty

Bug#1001188: Advice debugging zoneminder in stable?

[Dmitry Smirnov]

On Wednesday, 8 December 2021 3:01:01 AM AEDT Petter Reinholdtsen wrote:
> [Dmitry Smirnov]
> 
> > I can only say that the issue could be a case of Firefox's "Enhanced
> > Tracking Protection", which is a per-site setting you can access under
> > the shield icon left from the address bar. Could you give it a try?
> 
> I did, and with it disabled, Firefox worked.  Thanks.  I'll update the
> bug report, to let others know too.

Good to know. Thanks for confirming.

By the way, ZoneMinder entered bullseye-backports. :)

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

---

The thieves, thugs and murderers who declare their crimes to be "legal"—
which every tyrant in history has done — will always brand any who resist
them as criminals and terrorists.
 -- Larken Rose, The Most Dangerous Superstition

---

30 facts you NEED to know: Your COVID Cribsheet:
https://off-guardian.org/2021/09/22/30-facts-you-need-to-know-your-covid-cribsheet/


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

Bug#1001309: docker.io: TestGetSourceMount test failure with pbuilder

[Vignesh Raman]

Package: pbuilder
Version: 0.231
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: vignesh.ra...@collabora.com

Dear Maintainer,

TestGetSourceMount test in docker.io_20.10.5+dfsg1-1 fails in pbuilder with the 
below error,

=== Failed
=== FAIL: daemon TestGetSourceMount (0.00s)
oci_linux_test.go:185: assertion failed: error is not nil: Can't find mount 
point of /

This test is skipped in docker.io for pbuilder,
https://salsa.debian.org/go-team/packages/docker/-/commit/a31ac1d611431a530433179812ce809c11dc2edc

But when docker.io is built with sbuild, TestGetSourceMount passes.

Please could you look into this issue. Thanks.

Regards,
Vignesh

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

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

Versions of packages pbuilder depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  debootstrap1.0.123
ii  dpkg-dev   1.20.9

Versions of packages pbuilder recommends:
ii  devscripts  2.21.3+deb11u1
ii  eatmydata   105-9
ii  fakeroot1.25.3-1.1
ii  iproute25.10.0-4
ii  sudo1.9.5p2-3

Versions of packages pbuilder suggests:
pn  cowdancer   
pn  gdebi-core  

-- debconf information:
  pbuilder/rewrite: false
  pbuilder/nomirror:
  pbuilder/mirrorsite: http://deb.debian.org/debian/

-- debsums errors found:
debsums: changed file /usr/share/pbuilder/pbuilderrc (from pbuilder package)

Bug#1001308: RFP: nova-the-squirrel -- Nova the Squirrel platform arcade game

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: j...@nahmias.net, bushyt...@novasquirrel.com, 
debian-devel-ga...@lists.debian.org

* Package name: nova-the-squirrel
  Version : 1.0.6
  Upstream Author : NovaSquirrel 
* URL : https://novasquirrel.itch.io/nova-the-squirrel
* License : GPL3+
  Programming Lang: ASM
  Description : Nova the Squirrel platform arcade game

 Nova the Squirrel is a platformer game for the NES that draws inspiration
 from a lot of different games -- especially the Super Mario Bros series.
 It features ability copying and focuses on interesting puzzle mechanics.
 .
  * 33 different levels across 5 worlds, and 7 bosses to fight
  * Copy the abilities of your enemies. (10 in all!)
  * Over 35 different types of enemies, plus variants.
  * Interesting puzzle mechanics.
  * A collectible in every level for those wanting a challenge.
  * A few bonus challenge levels after the main game.

Bug#1001307: ceres-solver: invalid Uploaders field: missing comma between Anton Gladky and Francois Mazen

[Paul Wise]

Source: ceres-solver
Version: 2.0.0+dfsg1-1~exp1
Severity: serious

ceres-solver 2.0.0+dfsg1-1~exp1 introduced an invalid Uploaders field,
that is missing a comma between Anton Gladky and Francois Mazen.

   $ apt-cache showsrc ceres-solver | grep -E '^$|^Version|^Uploaders'
   Version: 1.14.0-14
   Uploaders: Philipp Huebner , Anton Gladky 

   
   Version: 2.0.0+dfsg1-1~exp1
   Uploaders: Anton Gladky  Francois Mazen 

According to Debian policy 5.6.3 the Uploaders field must separate
individual uploaders using commas:

   List of the names and email addresses of co-maintainers of the
   package, if any.
   ...
   The format of each entry is the same as that of the Maintainer
   field, and multiple entries must be comma separated.

   https://www.debian.org/doc/debian-policy/ch-controlfields.html#uploaders

This is causing the DDPO and BLS cron jobs to send error mails,
please fix it as soon as possible.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1001306: mount: exfat filesystem mtime's are wrong

[David Christensen]

Package: mount
Version: 2.36.1-8
Severity: normal
X-Debbugs-Cc: dpchr...@holgerdanske.com

Dear Maintainer,

Please see:

https://www.mail-archive.com/debian-user@lists.debian.org/msg776840.html


David



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

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

Versions of packages mount depends on:
ii  libblkid1  2.36.1-8
ii  libc6  2.31-13+deb11u2
ii  libmount1  2.36.1-8
ii  libsmartcols1  2.36.1-8
ii  util-linux 2.36.1-8

mount recommends no packages.

Versions of packages mount suggests:
pn  nfs-common  

-- no debconf information

Bug#733094: uvcdynctrl still filling the disk

[Kurt Meyer]

"Guvcview doesn't depend upon uvcdynctrl it just recommends it." Okay, but 
unless you disable "recommends", uvcdynctrl gets installed. Based on a little 
bit of research I performed, it is not recommended to disable "recommends" 
because recommended packages are usually needed for a more useful installation.

Source of info for not disabling "recommends":
https://unix.stackexchange.com/questions/122289/why-install-recommends-default-is-true

Does guvcview function or function well enough without uvcdynctrl?

*The following additional packages will be installed:**
*
*  libguvcview-2.0-2 libportaudio2 libwebcam0 uvcdynctrl uvcdynctrl-data**
*
*The following NEW packages will be installed:**
*
*  guvcview libguvcview-2.0-2 libportaudio2 libwebcam0 uvcdynctrl 
uvcdynctrl-data**
*
*0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.**
*
*Need to get 266 kB/386 kB of archives.**
*
*After this operation, 1,437 kB of additional disk space will be used.*

Bug#1000967: spdlog: Please package (and test) new version v1.9.x

[Boyuan Yang]

Hi Michael,

在 2021-12-02星期四的 13:23 +0800，Shengjing Zhu写道：
> On Thu, Dec 02, 2021 at 01:19:54PM +0800, Shengjing Zhu wrote:
> > On Wed, Dec 01, 2021 at 01:43:15PM -0500, Boyuan Yang wrote:
> > > Dear Debian spdlog package maintainer,
> > > 
> > > The spdlog upstream has released v1.9.x series since July 2021 (see
> > > https://github.com/gabime/spdlog/releases ). Please consider packaging
> > > the new
> > > releases in Debian and test whether they work well.
> > > 
> > > Probably we should make uploads in Debian Experimental first to test
> > > compatibility with fmtlib 8.x; this is also recommended by Debian's
> > > fmtlib
> > > package maintainer.
> > > 
> > 
> > I (fmtlib maintainer) just tried to rebuild the level 2 packages in fmtlib
> > transition, found spdlog 1.8 FTBFS with fmtlib 7.
> 
> I mean spdlog 1.8 FTBFS with fmtlib 8..
> 
> > 
> > So I'll need spdlog 1.9 to start fmtlib 8 transition.


Is there any update on this? Ideally I would like to see spdlog 1.9 + fmtlib
8.x in the upcoming Ubuntu 22.04 LTS, and we will need more tests before
pushing the new version on both side.

I am wondering if you have time in the near future to prepare a spdlog 1.9.x
upload into Debian experimental. If you find it ok, I can try to prepare a
version into experimental as NMU so that we can proceed with more testing on
new version's compatibility.

-- 
Thanks,
Boyuan Yang

Bug#1001305: orthanc ftbfs with glibc 2.34

[Steve Langasek]

Package: orthanc
Version: 1.9.7+dfsg-3
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear maintainers,

In Ubuntu, we have upgraded to glibc 2.34 which results in orthanc failing
to build from source, because it includes a test that tries to dlopen()
libdl.so and in glibc 2.34 libdl.so no longer exists, its functionality
having been rolled into libc6.  To fix this test, orthanc will need to
dlopen some other library.

Attached is a patch which switches the test to dlopen libmemusage.so
instead, which is also provided by libc6-dev so should always be available.

Please consider applying this patch or a similar one in Debian.

This is obviously not critical in Debian yet, since experimental still only
has glibc 2.33.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru orthanc-1.9.7+dfsg/debian/patches/glibc-2.34.patch 
orthanc-1.9.7+dfsg/debian/patches/glibc-2.34.patch
--- orthanc-1.9.7+dfsg/debian/patches/glibc-2.34.patch  1969-12-31 
16:00:00.0 -0800
+++ orthanc-1.9.7+dfsg/debian/patches/glibc-2.34.patch  2021-12-07 
18:52:24.0 -0800
@@ -0,0 +1,26 @@
+Description: fix compatibility with glibc 2.34
+ In glibc 2.34, libdl.so no longer exists because the shared library has been
+ rolled into libc.so.  This causes the dlopen tests to fail.  Use
+ libmemusage.so instead, which is also provided by libc6-dev.
+Author: Steve Langasek 
+Last-Update: 2021-12-07
+Forwarded: no
+
+Index: orthanc-1.9.7+dfsg/OrthancServer/UnitTestsSources/PluginsTests.cpp
+===
+--- orthanc-1.9.7+dfsg.orig/OrthancServer/UnitTestsSources/PluginsTests.cpp
 orthanc-1.9.7+dfsg/OrthancServer/UnitTestsSources/PluginsTests.cpp
+@@ -86,10 +86,10 @@
+   //ASSERT_TRUE(l.HasFunction("_init"));
+   
+ #elif defined(__linux__) || defined(__FreeBSD_kernel__)
+-  SharedLibrary l("libdl.so");
++  SharedLibrary l("libmemusage.so");
+   ASSERT_THROW(l.GetFunction("world"), OrthancException);
+-  ASSERT_TRUE(l.GetFunction("dlopen") != NULL);
+-  ASSERT_TRUE(l.HasFunction("dlclose"));
++  ASSERT_TRUE(l.GetFunction("munmap") != NULL);
++  ASSERT_TRUE(l.HasFunction("free"));
+   ASSERT_FALSE(l.HasFunction("world"));
+ 
+ #elif defined(__FreeBSD__) || defined(__OpenBSD__)
diff -Nru orthanc-1.9.7+dfsg/debian/patches/series 
orthanc-1.9.7+dfsg/debian/patches/series
--- orthanc-1.9.7+dfsg/debian/patches/series2021-11-22 06:22:14.0 
-0800
+++ orthanc-1.9.7+dfsg/debian/patches/series2021-12-07 18:50:42.0 
-0800
@@ -1 +1,2 @@
 donotforcec++11.patch
+glibc-2.34.patch

Bug#994582: deluge-gtk: Deluge-GTK will only start in Thin mode

[Julien ROGER]

Package: deluge-common
Version: 2.0.3-3.1
Followup-For: Bug #994582
X-Debbugs-Cc: gulien.ro...@gmail.com

Dear Maintainer,

It seems that this bug is due to an incompatibility with deluge 2.0.3 and
python3.8 and newer. This bug is already "fixed" in deluge git since 2019.  It
would be nice to cherry pick this commit in order to have a working deluge in
bullseye.

https://git.deluge-
torrent.org/deluge/commit/?h=develop=351664ec071daa04161577c6a1c949ed0f2c3206

Thanks's


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

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

Versions of packages deluge-common depends on:
ii  python3 3.9.2-3
ii  python3-chardet 4.0.0-1
ii  python3-mako1.1.3+ds1-2
ii  python3-openssl 20.0.1-1
ii  python3-pil 8.1.2+dfsg-0.3
ii  python3-pkg-resources   52.0.0-4
ii  python3-pyasn1  0.4.8-1
ii  python3-rencode 1.0.6-1+b3
ii  python3-setproctitle1.2.1-1+b1
ii  python3-six 1.16.0-2
ii  python3-twisted 20.3.0-7
ii  python3-xdg 0.27-2
ii  python3-zope.interface  5.2.0-1

Versions of packages deluge-common recommends:
ii  geoip-database  20191224-3
ii  python3-dbus1.2.16-5
pn  python3-geoip   

deluge-common suggests no packages.

Bug#1001304: ITP: golang-github-muesli-ansi -- raw ANSI sequence helpers for Go

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-muesli-ansi
  Version : 0.0~git20211031.c9f0611-1
  Upstream Author : Christian Muehlhaeuser
* URL : https://github.com/muesli/ansi
* License : Expat
  Programming Lang: Go
  Description : raw ANSI sequence helpers for Go

 Package ansi provides raw ANSI sequence helpers for Go.
 .
 ANSI Writer
 .
   import "github.com/muesli/ansi"
 .
   w := ansi.Writer{Forward: os.Stdout}
   w.Write([]byte("\x1b[31mHello, world!\x1b[0m"))
   w.Close()
 .
 Compressor
 .
 The ANSI compressor eliminates unnecessary/redundant ANSI sequences.
 .
   import "github.com/muesli/ansi/compressor"
 .
   w := compressor.Writer{Forward: os.Stdout}
   w.Write([]byte("\x1b[31mHello, world!\x1b[0m"))
   w.Close()


Reason for packaging:
 Prerequisite for golang-github-charmbracelet-bubbletea
 @ https://github.com/charmbracelet/bubbletea

Bug#1001303: alure: FTBFS: -pthread: not found

[Steve Langasek]

Source: alure
Version: 1.2-8
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy

Dear maintainers,

alure currently fails to build from source in sid because something in its
build system produces a semicolon-separated list of build flags, which it
then tries to pass directly on the commandline:

[...]
/usr/bin/c++ -DHAVE_CONFIG_H -D_GNU_SOURCE=1 -I/tmp/alure-1.2/include 
-I/tmp/alure-1.2/obj-x86_64-linux-gnu -I/usr/include/AL -g -O2 
-ffile-prefix-map=/tmp/alure-1.2=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2   -Wextra -Wall 
-funswitch-loops -fvisibility=hidden -pthread  -DALURE_STATIC_LIBRARY -fPIC 
-D_REENTRANT;-pthread;-D_REENTRANT;-D_DEFAULT_SOURCE;-D_XOPEN_SOURCE=600;-I/usr/include/dbus-1.0;-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include;-I/usr/include/libinstpatch-2;-I/usr/include/glib-2.0;-I/usr/lib/x86_64-linux-gnu/glib-2.0/include;-I/usr/include/opus;-I/usr/include/SDL2
 -MD -MT CMakeFiles/alure-static.dir/src/codec_fluidsynth.o -MF 
CMakeFiles/alure-static.dir/src/codec_fluidsynth.o.d -o 
CMakeFiles/alure-static.dir/src/codec_fluidsynth.o -c 
/tmp/alure-1.2/src/codec_fluidsynth.cpp
c++: fatal error: no input files
compilation terminated.
/bin/sh: 1: -pthread: not found
/bin/sh: 1: -D_REENTRANT: not found
/bin/sh: 1: -D_DEFAULT_SOURCE: not found
/bin/sh: 1: -D_XOPEN_SOURCE=600: not found
/bin/sh: 1: -I/usr/include/dbus-1.0: not found
[...]

I don't know what is causing this misbehavior of the build system; if I look
at obj-x86_64-linux-gnu/CMakeCache.txt I see other variables using similar
separators but these only seem to leak onto the commandline for the
fluidsynth cflags:

FLUIDSYNTH_CFLAGS:INTERNAL=-D_REENTRANT;-pthread;-D_REENTRANT;-D_DEFAULT_SOURCE;-D_XOPEN_SOURCE=600;-I/usr/include/dbus-1.0;-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include;-I/usr/include/libinstpatch-2;-I/usr/include/glib-2.0;-I/usr/lib/x86_64-linux-gnu/glib-2.0/include;-I/usr/include/opus;-I/usr/include/SDL2

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


signature.asc
Description: PGP signature

Bug#1001302: nut-client: drop sysvinit support so apcupsd conflict can be dropped

[Matthew Gabeler-Lee]

Package: nut-client
Version: 2.7.4-13
Severity: wishlist

Dear Maintainer,

Trying to work out support for a new UPS I acquired, I found this upstream
github issue about supporting the protocol needed to get full information
out of my new hardware: https://github.com/networkupstools/nut/issues/139 (I
am fastcat in that discussion).

One item that came out of it: being able to install apcupsd side-by-side
would help work around this issue, but is not currently possible due to
conflicts between the packages.

AFAICT, this conflict centers _solely_ on the sysvinit script for
nut-client, or more precisely the /etc/init.d/ups-monitor symlink.  This is
no longer provided by upstream, but rather by the debian package.

If this symlink was removed, the conflict on apcupsd could be dropped, and
the two packages installed side-by-side.

Since this is just a symlink, I think it may be safe to remove it.  I think
it should be simple enough to write some post-upgrade logic to rewrite any
/etc/rcN.d links to the proper name, if they even exist?

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/16 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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nut-client depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libc62.32-4
ii  libupsclient42.7.4-13
ii  lsb-base 11.1.0

Versions of packages nut-client recommends:
ii  bash-completion  1:2.11-2

Versions of packages nut-client suggests:
pn  nut-monitor  

-- Configuration Files:
/etc/nut/nut.conf changed [not included]
/etc/nut/upsmon.conf [Errno 13] Permission denied: '/etc/nut/upsmon.conf'
/etc/nut/upssched.conf [Errno 13] Permission denied: '/etc/nut/upssched.conf'

-- no debconf information

Bug#1001301: transition from ftp to tnftp: update-alternatives: warning: /etc/alternatives/ftp is dangling

[Paul Wise]

Package: ftp
Version: 20210827-3
Severity: normal
Usertags: warnings

When I upgraded the ftp binary package from 0.17-35 to 20210827-3,
the tnftp invocation of update-alternatives gave a warning about
the netkit-ftp alternative being missing.

First tnftp was unpacked, then the old ftp package files removed, the
new ftp transitional package files unpacked, then the tnftp postinst
was run and then the ftp transitional package postinst was run.

https://www.debian.org/doc/debian-policy/ap-flowcharts.html

I think the correct solution is for the new ftp preinst to remove
the netkit-ftp alternative before the old ftp files are removed.

Another solution might be for the tnftp postinst to remove the
netkit-ftp alternative before adding the tnftp alternative.

I didn't test either of the potential solutions though.

   Package installation log:
   Log started: 2021-12-08  06:16:28
   apt-listchanges: Reading changelogs...
   apt-listchanges: Mailing root: apt-listchanges: changelogs for chianamo
   apt-listchanges: Reading changelogs...
   Selecting previously unselected package tnftp.
   Preparing to unpack .../tnftp_20210827-2_amd64.deb ...
   Unpacking tnftp (20210827-2) ...
   Preparing to unpack .../ftp_20210827-3_all.deb ...
   Unpacking ftp (20210827-3) over (0.17-35) ...
   Setting up tnftp (20210827-2) ...
   update-alternatives: warning: alternative /usr/bin/netkit-ftp (part of link 
group ftp) doesn't exist; removing from list of alternatives
   update-alternatives: warning: /etc/alternatives/ftp is dangling; it will be 
updated with best choice
   update-alternatives: using /usr/bin/tnftp to provide /usr/bin/ftp (ftp) in 
auto mode
   Setting up ftp (20210827-3) ...
   Processing triggers for man-db (2.9.4-2) ...
   [master 4edb9812] committing changes in /etc made by "/usr/bin/python3 
/usr/bin/unattended-upgrade"
    5 files changed, 2 insertions(+), 5 deletions(-)
    delete mode 12 alternatives/netrc.5.gz
    delete mode 12 alternatives/pftp
    delete mode 12 alternatives/pftp.1.gz
   Log ended: 2021-12-08  06:16:55

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates-debug'), (860, 'testing-proposed-updates'), (850, 
'buildd-testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), 
(790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), 
(690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ftp depends on:
ii  tnftp  20210827-2

ftp recommends no packages.

ftp suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1001274: scowl source has (probably outdated?) problematic license conditions

[Don Armstrong]

On Tue, 07 Dec 2021, Gernot Hillier wrote:
> The Debian copyright however cites from r/pos/README that "The MWords
> package was explicitly placed in the public domain". To me at least,
> it's unclear whether the both READMEs were considered and if yes, it
> would really help to add some clarifying statements in copyright why
> the licensing terms in the (old?) README files don't apply (any
> more?).

mwords and pos are both part of the Moby Words project, which Grady Ward
dedicated to the public domain (and also provided an equivalent license)
on June 1, 1996.

See
https://web.archive.org/web/20170930060409/http://icon.shef.ac.uk/Moby/
for more details (and the original source files).

They're present in the source, because that's how they are distributed
upstream, but the copyright file lists the actual licensing. [Maybe a
case to be made to clarify this in the upstream source, but I don't
think a Debian specific patch is warranted here.]

-- 
Don Armstrong  https://www.donarmstrong.com

Bug#985678: ITA: rasdaemon -- utility to receive RAS error tracings

[Taihsiang Ho (tai271828)]

If you are interested in testing the current package under development, you
may clone it via the dev-packaging-upstream-0.6.7 branch:
git clone https://salsa.debian.org/tai271828/rasdaemon.git
-b dev-packaging-upstream-0.6.7

- tai

On Wed, Dec 8, 2021 at 12:01 AM Taihsiang Ho (tai271828) 
wrote:

> Hi, everyone,
>
> Even though it is slow, I still made some progress. Let me elaborate here
> so you may know the current status from my side:
>
> - The latest upstream v0.6.7 has been packaged. See my repository
> https://salsa.debian.org/tai271828/rasdaemon.git forked from ahs3's
> repository https://salsa.debian.org/ahs3/rasdaemon
> - I packaged the upstream v0.6.7 with its release tarball
> https://www.infradead.org/~mchehab/rasdaemon/rasdaemon-0.6.7.tar.bz2
> - The package has not been well tested across platforms and archs. Once I
> complete the test and confident that the package works properly, I will
> seek for Debian developers' or maintainers' help to upload the package.
>
> You may build the package with this command:
> gbp buildpackage --git-ignore-new --git-builder=sbuild
>
> I am very new to the whole packaging and ITA process, so I believe the
> package needs a review by experts or veterans. In the meantime, if you are
> interested in this work, or aware of anything that needs to do or improve.
> Please let me know. I will appreciate your feedback.
>
> Cheers,
> Tai
>

Bug#1001299: visp: FTBFS with glibc 2.34

[Steve Langasek]

Package: visp
Version: 3.4.0-4
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear maintainers,

In Ubuntu, we have upgraded to glibc 2.34.  As a result, visp now fails to
build because MINSIGSTKSZ is no longer a constant but expands to a runtime
call to sysconf(), and the visp source assumes it's a constant.

I found an upstream patch for this in Catch, which is where the code in visp
was copied from, and have adapted it to apply to the visp source.  The
attached patch fixes the compile failure with glibc 2.34.

This is obviously not critical yet for Debian, which still only has glibc
2.33 in experimental.

Unfortunately, even after applying this patch, visp still FTBFS in Ubuntu
with a large number of test failures:

[...]
23% tests passed, 218 tests failed out of 282

Total Test time (real) =  40.88 sec

The following tests FAILED:
  3 - perfColorConversion (Subprocess aborted)
[...]

These failures are not reproducible on sid with or without the patch for
glibc 2.34 compatibility, but for the moment they block having a fixed visp
in Ubuntu.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru visp-3.4.0/debian/patches/glibc-2.34.patch 
visp-3.4.0/debian/patches/glibc-2.34.patch
--- visp-3.4.0/debian/patches/glibc-2.34.patch  1969-12-31 16:00:00.0 
-0800
+++ visp-3.4.0/debian/patches/glibc-2.34.patch  2021-12-07 13:58:05.0 
-0800
@@ -0,0 +1,297 @@
+Description: compatibility with glibc 2.34
+ Taken from catch2 upstream, commit id
+ c0d0a50bdb2ae2f749443c0386c2b25379bdbf76 in
+ https://github.com/catchorg/Catch2.
+Author: Steve Langasek 
+Last-Update: 2021-12-07
+
+Index: visp-3.4.0/3rdparty/catch2/catch.hpp
+===
+--- visp-3.4.0.orig/3rdparty/catch2/catch.hpp
 visp-3.4.0/3rdparty/catch2/catch.hpp
+@@ -7688,56 +7688,60 @@
+ #endif // defined(CATCH_PLATFORM_WINDOWS)
+ 
+ // end catch_windows_h_proxy.h
+-#if defined( CATCH_CONFIG_WINDOWS_SEH )
++#include 
+ 
+ namespace Catch {
+ 
+-struct FatalConditionHandler {
+-
+-static LONG CALLBACK handleVectoredException(PEXCEPTION_POINTERS 
ExceptionInfo);
++/**
++ * Wrapper for platform-specific fatal error (signals/SEH) handlers
++ *
++ * Tries to be cooperative with other handlers, and not step over
++ * other handlers. This means that unknown structured exceptions
++ * are passed on, previous signal handlers are called, and so on.
++ *
++ * Can only be instantiated once, and assumes that once a signal
++ * is caught, the binary will end up terminating. Thus, there
++ */
++class FatalConditionHandler {
++bool m_started = false;
++
++// Install/disengage implementation for specific platform.
++// Should be if-defed to work on current platform, can assume
++// engage-disengage 1:1 pairing.
++void engage_platform();
++void disengage_platform();
++public:
++// Should also have platform-specific implementations as needed
+ FatalConditionHandler();
+-static void reset();
+ ~FatalConditionHandler();
+ 
+-private:
+-static bool isSet;
+-static ULONG guaranteeSize;
+-static PVOID exceptionHandlerHandle;
+-};
+-
+-} // namespace Catch
+-
+-#elif defined ( CATCH_CONFIG_POSIX_SIGNALS )
+-
+-#include 
+-
+-namespace Catch {
+-
+-struct FatalConditionHandler {
+-
+-static bool isSet;
+-static struct sigaction oldSigActions[];
+-static stack_t oldSigStack;
+-static char altStackMem[];
+-
+-static void handleSignal( int sig );
++void engage() {
++assert(!m_started && "Handler cannot be installed twice.");
++m_started = true;
++engage_platform();
++}
+ 
+-FatalConditionHandler();
+-~FatalConditionHandler();
+-static void reset();
++void disengage() {
++assert(m_started && "Handler cannot be uninstalled without being 
installed first");
++m_started = false;
++disengage_platform();
++}
+ };
+ 
+-} // namespace Catch
+-
+-#else
+-
+-namespace Catch {
+-struct FatalConditionHandler {
+-void reset();
++//! Simple RAII guard for (dis)engaging the FatalConditionHandler
++class FatalConditionHandlerGuard {
++FatalConditionHandler* m_handler;
++public:
++FatalConditionHandlerGuard(FatalConditionHandler* handler):
++m_handler(handler) {
++m_handler->engage();
++}
++~FatalConditionHandlerGuard() {
++m_handler->disengage();
++}
+ };

Bug#985678: ITA: rasdaemon -- utility to receive RAS error tracings

[Taihsiang Ho (tai271828)]

Hi, everyone,

Even though it is slow, I still made some progress. Let me elaborate here
so you may know the current status from my side:

- The latest upstream v0.6.7 has been packaged. See my repository
https://salsa.debian.org/tai271828/rasdaemon.git forked from ahs3's
repository https://salsa.debian.org/ahs3/rasdaemon
- I packaged the upstream v0.6.7 with its release tarball
https://www.infradead.org/~mchehab/rasdaemon/rasdaemon-0.6.7.tar.bz2
- The package has not been well tested across platforms and archs. Once I
complete the test and confident that the package works properly, I will
seek for Debian developers' or maintainers' help to upload the package.

You may build the package with this command:
gbp buildpackage --git-ignore-new --git-builder=sbuild

I am very new to the whole packaging and ITA process, so I believe the
package needs a review by experts or veterans. In the meantime, if you are
interested in this work, or aware of anything that needs to do or improve.
Please let me know. I will appreciate your feedback.

Cheers,
Tai

Bug#1000239: Rescue system won't find root partition, but insists on /usr

[TomK]

This sounds correct, based on my experience with the bug. I suppose now there 
are zero ways to definitively determine which partition is actually root. So 
maybe a hidden flag (empty) file in root might do the trick. 

But the fact that /usr can be automounted, but nothing else can be manually 
mounted afterward is also a problem.   If there was a separate script to do the 
chroot part, and some manual interface by which to mount; perhaps the mount 
command in the rescue system PATH, the whole thing would be more flexible 
during the transition to ro mount for /usr in future Debian versions.

Presently it appears there will be several possibilities for the conditions of 
root and /usr, so no definite means cannot be devised to always do the correct 
thing. Even if a flag file is used to identify root, that might not be what 
rescue requires. 

In the near future I think the flag file would work, and then /usr could be 
mounted manually, as once was the case. But perhaps at some point mount would 
need to be a static binary, to account for libraries moved to /usr.

I'm not well versed on Debian policy, so just ignore my input if it makes no 
sense. If you find it irritating, it's my ignorance at work, nothing 
intentional.


 Original Message 
From: Simon McVittie 
Sent: December 4, 2021 11:42:56 AM UTC
To: Nicholas D Steeves 
Cc: 1000...@bugs.debian.org, TomK , Steve McIntyre 
, debian-rele...@lists.debian.org, 
debian-c...@lists.debian.org
Subject: Re: Bug#1000239: Rescue system won't find root partition, but insists 
on /usr

(Speaking only on my own behalf, not on behalf of the TC, here)

On Fri, 03 Dec 2021 at 16:08:24 -0500, Nicholas D Steeves wrote:
> 1. Debian isn't yet ready for usrmerge

Merged /usr is not actually the problem here, although it exacerbates what
appears to be a pre-existing bug in the rescue mode[0]. The root cause is
that since Debian 9 [1][2], the "/usr-like" parts of the root filesystem
are no longer guaranteed to be self-contained: important shared libraries[3]
and executables have been gradually moving into /usr for a while, and
stretch was the point at which this was declared to be officially allowed.

Merged /usr makes this very noticeable because it's the most extreme
version of that process, where *literally everything* "/usr-like" (most
notably /bin/sh) moves into /usr. When /usr is a separate filesystem, that
leaves a root filesystem that potentially contains only /etc, symlinks and
mount points, which is certainly not enough to be useful to chroot into.

> 2. Reassign to src:rescue, and fix the rescue system.

I think this will have to be the answer. See also [0].

> 3. Disallow configuring of a mount for "/usr"

That would be unfortunate, since one of the things enabled by merged
/usr is the ability to keep all "/usr-like" content on a separate /usr
filesystem that is mounted read-only during normal operation, remounting
it rw only for system updates[4], while leaving /etc and /var rw (and
potentially offering the ability to reformat the partition with /etc
and /var, and then repopulate it via systemd-tmpfiles or similar, as a
"factory reset" mechanism).

smcv

[0] https://bugs.debian.org/769738 (opened in 2014)
[1] 
https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#late-mounting-usr
[2] and possibly earlier: that release note was documenting current practice
rather than describing a new change
[3] for example about half the libraries in `ldd /sbin/cryptsetup`
[4] which potentially happen atomically across a reboot, as seen in ostree,
or while rebooted into a special boot mode, as with
systemd.offline-updates(7)

Bug#997363: libtorrent-rasterbar: FTBFS: configure: error: *** A compiler with support for C++17 language features is required.

[Sergio Durigan Junior]

On Saturday, December 04 2021, Petter Reinholdtsen wrote:

> [Stefano Rivera]
>> Presumably resolved in 2.0.0 in NEW, that doesn't use autoconf any more.
>
> Perhaps, but as NEW processing these days take a long time, as a user of
> the library I would prefer a fix for 1.2.14-1 in the mean time.
>
> The easiest fix seem to be to bypass the c++ standard detector which
> fail in configure.ac, causing the problematic test for C++17, while both
> C++11 and C++14 would work, by adding --with-cxx-standard=14 like this:
>
> --- rules.orig2021-12-04 07:42:25.578757615 +0100
> +++ rules 2021-12-04 07:37:18.662074573 +0100
> @@ -13,7 +13,8 @@
>  PYTHON3=$(shell py3versions -vr)
>  ALLPY=$(PYTHON3)
>  
> -CONFIGURE_ARGS = --with-libiconv 
> --with-boost-libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
> +CONFIGURE_ARGS = --with-libiconv 
> --with-boost-libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
> +  --with-cxx-standard=14
>  
>  %:
>   dh $@ --with python3
>
> It would also help a lot if the next upload is a source only upload.

Thanks for the patch, Petter.

I agree that it's a good compromise in order to make the package build
again, especially considering that version 2 is already in NEW.

I tried building libtorrent-rasterbar with your patch, but found that
there was yet another problem happening: its Jamfile wasn't working with
Python 3.10, which is already in the archive.  I went ahead and filed a
bug report, and the upstream was very quick in fixing it.

Anyway, the package builds locally now, so I'm going to take the liberty
to upload an NMU to DELAYED/5.  Andrew, feel free to remove it from the
queue if you'd like to tackle this upload yourself.

If/when the NMU is accepted, I will "gbp push" what I have locally so
that the git repo stays in sync.

Cheers,

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


signature.asc
Description: PGP signature

Bug#1001295: dominate: needs update for python3.10: 'Callable' from 'collections' is removed

[Paul Gevers]

Source: dominate
Version: 2.3.1-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

Dear maintainer(s),

With a recent upload of python3-defaults the autopkgtest of dominate 
fails in testing when that autopkgtest is run with the binary packages 
of python3-defaults from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
python3-defaults   from testing3.9.8-1
dominate   from testing2.3.1-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. 
https://docs.python.org/3.9/library/collections.html says:

"""
Deprecated since version 3.3, will be removed in version 3.10: Moved 
Collections Abstract Base Classes to the collections.abc module. For 
backwards compatibility, they continue to be visible in this module 
through Python 3.9.

"""
Time to move on.

Currently this regression is blocking the migration of python3-defaults 
to testing [1].


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dominate/17344293/log.gz

Testing with python3.10:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/dominate/__init__.py", line 4, 
in 

from .document import document
  File "/usr/lib/python3/dist-packages/dominate/document.py", line 19, 
in 

from . import tags
  File "/usr/lib/python3/dist-packages/dominate/tags.py", line 21, in 


from .dom_tag  import dom_tag, attr
  File "/usr/lib/python3/dist-packages/dominate/dom_tag.py", line 23, 
in 

from collections import defaultdict, namedtuple, Callable
ImportError: cannot import name 'Callable' from 'collections' 
(/usr/lib/python3.10/collections/__init__.py)

autopkgtest [20:14:07]: test autodep8-python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001293: libportal FTCBFS: gtkdoc-scangobj fails

[Helmut Grohne]

Source: libportal
Version: 0.4-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libportal fails to cross build from source, because running
gtkdoc-scangobj fails. It turns out that this is only needed for
building libportal-doc, so we can skip it. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru libportal-0.4/debian/changelog 
libportal-0.4/debian/changelog
--- libportal-0.4/debian/changelog  2021-09-21 18:29:00.0 +0200
+++ libportal-0.4/debian/changelog  2021-12-07 11:54:02.0 +0100
@@ -1,3 +1,10 @@
+libportal (0.4-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Don't run gtkdoc-scangobj during arch-only build. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 07 Dec 2021 11:54:02 +0100
+
 libportal (0.4-2) unstable; urgency=medium
 
   * d/p/portal-helpers-Unref-correct-object.patch:
diff --minimal -Nru libportal-0.4/debian/control libportal-0.4/debian/control
--- libportal-0.4/debian/control2021-09-21 18:29:00.0 +0200
+++ libportal-0.4/debian/control2021-12-07 11:54:02.0 +0100
@@ -6,12 +6,13 @@
  Simon McVittie ,
 Build-Depends:
  debhelper-compat (= 13),
- gtk-doc-tools,
  libglib2.0-dev (>= 2.58),
  libgstreamer-plugins-base1.0-dev ,
  libgtk-3-dev ,
  meson (>= 0.46.0),
  pkg-config,
+Build-Depends-Indep:
+ gtk-doc-tools,
 Rules-Requires-Root: no
 Standards-Version: 4.6.0
 Homepage: https://github.com/flatpak/libportal
diff --minimal -Nru libportal-0.4/debian/rules libportal-0.4/debian/rules
--- libportal-0.4/debian/rules  2021-09-21 18:29:00.0 +0200
+++ libportal-0.4/debian/rules  2021-12-07 11:53:59.0 +0100
@@ -16,6 +16,11 @@
 else
 meson_options += -Dbuild-portal-test=true
 endif
+ifeq ($(filter libportal-doc,$(built_binaries)),)
+meson_options += -Dgtk_doc=false
+else
+meson_options += -Dgtk_doc=true
+endif
 
 %:
dh $@

Bug#1001292: deepdiff: needs update for python3.10: 'Mapping' from 'collections' is removed

[Paul Gevers]

Source: deepdiff
Version: 3.3.0-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

Dear maintainer(s),

With a recent upload of python3-defaults the autopkgtest of deepdiff 
fails in testing when that autopkgtest is run with the binary packages 
of python3-defaults from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
python3-defaults   from testing3.9.8-1
deepdiff   from testing3.3.0-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. 
https://docs.python.org/3.9/library/collections.html says:

"""
Deprecated since version 3.3, will be removed in version 3.10: Moved 
Collections Abstract Base Classes to the collections.abc module. For 
backwards compatibility, they continue to be visible in this module 
through Python 3.9.

"""
Time to move on.

Currently this regression is blocking the migration of python3-defaults 
to testing [1].


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/d/deepdiff/17344291/log.gz

Testing with python3.10:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/deepdiff/__init__.py", line 7, 
in 

from .diff import DeepDiff
  File "/usr/lib/python3/dist-packages/deepdiff/diff.py", line 19, in 


from collections import Mapping
ImportError: cannot import name 'Mapping' from 'collections' 
(/usr/lib/python3.10/collections/__init__.py)

autopkgtest [20:14:06]: test autodep8-python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001291: binoculars: autopkgtest tests for all supported python3 versions but vtk7 extensions don't exist for all

[Paul Gevers]

Source: binoculars
Version: 0.0.6-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

Dear maintainer(s),

With a recent upload of python3-defaults the autopkgtest of binoculars 
fails in testing when that autopkgtest is run with the binary packages 
of python3-defaults from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
python3-defaults   from testing3.9.8-1
binoculars from testing0.0.6-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems 
you're testing for all supported Python3 version in Debian, but one of 
your dependencies doesn't provide the required extensions (bug #951300). 
Either convince the maintainer of that package to build the extensions, 
or only test with the default Python3 version.


Currently this regression is blocking the migration of python3-defaults 
to testing [1].


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/b/binoculars/17344284/log.gz

Testing with python3.10:
test_IO (test_cfg.TestCase) ... ok
test_id03 (unittest.loader._FailedTest) ... ERROR
test_metadata (unittest.loader._FailedTest) ... ERROR

==
ERROR: test_id03 (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_id03
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/vtk/vtkCommonCore.py", line 5, 
in 

from .vtkCommonCorePython import *
ModuleNotFoundError: No module named 'vtk.vtkCommonCorePython'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/loader.py", line 436, in 
_find_test_path

module = self._get_module_from_name(name)
  File "/usr/lib/python3.10/unittest/loader.py", line 377, in 
_get_module_from_name

__import__(name)
  File 
"/tmp/autopkgtest-lxc.73x5fv_7/downtmp/autopkgtest_tmp/tests/test_id03.py", 
line 1, in 

from binoculars.backends import id03
  File "/usr/lib/python3/dist-packages/binoculars/backends/id03.py", 
line 10, in 

from .. import backend, errors, util
  File "/usr/lib/python3/dist-packages/binoculars/backend.py", line 1, 
in 

from . import util, errors, dispatcher
  File "/usr/lib/python3/dist-packages/binoculars/dispatcher.py", line 
9, in 

from . import util, errors, space
  File "/usr/lib/python3/dist-packages/binoculars/space.py", line 13, 
in 

from vtk import vtkImageData, vtkXMLImageDataWriter
  File "/usr/lib/python3/dist-packages/vtk/__init__.py", line 41, in 


from .vtkCommonCore import *
  File "/usr/lib/python3/dist-packages/vtk/vtkCommonCore.py", line 9, 
in 

from vtkCommonCorePython import *
ModuleNotFoundError: No module named 'vtkCommonCorePython'


==
ERROR: test_metadata (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_metadata
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/vtk/vtkCommonCore.py", line 5, 
in 

from .vtkCommonCorePython import *
ModuleNotFoundError: No module named 'vtk.vtkCommonCorePython'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/loader.py", line 436, in 
_find_test_path

module = self._get_module_from_name(name)
  File "/usr/lib/python3.10/unittest/loader.py", line 377, in 
_get_module_from_name

__import__(name)
  File 
"/tmp/autopkgtest-lxc.73x5fv_7/downtmp/autopkgtest_tmp/tests/test_metadata.py", 
line 2, in 

import binoculars.space
  File "/usr/lib/python3/dist-packages/binoculars/space.py", line 13, 
in 

from vtk import vtkImageData, vtkXMLImageDataWriter
  File "/usr/lib/python3/dist-packages/vtk/__init__.py", line 41, in 


from .vtkCommonCore import *
  File "/usr/lib/python3/dist-packages/vtk/vtkCommonCore.py", line 9, 
in 

from vtkCommonCorePython import *
ModuleNotFoundError: No module named 'vtkCommonCorePython'


--
Ran 3 tests in 0.022s

FAILED (errors=2)
ConfigFile{
  [dispatcher]
destination = b'demo_{first}-{last}.hdf5'
overwrite = b'true'
type = b'local'
  [projection]
resolution = b'0.002, 0.002, 1'
type = b'id03:hklprojection'
  [input]
centralpixel = b'40, 255'
imagefolder = 

Bug#1001290: convertdate: autopkgtest tests for all supported python3s but fails to install them

[Paul Gevers]

Source: convertdate
Version: 2.3.2-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

Dear maintainer(s),

With a recent upload of python3-defaults the autopkgtest of convertdate 
fails in testing when that autopkgtest is run with the binary packages 
of python3-defaults from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
python3-defaults   from testing3.9.8-1
convertdatefrom testing2.3.2-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems the 
test tries to test for all supported Python3 versions, but fails to 
ensure all those versions are actually installed during the test.


Currently this regression is blocking the migration of python3-defaults 
to testing [1].


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/c/convertdate/17344289/log.gz

+ cp -r tests/ /tmp/autopkgtest-lxc.9wwlakm4/downtmp/autopkgtest_tmp
+ cd /tmp/autopkgtest-lxc.9wwlakm4/downtmp/autopkgtest_tmp/
+ export PYTHONWARNINGS=d
+ py3versions -s
+ echo --
+ echo Testing with python3.10
+ echo --
+ LC_ALL=C python3.10 -m unittest discover --verbose
/tmp/autopkgtest-lxc.9wwlakm4/downtmp/build.aU4/src/debian/tests/python3-unittest: 
11: python3.10: not found

--
Testing with python3.10
--
autopkgtest [20:13:28]: test python3-unittest



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001289: colorclass: needs update for python3.10: 'Mapping' from 'collections' is removed

[Paul Gevers]

Source: colorclass
Version: 2.2.0-2.1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python3-defaults

Dear maintainer(s),

With a recent upload of python3-defaults the autopkgtest of colorclass 
fails in testing when that autopkgtest is run with the binary packages 
of python3-defaults from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
python3-defaults   from testing3.9.8-1
colorclass from testing2.2.0-2.1
all others from testingfrom testing

I copied some of the output at the bottom of this report. 
https://docs.python.org/3.9/library/collections.html says:

"""
Deprecated since version 3.3, will be removed in version 3.10: Moved 
Collections Abstract Base Classes to the collections.abc module. For 
backwards compatibility, they continue to be visible in this module 
through Python 3.9.

"""
Time to move on.

Currently this regression is blocking the migration of python3-defaults 
to testing [1]. Of course, python3-defaults shouldn't just break your 
autopkgtest (or even worse, your package), but it seems to me that the 
change in python3-defaults was intended and your package needs to update 
to the new situation.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from python3-defaults should 
really add a versioned Breaks on the unfixed version of (one of your) 
package(s). Note: the Breaks is nice even if the issue is only in the 
autopkgtest as it helps the migration software to figure out the right 
versions to combine in the tests.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/c/colorclass/17344288/log.gz

Testing with python3.10:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/colorclass/__init__.py", line 
11, in 

from colorclass.codes import list_tags  # noqa
  File "/usr/lib/python3/dist-packages/colorclass/codes.py", line 4, in 


from collections import Mapping
ImportError: cannot import name 'Mapping' from 'collections' 
(/usr/lib/python3.10/collections/__init__.py)

autopkgtest [20:13:20]: test autodep8-python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001288: ITS: libident

[Boyuan Yang]

Source: libident
Version: 0.22-3.1
Severity: important
X-Debbugs-CC: p...@debian.org

Dear package libident maintainer in Debian,

After looking into the package you maintain (libident, 
https://tracker.debian.org/pkg/libident ), I found that this package
received no maintainer updates in the past 16 years and was not in good
shape. As a result, I am filing an ITS (Intent to Salvage) request
against your package according to section 5.12 in Debian's Developers'
Reference [1].

My current plan is to package the latest upstream release (0.32),
clean up packaging and review/fix all Debian bug reports.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(Dec 28, 2021) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#1001287: patchelf: Please consider packaging new version (0.14.3)

[Boyuan Yang]

Source: patchelf
Version: 0.12-1
Tags: sid bookworm
Severity: normal
X-Debbugs-CC: fsate...@debian.org

Dear Debian patchelf package maintainer,

As in https://github.com/NixOS/patchelf/releases , the patchelf upstream has
released new versions (up to v0.14.3). Could you please check it and have the
new version packaged in Debian?

Thanks,
Boyuan Yang


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

Bug#999665: dh_strip_nondeterminism breaks Multi-Arch: same in binNMUs

[Niels Thykier]

Chris Lamb:
> Hi Niels,
> 
>> I think it would something like this from the debhelper side:
>>
>>   https://salsa.debian.org/debian/debhelper/-/merge_requests/58
>>
>> Would that work for you? :)
> 
> Indeed it would. Would strip-nondeterminism then simply Depend on the
> version of debhelper this change gets released in? Or rather: should
> we do something more involved than that?
> 
> 
> Regards,
> 

Hi,

You can either depend on it or do a runtime check for the new function
to see if the feature is available - whatever floats your boat. :)

When you concluded the feature is available, you would then call
get_non_binnmu_date_epoch instead of get_source_date_epoch to obtain the
value for SOURCE_DATE_EPOCH.  You may want to do a
`$ENV{SOURCE_DATE_EPOCH} = get_non_binnmu_date_epoch()` depending on
whether you call third-party tools that use the variable.

Thanks,
~Niels

Bug#1001234: src:firefox-esr: fails to migrate to testing for too long: FTBFS on mipsel and unresolved RC bug

[Paul Gevers]

Hi Mike,

On 06-12-2021 23:07, Mike Hommey wrote:

The FTBFS on
mipsel is not going to go away ever. The rust compiler needs more than 2GB
of memory to compile a specific crate in Firefox, and processes on
mipsel can only get 2GB memory. The only way around that would be to
cross-compile, which Debian doesn't do as of today.  We'll have to remove
firefox-esr on mipsel.


You'd want to file a removal bug against ftp.debian.org to achieve that. 
It won't happen automagically.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#997213: i2p: FTBFS: [javac] /<>/apps/jetty/java/src/net/i2p/jetty/I2PRequestLog.java:25: error: package javax.servlet.http does not exist

[zzz]

On Mon, 6 Dec 2021 21:11:13 +0200 Adrian Bunk  wrote:

The problem is a missing build dependency on libservlet3.1-java
(this was previously hidden by libjetty9-java depending on 
libservlet3.1-java).


I haven't checked whether a runtime dependency on libservlet3.1-java is 
also missing.


cu
Adrian





Thanks Adrian, I'll fix it upstream,
unfortunately the maintainer is not responsive and i2p in Debian is 1 year and 
4 releases behind already.

Bug#997774: tensorpipe: diff for NMU version 0.0~git20210304.369e855-2.1

[Boyuan Yang]

Control: tags 997774 + patch
Control: tags 997774 + pending

Dear maintainer,

I've prepared an NMU for tensorpipe (versioned as 0.0~git20210304.369e855-2.1)
and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru tensorpipe-0.0~git20210304.369e855/debian/changelog tensorpipe-
0.0~git20210304.369e855/debian/changelog
--- tensorpipe-0.0~git20210304.369e855/debian/changelog 2021-09-01
22:19:19.0 -0400
+++ tensorpipe-0.0~git20210304.369e855/debian/changelog 2021-12-07
15:09:03.0 -0500
@@ -1,3 +1,13 @@
+tensorpipe (0.0~git20210304.369e855-2.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * debian/not-installed: Also exclude the following files from
+installation: (Closes: #997774)
++ usr/lib/*/cmake/GTest/GMockTargets-none.cmake
++ usr/lib/*/cmake/GTest/GMockTargets.cmake
+
+ -- Boyuan Yang   Tue, 07 Dec 2021 15:09:03 -0500
+
 tensorpipe (0.0~git20210304.369e855-2) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru tensorpipe-0.0~git20210304.369e855/debian/not-installed tensorpipe-
0.0~git20210304.369e855/debian/not-installed
--- tensorpipe-0.0~git20210304.369e855/debian/not-installed 2021-09-01
22:19:00.0 -0400
+++ tensorpipe-0.0~git20210304.369e855/debian/not-installed 2021-12-07
15:08:59.0 -0500
@@ -6,6 +6,8 @@
 usr/lib/*/pkgconfig/gtest_main.pc
 usr/lib/*/pkgconfig/gtest.pc
 usr/lib/*/pkgconfig/gmock.pc
+usr/lib/*/cmake/GTest/GMockTargets-none.cmake
+usr/lib/*/cmake/GTest/GMockTargets.cmake
 usr/lib/*/cmake/GTest/GTestConfig.cmake
 usr/lib/*/cmake/GTest/GTestConfigVersion.cmake
 usr/lib/*/cmake/GTest/GTestTargets.cmake


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

Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]

[Tomas Pospisek]

On 06.12.21 20:43, Noah Meyerhans wrote:

On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote:

So what's happening with chromium in both sid and stable? I saw on d-release 
that it was removed from testing (#998676 and #998732), with a  discussion 
about ending security support for it in stable.


The problem really is lack of maintenance. In my opinion, chromium deserves an active 
*team* to support it in Debian.  <...>  The security team doesn't have the 
bandwidth to do it themselves, they need a team to help them.


Sorry for a silly question, but whatʼs so wrong with the build done by 
linuxmint.com [1], so Debian needs a whole team to duplicate their effort?  
Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my 
(limited) experience.



Well, you can start with the fact that the Mint chromium source packages
don't even include the chromium source, let alone the sources for all
the other things they build (NodeJS, and more).

The biggest difficulty, as far as I can tell from my look at Chromium
from several months ago, is that our patch set [1] needs a lot of
attention with every chromium release.  Mint doesn't apply any patches
at all to the source, at least none of any real complexity.

One lesson we may take from Mint, though, is that it's not worth trying
to patch Chromium as much as we'd like.  Anything that we can do to
simplify the Chromium packaging will help us keep the package
up-to-date, which in turn will help us keep our users safer.  In my
opinion, we should be pretty aggressive about dropping as many of the
Chromium patches as possible, even if that means we link against
bundled/vendored dependencies.

Legal/licensing considerations are still important and I don't know if
we actually *can* ship builds based on the bundled stuff.  But based on
the number of patches we have to disable various things [2] or build
against system dependencies [3], I can't help but think we'd have an
easier time keeping this package fresh if we could drop some of those.

noah

1. 
https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series
2. 
https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable
3. 
https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system


I'd also like to point out, that the ungoogled-chromium project has some 
overlap in goals with Debian and it'd possibly be interessing to join 
forces:


https://github.com/ungoogled-software/ungoogled-chromium-debian

(I have been running an ungoogled-chromium for a while (ca. a year 
ago?), however at that time their chrome wasn't extremely stable so I 
gave up again. Does anybody have experience using it recently?)

*t

Bug#1001286: linux: Systems with more than 4 memory slots not supported yet, not instantiating SPD

[Сергей Фёдоров]

Source: linux
Version: 5.10.46-4
Severity: normal
X-Debbugs-Cc: serfyo...@yandex.ru

Dear Maintainer,



/var/log/messages

Dec  2 06:51:04 A1 kernel: [1.349519] i801_smbus :00:1f.3: SMBus using 
PCI interrupt
Dec  2 06:51:04 A1 kernel: [1.350413] i2c i2c-0: 8/8 memory slots populated 
(from DMI)
Dec  2 06:51:04 A1 kernel: [1.350416] i2c i2c-0: Systems with more than 4 
memory slots not supported yet, not instantiating SPD

Dec  3 05:28:15 A1 kernel: [1.322527] i801_smbus :00:1f.3: SMBus using 
PCI interrupt
Dec  3 05:28:15 A1 kernel: [1.322911] i2c i2c-0: 4/8 memory slots populated 
(from DMI)
Dec  3 05:28:15 A1 kernel: [1.322914] i2c i2c-0: Systems with more than 4 
memory slots not supported yet, not instantiating SPD

/var/log/syslog

Dec  2 22:12:57 A1 kernel: [1.341085] i801_smbus :00:1f.3: SMBus using 
PCI interrupt
Dec  2 22:12:57 A1 kernel: [1.341467] i2c i2c-0: 8/8 memory slots populated 
(from DMI)
Dec  2 22:12:57 A1 kernel: [1.341470] i2c i2c-0: Systems with more than 4 
memory slots not supported yet, not instantiating SPD

Dec  3 05:28:15 A1 kernel: [1.322527] i801_smbus :00:1f.3: SMBus using 
PCI interrupt
Dec  3 05:28:15 A1 kernel: [1.322911] i2c i2c-0: 4/8 memory slots populated 
(from DMI)
Dec  3 05:28:15 A1 kernel: [1.322914] i2c i2c-0: Systems with more than 4 
memory slots not supported yet, not instantiating SPD

/var/log/kern.log

Dec  2 22:12:57 A1 kernel: [1.341085] i801_smbus :00:1f.3: SMBus using 
PCI interrupt
Dec  2 22:12:57 A1 kernel: [1.341467] i2c i2c-0: 8/8 memory slots populated 
(from DMI)
Dec  2 22:12:57 A1 kernel: [1.341470] i2c i2c-0: Systems with more than 4 
memory slots not supported yet, not instantiating SPD

Dec  3 05:28:15 A1 kernel: [1.322527] i801_smbus :00:1f.3: SMBus using 
PCI interrupt
Dec  3 05:28:15 A1 kernel: [1.322911] i2c i2c-0: 4/8 memory slots populated 
(from DMI)
Dec  3 05:28:15 A1 kernel: [1.322914] i2c i2c-0: Systems with more than 4 
memory slots not supported yet, not instantiating SPD

Viewing log-in led to the idea that so far
Systems with more than 4 memory slots not supported yet, not instantiating SPD

Is it possible to remove this restriction for "8 memory slots"?



For memory strips:
Kingston HyperX  KHX16C10B1R/8
Kingston HyperX Fury HX316C10FRK2/16
Kingston HyperX Fury HX316C10FWK2/16

For Debian-11.1.0 64 Sid

/etc/modules-load.d/:
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# we use any of the following three to choose from
# eeprom at24 ee1004
at24
i2c_i801
i2c_smbus
i2c-dev


# i2cdetect -l

i2c-0   smbus   SMBus I801 adapter at f000  SMBus adapter
i2c-1   i2c nvkm-:01:00.0-bus-  I2C adapter
i2c-2   i2c nvkm-:01:00.0-bus-0001  I2C adapter
i2c-3   i2c nvkm-:01:00.0-bus-0002  I2C adapter

For some reason, at least one file is not created automatically in 
"/sys/bus/i2c/drivers/"
"0-0050" ... "0-0057"
 ...
"3-0050" ... "3-0057"
with a description of the memory parameters.


i2cdetect -y 0
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 08 -- -- -- -- -- -- --
10: 10 11 -- -- 14 15 -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --


# i2cdetect -y 1
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- 37 -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --


# i2cdetect -y 2
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --


# i2cdetect -y 3
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- 

Bug#1001285: bullseye-pu: package python-django/2:2.2.25-1~debu11u1

[Chris Lamb]

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

Dear stable release managers,

Please consider python-django (2:2.2.25-1~debu11u1) for bullseye:
  
  python-django (2:2.2.25-1~debu11u1) bullseye; urgency=medium
  .
* New upstream security release:
  .
  - CVE-2021-44420: Potential bypass of an upstream access control based on
URL paths.
  .
  Full details are available here:
  
  .
* Update gbp.conf for bullseye release.


The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/changelog b/debian/changelog
index 6deb982f9..85b8f98d2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+python-django (2:2.2.25-1~debu11u1) bullseye; urgency=medium
+
+  * New upstream security release:
+
+- CVE-2021-44420: Potential bypass of an upstream access control based on
+  URL paths.
+
+Full details are available here:
+
+
+  * Update gbp.conf for bullseye release.
+
+ -- Chris Lamb   Tue, 07 Dec 2021 09:29:21 -0800
+
 python-django (2:2.2.24-1) unstable; urgency=medium
 
   * New upstream security release. (Closes: #989394)
diff --git a/Django.egg-info/PKG-INFO b/Django.egg-info/PKG-INFO
index bfed6be0f..ecc68c78d 100644
--- a/Django.egg-info/PKG-INFO
+++ b/Django.egg-info/PKG-INFO
@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: Django
-Version: 2.2.24
+Version: 2.2.25
 Summary: A high-level Python Web framework that encourages rapid development 
and clean, pragmatic design.
 Home-page: https://www.djangoproject.com/
 Author: Django Software Foundation
@@ -76,5 +76,5 @@ Classifier: Topic :: Internet :: WWW/HTTP :: WSGI
 Classifier: Topic :: Software Development :: Libraries :: Application 
Frameworks
 Classifier: Topic :: Software Development :: Libraries :: Python Modules
 Requires-Python: >=3.5
-Provides-Extra: bcrypt
 Provides-Extra: argon2
+Provides-Extra: bcrypt
diff --git a/Django.egg-info/SOURCES.txt b/Django.egg-info/SOURCES.txt
index 712c72f32..7c210f1d4 100644
--- a/Django.egg-info/SOURCES.txt
+++ b/Django.egg-info/SOURCES.txt
@@ -3387,6 +3387,7 @@ docs/contents.txt
 docs/glossary.txt
 docs/index.txt
 docs/make.bat
+docs/requirements.txt
 docs/spelling_wordlist
 docs/_ext/djangodocs.py
 docs/_theme/djangodocs/genindex.html
@@ -3834,6 +3835,7 @@ docs/releases/2.2.21.txt
 docs/releases/2.2.22.txt
 docs/releases/2.2.23.txt
 docs/releases/2.2.24.txt
+docs/releases/2.2.25.txt
 docs/releases/2.2.3.txt
 docs/releases/2.2.4.txt
 docs/releases/2.2.5.txt
diff --git a/PKG-INFO b/PKG-INFO
index bfed6be0f..ecc68c78d 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: Django
-Version: 2.2.24
+Version: 2.2.25
 Summary: A high-level Python Web framework that encourages rapid development 
and clean, pragmatic design.
 Home-page: https://www.djangoproject.com/
 Author: Django Software Foundation
@@ -76,5 +76,5 @@ Classifier: Topic :: Internet :: WWW/HTTP :: WSGI
 Classifier: Topic :: Software Development :: Libraries :: Application 
Frameworks
 Classifier: Topic :: Software Development :: Libraries :: Python Modules
 Requires-Python: >=3.5
-Provides-Extra: bcrypt
 Provides-Extra: argon2
+Provides-Extra: bcrypt
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 114ce39f3..f97b5cfdf 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,6 +1,6 @@
 [DEFAULT]
 upstream-branch=upstream/2.0.x
-debian-branch=debian/sid
+debian-branch=debian/bullseye
 pristine-tar=True
 
 [pq]
diff --git a/django/__init__.py b/django/__init__.py
index 7963a360d..4fbd3665a 100644
--- a/django/__init__.py
+++ b/django/__init__.py
@@ -1,6 +1,6 @@
 from django.utils.version import get_version
 
-VERSION = (2, 2, 24, 'final', 0)
+VERSION = (2, 2, 25, 'final', 0)
 
 __version__ = get_version(VERSION)
 
diff --git a/django/urls/resolvers.py b/django/urls/resolvers.py
index 5b722474c..3f8f6c00e 100644
--- a/django/urls/resolvers.py
+++ b/django/urls/resolvers.py
@@ -147,7 +147,11 @@ class RegexPattern(CheckURLMixin):
 self.converters = {}
 
 def match(self, path):
-match = self.regex.search(path)
+match = (
+self.regex.fullmatch(path)
+if self._is_endpoint and self.regex.pattern.endswith('$')
+else self.regex.search(path)
+)
 if match:
 # If there are any named groups, use those as kwargs, ignoring
 # non-named groups. Otherwise, pass all non-named arguments as
@@ -230,7 +234,7 @@ def _route_to_regex(route, is_endpoint=False):
 converters[parameter] = converter
 parts.append('(?P<' + parameter + '>' + converter.regex + ')')
 if is_endpoint:
-parts.append('$')
+parts.append(r'\Z')
 return ''.join(parts), 

Bug#1001284: python-pysam: libhts-dev build dependency must be bumped to >= 1.14

[Adrian Bunk]

Source: python-pysam
Version: 0.18.0+ds-1~exp1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=python-pysam=amd64=0.18.0%2Bds-1~exp1=1638890599=0

...
samtools/bam_import.c.pysam.c: In function ‘import_fastq’:
samtools/bam_import.c.pysam.c:182:35: error: ‘FASTQ_OPT_NAME2’ undeclared 
(first use in this function); did you mean ‘FASTQ_OPT_RNUM’?
  182 | hts_set_opt(fp_in[i], FASTQ_OPT_NAME2, 1);
  |   ^~~
...

Bug#1001283: python3-nbconvert: nbconvert Depends: python3-mistune (<< 2)

[Drew Parsons]

Package: python3-nbconvert
Version: 6.1.0-1
Severity: serious
Justification: FTBFS
Control: affects -1 src:mistune

setup.py for nbconvert declares the requirement
'mistune>=0.8.1,<2'

The upper bound is not enforecd in the debian packaging.

In this case it actually matters.  mistune 2.0.0 has just been
uploaded, and nbconvert fails against it,
e.g. debci
https://ci.debian.net/data/autopkgtest/testing/amd64/n/nbconvert/17364189/log.gz

or using sphinx to build docs
e.g. rebuilding nbconvert:

   debian/rules override_dh_sphinxdoc
make[1]: Entering directory '/home/drew/projects/python/build/nbconvert-6.1.0'
PYTHONPATH=. python3 -m sphinx -b html docs/source 
debian/python-nbconvert-doc/usr/share/doc/python-nbconvert-doc/html
Running Sphinx v4.3.1

Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/config.py", line 329, in 
eval_config_file
exec(code, namespace)
  File "/projects/python/build/nbconvert-6.1.0/docs/source/conf.py", line 25, 
in 
exec(compile(f.read(), 'autogen_config.py', 'exec'), {})
  File "autogen_config.py", line 11, in 
  File "/projects/python/build/nbconvert-6.1.0/nbconvert/__init__.py", line 4, 
in 
from .exporters import *
  File 
"/projects/python/build/nbconvert-6.1.0/nbconvert/exporters/__init__.py", line 
3, in 
from .html import HTMLExporter
  File "/projects/python/build/nbconvert-6.1.0/nbconvert/exporters/html.py", 
line 18, in 
from nbconvert.filters.highlight import Highlight2HTML
  File "/projects/python/build/nbconvert-6.1.0/nbconvert/filters/__init__.py", 
line 6, in 
from .markdown import *
  File "/projects/python/build/nbconvert-6.1.0/nbconvert/filters/markdown.py", 
line 13, in 
from .markdown_mistune import markdown2html_mistune
  File 
"/projects/python/build/nbconvert-6.1.0/nbconvert/filters/markdown_mistune.py", 
line 31, in 
class MathBlockGrammar(mistune.BlockGrammar):
AttributeError: module 'mistune' has no attribute 'BlockGrammar'

make[1]: *** [debian/rules:26: override_dh_sphinxdoc] Error 2


So nbconvert FTBFS.
Marking Severity: serious for that reason.




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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 python3-nbconvert depends on:
ii  python3  3.9.8-1
ii  python3-bleach   4.1.0-1
ii  python3-defusedxml   0.7.1-1
ii  python3-entrypoints  0.3-9
ii  python3-jinja2   3.0.1-2
ii  python3-jupyter-core 4.9.1-1
ii  python3-jupyterlab-pygments  0.1.2-7
ii  python3-mistune  2.0.0-1
ii  python3-nbclient 0.5.6-2
ii  python3-nbformat 5.1.3-1
ii  python3-pandocfilters1.5.0-1
ii  python3-pygments 2.7.1+dfsg-2.1
ii  python3-testpath 0.5.0+dfsg-1
ii  python3-traitlets5.1.1-1

Versions of packages python3-nbconvert recommends:
ii  pandoc  2.9.2.1-1+b2
ii  python3-jupyter-client  7.1.0-1

Versions of packages python3-nbconvert suggests:
pn  python-nbconvert-doc   
ii  texlive-fonts-recommended  2021.20211127-1
ii  texlive-plain-generic  2021.20211127-1
ii  texlive-xetex  2021.20211127-1

-- no debconf information

Bug#1001282: samtools: libhts-dev build dependency must be bumped to >= 1.14

[Adrian Bunk]

Source: samtools
Version: 1.14-1~exp1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=samtools=amd64=1.14-1~exp1=1638890648=0

...
bam_plcmd.c: In function ‘pileup_seq’:
bam_plcmd.c:75:5: error: unknown type name ‘hts_base_mod_state’
   75 | hts_base_mod_state *m = p->cd.p;
  | ^~
...

Bug#1001281: flawfinder: Source-only upload needed

[Boyuan Yang]

Source: flawfinder
Version: 2.0.19-1
Severity: important
X-Debbugs-CC: j...@debian.org

Hi Javier,

Thanks for updating package flawfinder in Debian! However, the latest upload
was not a source-only upload and its testing migration will be blocked. Can
you upload a new version with source-only upload as described in
https://wiki.debian.org/SourceOnlyUpload ?

Thanks,
Boyuan Yang


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

Bug#1001280: buster-pu: package publicsuffix/20211207.1025-0+deb10u1

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@fifthhorseman.net
Control: affects -1 src:publicsuffix

Please consider an update to publicsuffix in debian buster.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the previous version in buster is attached.

This proposed release is also available at the
"publicsuffix_debian/20211207.1025-0+deb10u1" tag on the "debian/buster" branch 
at
the git repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to buster.


publicsuffix_20211109.1735-0+deb10u1_20211207.1025-0+deb10u1.debdiff.gz
Description: application/gzip

Bug#1001279: bullseye-pu: package publicsuffix/20211207.1025-0+deb11u1

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@fifthhorseman.net
Control: affects -1 src:publicsuffix

Please consider an update to publicsuffix in debian bullseye.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the previous version in bullseye is attached.

This proposed release is also available at the
"publicsuffix_debian/20211207.1025-0+deb11u1" tag on the "debian/bullseye" 
branch at
the git repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to bullseye.


publicsuffix_20211109.1735-0+deb11u1_20211207.1025-0+deb11u1.debdiff.gz
Description: application/gzip

Bug#1001009: Downloads external files on install

[Tong Sun]

Control: tags -1 - moreinfo + pending
thanks

This should fix it
https://salsa.debian.org/debian/dbab/-/commit/4cd8db27cec918244a9fba3d698a7b0123c9f3f9

and the bug will be closed after a new release.


On Tue, Dec 7, 2021 at 10:57 AM Andrey Rahmatullin  wrote:
>
> On Sun, Dec 05, 2021 at 09:56:02AM -0500, Tong Sun wrote:
> > Thanks Andrey,
> >
> > Two questions,
> >
> > By "moved to contrib", did you meant to change
> >
> > Section: net
> >
> > to
> >
> > Section: contrib
> >
> > in d/control?
> Please read
> https://www.debian.org/doc/debian-policy/ch-archive.html#archive-areas and
> https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
>
> > Now, let's define what "package cannot function" actually means. If
> > functions normally without this or similar unpackaged file, but the
> > program is completely data driven, i.e., no ads sites from the list
> > are blocked unless the list is there.
> >
> > So, strictly speaking, the package indeed cannot function without this
> > or similar unpackaged file, right? And the solution is just above,
> > right?
> I don't know the current project consensus on this, if it exists.
> If the software can only work with certain non-free files it should go
> into contrib, if OTOH it can work with some user-provided files, or with
> free files if those exist, it can stay in main. But downloading external
> files in postinst is certainly not fit for main.
>
> --
> WBR, wRAR

Bug#1000792: gnuradio: unsatisfiable Build-Depends(-Arch) on s390x: libunwind-dev

[Steve Langasek]

Package: gnuradio
Followup-For: Bug #1000792
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
Control: tags -1 patch

Hello,

libunwind-dev also does not exist on riscv64.

In Ubuntu, I've applied the attached patch to skip the libunwind-dev
build-dependency on these two architectures, to not regress architecture
support for gnuradio.  I've confirmed the package builds without
libunwind-dev.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gnuradio-3.9.4.0/debian/control gnuradio-3.9.4.0/debian/control
--- gnuradio-3.9.4.0/debian/control 2021-11-27 09:02:04.0 -0800
+++ gnuradio-3.9.4.0/debian/control 2021-12-07 07:26:17.0 -0800
@@ -35,7 +35,7 @@
   libsoapysdr-dev,
   libthrift-dev (>= 0.13.0-5) [amd64 arm64 armel armhf i386],
libuhd-dev (>= 4),
-  libunwind-dev,
+  libunwind-dev [!riscv64 !s390x],
libusb-1.0-0-dev [!kfreebsd-any],
libusb2-dev [kfreebsd-any],
   libvolk2-dev,

Bug#998206: calendar: cronjob processes all users’ calendars as root, allowing information disclosure

[Michael Meskes]

> As
> I understand it, this is the POSIX way. Anyway, I'm going to prepare
> a
> patch.

I did some more testing and it seems this simple patch fixes the issue:

--- calendar.c  2021-12-07 17:53:16.044315761 +0100
+++ calendar.c  2021-12-07 08:59:20.293726904 +0100
@@ -190,6 +190,8 @@
case 0: /* child */
(void)setpgid(getpid(), getpid());
(void)setlocale(LC_ALL, "");
+   if (setgid(pw->pw_gid) != 0 ||
setuid(pw->pw_uid) != 0)
+   err(1, "unable to switch to
user %u group %u", pw->pw_uid, pw->pw_gid);
if (acstat) {
if (chdir(pw->pw_dir) ||
stat(calendarFile, )
!= 0 ||

Any comments?

@security team: Do you want me to prepare a fix for stable, too?

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org

Bug#995769: dbab: v1.5.7 package fail to upgrade from bullseye (1.5.01-1)

[Tong Sun]

Control: tags -1 help
thanks

I tried but got problems after problems...

On Sun, Nov 28, 2021 at 1:51 PM Boyuan Yang  wrote:
>
> Hi,
>
> Getting package autoremoved from testing is not end-of-the-world -- once the
> bug is fixed, it can get back to Debian Testing at any time. Meanwhile, the
> previous bug is real and will need to be fixed sooner or later.
>
> I may get back to look into the bug later, bug I don't have enough time
> recently. Feel free to find help from others, or I may get involved when I
> have enough time.
>
> Thanks,
> Boyuan Yang
>
>
> 在 2021-11-28星期日的 11:35 -0500，Tong Sun写道：
> > Hi Boyuan, please please help.
> >
> > -- Forwarded message -
> > From: Tong Sun 
> > Date: Sun, Nov 28, 2021 at 11:33 AM
> > Subject: Re: Bug#995769: dbab: v1.5.7 package fail to upgrade from
> > bullseye (1.5.01-1)
> > To: Boyuan Yang , <995...@bugs.debian.org>
> >
> >
> > To Boyuan, or any mentors reading this issue.
> >
> > I've been trying to fix it myself, but all my previous attempts
> > failed, because I don't understand what breaks and why, from the
> > output of the package upgrade log.
> >
> > I've sent a help request to debian-mentors a few days ago, but nobody
> > answers yet.
> >
> > My package is now marked for autoremoval from testing, with a wrong
> > reason, and I don't know how to stop my package being autoremed from
> > testing, and I got no answers/help on that either.
> >
> > Since I don't know how to fix it myself, and all my previous attempts
> > failed, if nobody helps me by next weekend, I'll do the only thing
> > that I know -- to change the severity of this bug to minor, because
> > there is a simple solution to it as explained below. This will solve
> > everything and win me the time it takes for me to do further
> > investigation/testing.
> >
> > Really hope it won't be the case.
> > Somebody help please.
> > Thanks
> >
> > On Thu, Oct 7, 2021 at 9:31 PM Tong Sun wrote:
> > >
> > > On Tue, Oct 5, 2021 at 7:27 AM Boyuan Yang  wrote:
> > >
> > > > Package dbab/1.5.7-1 has broken maintscript and cannot be properly
> > > > upgraded
> > > > from dbab/1.5.01-1 to dbab/1.5.7-1:
> > >
> > > Thanks for reporting. I'll try to fix it ASAP.
> > >
> > > In the meantime, for anyone who doesn't want to wait for the fix to be
> > > published --
> > > do not do an upgrade -- remove the package completely, then do a fresh
> > > install.
> > >
> > > thx
>

Bug#983679: searx: Extraneous /searx/ added to URL

[Johannes Schauer Marin Rodrigues]

Hi Alex,

Quoting Alex Dekker (2021-02-28 12:09:55)
> It appears that Searx is adding an extra /searx/ to its own URLs.
> My setup is:
> - Apache hosting my domain example.org and proxying Searx to 
> example.org/searx/
> - uwsgi hosting Searx.
> 
> Accessing example.org/searx, I see logs of 404s in the UWSGI log file:
> 
> [pid: 1844588|app: 0|req: 59/139] ::1 () {50 vars in 1319 bytes} [Sun Feb 28 
> 10:45:14 2021] GET /searx/ => generated 11037 bytes in 5 msecs (HTTP/1.1 200) 
> 3 headers in 114 bytes (1 switches on core 0)
> [pid: 1844588|app: 0|req: 60/140] ::1 () {48 vars in 1357 bytes} [Sun Feb 28 
> 10:45:14 2021] GET /searx/searx/static/js/jquery-1.11.1.min.js => generated 
> 3673 bytes in 7 msecs (HTTP/1.1 404) 3 headers in 120 bytes (1 switches on 
> core 0)
> [pid: 1844590|app: 0|req: 23/141] ::1 () {48 vars in 1356 bytes} [Sun Feb 28 
> 10:45:14 2021] GET /searx/searx/static/css/leaflet.min.css => generated 3673 
> bytes in 7 msecs (HTTP/1.1 404) 3 headers in 120 bytes (1 switches on core 0)
> [pid: 1844589|app: 0|req: 37/142] ::1 () {48 vars in 1341 bytes} [Sun Feb 28 
> 10:45:14 2021] GET /searx/searx/static/js/bootstrap.min.js => generated 3673 
> bytes in 4 msecs (HTTP/1.1 404) 3 headers in 120 bytes (2 switches on core 0)
> [pid: 1844591|app: 0|req: 23/143] ::1 () {48 vars in 1416 bytes} [Sun Feb 28 
> 10:45:14 2021] GET /searx/searx/static/themes/oscar/css/logicodev.min.css => 
> generated 3673 bytes in 4 msecs (HTTP/1.1 404) 3 headers in 120 bytes (2 
> switches on core 0)
> [pid: 1844589|app: 0|req: 38/144] ::1 () {48 vars in 1364 bytes} [Sun Feb 28 
> 10:45:14 2021] GET /searx/searx/static/css/bootstrap.min.css => generated 
> 3673 bytes in 8 msecs (HTTP/1.1 404) 3 headers in 120 bytes (1 switches on 
> core 0)
> 
> Obviously this leads to a rather odd looking results page as all the extra 
> elements cannot be loaded.
> I have found a workaround: change 
> 
> base_url : "https://example.org/searx;
> to
> base_url : "https://example.org/;
> 
> This seems intuitively wrong to me but it works!
> 
> I think this issue began after upgrading to 0.18. I am not 100% certain here 
> as I have not used Searx for a while because it has been choking on Google 
> results. I try it every now and then to see if it's started working again.

I only tested searx with nginx:

https://sources.debian.org/src/searx/0.18.0+dfsg1-1/debian/tests/general/

If you can show me how you set up your apache, then I can add a second test
that might be able to reproduce your problem.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.13-0+deb11u1

[Otto Kekäläinen]

> When we were faced with a similar situation for 10.3 last year, we
> decided to proceed anyway as 10.5 was about to become the default
> version and 10.3 was then removed from unstable shortly afterwards.

True

> Looking at the current status of the 10.6 packages in unstable, it
> doesn't seem like we're in the same situation - there are build
> failures on multiple architectures, for instance, and no packages in
> testing yet. As such, I'm trying to gauge the likely timescales
> involved, so that we can make the best decision for our users.

There isn't currently any active contributors to 10.6 in Debian and I
am changing apartments this week so I might not have time to address
everything quickly. Time scale for 10.6 getting into Debian testing is
probably several weeks.

Bug#1001278: RFP: waydroid -- Run a full Android system on Wayland using a container

[Federico Ceratto]

Package: wnpp
Severity: wishlist

* Package name: waydroid
  Version : 1.2.0
  Upstream Author : Erfan Abdi and others
* URL : https://waydro.id/
* License : GPL-3.0
  Programming Lang: Python
  Description : Run a full Android system on Wayland using a container

Waydroid uses Linux namespaces (user, pid, uts, net, mount, ipc) to run a full 
Android system in a container and provide Android applications.
The Android system inside the container has direct access to any needed 
hardware.
The Android runtime environment ships with a minimal customized Android system 
image based on LineageOS. The image is currently based on Android 10.

Waydroid can be useful on desktops and laptops but also on Debian/Mobian based 
smartphones like PinePhone.

Bug#962208: fix ftbfs with glibc 2.31

[Andreas Beckmann]

Control: tag -1 - bullseye

On Thu, 4 Jun 2020 16:40:47 +0200 Matthias Klose  wrote:

fix ftbfs with glibc 2.31. patch at


I cannot reproduce the FTBFS in bullseye (but in bookworm). Tagging 
accordingly.


Andreas

Bug#994948: searx: Can not connect to searx by nginx with searx.ini from /usr/share/doc/searx/examples/uwsgi..

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + unreproducible moreinfo

Hi Sven,

Quoting Sven Wagner (2021-09-23 18:54:15)
> I installed searx and used for Nginx and UWSGI the examples from 
> /usr/share/doc/searx/examples
> When trying to reach my instance with my browser, I got 502 Bad Gateway.
> To solve this, I had to do two things, first I had to 
> apt install uwsgi-plugin-python3
> I do not know, maybe this package should be installed with searx.

not by default, no. But I'll add uwsgi-plugin-python3 to the Suggests.

> Than I had to add to change in /etc/uwsgi/apps-available/searx.ini
> The following line:
> plugin = python3
> to
> plugins = python3
> Maybe this can be changed directely in:
> /usr/share/doc/searx/examples/uwsgi/apps-available/searx.ini

I cannot reproduce your finding. Firstly, the uwsgi documentation states that
both "plugins" as well as "plugin" is supported. Please point out where it says
that "plugin" is wrong.

Secondly, the autopkgtest of searx tests the same setup you have:

https://sources.debian.org/src/searx/0.18.0+dfsg1-1/debian/tests/general/

But the job is green everywhere:

https://ci.debian.net/packages/s/searx/

So I need more information before I can do anything about this.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1001277: cwltool: please make the build reproducible

[Chris Lamb]

Source: cwltool
Version: 3.1.20211104071347-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
cwltool could not be built reproducibly.

This is because a file generated during the tests can end up in the
binary package with one of two potential contents, specifically:

│ │ │ ├── ./usr/lib/python3.10/dist-packages/out
│ │ │ │ @@ -1 +1 @@
│ │ │ │ -override
│ │ │ │ +override_super

Patch attached that deletes this [test-related] file, which probably
shouldn't be shipped under dist-packages/ anyway.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2021-12-07 07:32:20.637508004 -0800
--- b/debian/rules  2021-12-07 07:55:24.372821248 -0800
@@ -36,4 +36,5 @@
cd {build_dir}; export PYTHONPATH=$$(pwd); {interpreter} -m pytest \
-k 'not (test_http_path_mapping or test_pack or 
test_get_subgraph or test_use_metadata or test_load_graph_fragment_from_packed 
or test_udocker_usage_should_not_write_cid_file or 
test_udocker_should_display_memory_usage or test_content_types or 
test_get_step)' \
-n auto --ignore cwltool/schemas/ -rs --pyargs cwltool" 
dh_auto_test
+   find .pybuild -name "out" -type f -delete
 endif

Bug#1001188: zoneminder: 'Probe ONVIF' fail with Firefox and Chromium

[Petter Reinholdtsen]

Based on an advice from Dmitry, I tried to disable the "Enhanced
Tracking Protection" feature in Firefox, using the switch available
under the shield icon next to the URL, and with the feature disabled I
could use Firefox to add a ONVIF camera. :)

--
Happy hacking
Petter Reinholdtsen

Bug#1001009: Downloads external files on install

[Andrey Rahmatullin]

On Sun, Dec 05, 2021 at 09:56:02AM -0500, Tong Sun wrote:
> Thanks Andrey,
> 
> Two questions,
> 
> By "moved to contrib", did you meant to change
> 
> Section: net
> 
> to
> 
> Section: contrib
> 
> in d/control?
Please read
https://www.debian.org/doc/debian-policy/ch-archive.html#archive-areas and
https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections

> Now, let's define what "package cannot function" actually means. If
> functions normally without this or similar unpackaged file, but the
> program is completely data driven, i.e., no ads sites from the list
> are blocked unless the list is there.
> 
> So, strictly speaking, the package indeed cannot function without this
> or similar unpackaged file, right? And the solution is just above,
> right?
I don't know the current project consensus on this, if it exists.
If the software can only work with certain non-free files it should go
into contrib, if OTOH it can work with some user-provided files, or with
free files if those exist, it can stay in main. But downloading external
files in postinst is certainly not fit for main.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.13-0+deb11u1

[Adam D. Barratt]

Hi,

On Mon, 2021-12-06 at 11:39 -0800, Otto Kekäläinen wrote:
> MariaDB 10.6.5 has been uploaded to Sid and will replace 10.5 as soon
> as it has the initial bugs weeded out and is same or better overall
> quality as 10.5.

I saw the 10.6 uploads, but I'm afraid that doesn't directly address
the concern.

With 10.5 still being the default in unstable, if we only release
10.5.13 via the point release then users of Debian's default
MySQL/MariaDB package in unstable and testing do not benefit from the
updates included in it, including the fixes for CVE-2021-35604.

When we were faced with a similar situation for 10.3 last year, we
decided to proceed anyway as 10.5 was about to become the default
version and 10.3 was then removed from unstable shortly afterwards.

Looking at the current status of the 10.6 packages in unstable, it
doesn't seem like we're in the same situation - there are build
failures on multiple architectures, for instance, and no packages in
testing yet. As such, I'm trying to gauge the likely timescales
involved, so that we can make the best decision for our users.

Regards,

Adam

Bug#992613: buster-pu: package icu/63.1-6+deb10u2

[GCS]

On Sat, Dec 4, 2021 at 6:40 PM Adam D. Barratt  wrote:
> Control: tags -1 + confirmed
>
> On Sat, 2021-08-21 at 09:10 +0200, László Böszörményi wrote:
> > ICU had a non-standard tool for revealing its headers and libs paths,
> > compiler switches needed for development. This tool, icu-config, was
> > removed after being deprecated over pkg-config for years.
>
> Please go ahead, thanks.
 Uploaded. Please note, there was a security upload after I've filed
this PU. Thus the changes were made on top of that, resulting
63.1-6+deb10u3 as the new package revision. But no other change was
made.

Regards,
Laszlo/GCS

Bug#1001276: ctfutils: library conflict on libctf.so.0 with libctf0

[Jessica Clarke]

Control: reassign -1 binutils
Control: retitle -1 binutils: Hijacks libctf library name on (k)FreeBSD

On 7 Dec 2021, at 15:25, Jessica Clarke  wrote:
> 
> On 7 Dec 2021, at 15:09, Andreas Beckmann  wrote:
>> 
>> Package: ctfutils
>> Version: 10.3~svn297264-2
>> Severity: serious
>> 
>> Hi,
>> 
>> there is a (potential) library conflict:
>> 
>> ctfutils (src:ctfutils): /usr/lib/libctf.so.0
>> libctf0 (src:binutils):  /usr/lib/$DEB_HOST_MULTIARCH/libctf.so.0
>> 
>> I don't know if the libraries could be used as replacements of each
>> other, but if both packages are installed, only one of libraries will
>> be used to resolve dependencies of other shared libraries or binaries.
> 
> *sigh* What is the plan for building binutils on real FreeBSD? Because
> that has a libctf (albeit, now at .2) in the base system that will
> conflict. Is this just a GNU-written replacement we should disable in
> binutils on kfreebsd-*? Presumably that’s what they do on FreeBSD…

Regardless, this is binutils’s bug, it can’t just hijack libraries,
especially those that are OS-provided system libraries like libctf.

Jess

Bug#1001276: ctfutils: library conflict on libctf.so.0 with libctf0

[Jessica Clarke]

On 7 Dec 2021, at 15:09, Andreas Beckmann  wrote:
> 
> Package: ctfutils
> Version: 10.3~svn297264-2
> Severity: serious
> 
> Hi,
> 
> there is a (potential) library conflict:
> 
> ctfutils (src:ctfutils):  /usr/lib/libctf.so.0
> libctf0 (src:binutils):   /usr/lib/$DEB_HOST_MULTIARCH/libctf.so.0
> 
> I don't know if the libraries could be used as replacements of each
> other, but if both packages are installed, only one of libraries will
> be used to resolve dependencies of other shared libraries or binaries.

*sigh* What is the plan for building binutils on real FreeBSD? Because
that has a libctf (albeit, now at .2) in the base system that will
conflict. Is this just a GNU-written replacement we should disable in
binutils on kfreebsd-*? Presumably that’s what they do on FreeBSD...

Jess

Bug#1001276: ctfutils: library conflict on libctf.so.0 with libctf0

[Andreas Beckmann]

Package: ctfutils
Version: 10.3~svn297264-2
Severity: serious

Hi,

there is a (potential) library conflict:

ctfutils (src:ctfutils):/usr/lib/libctf.so.0
libctf0 (src:binutils): /usr/lib/$DEB_HOST_MULTIARCH/libctf.so.0

I don't know if the libraries could be used as replacements of each
other, but if both packages are installed, only one of libraries will
be used to resolve dependencies of other shared libraries or binaries.


Andreas

Bug#953740: Please package new upstream release of fonts-cantarell

[Fabian Greffrath]

PS: Related upstream request here

https://gitlab.gnome.org/GNOME/cantarell-fonts/-/issues/55

 - Fabian

Bug#953740: Please package new upstream release of fonts-cantarell

[Fabian Greffrath]

Gentlemen,

Am 03.12.2021 14:09, schrieb Fabian Greffrath:

That'd be it, then. ;)


I have uploaded a package to experimental [*] in which I applied the two 
"tricks" I outlined before. I have not experienced any issues with Gnome 
Shell, Gnome Control Center or any other Gnome app, yet. Please install 
the package and give it a try yourself.


[*] Because we are tracking GNOME releases in debian/watch, but I have 
packaged a font release which is not part of a GNOME release, yet. The 
optional building of either the static fonts or the variable font has 
just been introduced in Cantarell 0.302, whereas GNOME still has 0.301 
on its servers. Also, because I have disabled an overlay removal 
algorithm which upstream has explicitly chosen and fall back to the 
default one instead.


Thanks!

 - Fabian

Bug#892058: Your Debian key is expiring

[Bernd Zeimetz]

On Sun, 2021-12-05 at 05:36 -0800, felix.lech...@lease-up.com wrote:


> If you like this service, please leave a favorable comment here [2].


Very useful service, thanks for providing it!


Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#842441: m17n-lib FTCBFS: uses build architecture pkg-config

[Boyuan Yang]

Hi,

On Mon, 29 Nov 2021 22:46:08 +0100 Harshula  wrote:
> Hi Helmut,
> 
> Great, thanks for that! So, replace all instances of pkg-config calls 
> with $PKG_CONFIG calls to ensure the cross-build environment's 
> pkg-config executable is run.
> 
> Should deprecating pkg-config calls go into debian-policy and/or 
> lintian? I noticed that a more specific issue you reported got turned 
> into 
>
https://lintian.debian.org/tags/autotools-pkg-config-macro-not-cross-compilation-safe
 
> .
> 
> 
> Hi Boyuan,
> 
> Thoughts?

I just took a look, and in general I agree with
https://bugs.debian.org/842441#57 . Upstream may not be aware of cross-
compilation issues when drafting the build system scripts. Probably this patch
can be contributed back to upstream.

Thanks,
Boyuan


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

Bug#1001275: ITP: obs-downstream-keyer -- plugin for OBS Studio that adds a Downstream Keyer (DSK) dock

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, exel...@hotmail.com

* Package name: obs-downstream-keyer
  Version : 0.2.1
  Upstream Author : Exeldro 
* URL : 
https://obsproject.com/forum/resources/downstream-keyer.1254/
* License : GPL-2
  Programming Lang: C++
  Description : plugin for OBS Studio that adds a Downstream Keyer (DSK) 
dock

 This plugin allows OBS to create overlays. Overlays are objects over a scene.
 Changing this scene will keep the overlay. This resource can be used to show
 logos, news or to show chat comments in live streams (there are some tutorials
 in the Internet to learn about the integration between this plugin and web
 browsers).

Bug#1001274: scowl source has (probably outdated?) problematic license conditions

[Gernot Hillier]

Source: scowl
Version: 2019.10.06-1

During licensing checks of the "scowl" sources, we identified two 
problematic files. r/pos/README-orig as well as r/mwords/README. Both say:


[...]
This documentation, software and/or database was developed
and copyrighted by Grady Ward and is licensed, not sold, to
you on a non-exclusive, non-transferable basis. The documentation,
software and/or database and derivative works of this database
may not be copied in whole or part except for archival purposes
as provided by law.
[...]

The Debian copyright however cites from r/pos/README that "The MWords 
package was explicitly placed in the public domain". To me at least, 
it's unclear whether the both READMEs were considered and if yes, it 
would really help to add some clarifying statements in copyright why the 
licensing terms in the (old?) README files don't apply (any more?).


I also reported an upstream bug at 
https://github.com/en-wl/wordlist/issues/333.

Bug#1001245: weechat: FTBS against Ruby 3.0

[Lucas Kanashiro]

Hi,

Em 07/12/2021 09:07, Sébastien Helleu escreveu:

Hi,

If this patch is applied, other commits should be used as well: they fix issues
on macOS and detection with autotools, but not sure then if they are mandatory
for the Debian package.

Commits:

* Fix compilation with Ruby 3.0 on macOS:
   
https://github.com/weechat/weechat/commit/27a480c7d7cc897ec1228f25d97bbfeb0f52dca3

* Fix detection of Ruby 3.0 on macOS:
   
https://github.com/weechat/weechat/commit/be753046b729dab518c390cbf9be6360310fc65a

* Add detection of Ruby 3.0 in autotools:
   
https://github.com/weechat/weechat/commit/aed64f5020f63a37413da29367734b066fdaf235


I tested it applying only this commit:

https://github.com/weechat/weechat/commit/fe9768f484304c28cf

I removed the Changelog addition to make it apply cleanly. That was what 
I needed to make it work with Ruby 3.0. If you believe you need more 
than that please go ahead, my goal is to make it support the new ruby 
version.


Cheers!

--

Lucas Kanashiro

Bug#1001273: gcc-avr,gcc-sh-elf: both ship /usr/lib/libcc1.so*

[Andreas Beckmann]

Package: gcc-avr,gcc-sh-elf
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite
Control: found -1 1:5.4.0+Atmel3.6.2-2
Control: found -1 11.2.0-12+1

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:

  Preparing to unpack .../gcc-sh-elf_11.2.0-12+1_amd64.deb ...
  Unpacking gcc-sh-elf (11.2.0-12+1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/gcc-sh-elf_11.2.0-12+1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/libcc1.so.0.0.0', which is also in package 
gcc-avr 1:5.4.0+Atmel3.6.2-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/gcc-sh-elf_11.2.0-12+1_amd64.deb

This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/lib/libcc1.so
  /usr/lib/libcc1.so.0
  /usr/lib/libcc1.so.0.0.0

But, maybe even worse, there is also libcc1-0 shipping

  /usr/lib//libcc1.so.0
  /usr/lib//libcc1.so.0.0.0

This bug is assigned to both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may
also register in the BTS that the other package is affected by the bug.

Cheers,

Andreas

PS: for more information about the detection of file overwrite errors
of this kind see https://qa.debian.org/dose/file-overwrites.html


gcc-avr=1:5.4.0+Atmel3.6.2-2_gcc-sh-elf=11.2.0-12+1.log.gz
Description: application/gzip

Bug#995587: transition: ruby3.0-add

[Antonio Terceiro]

Hi,

On Sat, 2 Oct 2021 15:14:39 -0300 Antonio Terceiro  wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> We would like to add support for ruby3.0 in ruby-defaults.

This can now be closed. There are 4 unfixed packages in the tracker, but
they are all out of testing. Some of them probably need to be removed
from the archive entirely, but we will look at them later and give
someone who cares a chance to fix them before that.


signature.asc
Description: PGP signature

Bug#1001267: php7.4-imap: starttls is unable to connect with imap servers which support only TLS 1.2 and TLS 1.3

[Ondřej Surý]

Control: reassign -1 libc-client2007e
Control: affects -1 php7.4-imap php8.0-imap

Well, you said it yourself - it’s libc-client problem, not php7.4-imap problem.

--
Ondřej Surý  (He/Him)

> On 7. 12. 2021, at 11:27, Falk Hackenberger  wrote:
> 
> Package: php7.4-imap
> Version: 7.4.25-1+deb11u1
> Severity: normal
> 
> Dear Maintainer,
> 
> I try to use php7.4-imap to connect with a imap server which supports only 
> starttls over port 143 and supports only TLS 1.2 or newer.
> php -r '$user="username";$pass="Password";$mbox=imap_open( 
> "{server.example.com:143/imap/tls/novalidate-cert}", $user, $pass, 
> OP_DEBUG);echo ($mbox !== false)?"OK":imap_last_error();'
> This fails with:
> "PHP Warning:  imap_open(): Couldn't open stream" und "TLS/SSL failure for 
> server.example.com: SSL negotiation failed". 
> 
> According to [1], the reason is the old libc-client2007e, which can not 
> handle newer TLS Versions on startttls.
> 
> [1] https://bugs.php.net/bug.php?id=76928
> 
> -- Package-specific info:
>  Additional PHP 7.4 information 
> 
>  PHP @PHP_VERSION SAPI (php7.4query -S): 
> 
>  PHP 7.4 Extensions (php7.4query -M -v): 
> 
>  Configuration files: 
>  /etc/php/7.4/mods-available/imap.ini 
> extension=imap.so
> 
> 
> -- System Information:
> Debian Release: 11.1
>  APT prefers stable-updates
>  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages php7.4-imap depends on:
> ii  libc-client2007e  8:2007f~dfsg-7+b1
> ii  libc6 2.31-13+deb11u2
> ii  php-common2:76
> ii  php7.4-common 7.4.25-1+deb11u1
> ii  ucf   3.0043
> 
> php7.4-imap recommends no packages.
> 
> php7.4-imap suggests no packages.
> 
> Versions of packages php7.4-common depends on:
> ii  libc6   2.31-13+deb11u2
> ii  libffi7 3.3-6
> ii  libssl1.1   1.1.1k-1+deb11u1
> ii  php-common  2:76
> ii  ucf 3.0043
> 
> Versions of packages php7.4-cli depends on:
> ii  libargon2-1  0~20190702-0.1+0~20190710.3+debian9~1.gbp2fb167
> ii  libc62.31-13+deb11u2
> ii  libedit2 3.1-20191231-2+b1
> ii  libmagic11:5.39-3
> ii  libpcre2-8-0 10.36-2
> ii  libsodium23  1.0.18-1
> ii  libssl1.11.1.1k-1+deb11u1
> ii  libxml2  2.9.10+dfsg-6.7
> ii  mime-support 3.66
> ii  php7.4-common7.4.25-1+deb11u1
> ii  php7.4-json  7.4.25-1+deb11u1
> ii  php7.4-opcache   7.4.25-1+deb11u1
> ii  php7.4-readline  7.4.25-1+deb11u1
> ii  tzdata   2021a-1+deb11u2
> ii  ucf  3.0043
> ii  zlib1g   1:1.2.11.dfsg-2
> 
> Versions of packages php7.4-cli suggests:
> pn  php-pear  
> 
> Versions of packages php7.4-fpm depends on:
> ii  libacl1 2.2.53-10
> ii  libapparmor12.13.6-10
> ii  libargon2-1 0~20190702-0.1+0~20190710.3+debian9~1.gbp2fb167
> ii  libc6   2.31-13+deb11u2
> ii  libmagic1   1:5.39-3
> ii  libpcre2-8-010.36-2
> ii  libsodium23 1.0.18-1
> ii  libssl1.1   1.1.1k-1+deb11u1
> ii  libsystemd0 247.3-6
> ii  libxml2 2.9.10+dfsg-6.7
> ii  mime-support3.66
> ii  php7.4-cli  7.4.25-1+deb11u1
> ii  php7.4-common   7.4.25-1+deb11u1
> ii  php7.4-json 7.4.25-1+deb11u1
> ii  php7.4-opcache  7.4.25-1+deb11u1
> ii  procps  2:3.3.17-5
> ii  tzdata  2021a-1+deb11u2
> ii  ucf 3.0043
> ii  zlib1g  1:1.2.11.dfsg-2
> 
> Versions of packages php7.4-fpm suggests:
> pn  php-pear  
> 
> -- no debconf information
> 

Bug#1001131: [RFC PATCH] Enhance docs with answers for common questions

[David Bremner]

Nicholas D Steeves  writes:

> Package: dh-elpa
> Version: 2.0.9
> Severity: normal
> Control: tag -1 patch
>
> Hello,
>
> I've noticed that these questions are still coming up on
> #debian-emacs, so I thought I'd work on a documentation enhancement
> proposal.  I've attached a patch series, and--if preferred--a git remote is 
> available at: https://salsa.debian.org/sten/dh-elpa.git
>
> The commit messages further information, and short changelog messages
> have also been provided.

Overall this seems like a good idea. I have a few suggestions.

> +An "Emacs Lisp Package Archive" style package is a library that
> +includes the metadata that is necessary to integrate with GNU Emacs
> +via B This metadata is provided using headers and/or an
> +B file.  B will attempt to autogenerate
> +this file from headers, and will warn when this is not possible.  When
> +converting a legacy-style Debian Emacs package to a new-style ELPA
> +package, maintainers will typically choose to hand-craft this file;
> +When upstream releases no longer occur, the B variable of
> +this file will not need to be updated, thus for such packages, a
> +B involves neglegible to zero maintenance burden.
> +

- I did wonder if all of "legacy-style" discussion should be
  together, perhaps under a subheading.
- it might be useful to define "legacy-style"
- I tripped over "neglegible to zero", perhaps replace with something
  simpler like "minimal".

> +Why convert a legacy-style Debian Emacs package to a new-style ELPA
> +one?  Using B centralises maintscripts, allowing one to drop

- "maintscripts" seems a bit jargony, and the real point is that the
  packager does not need to maintain emacsen-common install/remove
  scripts. However, maybe it is better to be concise than precise here.

> +them from the package; this eliminates a source of bugs, and allows
> +all B-using packages to inherit cross-archive updates to
> +emacsen packages.  Integration with the GNU Emacs package manager is
> +consistent with a better user experience, and the primary reason to

- The phrase "consistent with a better user experience" sounds quite a
  bit overcomplicated and overqualified.

> +not adopt B is when compatibility with XEmacs is required.
> +
>  B will attempt to run ERT and Buttercup test suites using
>  dh_elpa_test(1) if the debhelper compat level is 10 or higher.  This
>  will override dh_auto_test(1).  To disable this behaviour, or tweak it
> -- 
> 2.30.2
>
>>From 6b1105955c1eb56ace4413d37f06973409417629 Mon Sep 17 00:00:00 2001
> From: Nicholas D Steeves 
> Date: Sat, 4 Dec 2021 19:34:17 -0500
> Subject: [PATCH 3/3] =?UTF-8?q?Replace=20occurrences=20of=20=20wi?=
>  =?UTF-8?q?th=20=20for=20disambiguation=E2=80=A6?=
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> and readability.  The new Description in dh_elpa.1 mentions
> "package.el".  Here, "package" is a static atom; however, in
> "elpa-package-pkg.el" the same atom is a foo-style variable.  The term
> also appears too often in the man page, and this reduces readability.
>
> Please feel free to change to something more appropriate should foo
> not be desired.

I guess for an audience of debian contributors foo is OK, but I guess if
possible it would be nice to have something a bit less in-jokey. I don't
know if it's a strict improvement, but "hello" would be consistent with
other docs.

d

Bug#1001245: weechat: FTBS against Ruby 3.0

[Sébastien Helleu]

On Mon, Dec 06, 2021 at 06:23:50PM -0300, Lucas Kanashiro wrote:
> Package: weechat
> Version: 3.3-1
> Severity: important
> Tags: patch bookworm sid
> User: debian-r...@lists.debian.org
> Usertags: ruby3.0
> 
> Dear maintainer,
> 
> The current version of weechat does not support Ruby 3.0, please apply the
> upstream patch below:
> 
> https://github.com/weechat/weechat/commit/fe9768f484304c28cf4e6d6eb980613b00ca6904
> 
> 
> It will fix the current FTBFS against ruby3.0.
> 
> TIA!
> 
> -- 
> Lucas Kanashiro

Hi,

If this patch is applied, other commits should be used as well: they fix issues
on macOS and detection with autotools, but not sure then if they are mandatory
for the Debian package.

Commits:

* Fix compilation with Ruby 3.0 on macOS:
  
https://github.com/weechat/weechat/commit/27a480c7d7cc897ec1228f25d97bbfeb0f52dca3

* Fix detection of Ruby 3.0 on macOS:
  
https://github.com/weechat/weechat/commit/be753046b729dab518c390cbf9be6360310fc65a

* Add detection of Ruby 3.0 in autotools:
  
https://github.com/weechat/weechat/commit/aed64f5020f63a37413da29367734b066fdaf235


-- 
Sébastien Helleu

web: weechat.org / flashtux.org
irc: FlashCode @ irc.libera.chat

Bug#1001271: kitty: Pressing "Print Screen" causses input "361u"

[Marc Kleine-Budde]

Package: kitty
Version: 0.21.2-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

 Updating kitty from 0.19.3-1 to 0.21.2-1.
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 My window manager doesn't have any bindings for the "Print Scren" button.
 I'm using it as the push-to-talk button in mumble.

 Pressing "Print Screen" while the kitty window is active.

   * What was the outcome of this action?

 Kitty writes "361u" (without the >"<) into the terminal.
 mumble properly detects push-to-talk, as expected.

   * What outcome did you expect instead?

 Kitty should not write anything to the terminal.
 mumble properly detects push-to-talk.

Here some debug output of kitty --debug-keyboard (0.19.3-1) while pushing  
"Print Screen":

| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 283 (PRINT SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 283 native_code: 0xff61 action: PRESS mods: 0x0 text: 
'' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 283 (PRINT SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 283 native_code: 0xff61 action: REPEAT mods: 0x0 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 283 (PRINT SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 283 native_code: 0xff61 action: REPEAT mods: 0x0 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 283 (PRINT SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 283 native_code: 0xff61 action: REPEAT mods: 0x0 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 283 (PRINT SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 283 native_code: 0xff61 action: REPEAT mods: 0x0 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 283 (PRINT SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 283 native_code: 0xff61 action: REPEAT mods: 0x0 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 283 (PRINT SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 283 native_code: 0xff61 action: REPEAT mods: 0x0 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 283 (PRINT SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 283 native_code: 0xff61 action: REPEAT mods: 0x0 
text: '' state: 0 sent key to child
| Release xkb_keycode: 0x6b clean_sym: Print mods: none glfw_key: 283 (PRINT 
SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 283 native_code: 0xff61 action: RELEASE mods: 0x0 
text: '' state: 0 ignoring as keyboard mode does not allow release events


Here some debug output of kitty --debug-keyboard (0.21.2-1) while pushing  
"Print Screen":

| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 57361 (PRINT_SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 0xe011 native_code: 0xff61 action: PRESS mods: none 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 57361 (PRINT_SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 0xe011 native_code: 0xff61 action: REPEAT mods: none 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 57361 (PRINT_SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 0xe011 native_code: 0xff61 action: REPEAT mods: none 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 57361 (PRINT_SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 0xe011 native_code: 0xff61 action: REPEAT mods: none 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 57361 (PRINT_SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 0xe011 native_code: 0xff61 action: REPEAT mods: none 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 57361 (PRINT_SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 0xe011 native_code: 0xff61 action: REPEAT mods: none 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 57361 (PRINT_SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 0xe011 native_code: 0xff61 action: REPEAT mods: none 
text: '' state: 0 sent key to child
| Press xkb_keycode: 0x6b clean_sym: Print composed_sym: Print mods: none 
glfw_key: 57361 (PRINT_SCREEN) xkb_key: 65377 (Print)
| on_key_input: glfw key: 0xe011 native_code: 0xff61 

Bug#1001219: libnss3: recent update prevents ssl connections in chromium 73

[Tobias Kalleder]

Hi Utkarsh,

pulled your .deb (only the libnss3_3.26.2-1.1+deb9u4~ppa1_amd64.deb) and that 
fixed the issue and everything works as before again :)

Thanks a lot,

Tobias

On Tue, 7 Dec 2021 14:14:30 +0530 Utkarsh Gupta  wrote:
> Hi Tobias,
> 
> On Mon, Dec 6, 2021 at 8:48 PM Tobias Kalleder  wrote:
> >* What led up to the situation?
> > automatic security update to libnss3 (2:3.26.2-1.1+deb9u3) Thu, 02 
> > Dec 2021 17:05:48 +0530Thu, 02 Dec 2021 17:05:48 +0530
> > prevents chromium 73.0.3683.75 from most if not all ssl connections
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > chromium in headless mode not loading css from external resources 
> > and throws errors, see below
> >* What was the outcome of this action?
> > external css/js files loaded from cloudflare cdn do not load at all
> > [1206/150811.360650:ERROR:cert_verify_proc_nss.cc(974)] 
> > CERT_PKIXVerifyCert for cdnjs.cloudflare.com failed err=-8182
> > [1206/150811.362285:ERROR:ssl_client_socket_impl.cc(962)] handshake 
> > failed; returned -1, SSL error code 1, net_error -207
> >
> > * What outcome did you expect instead?
> > ssl connections to cdn to work in order to load css/js resources
> 
> Thank you for the bug report. I did the upload and I am sorry that it
> didn't work out as expected. Whilst I am not 100% sure why this
> could've happened, I, however, have a suspicion on the missing
> "breaks", which could've plausibly caused this.
> 
> Would you mind pulling in the .debs from here:
> https://people.debian.org/~utkarsh/lts/nss/
> and testing this out, please? Let me know how does that behave? Do you
> still see the regression? If so, could you please provide me the steps
> to reproduce?
> 
> Thank you!
> 
> 
> - u
> 
> 

Bug#980982: New upstream version 2.0.18

[Javier Fernandez-Sanguino]

tag 980982 pending
thanks

Dear colleagues,

I have prepared a new package version for upstream version 2.0.19. I tried
to upload it yesterday but had some issues.

In any case it should be available in the archive soon.

Saludos,

Javier

El vie., 9 jul. 2021 20:57, LeJacq, Jean Pierre <
jeanpierre.lej...@quoininc.com> escribió:

> Hello Javier,
>
> There has been several releases of flawfinder,  Version 2.01.8 released
> 2021-06-25 is the latest at the time of this report.
>
> --
> JP
>

Bug#1001263: logind: IdleAction=ignore not effective

[Andrea Villa]

Thanks for the quick answer Michael; I see logind suspending the system but
not because of "System idle": I have then to investigate what component is
triggering such suspend after a certain inactivity time.
I guess this bug can be therefore closed.

Cheers,

Andrea

On Tue, Dec 7, 2021 at 11:55 AM Michael Biebl  wrote:

> On 07.12.21 10:30, Michael Biebl wrote:
> > Control: tags -1 + moreinfo
> >
> > On 07.12.21 09:47, Andrea V wrote:
> >> changing IdleAction options inside /etc/systemd/logind.conf does not
> >> have any effect on automatic sleep.
> >
> > What exactly does that mean?
> > Do you want logind to suspend after some idle time (and it doesn't) or
> > did you set IdleAction to ignore but it suspended anyway?
>
> Assuming it is the latter, keep in mind that  IdleAction=ignore is the
> default, so you don't need to explicitly configure it.
>
> I suspect that your system suspend wasn't actually trigged by logind's
> idle action.
>
> But you can find out easily.
>
> Run (as root) journalctl -u systemd-logind and check the time window
> when your system went into suspend. If it was triggered by logind, then
> you should have a message like:
>
>
> Dez 07 11:49:33 pluto systemd-logind[3087]: System idle. Doing suspend
> operation.
> Dez 07 11:49:33 pluto systemd-logind[3087]: Suspending...
>
>
>
>

Bug#1001263: logind: IdleAction=ignore not effective

[Michael Biebl]

On 07.12.21 10:30, Michael Biebl wrote:

Control: tags -1 + moreinfo

On 07.12.21 09:47, Andrea V wrote:

changing IdleAction options inside /etc/systemd/logind.conf does not
have any effect on automatic sleep.


What exactly does that mean?
Do you want logind to suspend after some idle time (and it doesn't) or 
did you set IdleAction to ignore but it suspended anyway?


Assuming it is the latter, keep in mind that  IdleAction=ignore is the 
default, so you don't need to explicitly configure it.


I suspect that your system suspend wasn't actually trigged by logind's 
idle action.


But you can find out easily.

Run (as root) journalctl -u systemd-logind and check the time window 
when your system went into suspend. If it was triggered by logind, then 
you should have a message like:



Dez 07 11:49:33 pluto systemd-logind[3087]: System idle. Doing suspend 
operation.

Dez 07 11:49:33 pluto systemd-logind[3087]: Suspending...





OpenPGP_signature
Description: OpenPGP digital signature

Bug#956325: 956325 fixed in 0.18.1-1

[Ralf E-Mail]

tags 956325 buster
fixed 956325 0.18.1-1
thanks

Bug#1001270: Sddm: Autologin no longer works after upgrade from 10 buster to 11 bullseye

[Ralf E-Mail]

Package: sddm
Version: 0.19.0-3

I recently upgraded my system to bullseye and sddm autologin no longer
works.
The screen gets stuck black with the a cursor blinking, but nothing more
happens.
I cannot switch to the console via ctrl+alt+F1.
However login in via ssh from another machine works perfectly.

The file /etc/pam.d/sddm-autologin is not modified and identical to the
upstream (debian) version.

In journalctl i find the following sddm entries (please ignore the
QIODevice::write entry - state.conf is by purpose not writeable and never
caused any problems).

Dez 07 10:37:07 W sddm[1006]: Initializing...
Dez 07 10:37:07 W sddm[1006]: Starting...
Dez 07 10:37:07 W sddm[1006]: Logind interface found
Dez 07 10:37:07 W sddm[1006]: Adding new display on vt 7 ...
Dez 07 10:37:07 W sddm[1006]: Loading theme configuration from ""
Dez 07 10:37:07 W sddm[1006]: Display server starting...
Dez 07 10:37:07 W sddm[1006]: Adding cookie to "/var/run/sddm/{}"
Dez 07 10:37:07 W sddm[1006]: Running: /usr/bin/X -nolisten tcp -auth
/var/run/sddm/{} -background none -noreset -displayfd 17 -seat seat0 vt7
Dez 07 10:37:08 W sddm[1006]: Setting default cursor
Dez 07 10:37:08 W sddm[1006]: Running display setup script
 "/usr/share/sddm/scripts/Xsetup"
Dez 07 10:37:08 W sddm[1006]: Display server started.
Dez 07 10:37:08 W sddm[1006]: Reading from
"/usr/share/xsessions/plasma.desktop"
Dez 07 10:37:08 W sddm[1006]: Reading from
"/usr/share/xsessions/plasma.desktop"
Dez 07 10:37:08 W sddm[1006]: Session
"/usr/share/xsessions/plasma.desktop" selected, command:
"/usr/bin/startplasma-x11"
Dez 07 10:37:08 W sddm-helper[1085]: [PAM] Starting...
Dez 07 10:37:08 W sddm-helper[1085]: [PAM] Authenticating...
Dez 07 10:37:08 W sddm-helper[1085]: [PAM] returning.
Dez 07 10:37:08 W sddm[1006]: Authenticated successfully
Dez 07 10:37:08 W sddm[1006]: QIODevice::write (QFile,
"/var/lib/sddm/state.conf"): device not open
Dez 07 10:37:08 W sddm-helper[1085]: pam_unix(sddm-autologin:session):
session opened for user (uid=) by (uid=0)
Dez 07 10:37:08 W sddm-helper[1085]: Starting:
"/etc/sddm/wayland-session /usr/bin/startplasma-x11"
Dez 07 10:37:08 W sddm-helper[1109]: Jumping to VT 1
Dez 07 10:37:08 W sddm-helper[1109]: VT mode didn't need to be fixed
Dez 07 10:37:09 W sddm[1006]: Session started
Dez 07 10:37:09 W sddm-helper[1085]: [PAM] Closing session
Dez 07 10:37:09 W sddm-helper[1085]: pam_unix(sddm-autologin:session):
session closed for user 
Dez 07 10:37:09 W sddm-helper[1085]: [PAM] Ended.
Dez 07 10:37:09 W sddm[1006]: Auth: sddm-helper exited with 1

Since the problem is reproducible and the machine does not crash, I can
assist with more logs, etc.

Thanks for your support in advance,
Ralf

Bug#1001268: snmpd fails to start at boot if network is not online

[Dominique Brazziel]

Package: snmpdVersion: 5.9.1+dfsg-1Severity: importantX-Debbugs-Cc: 
dbrazz...@snet.net
Dear Maintainer,
   * What led up to the situation?
After boot snmpd not running   * What exactly did you do (or not do) that was 
effective (or     ineffective)?   * What was the outcome of this action?Message 
'Error opening specified endpoint "<* interface IP address *>"   * What outcome 
did you expect instead?snmpd up and running

    The reason for the startup failure is snmpd depends on the passive 
network.target. The wifi
modem was not yet active and connected at the time the network target was 
reached.was to change the service unit to depend on 'network-online.target'.
-- System Information:Debian Release: bookworm/sid  APT prefers testing  APT 
policy: (990, 'testing'), (500, 'stable-security'), (500, 
'unstable')Architecture: amd64 (x86_64)
Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)Kernel taint flags: 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULELocale: LANG=en_US.UTF-8, 
LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), 
LANGUAGE not setShell: /bin/sh linked to /usr/bin/dashInit: systemd (via 
/run/systemd/system)LSM: AppArmor: enabled
Versions of packages snmpd depends on:ii  adduser                3.118ii  
debconf [debconf-2.0]  1.5.79ii  init-system-helpers    1.60ii  libc6           
       2.32-4ii  libsnmp-base           5.9.1+dfsg-1ii  libsnmp40              
5.9.1+dfsg-1ii  lsb-base               11.1.0
Versions of packages snmpd recommends:ii  procps  2:3.3.17-5

Bug#476909: please ITP one new package to download dictionaries

[肖盛文]

Control: -1 tags wontfix


Hi dimka,

    stardict was recently reintroduced to Debian sid.

I'm new maintainer of the stardict.

Do you use stardict now?


I just read the old bug #476909.

I also suggestion:

3) Create a new package.


The upstream stardict source code is so big and complex,

so split the download dictionaries function to one independent package 
is better.


I would add the new package to Suggests: or Recommends: field in 
stardict package.



regards,

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



OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#997657: NMU

[Daniel Leidert]

Hi,

I've just uploaded an NMU to fix this issue. Please find attached the debdiff.
Please note that your Git repository is not in sync with the Debian archive. It
is missing version 3.0.0, this NMU applies to.

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

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert
diff -Nru ruby-prawn-icon-3.0.0/debian/changelog ruby-prawn-icon-3.0.0/debian/changelog
--- ruby-prawn-icon-3.0.0/debian/changelog	2021-10-10 20:37:56.0 +0200
+++ ruby-prawn-icon-3.0.0/debian/changelog	2021-12-07 11:14:30.0 +0100
@@ -1,3 +1,12 @@
+ruby-prawn-icon (3.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use gem installation layout, so the font files can be found in the
+expected path (closes: #997657).
+  * Enable tests and add ruby-pdf-inspector to build dependencies.
+
+ -- Daniel Leidert   Tue, 07 Dec 2021 11:14:30 +0100
+
 ruby-prawn-icon (3.0.0-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru ruby-prawn-icon-3.0.0/debian/control ruby-prawn-icon-3.0.0/debian/control
--- ruby-prawn-icon-3.0.0/debian/control	2021-10-10 20:37:56.0 +0200
+++ ruby-prawn-icon-3.0.0/debian/control	2021-12-07 11:14:30.0 +0100
@@ -6,6 +6,7 @@
 Build-Depends: debhelper-compat (= 13),
gem2deb,
rake,
+   ruby-pdf-inspector,
ruby-prawn (<< 3.0.0),
ruby-prawn (>= 1.1.0),
ruby-rspec
@@ -20,8 +21,8 @@
 Package: ruby-prawn-icon
 Architecture: all
 XB-Ruby-Versions: ${ruby:Versions}
-Depends: ${ruby:Depends},
- ${misc:Depends}
+Depends: ${misc:Depends},
+ ${ruby:Depends}
 Description: Provides icon fonts for PrawnPDF
  Prawn::Icon provides various icon fonts including
  FontAwesome, PaymentFont and Foundation Icons
diff -Nru ruby-prawn-icon-3.0.0/debian/patches/0003-Remove-bundler-and-simplecov.patch ruby-prawn-icon-3.0.0/debian/patches/0003-Remove-bundler-and-simplecov.patch
--- ruby-prawn-icon-3.0.0/debian/patches/0003-Remove-bundler-and-simplecov.patch	1970-01-01 01:00:00.0 +0100
+++ ruby-prawn-icon-3.0.0/debian/patches/0003-Remove-bundler-and-simplecov.patch	2021-12-07 11:14:30.0 +0100
@@ -0,0 +1,31 @@
+Author: Daniel Leidert
+Date: 2021-12-07
+Subject: Remove bundler and simplecov usage
+
+Forwarded: not-needed
+
+--- a/spec/spec_helper.rb
 b/spec/spec_helper.rb
+@@ -5,11 +5,11 @@
+ # This is free software. Please see the LICENSE and COPYING files for details.
+ #
+ #
+-require 'simplecov'
+-SimpleCov.start
++#require 'simplecov'
++#SimpleCov.start
+ 
+-require "bundler"
+-Bundler.setup
++#require "bundler"
++#Bundler.setup
+ 
+ require "prawn/icon"
+ require 'pdf/inspector'
+@@ -22,4 +22,4 @@
+ RSpec.configure do |config|
+   config.include PDFHelper
+   config.include ParserHelper
+-end
+\ No newline at end of file
++end
diff -Nru ruby-prawn-icon-3.0.0/debian/patches/series ruby-prawn-icon-3.0.0/debian/patches/series
--- ruby-prawn-icon-3.0.0/debian/patches/series	2021-10-10 20:37:56.0 +0200
+++ ruby-prawn-icon-3.0.0/debian/patches/series	2021-12-07 11:14:30.0 +0100
@@ -1,2 +1,3 @@
 0001-Clear-executable-bit-on-data-fonts-pf.patch
-0002-Access-data-files-from-usr-share-ruby-prawn-icon.patch
+#0002-Access-data-files-from-usr-share-ruby-prawn-icon.patch
+0003-Remove-bundler-and-simplecov.patch
diff -Nru ruby-prawn-icon-3.0.0/debian/ruby-prawn-icon.install ruby-prawn-icon-3.0.0/debian/ruby-prawn-icon.install
--- ruby-prawn-icon-3.0.0/debian/ruby-prawn-icon.install	2021-10-10 20:37:56.0 +0200
+++ ruby-prawn-icon-3.0.0/debian/ruby-prawn-icon.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-data/fonts/[a-z]* /usr/share/ruby-prawn-icon/data/fonts/
diff -Nru ruby-prawn-icon-3.0.0/debian/ruby-tests.rake ruby-prawn-icon-3.0.0/debian/ruby-tests.rake
--- ruby-prawn-icon-3.0.0/debian/ruby-tests.rake	2021-10-10 20:37:56.0 +0200
+++ ruby-prawn-icon-3.0.0/debian/ruby-tests.rake	2021-12-07 11:14:30.0 +0100
@@ -1,4 +1,5 @@
-task default: %w[test]
+require 'gem2deb/rake/spectask'
 
-task :test do
+Gem2Deb::Rake::RSpecTask.new do |spec|
+  spec.pattern = './spec/**/*_spec.rb'
 end
diff -Nru ruby-prawn-icon-3.0.0/debian/rules ruby-prawn-icon-3.0.0/debian/rules
--- ruby-prawn-icon-3.0.0/debian/rules	2021-10-10 20:37:56.0 +0200
+++ ruby-prawn-icon-3.0.0/debian/rules	2021-12-07 11:09:32.0 +0100
@@ -5,5 +5,7 @@
 # Uncomment this to turn on verbose mode.
 export DH_VERBOSE=1
 
+export DH_RUBY = --gem-install
+
 %:
 	dh $@ --buildsystem=ruby --with ruby


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

Bug#929050: weex: use dh autoreconf to update configure, so that support new architectures

[Ludovic Drolez]

Hi!

I've tried to use dh_autoreconf, but now the build fails.
Did you try a recent build with it?

Best regards,

Ludovic

On Thu, May 16, 2019 at 11:37:25AM +0800, YunQiang Su wrote:
> +  * Run dh_autoreconf to update configure.


-- 
Ludovic Drolez.

https://drolez.com/blog/music/   - Music and Tech Blog

Bug#1001242: weex FTBFS: dh_testroot: error: You must run this as root (or use fakeroot).

[Ludovic Drolez]

Hi!
Sorry I thought that was required for all builds?
Ludovic

> dh_testroot
> dh_testroot: error: You must run this as root (or use fakeroot).

-- 
Ludovic Drolez.

https://drolez.com/blog/   - Music and Tech Blog

Bug#1001267: php7.4-imap: starttls is unable to connect with imap servers which support only TLS 1.2 and TLS 1.3

[Falk Hackenberger]

Package: php7.4-imap
Version: 7.4.25-1+deb11u1
Severity: normal

Dear Maintainer,

I try to use php7.4-imap to connect with a imap server which supports only 
starttls over port 143 and supports only TLS 1.2 or newer.
php -r '$user="username";$pass="Password";$mbox=imap_open( 
"{server.example.com:143/imap/tls/novalidate-cert}", $user, $pass, 
OP_DEBUG);echo ($mbox !== false)?"OK":imap_last_error();'
This fails with:
"PHP Warning:  imap_open(): Couldn't open stream" und "TLS/SSL failure for 
server.example.com: SSL negotiation failed". 

According to [1], the reason is the old libc-client2007e, which can not handle 
newer TLS Versions on startttls.

[1] https://bugs.php.net/bug.php?id=76928

-- Package-specific info:
 Additional PHP 7.4 information 

 PHP @PHP_VERSION SAPI (php7.4query -S): 

 PHP 7.4 Extensions (php7.4query -M -v): 

 Configuration files: 
 /etc/php/7.4/mods-available/imap.ini 
extension=imap.so


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

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

Versions of packages php7.4-imap depends on:
ii  libc-client2007e  8:2007f~dfsg-7+b1
ii  libc6 2.31-13+deb11u2
ii  php-common2:76
ii  php7.4-common 7.4.25-1+deb11u1
ii  ucf   3.0043

php7.4-imap recommends no packages.

php7.4-imap suggests no packages.

Versions of packages php7.4-common depends on:
ii  libc6   2.31-13+deb11u2
ii  libffi7 3.3-6
ii  libssl1.1   1.1.1k-1+deb11u1
ii  php-common  2:76
ii  ucf 3.0043

Versions of packages php7.4-cli depends on:
ii  libargon2-1  0~20190702-0.1+0~20190710.3+debian9~1.gbp2fb167
ii  libc62.31-13+deb11u2
ii  libedit2 3.1-20191231-2+b1
ii  libmagic11:5.39-3
ii  libpcre2-8-0 10.36-2
ii  libsodium23  1.0.18-1
ii  libssl1.11.1.1k-1+deb11u1
ii  libxml2  2.9.10+dfsg-6.7
ii  mime-support 3.66
ii  php7.4-common7.4.25-1+deb11u1
ii  php7.4-json  7.4.25-1+deb11u1
ii  php7.4-opcache   7.4.25-1+deb11u1
ii  php7.4-readline  7.4.25-1+deb11u1
ii  tzdata   2021a-1+deb11u2
ii  ucf  3.0043
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages php7.4-cli suggests:
pn  php-pear  

Versions of packages php7.4-fpm depends on:
ii  libacl1 2.2.53-10
ii  libapparmor12.13.6-10
ii  libargon2-1 0~20190702-0.1+0~20190710.3+debian9~1.gbp2fb167
ii  libc6   2.31-13+deb11u2
ii  libmagic1   1:5.39-3
ii  libpcre2-8-010.36-2
ii  libsodium23 1.0.18-1
ii  libssl1.1   1.1.1k-1+deb11u1
ii  libsystemd0 247.3-6
ii  libxml2 2.9.10+dfsg-6.7
ii  mime-support3.66
ii  php7.4-cli  7.4.25-1+deb11u1
ii  php7.4-common   7.4.25-1+deb11u1
ii  php7.4-json 7.4.25-1+deb11u1
ii  php7.4-opcache  7.4.25-1+deb11u1
ii  procps  2:3.3.17-5
ii  tzdata  2021a-1+deb11u2
ii  ucf 3.0043
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages php7.4-fpm suggests:
pn  php-pear  

-- no debconf information

Bug#1001266: dh-golang: DH_GOLANG_EXCLUDES handling can be improved

[Alois Micard]

Package: dh-golang
Version: 1.52
Severity: normal
X-Debbugs-Cc: creekor...@debian.org, f...@debian.org

Hello team,

While working on syncthing, I've noticed something weird with
the way DH_GOLANG_EXCLUDES is interpreted.

The following exclusion in d/rules:

```
export DH_GOLANG_EXCLUDES := meta
```

Will cause the exclusion of the following files from
the build targets:

```
./meta/copyright_test.go
./meta/gofmt_test.go
./meta/metalint_test.go
./lib/db/meta_test.go
./lib/db/meta.go
```

In my scenario, I only wanted to exclude files from the meta folder
(i.e meta/*) so I've updated d/rules like this:

```
export DH_GOLANG_EXCLUDES := meta/
```

And now, nothing is being filtered, previous files are now included
in the build target.

Trying to escape the exclusion: `meta\/` hasn't worked either way:
previous files are still included in the build target.

@foka (in CC) helped me fixing my syntax by using `meta($$|/)` as
an exclusion, in order to match both meta/ and meta$.

---

@foka has done a little analysis of the situation, and while
this behavior is weird, it is definitely expected:

dh-golang is doing a `go list $xs-go-import-path` against the package
and in our situation, the meta directory would appear as
github.com/syncthing/syncthing/meta (no trailing '/') and therefore
this explain why it hasn't match against the DH_GOLANG_EXCLUDES regex.

Maybe dh-golang can be improved to handle such case? (i.e trying to
match both meta/ and meta$ in this scenario).

---

@foka: the documentation about DH_GOLANG_EXCLUDES [1], is therefore 
currently false, since examples/ will not be excluded from build 
and test but from the .deb.

Cheers,

[1]: 
https://manpages.debian.org/testing/dh-golang/Debian::Debhelper::Buildsystem::golang.3pm.en.html#DH_GOLANG_EXCLUDES

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

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

Versions of packages dh-golang depends on:
ii  debhelper 13.5.2
ii  libdpkg-perl  1.20.9
ii  perl  5.32.1-6

dh-golang recommends no packages.

dh-golang suggests no packages.

-- no debconf information

Bug#1001265: Please upgrade to stockfish 14.1

[Claudio Saavedra]

Package: stockfish
Version: 12-2

Bug#997981: subject

[Thomas Glanzmann]

Hello,
I have the same issue. I'm on Debian 10 amd64 with 0.12.2-3. I also
tried 1.1.2-2~bpo10+1. This issue is related with something Letsencrypt
changed. The last Letsencrypt Certificate was from 8th October. Tonight
I renewed my Letsencrypt Certificate autoamtically. After that before
the login promot, ocserv was crashing. From the client it looked like
that:

(nuc) [~] openconnect vpn.company.com
POST https://vpn.company.com/
Connected to 1.2.3.4:443
SSL negotiation with vpn.company.com
Connected to HTTPS on vpn.company.com with ciphersuite 
(TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
Error reading HTTP response: Invalid argument
GET https://vpn.company.com/
Connected to 1.2.3.4:443
SSL negotiation with vpn.company.com
Connected to HTTPS on vpn.company.com with ciphersuite 
(TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
Error reading HTTP response: Invalid argument
Failed to obtain WebVPN cookie

>From the server site it looked like that:

Dec  7 04:00:58 debian ocserv[6166]: main: main.c:983: Child 6178 died with 
sigsegv
... 180 ... similiar entries skipped.

I was able to restore operation by compiling ocserv from source:

sudo apt-get build-dep -y ocserv
wget https://www.infradead.org/ocserv/download/ocserv-1.1.5.tar.xz
tar xfJ ocserv-1.1.5.tar.xz
cd ocserv-1.1.5
sudo mkdir -p /local/ocserv
sudo chown  /local/ocserv
./configure --prefix=/local/ocserv
make
make instsall
sudo /etc/init.d/ocserv stop
sudo /local/ocserv/sbin/ocserv -c /etc/ocserv/ocserv.conf

However I'll upgrade to Debian 11 tonight. Debian 11 doesn't have this problem,
because I have several other ocserv on Debian 11, which don't have the issue.

Cheers,
Thomas

Bug#984268: ogmtools: diff for NMU version 1:1.5-4.1

[Marc Leeman]

Thanks Adrian.


On Tue, 9 Nov 2021 at 16:06, Adrian Bunk  wrote:

> Control: tags 984268 + patch
> Control: tags 984268 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for ogmtools (versioned as 1:1.5-4.1) and uploaded
> it to DELAYED/15. Please feel free to tell me if I should cancel it.
>
> cu
> Adrian
>


-- 
g. Marc

Bug#997657: Problem is in ruby-prawn-icon

[Daniel Leidert]

Hi,

the problem is actually in ruby-prawn-icon in the files
/usr/lib/ruby/vendor_ruby/prawn/icon/font_data.rb and
/usr/lib/ruby/vendor_ruby/prawn/icon/configuration.rb.

In the first the path to the fonts relies on 

Icon.configuration.font_directory

which is defined in the second and leads to the non-existent directory
/usr/lib/ruby/data/fonts, whereas the fonts are actually in
/usr/share/ruby-prawn-icon/data/fonts/.

The quick fix might be to change to the gem installation layout. Otherwise the
font_directory default must be adjusted.

Reassigning to ruby-prawn-icon.

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

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


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

Bug#405482: stardict-gtk: segfaults when enable_collation=1 in the .cfg

[肖盛文]

Control: tags -1 |moreinfo |||unreproducible||

Hi,

    I can't unreproducible this bug in the new version.||

||apt install stardict-english-czech||

||then use the step from:||

||https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405482#45||

||There is not ||segfaults.

The part of my ~/.config/stardict/stardict.cfg :

[/apps/stardict/preferences/dictionary]
scan_selection=false
enable_collation=true
do_not_load_bad_dict=true
collate_function=3



||
||


在 2021/12/6 上午11:14, Paul Wise 写道:

On Wed, 03 Jan 2007 22:28:10 +0100 Pierre Habouzit wrote:


stardict-gtk: segfaults when enable_collation=1 in the .cfg

stardict was recently reintroduced to Debian sid.
Please try to reproduce the bug with the new version.


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



OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001263: logind: IdleAction=ignore not effective

[Michael Biebl]

Control: tags -1 + moreinfo

On 07.12.21 09:47, Andrea V wrote:

changing IdleAction options inside /etc/systemd/logind.conf does not
have any effect on automatic sleep.


What exactly does that mean?
Do you want logind to suspend after some idle time (and it doesn't) or 
did you set IdleAction to ignore but it suspended anyway?






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001190: tracker.debian.org: news: emails: show Message-ID header, link to lists.d.o/msgid-search

[Paul Wise]

On Tue, 2021-12-07 at 09:23 +0100, Raphael Hertzog wrote:

> The tracker doesn't receive emails via mailing lists, it gets sent a
> direct copy from the various services.

Ah. That is the case for Debian but maybe not for other instances,
so I think this could be useful for some distros eventually.

> What's the "domain" of an email message? The one from the sender?

The one in the List-Id or the recipient that is a mailing list server,
but as you say that isn't available for Debian.

> I don't see how this can be helpful if you have to look up the message on
> your own.

Agreed, but it is better than having no idea where the archives are at
all and having to do a web search for that or go to the domain and then
try to find the mailing list and click into the list archives.

> This, however, is something that is clearly more in line with the logic
> of distro tracker. I agree that a query to lookup a message-id could be
> useful.

Excellent.

> (And actually I am interested in tracking message-id of everything that
> went through distro-tracker to be able to drop duplicates easily and/or
> present other summary views to the respective maintainers)

That seems useful too.

> > I think the options I presented above are generic enough to have a low
> > enough cost. For cases not covered by them I think as a compromise, it
> > would be reasonable to just show the Message-ID header with no link.
> 
> This is also reasonable, indeed.

Great.

Thanks for the discussion :)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1001264: coinor-cbc is built with asserts enabled

[Alex Stapleton]

Package: coinor-cbc
Version: 2.10.5+ds1-3
Severity: normal
X-Debbugs-Cc: alex.staple...@gmail.com

Dear Maintainer,

The coinor-cbc package is built with debug flags enabled that result in
it crashing on inputs that should not cause it to crash.

An example problem is provided in this GitHub issue 
https://github.com/coin-or/Cbc/issues/462
and there is input from the upstream maintainer that says asserts should
not be enabled in normal use.

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

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

Versions of packages coinor-cbc depends on:
ii  coinor-libcbc3  2.10.5+ds1-3
ii  coinor-libclp1  1.17.5+repack1-1
ii  libc6   2.31-13+deb11u2
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6

coinor-cbc recommends no packages.

coinor-cbc suggests no packages.

-- no debconf information

Bug#995394: bullseye-pu: package horizon/3:18.6.2-5

[Thomas Goirand]

On 12/3/21 5:47 PM, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2021-09-30 at 17:03 +0200, Thomas Goirand wrote:
>> For some reasons, the compiled .mo translations were
>> disabled in the package. This update will re-activate them.
>>
>> [ Reason ]
>> I'm really not sure why this was desactivated (I don't remember).
>>
>> [ Impact ]
>> No translations available in the OpenStack Dashboard.
>>
> 
> Please go ahead.
> 
> Regards,
> 
> Adam
> 

Uploaded.

Thomas

Bug#994064: bullseye-pu: package python-eventlet/0.26.1-7

[Thomas Goirand]

On 12/3/21 5:25 PM, Julien Cristau wrote:
> Control: tag -1 confirmed
> 
> Hi Thomas,
> 
> A couple of comments on the diff below, otherwise fine to go ahead.
> 
> On Fri, Sep 10, 2021 at 09:50:25PM +0200, Thomas Goirand wrote:
>> diff -Nru python-eventlet-0.26.1/debian/greendns.orig.py 
>> python-eventlet-0.26.1/debian/greendns.orig.py
>> --- python-eventlet-0.26.1/debian/greendns.orig.py   2021-05-11 
>> 08:03:43.0 +0200
>> +++ python-eventlet-0.26.1/debian/greendns.orig.py   2021-09-10 
>> 21:42:12.0 +0200
> 
> That looks odd, this file probably shouldn't be there?

This may look odd, but it's there on purpose. Look what's done in
override_dh_sphinxdoc: in debian/rules, and you may understand. The
debian/rules is doing some modifications to greendns.py so that the doc
can be built.

> [...]
>> diff -Nru python-eventlet-0.26.1/debian/greendns.py 
>> python-eventlet-0.26.1/debian/greendns.py
>> --- python-eventlet-0.26.1/debian/greendns.py2021-05-11 
>> 08:03:43.0 +0200
>> +++ python-eventlet-0.26.1/debian/greendns.py2021-09-10 
>> 21:42:12.0 +0200
> [...]
>>  def tcp(q, where, timeout=DNS_QUERY_TIMEOUT, port=53,
>> @@ -794,7 +834,19 @@
>>  @type source: string
>>  @param source_port: The port from which to send the message.
>>  The default is 0.
>> -@type source_port: int"""
>> +@type source_port: int
>> +@type ignore_unexpected: bool
>> +@param one_rr_per_rrset: If True, put each RR into its own
>> +RRset.
>> +@type one_rr_per_rrset: bool
>> +@param ignore_trailing: If True, ignore trailing
>> +junk at end of the received message.
>> +@type ignore_trailing: bool
>> +@param sock: the socket to use for the
>> +query.  If None, the default, a socket is created.  Note that
>> +if a socket is provided, it must be a nonblocking datagram socket,
>> +and the source and source_port are ignored.
>> +@type sock: socket.socket | None"""
>>  
>>  wire = q.to_wire()
>>  if af is None:
> 
> The doc for sock here looks like a copy/paste error from the udp case,
> and should be a TCP socket instead.
> 
> Looks like
> https://github.com/eventlet/eventlet/blob/master/eventlet/support/greendns.py#L861
> still has it wrong.
> 
>> @@ -810,7 +862,10 @@
>>  destination = (where, port, 0, 0)
>>  if source is not None:
>>  source = (source, source_port, 0, 0)
>> -s = socket.socket(af, socket.SOCK_STREAM)
>> +if sock:
>> +s = sock
>> +else:
>> +s = socket.socket(af, socket.SOCK_STREAM)
>>  s.settimeout(timeout)
>>  try:
>>  expiration = compute_expiration(dns.query, timeout)

I have to admit I don't really understand the above. :/
I just applied the patch that Filippo Giunchedi gave to me, and it
magically worked. (multiple users reported this)

> otherwise fine to go ahead.

Uploaded, thanks a lot, as this issue was really a huge concern for me.

Cheers,

Thomas Goirand (zigo)

Bug#1001263: logind: IdleAction=ignore not effective

[Andrea V]

Package: systemd
Version: 249.7-1
Severity: normal
X-Debbugs-Cc: andreakarim...@gmail.com

Dear Maintainer,

changing IdleAction options inside /etc/systemd/logind.conf does not
have any effect on automatic sleep. In addition, even specifying a
command that should explicitly prevent the system from going to sleep on
idle has also no effect:

# systemd-inhibit --what=idle bash -c 'sleep 999'
# systemd-inhibit --list
WHO  UID  USER   PIDCOMMWHAT WHY
   MODE 
ModemManager 0root   1213   ModemManagersleep
ModemManager needs to reset devices   delay
NetworkManager   0root   1150   NetworkManager  sleep
NetworkManager needs to turn off networks delay
Unattended Upgrades Shutdown 0root   1273   unattended-upgr shutdown Stop 
ongoing upgrades or perform upgrades before shutdown delay
bash -c sleep 9991000 karimo 2530   systemd-inhibit idle 
Unknown reasonblock

Bests!

-- Package-specific info:

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 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 systemd depends on:
ii  adduser  3.118
ii  libacl1  2.3.1-1
ii  libapparmor1 3.0.3-6
ii  libaudit11:3.0.6-1+b1
ii  libblkid12.37.2-4
ii  libc62.32-4
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.26-1
ii  libcryptsetup12  2:2.4.2-1
ii  libgcrypt20  1.9.4-4
ii  libgnutls30  3.7.2-2
ii  libgpg-error01.42-3
ii  libip4tc21.8.7-1
ii  libkmod2 29-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.37.2-4
ii  libpam0g 1.4.0-10
ii  libseccomp2  2.5.3-2
ii  libselinux1  3.3-1+b1
ii  libsystemd0  249.7-1
ii  libzstd1 1.4.8+dfsg-3
ii  mount2.37.2-4
ii  util-linux   2.37.2-4

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.12.20-3
ii  systemd-timesyncd [time-daemon]  249.7-1

Versions of packages systemd suggests:
ii  policykit-10.105-31
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   249.7-1
ii  libpam-systemd   249.7-1
ii  udev 249.7-1

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
SystemMaxUse=5G

/etc/systemd/logind.conf changed:
[Login]
IdleAction=ignore
IdleActionSec=120min


-- no debconf information

Bug#1001190: tracker.debian.org: news: emails: show Message-ID header, link to lists.d.o/msgid-search

[Raphael Hertzog]

Hi,

On Tue, 07 Dec 2021, Paul Wise wrote:
> Not necessarily, there are several options for this that would make it
> a very generic feature, some ideas:
> 
> When the List-Archive header exists and contains a URL, the link could
> be to that URL. This works for Debian lists and mailman lists and
> probably other types of lists too.

The tracker doesn't receive emails via mailing lists, it gets sent a
direct copy from the various services.

> distro-tracker could have a list of domains that are known to have
> Message-ID search URLs and then map the List-Id to those URLs.

What's the "domain" of an email message? The one from the sender?

> For domains that have no Message-ID search URLs but do have archive
> links for the Maintainer field, the link could be to just the top-level
> archive link used for the Maintainer field.

I don't see how this can be helpful if you have to look up the message on
your own.

> Once #1001254 is implemented, then the link could be to the DPT
> Message-ID search, in a similar way to how lists.d.o links to its
> Message-ID search from the Message-ID field in its archives.

This, however, is something that is clearly more in line with the logic
of distro tracker. I agree that a query to lookup a message-id could be
useful.

(And actually I am interested in tracking message-id of everything that
went through distro-tracker to be able to drop duplicates easily and/or
present other summary views to the respective maintainers)

> I think the options I presented above are generic enough to have a low
> enough cost. For cases not covered by them I think as a compromise, it
> would be reasonable to just show the Message-ID header with no link.

This is also reasonable, indeed.

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


signature.asc
Description: PGP signature