Bug#1025832: transition: libkeduvocdocument

[Aurélien COUDERC]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: libkeduvocdocum...@packages.debian.org, Debian Qt/KDE Maintainers 

Control: affects -1 + src:libkeduvocdocument

Dear Release Team,

I’d like to request a transition slot for libkeduvocdocument.

It has 4 reverse dependencies:
- kanagram
- khangman
- kwordquiz
- parley

All 4 rebuild successfully with the new version of the library.

I’ve uploaded libktorrent 4:22.11.90-2 with the new ABI to experimental
and it builds successfully on all release architectures. [0]


Ben file:

title = "libkeduvocdocument";
is_affected = .depends ~ "libkeduvocdocument5" | .depends ~ 
"libkeduvocdocument5abi1";
is_good = .depends ~ "libkeduvocdocument5abi1";
is_bad = .depends ~ "libkeduvocdocument5";

[0] 
https://buildd.debian.org/status/package.php?p=libkeduvocdocument=experimental

Bug#1025831: vpb-driver: FTBFS due to missing threads.h

[Bo YU]

Source: vpb-driver
Version: 4.2.61-1.3
Severity: serious
Tags: ftbfs

Dear Maintainer,

The package has a ftbfs on all arch:

```
../../../include/vt/tonegen.h: In static member function ‘static void 
ToneGen::mutex_cleanup(void*)’:
../../../include/vt/tonegen.h:527:13: error: ‘pthread_mutex_unlock’ was not 
declared in this scope; did you mean ‘pthread_mutex_t’?
  527 | pthread_mutex_unlock((pthread_mutex_t*)p);
  | ^~~~
  | pthread_mutex_t
../../../include/vt/tonegen.h: In member function ‘void ToneGen::DoStop()’:
../../../include/vt/tonegen.h:538:17: error: ‘pthread_cond_broadcast’ was not 
declared in this scope; did you mean ‘pthread_condattr_t’?
  538 | pthread_cond_broadcast( _cond );
  | ^~
  | pthread_condattr_t
../../../include/vt/tonegen.h: In constructor ‘ToneGen::ToneGen()’:
../../../include/vt/tonegen.h:559:9: error: ‘pthread_mutex_init’ was not 
declared in this scope; did you mean ‘pthread_mutex_t’?
  559 | pthread_mutex_init(_mutex, NULL);
  | ^~
  | pthread_mutex_t
../../../include/vt/tonegen.h:560:9: error: ‘pthread_cond_init’ was not 
declared in this scope; did you mean ‘pthread_cond_t’?
  560 | pthread_cond_init(_cond, NULL);
 ...
```

The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=vpb-driver=all=4.2.61-1.3=1670637027=0

This should be easy to fix and I will update it once test and verify.


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1025713: marked as done (isenkram FTBFS: error: version numbers in d/changelog and isenkram/__init__.py do not match)

[Petter Reinholdtsen]

While I look at non-maintainer uploads as a nice gesture to help, and am
happy to see your contribution, I would like to point out that while
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu >
do not state that the package being NMU-ed need to be test built before
upload, it is considered best practice.

Note, I am very happy to see your NMU commited to the shared git
repository on salsa, and find it to be a good alternative to the
developer reference required NMU bug report on bugs.debian.org.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1025830: beauti2 fails to start

[Pierre Gruet]

Package: beast2-mcmc
Version: 2.7.2+dfsg-1
Severity: important

Hi,

When launching
$ beauti2
I get the exception message discussed in bug #1025829, then a window from the
beast package manager, then the program terminates.
In the console I have

Graphics Device initialization failed for :  es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing 
QuantumRenderer: no suitable pipeline found
at 
com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:222)
at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:261)
at 
com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
at 
com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
at 
com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
at 
com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
at 
com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no 
suitable pipeline found
at 
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94)
at 
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
... 1 more
java.lang.reflect.InvocationTargetException
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at beast.pkgmgmt.launcher.BeastLauncher.run(Unknown Source)
at beast.pkgmgmt.launcher.BeautiLauncher.main(Unknown Source)
Caused by: java.lang.RuntimeException: No toolkit found
at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:273)
at 
com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
at 
com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
at 
com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
at 
com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
at 
com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
at java.base/java.lang.Thread.run(Thread.java:833)

so probably there is an issue when loading openjfx. I whall investigate shortly
but nevertheless drop this bug so that it does not get forgotten.

Cheers,

-- 
Pierre


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
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 beast2-mcmc depends on:
ii  default-jre 2:1.17-73
ii  libantlr4-runtime-java  4.7.2-5
ii  libcolt-free-java   1.2.0+dfsg-7
ii  libhmsbeagle-java   3.1.2+dfsg-12+b1
ii  libopenjfx-java 11.0.11+0-1.1
ii  openjfx 11.0.11+0-1.1

beast2-mcmc recommends no packages.

beast2-mcmc suggests no packages.

-- no debconf information

Bug#1025829: prints an exception message at startup

[Pierre Gruet]

Package: beast2-mcmc
Version: 2.7.2+dfsg-1
Severity: normal

Hi,

When launching
$ beast2-mcmc
I get an exception message

java.lang.NullPointerException: Cannot invoke "java.io.InputStream.close()" 
because "" is null
at beast.pkgmgmt.launcher.BeastLauncher.copyFileUsingStream(Unknown 
Source)
at beast.pkgmgmt.launcher.BeastLauncher.createBeastPackage(Unknown 
Source)
at beast.pkgmgmt.launcher.BeastLauncher.installBEASTPackage(Unknown 
Source)
at beast.pkgmgmt.launcher.BeastLauncher.getPath(Unknown Source)
at beast.pkgmgmt.launcher.BeastLauncher.main(Unknown Source)
java.lang.NullPointerException: Cannot invoke "java.io.InputStream.close()" 
because "" is null
at beast.pkgmgmt.launcher.BeastLauncher.copyFileUsingStream(Unknown 
Source)
at beast.pkgmgmt.launcher.BeastLauncher.createBeastPackage(Unknown 
Source)
at beast.pkgmgmt.launcher.BeastLauncher.installBEASTPackage(Unknown 
Source)
at beast.pkgmgmt.launcher.BeastLauncher.getPath(Unknown Source)
at beast.pkgmgmt.launcher.BeastLauncher.main(Unknown Source)

There is an ongoing discussion in
https://github.com/CompEvol/beast2/issues/1060
but I guess the issue is on the Debian packaging side. I shall look at it soon
but nevertheless drop this bug so that it does not get forgotten.

Cheers,

-- 
Pierre


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
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 beast2-mcmc depends on:
ii  default-jre 2:1.17-73
ii  libantlr4-runtime-java  4.7.2-5
ii  libcolt-free-java   1.2.0+dfsg-7
ii  libhmsbeagle-java   3.1.2+dfsg-12+b1
ii  libopenjfx-java 11.0.11+0-1.1
ii  openjfx 11.0.11+0-1.1

beast2-mcmc recommends no packages.

beast2-mcmc suggests no packages.

-- no debconf information

Bug#1025828: cloud.debian.org: cloud-init may run time synchronization dependent jobs before the clock is synchronized

[Noah Meyerhans]

Package: cloud.debian.org
Severity: normal

Certain functionality built in to cloud-init depends on a reasonably
accurate clock, such as apt repo metadata signature verification.  In the
case where a system's hardware clock is far out of sync, chrony may not have
completed synchronization before apt tries to refresh apt caches in the
package_update_upgrade_install module or in a userdata shell script.  An
example of the resulting failure follows:

MS Name/IP address Stratum Poll Reach LastRx Last sample
===
^? 169.254.169.123   3   6 1 1   -2986h[ -2986h] +/-  586us
Sun Aug  7 13:25:16 UTC 2022
Get:2 http://cdn-aws.deb.debian.org/debian bullseye InRelease [116 kB]
Get:3 http://cdn-aws.deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Get:4 http://cdn-aws.deb.debian.org/debian bullseye-backports InRelease [49.0 
kB]
Reading package lists...
E: Release file for 
http://security.debian.org/debian-security/dists/bullseye-security/InRelease is 
not valid yet (invalid for another 124d 5h 58min 50s). Updates for this 
repository will not be applied.
E: Release file for 
http://cdn-aws.deb.debian.org/debian/dists/bullseye/InRelease is not valid yet 
(invalid for another 33d 20h 52min 34s). Updates for this repository will not 
be applied.
E: Release file for 
http://cdn-aws.deb.debian.org/debian/dists/bullseye-updates/InRelease is not 
valid yet (invalid for another 124d 6h 53min 11s). Updates for this repository 
will not be applied.
E: Release file for 
http://cdn-aws.deb.debian.org/debian/dists/bullseye-backports/InRelease is not 
valid yet (invalid for another 124d 6h 53min 11s). Updates for this repository 
will not be applied.
2022-08-07 13:25:17,663 - cc_scripts_user.py[WARNING]: Failed to run module 
scripts-user (scripts in /var/lib/cloud/instance/scripts)
2022-08-07 13:25:17,664 - util.py[WARNING]: Running module scripts-user 
() failed
Cloud-init v. 20.4.1 finished at Sun, 07 Aug 2022 13:25:17 +. Datasource 
DataSourceEc2Local.  Up 10.28 seconds

The userdata script was:

#!/bin/bash
chronyc sources
date
DEBIAN_FRONTEND=noninteractive apt-get update

A possible workaround to this is to run a command like `chronyc waitsync`
before apt.  It turns out to be not entirely trivial to insert such a
command in the right place with userdata, though.

We should make some reasonable effort to ensure the clock is in sync before
executing the cloud-final.service, which is where all the package
installation work happens.  It's not immediately clear exactly where we
should do this, whether it's in the chrony configs, cloud-init itself,
cloud-init's systemd configuration, or elsewhere.  And then, should the fix
be in one of the packages or the images?

Bug#1021846: [programmer11...@programist.ru: Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem]

[программист некто]

Hello. Sorry for long wait.

>программист некто: could you please try these changes and report back?

I tried the first patch with grub 2.06-7. Result: grub-install works without 
error.

Bug#1025795: live-build: --memtest option broken with current version of memtest86+

[Mark Nipper]

The attached patch, aside from the missing associated
documentation changes, seems to do the trick.  Please include or
modify as you see fit.

Thanks!

-- 
Mark Nipper
--- /usr/share/live/build/functions/configuration.sh.bk	2022-12-09 18:15:15.623888651 -0800
+++ /usr/share/live/build/functions/configuration.sh	2022-12-09 18:20:50.416814951 -0800
@@ -741,7 +741,7 @@
 		Echo_warning "You have specified a value of LB_ISO_VOLUME (--iso-volume) that is too long; the maximum length is 32 characters."
 	fi
 
-	if ! In_list "${LB_MEMTEST}" memtest86+ memtest86 none; then
+	if ! In_list "${LB_MEMTEST}" memtest86+ memtest86 memtest86+x32 memtest86+x64 none; then
 		Echo_error "You have specified an invalid value for LB_MEMTEST (--memtest)."
 		exit 1
 	fi
--- /usr/lib/live/build/config.bk	2022-12-09 18:22:30.001090431 -0800
+++ /usr/lib/live/build/config	2022-12-09 18:23:15.661216741 -0800
@@ -90,7 +90,7 @@
 \t[-k|--linux-flavours FLAVOUR|\"FLAVOURS\"]\n\
 \t[--linux-packages PACKAGE|\"PACKAGES\"]\n\
 \t[--loadlin true|false]\n\
-\t[--memtest memtest86+|memtest86|none]\n\
+\t[--memtest memtest86+|memtest86|memtest86+x32|memtest86+x64|none]\n\
 \t[--mirror-binary URL]\n\
 \t[--mirror-binary-security URL]\n\
 \t[--mirror-bootstrap URL]\n\
--- /usr/lib/live/build/binary_memtest.bk	2022-12-09 18:23:35.137270619 -0800
+++ /usr/lib/live/build/binary_memtest	2022-12-09 18:39:40.467932065 -0800
@@ -64,6 +64,14 @@
 	memtest86+)
 		Check_package chroot /boot/memtest86+.bin memtest86+
 		;;
+
+	memtest86+x32)
+		Check_package chroot /boot/memtest86+x32.bin memtest86+
+		;;
+
+	memtest86+x64)
+		Check_package chroot /boot/memtest86+x64.bin memtest86+
+		;;
 esac
 
 # Restoring cache

Bug#1025827: slic3r-prusa: FTBFS on armel mipsel powerpc riscv64 sh4 m68k

[Bo YU]

Source: slic3r-prusa
Version: 2.5.0+dfsg-3
Severity: important
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

The MR[0] has been submitted by bunk one month ago, I'm assuming you 
haven't noticed it because gitlab will not send notifications from a 
MR IIRC. Due to fail build on armel & mipsel, this will block the
package to testing I think. So please consider to merge the MR on next
upload, thanks.

[0]: https://salsa.debian.org/3dprinting-team/slic3r-prusa/-/merge_requests/3
-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1024596: usrmerge: remove hard-coded list of bi-arch directories

[Marco d'Itri]

On Nov 21, Luca Boccassi  wrote:

> > We could add a versioned Depends on libc6 (and the equivalent libcX on
> > !linux)) to usrmerge (and usr-is-merged) to ensure a "fixed" libc is
> > already installed (and only "fixed" libc-foo packages can be installed
> > afterwards). That Depends should be sufficient to also keep out older
> > libc-foo since iirc libc6 and libc6-foo are (transitively) version-locked).
Does this look right to everybody?

https://salsa.debian.org/md/usrmerge/-/commit/7284cd4b4b40231b3d4a1ef56d9217091e714b91

We also need a similar change in debootstrap: in setup_merged_usr(), 
skip adding the biarch directories on bullseye or newer.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1025826: alacritty: Wrong Icon Name in Alacritty.desktop

[Zhian Chen]

Package: alacritty
Version: 0.11.0-2
Severity: normal
X-Debbugs-Cc: moonexi...@gmail.com

Dear Maintainer,

I am very appreciated that Alacritty has entered into Official Repository 
thanks to your consistent hard works. The fresh package works very well!

A small bug: system can not render Alacritty's icon properly, and the solution 
is renaming Alacritty.desktop K-V `Icon=Alacritty` to `Icon=alacritty-term`, 
which would allow Alacritty uses `alacritty-term.svg` as its Icon. or just 
renaming `alacritty-term.svg` to `alacritty.svg` to keep the naming consistent.


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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 alacritty depends on:
ii  libc6   2.36-6
ii  libfontconfig1  2.13.1-4.5
ii  libfreetype62.12.1+dfsg-3
ii  libgcc-s1   12.2.0-9.1
ii  libxcb1 1.15-1

alacritty recommends no packages.

alacritty suggests no packages.

-- no debconf information

Bug#1024268: (no subject)

[Amy]

It now works as of the most recent updates.

Thank you.



OpenPGP_0xDE629EFF20C96984.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025825: ImportError: cannot import name 'safe_join' from 'flask'

[Rock Storm]

Package: grip
Version: 4.2.0-3
Severity: important
X-Debbugs-Cc: rockst...@gmx.com

Dear Maintainer,

Program will not even start with the following trace:

```
$ grip -b
Traceback (most recent call last):
  File "/usr/bin/grip", line 9, in 
load_entry_point('grip==4.2.0', 'console_scripts', 'grip')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 486, in 
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2867, 
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2471, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2477, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/share/grip/grip/__init__.py", line 13, in 
from .api import (
  File "/usr/share/grip/grip/api.py", line 8, in 
from .app import Grip
  File "/usr/share/grip/grip/app.py", line 28, in 
from .assets import GitHubAssetManager, ReadmeAssetManager
  File "/usr/share/grip/grip/assets.py", line 16, in 
from flask import safe_join
ImportError: cannot import name 'safe_join' from 'flask' 
(/usr/lib/python3/dist-packages/flask/__init__.py)
```

Please let me know if I can help to debug any further.


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

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

Versions of packages grip depends on:
ii  python3   3.10.6-1
ii  python3-docopt0.6.2-4
ii  python3-flask 2.2.2-2
ii  python3-markdown  3.4.1-2
ii  python3-path-and-address  2.0.1-3
ii  python3-pygments  2.13.0+dfsg-1
ii  python3-requests  2.27.1+dfsg-1

grip recommends no packages.

grip suggests no packages.

-- no debconf information

Bug#1025824: libmojo-ioloop-readwriteprocess-perl: wrong syscall use on armhf

[Steve Langasek]

Package: libmojo-ioloop-readwriteprocess-perl
Version: 0.32-1
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Hi Hideki,

The libmojo-ioloop-readwriteprocess-perl package is failing its autopkgtests
on armhf in Ubuntu with a SIGILL, blocking the perl 5.36 transition, because
upstream has added 'armv7l' to the list of uname() values for which it
"knows" the correct syscall to use for prctl.

As a result upstream has regressed prctl support on armhf, because it
hard-codes the OABI syscall number.  armhf is EABI.

A kernel for armhf is not guaranteed to provide the OABI syscall entry
points.  Since the newer armhf kernels used by Ubuntu for autopkgtests do
not, the autopkgtest fails with SIGILL.

Before upstream made this change, the code would fall back to the value of
_prctl *which is correct on this platform*.

Upstream should stop trying to "cleverly" override the system definitions of
syscall numbers.

The attached patch is sufficient to fix this module on armhf and make it
pass in Ubuntu.  It also makes it correct for Debian, where armhf kernels
are also not guaranteed to expose syscalls for an ABI that we don't use at
all in the distro.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libmojo-ioloop-readwriteprocess-perl-0.32/debian/patches/series 
libmojo-ioloop-readwriteprocess-perl-0.32/debian/patches/series
--- libmojo-ioloop-readwriteprocess-perl-0.32/debian/patches/series 
2022-02-21 16:53:42.0 -0800
+++ libmojo-ioloop-readwriteprocess-perl-0.32/debian/patches/series 
2022-12-09 17:35:11.0 -0800
@@ -1,2 +1,3 @@
 use-bin-true-in-tests
 typo-in-manual-page
+wrong-arm-syscall-use.patch
diff -Nru 
libmojo-ioloop-readwriteprocess-perl-0.32/debian/patches/wrong-arm-syscall-use.patch
 
libmojo-ioloop-readwriteprocess-perl-0.32/debian/patches/wrong-arm-syscall-use.patch
--- 
libmojo-ioloop-readwriteprocess-perl-0.32/debian/patches/wrong-arm-syscall-use.patch
1969-12-31 16:00:00.0 -0800
+++ 
libmojo-ioloop-readwriteprocess-perl-0.32/debian/patches/wrong-arm-syscall-use.patch
2022-12-09 17:37:30.0 -0800
@@ -0,0 +1,20 @@
+Description: remove boneheaded hard-coding of OABI syscall entry point
+ Package fails autopkgtests on armhf in Ubuntu because the kernel doesn't
+ expose the OABI syscall personality, and this code pointlessly hardcodes
+ a syscall number for the platform instead of using the system definition.
+Author: Steve Langasek 
+Last-Update: 2022-12-09
+Forwarded: no
+
+Index: 
libmojo-ioloop-readwriteprocess-perl-0.32/lib/Mojo/IOLoop/ReadWriteProcess/Session.pm
+===
+--- 
libmojo-ioloop-readwriteprocess-perl-0.32.orig/lib/Mojo/IOLoop/ReadWriteProcess/Session.pm
 
libmojo-ioloop-readwriteprocess-perl-0.32/lib/Mojo/IOLoop/ReadWriteProcess/Session.pm
+@@ -170,7 +170,6 @@
+ : ($machine eq "ppc" || $machine eq "ppc64le") ? 171
+ : $machine eq "ia64"   ? 1170
+ : $machine eq "alpha"  ? 348
+-: ($machine eq "arm" || $machine eq "armv7l")  ? 0x90 + 172
+ : $machine eq "avr32"  ? 148
+ : $machine eq "mips"   ? 4000 + 192
+ : $machine eq "mips64" ? 5000 + 153

Bug#1025823: qt6-base FTBFS on Alpha; Unknown Q_PROCESSOR_xxx macro

[Michael Cree]

Source: qt6-base
Version: 6.3.1+dfsg-10
Severity: important
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

The build fails with:
/<>/src/corelib/plugin/qelfparser_p.cpp:178:4: error: #error 
"Unknown Q_PROCESSOR_xxx macro, please update."

Full log at:
https://buildd.debian.org/status/fetch.php?pkg=qt6-base=alpha=6.3.1%2Bdfsg-10=1664652510=0

Attached is patch to provide the Q_PROCESSOR defines for Alpha.  With
that qt6-base builds successfully.

Cheers
Michael.

Index: qt6-base-6.3.1+dfsg/src/corelib/global/qprocessordetection.h
===
--- qt6-base-6.3.1+dfsg.orig/src/corelib/global/qprocessordetection.h
+++ qt6-base-6.3.1+dfsg/src/corelib/global/qprocessordetection.h
@@ -82,11 +82,12 @@
 /*
 Alpha family, no revisions or variants
 
-Alpha is bi-endian, use endianness auto-detection implemented below.
+Alpha is bi-endian; use auto-detection below.
 */
-// #elif defined(__alpha__) || defined(_M_ALPHA)
-// #  define Q_PROCESSOR_ALPHA
-// Q_BYTE_ORDER not defined, use endianness auto-detection
+#if defined(__alpha__) || defined(_M_ALPHA)
+#  define Q_PROCESSOR_ALPHA
+#  define Q_PROCESSOR_WORDSIZE 8
+#endif
 
 /*
 ARM family, known revisions: V5, V6, V7, V8
Index: qt6-base-6.3.1+dfsg/src/corelib/plugin/qelfparser_p.cpp
===
--- qt6-base-6.3.1+dfsg.orig/src/corelib/plugin/qelfparser_p.cpp
+++ qt6-base-6.3.1+dfsg/src/corelib/plugin/qelfparser_p.cpp
@@ -141,6 +141,8 @@ struct ElfMachineCheck
 static const Elf32_Half ExpectedMachine =
 #if 0
 // nothing
+#elif defined(Q_PROCESSOR_ALPHA)
+EM_ALPHA
 #elif defined(Q_PROCESSOR_ARM_32)
 EM_ARM
 #elif defined(Q_PROCESSOR_ARM_64)
@@ -407,6 +409,7 @@ Q_DECL_UNUSED Q_DECL_COLD_FUNCTION stati
 switch (r.machine) {
 // list definitely not exhaustive!
 case EM_NONE:   d << ", no machine"; break;
+case EM_ALPHA:	d << ", Alpha"; break;
 case EM_ARM:d << ", ARM"; break;
 case EM_AARCH64:d << ", AArch64"; break;
 #ifdef EM_BLACKFIN

Bug#1024106: traceshark: QCustomPlot transition

[Paul Wise]

On Tue, 15 Nov 2022 09:58:37 + Sudip Mukherjee wrote:

> I think this should not have "Severity: serious" yet. The qcustomplot
> transition has not yet started. imho, It will start when Sebastian
> confirms and its uploaded to unstable and then these are serious
> severity.

The transition has started, it would be good to get traceshark fixed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1025822: golang-github-masterminds-sprig-v3-dev: missing package relationships (conflicting files)

[Cyril Brulebois]

Package: golang-github-masterminds-sprig-v3-dev
Version: 3.2.3-1
Severity: serious
Justification: Policy 7.6

Hi,

My sid development chroot broke during the latest dist-upgrade due to:

Unpacking golang-github-masterminds-sprig-v3-dev (3.2.3-1) ...
…
 trying to overwrite 
'/usr/share/gocode/src/github.com/Masterminds/sprig/crypto.go', which is also 
in package golang-github-masterminds-sprig-dev 3.2.2-1

The newer package has no Breaks/Replaces that are customary when moving files 
around:
  
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

And for what it's worth, even if it's too late, I'm not sure the package
rename was really required in the first place. We have a number of
packages with either -vN or .vN in their names, but there are no strict
naming rules that I know of. :)


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1005418: Fails to build modules for Linux 5.13 onward

[Bastian Germann]

NMUing this package with the debdiff attached.diff -Nru vpb-driver-4.2.61/debian/changelog vpb-driver-4.2.61/debian/changelog
--- vpb-driver-4.2.61/debian/changelog  2022-12-10 00:47:42.0 +0100
+++ vpb-driver-4.2.61/debian/changelog  2022-12-10 00:42:50.0 +0100
@@ -1,3 +1,11 @@
+vpb-driver (4.2.61-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Convert to 3.0 source format (Closes: #1007564)
+  * Fix build on current Linux version (Closes: #1005418)
+
+ -- Bastian Germann   Sat, 10 Dec 2022 00:42:50 +0100
+
 vpb-driver (4.2.61-1.2) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru vpb-driver-4.2.61/debian/patches/debian.patch 
vpb-driver-4.2.61/debian/patches/debian.patch
--- vpb-driver-4.2.61/debian/patches/debian.patch   1970-01-01 
01:00:00.0 +0100
+++ vpb-driver-4.2.61/debian/patches/debian.patch   2022-12-10 
00:42:50.0 +0100
@@ -0,0 +1,221 @@
+--- vpb-driver-4.2.61.orig/src/vpb/Makefile
 vpb-driver-4.2.61/src/vpb/Makefile
+@@ -46,7 +46,9 @@ install:
+   echo "installing $$m --> $(MODULEDIR)"; \
+   install -m 644 $$m $(MODULEDIR);\
+   done
+-  /sbin/depmod
++ifeq ($(DESTDIR),)
++  /sbin/depmod $(KVERS)
++endif
+ 
+ clean distclean:
+   $(RM) *.o *.ko *~ core *.mod.c .*.cmd
+--- vpb-driver-4.2.61.orig/src/vpb/vpb.c
 vpb-driver-4.2.61/src/vpb/vpb.c
+@@ -97,14 +97,6 @@
+ #define MODVERSIONS
+ #endif
+ 
+-#ifdef MODVERSIONS
+-#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,4))
+-#include 
+-#else
+-#include 
+-#endif
+-#endif
+-
+ #include 
+ #include 
+ #include 
+@@ -279,7 +271,7 @@ int init_module(void)
+   printk(KERN_INFO NAME ": tmp [0x%lx] dev->res2 
[0x%lx]\n",
+   tmp, (unsigned 
long)dev->resource[2].start);
+ 
+-base2[numPCI] = 
ioremap_nocache(dev->resource[2].start &
++base2[numPCI] = ioremap(dev->resource[2].start &
+ PCI_BASE_ADDRESS_MEM_MASK,
+ sizeof(short)*SIZE_WD);
+ 
+--- vpb-driver-4.2.61.orig/src/vtcore/Makefile
 vpb-driver-4.2.61/src/vtcore/Makefile
+@@ -50,8 +50,10 @@ install:
+   echo "installing $$m --> $(MODULEDIR)"; \
+   install -m 644 $$m $(MODULEDIR);\
+   done
+-  /sbin/depmod
++ifeq ($(DESTDIR),)
++  /sbin/depmod $(KVERS)
+   @modprobe -r netjet > /dev/null 2>&1 || true
++endif
+ 
+ clean distclean:
+   rm -f *.o *.ko *~ core *.mod.c .*.cmd
+--- vpb-driver-4.2.61.orig/src/vtcore/vtcommon.h
 vpb-driver-4.2.61/src/vtcore/vtcommon.h
+@@ -49,14 +49,6 @@
+  #endif
+ #endif
+ 
+-#ifdef MODVERSIONS
+- #if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,4))
+-  #include 
+- #else
+-  #include 
+- #endif
+-#endif
+-
+ #include 
+ 
+ 
+--- vpb-driver-4.2.61.orig/src/vtcore/vtcore_main.c
 vpb-driver-4.2.61/src/vtcore/vtcore_main.c
+@@ -213,6 +213,34 @@ static inline const char *porttype(int t
+   }
+ } //}}}
+ 
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,6,0)
++#define VT_DEFINE_PROC_OPS(storage, name, _owner, _open, _write)  \
++storage const struct proc_ops name = {
\
++  .proc_open  = _open,\
++  .proc_read  = seq_read, \
++  .proc_lseek = seq_lseek,\
++  .proc_release   = single_release,   \
++  .proc_write = _write,   \
++}
++#else  /* LINUX_VERSION_CODE < KERNEL_VERSION(5,6,0) */
++#define VT_DEFINE_PROC_OPS(storage, name, _owner, _open, _write)  \
++storage const struct file_operations name = { \
++  .owner  = _owner,   \
++  .open   = _open,\
++  .read   = seq_read, \
++  .llseek = seq_lseek,\
++  .release= single_release,   \
++  .write  = _write,   \
++}
++#endif
++
++#define VT_DEFINE_PROC_OPS_OPEN(storage, name)
\
++  VT_DEFINE_PROC_OPS(storage, name ## _proc_fops, NULL,   \
++ name ## _proc_open, NULL)
++
++#define VT_DEFINE_PROC_OPS_OPEN_WRITE(storage, name)  \
++  VT_DEFINE_PROC_OPS(storage, name ## _proc_fops, THIS_MODULE,\
++ name ## _proc_open, name ## _proc_write)
+ 
+ static int vt_int_proc_show(struct seq_file *m, void *v)
+ { //{{{
+@@ -225,12 +253,8 @@ static int vt_int_proc_open(struct inode
+   return single_open(file, vt_int_proc_show, PDE_DATA(inode));
+ }
+ 
+-const struct file_operations 

Bug#1025433: [Emc-developers] Bug#1025433: Copyright issue

[Adam Ant]

Source: linuxcnc
Severity serious
 
 

Sent: Thursday, December 08, 2022 at 1:36 AM
From: "andy pugh" 
To: "EMC developers" , "Adam Ant" 

Subject: Re: [Emc-developers] Bug#1025433: Copyright issue

  

On Thu, 8 Dec 2022 at 00:42, Adam Ant 
mailto:adam...@engineer.com]> wrote:

 

The correct course of action is to ask Paolo Mantegazza rather than debating 
symantics.
You can not just pull substantial chunks of code from one source and then claim 
that you wrote it.
 But Paulo didn't write it _either_ 
 
If you go back in time to 2003: 
https://github.com/LinuxCNC/linuxcnc/blob/07bc1e161f834d8b192fe279819261294e5fe150/src/rtapi/procfs_macros.h[https://github.com/LinuxCNC/linuxcnc/blob/07bc1e161f834d8b192fe279819261294e5fe150/src/rtapi/procfs_macros.h]
and compare that to a 1999 version of the RTAI file, the only line in common is 
"#include "
 
At some point _both_ files included a chunk of work from Erwin Rol:
 
// proc print macros - Contributed by: Erwin Rol 
(er...@muffin.org[mailto:er...@muffin.org])
 
_Most_ of both files was written by Erwin Rol. But both files existed 
previously, and separately, as far as I can tell looking back in both archives. 
 
 
Regardless of who wrote the original code, you can not take a file, hack it a 
little and then claim sole copyright yourself.
It brings the Debian project in to disrepute if they host the package.

Bug#1011494: FTBFS: compat level 6 unsupported

[Bastian Germann]

Fix via NMU with debdiff attached.diff -Nru atitvout-0.4/debian/changelog atitvout-0.4/debian/changelog
--- atitvout-0.4/debian/changelog   2022-12-10 00:20:02.0 +0100
+++ atitvout-0.4/debian/changelog   2022-12-10 00:12:44.0 +0100
@@ -1,3 +1,12 @@
+atitvout (0.4-13.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to 3.0 source format. (Closes: #1007322)
+  * Drop non-existing Vcs fields.
+  * Update debhelper compat level to 7. (Closes: #1011494)
+
+ -- Bastian Germann   Sat, 10 Dec 2022 00:12:44 +0100
+
 atitvout (0.4-13.1) unstable; urgency=medium
 
   * Non-maintainer upload.
@@ -13,7 +22,7 @@
   * Bump Standards-Version up to 3.8.1 
 
  -- Philippe Coval   Sun, 24 May 2009 22:15:54 +0200
-   
+
 atitvout (0.4-12ubuntu1) intrepid; urgency=low
 
   * lrmi-0.6/lrmi.c:
diff -Nru atitvout-0.4/debian/compat atitvout-0.4/debian/compat
--- atitvout-0.4/debian/compat  2022-12-10 00:20:02.0 +0100
+++ atitvout-0.4/debian/compat  2022-12-10 00:12:44.0 +0100
@@ -1 +1 @@
-6
+7
diff -Nru atitvout-0.4/debian/control atitvout-0.4/debian/control
--- atitvout-0.4/debian/control 2022-12-10 00:20:02.0 +0100
+++ atitvout-0.4/debian/control 2022-12-10 00:11:42.0 +0100
@@ -2,11 +2,9 @@
 Section: misc
 Priority: optional
 Maintainer: Philippe Coval 
-Build-Depends: debhelper (>= 6), quilt, libx86-dev
+Build-Depends: debhelper (>= 7), libx86-dev
 Standards-Version: 3.8.1
 Homepage: http://0pointer.de/lennart/projects/atitvout/
-Vcs-Svn: svn://svn.debian.org/svn/collab-maint/deb-maint/atitvout/
-Vcs-Browser: http://svn.debian.org/wsvn/collab-maint/deb-maint/atitvout/
 
 Package: atitvout
 Architecture: i386 ia64
diff -Nru atitvout-0.4/debian/rules atitvout-0.4/debian/rules
--- atitvout-0.4/debian/rules   2022-12-10 00:20:02.0 +0100
+++ atitvout-0.4/debian/rules   2022-12-10 00:12:21.0 +0100
@@ -15,10 +15,8 @@
INSTALL_PROGRAM += -s
 endif
 
-include /usr/share/quilt/quilt.make
-
 configure: configure-stamp
-configure-stamp: patch
+configure-stamp:
dh_testdir
# Add here commands to configure the package.
 
@@ -40,7 +38,7 @@
 
touch build-stamp
 
-clean: unpatch
+clean:
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
diff -Nru atitvout-0.4/debian/source/format atitvout-0.4/debian/source/format
--- atitvout-0.4/debian/source/format   1970-01-01 01:00:00.0 +0100
+++ atitvout-0.4/debian/source/format   2022-12-10 00:12:37.0 +0100
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#876191: most: configure cannot be built from source

[Jakub Wilk]

Control: tags -1 + fixed-upstream

* Helmut Grohne , 2017-09-19 14:27:

I was trying to fix a bug in most that requires modifying configure.
Thus I tried to regenerate it and ... failed.

It seems that configure was generated with autoconf2.61.


The latest upstream release (v5.2.0) uses Autoconf 2.69.

--
Jakub Wilk

Bug#1004869: python-xarray: autopkgtest regression on i386

[Adrian Bunk]

On Fri, Dec 09, 2022 at 10:22:36AM +, Graham Inggs wrote:
> Control: reopen -1
> 
> The tests on i386 [1] still fail.
> 
> There have been a couple of attempts at closing this bug, perhaps the
> i386 porters can help?
>...

This seems to be a marginal difference in one test out of many,
likely caused by the excess precision of the x87.

The patch below to XFAIL this one test works for me.

cu
Adrian

--- xarray/tests/test_interp.py.old 2022-12-09 22:44:17.418627920 +
+++ xarray/tests/test_interp.py 2022-12-09 22:45:08.170599489 +
@@ -854,6 +854,7 @@
 @requires_dask
 @pytest.mark.parametrize("method", ["linear", "nearest"])
 @pytest.mark.filterwarnings("ignore:Increasing number of chunks")
+@pytest.mark.xfail
 def test_interpolate_chunk_advanced(method: InterpOptions) -> None:
 """Interpolate nd array with an nd indexer sharing coordinates."""
 # Create original array

Bug#1025169: python3-numpy: again, why force users to install two versions of Python

[Joachim Wuttke]

Dear Sandro:

>> Why does python3-numpy under bookworm, since a few days,
>> depend on python3.10 *and* on python3.11?
>
> because it provides compiled extensions for both 3.10. and 3.11.

Sorry, I don't get the logic.
To make good use of this package, we need either 3.10 *or* 3.11.
Why then force us to install 3.10 *and* 3.11?


> Please search older report similar to this one for more information.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945824
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025169
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003805

Conclusion:
- Many users see a severe issue here.
- You are firmly determined to keep python3-numpy dependent on
  several python versions. But why?
- You would only accept a patch if it "works in every single situation".
  This amounts to saying "never". Hardly any package is free of bugs.
  Please take note that the current situation is very remote from
  working in every single situation. Any decision should be based
  on fairly weighed pro and cons.


For the benefit of those who see this discussion while searching
for a solution that just works for them:

Currently the simplest solution is to deinstall python3-numpy,
then reinstall numpy (and matplotlib and other packages that
depend on numpy) using pip3.


Cheers, Joachim

Bug#1017435: debian-installer: georgian text mode fails to render all characters

[Holger Wansing]

Hi,

Holger Wansing  wrote (Tue, 16 Aug 2022 22:59:34 +0200):
> 
> Philip Hands  wrote (Tue, 16 Aug 2022 11:22:30 +0200):
> > openQA just noticed that the rendering of certain characters just changed,
> > highlighting the fact that the rendering was already broken.
> 
> 
> To be more precise here:
> - this only affects the text installer; rendering in graphical installer 
> seems fine;
> - Georgian started to be available for the text installer in debian 10, and 
> some
>   research showed, that this issue is there from that beginning (debian 10).
> 
> Since noone noticed this for years, maybe we can go with a workaround to
> disable Georgian for the text installer (if noone finds the real solution
> for this).

As a workaround, I have now disabled Georgian in the text installer for now:
https://salsa.debian.org/installer-team/localechooser/-/commit/6391b845540667d649a5ee118410867f11b0ce81


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1007558: cbmplugs: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a LowNMU to convert this package. debdiff attached.diff -Nru cbmplugs-1.2.2/cbmplugs.h cbmplugs-1.2.2/cbmplugs.h
--- cbmplugs-1.2.2/cbmplugs.h   2022-12-09 23:26:50.0 +0100
+++ cbmplugs-1.2.2/cbmplugs.h   2009-12-01 16:15:33.0 +0100
@@ -33,7 +33,7 @@
GimpParam **return_vals)
 #endif
 
-typedef enum {
+enum {
KOALA = 0x0,
ADVOCP,
OCP,
diff -Nru cbmplugs-1.2.2/debian/changelog cbmplugs-1.2.2/debian/changelog
--- cbmplugs-1.2.2/debian/changelog 2022-12-09 23:26:50.0 +0100
+++ cbmplugs-1.2.2/debian/changelog 2022-12-09 23:23:25.0 +0100
@@ -1,3 +1,10 @@
+cbmplugs (1.2.2-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to 3.0 source format. (Closes: #1007558)
+
+ -- Bastian Germann   Fri, 09 Dec 2022 23:23:25 +0100
+
 cbmplugs (1.2.2-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cbmplugs-1.2.2/debian/patches/cbmplugs.h.patch 
cbmplugs-1.2.2/debian/patches/cbmplugs.h.patch
--- cbmplugs-1.2.2/debian/patches/cbmplugs.h.patch  1970-01-01 
01:00:00.0 +0100
+++ cbmplugs-1.2.2/debian/patches/cbmplugs.h.patch  2022-12-09 
23:23:25.0 +0100
@@ -0,0 +1,13 @@
+Description: Add typedef definition
+---
+--- cbmplugs-1.2.2.orig/cbmplugs.h
 cbmplugs-1.2.2/cbmplugs.h
+@@ -33,7 +33,7 @@
+   GimpParam **return_vals)
+ #endif
+ 
+-enum {
++typedef enum {
+   KOALA = 0x0,
+   ADVOCP,
+   OCP,
diff -Nru cbmplugs-1.2.2/debian/patches/series 
cbmplugs-1.2.2/debian/patches/series
--- cbmplugs-1.2.2/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ cbmplugs-1.2.2/debian/patches/series2022-12-09 23:23:25.0 
+0100
@@ -0,0 +1 @@
+cbmplugs.h.patch
diff -Nru cbmplugs-1.2.2/debian/source/format 
cbmplugs-1.2.2/debian/source/format
--- cbmplugs-1.2.2/debian/source/format 1970-01-01 01:00:00.0 +0100
+++ cbmplugs-1.2.2/debian/source/format 2022-12-09 23:23:14.0 +0100
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#1021562: pahole: Update for building Linux kernel with newer toolchains

[Salvatore Bonaccorso]

Hi Domenico,

On Tue, Oct 11, 2022 at 01:41:23PM +0200, Domenico Andreoli wrote:
> On Mon, Oct 10, 2022 at 08:51:48PM +0200, Jan-Benedict Glaw wrote:
> > Package: pahole
> > Distribution: sid
> > 
> > Hi!
> 
> Hi Jan-Benedict!
> 
> >
> > [...]
> > 
> > I think that's caused wrt. this thread:
> > https://www.spinics.net/lists/dwarves/msg01719.html, it would be nice
> > to have this fixed in Debian's `pahole`.
> 
> Agreed, it's time for a new upload. I'll try to prepare it in the coming days.

Did you found time to work on a update including the required changes
for pahole? 

https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=bcc648a10cbcd0b96b84ff7c737d56ce70f7b501

The last uploads for src:linux FTBFS on arm64 for both 6.0.12-1 and
6.1~rc8-1~exp1, with

https://buildd.debian.org/status/fetch.php?pkg=linux=arm64=6.0.12-1=1670586537=0
https://buildd.debian.org/status/fetch.php?pkg=linux=arm64=6.1%7Erc8-1%7Eexp1=1670583119=0

Regards,
Salvatore

Bug#1007544: amoeba-data: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/3. debdiff attached.diff -Nru amoeba-data-1.1/debian/changelog amoeba-data-1.1/debian/changelog
--- amoeba-data-1.1/debian/changelog2022-12-09 23:19:59.0 +0100
+++ amoeba-data-1.1/debian/changelog2022-12-09 23:15:44.0 +0100
@@ -1,3 +1,10 @@
+amoeba-data (1.1-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to 3.0 source format. (Closes: #1007544)
+
+ -- Bastian Germann   Fri, 09 Dec 2022 23:15:44 +0100
+
 amoeba-data (1.1-7) unstable; urgency=medium
 
   * Add empty build-arch and build-indep targets. (Closes: #999229)
diff -Nru amoeba-data-1.1/debian/patches/Makefile.patch 
amoeba-data-1.1/debian/patches/Makefile.patch
--- amoeba-data-1.1/debian/patches/Makefile.patch   1970-01-01 
01:00:00.0 +0100
+++ amoeba-data-1.1/debian/patches/Makefile.patch   2022-12-09 
23:15:44.0 +0100
@@ -0,0 +1,10 @@
+Description: Add Makefile
+---
+--- /dev/null
 amoeba-data-1.1/Makefile
+@@ -0,0 +1,5 @@
++clean:
++all:
++
++install:
++  install -m 0644 demo.dat $(DESTDIR)/usr/share/amoeba
diff -Nru amoeba-data-1.1/debian/patches/series 
amoeba-data-1.1/debian/patches/series
--- amoeba-data-1.1/debian/patches/series   1970-01-01 01:00:00.0 
+0100
+++ amoeba-data-1.1/debian/patches/series   2022-12-09 23:15:44.0 
+0100
@@ -0,0 +1 @@
+Makefile.patch
diff -Nru amoeba-data-1.1/debian/source/format 
amoeba-data-1.1/debian/source/format
--- amoeba-data-1.1/debian/source/format1970-01-01 01:00:00.0 
+0100
+++ amoeba-data-1.1/debian/source/format2022-12-09 23:15:30.0 
+0100
@@ -0,0 +1 @@
+3.0 (quilt)
diff -Nru amoeba-data-1.1/Makefile amoeba-data-1.1/Makefile
--- amoeba-data-1.1/Makefile2022-12-09 23:19:59.0 +0100
+++ amoeba-data-1.1/Makefile1970-01-01 01:00:00.0 +0100
@@ -1,5 +0,0 @@
-clean:
-all:
-
-install:
-   install -m 0644 demo.dat $(DESTDIR)/usr/share/amoeba

Bug#1025821: rust-capnp: CVE-2022-46149

[Salvatore Bonaccorso]

Source: rust-capnp
Version: 0.14.7-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rust-capnp.

CVE-2022-46149[0]:
| Cap'n Proto is a data interchange format and remote procedure call
| (RPC) system. Cap'n Proro prior to versions 0.7.1, 0.8.1, 0.9.2, and
| 0.10.3, as well as versions of Cap'n Proto's Rust implementation prior
| to 0.13.7, 0.14.11, and 0.15.2 are vulnerable to out-of-bounds read
| due to logic error handling list-of-list. This issue may lead someone
| to remotely segfault a peer by sending it a malicious message, if the
| victim performs certain actions on a list-of-pointer type.
| Exfiltration of memory is possible if the victim performs additional
| certain actions on a list-of-pointer type. To be vulnerable, an
| application must perform a specific sequence of actions, described in
| the GitHub Security Advisory. The bug is present in inlined code,
| therefore the fix will require rebuilding dependent applications.
| Cap'n Proto has C++ fixes available in versions 0.7.1, 0.8.1, 0.9.2,
| and 0.10.3. The `capnp` Rust crate has fixes available in versions
| 0.13.7, 0.14.11, and 0.15.2.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-46149
https://www.cve.org/CVERecord?id=CVE-2022-46149
[1] 
https://github.com/capnproto/capnproto/security/advisories/GHSA-qqff-4vw4-f6hx
[2] https://rustsec.org/advisories/RUSTSEC-2022-0068.html

Regards,
Salvatore

Bug#1025791: fsck.f2fs is unable to check mounted FS

[Theodore Ts'o]

On Fri, Dec 09, 2022 at 11:16:46AM +0300, Michael Tokarev wrote:
> Package: f2fs-tools
> Version: 1.14.0-2
> Severity: important
> 
> When running an fsck.f2fs on a readonly-mounted filesystem (root filesystem
> for example, which obviously can not be unmounted), fsck.f2fs always fails:
> 
> I don't know if this is a kernel issue (who explicitly prevents
> opening of a mounted block device) or f2fs-tools issue (who is
> not doing any special actions required to work around that), but
> the result is that the root filesystem is never checked for errors,
> and the boot process always complains about failed fsck.
> 
> Other filesystems (eg ext*fs) is able to check and repair a mounted
> (read-only) filesystem just fine.
> 
> This is why I think this bug is of Severity: important.  The only way
> to check f2fs root  filesystem for errors is to put fsck.f2fs into
> initramfs and go from there, or boot some rescue media.

Well, btrfs and xfs have /sbin/fsck.$FSTYP which is a no-op when it is
run with the -a option.  Whether or not this is a good idea is
something where I have my own opinions  but as the ext4
maintainer, I'm obviously biased.  :-)

The point is that there are many many other file systems supported by
Debian which never checks the root file system for errors --- even if
you use an initramfs.

The other thing I'll note is that f2fs-tools isn't getting much love
in Debian at the moment.  The original maintainer/uploader was Vincent
Cheng, and I joined the Filesystem Group to help out mainly because I
wnated to get an updated f2fs-tools for kernel testing[1].  I don't
actually use f2fs except for kernel testing, so I wouldn't want to be
making changes to f2fs-tools or its support scripts, since I might not
notice any potential problems.

[1] https://thunk.org/gce-xfstests

So if you or other folks would be interested in helping with
f2fs-tools, especially if you are actually interested in using f2fs as
a root file system, please consider joining the file system group and
helping out.  There is new version of f2fs-tools that hasn't been
packaged yet and I'm not sure when I will have the time

   - Ted

Bug#1025537: nfsd: Kernel Oops while serving NFS

[Salvatore Bonaccorso]

Hi Olivier,

On Tue, Dec 06, 2022 at 10:54:31PM +1100, Olivier Mehani wrote:
> Package: src:linux
> Version: 6.0.10-1
> Severity: important
> File: nfsd
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> On testing/bookworm, since booting on a 6-versioned linux-image, I have 
> noticed frequent hang ups of the nfs server, rendering it mostly 
> unusable. This is accompanied with Kernel Oops in the dmesg.
> 
> This sounds similar to previous bugs #1014793 and #1020548, both RESOLVED by
> later patches.

How easy can you trigger and reproduce the issue? If you can easily
reach that situation, can you try to bisect the issue? Easiest would
be to first pin point between Debian revisions, and later further
bisect in upstream stable series.

Do you have the possibility to do that?

Regards,
Salvatore

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

That’s really cool.  Thank you for doing that.

On Friday, December 9, 2022 11:09:00 AM MST Agustin Martin wrote:
> By the way, I have been playing with an old helper
> (installdeb-myspell) shipped with dictionaries-common-dev to help with
> these bdic files. First cut committed to salsa. Currently
> installdeb-myspell will fail if no conversion tool is found.


-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1025820: Bug: grub-pc 2.06-3~deb10u3 upgrade assumes /tmp is exec

[imschmeg]

Package: grub-pc
Version: 2.06-3~deb10u3

The error message during an "apt upgrade" that includes grub-pc is:

open2: exec of /tmp/grub-pc.config.ajRf2i configure 2.06-3~deb10u2
failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm
line 59. 

The problem is that apt upgrade assumes /tmp is mounted exec.  Common
security practice is to mount /tmp noexec, which I do.

Apt install scripts could instead be executed without being exec by
passing them as a parameter to the shell command.

Also, after the error, the apt upgrade finished instead of aborting,
leaving my system in an unknown state.  I had to remount /tmp with exec
and reinstall the grub packages.

My system is:
$ uname -a
Linux lapdog 5.10.0-15mx-amd64 #1 SMP Debian 5.10.120-1~mx19+1
(2022-06-13) x86_64 GNU/Linux

Bug#1025819: util-linux: Move isosize out of /usr/sbin

[Kevin Thibedeau]

Package: util-linux
Version: 2.36.1-8+deb11u1
Severity: wishlist

Dear Maintainer,


The isosize program is currently in /usr/sbin and requires root 
permission to
run. This program should be safe for regular users to use and can be 
moved to
/usr/bin. Moreover, the genisoimage package provides the isoinfo program 
which
performs the same access to optical drives without needing root. The 
latter has
more verbose output and isosize is more suitable for scripting that just 
needs to

get a filesystem size.


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

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

Versions of packages util-linux depends on:
ii libaudit1 1:3.0-2
ii libblkid1 2.36.1-8+deb11u1
ii libc6 2.31-13+deb11u5
ii libcap-ng0 0.7.9-2.2+b1
ii libcrypt1 1:4.4.18-4
ii libmount1 2.36.1-8+deb11u1
ii libpam0g 1.4.0-9+deb11u1
ii libselinux1 3.1-3
ii libsmartcols1 2.36.1-8+deb11u1
ii libsystemd0 247.3-7+deb11u1
ii libtinfo6 6.2+20201114-2
ii libudev1 247.3-7+deb11u1
ii libuuid1 2.36.1-8+deb11u1
ii login 1:4.8.1-1
ii zlib1g 1:1.2.11.dfsg-2+deb11u2

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii dosfstools 4.2-1
ii kbd 2.3.0-3
ii util-linux-locales 2.36.1-8+deb11u1

Bug#1025818: curl: Command line option -O no longer works as expected

[Stefan Weil]

Package: curl
Version: 7.86.0-2
Severity: normal
X-Debbugs-Cc: s...@weilnetz.de

It looks like there is a regression for curl in bookworm:

The following command no longer works as expected (bullseye was fine):

curl -O -L 
"https://search.maven.org/remotecontent?filepath=org/piccolo2d/piccolo2d-extras/3.0.1/piccolo2d-extras-3.0.1.jar;

Instead of storing the downloaded file as "piccolo2d-extras-3.0.1.jar",
it creates a file named "remotecontent".

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

Kernel: Linux 6.0.0-5-amd64 (SMP w/6 CPU threads; PREEMPT)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages curl depends on:
ii  libc6 2.36-6
ii  libcurl4  7.86.0-2
ii  zlib1g1:1.2.11.dfsg-4.1

curl recommends no packages.

curl suggests no packages.

Bug#1025817: RM: sdic -- RoQA; RC-buggy, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove sdic. It's RC-buggy and dropped from testing since 2017.

Cheers,
Moritz

Bug#1025816: libde265: CVE-2022-43243 CVE-2022-43248 CVE-2022-43253

[Moritz Mühlenhoff]

Source: libde265
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for libde265.

CVE-2022-43243[0]:
| Libde265 v1.0.8 was discovered to contain a heap-buffer-overflow
| vulnerability via ff_hevc_put_weighted_pred_avg_8_sse in sse-
| motion.cc. This vulnerability allows attackers to cause a Denial of
| Service (DoS) via a crafted video file.

https://github.com/strukturag/libde265/issues/339

CVE-2022-43248[1]:
| Libde265 v1.0.8 was discovered to contain a heap-buffer-overflow
| vulnerability via put_weighted_pred_avg_16_fallback in fallback-
| motion.cc. This vulnerability allows attackers to cause a Denial of
| Service (DoS) via a crafted video file.

https://github.com/strukturag/libde265/issues/349

CVE-2022-43253[2]:
| Libde265 v1.0.8 was discovered to contain a heap-buffer-overflow
| vulnerability via put_unweighted_pred_16_fallback in fallback-
| motion.cc. This vulnerability allows attackers to cause a Denial of
| Service (DoS) via a crafted video file.

https://github.com/strukturag/libde265/issues/348


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-43243
https://www.cve.org/CVERecord?id=CVE-2022-43243
[1] https://security-tracker.debian.org/tracker/CVE-2022-43248
https://www.cve.org/CVERecord?id=CVE-2022-43248
[2] https://security-tracker.debian.org/tracker/CVE-2022-43253
https://www.cve.org/CVERecord?id=CVE-2022-43253

Please adjust the affected versions in the BTS as needed.

Bug#1025773: evolution-data-server 3.38.3-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025773 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: evolution-data-server
Version: 3.38.3-1+deb11u1

Explanation: move Google Contacts addressbooks to CalDAV since the Google 
Contacts API has been turned off

Bug#1025809: evolution-data-server 3.38.3-1+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025809 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: evolution-data-server
Version: 3.38.3-1+deb11u2

Explanation: fix compatibility with Gmail OAuth changes

Bug#1025774: evolution 3.38.3-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025774 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: evolution
Version: 3.38.3-1+deb11u1

Explanation: move Google Contacts addressbooks to CalDAV since the Google 
Contacts API has been turned off

Bug#1025766: golang-github-go-chef-chef 0.0.1+git20161023.60.deb8c38-1.2~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025766 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: golang-github-go-chef-chef
Version: 0.0.1+git20161023.60.deb8c38-1.2~deb11u1

Explanation: fix intermittent test failure

Bug#1025764: isoquery 3.2.4-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025764 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: isoquery
Version: 3.2.4-1+deb11u1

Explanation: fix test failure caused by French translation change in the 
iso-codes package

Bug#1025758: efitools 1.9.2-2~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025758 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: efitools
Version: 1.9.2-2~deb11u1

Explanation: fix intermittent build failure due to incorrect dependency in 
makefile

Bug#1025755: dovecot-fts-xapian 1.4.9a-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025755 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: dovecot-fts-xapian
Version: 1.4.9a-1+deb11u1

Explanation: generate dependency on dovecot ABI in use during build

Bug#1025716: mutt 2.0.5-4.1+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025716 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: mutt
Version: 2.0.5-4.1+deb11u2

Explanation: fix gpgme crash when listing keys in a public key block, and 
public key block listing for old versions of gpgme

Bug#1025754: containerd 1.4.13~ds1-1~deb11u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025754 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: containerd
Version: 1.4.13~ds1-1~deb11u3

Explanation: CRI plugin: Fix goroutine leak during Exec [CVE-2022-23471]

Bug#1025710: awstats 7.8-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025710 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: awstats
Version: 7.8-2+deb11u1

Explanation: fix cross site scripting issue [CVE-2022-46391]

Bug#1025601: leptonlib 1.79.0-1.1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025601 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: leptonlib
Version: 1.79.0-1.1+deb11u1

Explanation: fix divide-by-zero [CVE-2022-38266]

Bug#1025323: nano 5.4-2+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025323 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: nano
Version: 5.4-2+deb11u2

Explanation: fix crashes and a potential data loss issue

Bug#1025205: mplayer 1.4+ds1-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025205 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: mplayer
Version: 1.4+ds1-1+deb11u1

Explanation: fix several security issues [CVE-2022-38850 CVE-2022-38851 
CVE-2022-38855 CVE-2022-38858 CVE-2022-38860 CVE-2022-38861 CVE-2022-38863 
CVE-2022-38864 CVE-2022-38865 CVE-2022-38866]

Bug#1025137: g810-led 0.4.2-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025137 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: g810-led
Version: 0.4.2-1+deb11u1

Explanation: control device access with uaccess instead of making everything 
world-writable [CVE-2022-46338]

Bug#1025389:

[Martin]

Removing the Intel config in

/etc/X11/xorg.conf.d/*.conf

made my laptop boot again.

Bug#1025205: bullseye-pu: package mplayer/2:1.4+ds1-1+deb11u1

[Moritz Mühlenhoff]

Am Wed, Dec 07, 2022 at 08:31:06PM + schrieb Adam D. Barratt:
> Control: tags -1 + confirmed
> 
> On Wed, 2022-11-30 at 22:42 +0100, Moritz Muehlenhoff wrote:
> > This updates fixes various minor crashes in mplayer, which
> > don't warrant a DSA by itself. I've run the PoCs against
> > the updated build where applicable and also tested various
> > random media files.
> > 
> > Note this isn't fixed in unstable, since mplayer FTBFSes
> > with ffmpeg 5.0 and won't be in bookworm (#1005899).
> > 
> 
> Please go ahead.

Thanks! Upload.

Cheers,
Moritz

Bug#1025700: virglrenderer 0.8.2-5+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025700 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: virglrenderer
Version: 0.8.2-5+deb11u1

Explanation: fix out-of-bounds write issue [CVE-2022-0135]

Bug#1024850: spf-engine 2.9.2-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1024850 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: spf-engine
Version: 2.9.2-1+deb11u1

Explanation: fix pyspf-milter failing to start due to an invalid import 
statement

Bug#1017723: nftables 0.9.8-3.1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1017723 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: nftables
Version: 0.9.8-3.1+deb11u1

Explanation: fix off-by-one / double free error

Bug#1025083: omnievents 2.6.2-5.1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025083 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: omnievents
Version: 2.6.2-5.1+deb11u1

Explanation: add missing dependency on libjs-jquery to the omnievents-doc 
package

Bug#1025815: maintainerscripts choke on debconf-set-selection set input

[Marc Haber]

Package: slapd
Version: 2.5.13+dfsg-2
Severity: minor

Hi,

the autopkgtests for sudo use debconf-set-selections to preconfigure
slapd to test sudo-ldap. The input file was taken from
debconf-get-selections output and contained extra whitspace before "when
needed":

slapd   slapd/dump_database select when needed
(fixed version)

Since a few months, openldap's maintainer scripts choke on that in the
case construct that has "when needed" in one of the cases. Those scripts
fall through to the *) clause, erroring out.

Using a construct like

RET="$(echo $RET | sed 's/^[[:space:]]\+//')"

before the case fixes the issues for me, but I am not sure whether this
is an acceptable fix for the package.

Nevetheless, openldap should be able to reconfigure itself after the
Debconf database is preseeded with a string that came out of
debconf-get-selections.

If this is a debconf issue, please reassign appropriately.

In sudo, I fixed this by removing extra whitespace from the file

Greetings
Marc

Bug#1025775: libsdl2 breaks cataclysm-dda autopkgtest in lxc: only bottom left corner appears in screenshot

[Simon McVittie]

Control: reassign -1 src:cataclysm-dda 0.F-3-8
Control: tags -1 + patch

On Fri, 09 Dec 2022 at 17:58:38 +, Simon McVittie wrote:
> With SDL 2.26, it seems that under some circumstances (lxc but not qemu
> or podman, for some reason), the window won't become fullscreen without
> a window manager being present.

Bisecting SDL reveals that this was triggered by an intentional change,
.

Before that commit, SDL would set the window dimensions to the screen
size and also set the "please fullscreen" flag. However, this meant that
un-fullscreening a window would result in it still being screen-sized.

Since that commit, SDL sets the window dimensions to its non-fullscreen
size but sets the "please fullscreen" flag. A compatible window manager
will ignore the window dimensions and display the game full-screen, but
when the window leaves fullscreen, the window manager will use the
windowed dimensions automatically.

Assuming that full-screen will work as intended without a window manager
seems like a bug in cataclysm-dda's autopkgtest rather than a sign of
missing functionality in SDL, so I'm reassigning this to cataclysm-dda.
Please consider the attached patch, also available from

(git fetch https://salsa.debian.org/smcv/cataclysm-dda-branches autopkgtest-wm).

You might also find the changes in

useful for debugging and/or test robustness
(git fetch https://salsa.debian.org/smcv/cataclysm-dda-branches 
autopkgtest-misc).

smcv
>From c64b43ab617b4125917c8badc84530cad62aa50a Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Fri, 9 Dec 2022 14:03:03 +
Subject: [PATCH] d/tests/test-tiles: Run a window manager inside Xvfb

Previously, this test relied on SDL setting the window dimensions to the
full size of the screen, so that even when running in an Xvfb
environment without a window manager, it will occupy the whole screen
area and have the contents we are looking for.

However, since commit ,
SDL instead sets the window dimensions to its non-windowed size, relying
on the window manager to obey the "please make this fullscreen" flag and
ignore those dimensions. This was done to fix a bug: without that
information, when the window becomes non-fullscreen, the window manager
cannot know how large it should become.

Games are generally designed to run under a window manager, so running
without a window manager is not a realistic test. Adding a simple window
manager (openbox) makes this test more realistic, and also ensures that
the "draw as fullscreen" flag is respected.

Signed-off-by: Simon McVittie 
Closes: #1025775
---
 debian/tests/control| 2 +-
 debian/tests/test-tiles | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/tests/control b/debian/tests/control
index f066122e..67ee6cf1 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -4,4 +4,4 @@ Depends: cataclysm-dda-curses, expect, locales-all
 
 Test-Command: timeout -v 5m xvfb-run debian/tests/test-tiles
 Restrictions: allow-stderr, superficial
-Depends: cataclysm-dda-sdl, xvfb, xauth, xdotool, scrot, tesseract-ocr, locales-all, pulseaudio
+Depends: cataclysm-dda-sdl, openbox, xvfb, xauth, xdotool, scrot, tesseract-ocr, locales-all, pulseaudio
diff --git a/debian/tests/test-tiles b/debian/tests/test-tiles
index 566dcb60..db4ed9c8 100755
--- a/debian/tests/test-tiles
+++ b/debian/tests/test-tiles
@@ -13,7 +13,8 @@ export LANG=en_US.UTF-8
 # cdda needs audio or it won't start (#59464)
 pulseaudio --start
 
-# start cdda and wait a bit
+# start cdda and a window manager, and wait a bit
+openbox &
 cataclysm-tiles &
 PID=$!
 sleep 15
-- 
2.38.1

Bug#1025813: release.debian.org: Help grass & libgdal-grass migrate to testing

[Bas Couwenberg]

Package: release.debian.org
Severity: normal

With the migration of fftw3 testing migration of grass & libgdal-grass is still 
blocked by the autopkgtest failure of the latter.

I've scheduled several jobs to use both grass & libgdal-grass from unstable to 
make the autopkgtest succeed, but britney ignores these successfull jobs.

grass (8.2.0-3) has a patch to use the upstream version instead of the build 
timestamp for the version check and the libgdal-grass (1:1.0.2-3) was rebuilt 
for this and the documentation in README.source was updated accordingly.

See also prior discussion during the gdal transition: #1023846.

Kind Regards,

Bas

Bug#1025075: faraday-typhoeus adapter to support faraday 2.0

[Vinay]

Since this is an upstream issue we need to wait until typhoeus updates 
to faraday 2.0


https://github.com/typhoeus/typhoeus/issues/686

faraday-typhoeus 2 adapter for typhoeus -> 
https://github.com/dleavitt/faraday-typhoeus

Bug#1023360: singular-doc: info file in /usr/share/doc

[Jerome BENOIT]

Hello Jakub, thanks for your report.
The issue has been already fixed in the current experiemental.
I am on my way to upload it to unstable.
Cheers,
Jerome
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020380: singular-modules: Files p_Procs_Field${x}.so, for x in General Indep Q Zp, are now symlinks to p_Procs_Field${x}.so.0.0.0 , however, those are missing

[Jerome BENOIT]

Hello Jan, thanks for your report.
I could reproduce the issue and, more importantly,
I isolated it. I am on my way to fix it.
Cheers,
Jerome
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B


OpenPGP_signature
Description: OpenPGP digital signature

Bug#642906: RFH: balsa -- An e-mail client for GNOME

[Jeremy Bicha]

Daniel,

Do you still use balsa? If so, do you think we can close this RFH bug?

The biggest thing we were missing was someone who uses the app to
confirm it's still working and able to make occasional fixes (which
you can since you're a team maintainer for it).

Thank you,
Jeremy Bicha

Bug#1024389: python3-ledger: sefault during garbage collection

[Bernhard Übelacker]

Dear Maintainer,
this SIGSEGV and also the valgrind "invalid read"
below ledger::journal_t::clear_xdata can also be
seen in a Debian 11 Bullseye VM.

Because valgrind points already to a use-after-free,
and the output "Done." is printed,
might the issue here be, that python does destruct the
"session" variable before the "journal" while it is
still kind of connected at C++ side?
And therefore maybe an upstream issue?

Kind regards,
Bernhard

Bug#993290: please provide bridge-utils- compatible /etc/network/if-up-d/ script for ifupdown

[Andreas Henriksson]

Hello Michail Tokarev,

Late followup, but here's my personal opinion for the sake of having a
discussion which you asked for.
(JFTR I'm not maintaining this package and my opinion might have 0 value
on this topic.)

On Mon, Aug 30, 2021 at 12:23:09PM +0300, Michael Tokarev wrote:
> Source: iproute2
> Severity: normal
> 
> iproute2 package contains bridge control utility for a long time
> (maybe since the beginning). It is superior to brctl utility which
> is traditionally used to setup bridges on linux.
> 
> It is more: these days, bridges are often used with virtual machines,
> and there, iproute's bridge is *significantly* better when used
> together with vlan tagging, since bridge code in linux can deal with
> per-port vlan settings internally and hence we only require single
> bridge with everything, compared with a bridge for each vlan as with
> bridge-utils.

The iproute2 collection is generally where to look for utilities
that use modern kernel interfaces for networking, rather than old
tools using old/obsolete ioctl interfaces that exists for backwards
compatibility (and often can not represent the real running configuration).

> 
> By providing bridge functionality in the iproute package we'll eliminate
> bridge-utils dependency altogether.
> 
> And since ip utility can deal with vlans too, while at it we can absorb
> vlan package functionality too.

I think vlan package is a good example. The content of the package got
replaced by a script that simply gives existing users a migration path
*without* adding legacy burden on iproute2!

And speaking as a former iproute2 package maintainer and uploader of
vlan 2.0, the last part was equally important to me! :)

I think bridge-utils should follow the same path as vlan:
By having a new version that provides an upgrade path for existing
users without burdening others who never installed the legacy tools
with legacy migration cruft.

> 
> It is interesting that so far this hasn't been done. We switched to
> iproute-based bridging several years ago and it was a real game-change
> for us.
> 
> I have a script to set up bridges using ip utility (including per-port
> vlan settings), which looks like this in network/interfaces
> (a bit modified real example):
> 
> --- cut ---
> # this is the bridge interface:
> auto brf
> iface brf inet manual
>  bridge-vids 3 5 8 9 14
>  bridge-ports tls-eth
>  bridge-fd 5
>  bridge-maxwait 0
> 
> # this is the physical interface which is part of the bridge
> auto tls-eth
> iface tls-eth inet manual
>  # the same as for brf but tag14 is internal to the host
>  bridge-vids 3 5 8 9
> 
> # this is actual host's interface in vlan 1
> auto tls-mother
> iface tls-mother inet static
>  vlan 3@brf
>  address 192.168.177.15/26
>  gateway 192.168.177.5
> 
> # other interfaces for virtual machines etc
> --- cut ---
> 
> The "vlan" works both in bridge mode and with regular interfaces.
> 
> But I'd love to have some discussion about how the setup should look like
> before sending the actual script.

If my previous comments wheren't already spicy enough, here's a hot
take: I consider ifupdown itself to belong on the pile of legacy cruft.

> 
> Also I'm a bit unsure - if this functionality is to be merged into
> /etc/network/if-pre-up.d/iproute2, how can we disable the same
> functionality in if-pre-up.d/bridge-utils?

Additionally iproute2 is low-level tools, ifupdown uses it as an
implementation detail. Having iproute2 provide ifupdown glue just
creates a confusing circular relationship. If you want ifupdown to
use more of iproute2, then I say implement it in ifupdown!

> 
> Thanks!
> 
> /mjt
> 

Hope that my comments where not too spicy and hopefully some food for
though.

(If it wasn't already obvious: My suggestion is to tags +wontfix this
bug report on the iproute2 side.)

Regards,
Andreas Henriksson

Bug#1024652: ruby3.0: Segmentation fault from irb when performing a simple multiplication

[Gunnar Wolf]

Antonio Terceiro dijo [Wed, Dec 07, 2022 at 03:29:41PM -0300]:
> > > (And just to be on the safe side, maybe you could do a memory test
> > > to exclude a hardware failure.)
> > 
> > OK -- I cannot say I'll do a memtest right now, as this is a
> > productive machine, but will do it soon-ish ☺
> > 
> > I have the following in my .irbrc:
> > (...)
> My guess is that wirble is the culprit. How was it installed? What's the
> probability that it was built for a different Ruby interpreter?
> 
> (irb itself does colors nowadays so you should not need wirble.
> according to rubygems.org the last release was in 2009).

Right, Wirble makes no sense... And I don't have it installed; its
symbols are not installed in irb. It seems that irb silently fails
missing 'require' statements.

Bug#1025243: sudo: autopkgtest fails if glibc is upgraded in testbed (on s390x)

[Marc Haber]

On Thu, Dec 01, 2022 at 01:02:45PM +0100, Paul Gevers wrote:
> And right after hitting the send button I realized that my reasoning is at
> least partially flawed. The testbed will always update glibc, because the
> testbed is build from testing, and glibc hasn't migrated yet. Still, it's a
> weird pattern.

Is there still something that sudo can do here? I fixed an issue in the
ldap autopkgtest¹ recently, but your logs looks like the test gets
further than the place where this issue errors out.

Would more output in the test help? What is the canonical way to write a
test that can have its verbosity turned up for debugging, how is this
wish communicated to a system that runs the tests in an automated way?
Can a mere mortal DD run an autopkgtest on a porterbox?

Greetings
Marc

Bug#997580: libpicocontainer1-java: FTBFS in bullseye

[Santiago Vila]

reopen 997580
found 997580 1.3-2
fixed 997580 1.3-3
thanks

This is a FTBFS bug but it's still unfixed in stable.

Follows a proposal to fix it in stable. I believe it may be used "as 
is". I merely took the patch from debian/patches in 1.3-3 and applied it 
over the version in bullseye). I can confirm that the package builds 
again in stable after that.


Thanks.diff -Nru libpicocontainer1-java-1.3/debian/changelog 
libpicocontainer1-java-1.3/debian/changelog
--- libpicocontainer1-java-1.3/debian/changelog 2019-12-29 16:10:19.0 
+0100
+++ libpicocontainer1-java-1.3/debian/changelog 2022-12-09 19:05:00.0 
+0100
@@ -1,3 +1,11 @@
+libpicocontainer1-java (1.3-2+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Extend the xstream whitelist to prevent a ForbiddenClassException.
+(Closes: #997580)
+
+ -- Markus Koschany   Fri, 09 Dec 2022 19:05:00 +0100
+
 libpicocontainer1-java (1.3-2) unstable; urgency=medium
 
   * No change rebuild.
diff -Nru 
libpicocontainer1-java-1.3/debian/patches/extend-the-xstream-whitelist.patch 
libpicocontainer1-java-1.3/debian/patches/extend-the-xstream-whitelist.patch
--- 
libpicocontainer1-java-1.3/debian/patches/extend-the-xstream-whitelist.patch
1970-01-01 01:00:00.0 +0100
+++ 
libpicocontainer1-java-1.3/debian/patches/extend-the-xstream-whitelist.patch
2022-12-09 19:05:00.0 +0100
@@ -0,0 +1,85 @@
+From: Markus Koschany 
+Date: Sat, 13 Nov 2021 18:00:25 +0100
+Subject: extend the xstream whitelist
+
+Extend the xstream whitelist.
+
+Forwarded: not-needed
+---
+ .../org/picocontainer/defaults/XStreamSerialisationTestCase.java  | 5 -
+ .../org/picocontainer/doc/advanced/CollectionDemoClasses.java | 4 ++--
+ .../org/picocontainer/tck/AbstractComponentAdapterTestCase.java   | 8 +---
+ 3 files changed, 11 insertions(+), 6 deletions(-)
+
+--- 
a/container/src/test/org/picocontainer/defaults/XStreamSerialisationTestCase.java
 
b/container/src/test/org/picocontainer/defaults/XStreamSerialisationTestCase.java
+@@ -19,6 +19,7 @@
+ public void testShouldBeAbleToSerialiseEmptyPico() {
+ if (JVM.is14()) {
+ MutablePicoContainer pico = new DefaultPicoContainer();
++xStream.allowTypesByWildcard(new 
String[]{"org.picocontainer.**"});
+ String picoXml = xStream.toXML(pico);
+ PicoContainer serializedPico = (PicoContainer) 
xStream.fromXML(picoXml);
+ 
+@@ -31,6 +32,7 @@
+ MutablePicoContainer pico = new DefaultPicoContainer();
+ pico.registerComponentImplementation(SimpleTouchable.class);
+ pico.registerComponentImplementation(DependsOnTouchable.class);
++xStream.allowTypesByWildcard(new 
String[]{"org.picocontainer.**"});
+ String picoXml = xStream.toXML(pico);
+ PicoContainer serializedPico = (PicoContainer) 
xStream.fromXML(picoXml);
+ 
+@@ -44,10 +46,11 @@
+ pico.registerComponentImplementation(SimpleTouchable.class);
+ pico.registerComponentImplementation(DependsOnTouchable.class);
+ pico.getComponentInstances();
++xStream.allowTypesByWildcard(new 
String[]{"org.picocontainer.**"});
+ String picoXml = xStream.toXML(pico);
+ PicoContainer serializedPico = (PicoContainer) 
xStream.fromXML(picoXml);
+ 
+ assertEquals(2, serializedPico.getComponentInstances().size());
+ }
+ }
+-}
+\ No newline at end of file
++}
+--- 
a/container/src/test/org/picocontainer/doc/advanced/CollectionDemoClasses.java
 
b/container/src/test/org/picocontainer/doc/advanced/CollectionDemoClasses.java
+@@ -1,6 +1,6 @@
+ /*
+- * Copyright (C) 2004 Jörg Schaible
+- * Created on 24.10.2004 by Jörg Schaible
++ * Copyright (C) 2004 Joerg Schaible
++ * Created on 24.10.2004 by Joerg Schaible
+  */
+ package org.picocontainer.doc.advanced;
+ 
+--- 
a/container/src/test/org/picocontainer/tck/AbstractComponentAdapterTestCase.java
 
b/container/src/test/org/picocontainer/tck/AbstractComponentAdapterTestCase.java
+@@ -235,7 +235,8 @@
+ assertSame(getComponentAdapterType(), 
componentAdapter.getClass());
+ final Object instance = 
componentAdapter.getComponentInstance(picoContainer);
+ assertNotNull(instance);
+-final XStream xstream = new XStream(new 
PureJavaReflectionProvider(), new XppDriver());
++XStream xstream = new XStream(new PureJavaReflectionProvider(), 
new XppDriver());
++xstream.allowTypesByWildcard(new 
String[]{"org.picocontainer.**"});
+ final String xml = xstream.toXML(componentAdapter);
+ final ComponentAdapter serializedComponentAdapter = 
(ComponentAdapter)xstream.fromXML(xml);
+ assertEquals(componentAdapter.getComponentKey(), 
serializedComponentAdapter.getComponentKey());
+@@ -252,7 +253,8 @@
+ assertSame(getComponentAdapterType(), 
componentAdapter.getClass());
+ 

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Agustin Martin]

El mar, 6 dic 2022 a las 23:34, Agustin Martin
() escribió:
>
> El dom, 4 dic 2022 a las 4:54, Soren Stoutner () escribió:
> >
> > I created an MR:
> >
> > https://salsa.debian.org/debian/dictionaries-common/-/merge_requests/5
> >
> > Please review and make sure I haven’t missed anything or misrepresented the 
> > consensus.
>
> Merged.
>
> Will wait some days for possible new comments.

By the way, I have been playing with an old helper
(installdeb-myspell) shipped with dictionaries-common-dev to help with
these bdic files. First cut committed to salsa. Currently
installdeb-myspell will fail if no conversion tool is found.

Bug#955830: efax-gtk: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Ying-Chun Liu (PaulLiu)]

Hi all,

I plan to fix RC bugs #965505, #998956 by NMU this package.
The debdiff is as attachment.

My plan is I'll wait for 10 days to see if anyone complains in the bug 
report.

And then I'll upload to delay/10 queue.

The following changes are made:
  * Non-maintainer upload.
  * Bump debhelper version to 12. (Closes: #965505)
- Update debian/rules to use dh. (Closes: #998956)
- Remove Build-Depends on autotools-dev
  * Add debian/patches/0002-fix-format-security.patch
- Newer debhelper force format-security. Thus we need a patch.
  * Add debian/patches/0003-correct-gettext-version.patch
- Update gettext version.
  * Remove unnecessarily Build-Depends on deprecated libdbus-glib-1-dev
(Closes: #955830)


Yours,
Paul


diff -Nru efax-gtk-3.2.8/debian/changelog efax-gtk-3.2.8/debian/changelog
--- efax-gtk-3.2.8/debian/changelog 2021-02-06 22:21:12.0 +0800
+++ efax-gtk-3.2.8/debian/changelog 2022-12-09 23:39:09.0 +0800
@@ -1,3 +1,18 @@
+efax-gtk (3.2.8-2.3) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Bump debhelper version to 12. (Closes: #965505)
+- Update debian/rules to use dh. (Closes: #998956)
+- Remove Build-Depends on autotools-dev
+  * Add debian/patches/0002-fix-format-security.patch
+- Newer debhelper force format-security. Thus we need a patch.
+  * Add debian/patches/0003-correct-gettext-version.patch
+- Update gettext version.
+  * Remove unnecessarily Build-Depends on deprecated libdbus-glib-1-dev
+(Closes: #955830)
+
+ -- Ying-Chun Liu (PaulLiu)   Fri, 09 Dec 2022 23:39:09 
+0800
+
 efax-gtk (3.2.8-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru efax-gtk-3.2.8/debian/clean efax-gtk-3.2.8/debian/clean
--- efax-gtk-3.2.8/debian/clean 1970-01-01 08:00:00.0 +0800
+++ efax-gtk-3.2.8/debian/clean 2022-12-09 23:39:09.0 +0800
@@ -0,0 +1,2 @@
+efax/efax-0.9a.1
+efax/efix-0.9a.1
diff -Nru efax-gtk-3.2.8/debian/compat efax-gtk-3.2.8/debian/compat
--- efax-gtk-3.2.8/debian/compat2010-11-14 02:00:15.0 +0800
+++ efax-gtk-3.2.8/debian/compat1970-01-01 08:00:00.0 +0800
@@ -1 +0,0 @@
-5
diff -Nru efax-gtk-3.2.8/debian/control efax-gtk-3.2.8/debian/control
--- efax-gtk-3.2.8/debian/control   2017-03-22 19:43:43.0 +0800
+++ efax-gtk-3.2.8/debian/control   2022-12-09 23:39:09.0 +0800
@@ -2,7 +2,7 @@
 Section: comm
 Priority: optional
 Maintainer: Lior Kaplan 
-Build-Depends: debhelper (>= 5.0.0), autotools-dev, pkg-config, libgtk2.0-dev, 
libdbus-glib-1-dev, libtiff5-dev, gettext
+Build-Depends: debhelper-compat (= 12), pkg-config, libgtk2.0-dev, 
libtiff5-dev, gettext
 Standards-Version: 3.9.1
 Vcs-Git: git://git.code.sf.net/p/efax-gtk/git
 Vcs-Browser: http://sourceforge.net/p/efax-gtk/git/ci/master
diff -Nru efax-gtk-3.2.8/debian/patches/0002-fix-format-security.patch 
efax-gtk-3.2.8/debian/patches/0002-fix-format-security.patch
--- efax-gtk-3.2.8/debian/patches/0002-fix-format-security.patch
1970-01-01 08:00:00.0 +0800
+++ efax-gtk-3.2.8/debian/patches/0002-fix-format-security.patch
2022-12-09 23:39:09.0 +0800
@@ -0,0 +1,43 @@
+Description: fix for hardening
+ When bumping debhelper compat, hardening is enabled. So
+ we need to fix all the format-security errors.
+Author: Ying-Chun Liu (PaulLiu) 
+Last-Update: 2022-12-10
+Index: efax-gtk-3.2.8/src/dialogs.cpp
+===
+--- efax-gtk-3.2.8.orig/src/dialogs.cpp
 efax-gtk-3.2.8/src/dialogs.cpp
+@@ -398,7 +398,7 @@ InfoDialog::InfoDialog(const char* text,
+WinBase(caption, prog_config.window_icon_h,
+  modal, parent_p,
+  GTK_WINDOW(gtk_message_dialog_new(0, 
GtkDialogFlags(0),
+-message_type, GTK_BUTTONS_CLOSE, 
text))) {
++message_type, GTK_BUTTONS_CLOSE, 
"%s", text))) {
+ 
+   // make further specialisations for a message dialog object
+ 
+Index: efax-gtk-3.2.8/efax/efaxlib.c
+===
+--- efax-gtk-3.2.8.orig/efax/efaxlib.c
 efax-gtk-3.2.8/efax/efaxlib.c
+@@ -1943,7 +1943,7 @@ int nextopage ( OFILE *f, int page )
+   tiffinit(f) ;   /* rewind & update TIFF header */
+   break ;
+ case O_PCL:
+-  fprintf ( f->f, PCLEND ) ;
++  fprintf ( f->f, "%s", PCLEND ) ;
+   break ;
+ case O_PS:
+   fprintf ( f->f, PSPAGEEND ) ;
+Index: efax-gtk-3.2.8/efax-gtk-faxfilter/efax-gtk-socket-client.cpp
+===
+--- efax-gtk-3.2.8.orig/efax-gtk-faxfilter/efax-gtk-socket-client.cpp
 efax-gtk-3.2.8/efax-gtk-faxfilter/efax-gtk-socket-client.cpp
+@@ -87,6 +87,6 @@ int main(int argc, char* argv[]) {
+ void error_msg(const char* message) {
+ 
+   std::cerr << "efax-gtk-socket-client: " << message 

Bug#1025775: libsdl2 breaks cataclysm-dda autopkgtest in lxc: only bottom left corner appears in screenshot

[Simon McVittie]

On Fri, 09 Dec 2022 at 13:45:17 +, Simon McVittie wrote:
> On Thu, 08 Dec 2022 at 21:55:07 +0100, Paul Gevers wrote:
> > With a recent upload of libsdl2 the autopkgtest of cataclysm-dda fails in
> > testing when that autopkgtest is run with the binary packages of libsdl2
> > from unstable. It passes when run with only packages from testing. In
> > tabular form:
> > 
> >passfail
> > libsdl2from testing2.26.0+dfsg-1
> > cataclysm-dda  from testing0.F-3-8
> > all others from testingfrom testing
> 
> The test is to:
> 
> * run cataclysm-tiles in the background
> * wait 15 seconds
> * focus the cataclysm-tiles window
> * take a screenshot
> * use tesseract to do OCR on the window contents
> * look for some specific strings in the window contents
...
> I can reproduce this with a lxc container inside a bookworm VM:
> 
> $ sudo autopkgtest-build-lxc debian bookworm amd64
> $ apt download libsdl2-2.0-0=2.26.0+dfsg-1
> $ rm -fr ~/artifacts; \
>   autopkgtest \
>   --no-built-binaries \
>   --shell-fail \
>   -o ~/artifacts \
>   ~/libsdl2-2.0-0_2.26.0+dfsg-1_amd64.deb \
>   . \
>   -- lxc --sudo autopkgtest-bookworm-amd64

I can also reproduce this by poking a specific libSDL2-2.0.so.0 into the
container like this:

$ rm -fr ~/artifacts;
  autopkgtest \
  --no-built-binaries \
  --test-name=command1 \
  --copy 
~/libsdl2-2.0-0_2.26.0+dfsg-1_amd64/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2600.0:/test/libSDL2-2.0.so.0
 \
  --env=LD_LIBRARY_PATH=/test \
  -o ~/artifacts \
  . \
  -- lxc --sudo autopkgtest-bookworm-amd64

which lets me bisect SDL (in progress) with commands like:

$ rm -fr ~/artifacts;
  ./autogen.sh && \
  ./configure && \
  make -j5 && \
  autopkgtest \
  --no-built-binaries \
  --test-name=command1 \
  --copy $(readlink -f build/.libs/libSDL2-2.0.so.0):/test/libSDL2-2.0.so.0 
\
  --env=LD_LIBRARY_PATH=/test \
  -o ~/artifacts \
  /path/to/cataclysm-dda \
  -- lxc --sudo autopkgtest-bookworm-amd64

Meanwhile, I also have what I think is a workaround: if d/tests/control
and d/tests/cataclysm-tiles install and run a window manager in the Xvfb
environment (I used openbox), then it seems cataclysm-tiles becomes
correctly full-screen. This seems like a more realistic test-case anyway,
because in reality Debian users are going to run cataclysm-tiles in an
X11 or Wayland session with a working X11 window manager.

smcv
>From a1dadc03c10fd4ad1b81da96e32df19ed777a283 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Fri, 9 Dec 2022 14:03:03 +
Subject: [PATCH] d/tests/test-tiles: Run a window manager inside Xvfb

With SDL 2.26, it seems that under some circumstances (lxc but not qemu
or podman, for some reason), the window won't become fullscreen without
a window manager being present.

Games are generally designed to run under a window manager, so it
isn't a huge problem if they misbehave without one. Add a simple window
manager (openbox) to make this test more realistic.

Closes: #1025775
Signed-off-by: Simon McVittie 
---
 debian/tests/control| 2 +-
 debian/tests/test-tiles | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/tests/control b/debian/tests/control
index 86c92df4..4048a43a 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -4,4 +4,4 @@ Depends: cataclysm-dda-curses, expect, locales-all
 
 Test-Command: timeout -v 5m xvfb-run -s "-wr" debian/tests/test-tiles
 Restrictions: allow-stderr, superficial
-Depends: cataclysm-dda-sdl, xvfb, xauth, xdotool, scrot, tesseract-ocr, locales-all, pulseaudio
+Depends: cataclysm-dda-sdl, openbox, xvfb, xauth, xdotool, scrot, tesseract-ocr, locales-all, pulseaudio
diff --git a/debian/tests/test-tiles b/debian/tests/test-tiles
index 3aaa133a..3d9f04a5 100755
--- a/debian/tests/test-tiles
+++ b/debian/tests/test-tiles
@@ -21,7 +21,8 @@ export LANG=en_US.UTF-8
 # cdda needs audio or it won't start (#59464)
 export SDL_AUDIODRIVER=dummy
 
-# start cdda and wait a bit
+# start cdda and a window manager, and wait a bit
+openbox &
 cataclysm-tiles &
 PID=$!
 sleep 15
-- 
2.38.1

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

[Sean Whitton]

Hello Paul,

On Tue 01 Nov 2022 at 09:47PM +01, Paul Gevers wrote:

> 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.

Alright, all the RC bugs are closed.  Of the four autopkgtest failures,
emacs-deferred and flycheck we need to wait and see when they are
re-run, but the evil-el and haskell-mode failures are due to bugs in
those packages.  evil-el is orphaned and haskell-mode is unmaintained.
Could they both be hinted out of testing, please?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1025812: elpa-haskell-mode: Tests fail against Emacs 28.2

[Sean Whitton]

Package: elpa-haskell-mode
Version: 17.2-3
Severity: serious

Hello,

Dear maintainer,

Test haskell-generate-tags condition:
(file-missing "Searching for program" "No such file or directory" "git")
   FAILED  100/538  haskell-generate-tags (0.048838 sec)

See: 
https://ci.debian.net/data/autopkgtest/testing/amd64/h/haskell-mode/29137490/log.gz

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1025382: SOLVED Bug#1025382: nvidia-tesla-510-kernel-dkms: Error when building initial module for kernel 6.0.0-5-amd64 (x86_64)

[Hoareau Jean Pierre]

Sir, I inform you that I fixed this problem during the Bookworm update 
of December 7, 2022 by deleting the following files: Commit Log for Wed Dec  7 18:25:07 2022Commit Log for Wed Dec  7 18:26:49 2022

Les paquets suivants ont été supprimés :
liblist-moreutils-perl
liblist-moreutils-xs-perl
libnvidia-allocator1
libnvidia-allocator1:i386
libnvidia-rtcore
libnvidia-tesla-470-cbl
libnvidia-tesla-470-eglcore
libnvidia-tesla-470-eglcore:i386
libnvidia-tesla-470-glcore
libnvidia-tesla-470-glcore:i386
libnvidia-tesla-470-glvkspirv
libnvidia-tesla-470-glvkspirv:i386
libnvidia-tesla-470-ptxjitcompiler1
libnvidia-tesla-470-ptxjitcompiler1:i386
libnvidia-tesla-470-rtcore

Commit Log for Wed Dec  7 18:26:49 2022
Les paquets suivants ont été complètement supprimés :
libgl1-nvidia-tesla-510-glvnd-glx
libglx-nvidia-tesla-510-0
libnvidia-tesla-510-ml1
libnvidia-tesla-510-ptxjitcompiler1
nvidia-tesla-510-alternative
nvidia-tesla-510-kernel-dkms
nvidia-tesla-510-vdpau-driver

and reinstalling the package nvidia-tesla-510-kernel-dkms The new 
updates went well. Many thanks, regards Jean Pierre

Bug#1025025: ImportError: cannot import name 'Application' from 'cleo'

[George Shuklin]

Unfortunately, 1.2.2+dfsg-1didn't fixed the problem:

dpkg -l|grep poetr
ii  python3-poetry  1.2.2+dfsg-1

/usr/bin/poetry config virtualenvs.create false
Traceback (most recent call last):
  File "/usr/bin/poetry", line 5, in 
    from poetry.console.application import main
  File "/usr/lib/python3/dist-packages/poetry/console/application.py", 
line 13, in 

    from cleo.events.console_events import COMMAND
ModuleNotFoundError: No module named 'cleo.events'

Bug#1025739: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Andreas Tille]

Hi Marco

Am Fri, Dec 09, 2022 at 03:33:38PM +0100 schrieb Marco d'Itri:
> On Dec 09, Andreas Tille  wrote:
> 
> > I would consider asking upstream about this for sure but the code is in
> > maintenance mode and there is no Git repository to step back in history.
> > The only way to go would be to take configure.ac from a later version
> > and find out how it can be tweaked to create some working configure
> > file from it.  I do not consider my time well spent in doing so except
> > if there is some consensus here on the list that configure files without
> > configure.ac are "missing source".
> If there is no surviving configure.ac which can generate the current 
> configure file then it is quite obvious that this is not a DFSG issue, 
> because no such source exists.

Thanks to Alexander Sulfrian who pointed out the Git repository
featuring old tags that were obviously taken over from SVN I was proven
wrong with the statement that there is no configure.ac any more.

Unfortunately this is no simple drop-in with modern autoconf tools
and my weak attempt in Git to use this failed.[1]

> But if your package contains a manually edited configure file then this
> is a bad practice, and experience shows that sooner or later you will 
> have to deal with the resulting bugs.

I have no reasons to assume that the provided configure was manually
edited.  Its definitely created by old Autoconf (2.57) and can't be
recreated with recent autoconf tools.  But the build works fine with the
configure that is provided.

> Clearly, the severity of these bugs is different, at least as long as 
> your package builds.

This is actually my main point.  Helmut and I have obviously different
opinions about the relevance of the problem regarding DFSG and the
resulting implication for the severity of the bug.  Helmut have stated
good reasons why a recent configure.ac is helpful / important for him
(injecting PKG_CHECK_MODULES) and I would agree with severity important
(to get progress ongoing).  However, waving with the big club DFSG is
IMHO a bit too much in the case of a shell script (no matter how badly
it is written for the intended purpose).

I moved the discussion to debian-devel not primarily for this specific
case (which I intend to fix no matter what severity this bug might
have).  My main point is that we should find some consensus about the
severity of this bug to be clear in other cases we definitely have in
our archive.

Kind regards
   Andreas.

[1] 
https://salsa.debian.org/med-team/hmmer2/-/commit/d1f5b3d08391efd66b69090e544803d6bd0f6638

-- 
http://fam-tille.de

Bug#1017881: ITA: unclutter-xfixes -- hide the X mouse cursor after a period of inactivity, using XFixes

[Sean Whitton]

Hello,

On Fri 09 Dec 2022 at 03:13AM -08, Stefan Kangas wrote:

> Sean Whitton  writes:
>
>> You can type 'dgit fetch sid' to obtain the signed debian/1.6-1 tag I
>> made upon upload, for pushing to salsa (for future sponsorship you might
>> give me write access to push these myself -- the sponsor, and not the
>> sponsee, should be making the signed tags, as in this case).
>
> I've pushed your signed tag, and invited you to the salsa repository.

Cool, thanks.

>> I noticed the new Vcs-* fields are wrong, btw.
>
> I'm probably missing something, but they seem correct to me:
>
> Vcs-Browser: https://salsa.debian.org/skangas/hashcash
> Vcs-Git: https://salsa.debian.org/skangas/hashcash.git -b debian/latest

s/hashcash/unclutter-xfixes/ surely?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1025811: fonts-ipamj-mincho: New upstream release available

[YOSHINO Yoshihito]

Package: fonts-ipamj-mincho
Severity: normal
X-Debbugs-Cc: yy.y.ja...@gmail.com

Dear Maintainer,

New upstream version 006.01 is available at
https://moji.or.jp/mojikiban/font/

Also note the upstream change:
https://moji.or.jp/2020/08/25/release20200825/

Regards,

-- 
YOSHINO Yoshihito 

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

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

Bug#1025714: octave-vrml: FTBFS randomly in sid (dpkg-gencontrol failure)

[Niels Thykier]

Rafael Laboissière:

Control: tags -1 + confirmed
Control: notfound -1 1.0.13-7
Control: reassign -1 dh-octave
Control: found -1 1.2.4

* Santiago Vila  [2022-12-07 22:30]:


Package: src:octave-vrml
Version: 1.0.13-7
Tags: ftbfs

Dear Maintainer:

[...]
The file debian/octave-vrml.substvars seems in fact to be broken:

 octave:Depends=octave (>= 7.3.0), octave-linear-algebra,
 octave-miscellaneous, octave-statistics
 , octave-struct
 octave:Upstream-Description=3D graphics using VRML
 misc:Depends=
 misc:Pre-Depends=


[...]


Thanks for the bug report.

The issue is caused by a bug in the dh_octave_substvar script, from the 
dh-octave package. I am looking at it. More to come soon.


Best,

Rafael Laboissière



I had hoped that debhelper's addsubstvar would catch an unescaped 
newline in the input bug already in the addsubstvar's call if it was 
done via `Dh_Lib`.  If you find that is not the case, please do file a 
bug against debhelper for that bit.


~Niels

Bug#1017004: closed by Debian FTP Masters (reply to Jonas Smedegaard ) (Bug#1017004: fixed in asterisk 1:20.0.1~dfsg+~cs6.12.40431414-1)

[Salvatore Bonaccorso]

Hi Jonas,

Thanks for your time going into detail about it.

On Fri, Dec 09, 2022 at 03:59:47PM +0100, Jonas Smedegaard wrote:
> Hi Salvatore,
> 
> Quoting Salvatore Bonaccorso (2022-12-09 15:15:26)
> > This issue does not appear to be fixed with the
> > 1:20.0.1~dfsg+~cs6.12.40431414-1 . could you double-check again?
> 
> First of all: Thanks a lot for doublechecking!
> 
> I did not test the bug nor the bugfix - I only traced reports across
> projects when I closed this bug.
> 
> If you reopen similarly based only on tracing reports across projects,
> then I suspect the (sub)issue really is Asterisk project failing to
> prominently reference CVE or GHSA issue hints in their bug closure.
> 
> The issue tracked here - unless I am mistaken - is CVE-2022-31031, also
> reported as GHSA-26j7-ww69-c4qj against PJSIP project, and (referencing
> only GHSA identifiers, and only in patch content not commit header)

This is correct, we are talking about CVE-2022-31031 known as well as
GHSA-26j7-ww69-c4qj.
> 
> PJSIP project fix is here:
> https://github.com/pjsip/pjproject/commit/450baca

Correct, this is the one referenced.
> 
> Asterisk inclusion of the PJSIP fix is here:
> https://github.com/asterisk/asterisk/commit/702f400

This looks as well correct.

> Debian inclusion of Asterisk inclusion of PJSIP fix is here:
> https://salsa.debian.org/pkg-voip-team/asterisk/-/blob/debian/1%2520.0.1_dfsg+_cs6.12.40431414-1/third-party/pjproject/patches/0201-potential-stack-buffer-overflow-when-parsing-message-as-a-STUN-client.patch
> 
> I have now double-checked that during build the configure target has
> succesfully applied the STUN-related patch, and that the file
> third-party/pjproject/source/pjlib-util/src/pjlib-util/stun_simple.c
> contains the newly introduced string "attr_max_cnt" unique to the PJSIP
> bugfix.

Ok so now I see what went possibly wrong. On source unpack an applying
all debian/patches, the file 
./Xpjproject/pjlib-util/src/pjlib-util/stun_simple.c
was still unpatched.

>From here I now understand they are patched by the upstream approach
trough third-party/pjproject/Makefile using the apply_patches script
and the build of the third_party included projects is triggered in the
build.

> I (still) consider this issue fixed, but will leave this bugreport open
> awaiting your further assesment.

Thanks so at further look and understanding the above, the additional
patches get applied and so CVE-2022-31031 should indeed be fixed. I
checked now again the explicit build, and the file get patched in
./asterisk-20.0.1~dfsg+~cs6.12.40431414/third-party/pjproject/source/pjlib-util/src/pjlib-util/stun_simple.c

Regards,
Salvatore

Bug#1025370: ntcard: ftbfs with nthash 2.3.0

[Andreas Tille]

Control: forwarded -1 https://github.com/bcgsc/ntCard/issues/75

Bug#965467: concalc: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Ying-Chun Liu (PaulLiu)]

Hi all,

I think this bug is easy to fix.
This package uses cdbs. Bump debhelper version to 9 solves the problem.
NMU as attachment.

Using debhelper compat >= 10 will have some problems. For example, 
cannot build twice in a row.


I'll wait for 5 days and upload to delay/5 queue.
The maintainer allows lowNMU. So if anyone wants to upload it faster 
please do.


NMU diff as attachment.

Yours,
Paul


diff -Nru concalc-0.9.2/debian/changelog concalc-0.9.2/debian/changelog
--- concalc-0.9.2/debian/changelog  2011-11-13 15:19:43.0 +0800
+++ concalc-0.9.2/debian/changelog  2022-12-09 23:22:45.0 +0800
@@ -1,3 +1,10 @@
+concalc (0.9.2-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Bump debhelper version to 9.
+
+ -- Ying-Chun Liu (PaulLiu)   Fri, 09 Dec 2022 23:22:45 
+0800
+
 concalc (0.9.2-2) unstable; urgency=low
 
   * Add fix-string-format-error.patch, thanks to Eric Alexander
diff -Nru concalc-0.9.2/debian/compat concalc-0.9.2/debian/compat
--- concalc-0.9.2/debian/compat 2008-01-19 04:09:29.0 +0800
+++ concalc-0.9.2/debian/compat 2022-12-09 23:19:20.0 +0800
@@ -1 +1 @@
-6
+9
diff -Nru concalc-0.9.2/debian/control concalc-0.9.2/debian/control
--- concalc-0.9.2/debian/control2011-11-13 14:43:31.0 +0800
+++ concalc-0.9.2/debian/control2022-12-09 23:19:28.0 +0800
@@ -2,7 +2,7 @@
 Section: math
 Priority: optional
 Maintainer: Varun Hiremath 
-Build-Depends: cdbs, debhelper (>= 7), quilt
+Build-Depends: cdbs, debhelper (>= 9), quilt
 Standards-Version: 3.9.2
 Homepage: http://extcalc-linux.sourceforge.net/
 Vcs-Svn: https://bollin.googlecode.com/svn/concalc/


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025739: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Alexander Sulfrian]

Hi,

On Fri, Dec 09, 2022 at 01:14:40PM +0100, Andreas Tille wrote:
> I would consider asking upstream about this for sure but the code is in
> maintenance mode and there is no Git repository to step back in history.
> The only way to go would be to take configure.ac from a later version
> and find out how it can be tweaked to create some working configure
> file from it.  I do not consider my time well spent in doing so except
> if there is some consensus here on the list that configure files without
> configure.ac are "missing source".

isn't the matching configure.ac available here?

https://github.com/MichiganTech/hmmer/blob/2.3.2/configure.ac

This repository is at least referenced in debian/upstream/metadata and
the package version seems to match the git tag.


Alex

Bug#1017004: closed by Debian FTP Masters (reply to Jonas Smedegaard ) (Bug#1017004: fixed in asterisk 1:20.0.1~dfsg+~cs6.12.40431414-1)

[Jonas Smedegaard]

Hi Salvatore,

Quoting Salvatore Bonaccorso (2022-12-09 15:15:26)
> This issue does not appear to be fixed with the
> 1:20.0.1~dfsg+~cs6.12.40431414-1 . could you double-check again?

First of all: Thanks a lot for doublechecking!

I did not test the bug nor the bugfix - I only traced reports across
projects when I closed this bug.

If you reopen similarly based only on tracing reports across projects,
then I suspect the (sub)issue really is Asterisk project failing to
prominently reference CVE or GHSA issue hints in their bug closure.

The issue tracked here - unless I am mistaken - is CVE-2022-31031, also
reported as GHSA-26j7-ww69-c4qj against PJSIP project, and (referencing
only GHSA identifiers, and only in patch content not commit header)

PJSIP project fix is here:
https://github.com/pjsip/pjproject/commit/450baca

Asterisk inclusion of the PJSIP fix is here:
https://github.com/asterisk/asterisk/commit/702f400

Debian inclusion of Asterisk inclusion of PJSIP fix is here:
https://salsa.debian.org/pkg-voip-team/asterisk/-/blob/debian/1%2520.0.1_dfsg+_cs6.12.40431414-1/third-party/pjproject/patches/0201-potential-stack-buffer-overflow-when-parsing-message-as-a-STUN-client.patch

I have now double-checked that during build the configure target has
succesfully applied the STUN-related patch, and that the file
third-party/pjproject/source/pjlib-util/src/pjlib-util/stun_simple.c
contains the newly introduced string "attr_max_cnt" unique to the PJSIP
bugfix.


I (still) consider this issue fixed, but will leave this bugreport open
awaiting your further assesment.

Thanks,

 - Jonas

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

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

signature.asc
Description: signature

Bug#1025810: libnginx-mod-http-memc: Rebuild parser using ragel

[Jérémy Lal]

Package: libnginx-mod-http-memc
Version: 0.19-1+b1
Severity: normal

Because it's actually not in its preferred form for modification,
src/ngx_http_memc_response.c
should be rebuilt out of 
 ragel -G2 src/ngx_http_memc_response.rl

as explained in the docs.



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

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 libnginx-mod-http-memc depends on:
ii  libc6 2.36-6
ii  nginx-common  1.22.1-4

Versions of packages libnginx-mod-http-memc recommends:
ii  nginx-core [nginx]  1.22.1-4

libnginx-mod-http-memc suggests no packages.

-- no debconf information

Bug#1025808: python3-jinja2: Bug in jinja2 template macros causes ansible problems

[Micah Anderson]

Package: python3-jinja2
Version: 3.0.3-2
Severity: important
Tags: upstream

Hello,

There is a bug in the version of the package that is in Bookworm that causes
Ansible templates to fail in frustrating ways (see
https://github.com/ansible/ansible/issues/77272), it has been fixed upstream
(https://github.com/pallets/jinja/issues/1510 and fixed upstream in the 3.1.0
release (https://github.com/pallets/jinja/pull/1511).

This will affect Ansible users quite a bit if this version is included in the
release.

Thanks!

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

Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
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 python3-jinja2 depends on:
ii  python3 3.10.6-1
ii  python3-markupsafe  2.1.1-1+b1

Versions of packages python3-jinja2 recommends:
ii  python3-babel  2.10.3-1
ii  python3-pkg-resources  65.5.0-1

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

-- no debconf information

Bug#1025807: nginx-dev: Use absolute paths in /usr/share/nginx/modules-available/*.conf files

[Jérémy Lal]

Package: nginx-dev
Version: 1.22.1-4
Severity: normal

When running nginx as user (with another root), one cannot include those conf 
files,
before they end up loading modules relative to current nginx root, which is 
clearly
not what is expected:

[emerg] dlopen() 
"/home/dev/Software/github/upcache/nginx/modules/ndk_http_module.so" failed 
(/home/dev/Software/github/upcache/nginx/modules/ndk_http_module.so: cannot 
open shared object file: No such file or directory) in 
/usr/share/nginx/modules-available/mod-http-ndk.conf:1


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 nginx-dev depends on:
ii  debhelper [debhelper-compat]  13.11.1
ii  dpkg-dev  1.21.12
ii  libgd-dev 2.3.3-7
ii  libgeoip-dev  1.6.12-9
ii  libpcre3-dev  2:8.39-14
ii  libperl-dev   5.36.0-5
ii  libssl-dev3.0.7-1
ii  libxslt1-dev  1.1.35-1
ii  nginx-core1.22.1-4
ii  po-debconf1.0.21+nmu1
ii  quilt 0.66-2.2
ii  zlib1g-dev1:1.2.13.dfsg-1

nginx-dev recommends no packages.

nginx-dev suggests no packages.

-- no debconf information

Bug#1025739: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Marco d'Itri]

On Dec 09, Andreas Tille  wrote:

> I would consider asking upstream about this for sure but the code is in
> maintenance mode and there is no Git repository to step back in history.
> The only way to go would be to take configure.ac from a later version
> and find out how it can be tweaked to create some working configure
> file from it.  I do not consider my time well spent in doing so except
> if there is some consensus here on the list that configure files without
> configure.ac are "missing source".
If there is no surviving configure.ac which can generate the current 
configure file then it is quite obvious that this is not a DFSG issue, 
because no such source exists.

But if your package contains a manually edited configure file then this
is a bad practice, and experience shows that sooner or later you will 
have to deal with the resulting bugs.

Clearly, the severity of these bugs is different, at least as long as 
your package builds.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1020415: bcron-start terminated 111 status

[Georges Khaznadar]

Dear Thomas,

Tomas Hodek a écrit :
> I have been using Debian on servers for many years, but this is first time I
> had to file bug report, so i am quite newbie in how to properly debug
> package. 

Please can you remind me why you could not use cron for your crontabs?
As I understand cron's internals a little better than bcron's, I might
be able to fix the issue which prevents you from using cron?

Here is an excerpt of your latest message about this issue:

Our issue with cron was not yet reported, since I did not found any
regularity and have no test environment where I was able to
reproduce this issue. Only thing I know for sure is the fact that
cron process sometimes eats 1 whole CPU core and then jobs are not
being executed correctly. Normal CPU usage is mere percents. Restart
of daemon fixes it.

I suppose that there is some significant difference between your set of
cron jobs and cron jobs other debian users are running majoritarily, as
nobody complains about a similar issue.

I wonder whether you have a few commands in some cron job which can have
a long life time and require many computing force? Could you know which
children commands were executed when you saw high CPU usage? cron puts
no limit (in duration or cpu & memory usage) for children processes.


> But if RFH will not help with finding and issue, this package is no
> longer usable for users, so marking it obsolete seems to only a reasonable
> choice. But it is not up to me, and I think it would be better to someone to
> look at this issue, who has better understanding of how systemd and c++ (I
> think bcron is written in it) programming works.

Bcron is written in pure C, no C++; the problem is that its author,
Bruce Guenter, wrote bcron's source files without taking care of any
internal documentation. Here is an example, taken from line 27 of the
file bcron-spool.c

---8<---
static void respond(const char* msg)
{
...
}
---8<---

Today's guidelines are to prepend a documentation before such function
definitions. As I read the code of `respond`, I would bet for such a
header:

---8<---
/**
 * @function respond:
 *   outputs a message, and exits
 *
 * @param msg is a string whose first character decides the exit way
 *   and the remainder is the actual message to display. When the first
 *   character is 'K', it calls exit(0); when it is 'Z', it dies with
 *   code 111 logged to syslog; otherwise, it dies with code 100.
 **/
static void respond(const char* msg)
{
...
}
---8<---

There are about 40 undocumented function in bcron's source code. I do
not want to spend much time to understand all implicit ideas wired in
the C code, and verify their adequation with the program's goal. If
somebody wants to revive bcron, this is still the right way to go
forward.

Indeed, the situation is even worse: most of bcron's code is built upon
Bruce Guenter's own libraries (debian packages: bglibs and libbg-dev),
whose internals are documented nowhere, so if one wants to audit
how the previous function exits, one has to document thoroughly the
functions and macros die_oom, die1sys, die1, die3sys whose source code
are under /usr/include/bglibs/msg.h and in the C source (which you can
get by `apt-get source bglibs`).

Instead of this, cron is built directly upon libc, whose primitives are
documented by up-to-date manpages.

Best regards,   Georges.



signature.asc
Description: PGP signature

Bug#1025739: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Helmut Grohne]

Hi Andreas,

On Fri, Dec 09, 2022 at 01:14:40PM +0100, Andreas Tille wrote:
> This "prominent" example was heavily discussed and IMHO its not really
> an example for the current case.  If you look at the configure file of
> hmmer2[1] it surely claims that it is autogenerated.  However, its
> perfectly simple and straightforward shell text with sensibly named
> variables so it is editable code.  Calling this piece of shell source
> code "missing source" is IMHO an over-interpretation of the letters of
> DFSG.

Unsurprisingly, I respectfully disagree. A typical change you'd want to
do to configure is replace a bare pkg-config invocation with
PKG_CHECK_MODULES. Doing this to your configure script is quite similar
in experience to patching a binary. Another very common task is updating
macros from old version, because they contain bugfixes. Being macros,
you'd be chasing down every single interpolation.

Your comparison to compressed javascript (in your earlier reply) is also
interesting. A major aspect of minification is removal of spaces.
Looking into the generated configure script, indentation is total
garbage. Then minification tends to mangle variables. While configure
doesn't really have mangled variables, it only has global variables and
since it doesn't use functions, it establishes scope using *_save
variables. The resulting mess of variables isn't any better than that in
compressed javascript.

So yeah, maybe the comparison to binary is not exactly right, but
comparing it to disassembly certainly is. If you were to ship an
assembly file compiled from a C file without the C source, that would
quite certainly count as missing source.

And then, we also have DFSG #3, which primarily talks about the license
allowing derivative works, but if the "source" renders derivative works
infeasible, then having a license to do so is kinda useless.

Helmut

Bug#1025729: evolution-data-server: Gmail OAuth2: "Access blocked: GNOME Evolution’s request is invalid"

[Jeremy Bicha]

On Thu, Dec 8, 2022 at 9:11 PM Full Name  wrote:
> To reproduce for an existing account that hasn't yet been blocked, I
> think revoking Evolution from third party app access should do the
> trick:
>
> 1. Login to google
> 2. Go to https://myaccount.google.com/permissions?pli=1
> 3. Under GNOME Evolution, Remove Access
> 4. Attempt to login using Evolution

Instead of using Evolution to log in, use GNOME Online Accounts.

Open the GNOME Settings app.
In the sidebar, click Online Accounts
Click Add an account > Google
Log in here.
After you log in, open Evolution.

Thank you,
Jeremy Bicha

Bug#1017004: closed by Debian FTP Masters (reply to Jonas Smedegaard ) (Bug#1017004: fixed in asterisk 1:20.0.1~dfsg+~cs6.12.40431414-1)

[Salvatore Bonaccorso]

Control: reopen -1
Control: found -1 1:18.14.0~~rc1~dfsg+~cs6.12.40431414-1
Control: found -1 1:20.0.1~dfsg+~cs6.12.40431414-1

Hi Jonas,

This issue does not appear to be fixed with the
1:20.0.1~dfsg+~cs6.12.40431414-1 . could you double-check again?

Regards,
Salvatore

Bug#1025274: RFS: tuxguitar/1.5.6+dfsg1-1 [QA] -- Multitrack guitar tablature editor and player

[Lourisvaldo Figueredo Junior]

Em sexta-feira, 9 de dezembro de 2022, às 10:10:32 -03, Helmar Gerloni 
escreveu:
>  Right now i only have
> amd64 hardware available, so i can't build on other architectures
> (cross-compile maybe, but that doesn't sound trivial).

I have already had success following these articles:
https://wiki.debian.org/CrossCompiling
https://wiki.debian.org/CrossBuildPackagingGuidelines

Good Luck!

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

Bug#1014284: [kernel 5.18.5-1] [arm64 on Rock64 SBC]

[Diederik de Haas]

Control: tag -1 moreinfo

On Sunday, 3 July 2022 14:40:36 CET Jean-Marc LACROIX wrote:
> Package: linux-image-5.18.0-2-arm64
> Version:  5.18.5-1
> 
> Please find in  attached file success story  (!)   on recent boot  for
> target rock64 (pine64)  with 64 Go class10  MMC card with Debian  11.3
> Bullseye and Bookworm 5.18.5-1 kernel with following configuration ...

There is no attached file ... 

> ansible@hn-rock64-130:~$ uname -a
> Linux hn-rock64-130 5.18.0-2-arm64 #1 SMP Debian 5.18.5-1 (2022-06-16)
> aarch64 GNU/Linux
> ...
> ansible@hn-rock64-130:~$ cat
> /etc/apt/preferences.d/preferences_debian_v_11_bullseye* |grep -v "#"
> |grep -v ^$
> 
> Package: vmdb2
> Pin: release o=Debian,l=Debian,n=bullseye
> Pin-Priority: 920
> Package: *
> Pin: release o=Debian,l=Debian,n=bullseye/updates
> Pin-Priority: 500
> Package: *
> Pin: release o=Debian,l=Debian,n=bullseye-update
> Pin-Priority: 500
> Package: *
> Pin: release o=Debian,l=Debian,n=bullseye
> Pin-Priority: 500
> Package: *
> Pin: release o=Debian,l=Debian,n=bullseye-backports
> Pin-Priority: 100
> Package: *
> Pin: release o=Debian,l=Debian,n=buster
> Pin-Priority: 90
> Package: *
> Pin: release o=Debian,l=Debian,n=bookworm
> Pin-Priority: 80
> Package: *
> Pin: release o=Debian,l=Debian,n=sid
> Pin-Priority: 70
> Package: *
> Pin: release o=Debian,l=Debian,n=experimental
> Pin-Priority: 60
> Package: avahi-daemon
> Pin: release *
> Pin-Priority: -1
> Package: dbus
> Pin: release a=bullseye
> Pin-Priority: -1
> 
> Package: dhcpcd5
> Pin: release *
> Pin-Priority: -1
> Package: rtkit
> Pin: release *
> Pin-Priority: -1
> Package: systemd
> Pin: release *
> Pin-Priority: -1

This looks rather troublesome to me as you're combining oldstable/stable/
testing/unstable/experimental*, but AFAICT you're mostly running a Bullseye 
system and then using kernel 5.18.5-1 isn't the most logical choice.
If you want to try a newer kernel on a Bullseye system, using bullseye-
backports would be the most logical choice ...

*) I'm aware of how APT preferences work, so there's no need to explain that.
It's probably not relevant to this bug, but this is called a FrankenDebian:
https://wiki.debian.org/DontBreakDebian

> ... list of loaded kernel modules

> After installing kernel 5.18.0-2-arm64, the good  news is that the mmc
> device number now looks ALWAYS correct (!).  Previously, in the kernel
> (5.10.xx),   when booting   target,sometimes mmc  id   was  either
> /dev/mmcblk0 or /dev/mmcblk1 for unknown reasons (?).
> 
> Now either with a soft  reboot command (sudo reboot)  or with a forced
> shutdown (power ON/OFF), the identification is still good,i.e. /dev/mmcblk0.

Great.

> But [ref 1], there is still some stranges messages in dmesg ...

I'm guessing [ref 1] and [ref 2] were mentioned in the file which was NOT 
attached? The consequence is that I can't tell what the issue is what this bug 
is/should be about. Can you clarify?

> [7.585764] dwmmc_rockchip ff52.mmc: DW MMC controller at irq
> 40,32 bit host data width,256 deep fifo
> [7.586886] rockchip-pinctrl pinctrl: pin gpio0-2 already requested
> by vcc-host-5v-regulator; cannot claim for vcc-host1-5v-regulator
> [7.588110] rockchip-pinctrl pinctrl: pin-2 (vcc-host1-5v-regulator)
> status -22
> [7.588576] ehci-platform ff5c.usb: USB 2.0 started, EHCI 1.00
> [7.588797] rockchip-pinctrl pinctrl: could not request pin 2
> (gpio0-2) from group usb20-host-drv  on device rockchip-pinctrl
> [7.589899] usb usb1: New USB device found, idVendor=1d6b,
> idProduct=0002, bcdDevice= 5.18
> [7.590353] reg-fixed-voltage vcc-host1-5v-regulator: Error applying
> setting, reverse things back

Ideally these warnings should be resolved some time, but I'm seeing them too 
(I also have Rock64 devices), but AFAICT they're harmless.

> [7.694550] rk_gmac-dwmac ff54.ethernet: phy regulator is not
> available yet, deferred probing

The 'deferred probing' just means it will be tried again at a later point.
If ethernet would not work after it finished booting, that would be a problem, 
but I'm not aware that actually happens.

> As a result, it is not very clear for me why there is one warning
> message ([ref 2]) ?

Not having [ref 2] so I don't know which warning that is.
But as said earlier, there are several warnings (and maybe even errors) 
reported, but AFAIK they're harmless.

> Any ideas or suggestions will be appreciated (!)

If you could clearly state what issue/bug you encountered, that would help.
And while you're at it, please also try whether a more recent kernel may have 
already fixed the issue you tried to report.

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

Bug#1025775: libsdl2 breaks cataclysm-dda autopkgtest in lxc: only bottom left corner appears in screenshot

[Simon McVittie]

Control: retitle -1 libsdl2 breaks cataclysm-dda autopkgtest in lxc: only 
bottom left corner appears in screenshot

On Thu, 08 Dec 2022 at 21:55:07 +0100, Paul Gevers wrote:
> With a recent upload of libsdl2 the autopkgtest of cataclysm-dda fails in
> testing when that autopkgtest is run with the binary packages of libsdl2
> from unstable. It passes when run with only packages from testing. In
> tabular form:
> 
>passfail
> libsdl2from testing2.26.0+dfsg-1
> cataclysm-dda  from testing0.F-3-8
> all others from testingfrom testing

The test is to:

* run cataclysm-tiles in the background
* wait 15 seconds
* focus the cataclysm-tiles window
* take a screenshot
* use tesseract to do OCR on the window contents
* look for some specific strings in the window contents

This seems to be quite flaky regardless of SDL version: while trying to
reproduce the bug I've seen "New Game" OCR as "(NEWIGAME]", and "World"
OCR as "Morld" or "Hor 1d".

On ci.debian.net with the old SDL, it renders like this:
https://people.debian.org/~smcv/bug1025775/good.png
https://people.debian.org/~smcv/bug1025775/good.txt

On ci.debian.net with the new SDL, it renders like this:
https://people.debian.org/~smcv/bug1025775/bad.png
https://people.debian.org/~smcv/bug1025775/bad.txt

which seems to be the same as the bottom left 640x384 pixel region of
the good rendering?

I can reproduce this with a lxc container inside a bookworm VM:

$ sudo autopkgtest-build-lxc debian bookworm amd64
$ apt download libsdl2-2.0-0=2.26.0+dfsg-1
$ rm -fr ~/artifacts; \
  autopkgtest \
  --no-built-binaries \
  --shell-fail \
  -o ~/artifacts \
  ~/libsdl2-2.0-0_2.26.0+dfsg-1_amd64.deb \
  . \
  -- lxc --sudo autopkgtest-bookworm-amd64

Adapting the test script to take a screenshot of the whole screen instead
of just the window, and use a white background instead of black, it looks
like the game is only rendering into a small region of the screen:
https://people.debian.org/~smcv/bug1025775/bad-screen.png

I *cannot* reproduce this interactively in a bookworm VM with the upgraded
libsdl2. I don't know why lxc is any different, but it seems that it is.
When I run

$ rm -fr ~/artifacts; \
  mkdir ~/artifacts; \
  AUTOPKGTEST_ARTIFACTS=$HOME/artifacts timeout -v 5m xvfb-run 
debian/tests/test-tiles

in my VM, even with the upgraded SDL I get a rendering similar
to good.png, good.txt above. I was also unable to reproduce this
interactively in a podman container.

Please see
https://salsa.debian.org/smcv/cataclysm-dda-branches/-/tree/autopkgtest-misc
for some adjustments to the autopkgtest that might make it easier to debug.

smcv

Bug#1025274: RFS: tuxguitar/1.5.6+dfsg1-1 [QA] -- Multitrack guitar tablature editor and player

[Helmar Gerloni]

First of all thank you for your feedback, Adam!

Am Donnerstag, 8. Dezember 2022, 17:17:48 CET schrieb Adam Borowski:
> On Thu, Dec 01, 2022 at 09:35:15PM +0100, Helmar Gerloni wrote:
> > The package builds and runs on amd64.  I was not able to build it on i386
> > because of missing libswt-gtk-4-java.
> 
> That's not a problem, upstream of that package has dropped support for
> 32-bit and unless it somehow comes back, tuxguitar will stay
> BD-Uninstallable on those architectures.
> 
> Because of the off chance the dependences _do_ come back, it's better
> to leave them enabled instead of explicitly dropping in debian/control.
Tuxguitar 1.5 is now built with Maven and comes with build scripts for Linux 
on amd64 (x86_64), i386 (x86) and armv7hl. The differences between the build 
scripts for amd64 and i386 are minor, and for many other architectures 
supported by Debian there are no build scripts at all.
So my idea was to use the upstream build scripts for amd64 for all 
architectures and modify/patch them so that they hopefully work on all 
architectures supported by Debian.
This is the reason why i removed all non-amd64 build scripts from the Debian 
sources (among other things).
But maybe this is not the right way, i don't know. Right now i only have amd64 
hardware available, so i can't build on other architectures (cross-compile 
maybe, but that doesn't sound trivial).

> > I don't know if it builds on other architectures; probably not
> > out-of-the-box.
> 
> The previous versions were ok, I tested arm64 and it fails the same way
> amd64 does.  Which is:
> 
> [ERROR] Plugin org.apache.maven.plugins:maven-antrun-plugin:1.7 or one of
> its dependencies could not be resolved: Cannot access central
> (https://repo.maven.apache.org/maven2) in offline mode and the artifact
> org.apache.maven.plugins:maven-antrun-plugin:jar:1.7 has not been downloaded
> from it before.
> 
> Sounds like you missed a build dependency...
I thought ${maven:CompileDepends} in debian/control handles this build 
dependencies, but somehow it did not work.
I added some more dependencies to the Build-Depends, so hopefully they are 
complete now.

Bug#1025806: ifeffit should move to main

[Adrian Bunk]

Package: ifeffit
Version: 2:1.2.11d-12.1
Severity: important
X-Debbugs-Cc: Roland Mas 

ifeffit (2:1.2.11d-12.1) unstable; urgency=medium
...
  * Rebuild for giza as a replacement for pgplot5.

 -- Roland Mas   Wed, 05 Oct 2022 14:22:29 +0200


After that change, ifeffit should move to main.

Bug#991650: Fix for bullseye

[Santiago Vila]

reopen 991650
found 991650 4.0.2-3
fixed 991650 4.0.2-4
thanks

Hi. I attach a proposal to fix this in bullseye. I merely applied the 
patch to the stable version and added a changelog entry (and tested that 
it works as expected).


Thanks.diff -Nru python-django-imagekit-4.0.2/debian/changelog 
python-django-imagekit-4.0.2/debian/changelog
--- python-django-imagekit-4.0.2/debian/changelog   2020-02-23 
16:33:44.0 +0100
+++ python-django-imagekit-4.0.2/debian/changelog   2022-12-09 
13:44:00.0 +0100
@@ -1,3 +1,10 @@
+python-django-imagekit (4.0.2-3+deb11u1) bullseye; urgency=medium
+
+  * Add patch to avoid triggering path traversal detection in tests
+(Closes: #991650).
+
+ -- Michael Fladischer   Fri, 09 Dec 2022 13:44:00 +0100
+
 python-django-imagekit (4.0.2-3) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru 
python-django-imagekit-4.0.2/debian/patches/0005-Set-filename-in-tests-to-avoid-path-traversal-detect.patch
 
python-django-imagekit-4.0.2/debian/patches/0005-Set-filename-in-tests-to-avoid-path-traversal-detect.patch
--- 
python-django-imagekit-4.0.2/debian/patches/0005-Set-filename-in-tests-to-avoid-path-traversal-detect.patch
 1970-01-01 01:00:00.0 +0100
+++ 
python-django-imagekit-4.0.2/debian/patches/0005-Set-filename-in-tests-to-avoid-path-traversal-detect.patch
 2022-12-09 13:42:06.0 +0100
@@ -0,0 +1,29 @@
+From: Michael Fladischer 
+Date: Sun, 31 Oct 2021 20:48:19 +
+Subject: Set filename in tests to avoid path traversal detection (Closes:
+ #991650).
+
+---
+ tests/test_sourcegroups.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/tests/test_sourcegroups.py b/tests/test_sourcegroups.py
+index c69b11f..416b964 100644
+--- a/tests/test_sourcegroups.py
 b/tests/test_sourcegroups.py
+@@ -23,7 +23,7 @@ def test_source_saved_signal():
+ source_group = ImageFieldSourceGroup(ImageModel, 'image')
+ receiver = make_counting_receiver(source_group)
+ source_saved.connect(receiver)
+-ImageModel.objects.create(image=File(get_image_file()))
++ImageModel.objects.create(image=File(get_image_file(), 
name='reference.png'))
+ eq_(receiver.count, 1)
+ 
+ 
+@@ -51,5 +51,5 @@ def test_abstract_model_signals():
+ source_group = ImageFieldSourceGroup(AbstractImageModel, 'original_image')
+ receiver = make_counting_receiver(source_group)
+ source_saved.connect(receiver)
+-ConcreteImageModel.objects.create(original_image=File(get_image_file()))
++ConcreteImageModel.objects.create(original_image=File(get_image_file(), 
name='reference.png'))
+ eq_(receiver.count, 1)
diff -Nru python-django-imagekit-4.0.2/debian/patches/series 
python-django-imagekit-4.0.2/debian/patches/series
--- python-django-imagekit-4.0.2/debian/patches/series  2020-02-23 
16:33:44.0 +0100
+++ python-django-imagekit-4.0.2/debian/patches/series  2022-12-09 
13:42:06.0 +0100
@@ -2,3 +2,4 @@
 0002-Disable-usage-of-nose-progressive-as-it-has-not-been.patch
 0003-Disable-build-status-image-to-prevent-privacy-breach.patch
 0004-Do-not-check-for-existence-if-name-is-None-Closes-95.patch
+0005-Set-filename-in-tests-to-avoid-path-traversal-detect.patch

Bug#968045: golang-gonum-v1-plot: please make the build reproducible

[Nilesh Patra]

On Thu, Dec 08, 2022 at 11:18:56AM -0800, Vagrant Cascadian wrote:
> On 2021-07-06, Nilesh Patra wrote:
> > On Mon, 01 Mar 2021 13:08:03 - "Chris Lamb"  wrote:
> >> > Thanks again, but unfortunately this patch breaks the autopkgtests :/
> >> > The only way to make it reproducible and allow testing migration would
> >> > be to disable the tests.
> >> 
> >> As I understand the problem:
> >> 
> >> * The data underneath /testdata/ has non-deterministic data (PDFs)
> >> 
> >> * The patch prevents /testdata/ from being installed in the binary
> >>   package.
> >> 
> >> * The autopkgtests fail as they require this test data.
> >
> > Yes, that is exactly what is happening
> >
> >> > What do you think would be better? Please let me know.
> >> 
> >> Interesting choice of trade-off. Would it be possible for the
> >> autopkgtests to build the test data at "autopkgtest time"?
> >
> > Probably, however this will need a few workarounds
> > Autopkgtests are triggered with the default autodep8 thing for
> > dh-make-golang,
> > So this will likely need a script followed by the normal autopkgtesting 
> > stuff
> >
> 
> >> Alternatively, do we need these PDFs? We could ship the testdata
> >> directory but not ship the .pdf files?
> >
> > Probably not.
> > The build time tests are run as autopkgtests as well, so if you remove
> > these tests, or patch these out, the effect will be same on both.
> > One of the things I'm not very fond of about the golang system :)
> >
> > Several packages keep on shipping these data just for testing purposes
> > -- nothing wrong, but lack of choice for customisation
> >
> >> The other, nicer solution could be to patch fpdf to use the
> >> SOURCE_DATE_EPOCH environment variable if it exists. This would seem
> >> quite straightforward to do, actually -- this is fpdf.go from the
> >> "golang-github-jung-kurt-gofpdf" source package:
> >> 
> >>   // returns Now() if tm is zero
> >>   func timeOrNow(tm time.Time) time.Time {
> >> if tm.IsZero() {
> >>   return time.Now()
> >> }
> >> return tm
> >>   }
> >
> > Indeed, I'll give this a shot, and see how this goes, thanks for
> > pointing this out!
> 
> I am guessing that did not turn out to be as easy as hoped?

Um, not exactly - I haven't had time for this, other packages had
higher priority and working on this bug report kept sinking down in
my TODO list, to the point I forgot about this.

> I have tested an alternate patch patch which works around the issue by
> removing only the files that embed timestamps from the testdata
> directory.
> 
> I am not sure if removing these files will affect autopkgtest or not,
> but it is worth a try!

It works OK, I have uploaded the package with your patch. Thanks!

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1025805: ruby-pgplot should move to main

[Adrian Bunk]

Package: ruby-pgplot
Version: 0.2.0-2
Severity: important
X-Debbugs-Cc: Lucas Kanashiro , Debian Ruby Extras 
Maintainers 

ruby-pgplot (0.2.0-2) unstable; urgency=medium
...
  * B-d on giza-dev instead of pgplot5 (Closes: #995922)
...
 -- Lucas Kanashiro   Thu, 04 Nov 2021 17:06:26 -0300


After that change, ruby-pgplot should move to main.