Bug#1023309: RFP: fawkes - privacy-preserving tool against facial recognition systems

[debian . gamess]

Package: wnpp
Severity: wishlist

* Package name: fawkes
   Version : 0.3
   Upstream Author : Shawn Shan
* URL : https://github.com/Shawn-Shan/fawkes
* License : BSD-3-Clause License
   Programming Lang: Python
   Description : privacy-preserving tool against facial recognition

Fawkes is a software tool that gives individuals the ability to limit
how unknown third parties can track them by building facial recognition
models out of their publicly available photos. At a high level, Fawkes
"poisons" models that try to learn what you look like, by putting hidden
changes into your photos, and using them as Trojan horses to deliver that
poison to any facial recognition models of you. Fawkes takes your personal
images and makes tiny, pixel-level changes that are invisible to the human
eye, in a process we call image cloaking. You can then use these "cloaked"
photos as you normally would, sharing them on social media, sending them
to friends, printing them or displaying them on digital devices, the same
way you would any other photo. The difference, however, is that if and
when someone tries to use these photos to build a facial recognition model,
"cloaked" images will teach the model an highly distorted version of what
makes you look like you. The cloak effect is not easily detectable by humans
or machines and will not cause errors in model training. However, when
someone tries to identify you by presenting an unaltered, "uncloaked" image
of you (e.g. a photo taken in public) to the model, the model will fail to
recognize you.

I'm not aware of any other similar tool in Debian.

--

Bug#981291: .deb packaging available by upstream developers

[debian . gamess]

The .deb packaging has been available for download for a while on the LibreWolf
website.

Bug#1023308: ncdu: please update ncdu package to upstream 2.2.1 version

[Jason Lewis]

Package: ncdu
Version: 1.17-0.1
Severity: wishlist

Dear Maintainer,

ncdu upstream is up to v2.2.1 now. please consider updating the debian 
package


thanks

Jason



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

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_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 ncdu depends on:
ii libc6 2.35-4
ii libncursesw6 6.3+20220423-2
ii libtinfo6 6.3+20220423-2

ncdu recommends no packages.

ncdu suggests no packages.

-- no debconf information

--
Jason Lewis
http://emacstragic.net

Bug#1023307: baresip is up to v2.9.0 upstream please consider updating the packages

[Jason Lewis]

Package: baresip
Severity: wishlist

Dear Maintainer,

Please consider packaging a newer version of baresip. it is up to v2.9.0 
upstream now.


thanks

Jason


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_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

--
Jason Lewis
http://emacstragic.net

Bug#999331: cl-pubmed: diff for NMU version 2.1.3-5.2

[Marcos Talau]

Control: tags 999331 + patch
Control: tags 999331 + pending


Dear maintainer,

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

Regards.
diff -u cl-pubmed-2.1.3/debian/changelog cl-pubmed-2.1.3/debian/changelog
--- cl-pubmed-2.1.3/debian/changelog
+++ cl-pubmed-2.1.3/debian/changelog
@@ -1,3 +1,10 @@
+cl-pubmed (2.1.3-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999331).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 23:44:03 -0300
+
 cl-pubmed (2.1.3-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u cl-pubmed-2.1.3/debian/rules cl-pubmed-2.1.3/debian/rules
--- cl-pubmed-2.1.3/debian/rules
+++ cl-pubmed-2.1.3/debian/rules
@@ -39,5 +39,7 @@
 
 binary: binary-indep
 
+build-arch: build
+build-indep: build
 
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#999165: cl-umlisp-orf: diff for NMU version 3.3.2-3.1

[Marcos Talau]

Control: tags 999165 + patch
Control: tags 999165 + pending


Dear maintainer,

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

Regards.
diff -Nru cl-umlisp-orf-3.3.2/debian/changelog cl-umlisp-orf-3.3.2/debian/changelog
--- cl-umlisp-orf-3.3.2/debian/changelog	2011-04-02 23:12:14.0 -0300
+++ cl-umlisp-orf-3.3.2/debian/changelog	2022-11-01 23:50:11.0 -0300
@@ -1,3 +1,10 @@
+cl-umlisp-orf (3.3.2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999165).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 23:50:11 -0300
+
 cl-umlisp-orf (3.3.2-3) unstable; urgency=low
 
   * Fix package description (closes:620524)
diff -Nru cl-umlisp-orf-3.3.2/debian/rules cl-umlisp-orf-3.3.2/debian/rules
--- cl-umlisp-orf-3.3.2/debian/rules	2009-08-03 23:29:25.0 -0300
+++ cl-umlisp-orf-3.3.2/debian/rules	2022-11-01 23:50:11.0 -0300
@@ -39,5 +39,7 @@
 
 binary: binary-indep
 
+build-arch: build
+build-indep: build
 
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#998994: cl-pipes: diff for NMU version 1.2.1-5.2

[Marcos Talau]

Control: tags 998994 + patch
Control: tags 998994 + pending


Dear maintainer,

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

Regards.
diff -u cl-pipes-1.2.1/debian/changelog cl-pipes-1.2.1/debian/changelog
--- cl-pipes-1.2.1/debian/changelog
+++ cl-pipes-1.2.1/debian/changelog
@@ -1,3 +1,10 @@
+cl-pipes (1.2.1-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998994).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 23:42:31 -0300
+
 cl-pipes (1.2.1-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u cl-pipes-1.2.1/debian/rules cl-pipes-1.2.1/debian/rules
--- cl-pipes-1.2.1/debian/rules
+++ cl-pipes-1.2.1/debian/rules
@@ -41,5 +41,7 @@
 
 binary: binary-indep
 
+build-arch: build
+build-indep: build
 
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#998971: cl-xlunit: diff for NMU version 0.6.3-2.2

[Marcos Talau]

Control: tags 998971 + patch
Control: tags 998971 + pending


Dear maintainer,

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

Regards.
diff -u cl-xlunit-0.6.3/debian/changelog cl-xlunit-0.6.3/debian/changelog
--- cl-xlunit-0.6.3/debian/changelog
+++ cl-xlunit-0.6.3/debian/changelog
@@ -1,3 +1,10 @@
+cl-xlunit (0.6.3-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998971).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 23:51:27 -0300
+
 cl-xlunit (0.6.3-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u cl-xlunit-0.6.3/debian/rules cl-xlunit-0.6.3/debian/rules
--- cl-xlunit-0.6.3/debian/rules
+++ cl-xlunit-0.6.3/debian/rules
@@ -41,5 +41,7 @@
 
 binary: binary-indep
 
+build-arch: build
+build-indep: build
 
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#998959: cl-xptest: diff for NMU version 1.2.4-3.2

[Marcos Talau]

Control: tags 998959 + patch
Control: tags 998959 + pending


Dear maintainer,

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

Regards.
diff -u cl-xptest-1.2.4/debian/changelog cl-xptest-1.2.4/debian/changelog
--- cl-xptest-1.2.4/debian/changelog
+++ cl-xptest-1.2.4/debian/changelog
@@ -1,3 +1,10 @@
+cl-xptest (1.2.4-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998959).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 23:52:47 -0300
+
 cl-xptest (1.2.4-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u cl-xptest-1.2.4/debian/rules cl-xptest-1.2.4/debian/rules
--- cl-xptest-1.2.4/debian/rules
+++ cl-xptest-1.2.4/debian/rules
@@ -40,5 +40,7 @@
 
 binary: binary-indep
 
+build-arch: build
+build-indep: build
 
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#998935: cl-umlisp: diff for NMU version 1:2007ac.2-6.1

[Marcos Talau]

Control: tags 998935 + patch
Control: tags 998935 + pending


Dear maintainer,

I've prepared an NMU for cl-umlisp (versioned as 1:2007ac.2-6.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru cl-umlisp-2007ac.2/debian/changelog cl-umlisp-2007ac.2/debian/changelog
--- cl-umlisp-2007ac.2/debian/changelog	2011-04-03 01:10:11.0 -0300
+++ cl-umlisp-2007ac.2/debian/changelog	2022-11-01 23:48:37.0 -0300
@@ -1,3 +1,10 @@
+cl-umlisp (1:2007ac.2-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998935).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 23:48:37 -0300
+
 cl-umlisp (1:2007ac.2-6) unstable; urgency=low
 
   * debian/control: Fix typo in package description
diff -Nru cl-umlisp-2007ac.2/debian/rules cl-umlisp-2007ac.2/debian/rules
--- cl-umlisp-2007ac.2/debian/rules	2009-08-03 23:26:16.0 -0300
+++ cl-umlisp-2007ac.2/debian/rules	2022-11-01 23:48:37.0 -0300
@@ -40,5 +40,7 @@
 
 binary: binary-indep
 
+build-arch: build
+build-indep: build
 
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#999012: cl-photo: diff for NMU version 0.14-4.2

[Marcos Talau]

Control: tags 999012 + patch
Control: tags 999012 + pending


Dear maintainer,

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

Regards.
diff -u cl-photo-0.14/debian/changelog cl-photo-0.14/debian/changelog
--- cl-photo-0.14/debian/changelog
+++ cl-photo-0.14/debian/changelog
@@ -1,3 +1,10 @@
+cl-photo (0.14-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999012).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 23:41:10 -0300
+
 cl-photo (0.14-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u cl-photo-0.14/debian/rules cl-photo-0.14/debian/rules
--- cl-photo-0.14/debian/rules
+++ cl-photo-0.14/debian/rules
@@ -40,5 +40,7 @@
 
 binary: binary-indep
 
+build-arch: build
+build-indep: build
 
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#1023306: baresip is up to v2.9.0 upstream please consider updating the debian packages

[Jason Lewis]

Package: baresip
Severity: wishlist

Dear Maintainer,

Please consider packaging a newer version of baresip. it is up to v2.9.0 
upstream now.



thanks


Jason



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

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_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 baresip depends on:
pn baresip-core

Versions of packages baresip recommends:
pn baresip-ffmpeg
pn baresip-gstreamer
pn baresip-gtk
pn baresip-x11

baresip suggests no packages.

--
Jason Lewis
http://emacstragic.net

Bug#999079: cl-irc-logger: diff for NMU version 0.9.4-3.2

[Marcos Talau]

Control: tags 999079 + patch
Control: tags 999079 + pending


Dear maintainer,

I've prepared an NMU for cl-irc-logger (versioned as 0.9.4-3.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u cl-irc-logger-0.9.4/debian/changelog cl-irc-logger-0.9.4/debian/changelog
--- cl-irc-logger-0.9.4/debian/changelog
+++ cl-irc-logger-0.9.4/debian/changelog
@@ -1,3 +1,10 @@
+cl-irc-logger (0.9.4-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999079).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 23:06:40 -0300
+
 cl-irc-logger (0.9.4-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u cl-irc-logger-0.9.4/debian/rules cl-irc-logger-0.9.4/debian/rules
--- cl-irc-logger-0.9.4/debian/rules
+++ cl-irc-logger-0.9.4/debian/rules
@@ -40,5 +40,7 @@
 
 binary: binary-indep
 
+build-arch: build
+build-indep: build
 
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#999045: cl-lml: diff for NMU version 2.5.7-4.2

[Marcos Talau]

Control: tags 999045 + patch
Control: tags 999045 + pending


Dear maintainer,

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

Regards.
diff -u cl-lml-2.5.7/debian/changelog cl-lml-2.5.7/debian/changelog
--- cl-lml-2.5.7/debian/changelog
+++ cl-lml-2.5.7/debian/changelog
@@ -1,3 +1,10 @@
+cl-lml (2.5.7-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999045).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 23:14:05 -0300
+
 cl-lml (2.5.7-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u cl-lml-2.5.7/debian/rules cl-lml-2.5.7/debian/rules
--- cl-lml-2.5.7/debian/rules
+++ cl-lml-2.5.7/debian/rules
@@ -41,5 +41,7 @@
 
 binary: binary-indep
 
+build-arch: build
+build-indep: build
 
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#998990: cl-lml2: diff for NMU version 1.6.6-4.2

[Marcos Talau]

Control: tags 998990 + patch
Control: tags 998990 + pending


Dear maintainer,

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

Regards.
diff -u cl-lml2-1.6.6/debian/changelog cl-lml2-1.6.6/debian/changelog
--- cl-lml2-1.6.6/debian/changelog
+++ cl-lml2-1.6.6/debian/changelog
@@ -1,3 +1,10 @@
+cl-lml2 (1.6.6-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998990).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 23:15:58 -0300
+
 cl-lml2 (1.6.6-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u cl-lml2-1.6.6/debian/rules cl-lml2-1.6.6/debian/rules
--- cl-lml2-1.6.6/debian/rules
+++ cl-lml2-1.6.6/debian/rules
@@ -41,5 +41,7 @@
 
 binary: binary-indep
 
+build-arch: build
+build-indep: build
 
-.PHONY: build clean binary-arch binary-indep binary install
+.PHONY: build build-arch build-indep clean binary-arch binary-indep binary install

Bug#998973: cl-pg: diff for NMU version 1:20061216-6.1

[Marcos Talau]

Control: tags 998973 + patch
Control: tags 998973 + pending


Dear maintainer,

I've prepared an NMU for cl-pg (versioned as 1:20061216-6.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru cl-pg-20061216/debian/changelog cl-pg-20061216/debian/changelog
--- cl-pg-20061216/debian/changelog	2018-04-07 13:25:47.0 -0300
+++ cl-pg-20061216/debian/changelog	2022-11-01 23:32:08.0 -0300
@@ -1,3 +1,10 @@
+cl-pg (1:20061216-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998973).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 23:32:08 -0300
+
 cl-pg (1:20061216-6) unstable; urgency=medium
 
   * Team upload.
diff -Nru cl-pg-20061216/debian/rules cl-pg-20061216/debian/rules
--- cl-pg-20061216/debian/rules	2018-04-07 13:25:09.0 -0300
+++ cl-pg-20061216/debian/rules	2022-11-01 23:32:08.0 -0300
@@ -59,4 +59,8 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure

Bug#998947: cl-modlisp: diff for NMU version 0.6-7.2

[Marcos Talau]

Control: tags 998947 + patch
Control: tags 998947 + pending


Dear maintainer,

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

Regards.
diff -u cl-modlisp-0.6/debian/changelog cl-modlisp-0.6/debian/changelog
--- cl-modlisp-0.6/debian/changelog
+++ cl-modlisp-0.6/debian/changelog
@@ -1,3 +1,10 @@
+cl-modlisp (0.6-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998947).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 23:30:21 -0300
+
 cl-modlisp (0.6-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u cl-modlisp-0.6/debian/rules cl-modlisp-0.6/debian/rules
--- cl-modlisp-0.6/debian/rules
+++ cl-modlisp-0.6/debian/rules
@@ -41,5 +41,7 @@
 
 binary: binary-indep binary-arch
 
+build-arch: build
+build-indep: build
 
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#998933: cgilib: diff for NMU version 0.6-1.2

[Marcos Talau]

Control: tags 998933 + patch
Control: tags 998933 + pending

Dear maintainer,

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

Regards.
diff -u cgilib-0.6/debian/changelog cgilib-0.6/debian/changelog
--- cgilib-0.6/debian/changelog
+++ cgilib-0.6/debian/changelog
@@ -1,3 +1,10 @@
+cgilib (0.6-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998933).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 22:55:50 -0300
+
 cgilib (0.6-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u cgilib-0.6/debian/rules cgilib-0.6/debian/rules
--- cgilib-0.6/debian/rules
+++ cgilib-0.6/debian/rules
@@ -119,3 +119,6 @@
 
-.PHONY: binary binary-arch binary-indep clean checkroot
+build-arch: build
+build-indep: build
+
+.PHONY: binary binary-arch binary-indep build build-arch build-indep clean checkroot
 

Bug#1003729: packages.debian.org: Still missing, worried for bullseye

[David Calman]

Package: www.debian.org
Followup-For: Bug #1003729
X-Debbugs-Cc: alt.people.davidcal...@gmail.com

Dear Maintainer,

It's still missing from packages.debian.org. I'm now worried that Bullseye
will be the same way.

Bug#1023305: ITP: zst -- CLI tool for zstd (and other) compression

[Adam Borowski]

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

* Package name: zst
  Version : not released yet
  Upstream Author : yours truly
* URL : https://github.com/kilobyte/zst
  Programming Lang: C
  Description : CLI tool for zstd (and other) compression

 This is an alternate tool for zstd compression, one that takes a lot
 less space than the official one.  It also behaves in a way consistent
 with other Unix compressors: the level goes only up to 9, the original
 copy of the file is not kept, etc.
 .
 The executable can also replace gzip xz bzip2.


A bunch of features are not yet ready, but I'm filing this ITP now that
the core functionality is already working but there's still time for
design changes.  Stuff that's aimed for important/Essential needs to
be discussed well...

Existing compressors:
  | tool | lib
--+--+-
gzip  | Ess  | Ess
bzip2 | std  | Ess (but it'd be nice to remove it)
xz| std  | Ess
zstd  | opt  | Ess
lz4   | opt  | libsystemd0 but not libelogind0

Bug#1017711: emacs-gtk: terminated with signal SIGABRT, 137 MB coredump

[Sean Whitton]

Hello,

On Tue 01 Nov 2022 at 11:17PM +01, Vincent Lefevre wrote:

> On 2022-10-31 15:59:17 +0100, Vincent Lefevre wrote:
>> Hi,
>>
>> On 2022-10-30 06:31:27 -0700, Sean Whitton wrote:
>> > I've backported a couple of patches from upstream related to native
>> > compilation, now, so would you be able to test again with the latest
>> > upload?  Thanks.
>>
>> If you mean 1:28.2+1-3, I still got the same issue. But it seems
>> that after a reboot, the problem no longer occurs (after removing
>> the .emacs.d directory). Was a reboot needed?
>
> Unfortunately, it has just occurred again (with emacs run by
> Subversion to enter a commit message).
>
> Core was generated by `/usr/bin/emacs -no-comp-spawn --batch -l 
> /tmp/emacs-async-comp-url.el-FGov4z.el'.
> Program terminated with signal SIGABRT, Aborted.
> #0  __pthread_kill_implementation (threadid=, 
> signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
> 44  ./nptl/pthread_kill.c: No such file or directory.
>
> I've attached the backtrace. Seems too many recursive calls to
> mark_object and mark_objects.
>
> Worse, not just a background emacs process, the UI also crashes
> (IIRC, this didn't happen before).

Thanks for following up.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#964540: dropwatch build times out in the testsuite

[Andreas Beckmann]

Control: severity -1 normal

On Wed, 8 Jul 2020 13:26:54 +0200 Matthias Klose  wrote:

Package: src:dropwatch
Version: 1.5.3-1



dropwatch build times out in the testsuite, no output available in the build 
log.


The 1.5.4-1 release built fine on the buildds for all release 
architectures. But there were testsuite timeouts on some ports 
architectures.



Andreas

Bug#1010648: marked as pending in golang-github-pierrec-lz4.v4

[Nicholas D Steeves]

Hi Eric!

Eric Evans  writes:

> This is now a blocker on a recent upstream release of
> golang-github-gocql-gocql as well.  I understand the argument about
> excluding test data, but there is probably a point at which users would be
> better served by a golang-github-pierrec-lz4.v4 without (complete) test
> coverage, than they would be without syncthing, or a modern gocql driver.
>

I agree 100%.

> Perhaps we move forward with a repackaged upstream tarball while waiting
> for upstream to fix these issues?
>

I did this 06 June 2022, where it waited for review until 06 Oct and was
rejected with specious rationale--namely that a Go reimplementation of
the C reference implementation of xxHash was a derived work under the
license of the reference implementation.  This is contrary to Debian
expectations, contrary to the consensus of the debian-legal mailing list
(speculating about license is a liability), and contrary to legal
precedent established in American courts (algorithms are patentable but
not copyrightable, APIs are neither)...  The ftpmaster reviewing this
package also expected me to misattribute the Go reimplementation to the
author of the reference implementation, under the BSD-2-clause license
of the reference implementation.  All of this should be archived on the
Debian Golang mailing list.

I think you'll need to contact ftpmasters about this issue, and about
how it now blocks gocql, because frankly I doubt the package will be
reviewed before the freeze.

https://ftp-master.debian.org/new/golang-github-pierrec-lz4.v4_4.1.14+dfsg-1.html

Feel free to make any changes; it's a team package, and my free time ran
out in September.

Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1023304: salsa: allow changing notifications for packages I maintain / am an uploader for

[Jelmer Vernooij]

Package: devscripts
Severity: wishlist

It would be great if there was a way to easily change the notifications for all 
salsa projects that I care about.

At the moment, I can subscribe to individual packages or change my global 
settings, but one is too fine grained and the other too broad.

Ideally I'd like to subscribe to a subset of packages - e.g. those I am 
uploader for or maintainer of, or that I ever uploaded.

A salsa subcommand seems ideal for this - it can query apt for relevant 
packages, resolve Vcs-Git URLs, then use the API to change notification 
settings.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#1022117: RFS: depthcharge-tools/0.6.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration

[Alper Nebi Yasak]

On 31/10/2022 00:52, Jérémy Lal wrote:
> Le dim. 30 oct. 2022 à 22:42, Jérémy Lal  a écrit :
>> Everything seems to be fine with your package.
>> It builds fine, is lintian-clean, copyright is ok, and best practices are
>> observed.
>>
>> Since it's a python program, it would make more sense to team-maintain it
>> in the python-team group.
>> I cloned your repo to
>> https://salsa.debian.org/python-team/packages/depthcharge-tools
>>
>> Now you need to request write access (developer role) to that repository.
>> Please have a look at https://wiki.debian.org/Teams/PythonTeam/HowToJoin
>>
>> After that, debian/control should be modified to be:
>> Maintainer: Alper Nebi Yasak 
>>  , Debian Python Team 
>> Vcs-Browser:
>> https://salsa.debian.org/python-team/packages/depthcharge-tools
>> Vcs-Git:
>> https://salsa.debian.org/python-team/packages/depthcharge-tools.git
>>
> 
> Also since python-team admins are busy, I've took the liberty to make the
> changes,
> slightly differently (see
> https://salsa.debian.org/python-team/packages/depthcharge-tools),
> and I uploaded your package to NEW.

Thanks! I sent an email to the debian-python list just now about joining
the Python team. I agree with your changes and points above, but didn't
want to put the team as Maintainer before getting an OK from them.

Bug#1023303: jhead 1:3.06.0.1-3 deletes EXIF data

[Stefan Pietsch]

Package: jhead
Version: 1:3.06.0.1-3
Severity: grave


jhead version 1:3.06.0.1-3 deletes EXIF data when rotating images:

$ exiftool IMG_20221102_000230.jpg | wc -l

77



$ jhead -autorot IMG_20221102_000230.jpg



Nonfatal Error : 'IMG_20221102_000230.jpg' Command has invalid characters.



$ exiftool IMG_20221102_000230.jpg | wc -l

23





jhead 1:3.06.0.1-2 is not affected.

Bug#1023302: subnetcalc: new upstream version

[Christoph Anton Mitterer]

Package: subnetcalc
Version: 2.4.19-1+b1
Severity: wishlist



Hey.

2.4.20 seems to be out :-)

Thanks and best wishes,
Chris

Bug#967987: fuzz: diff for NMU version 0.6-19.1

[Marcos Talau]

Control: tags 967987 + pending

Dear maintainer,

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

Regards.
diff -Nru fuzz-0.6/debian/changelog fuzz-0.6/debian/changelog
--- fuzz-0.6/debian/changelog	2020-09-28 09:32:35.0 -0300
+++ fuzz-0.6/debian/changelog	2022-11-01 19:09:03.0 -0300
@@ -1,3 +1,12 @@
+fuzz (0.6-19.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/30-glibc-2.32.patch: Fix FTBFS against glibc 2.32 by using
+strerror() instead of sys_errlist. Thanks to Logan Rosen .
+(Closes: #967987).
+
+ -- Marcos Talau   Tue, 01 Nov 2022 19:09:03 -0300
+
 fuzz (0.6-19) unstable; urgency=medium
 
   * debian/control:
diff -Nru fuzz-0.6/debian/patches/30-glibc-2.32.patch fuzz-0.6/debian/patches/30-glibc-2.32.patch
--- fuzz-0.6/debian/patches/30-glibc-2.32.patch	1969-12-31 21:00:00.0 -0300
+++ fuzz-0.6/debian/patches/30-glibc-2.32.patch	2022-11-01 19:09:03.0 -0300
@@ -0,0 +1,19 @@
+Description: Fix FTBFS against glibc 2.32
+Author: Logan Rosen 
+Bug-Debian: https://bugs.debian.org/967987
+Forwarded: https://sourceforge.net/p/fuzz/bugs/6
+Last-Update: 2022-11-01
+
+Index: fuzz-0.6/fuzz.c
+===
+--- fuzz-0.6.orig/fuzz.c
 fuzz-0.6/fuzz.c
+@@ -814,7 +814,7 @@ void do_child(int *progpipe, char **argv
+ 
+   execv(progname,arguments);
+   write(cpy_stderr,"Exec failed.\n",strlen("Exec failed.\n"));
+-  write(cpy_stderr,sys_errlist[errno],strlen(sys_errlist[errno]));
++  write(cpy_stderr,strerror(errno),strlen(strerror(errno)));
+   exit(CANT_FORK_EXIT);
+ }
+ 
diff -Nru fuzz-0.6/debian/patches/series fuzz-0.6/debian/patches/series
--- fuzz-0.6/debian/patches/series	2016-10-19 04:16:45.0 -0200
+++ fuzz-0.6/debian/patches/series	2022-11-01 19:09:03.0 -0300
@@ -1,3 +1,4 @@
 10-fuzz.1-manpage-fixes.patch
 10-fuzz.1-manpage-fixes=11-newlines.patch
 20-fuzz.c--option-chroot.patch
+30-glibc-2.32.patch

Bug#1005326: no-code-sections triggered on non-ELF files

[Daniel Kahn Gillmor]

On Fri 2022-02-11 12:51:06 -0800, Felix Lechner wrote:
> I confirmed that Lintian's invocation produces that error for
> usr/lib/dxvk/wine64-development/d3d10.dll.a in dxvk, but how can we
> tell such archives apart from those that are legitimately broken?

This error is also mistakenly produced for libassuan-mingw-w64-dev (used
for cross-building gpgv.exe as part of a windows installer signature
verification tool):

E: libassuan-mingw-w64-dev: no-code-sections 
[usr/i686-w64-mingw32/lib/libassuan.a]
E: libassuan-mingw-w64-dev: no-code-sections 
[usr/i686-w64-mingw32/lib/libassuan.dll.a]
E: libassuan-mingw-w64-dev: no-code-sections 
[usr/x86_64-w64-mingw32/lib/libassuan.a]
E: libassuan-mingw-w64-dev: no-code-sections 
[usr/x86_64-w64-mingw32/lib/libassuan.dll.a]


   --dkg


signature.asc
Description: PGP signature

Bug#1022289: [pkg-gnupg-maint] Bug#1022289: libassuan: FTBFS: configure: error: libgpg-error was not found

[Daniel Kahn Gillmor]

Hi Andreas--

Thanks for this.  I'm wrapping this up with a few other lintian fixes
and i should have a released version in unstable by later today or
tomorrow.

Thanks for helping out here!

--dkg

On Tue 2022-11-01 14:10:36 +0100, Andreas Metzler wrote:
> On 2022-10-23 Andreas Metzler  wrote:
> [...]
>> Caused by new gpg-error dropping gpg-error-config, this works for me:
>
>> --- libassuan-2.5.5/debian/rules2022-04-30 17:47:12.0 +0200
>> +++ patched/libassuan-2.5.5.patched/debian/rules2022-10-23 
>> 18:23:40.505849321 +0200
>> @@ -27,7 +27,6 @@
>> for cpu in i686 x86_64; do \
>>  mkdir -p build-$$cpu-w64-mingw32 && \
>>  cd build-$$cpu-w64-mingw32 && $(WIN_FLAGS) ../configure \
>> -   --with-libgpg-error-prefix=/usr/$$cpu-w64-mingw32 \
>
> Hello,
>
> Commited to GIT, please give me a heads up if you want me to make either
> a NMU or add myself to Uploaders and make a regular upload. (Although
> this is a serious bugreport I do not think it is yet so urgent to
> require a upload without maintainer feedback. - Might change, e.g if
> libassuan blocked a transition.)
>
> cu Andreas
> -- 
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
> ___
> pkg-gnupg-maint mailing list
> pkg-gnupg-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-gnupg-maint


signature.asc
Description: PGP signature

Bug#1023301: Krita 4.4.2 reports support for an invalid MIME type: jpeg/jfif

[Grzegorz Szymaszek]

Package: krita
Version: 1:4.4.2+dfsg-1
Severity: minor

Dear Maintainer,

The Krita 4.4.2 package contains a Desktop Entry file krita_jpeg.desktop
that has "jpeg/jfif" set as one of the supported MIME types. Since it is
not a valid type, it causes update-desktop-database(1) (and most likely
other tools) to report an error.

This is an upstream bug[1], introduced in March 2020[2], that is already
fixed upstream[3] in Krita 4.4.7[4]. Please consider backporting the fix
to the Debian bullseye krita package.

[1]: https://bugs.kde.org/show_bug.cgi?id=424888
[2]: 
https://invent.kde.org/graphics/krita/-/commit/e1735d0654a0fbd761658172dc2d79758d01c2a3
[3]: https://invent.kde.org/graphics/krita/-/merge_requests/663
[4]: 
https://invent.kde.org/graphics/krita/-/commit/5f84290b7ce98c37de589aa7925f27ebfc4353a0


All the best

-- 
Grzegorz


signature.asc
Description: PGP signature

Bug#1017711: emacs-gtk: terminated with signal SIGABRT, 137 MB coredump

[Vincent Lefevre]

On 2022-10-31 15:59:17 +0100, Vincent Lefevre wrote:
> Hi,
> 
> On 2022-10-30 06:31:27 -0700, Sean Whitton wrote:
> > I've backported a couple of patches from upstream related to native
> > compilation, now, so would you be able to test again with the latest
> > upload?  Thanks.
> 
> If you mean 1:28.2+1-3, I still got the same issue. But it seems
> that after a reboot, the problem no longer occurs (after removing
> the .emacs.d directory). Was a reboot needed?

Unfortunately, it has just occurred again (with emacs run by
Subversion to enter a commit message).

Core was generated by `/usr/bin/emacs -no-comp-spawn --batch -l 
/tmp/emacs-async-comp-url.el-FGov4z.el'.
Program terminated with signal SIGABRT, Aborted.
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: No such file or directory.

I've attached the backtrace. Seems too many recursive calls to
mark_object and mark_objects.

Worse, not just a background emacs process, the UI also crashes
(IIRC, this didn't happen before).

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

Thread 1 (Thread 0x7f5b914cb380 (LWP 35005)):
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
tid = 
ret = 0
pd = 
old_mask = {__val = {0 }}
ret = 
#1  0x7f5b922895df in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7f5b9223da02 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
ret = 
#3  0x55fdfd114864 in terminate_due_to_signal (sig=sig@entry=6, 
backtrace_limit=backtrace_limit@entry=40) at ./debian/build-src/src/emacs.c:437
#4  0x55fdfd114d27 in emacs_abort () at ./debian/build-src/src/sysdep.c:2282
#5  0x55fdfd111e99 in check_message_stack () at 
./debian/build-src/src/xdisp.c:12157
#6  0x55fdfd20492a in shut_down_emacs (sig=0, stuff=0x0) at 
./debian/build-src/src/emacs.c:2789
tpgrp = 
#7  0x55fdfd114765 in Fkill_emacs (arg=arg@entry=0x6) at 
./debian/build-src/src/emacs.c:2692
exit_code = 
#8  0x55fdfd114827 in terminate_due_to_signal (sig=sig@entry=1, 
backtrace_limit=backtrace_limit@entry=40) at ./debian/build-src/src/emacs.c:417
#9  0x55fdfd114d00 in handle_fatal_signal (sig=sig@entry=1) at 
./debian/build-src/src/sysdep.c:1762
#10 0x55fdfd114d17 in deliver_process_signal (handler=0x55fdfd114cf5 
, sig=1) at ./debian/build-src/src/sysdep.c:1720
old_errno = 2
on_main_thread = true
#11 deliver_fatal_signal (sig=1) at ./debian/build-src/src/sysdep.c:1768
#12 0x7f5b9223daa0 in  () at 
/lib/x86_64-linux-gnu/libc.so.6
#13 0x55fdfd2641c3 in mark_object (arg=0x295d90329a68) at 
./debian/build-src/src/alloc.c:6628
obj = 0x295d90329a68
po = 
cdr_count = 0
#14 0x55fdfd26528e in mark_objects (n=3, obj=0x7f5b8e029930) at 
./debian/build-src/src/alloc.c:6607
i = 0
ptr = 0x7f5b8e029928
size = 3
#15 mark_vectorlike (header=0x7f5b8e029928) at 
./debian/build-src/src/alloc.c:6382
ptr = 0x7f5b8e029928
size = 3
#16 0x55fdfd26528e in mark_objects (n=3, obj=0x7f5b8e0298c0) at 
./debian/build-src/src/alloc.c:6607
i = 2
ptr = 0x7f5b8e0298b8
size = 3
#17 mark_vectorlike (header=0x7f5b8e0298b8) at 
./debian/build-src/src/alloc.c:6382
ptr = 0x7f5b8e0298b8
size = 3
#18 0x55fdfd26528e in mark_objects (n=711, obj=0x7f5b8e027fc8) at 
./debian/build-src/src/alloc.c:6607
i = 614
ptr = 0x7f5b8e027fc0
size = 711
#19 mark_vectorlike (header=0x7f5b8e027fc0) at 
./debian/build-src/src/alloc.c:6382
ptr = 0x7f5b8e027fc0
size = 711
#20 0x55fdfd26528e in mark_objects (n=7, obj=0x7f5b8da7eab8) at 
./debian/build-src/src/alloc.c:6607
i = 5
ptr = 0x7f5b8da7eab0
size = 7
#21 mark_vectorlike (header=0x7f5b8da7eab0) at 
./debian/build-src/src/alloc.c:6382
ptr = 0x7f5b8da7eab0
size = 7
#22 0x55fdfd2646ed in mark_object (arg=) at 
./debian/build-src/src/alloc.c:6787
subr = 0x7f5b8df6d260
ptr = 0x7f5b8df6d260
pvectype = 
obj = 0x7f5b8df6d265
po = 0x7f5b8df6d260
cdr_count = 0
#23 0x55fdfd2642d3 in mark_object (arg=) at 
./debian/build-src/src/alloc.c:6815
ptr = 0x7f5b8df6d230
obj = 
po = 0x7f5b8df6d230
cdr_count = 
#24 0x55fdfd26528e in mark_objects (n=5, obj=0x55fdff0253d8) at 
./debian/build-src/src/alloc.c:6607
i = 3
ptr = 0x55fdff0253d0
size = 5
#25 mark_vectorlike (header=0x55fdff0253d0) at 
./debian/build-src/src/alloc.c:6382
ptr = 0x55fdff0253d0
size = 5
#26 0x55fdfd2642d3 in mark_object (arg=) at 

Bug#1023300: RFP: elixir-evacuated-phoenix -- Peace of mind from prototype to production (evacuated from NSA/Microsoft Github)

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist
* Package name:  elixir-evacuated-phoenix
  Upstream Author :   Chris McCord
* URL :
https://git.freecumextremist.com/themusicgod1/evacuated-phoenix
* License : MIT
  Programming Lang: elixir
  Description :  Elixir Web Framework targeting full-featured,
fault tolerant applications with realtime functionality

elixir-evacuated-phoenix is a dependency of pleroma/based ( #895050 )

Bug#1023299: ganeti-testsuite: yaml.load in testsuite needs to specify loader

[Scott Kitterman]

Source: ganeti-testsuite
Version: 3.0.2-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Previously yaml.load did not require a loader to be specified:

load(stream, Loader=None)

Now it does (starting in pyyaml 6.0):

load(stream, Loader)

Ganeti-testsuit uses yaml.load without specifying a loader, which now
causes a test failure in unstable.  Due to ganeti not being buildable
currently, it's not possible to fix this at the moment.

Note: Using FTBFS as a tag since that's the closest thing we have to a
test failure that would prevent migration.

Scott K

Bug#1023298: linux: FTBFS on arm64 and armhf (ABI changes)

[Salvatore Bonaccorso]

Source: linux
Version: 6.0.6-2
Severity: serious
Justification: FTBFS
X-Debbugs-Cc: car...@debian.org

Documenting the build failures on arm64 and armhf due to ABI changes:

https://buildd.debian.org/status/fetch.php?pkg=linux=arm64=6.0.6-2=1667324068=0
https://buildd.debian.org/status/fetch.php?pkg=linux=armhf=6.0.6-2=1667316319=0

Regards,
Salvatore

Bug#291823: marked as done (cruft: some tool inspecting reports hierarchically)

[Alexandre Detiste]

So for the record I went here with NCDU instead of MC.

It looks great.

Here's how to invoque it:

cpigs -e | ncdu -f -

in the future "cpigs" could automagical detect that stdout is a TTY and in
this case launch ncdu itself,
for more convenience. This could be overridden by "cpigs -e | cat".

[image: Screenshot_20221101_201911.png]

Bug#1010648: marked as pending in golang-github-pierrec-lz4.v4

[Eric Evans]

[ Nicholas D Steeves ]
> Upload rejected because ftpmasters did not accept that the public domain
> works had been implicitly relicensed by upstream as BSD-3-clause,
> because I missed one Linux kernel image file in the test data (which
> needs source to be DFSG free and for license compliance; this one is
> admittedly serious), and because there was some incredulity about the
> licensing of other test data.  With the exception of the Linux kernel
> image (absent in v2), the licensing of same test data was not considered
> a problem for golang-github-pierrec-lz4 (v2).
> 
> So for now progress towards fulfilling this ITP is blocked, and thus
> progress towards Syncthing 1.19.2 is blocked.  I believe it would be
> unwise to exclude all test data from a +dfsg orig tarball (and disable
> the tests), because this would expose Syncthing users' data to greater
> potential risk than using an older version of Syncthing with a
> golang-github-pierrec-lz4 (v2) with CI coverage.

This is now a blocker on a recent upstream release of
golang-github-gocql-gocql as well.  I understand the argument about
excluding test data, but there is probably a point at which users would be
better served by a golang-github-pierrec-lz4.v4 without (complete) test
coverage, than they would be without syncthing, or a modern gocql driver.

Perhaps we move forward with a repackaged upstream tarball while waiting
for upstream to fix these issues?

Cheers,

-- 
Eric Evans
eev...@debian.org


signature.asc
Description: PGP signature

Bug#1023297: src:emacs: fails to migrate to testing for too long: unresolved RC issues

[Paul Gevers]

Source: emacs
Version: 1:27.1+1-3.1
Severity: serious
Control: close -1 1:28.2+1-3
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1017711 1020258

Dear maintainer(s),

[I know you probably know I understand the delay, but to be transparent 
I'm filing this bug anyways. emacs is a key package so will not be 
autoremoved.]


The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:emacs has been trying to migrate for 74 
days [2]. Hence, I am filing this bug.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#986324: soci: libsoci-dev needs Depends: on libboost1.74-dev

[Bill Blough]

Hi Dennis,

On Sun, Oct 30, 2022 at 09:04:41AM +0100, Dennis Filder wrote:

> (Reply is late as I wasn't CC'ed)
Apologies - I meant to CC you, but apparently forgot.


> BTW: If #1021125 is still open by 2022-11-07 we'll probably NMU it
> (it's just a soversion bump/library package rename).

Please feel free to NMU at your convenience. I'm going to be very busy
this week, and it's unlikely that I will get to it in time.


Best regards,

Bill

Bug#1023296: plasma-workspace: ssh-agent not working in KDE Plasma Wayland session

[Ralf Jung]

Package: plasma-workspace
Version: 4:5.26.0-2
Severity: normal

Dear Maintainer,

when I start a KDE Plasma Wayland session, the ssh-agent is not working: 
attempting to load my SSH key into the agent (in Konsole via ssh-add) fails 
saying
"Could not open a connection to your authentication agent."

This is probably caused by the fact that the SSH_AUTH_SOCK env var is not set. 
(I am now setting it in my .bashrc to work around the issue.)
I have no idea how that env var is *supposed* to end up in the plasma session, 
but whatever mechanism is supposed to achieve that is not working.
I can see that ssh-agent comes with a systemd user service, which is setting 
the required variable in "dbus-update-activation-environment", so maybe KDE is 
somehow supposed to fetch that and that is not working?
Or maybe it's something else entirely. From feedback I got on IRC, it seems 
other distros have special ssh-agent scripts in /etc/xdg/plasma-workspace/env/, 
but I don't know if that is something standard.

Kind regards,
Ralf

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

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
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 plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus]1.14.4-1
ii  drkonqi 5.26.0-2
ii  frameworkintegration5.98.0-1
ii  gdb 12.1-3
ii  init-system-helpers 1.65.2
ii  iso-codes   4.11.0-1
ii  kactivitymanagerd   5.26.0-1
ii  kded5   5.98.0-1
ii  kinit   5.98.0-1
ii  kio 5.98.0-1
ii  kpackagetool5   5.98.0-1
ii  kwin-common 4:5.26.0-1
ii  libappstreamqt2 0.15.5-1
ii  libc6   2.35-4
ii  libcolorcorrect54:5.26.0-2
ii  libcrypt1   1:4.4.28-2
ii  libfontconfig1  2.13.1-4.5
ii  libfreetype62.12.1+dfsg-3
ii  libgcc-s1   12.2.0-3
ii  libgps283.22-4.1+b1
ii  libice6 2:1.0.10-1
ii  libicu7171.1-3
ii  libkf5activities5   5.98.0-1
ii  libkf5activitiesstats1  5.98.0-1
ii  libkf5archive5  5.98.0-1
ii  libkf5authcore5 5.98.0-1
ii  libkf5baloo55.98.0-1+b1
ii  libkf5bookmarks55.98.0-1
ii  libkf5calendarevents5   5.98.0-2
ii  libkf5completion5   5.98.0-1
ii  libkf5config-bin5.98.0-2
ii  libkf5configcore5   5.98.0-2
ii  libkf5configgui55.98.0-2
ii  libkf5configwidgets55.98.0-1
ii  libkf5coreaddons5   5.98.0-1
ii  libkf5crash55.98.0-1
ii  libkf5dbusaddons5   5.98.0-1
ii  libkf5declarative5  5.98.0-2
ii  libkf5globalaccel-bin   5.98.0-1
ii  libkf5globalaccel5  5.98.0-1
ii  libkf5guiaddons55.98.0-2
ii  libkf5holidays5 1:5.98.0-1
ii  libkf5i18n5 5.98.0-1+b1
ii  libkf5iconthemes5   5.98.0-2+b1
ii  libkf5idletime5 5.98.0-1
ii  libkf5jobwidgets5   5.98.0-1
ii  libkf5kcmutils5 5.98.0-1
ii  libkf5kexiv2-15.0.0 21.12.3-1
ii  libkf5kiocore5  5.98.0-1
ii  libkf5kiofilewidgets5   5.98.0-1
ii  libkf5kiogui5   5.98.0-1
ii  libkf5kiowidgets5   5.98.0-1
ii  libkf5networkmanagerqt6 

Bug#1023295: ITP: python-twomemo -- python-omemo backend for OMEMO 2

[Martin]

Package: wnpp
Owner: deba...@debian.org
Severity: wishlist

* Package name: python-twomemo
  Version : (no release yet)
  Upstream Author : Tim Henkes (Syndace) 
* URL or Web page : https://github.com/Syndace/python-twomemo
* License : MIT
  Programming Lang: Python
  Description : python-omemo backend for OMEMO 2

Backend implementation for python-omemo, equipping python-omemo with
support for OMEMO under the namespace urn:xmpp:omemo:2
(casually/jokingly referred to as "twomemo").

Bug#1023294: ITP: python-oldmemo -- python-omemo backend for OMEMO 1

[From]

Package: wnpp
Owner: deba...@debian.org
Severity: wishlist

* Package name: python-oldmemo
  Version : (no release yet)
  Upstream Author : Tim Henkes (Syndace) 
* URL or Web page : https://github.com/Syndace/python-oldmemo
* License : AGPL-3
  Programming Lang: Python
  Description : python-omemo backend for OMEMO 1

Backend implementation for python-omemo, equipping python-omemo with
support for OMEMO under the namespace eu.siacs.conversations.axolotl
(casually/jokingly referred to as "oldmemo").

Bug#1023293: ITP: libxeddsa -- toolkit around Curve25519 and Ed25519 key pairs

[Martin]

Package: wnpp
Owner: deba...@debian.org
Severity: wishlist

* Package name: libxeddsa
  Version : v2.0.0 (2022-04-02)
  Upstream Author : Tim Henkes (Syndace) 
* URL or Web page : https://github.com/Syndace/libxeddsa
* License : MIT
  Programming Lang: C
  Description : toolkit around Curve25519 and Ed25519 key pairs

A toolkit around Curve25519 and Ed25519 key pairs, with a focus on
conversion between the two.

Offers:

 - Conversion between Curve25519 and Ed25519 public keys
 - Extraction of private keys from seeds
 - Ed25519 digital signing using seeds or private keys
 - Ed25519 digital signature verification
 - X25519 Diffie-Hellman key agreement

Bug#1023286: fakeroot doesn't wrap __stat64_time64 (and friends) introduced by glibc 2.34 on 32 bit arches

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Clint Adams (2022-11-01 20:10:34)
> On Tue, Nov 01, 2022 at 07:44:05PM +0100, Johannes Schauer Marin Rodrigues 
> wrote:
> > the normal user "user" which suggests to me that the function is not
> > wrapped by fakeroot even though it should. Other functions that might be
> > interesting from glibc 2.34 and might need wrapping are
> > __fstatat64_time64 and __lstat64_time64.
> 
> If we only need to wrap the form with _time64 and not the one without, it
> should be easy to add that to the WRAPPED for loop in configure.ac .

only the form with _time64 is needed. On 64bit, __stat64_time64 is not used but
just a simple stat() is done. I've had to wrap the same functions on 32 bit
only in fakechroot as well

https://github.com/dex4er/fakechroot/pull/108

Do you have a patch for fakeroot that I can try?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1022144: Acknowledgement (gnome-todo: keeps crashing)

[Phil Dibowitz]

I filed an upstream bug here:

https://gitlab.gnome.org/World/Endeavour/-/issues/486

--
Phil Dibowitz p...@ipom.com
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't
 matter and those who matter don't mind."
 - Dr. Seuss

Bug#1013158: facet-analyser: vtk[6,7] removal

[Anton Gladky]

Hi Picca,

I have just successfully cloned the git-repo. I have only got a warning
"[attr]our-c-style   whitespace=tab-in-indent  format.clang-format=9 n"
but I thinking it is not critical.

Please try to checkout it again. Maybe it was salsa issue?

Regards

Anton


Am Di., 1. Nov. 2022 um 10:18 Uhr schrieb PICCA Frederic-Emmanuel <
frederic-emmanuel.pi...@synchrotron-soleil.fr>:

> Hello Anton, I try to checkout paraview in order to add the -dev
> dependencies
>
> but I have this message
>
> $ git clone https://salsa.debian.org/science-team/paraview
> Clonage dans 'paraview'...
> remote: Enumerating objects: 175624, done.
> remote: Counting objects: 100% (78929/78929), done.
> remote: Compressing objects: 100% (38687/38687), done.
> remote: Total 175624 (delta 47039), reused 65625 (delta 39190),
> pack-reused 96695
> Réception d'objets: 100% (175624/175624), 246.21 Mio | 12.11 Mio/s, fait.
> Résolution des deltas: 100% (109096/109096), fait.
> [attr]our-c-style  whitespace=tab-in-indent,-blank-at-eol
> format.clang-format non permis :
> ThirdParty/QtTesting/vtkqttesting/.gitattributes : 8
> [attr]our-c-style  whitespace=tab-in-indent,-blank-at-eol
> format.clang-format=9 non permis :
> ThirdParty/catalyst/vtkcatalyst/catalyst/.gitattributes : 4
> [attr]our-c-style  whitespace=tab-in-indent,-blank-at-eol
> format.clang-format=8 non permis : VTK/.gitattributes : 10
> [attr]our-c-style   whitespace=tab-in-indent  format.clang-format=9 non
> permis : VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/.gitattributes : 2
> Mise à jour des fichiers: 100% (30828/30828), fait.
> [attr]our-c-style  whitespace=tab-in-indent,-blank-at-eol
> format.clang-format=8 non permis : VTK/.gitattributes : 10
> [attr]our-c-style   whitespace=tab-in-indent  format.clang-format=9 non
> permis : VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/.gitattributes : 2
> Downloading VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/README.md (643 B)
> Error downloading object: VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/README.md
> (b30a14a): Smudge error: Error downloading
> VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/README.md
> (b30a14a308f64c6fc2969e2b959d79dacdc5affda1d1c0e24f8e176304147146):
> [b30a14a308f64c6fc2969e2b959d79dacdc5affda1d1c0e24f8e176304147146] Object
> does not exist on the server or you don't have permissions to access it:
> [404] Object does not exist on the server or you don't have permissions to
> access it
>
> Errors logged to
> /home/experiences/instrumentation/picca/debian/science-team/paraview/.git/lfs/logs/20221101T101535.441130442.log
> Use `git lfs logs last` to view the log.
> error: le filtre externe 'git-lfs filter-process' a échoué
> fatal: VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/README.md : le filtre smudge
> 'lfs' a échoué
> warning: Le clone a réussi, mais l'extraction a échoué.
> Vous pouvez inspecter ce qui a été extrait avec 'git status'
> et réessayer avec 'git restore --source=HEAD :/'
>

Bug#1023292: msmtp: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: msmtp
Version: 1.8.22-1
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for msmtp
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of msmtp debconf templates to German
# Copyright (C) Stefan Bauer , 2007.
# This file is distributed under the same license as the msmtp package.
# Helge Kreutzmann , 2021,2022.
#
msgid ""
msgstr ""
"Project-Id-Version: : msmtp 1.8.22-1\n"
"Report-Msgid-Bugs-To: ms...@packages.debian.org\n"
"POT-Creation-Date: 2022-10-27 23:33+\n"
"PO-Revision-Date: 2022-11-01 10:20+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../msmtp.templates:1001
msgid "Enable AppArmor support?"
msgstr "AppArmor-Unterstützung aktivieren?"

#. Type: boolean
#. Description
#: ../msmtp.templates:1001
msgid ""
" Apparmor is a kernel security mechanism to restrict programs capabilities\n"
" with per-program profiles.\n"
" .\n"
" The AppArmor profile for msmtp covers a lot of common usecases but there "
"are\n"
" still corner cases with some options which breaks msmtp with "
"incomprehensible\n"
" permissions denied errors."
msgstr ""
" Apparmor ist ein Kernel-Sicherheitsmechanismus, um Programm-Capabilitys\n"
" mit programmbezogenen Profilien zu beschränken.\n"
" .\n"
" Das AppArmor-Profil für Msmtp handelt eine ganze Reihe von typischen\n"
" Anwendungsszenarien ab, aber es gibt noch Randfälle bei einigen Optionen,\n"
" wodurch Msmtp mit unverständlichen „Berechtigungen verweigert“-Meldungen\n"
" fehlschlägt."

#. Type: error
#. Description
#: ../msmtp.templates:2001
msgid "Remove SetGID bit on msmtp"
msgstr "SetGID-Bit bei msmtp entfernen"

#. Type: error
#. Description
#: ../msmtp.templates:2001
msgid ""
" Starting from version 1.8.22, msmtp will no longer be SetGID. Hence the\n"
" creation of the system-wide configuration (/etc/msmtprc) using debconf is\n"
" removed.\n"
" .\n"
" From one side, using the system wide configuration implied msmtp to be "
"SetGID\n"
" but recent security hardening changes in GLib prevent SetGID binaries "
"built\n"
" against libsecret to talk to the D-Bus session, and therefore prevent it "
"from\n"
" being able to retrieve passwords from gnome-keyring or KWallet.\n"
" .\n"
" On another side, it was easy for a local user to obtain the credentials\n"
" stored in /etc/msmtprc even if the file was not readable for this user "
"when\n"
" msmtp was SetGid.\n"
" .\n"
" More information in the following bug reports:\n"
"   - https://bugs.debian.org/944188\n;
"   - https://bugs.debian.org/995012;
msgstr ""
" Beginnend mit Version 1.8.22 wird msmtp nicht mehr SetGID sein. Daher wurde\n"
" die Erstellung einer systemweiten Konfiguration (/etc/msmtprc) mittels\n"
" Debconf entfernt.\n"
" .\n"
" Einerseits impliziert die Verwendung der systemweiten Konfiguration SetGID,\n"
" aber kürzliche Sicherheitshärtungsänderungen in GLib hindern SetGID-\n"
" Programme, die gegen libsecret gebaut wurden, daran, mit D-Bus-Sitzungen zu\n"
" kommunizieren und verhindern damit, dass sie in der Lage sind, Passwörter\n"
" vom gnome-keyring oder KWallet abzurufen.\n"
" .\n"
" Andererseits war es für den lokalen Benutzer leicht, die in /etc/msmtprc\n"
" gespeicherten Zugangsberechtigungen zu erlangen, selbst falls die Datei für\n"
" diesen Benutzer nicht lesbar war, wenn msmtp SetGid war.\n"
" .\n"
" Weitere Informationen finden Sie in den folgenden Fehlerberichten:\n"
"   - https://bugs.debian.org/944188\n;
"   - https://bugs.debian.org/995012;

#~ msgid "Create a system wide configuration file?"
#~ msgstr "Soll eine systemweite Konfigurationsdatei erstellt werden?"

#~ msgid ""
#~ "msmtp has a sendmail emulation mode which allow to create a default "
#~ "system account that can be used by any user."
#~ msgstr ""
#~ "msmtp verfügt über einen sendmail-Emulationsmodus, welcher es erlaubt, "
#~ "ein Standard-Systemkonto anzulegen, das von jedem Benutzer verwendet "
#~ "werden kann."

#~ msgid "SMTP server hostname:"
#~ msgstr "SMTP-Servername:"

#~ msgid "SMTP port number:"
#~ msgstr "SMTP-Portnummer:"

#~ msgid "Generate an envelope-from address?"
#~ msgstr "Erstelle eine envelope-from-Adresse?"

#~ msgid ""
#~ "msmtp can generate an envelope-from address based on the login name and "
#~ "the \"maildomain\" configuration variable."
#~ msgstr ""
#~ "msmtp kann eine envelope-from-Adresse anhand des Anmeldenamens in "
#~ "Verbindung mit der Konfigurationsvariable »maildomain« erstellen."

#~ msgid "Domain to use for the envelope-from address:"
#~ msgstr "Domain, welche für die envelope-from-Adresse benutzt 

Bug#1022864: gscan2pdf: unnecessary test dependency on autopkgtest?

[Paul Gevers]

Hi,

On 01-11-2022 16:59, Jeff wrote:

gscan2pdf doesn't depend on autopkgtest directly. It has:

Testsuite: autopkgtest-pkg-perl

in the control file. Is that somehow incorrect?


https://sources.debian.org/src/gscan2pdf/2.13.0-1/debian/tests/control/
clearly states autopkgtest as a *test* dependency (line 2). I claim 
that's most likely incorrect.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023291: gitlab-sidekiq spamming logs after upgrade to gitlab 15.4.2

[Ondrej Zary]

Package: gitlab
Version: 15.4.2+ds1-1~fto11+3
Severity: normal
X-Debbugs-Cc: z...@gsystem.sk

Dear Maintainer,
after upgrading gitlab to 15.4.2, gitlab-sidekiq is spamming logs like this:

gitlab-sidekiq[311326]: Passing the timeout as a positional argument is 
deprecated, it should be passed as a keyword argument:
gitlab-sidekiq[311326]:   
redis.brpop("resque:gitlab:queue:adjourned_project_deletion", "resque:git
lab:queue:object_pool:object_pool_create", 
"resque:gitlab:queue:integrations_execute", "resque:gitlab:queue:gcp_cluster:clu
sters_cleanup_service_account", 
"resque:gitlab:queue:pipeline_default:ci_drop_pipeline", 
"resque:gitlab:queue:status_page_p
ublish", 
"resque:gitlab:queue:github_importer:github_import_stage_import_pull_requests", 
"resque:gitlab:queue:package_clean
up:packages_mark_package_files_for_destruction", ..
 blah maybe 100 more lines

/var/log/syslog is 10GB in just 3 days. I had to delete two other 20GB logs 
because the disk was full.


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 
'oldstable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=sk_SK.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 gitlab depends on:
ii  apache2 [httpd] 2.4.54-1~deb11u1
ii  asciidoctor 2.0.17-1~fto11+1
ii  bc  1.07.1-2+b2
ii  bundler 2.2.5-2
ii  bzip2   1.0.8-4
ii  dbconfig-pgsql  2.0.19
ii  debconf [debconf-2.0]   1.5.77
ii  fonts-font-awesome [node-font-  5.0.10+really4.7.0~dfsg-4.1
ii  gitlab-common   15.4.2+dfsg-1~fto11+1
ii  gitlab-workhorse15.4.2+ds1-1~fto11+3
ii  katex [node-katex]  0.13.11+~cs6.0.0-2~bpo11+1
ii  libjs-bootstrap4 [node-bootstr  4.5.2+dfsg1-8~deb11u1
ii  libjs-pdf [node-pdfjs-dist] 2.6.347+dfsg-3
ii  libjs-popper.js [node-popper.j  1.16.1+ds-3
ii  libruby2.7 [ruby-webrick]   2.7.4-1+deb11u1
ii  lsb-base11.1.0
ii  node-autosize   4.0.2~dfsg1-7
ii  node-axios  0.21.1+dfsg-1+deb11u1
ii  node-babel-loader   8.2.2-5
ii  node-babel-plugin-lodash3.3.4+~cs2.0.1-3
ii  node-babel7 7.12.12+~cs150.141.84-6
ii  node-brace-expansion2.0.0-1
ii  node-cache-loader   4.1.0+~cs2.0.0-1
ii  node-clipboard  2.0.8+ds+~cs9.6.11-1~bpo11+1
ii  node-compression-webpack-plugi  6.1.1-1
ii  node-copy-webpack-plugin5.1.2+~cs9.0.2-4
ii  node-core-js3.8.2-2
ii  node-cron-validator 1.3.1-1~bpo11+1
ii  node-css-loader 5.0.1+~cs14.0.5-1
ii  node-d3 5.16.0-4
ii  node-d3-selection   1.4.0-6
ii  node-dateformat 5.0.3-2~bpo11+1
ii  node-dompurify  2.3.7+dfsg-1~bpo11+1
ii  node-exports-loader 1.1.1-2
ii  node-file-loader6.2.0-2
ii  node-fuzzaldrin-plus0.5.0+dfsg-3
ii  node-glob   7.1.6+~7.1.3-1
ii  node-imports-loader 0.8.0-2
ii  node-jed1.1.1-2
ii  node-jquery 3.5.1+dfsg+~3.5.5-7
ii  node-jquery-ujs 1.2.2-2
ii  node-js-cookie  3.0.1+~3.0.0-2~bpo11+1
ii  node-js-yaml3.14.1+dfsg+~3.12.6-2
ii  node-jszip  3.5.0+dfsg-2
ii  node-jszip-utils0.0.2+dfsg-2
ii  node-lodash 4.17.21+dfsg+~cs8.31.198.20210220-9~bpo11+2
ii  node-marked 0.8.0+ds+repack-2
ii  node-mermaid8.14.0+~cs11.4.14-1~bpo11+1
ii  node-minimatch  3.0.4+~3.0.3-1
ii  node-miragejs   0.1.41+~cs5.6.6-4
ii  node-mousetrap  1.6.5~ds-1
ii  node-postcss8.4.8+~cs7.3.21-2~bpo11+2
ii  node-prismjs1.23.0+dfsg-1+deb11u2
ii  node-prosemirror-markdown   1.6.0-1~bpo11+2
ii  node-prosemirror-model  1.16.1+~cs1.1.5-1~bpo11+2
ii  node-prosemirror-state  1.3.4-1~bpo11+2
ii  node-prosemirror-view   1.23.13-1~bpo11+1
ii  node-raven-js   3.22.1+dfsg-2
ii  node-raw-loader 4.0.2-2
ii  node-style-loader   2.0.0-2
ii  node-three-orbit-controls   82.1.0-3
ii  node-three-stl-loader   1.0.6-3
ii  node-timeago.js 4.0.2-3
ii  node-underscore 1.9.1~dfsg-3
ii  node-url-loader 4.1.1-3
ii  node-uuid   8.3.2+~8.3.0-4
ii  node-vue   

Bug#1023290: golang-raven-go: Include outdated copy of CA bundles

[Shengjing Zhu]

Source: golang-raven-go
Version: 0.2.0+ds1-2
Severity: serious
Tags: security
X-Debbugs-Cc: z...@debian.org, prav...@debian.org

Hi Pirate Praveen,

In 2018, you said we should not package golang-github-certifi-gocertifi[1],
as we should use the system CA bundles.

But why you include that in the vendor dir[2] in golang-raven-go?

[1] https://lists.debian.org/debian-go/2018/12/msg00065.html
[2] 
https://salsa.debian.org/go-team/packages/golang-raven-go/-/tree/debian/0.2.0+ds1-1/vendor/github.com/certifi/gocertifi

Bug#1023288: ITP: golang-github-certifi-gocertifi -- curated collection of Root Certificates

[Shengjing Zhu]

Hi,

On Wed, Nov 2, 2022 at 3:42 AM Leo Antunes  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Leo Antunes 
>
> * Package name: golang-github-certifi-gocertifi
>   Version : 2021.04.29-1
>   Upstream Author : Certifi
> * URL : https://github.com/certifi/gocertifi
> * License : MPL-2.0
>   Programming Lang: Go
>   Description : curated collection of Root Certificates
>  This Go package contains a CA bundle that you can reference in your Go
>  code. This is useful for systems that do not have CA bundles that Golang
>  can find itself, or where a uniform set of CAs is valuable.
>  .
>  This is the same CA bundle that ships with the Python Requests
>  (https://github.com/kennethreitz/requests) library, and is a Golang
>  specific port of certifi (https://github.com/kennethreitz/certifi). The
>  CA bundle is derived from Mozilla's canonical set.
>

Please see the previous attempt.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966583

And methods people have chosen to avoid such package:

https://lists.debian.org/debian-go/2018/12/msg00065.html
https://lists.debian.org/debian-go/2020/12/msg00021.html

--
Shengjing Zhu

Bug#1022393: moment-timezone.js: FTBFS: make[1]: *** [debian/rules:12: data/meta/2022c.json] Error 1

[Antoine Beaupré]

On 2022-10-23 15:21:14, Lucas Nussbaum wrote:
>> make[1]: Entering directory '/<>'
>> # Fail the build if the tzdata package does not match TZVER.
>> grep -q '^# version 2022c$' /usr/share/zoneinfo/tzdata.zi
>> make[1]: *** [debian/rules:12: data/meta/2022c.json] Error 1

this looks like a failure due to the tzdata update... it looks like the
fix is just to update to latest upstream:

https://github.com/moment/moment-timezone/releases/tag/0.5.38

a.

-- 
Hard times are coming when we will be wanting the voices of writers
who can see alternatives to how we live now and can see through our
fear-stricken society and its obsessive technologies to other ways of
being, and even imagine some real grounds for hope. We will need
writers who can remember freedom. Poets, visionaries—the realists of a
larger reality. - Ursula Le Guin

Bug#1023289: please include mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin

[Sébastien Villemot]

Package: firmware-misc-nonfree
Version: 20221012-1
Severity: normal

Dear Maintainer,

The MEDIATEK MT7922 chip integrated in my motherboard requires a firmware that 
is
currently not installed by firmware-misc-nonfree for its bluetooth
functionality to work. Note that this firwmare is present in linux-firmware.git:

nov. 01 20:13:24 rama kernel: mt7921e :07:00.0: enabling device ( -> 
0002)
nov. 01 20:13:24 rama kernel: usbcore: registered new interface driver btusb
nov. 01 20:13:24 rama kernel: bluetooth hci0: firmware: failed to load 
mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin (-2)
nov. 01 20:13:24 rama kernel: firmware_class: See 
https://wiki.debian.org/Firmware for information about missing firmware
nov. 01 20:13:24 rama kernel: bluetooth hci0: firmware: failed to load 
mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin (-2)
nov. 01 20:13:24 rama kernel: bluetooth hci0: Direct firmware load for 
mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin failed with error -2
nov. 01 20:13:24 rama kernel: Bluetooth: hci0: Failed to load firmware file (-2)
nov. 01 20:13:24 rama kernel: Bluetooth: hci0: Failed to set up firmware (-2)

It would be nice to ship it.

Thanks for your work,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

Bug#1023288: ITP: golang-github-certifi-gocertifi -- curated collection of Root Certificates

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: golang-github-certifi-gocertifi
  Version : 2021.04.29-1
  Upstream Author : Certifi
* URL : https://github.com/certifi/gocertifi
* License : MPL-2.0
  Programming Lang: Go
  Description : curated collection of Root Certificates
 This Go package contains a CA bundle that you can reference in your Go
 code. This is useful for systems that do not have CA bundles that Golang
 can find itself, or where a uniform set of CAs is valuable.
 .
 This is the same CA bundle that ships with the Python Requests
 (https://github.com/kennethreitz/requests) library, and is a Golang
 specific port of certifi (https://github.com/kennethreitz/certifi). The
 CA bundle is derived from Mozilla's canonical set.

Bug#1023287: ITP: golang-github-github-smimesign -- An S/MIME signing utility for use with Git

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: golang-github-github-smimesign
  Version : 0.2.0-1
  Upstream Author : GitHub
* URL : https://github.com/github/smimesign
* License : Expat
  Programming Lang: Go
  Description : An S/MIME signing utility for use with Git

 Smimesign is an S/MIME signing utility that is compatible with Git.
 This allows developers to sign their Git commits and tags using
 X.509 certificates issued by public certificate authorities or their
 organization's internal certificate authority.

Bug#1023286: fakeroot doesn't wrap __stat64_time64 (and friends) introduced by glibc 2.34 on 32 bit arches

[Clint Adams]

On Tue, Nov 01, 2022 at 07:44:05PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> the normal user "user" which suggests to me that the function is not
> wrapped by fakeroot even though it should. Other functions that might be
> interesting from glibc 2.34 and might need wrapping are
> __fstatat64_time64 and __lstat64_time64.

If we only need to wrap the form with _time64 and not the one without, it
should be easy to add that to the WRAPPED for loop in configure.ac .

If both need to be wrapped because some programs can be compiled to use
the form without _time64, then those new functions need to be added to the
SEARCH for loop, or somewhere else entirely.

Bug#1023286: Acknowledgement (fakeroot doesn't wrap __stat64_time64 (and friends) introduced by glibc 2.34 on 32 bit arches)

[josch]

Control: affects -1 fakechroot

This is also breaking the fakechroot autopkgtest on armel, armhf and i386 (all 
the 32 bit arches) because a chroot created with fakechroot and fakeroot will 
not anymore be bit-by-bit identical to one created the normal way:

https://ci.debian.net/data/autopkgtest/testing/armel/f/fakechroot/27716791/log.gz

On all 64 bit arches (where __stat64_time64 doesn't exist) this still works.

signature.asc
Description: signature

Bug#1023286: Acknowledgement (fakeroot doesn't wrap __stat64_time64 (and friends) introduced by glibc 2.34 on 32 bit arches)

[Johannes Schauer Marin Rodrigues]

Control: affects -1 fakechroot

This is also breaking the fakechroot autopkgtest on armel, armhf and i386 (all 
the 32 bit arches) because a chroot created with fakechroot and fakeroot will 
not anymore be bit-by-bit identical to one created the normal way:

https://ci.debian.net/data/autopkgtest/testing/armel/f/fakechroot/27716791/log.gz

On all 64 bit arches (where __stat64_time64 doesn't exist) this still works.

signature.asc
Description: signature

Bug#1023286: fakeroot doesn't wrap __stat64_time64 (and friends) introduced by glibc 2.34 on 32 bit arches

[Johannes Schauer Marin Rodrigues]

Package: fakeroot
Version: 1.29-1
Severity: important

Control: affects -1 + mmdebstrap

Hi,

glibc 2.34 introduced several new functions on 32 bit arches which are
used by coreutils since 9.1 which was built with glibc 2.34. Since these
new functions are not wrapped by fakeroot, ownership information will be
wrong on 32 bit arches like i386 or armhf. To show what should happen,
lets run this on amd64:

mmdebstrap --arch=amd64 --include=fakeroot,adduser --variant=apt \
--customize-hook='chroot "$1" adduser --gecos user --disabled-password 
user' \
--customize-hook='chroot "$1" runuser -u user -- /bin/bash' \
unstable /dev/null
[...]
user@hoothoot:/$ whoami
user
user@hoothoot:/$ fakeroot /bin/bash
root@hoothoot:/# whoami
root
root@hoothoot:/# cd /tmp/
root@hoothoot:/tmp# echo foo > bar
root@hoothoot:/tmp# echo baz > blub
root@hoothoot:/tmp# chown --reference=/tmp/bar blub
root@hoothoot:/tmp# ls -lha bar blub
-rw-r--r-- 1 root root 4 Nov  1 18:39 bar
-rw-r--r-- 1 root root 4 Nov  1 18:39 blub

Success! Both files are owned by the (fake) root user. And now lets run
it on i386:

$ mmdebstrap --arch=i386 --include=fakeroot,adduser --variant=apt \
--customize-hook='chroot "$1" adduser --gecos user --disabled-password 
user' \
--customize-hook='chroot "$1" runuser -u user -- /bin/bash' \
unstable /dev/null
[...]
user@hoothoot:/$ whoami
user
user@hoothoot:/$ fakeroot /bin/bash
root@hoothoot:/# whoami
root
root@hoothoot:/# cd /tmp/
root@hoothoot:/tmp# echo foo > bar
root@hoothoot:/tmp# echo baz > blub
root@hoothoot:/tmp# chown --reference=/tmp/bar blub
root@hoothoot:/tmp# ls -lha bar blub
-rw-r--r-- 1 root root 4 Nov  1 18:26 bar
-rw-r--r-- 1 user user 4 Nov  1 18:26 blub

The file blub is not owned by the fake root user but by the outer user
"user". This is incorrect. When investigating what is going on I found
that the "chown" command calls __stat64_time64 on i386 which will return
the normal user "user" which suggests to me that the function is not
wrapped by fakeroot even though it should. Other functions that might be
interesting from glibc 2.34 and might need wrapping are
__fstatat64_time64 and __lstat64_time64.

This is breaking my package mmdebstrap.

Thanks!

cheers, josch

Bug#1023076: linux-headers-6.0.0-2-amd64: bluetooth crashes after returning from suspend

[Gabriel Francisco]

Hi Diederik, thank for your quick response!


I installed 6.0.5-1 and during the past few days seems to be working okay.


There is only occasional messages "Bluetooth: hci0: Opcode 0x 402 
failed: -16" that appeared after installing the firmware-linux package 
from unstable, but I'm not sure if that is the cause. Bluetooth is 
working okay so far, I will keep testing and report in case I find issues.



Thanks again and have a good week,

Gabriel Francisco

On 30/10/2022 02:02, Diederik de Haas wrote:

Control: reassign -1 src:linux 6.0.3-1
Control: severity -1 important

On Sunday, 30 October 2022 00:50:25 CEST Gabriel Francisco wrote:

Package: linux-headers-6.0.0-2-amd64
Version: 6.0.3-1
Severity: normal

With this kernel seems to crash bluetooth when returning from
suspend. Few days ago my cursor froze, the computer rebooted and I
couldn't find logs in /var/log/syslog.

I think it might be related to #1021905.

Indeed many similarities, but not exactly the same ...


[24595.999699] general protection fault,
...
[24595.999793]  ? bt_sock_wait_ready+0x128/0x1a0 [bluetooth]

These things are different. I increased severity because of GPF.

Before we look further, can you test 6.0.5-1 available in Unstable?

Bug#1023285: ITP: plasma-dialer -- Dialer for Plasma Mobile

[Marco Mattiolo]

Package: wnpp
Severity: wishlist
Owner: Marco Mattiolo 
X-Debbugs-Cc: debian-de...@lists.debian.org, marco.matti...@hotmail.it

* Package name    : plasma-dialer
  Version : 22.09
  Upstream Author : 
* URL : https://invent.kde.org/plasma-mobile/plasma-dialer
* License : GPL
  Programming Lang: C++, QML
  Description : Dialer for Plasma Mobile

Kirigami-based GUI application and background daemons: Dialer for Plasma 
Mobile

Bug#1023279: Segfault on startup; stack overflow involving libwx

[Michael Deegan]

Package: hugin
Followup-For: Bug #1023279

Okay, after downgrading Hugin (and Python, and Samba) to the versions in
bullseye, the SEGV goes away. As does downgrading just Hugin to 
2021.0.0+dfsg-1+b1
(which I pulled out of my apt-cacher-ng cache).

This might be a WX 3.2 bug or incompatibility.

HTH!

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 
'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (480, 'testing-debug'), 
(480, 'testing'), (470, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages hugin depends on:
ii  enblend 4.2-9
ii  enfuse  4.2-9
ii  hugin-tools 2021.0.0+dfsg-1+b1
ii  libc6   2.35-4
ii  libexiv2-27 0.27.5-4
ii  libfftw3-double33.3.8-2
ii  libgcc-s1   10.2.1-6
ii  libglew2.2  2.2.0-4+b1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  libglx0 1.5.0-1
ii  libgomp110.2.1-6
ii  libimage-exiftool-perl  12.16+dfsg-2
ii  liblcms2-2  2.12~rc1-2
ii  libopengl0  1.5.0-1
ii  libpano13-3 2.9.20~rc3+dfsg-1
ii  libsqlite3-03.34.1-3
ii  libstdc++6  12.2.0-3
ii  libtiff54.2.0-1+deb11u1
ii  libvigraimpex11 1.11.1+dfsg-8
ii  libwxbase3.0-0v53.0.5.1+dfsg-2
ii  libwxgtk3.0-gtk3-0v53.0.5.1+dfsg-2
ii  make4.3-4.1

hugin recommends no packages.

Versions of packages hugin suggests:
ii  darktable4.0.0-1
ii  dcraw9.28-2
ii  rawtherapee  5.8-3

-- debconf-show failed

-MD

-- 
-
Michael Deegan   Hugaholic  https://www.deegan.id.au/
  Jung, zr jbeel?  --

Bug#966573: progress packaging awscli v2

[Noah Meyerhans]

On Mon, Oct 31, 2022 at 10:50:19PM -0700, Noah Meyerhans wrote:
> > aws-crt-python is the hard part.  It depends on a bunch of C libraries which
> > follow a more modern development style.  They:
> > - provide no abi/api stability guarantees.
> > - have versioned releases, but no one cares about the versions.  The 
> > intention
> >   is that everyone should be following the main branch.
> > - only nominally support dynamic linking (it can be enabled, but is not 
> > used or
> >   tested by upstream).

Actually, taking a look at Amazon Linux 2022's packaging of these
libraries, I see that they're distributed as .so files, and the
aws-crt-python packagin declares runtime dependencies on these
dynamically loaded libraries.  So I don't think we're in uncharted
waters if we decide to ship .so libraries.

noah

Bug#1023284: libevent: FTBFS with glibc 2.36

[Samuel Thibault]

Source: libevent
Version: 2.0.21-stable-2+deb8u1
Severity: serious
Justification: FTBFS

Hello,

Since the upload of glibc 2.36 in unstable (2.36-3), libevent fails to
build from source:

dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libevent-core-2.1-7/DEBIAN/symbols doesn't 
match completely debian/libevent-core-2.1-7.symbols
--- debian/libevent-core-2.1-7.symbols 
(libevent-core-2.1-7_2.1.12-stable-5_amd64)
+++ dpkg-gensymbolse6mOZa   2022-11-01 18:35:41.660556092 +0100
@@ -394,7 +394,7 @@
  evutil_parse_sockaddr_port@Base 2.1.8-stable
  evutil_read_file_@Base 2.1.8-stable
  evutil_rtrim_lws_@Base 2.1.8-stable
- evutil_secure_rng_add_bytes@Base 2.1.8-stable
+#MISSING: 2.1.12-stable-5# evutil_secure_rng_add_bytes@Base 2.1.8-stable
  evutil_secure_rng_get_bytes@Base 2.1.8-stable
  evutil_secure_rng_global_setup_locks_@Base 2.1.8-stable
  evutil_secure_rng_init@Base 2.1.8-stable

That's probably due the addition of arc4random in glibc, which makes

#if !defined(EVENT__HAVE_ARC4RANDOM) || 
defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)
void
evutil_secure_rng_add_bytes(const char *buf, size_t n)
{
arc4random_addrandom((unsigned char*)buf,
n>(size_t)INT_MAX ? INT_MAX : (int)n);
}
#endif

not define evutil_secure_rng_add_bytes any more.

Samuel

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Bug#1018915: v4l-utils: FTBFS with libbpf 1.0.0

[Sudip Mukherjee]

On Tue, Nov 1, 2022 at 5:19 PM Sean Young  wrote:
>
> Hi Sudip,
>
> On Sat, Oct 29, 2022 at 11:17:03PM +0100, Sudip Mukherjee wrote:
> > Can you please test the attached patch and confirm that it does not break
> > any of the functionality. This is the only one now which is blocking me
> > from requesting libbbpf transition.
>
> Looks good, everything is working fine.

Thanks for testing.

>
> Thanks for writing the patch. Before it can be accepted, it should be posted
> on linux-me...@vger.kernel.org with a `Signed-off-by:`. If there are no
> review comments I can merge it into v4l-utils upstream.

I will send it tonight after I am back from $dayjob.


-- 
Regards
Sudip

Bug#1023283: ITP: snippy -- rapid haploid variant calling and core genome alignment

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: snippy -- rapid haploid variant calling and core genome alignment
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: snippy
  Version : 4.6.0
  Upstream Author : Torsten Seemann
* URL : https://github.com/tseemann/snippy/
* License : GPL-2+
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : rapid haploid variant calling and core genome alignment
 Snippy finds SNPs between a haploid reference genome and your NGS
 sequence reads. It will find both substitutions (snps) and
 insertions/deletions (indels). It will use as many CPUs as you can give
 it on a single computer (tested to 64 cores). It is designed with speed
 in mind, and produces a consistent set of output files in a single
 folder. It can then take a set of Snippy results using the same
 reference and generate a core SNP alignment (and ultimately a
 phylogenomic tree).

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/snippy

Bug#1018915: v4l-utils: FTBFS with libbpf 1.0.0

[Sean Young]

Hi Sudip,

On Sat, Oct 29, 2022 at 11:17:03PM +0100, Sudip Mukherjee wrote:
> Can you please test the attached patch and confirm that it does not break
> any of the functionality. This is the only one now which is blocking me
> from requesting libbbpf transition.

Looks good, everything is working fine.

Thanks for writing the patch. Before it can be accepted, it should be posted
on linux-me...@vger.kernel.org with a `Signed-off-by:`. If there are no
review comments I can merge it into v4l-utils upstream.

Thanks,

Sean

Bug#1023282: RFP: debrebuild-fepitre -- yet another package rebuilder tool

[Holger Levsen]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: frederic.pier...@qubes-os.org

* Package name: debrebuild-fepitre
  Upstream Author : Frédéric Pierret 
* URL : https://github.com/fepitre/debrebuild
* License : unclear ;) (author has been notified)
  Programming Lang: Python3
  Description : yet another package rebuilder tool

Given a buildinfo file from a Debian package, generate instructions for
attempting to reproduce the binary packages built from the associated
source and build information.

This package is currently used to create 
https://beta.tests.reproducible-builds.org/
and should be used for creating many more Debian rebuilder instances in future 
to
verify the reproducibility of packages distributed by Debian via ftp.debian.org


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The moon landing 50 years ago was paid by taxes, while Bezos space trip was
paid by not paying taxes.


signature.asc
Description: PGP signature

Bug#1023281: RFP: package-rebuilder -- package-rebuilder: orchestration tool for rebuilding packages

[Holger Levsen]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: frederic.pier...@qubes-os.org

* Package name: package-rebuilder
  Upstream Author : Frédéric Pierret 
* URL : https://github.com/fepitre/package-rebuilder
* License : unclear ;) (author has been notified)
  Programming Lang: Python3
  Description : package-rebuilder: orchestration tool for rebuilding 
packages

Standalone orchestrator for rebuilding Debian, Fedora and Qubes OS packages in
order to generate `in-toto` metadata which can be used with
`apt-transport-in-toto` or `dnf-plugin-in-toto` to validate reproducible 
status. 

This package is currently used to create 
https://beta.tests.reproducible-builds.org/
and should be used for creating many more Debian rebuilder instances in future 
to
verify the reproducibility of packages distributed by Debian via ftp.debian.org


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

During 2021 Bitcoin consumed 134 TWh in total, which is comparable to the
electrical energy consumed by a country like Argentina. It's also twice as
much as 2020. Related CO2 emissions were ~64 Megatons; enough to negate the
entire global net savings from deploying electrical vehicles world wide.


signature.asc
Description: PGP signature

Bug#1023280: monitoring-plugins-basic: check_disk always segfaults

[Stephane Bortzmeyer]

Package: monitoring-plugins-basic
Version: 2.3.2-1
Severity: important

Dear Maintainer,

% /usr/lib/nagios/plugins/check_disk -w 10 -c 5
zsh: segmentation fault  /usr/lib/nagios/plugins/check_disk -w 10 -c 5

With strace:

% strace /usr/lib/nagios/plugins/check_disk -w 10 -c 5 
execve("/usr/lib/nagios/plugins/check_disk", 
["/usr/lib/nagios/plugins/check_di"..., "-w", "10", "-c", "5"], 0xbead77b0 /* 
52 vars */) = 0
brk(NULL)   = 0x1c1f000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40094000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0644, stx_size=54650, ...}) = 0
mmap2(NULL, 54650, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40096000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0i\344\1\0004\0\0\0"..., 
512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0755, stx_size=1123124, ...}) = 0
mmap2(NULL, 1287060, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x400a8000
mmap2(0x400b, 1221524, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x400b
munmap(0x400a8000, 32768)   = 0
munmap(0x401db000, 29588)   = 0
mprotect(0x401ba000, 81920, PROT_NONE)  = 0
mmap2(0x401ce000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10e000) = 0x401ce000
mmap2(0x401d1000, 37780, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401d1000
close(3)= 0
set_tls(0x400952e0) = 0
set_tid_address(0x40094e48) = 751
set_robust_list(0x40094e4c, 12) = 0
rseq(0x400952c0, 0x20, 0, 0xe7f5def3)   = -1 ENOSYS (Function not implemented)
mprotect(0x401ce000, 8192, PROT_READ)   = 0
mprotect(0x43f000, 4096, PROT_READ) = 0
mprotect(0x400a6000, 4096, PROT_READ)   = 0
ugetrlimit(RLIMIT_STACK, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
munmap(0x40096000, 54650)   = 0
getrandom("\x66\xa6\x04\xbb", 4, GRND_NONBLOCK) = 4
brk(NULL)   = 0x1c1f000
brk(0x1c4)  = 0x1c4
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0644, stx_size=3709744, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x401db000
mmap2(NULL, 2592768, PROT_READ, MAP_PRIVATE, 3, 0x6f000) = 0x403db000
mmap2(NULL, 8192, PROT_READ, MAP_PRIVATE, 3, 0x338000) = 0x40096000
close(3)= 0
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0644, stx_size=2996, ...}) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2996
read(3, "", 4096)   = 0
close(3)= 0
openat(AT_FDCWD, "/usr/lib/locale/en_GB.UTF-8/LC_TIME", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en_GB.utf8/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en_GB/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en.UTF-8/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en.utf8/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/en/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
openat(AT_FDCWD, "/etc/mtab", O_RDONLY|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, 
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFREG|0444, stx_size=0, ...}) = 0
read(3, "/dev/sda1 / ext4 rw,relatime 0 0"..., 1024) = 1024
read(3, "x=1024 0 0\ndevpts /dev/lxc/tty3 "..., 1024) = 639
read(3, "", 1024)   = 0
close(3)= 0
statx(AT_FDCWD, "/", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, 
{stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=STATX_ATTR_MOUNT_ROOT, 
stx_mode=S_IFDIR|0755, stx_size=4096, ...}) = 0
uname({sysname="Linux", nodename="jadis", ...}) = 0
statfs64("/", 88, 0xbee04308)   = 0
--- SIGSEGV 

Bug#1022398: bladerf: FTBFS: dh_install: error: missing files, aborting

[Christoph Berg]

> > # Python3 bindings
> > python3 host/libraries/libbladeRF_bindings/python/setup.py install 
> > --root=debian/tmp/ --prefix=/usr
...
> > Copying bladerf.egg-info to 
> > debian/tmp/usr/local/lib/python3.10/dist-packages/bladerf-1.2.1-py3.10.egg-info
> > running install_scripts
> > Installing bladerf-tool script to debian/tmp/usr/local/bin

> >dh_install
> > dh_install: warning: Cannot find (any matches for) 
> > "usr/lib/python3*/site-packages/*" (tried in ., debian/tmp)

The problem here is that setup.py installs into tmp/usr/local despite
being told to use --prefix=/usr.

I have no idea why it's doing that and couldn't find a sane fix, so I
added a "mv usr/local usr" workaround to debian/rules.

Christoph

Bug#1023279: Segfault on startup; stack overflow involving libwx

[Michael Deegan]

Package: hugin
Version: 2021.0.0+dfsg-3
Severity: important

Console output:

(hugin:3576986): dbind-WARNING **: 22:42:21.509: Couldn't connect to 
accessibility bus: Failed to connect to socket /tmp/dbus-sLH9razXV7: Connection 
refused

(hugin:3576986): Gtk-CRITICAL **: 22:42:21.697: 
gtk_widget_set_size_request: assertion 'height >= -1' failed

(hugin:3576986): Gtk-CRITICAL **: 22:42:21.773: 
gtk_widget_set_size_request: assertion 'height >= -1' failed

(hugin:3576986): Gtk-CRITICAL **: 22:42:21.775: 
gtk_widget_set_size_request: assertion 'height >= -1' failed

(hugin:3576986): Gtk-CRITICAL **: 22:42:21.775: 
gtk_widget_set_size_request: assertion 'height >= -1' failed

(hugin:3576986): Gtk-CRITICAL **: 22:42:21.780: 
gtk_widget_set_size_request: assertion 'height >= -1' failed

(hugin:3576986): Gtk-CRITICAL **: 22:42:21.783: 
gtk_widget_set_size_request: assertion 'height >= -1' failed

(hugin:3576986): Gtk-CRITICAL **: 22:42:21.783: 
gtk_widget_set_size_request: assertion 'height >= -1' failed
/usr/share/hugin/data/plugins/top_five.py
   CAT:Control Points
   NAM:keep 5 CPs per image pair
   fails @api-max
/usr/share/hugin/data/plugins/woa.py
   CAT:Control Points
   NAM:Warped Overlap Analysis
   fails @api-max
ERROR: 22:42:22.231532 (./src/hugin1/hugin/GLViewer.cpp:133) 
SetUpContext(): Error initialising GLEW: Unknown error.
Segmentation fault

I'm wondering if it's the result of a recent libc upgrade, but I'm not about
to attempt a downgrade to verify. :P I did try running Hugin in a libvirt
VM, but I think there it's being fussy about the virtual environment
(despite having working direct-rendering opengl).

Stack trace starts with:

#0  0x55649847 in  ()
#1  0x5564b9e7 in  ()
#2  0x776fbdf2 in 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#3  0x776fbfab in wxEventHashTable::HandleEvent(wxEvent&, 
wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#4  0x776fc5c9 in wxEvtHandler::TryHereOnly(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#5  0x776fc64a in wxEvtHandler::ProcessEventLocally(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#6  0x776fc751 in wxEvtHandler::ProcessEvent(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#7  0x776fdee7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#8  0x771c6377 in wxWindowBase::Close(bool) () at 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#9  0x776fbdf2 in 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#10 0x776fbfab in wxEventHashTable::HandleEvent(wxEvent&, 
wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#11 0x776fc5c9 in wxEvtHandler::TryHereOnly(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#12 0x776fc64a in wxEvtHandler::ProcessEventLocally(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#13 0x776fc751 in wxEvtHandler::ProcessEvent(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#14 0x776fdee7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#15 0x771c6377 in wxWindowBase::Close(bool) () at 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#16 0x5564b992 in  ()
#17 0x776fbdf2 in 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#18 0x776fbfab in wxEventHashTable::HandleEvent(wxEvent&, 
wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#19 0x776fc5c9 in wxEvtHandler::TryHereOnly(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#20 0x776fc64a in wxEvtHandler::ProcessEventLocally(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#21 0x776fc751 in wxEvtHandler::ProcessEvent(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#22 0x776fdee7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#23 0x771c6377 in wxWindowBase::Close(bool) () at 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.2.so.0
#24 0x776fbdf2 in 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#25 0x776fbfab in wxEventHashTable::HandleEvent(wxEvent&, 
wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#26 0x776fc5c9 in 

Bug#1023100: ITP: cancelreader -- A cancelable reader for Go

[Holger Levsen]

On Tue, Nov 01, 2022 at 05:30:16PM +0100, Martin Dosch wrote:
> It is: 
> https://salsa.debian.org/go-team/packages/golang-github-muesli-cancelreader/-/blob/debian/sid/debian/control#L28
> :)

coolio!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

we'll all die. make a difference while you can. disobey. smile.


signature.asc
Description: PGP signature

Bug#1023100: ITP: cancelreader -- A cancelable reader for Go

[Martin Dosch]

It is: 
https://salsa.debian.org/go-team/packages/golang-github-muesli-cancelreader/-/blob/debian/sid/debian/control#L28 
:)


signature.asc
Description: PGP signature

Bug#1023276: evdi: diff for NMU version 1.12.0+dfsg-0.1

[Harlan Lieberman-Berg]

Package: evdi
Version: 1.9.0+dfsg-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for evdi (versioned as 1.12.0+dfsg-0.1) and uploaded it to
DELAYED/0 as there has been no activity for some time and it has been dropped
from testing.

Regards.

diff -Nru evdi-1.9.0+dfsg/debian/changelog evdi-1.12.0+dfsg/debian/changelog
--- evdi-1.9.0+dfsg/debian/changelog2021-01-26 10:32:36.0 -0500
+++ evdi-1.12.0+dfsg/debian/changelog   2022-11-01 11:56:26.0 -0400
@@ -1,3 +1,12 @@
+evdi (1.12.0+dfsg-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release (Closes: #994892, #1017058)
+  * Import patch to fix FTBFS in Linux >= 6.0 from upstream
+  * Add dh-dkms to build-depends
+
+ -- Harlan Lieberman-Berg   Tue, 01 Nov 2022 11:56:26 
-0400
+
 evdi (1.9.0+dfsg-1) unstable; urgency=medium
 
   * new upstream release 1.9.0
diff -Nru evdi-1.9.0+dfsg/debian/control evdi-1.12.0+dfsg/debian/control
--- evdi-1.9.0+dfsg/debian/control  2021-01-26 10:32:36.0 -0500
+++ evdi-1.12.0+dfsg/debian/control 2022-11-01 11:56:26.0 -0400
@@ -2,7 +2,7 @@
 Section: misc
 Priority: optional
 Maintainer: Hanno Stock 
-Build-Depends: debhelper-compat (= 13), dkms, dh-exec, libdrm-dev
+Build-Depends: debhelper-compat (= 13), dh-dkms, dkms, dh-exec, libdrm-dev
 Standards-Version: 4.5.0
 Rules-Requires-Root: no
 Homepage: https://github.com/DisplayLink/evdi
diff -Nru evdi-1.9.0+dfsg/debian/patches/0001-fix-6.0-ftbfs.patch 
evdi-1.12.0+dfsg/debian/patches/0001-fix-6.0-ftbfs.patch
--- evdi-1.9.0+dfsg/debian/patches/0001-fix-6.0-ftbfs.patch 1969-12-31 
19:00:00.0 -0500
+++ evdi-1.12.0+dfsg/debian/patches/0001-fix-6.0-ftbfs.patch2022-11-01 
11:56:26.0 -0400
@@ -0,0 +1,53 @@
+From bdc258b25df4d00f222fde0e3c5003bf88ef17b5 Mon Sep 17 00:00:00 2001
+From: Adam Tazul <71192298+simpilotad...@users.noreply.github.com>
+Date: Thu, 13 Oct 2022 10:50:00 +0100
+Subject: [PATCH] Add support for kernel 6.0 + a minor fix (#381)
+
+* Add support for kernel 6.0
+
+Fixes #376 by implementing @Crashdummyy's fix as posted 
[here](https://github.com/DisplayLink/evdi/issues/376#issuecomment-1237450695)
+
+* Fixing the style used in evdi_painter.c
+
+* Update evdi_painter.c
+
+* drm_framebuffer is only included on 5.15 and later
+
+* drm_framebuffer is only included on 6.0.0 and later
+
+* drm_framebuffer is only included on 6.0.0 and later
+
+* drm_framebuffer is only included on 6.0.0 and later
+
+* drm_framebuffer is only included on 5.15.0 and later
+---
+ module/evdi_drm_drv.h | 2 +-
+ module/evdi_painter.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+Index: evdi/module/evdi_drm_drv.h
+===
+--- evdi.orig/module/evdi_drm_drv.h
 evdi/module/evdi_drm_drv.h
+@@ -26,7 +26,7 @@
+ #include 
+ #endif
+ #if KERNEL_VERSION(5, 15, 0) <= LINUX_VERSION_CODE
+-#include 
++#include 
+ #else
+ #include 
+ #endif
+Index: evdi/module/evdi_painter.c
+===
+--- evdi.orig/module/evdi_painter.c
 evdi/module/evdi_painter.c
+@@ -885,7 +885,7 @@ evdi_painter_connect(struct evdi_device
+ 
+   painter_lock(painter);
+ 
+-evdi->pixel_area_limit = pixel_area_limit;
++  evdi->pixel_area_limit = pixel_area_limit;
+   evdi->pixel_per_second_limit = pixel_per_second_limit;
+   painter->drm_filp = file;
+   kfree(painter->edid);
diff -Nru evdi-1.9.0+dfsg/debian/patches/series 
evdi-1.12.0+dfsg/debian/patches/series
--- evdi-1.9.0+dfsg/debian/patches/series   1969-12-31 19:00:00.0 
-0500
+++ evdi-1.12.0+dfsg/debian/patches/series  2022-11-01 11:56:26.0 
-0400
@@ -0,0 +1 @@
+0001-fix-6.0-ftbfs.patch
diff -Nru evdi-1.9.0+dfsg/library/evdi_lib.c evdi-1.12.0+dfsg/library/evdi_lib.c
--- evdi-1.9.0+dfsg/library/evdi_lib.c  2021-01-26 09:31:59.0 -0500
+++ evdi-1.12.0+dfsg/library/evdi_lib.c 2022-07-13 09:58:06.0 -0400
@@ -29,7 +29,7 @@
 #define EVDI_INVALID_DEVICE_INDEX -1
 
 #define EVDI_MODULE_COMPATIBILITY_VERSION_MAJOR 1
-#define EVDI_MODULE_COMPATIBILITY_VERSION_MINOR 8
+#define EVDI_MODULE_COMPATIBILITY_VERSION_MINOR 9
 #define EVDI_MODULE_COMPATIBILITY_VERSION_PATCH 0
 
 #define evdi_log(...) do { \
@@ -468,15 +468,45 @@
return dev_index;
 }
 
-static int find_unused_card_for(const char *sysfs_parent_device_path)
+static bool is_correct_parent_device(const char *dirname, const char 
*parent_device)
 {
+   char link_path[PATH_MAX];
+
+   snprintf(link_path, PATH_MAX - 7, "%s/device", dirname);
+
+   if (parent_device == NULL)
+   return access(link_path, F_OK) != 0;
+
+   char link_resolution[PATH_MAX];
+   const ssize_t link_resolution_len = readlink(link_path, 
link_resolution, PATH_MAX);
+
+   if (link_resolution_len == -1 || link_resolution_len == PATH_MAX)
+   

Bug#1022864: gscan2pdf: unnecessary test dependency on autopkgtest?

[Jeff]

gscan2pdf doesn't depend on autopkgtest directly. It has:

Testsuite: autopkgtest-pkg-perl

in the control file. Is that somehow incorrect?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023275: boxes FTCBFS: strips with the build architecture strip

[Helmut Grohne]

Source: boxes
Version: 2.2.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

boxes fails to cross build from source, because it strips with the build
architecture strip. Beyond breaking cross compilation, doing so also
breaks DEB_BUILD_OPTIONS=nostrip as well as generation of -dbgsym
packages. Fixing this is not entirely trivial as the build target forces
this stripping. A relatively easy way to avoid it is switching to the
debug target, but doing so looses the -O flag. I'm attaching a patch for
your convenience.

Helmut
diff --minimal -Nru boxes-2.2.0/debian/changelog boxes-2.2.0/debian/changelog
--- boxes-2.2.0/debian/changelog2022-09-23 12:06:21.0 +0200
+++ boxes-2.2.0/debian/changelog2022-11-01 13:29:35.0 +0100
@@ -1,3 +1,10 @@
+boxes (2.2.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 01 Nov 2022 13:29:35 +0100
+
 boxes (2.2.0-1) unstable; urgency=medium
 
   * debian/watch: Switch to watch tagged versions on github releases page
diff --minimal -Nru boxes-2.2.0/debian/rules boxes-2.2.0/debian/rules
--- boxes-2.2.0/debian/rules2022-09-23 12:06:21.0 +0200
+++ boxes-2.2.0/debian/rules2022-11-01 13:29:35.0 +0100
@@ -1,6 +1,9 @@
 #!/usr/bin/make -f
 
-export CFLAGS_ADDTL+=$(shell dpkg-buildflags --get CFLAGS)
+export CFLAGS_ADDTL+=-O $(shell dpkg-buildflags --get CFLAGS)
 
 %:
dh $@
+
+override_dh_auto_build:
+   dh_auto_build -- debug

Bug#1018915: v4l-utils: FTBFS with libbpf 1.0.0

[Sean Young]

Hi Sudip, Gregor,

On Mon, Oct 31, 2022 at 11:29:29AM +, Sudip Mukherjee wrote:
> On Mon, Oct 31, 2022 at 10:44 AM Gregor Jasny  wrote:
> > One thing I miss in the patch is tightening the pkg-config rule to a
> > minimum required version which provides LIBBPF_OPTS. Proper place would
> > be here:
> >
> > https://git.linuxtv.org/v4l-utils.git/tree/configure.ac#n567
> 
> Ok, I might need help for this one. I will first check what will be
> the minimum libbpf version required for this change. afaik, libbpf/0.8
> is ok with these changes.

Looking at the bpf source code, 0.7 will be the required version. 

I think this is the correct autoconf line, but my autoconf knowledge is
very limited.

PKG_CHECK_MODULES([LIBBPF], [libbpf >= 0.7], [bpf_pc=yes], [bpf_pc=no])

Let me get back to you on testing.


Sean

Bug#1020938: khard: missing Python dependency python3-pkg-resources

[Sebastian Crane]

Dear Adrian,

Thank you very much for digging deeper into this issue! If I understand
you correctly, this bug report can be closed now, since the next Debian
Stable release would rebuild the package anyway. Is this indeed the
case?

Best wishes,

Sebastian

Bug#1023100: ITP: cancelreader -- A cancelable reader for Go

[Holger Levsen]

On Tue, Nov 01, 2022 at 03:10:37PM +, Martin Dosch wrote:
> https://github.com/muesli/cancelreader#usage says 'the cancel function can be 
> used to interrupt a blocking Read call'.

thanks! I think something like this should be included in the (long and/or
short) description...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Money is worth nothing on a dead planet.


signature.asc
Description: PGP signature

Bug#1023100: ITP: cancelreader -- A cancelable reader for Go

[Martin Dosch]

https://github.com/muesli/cancelreader#usage says 'the cancel function can be 
used to interrupt a blocking Read call'.

Am 31. Oktober 2022 19:11:22 UTC schrieb Holger Levsen :
>On Sun, Oct 30, 2022 at 09:23:52AM +0100, Martin Dosch wrote:
>>   Description : A cancelable reader for Go
>> 
>>  CancelReader
>>  .
>>  Latest Release (https://github.com/muesli/cancelreader/releases) Go Doc
>>  (https://pkg.go.dev/github.com/muesli/cancelreader) Software License
>>  (/LICENSE) Build Status (https://github.com/muesli/cancelreader/actions)
>>  Go ReportCard (https://goreportcard.com/report/muesli/cancelreader)
>>  .
>>  A cancelable reader for Go
>>  .
>>  This package is based on the fantastic work of Erik Geiser
>>  (https://github.com/erikgeiser) in Charm's Bubble Tea
>>  (https://github.com/charmbracelet/bubbletea) framework.
>> 
>>  This is a build-depend for newer versions of
>> golang-github-charmbracelet-bubbletea.
>
>what's a cancelable reader?
>
>

Bug#1023274: virtualbox: ExtensionPacks - VNC - ExtPack.xml: Invalid version string

[Thom]

Package: virtualbox
Version: 7.0.2-dfsg-2
Severity: normal
X-Debbugs-Cc: thom1...@gmail.com

Dear Maintainer,

user@host: ~ $ LANG=C

user@host: ~ $ sudo aptitude -t experimental install virtualbox 
virtualbox-ext-pack virtualbox-guest-additions-iso
The following NEW packages will be installed:
  dctrl-tools{a} dh-dkms{a} dkms{a} libgsoap-2.8.117{a} liblzf1{a} 
libqt5help5{a} libvncserver1{a} virtualbox virtualbox-dkms{a} 
virtualbox-ext-pack
  virtualbox-guest-additions-iso virtualbox-qt{a}
0 packages upgraded, 12 newly installed, 0 to remove and 53 not upgraded.
Need to get 90.5 MB of archives. After unpacking 242 MB will be used.
Do you want to continue? [Y/n/?]

[skip]

Setting up virtualbox (7.0.2-dfsg-2) ...
Setting up virtualbox-ext-pack (7.0.2-1) ...
virtualbox-ext-pack: downloading: 
https://download.virtualbox.org/virtualbox/7.0.2/Oracle_VM_VirtualBox_Extension_Pack-7.0.2.vbox-extpack
The file will be downloaded into /usr/share/virtualbox-ext-pack
License accepted.
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Successfully installed "Oracle VM VirtualBox Extension Pack".

[skip]

user@host: ~ $ VBoxManage list extpacks
Extension Packs: 2
Pack no. 0:   Oracle VM VirtualBox Extension Pack
Version:7.0.2
Revision:   154219
Edition:
Description:Oracle Cloud Infrastructure integration, Host Webcam, 
VirtualBox RDP, PXE ROM, Disk Encryption, NVMe, full VM encryption.
VRDE Module:VBoxVRDP
Crypto Module:  VBoxPuelCrypto
Usable: true
Why unusable:

Pack no. 1:   VNC
Version:
Revision:   0
Edition:
Description:
VRDE Module:
Crypto Module:
Usable: false
Why unusable:   Failed to load 
'/usr/lib/virtualbox/ExtensionPacks/VNC/ExtPack.xml': Invalid version string: 
@VBOX_VERSION_STRING_RAW@

user@host: ~ $ cat /usr/lib/virtualbox/ExtensionPacks/VNC/ExtPack.xml

http://www.virtualbox.org/VirtualBoxExtensionPack; version="1.0">
VNC
VNC plugin module
@VBOX_VERSION_STRING_RAW@
//. should be 7.0.2 

VBoxVNCMain
VBoxVNC






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

Kernel: Linux 6.0.0-2-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 virtualbox depends on:
ii  adduser   3.129
ii  iproute2  6.0.0-1
ii  libc6 2.35-4
ii  libcurl3-gnutls   7.86.0-1
ii  libdevmapper1.02.12:1.02.185-2
ii  libgcc-s1 12.2.0-7
ii  libgl11.5.0-1
ii  libgsoap-2.8.117  2.8.117-2+b1
ii  liblzf1   3.6-3
ii  libogg0   1.3.5-1
ii  libpng16-16   1.6.38-2
ii  libsdl1.2debian   1.2.15+dfsg2-8
ii  libssl3   3.0.5-4
ii  libstdc++612.2.0-7
ii  libvncserver1 0.9.13+dfsg-4
ii  libvorbis0a   1.3.7-1
ii  libvpx7   1.12.0-1
ii  libx11-6  2:1.8.1-2
ii  libxcursor1   1:1.2.1-1
ii  libxml2   2.9.14+dfsg-1.1
ii  libxt61:1.2.1-1
ii  procps2:3.3.17-7.1
ii  python3   3.10.6-1
ii  python3.103.10.8-1
ii  virtualbox-dkms [virtualbox-modules]  7.0.2-dfsg-2
ii  zlib1g1:1.2.11.dfsg-4.1

Versions of packages virtualbox recommends:
ii  libqt5core5a5.15.6+dfsg-3
ii  libqt5gui5  5.15.6+dfsg-3
ii  libqt5opengl5   5.15.6+dfsg-3
ii  libqt5widgets5  5.15.6+dfsg-3
ii  libxcb1 1.15-1
ii  libxext62:1.3.4-1+b1
ii  virtualbox-qt   7.0.2-dfsg-2

Versions of packages virtualbox suggests:
pn  vde2
ii  virtualbox-guest-additions-iso  7.0.2-1

-- no debconf information

Bug#1013259: samba-libs: Possible policy violation (now with libndr.so.2 => libndr.so.3)

[Michael Tokarev]

Hmm. Other sssd packages are also affected by this.
Not only sssd-ad but sssd-ipa and sssd-ad-common.

Added the Breaks for these in Bullseye (and also in Ubuntu Jammy, which
has exactly the same problem).  Will be in the next upload.

/mjt

Bug#866823: samba: does not follow symbolic links

[Michael Tokarev]

Control: tag -1 - confirmed upstream + moreinfo
Control: notfound -1 2:4.16.6+dfsg-6

Ok. So my testing yesterday was wrong, and I just tested a
hidden file as the symlink target. What a shame.

So, back to this bugreport: it looks like samba does all the
right thing with symlinks now - at least bullseye 4.13 and
bullseye-backports 4.16 and unstable 4.17 all does well in
this context.

It looks like this bug can be closed?

Thanks,

/mjt

Bug#1023273: Breaks packages like ocrmypdf

[Klaus Ethgen]

Package: ghostscript
Version: 10.0.0~dfsg-6
Severity: important

~> ocrmypdf -l deu -c y.pdf x.pdf
Opened a file
Scanning contents: 100%|#| 
16/16 [00:00<00:00, 729.27page/s]
Start processing 8 pages concurrently
Opened a file
6 Opened a file
6 Opened a file
5 Opened a file
4 Opened a file
7 Opened a file
8 Opened a file
3 Opened a file
2 Opened a file
1 Opened a file
   11 Opened a file
9 Opened a file
   10 Opened a file
   12 Opened a file
   15 Opened a file
   13 Opened a file
   16 Opened a file
   14 Opened a file
OCR: 100%|| 
16.0/16.0 [00:18<00:00,  1.18s/page]
Postprocessing...
Opened a file
GPL Ghostscript 10.0.0 (2022-09-21)
Copyright (C) 2022 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Unrecoverable error: rangecheck in .putdeviceprops

SubprocessOutputError: Ghostscript PDF/A rendering failed

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

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

Versions of packages ghostscript depends on:
ii  libc62.35-4
ii  libgs10  10.0.0~dfsg-6

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
ii  ghostscript-x  10.0.0~dfsg-6

-- no debconf information

-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1023272: RM: panko -- ROM; unmaintained upstream

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal

Hi,

Panko isn't maintained upstream and is now EOL. Let's remove it from Debian
before Brookworm.

Cheers,

Thomas Goirand (zigo)

Bug#1023156: haskell-gi-gtk FTBFS on armel

[Scott Talbert]

On Sun, 30 Oct 2022, Adrian Bunk wrote:


haskell-gi-gtk has only once ever been built successfully on armel.
Unless someone has a better suggestion, my short-term Plan B would be
that I request the removal of haskell-gi-gtk and reverse dependencies
on armel.


I think that's probably a good plan.  I believe I may have reported this 
bug (or one similar to it) to ghc, but it didn't sound like it was 
something that was going to fixed quickly/easily.


Scott

Bug#1023271: ITP: spacebar -- SMS/MMS application for Plasma Mobile

[Marco Mattiolo]

Package: wnpp
Severity: wishlist
Owner: Marco Mattiolo 
X-Debbugs-Cc: debian-de...@lists.debian.org, marco.matti...@hotmail.it

* Package name    : spacebar
  Version : 22.09
  Upstream Author : 
* URL : https://invent.kde.org/plasma-mobile/spacebar
* License : GPL
  Programming Lang: C++, QML
  Description : SMS/MMS application for Plasma Mobile


Spacebar is an SMS/MMS application that primarily targets Plasma Mobile.
It depends on Qt and few KDE Frameworks (Kirigami2, KI18n, KPeople, and 
ModemManagerQt).

Bug#1023268: Re : [Aptitude-devel] Bug#1023268: aptitude: apt-listchanges fails

[nicolas . patrois]

Le 01/11/2022 14:20:14, Axel Beckert a écrit :

> Hrm, this looks to me as if apt-listchanges wants to open some GTK
> program.

Yes, I think so; but there is no such bug with apt or with synaptic.

> For me, apt-listchanges works fine, but I let it display news just
> with less. So a few question:

> * Does this already happen for quite a while or is this a new
>   behaviour from just very recently?

Recently but as I run aptitude sometimes (mostly when apt fails for some 
reason), I don’t know if it’s very recent or not.

> * Which pager have you configured (for apt-listchanges)? — I have no
>   idea, why apt-listchanges should try to open a GTK application
>   otherwise.

apt-listchanges works fine with apt and I use the GTK application.
Maybe it’s because I run aptitude through sudo, I don’t run apt with sudo.
What’s is interesting is that there is a coredump.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#1023270: kexec-tools: Fix kexec on Xen

[Samuel Thibault]

Package: kexec-tools
Version: 1:2.0.24-1+b1
Severity: normal

Hello,

Currently, kexec doesn't work on Xen-booted systems, one just gets

  Could not get memory layout

This is because kexec-tools was built without libxenctrl support. Simply
adding the build-dep fixes that, as the attached patch does.

Samuel

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Versions of packages kexec-tools depends on:
ii  cdebconf [debconf-2.0] 0.264
ii  debconf [debconf-2.0]  1.5.79
ii  dpkg   1.21.9+b1
ii  libc6  2.35-4
ii  lsb-base   11.4
ii  sysvinit-utils [lsb-base]  3.05-6

kexec-tools recommends no packages.

kexec-tools suggests no packages.

-- debconf information:
* kexec-tools/load_kexec: false
* kexec-tools/use_grub_config: false

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2022-11-01 14:26:38.925235519 +0100
+++ debian/control  2022-11-01 14:26:41.405249314 +0100
@@ -3,7 +3,7 @@
 Homepage: https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/
 Priority: optional
 Maintainer: Khalid Aziz 
-Build-Depends: debhelper (>= 10.0.0), gnu-efi (>=3.0a-4)[ia64], libz-dev[arm64 
ia64], po-debconf
+Build-Depends: debhelper (>= 10.0.0), gnu-efi (>=3.0a-4)[ia64], libz-dev[arm64 
ia64], po-debconf, libxen-dev
 Standards-Version: 4.5.1.0
 
 Package: kexec-tools

Bug#1022972: Additional information

[Max Görner]

I want to add two pieces of additional information.

First, I removed nvidia-kernel-dkms and rebooted. The problem persists so I
guess this package does not affect the bug.

Second, similar to the aforementioned problem with keepasxc, I cannot finish
entering a password into pinentry, which is used by the gpg-agent to get the
private key's passphrase. I have to click on the OK button. I am unsure
whether this is related to the problem with the arrow keys, though.

Bug#1012333: u-boot-menu: add support for using config fragments

[Arnaud Ferraris]

Hi,

Le 23/09/2022 à 19:22, Vagrant Cascadian a écrit :

On 2022-09-23, Arnaud Ferraris wrote:

On Sat, 10 Sep 2022 10:18:39 -0700 Vagrant Cascadian
 wrote:

On 2022-06-04, Jonas Smedegaard wrote:

Quoting Arnaud Ferraris (2022-06-04 16:39:03)

Currently u-boot-menu makes use of a single configuration file
one has to edit in order to change the default options. It could
be useful to use config fragments containing only one (or more)
variables, so that different packages could change different
config options (for example, one fragment could modify the
default cmdline, while another one could change the DTB folder).


Thanks, that sounds like a useful feature indeed.

Seems more sensible for me, however, to implement this using debconf.

Otherwise, installation and removal of a package would need to trigger
u-boot-menu, and u-boot-menu would need to specially examine such
cofigfile snippets to skip snippets belonging to removed but not purged
packages.


Well, you could implement configuration files snippets directory outside
of /etc (e.g. /usr/share/u-boot-menu/snippet.d or something like that),
which would avoid this problem. u-boot-menu could have a dpkg trigger
that for when files in this directory change.


I quite like this approach, thanks for the suggestion!

Do you think allowing both /etc/u-boot-menu.d (aimed solely at
end-users) and /usr/share/u-boot-menu/conf.d (for other packages and/or
derivatives), with a dpkg trigger only on the latter, would make sense?
Or should we aim only for the /usr/share... approach?


I think it's reasonable, though you'd have to encourage packages to
*not* use /etc/u-boot-menu*.d, maybe documenting it in
README.Debian...


I added some notes about this in both the manpage and a (new) README.Debian



I could see a preference order being /etc/default/u-boot which is
overidden by /usr/share/u-boot-menu/conf.d which is overridden by
/etc/u-boot-menu.d (or /etc/u-boot-menu/conf.d ?).


Yes, that makes the most sense to me (I also used 
/etc/u-boot-menu/conf.d instead of /etc/u-boot-menu.d for consistency).




A fancy implementation might allow /etc to override /usr/share if the
filenames match, but that might be more complicated than it's
worth. Jonas knows I've fallen into that rabbit hole in packages of the
ancient past... :)


Hmm, I don't think that's worth the hassle as it would add *a lot* of 
complexity for very little gain IMHO.






That seems a lot simpler than introducing the complexity of debconf
generated configuration files...


Indeed, so far my experiments with debconf for solving this matter have
been sub-optimal at best.

I'll update my patch in the next few days and submit it asap.


Updated patch attached, as always comments and suggestions are welcome :)

Cheers,
Arnaud



Thanks!


live well,
   vagrant
From 2949907b16bff2857cff0fb713967d264feb6567 Mon Sep 17 00:00:00 2001
From: Arnaud Ferraris 
Date: Tue, 1 Nov 2022 13:33:22 +0100
Subject: [PATCH] u-boot-update: allow using config fragments

In order to allow other packages and/or derivative distros to configure
specific aspects of `u-boot-menu` it can be useful to allow using config
fragments. This patch therefore implements loading config files from
`/usr/share/u-boot-menu/conf.d` (to be used by other packages) and
`/etc/u-boot-menu.d` (to be used by end-users, taking priority over
files under the preceding location), overriding the values loaded from
the default configuration file.

This commit also adds a dpkg trigger so any modification of files under
`/usr/share/u-boot-menu/conf.d` will result in `u-boot-update` being
automatically run.
---
 debian/README.Debian| 32 
 debian/u-boot-menu.postinst |  8 
 debian/u-boot-menu.triggers |  1 +
 u-boot-update   |  9 +
 u-boot-update.8 | 16 +++-
 5 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 debian/README.Debian
 create mode 100755 debian/u-boot-menu.postinst
 create mode 100644 debian/u-boot-menu.triggers

diff --git a/debian/README.Debian b/debian/README.Debian
new file mode 100644
index 000..f502387
--- /dev/null
+++ b/debian/README.Debian
@@ -0,0 +1,32 @@
+Configuration files handling
+
+
+Configuration files are read from the following locations, ordered by priority:
+1. /etc/default/u-boot
+2. /usr/share/u-boot-menu/conf.d/*.conf
+3. /etc/u-boot-menu/conf.d/*.conf
+
+Each configuration file can contain one or more environment variable and is
+sourced by u-boot-update. See u-boot-update(8) for more information about
+allowed variables.
+
+Variables values can be overriden by highest-priority configuration files. For
+example, if /etc/default/u-boot contains `U_BOOT_DEFAULT=l0` and there is a
+file named /usr/share/u-boot-menu/conf.d/new-default.conf containing
+`U_BOOT_DEFAULT=l0r`, then the menu entry labelled `l0r` will be set as the
+default entry. Moreover, if there is a file named, for 

Bug#1023268: [Aptitude-devel] Bug#1023268: aptitude: apt-listchanges fails

[Axel Beckert]

Hi Nicolas,

Nicolas Patrois wrote:
> apt-listchanges fails with aptitude (not with apt or with synaptic).

Interesting. Thanks for the bug report.

> Here is its error output:
> 
> Récupération des rapports de bogue… Fait
> Analyse des informations Trouvé/Corrigé… Fait
> Invalid MIT-MAGIC-COOKIE-1 key
> Invalid MIT-MAGIC-COOKIE-1 key
> 
> (apt-listchanges:9303): Gtk-CRITICAL **: 12:49:38.236:
> _gtk_style_provider_private_get_settings: assertion
> 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
> 
> (apt-listchanges:9303): Gtk-CRITICAL **: 12:49:38.236:
> _gtk_style_provider_private_get_settings: assertion
> 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
> 
> (apt-listchanges:9303): Gtk-CRITICAL **: 12:49:38.236:
> _gtk_style_provider_private_get_settings: assertion
> 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
> Segmentation fault (core dumped)
> E: Le sous-processus /usr/bin/apt-listchanges --apt || test $? -lt 10 a 
> renvoyé
> un code d'erreur (1)
> E: Failure running script /usr/bin/apt-listchanges --apt || test $? -lt 10

Hrm, this looks to me as if apt-listchanges wants to open some GTK
program.

For me, apt-listchanges works fine, but I let it display news just
with less. So a few question:

* Does this already happen for quite a while or is this a new
  behaviour from just very recently?

* Which pager have you configured (for apt-listchanges)? — I have no
  idea, why apt-listchanges should try to open a GTK application
  otherwise.

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

Bug#1023269: debhelper: dh_installchangelogs doesn't give correct command to read complete changelog

[Shengjing Zhu]

Package: debhelper
Version: 13.10.1
Severity: normal
X-Debbugs-Cc: z...@debian.org

The changelog installed by dh_installchangelogs says:

> # To read the complete changelog use `apt changelog debootstrap`.

But it doesn't seem to work for me.

After searching, I find the correct command should be:

`apt changelog -o Acquire::Changelogs::AlwaysOnline=true debootstrap`

Bug#1022289: libassuan: FTBFS: configure: error: libgpg-error was not found

[Andreas Metzler]

On 2022-10-23 Andreas Metzler  wrote:
[...]
> Caused by new gpg-error dropping gpg-error-config, this works for me:

> --- libassuan-2.5.5/debian/rules2022-04-30 17:47:12.0 +0200
> +++ patched/libassuan-2.5.5.patched/debian/rules2022-10-23 
> 18:23:40.505849321 +0200
> @@ -27,7 +27,6 @@
> for cpu in i686 x86_64; do \
>  mkdir -p build-$$cpu-w64-mingw32 && \
>  cd build-$$cpu-w64-mingw32 && $(WIN_FLAGS) ../configure \
> -   --with-libgpg-error-prefix=/usr/$$cpu-w64-mingw32 \

Hello,

Commited to GIT, please give me a heads up if you want me to make either
a NMU or add myself to Uploaders and make a regular upload. (Although
this is a serious bugreport I do not think it is yet so urgent to
require a upload without maintainer feedback. - Might change, e.g if
libassuan blocked a transition.)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


signature.asc
Description: PGP signature

Bug#932820: vanguards: Use Python 3 instead of PyPy, because we are going to remove unsupported PyPy

[Bastian Germann]

On Sat, 15 Oct 2022 22:56:30 +0200 Micha Lenk  wrote:

* dh-python has a Debhelper sequence for pypy (Python 2), but not
   for pypy3 (Python 3). There is no bug report for dh-python open
   that would request it.

* Once a pypy3 Debhelper sequence is available, the following pypy3
   packages need to be created (just from looking at vanguards's
   Build-Depends:)
   * pypy3-setuptools
   * pypy3-stem
   * pypy3-pytest
   * pypy3-ipaddress


#1011926 will autoremove pypy (and with it vanguards) in a month.
You should really think of moving to CPython 3 as long as the pypy3
conditions are not fulfilled. I do not think there is high probability
of this happening before bookworm freeze, so if you want to keep
vanguards in bookworm CPython is the way to go.

Bug#1023268: aptitude: apt-listchanges fails

[Nicolas Patrois]

Package: aptitude
Version: 0.8.13-5
Severity: important

Dear Maintainer,

apt-listchanges fails with aptitude (not with apt or with synaptic).
Here is its error output:

Récupération des rapports de bogue… Fait
Analyse des informations Trouvé/Corrigé… Fait
Invalid MIT-MAGIC-COOKIE-1 key
Invalid MIT-MAGIC-COOKIE-1 key

(apt-listchanges:9303): Gtk-CRITICAL **: 12:49:38.236:
_gtk_style_provider_private_get_settings: assertion
'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(apt-listchanges:9303): Gtk-CRITICAL **: 12:49:38.236:
_gtk_style_provider_private_get_settings: assertion
'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(apt-listchanges:9303): Gtk-CRITICAL **: 12:49:38.236:
_gtk_style_provider_private_get_settings: assertion
'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
Segmentation fault (core dumped)
E: Le sous-processus /usr/bin/apt-listchanges --apt || test $? -lt 10 a renvoyé
un code d'erreur (1)
E: Failure running script /usr/bin/apt-listchanges --apt || test $? -lt 10


-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 12.1.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.3
  libsigc++ version: 2.10.8
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.3.20220423
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-gate.so.1 (0xb7f38000)
libapt-pkg.so.6.0 => /lib/i386-linux-gnu/libapt-pkg.so.6.0 (0xb7897000)
libncursesw.so.6 => /lib/i386-linux-gnu/libncursesw.so.6 (0xb7854000)
libtinfo.so.6 => /lib/i386-linux-gnu/libtinfo.so.6 (0xb7828000)
libsigc-2.0.so.0 => /lib/i386-linux-gnu/libsigc-2.0.so.0 (0xb781f000)
libcwidget.so.4 => /lib/i386-linux-gnu/libcwidget.so.4 (0xb7718000)
libsqlite3.so.0 => /lib/i386-linux-gnu/libsqlite3.so.0 (0xb758d000)
libboost_iostreams.so.1.74.0 => 
/lib/i386-linux-gnu/libboost_iostreams.so.1.74.0 (0xb7575000)
libxapian.so.30 => /lib/i386-linux-gnu/sse2/libxapian.so.30 (0xb731f000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb731a000)
libstdc++.so.6 => /lib/i386-linux-gnu/libstdc++.so.6 (0xb70f8000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6ff1000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6fca000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6d9e000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb6d81000)
libbz2.so.1.0 => /lib/i386-linux-gnu/libbz2.so.1.0 (0xb6d6f000)
liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xb6d42000)
liblz4.so.1 => /lib/i386-linux-gnu/liblz4.so.1 (0xb6d1c000)
libzstd.so.1 => /lib/i386-linux-gnu/libzstd.so.1 (0xb6c67000)
libudev.so.1 => /lib/i386-linux-gnu/libudev.so.1 (0xb6c39000)
libsystemd.so.0 => /lib/i386-linux-gnu/libsystemd.so.0 (0xb6b64000)
libgcrypt.so.20 => /lib/i386-linux-gnu/libgcrypt.so.20 (0xb6a53000)
libxxhash.so.0 => /lib/i386-linux-gnu/libxxhash.so.0 (0xb6a34000)
/lib/ld-linux.so.2 (0xb7f3a000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6a2f000)
libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb6a25000)
libcap.so.2 => /lib/i386-linux-gnu/libcap.so.2 (0xb6a1a000)
libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0xb69f)

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

Kernel: Linux 5.16.0-6-686-pae (SMP w/3 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-5
ii  libapt-pkg6.0 2.5.4
ii  libboost-iostreams1.74.0  1.74.0-17
ii  libc6 2.35-4
ii  libcwidget4   0.5.18-6
ii  libgcc-s1 12.2.0-7
ii  libncursesw6  6.3+20220423-2
ii  libsigc++-2.0-0v5 2.10.8-1
ii  libsqlite3-0  3.39.4-1
ii  libstdc++612.2.0-7
ii  libtinfo6 6.3+20220423-2
ii  libxapian30   1.4.21-1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.21.9
ii  sensible-utils  0.0.17

Versions of packages aptitude suggests:
ii  apt-xapian-index0.53
ii  aptitude-doc-en [aptitude-doc]  0.8.13-5
ii  aptitude-doc-fr [aptitude-doc]  0.8.13-5
ii  debtags 2.1.5
ii  tasksel 3.70

-- no debconf information

Bug#1023267: sc-im: scopen fails with gvim not found (if it is not installed)

[Gürkan Myczko]

Package: sc-im
Version: 0.8.2+ds-1
Severity: normal

Dear Maintainer,

sc-im ships a shell script called scopen, it looks like:
8<---snip
[[ $Ext == htm* ]] && exec w3m "$File"
[[ $Ext =~ (sc|tab|csv) ]] && exec sc-im "$File"
[[ $Ext == pdf ]] && exec_bg evince "$File"

exec_bg gvim "$File"
snap--->8

there's calls to w3m, evince and gvim, however the sc-im binary
does not depend on them.

One way to get this fixed is to not ship scopen, another to add the
packages as Depends in the binary package.

Thanks,

Bug#1023178: microprofile: Contains non-free source

[Bastian Germann]

Am 01.11.22 um 13:03 schrieb Andrea Pappacoda:
I'll fix it as soon as possible, possibly in the 4.0 release. I've already uploaded the latest release to mentors, but 
it doesn't contain this fix.


For the 4.0 release you would have to clarify the license situation.
At least, the Unlicense has to be contained in the debian/copyright file even 
if it does not apply to any file.

Bug#1013904: rinse: support newer fedora/opensuse and arm64

[Emanuele Rocca]

On 2022-11-01 12:50, Emanuele Rocca wrote:
> I've downloaded Benjamin's changes locally and I'm currently testing
> them.

Just to confirm, I've successfull created amd64 chroots for all newly
supported fedora/opensuse releases. Essentially:

for f in 32 33 34 35 36; do sudo rinse --distribution fedora-$f --arch amd64 
--directory /srv/chroots/fedora-$f ; done

for s in 15.3 15.4; do sudo rinse --distribution opensuse-$s --arch amd64 
--directory /srv/chroots/opensuse-$s; done

Also opensuse 15.3 *arm64* works fine.

  Emanuele