Bug#1068644: gnutls-bin: "Fatal error: The encryption algorithm is not supported" appeared with 3.8.5 upgrade

[Sanjoy Mahajan]

On 2024-04-08 18:30, Andreas Metzler  wrote:

>> It fails with "*** Fatal error: The encryption algorithm is not supported."
>
> Thank you and sorry. I have done a bisect and will try reverting the
> offending upstream commit as a hotfix.

Thank you for the quick fix.  I've just updated the packages to 3.8.5-2
and have re-tested: The connection works fine now.

-- 
-Sanjoy

Bug#1068689: urfkill dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: urfkill
Version: 0.5.0-7.1
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, urfkill
depends on both libglib2.0-0 and libglib2.0-0t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu has already fixed this issue by removing the hardcoded
dependency on libglib2.0-0.

http://launchpadlibrarian.net/720796799/urfkill_0.6.0~20150318.103828.5539c0d.1-0ubuntu10_0.6.0~20150318.103828.5539c0d.1-0ubuntu11.diff.gz

Bug#1068688: tpm2-initramfs-tool dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: tpm2-initramfs-tool
Version: 1.0.1-1
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, tpm2-initramfs-tool
depends on both libtss2-esys-3.0.2-0 and libtss2-esys-3.0.2-0t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu has already fixed this issue by replacing the hardcoded
dependency on libtss2-esys-3.0.2-0 with code in debian/rules
that generates a dependency (not sure why they didn't just
remove it).

http://launchpadlibrarian.net/720835666/tpm2-initramfs-tool_0.2.2-2build1_0.2.2-2ubuntu1.diff.gz

Bug#1068687: RFS: activities-el/0.7-1 [ITP] -- Save/restore sets of windows, tabs/frames, and their buffers in Emacs

[Xiyue Deng]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "activities-el":

 * Package name : activities-el
   Version  : 0.7-1
   Upstream contact : Adam Porter 
 * URL  : https://github.com/alphapapa/activities.el
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/emacsen-team/activities-el
   Section  : editors

The source builds the following binary packages:

  elpa-activities - Save/restore sets of windows, tabs/frames, and their 
buffers in Emacs

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/activities-el/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/a/activities-el/activities-el_0.7-1.dsc

Changes for the initial release:

 activities-el (0.7-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1068677).

Regards,
-- 
Xiyue Deng

Bug#1068686: xserver-xorg-input-wacom: Can't switch from "All Displays" on Intuos BT to one display

[Adam Glenn]

Package: xserver-xorg-input-wacom
Version: 1.2.1-1
Severity: important
X-Debbugs-Cc: gekit...@gmail.com

Dear Maintainer,

   * What led up to the situation? Connected my Intuos bluetooth tablet to my
computer the pen works fine but the tablet is mapped to both of my monitors.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? When I go into  "Wacom Tablet" in Gnome Settings I can see
the option for "All Displays" or each of the monitors but when I change the
dropdown the tablet stays mapped to both montors. If I change the drop down and
leave the app then come back it will say "All Displays" again.
   * What was the outcome of this action? No change
   * What outcome did you expect instead? I expected it to map to a single
monitor


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

Kernel: Linux 6.7.9-amd64 (SMP w/16 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.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xserver-xorg-input-wacom depends on:
ii  libc6  2.37-15.1
ii  libudev1   255.4-1+b1
ii  libx11-6   2:1.8.7-1
ii  libxi6 2:1.8.1-1
ii  libxinerama1   2:1.1.4-3
ii  libxrandr2 2:1.5.4-1
ii  xserver-xorg-core [xorg-input-abi-24]  2:21.1.11-3

xserver-xorg-input-wacom recommends no packages.

Versions of packages xserver-xorg-input-wacom suggests:
pn  xinput  

-- no debconf information

Bug#1068677: Acknowledgement (ITP: emacs-activities -- Save/restore sets of windows, tabs/frames, and their buffers in Emacs)

[Xiyue Deng]

Control: retitle -1 ITP: activities-el -- Save/restore sets of windows, 
tabs/frames, and their buffers in Emacs

Rename the source package following team recommendations[1].
-- 
Xiyue Deng

[1] https://wiki.debian.org/Teams/DebianEmacsenTeam

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Guillem Jover]

Hi!

On Mon, 2024-03-11 at 01:44:30 +0100, Nicolas Boulenguez wrote:
> Package: dpkg-dev
> Followup-For: Bug #872381

> Please consider this new patch queue instead of the old or untested
> ones.  With this one applied on 279c6ccb, the package builds and
> passes all tests.

Thanks!

> * scripts/mk: only use ASCII characters
>   Cosmetic independent suggestion.

I'll skip this one, these are in comments are UTF-8 should be safe to
use.

> * scripts/mk: protect files against double inclusion
>   The variables are renamed as you have recommended.
>   The test is fixed (ifdef fails on a defined but empty variable).

Merged, although I've renamed the variables to avoid the slashes and
«.», as even though permitted by make, can be rather surprising and
have unintended consequences if they need to be passed to a shell
(unlikely here but…). And they hardcode a pathname that might not
match the actual destination of these files in the system (which can
be rather confusing).

> * scripts/mk: stop hard-coding dpkg_datadir
>   Already discussed.

I've still skipped this for now, while I think I like it, see my
previous reply, as there's still the possibility we might need to
replace other stuff, such as SED anyway.

> * scripts/mk/buildopts.mk: search once for parallel= in DEB_BUILD_OPTIONS
> 
> > > [...DEB_BUILD_OPTION_PARALLEL empty instead of undefined
> > > when parallel= is missing...]
> > [kind of an API change].
> 
> I have changed my patch and updated the comment.

Merged.

> However..
> The policy only describes 'parallel=N' when N is a positive integer.
> I think we should assume that the option is either missing or valid.
> For me, 'parallel=' is as incorrect as 'parallel=foo'.

Right, but I'm not sure whether there's anything now relying on this,
which could break. :/

> > I think it might perhaps make more sense to fallback to setting it
> > to 1 if it's missing, but I need to ponder about possible
> > consequences/fallout, etc.
> 
> I doubt any sensible default exist.
> * 1 is safe/produces readable logs and $max_available_processors is fast.
> * the policy/debhelper/... have found no one-size-fits-all solution.

Sure, let's leave this for now, it can always be revisited later on.

> * scripts/buildflags.mk: add missing GCJFLAGS
>   Fixes a bug.

This was removed with commit 19dccf2b43d07ee0cb62ac002658768dce0b33aa,
due to the gcj project being dead since 2018.

> * scripts/buildflags.mk: generate the _FOR_BUILD variant of each variable

Merged.

> * scripts/buildflags.mk: sort the flag list
>   These changes hopefully prevent new missing flags in the future (the
>   output of dpkg-buildflags is sorted).

While in general I also prefer sorted lists, these currently try to
match the order in the toolchain stack, which also matches the order
in the manual page and other perl modules. I'll skip this for now.

> * scripts/*.mk: reduce the number of subprocesses

I've skipped this for now, see previous discussion about sed usage.

> * scripts/t: use loops instead of repetitions, check exports and overrides

Could you split this into one commit for the loop switch, and another
for the new tests? Also I think the later commit to handle spaces
should be folded into the loop splitting and new tests additions.

>   * all four combinations of existing/new scripts/mk/*.mk pass the
> existing/new tests in scripts/t/mk/*.mk.
>   * comparing the time taken by tests gives a rough idea of the speed
> gain
> architecture.mk 30 times faster (probably no gain under dpkg-buildpackage)
> buildflags.mk   20 times faster
> pkg-info.mk  4 times faster
> buildtools.mk20% faster
> 
> Guillem Jover
> > I've left this one out for now. I'm not entirely satisfied with the
> > sed usage here. If we keep using sed, then I think it needs to be
> > set via a SED variable, substituted from the value found at
> 
> In which context do you expect GNU Make but a non recent sed?
> Should I rewrite the regular expressions without -r/-E?

BSD systems come to mind, where GNU sed might be called gsed for
example, or not present at all. And where GNU make might be called
gmake. But the proper name is detected at configure time, so if we are
using sed then we should use the detected one.

> > configure time. But then, I've been pondering whether we can have
> > better export formats, that might make the sed usage not
> > necessary. I started with a make-eval export mode for buildflags,
> > but perhaps it would be better a more generic formatting mode where
> > the caller can specify how the output should look like, akin
> > «dpkg-query --showformat». Will ponder about this.
> 
> A generic format would be more maintainable in the long term.
> Something like that would be convenient for the makefiles.
> 
> dpkg-architecture --print-format='${Dollar}(eval export ${key} ?= ${value})'
> dpkg-buildflags --print-format='${Dollar}(eval ${key}:=${value})'
> dpkg-parsechangelog --print-format='${Dollar}(eval 

Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: Bug#1068559: Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)

[陈 晟祺]

Hi,

> 2024年4月9日 02:51，Paul Gevers  写道：
> 
> Our timeout is 1 seconds, so 2.47 hours, per autopkgtest stanza (overall 
> it's 8 hours). If the test is going to take longer, it will fail anyways. So 
> maybe it was just still running? I'm a bit hesitant, particularly about the 
> memory to make much bigger VM's, because most tests don't need it and it 
> limits the amount of VM's we can make. We need to strike a nice balance (or 
> fix https://salsa.debian.org/ci-team/debci/-/issues/166#note_451831 and add 
> zfs-linux to a "huge" list)
> 

I totally understand your consideration. I think it would be great if we could 
specify more detailed resource requirements on test metadata (thus not wasting 
resources on small tests).

> 
> Well, if we can't run the test on our infra, we could disable it, but what's 
> the point of having the autopkgtest then? (If you split the tests over 
> multiple stanza, you get the 2.47 hour per set. Does that help?)
> 

It might help. For upstream test on GitHub Actions, it is actually split into 
four parts [1], each taking ~1hr. I can (and plan to) integrate that into debt 
tests.

> Let me try to see if I can have debci create larger VM's for us and let me 
> try your package again. What are the resources you use yourself for the test 
> and how long does it take in that case?
> 

My testing resources are maybe not that representative (20 cores + 32GB 
memory), it takes about the same time (3hr40min) as upstream configuration (4 
cores + 7GB).
I will try with fewer resources recently and give you more information.

[1]: 
https://github.com/openzfs/zfs/blob/master/.github/workflows/scripts/setup-functional.sh

--
Thanks,
Shengqi Chen

Bug#1068685: tup: FTBFS on loong64

[zhangdandan]

Source: tup
Version: 0.7.11-4
Severity: wishlist
Tags: ftbfs patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the tup failed for loong64 in the Debian Package Auto-Building 
environment.

The error log is as follows,
```
../src/tup/platform.c:70:2: error: #error Unsupported cpu architecture. 
Please add support in tup/platform.c
   70 | #error Unsupported cpu architecture. Please add support in 
tup/platform.c

  |  ^
make[1]: *** [debian/rules:17: override_dh_auto_build] Error 1
```
The Full log can be found at 
https://buildd.debian.org/status/logs.php?pkg=tup=0.7.11-4=loong64.


I have added support for loongarch64 in tup package.
Please consider the patch I attached.
Your opinions are welcome.

Thanks,
Dandan Zhang

Description: Add support for LoongArch. 
Last-Update: 2024-04-09

--- tup-0.7.11.orig/src/tup/platform.c
+++ tup-0.7.11/src/tup/platform.c
@@ -66,6 +66,10 @@ const char *tup_arch = "hppa";
 const char *tup_arch = "riscv64";
 #elif (__riscv || __riscv__) && __riscv_xlen == 32
 const char *tup_arch = "riscv32";
+#elif __loongarch__ && __loongarch_grlen == 32
+const char *tup_arch = "loongarch32";
+#elif __loongarch__ && __loongarch_grlen == 64
+const char *tup_arch = "loongarch64";
 #else
 #error Unsupported cpu architecture. Please add support in tup/platform.c
 #endif
--- tup-0.7.11.orig/tup.1
+++ tup-0.7.11/tup.1
@@ -765,7 +765,7 @@ In this case, the @-variable "FOO" is ex
 TUP_PLATFORM is a special @-variable. If CONFIG_TUP_PLATFORM is not set in the tup.config file, it has a default value according to the platform that tup itself was compiled in. Currently the default value is one of "linux", "solaris", "macosx", "win32", "freebsd" or "netbsd".
 .TP
 .B @(TUP_ARCH)
-TUP_ARCH is another special @-variable. If CONFIG_TUP_ARCH is not set in the tup.config file, it has a default value according to the processor architecture that tup itself was compiled in. Currently the default value is one of "i386", "x86_64", "powerpc", "powerpc64", "ia64", "alpha", "sparc", "arm64", or "arm".
+TUP_ARCH is another special @-variable. If CONFIG_TUP_ARCH is not set in the tup.config file, it has a default value according to the processor architecture that tup itself was compiled in. Currently the default value is one of "i386", "x86_64", "powerpc", "powerpc64", "ia64", "alpha", "sparc", "loongarch32", "loongarch64", "arm64", or "arm".
 
 .SH "VARIANTS"
 Tup supports variants, which allow you to build your project multiple times with different configurations. Perhaps the most common case is to build a release and a debug configuration with different compiler flags, though any number of variants can be used to support whatever configurations you like. Each variant is built in its own directory distinct from each other and from the source tree. When building with variants, the in-tree build is disabled. To create a variant, make a new directory at the top of the tup hierarchy and create a "tup.config" file there. For example:

Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates

[Xiyue Deng]

Hi Nicholas,

Nicholas D Steeves  writes:

> Nicholas D Steeves  writes:
>
>> This package cannot be uploaded without a human Uploader.  See #1019031
>> and current git history for more info.  Either
>>
>> 1. Add yourself to Uploaders
>
> Yes, this requires a changelog entry too, in case that wasn't obvious.
>

Thanks for pointing out #1019031!  Totally missed it.  I'll opt for
option 1 obviously.  Updated team repo and mentors accordingly.

Also, accordingly to this comment from Tobias[1] it looks like there are
opinions that prefer to reuse existing RFS bugs instead of filing new
ones.  Do you think it's OK to reopen this one?

-- 
Xiyue Deng

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067127#15


signature.asc
Description: PGP signature

Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

[Dirk Eddelbuettel]

On 8 April 2024 at 18:21, Lucas Thode wrote:
| Apologies for the confusion, I didn't realize the patch in question was a new
| addition.  Just confirmed that it errors out instead of segfaulting or 
hanging.

Thanks for confirming!

Dirk
 
| On Sat, Apr 6, 2024 at 5:32 PM Dirk Eddelbuettel  wrote:
| 
| 
| Hi Lucas,
| 
| As Milan suggested, please sure you are current.  If in doubt, park you
| current checkout and start from
| 
|     git checkout https://github.com/eddelbuettel/dieharder.git
| 
| where you should see today's commit from merging PR 24.
| 
|     edd@rob:~/git/dieharder(master)$ git ls | head
|     *   3442896 - (HEAD -> master, origin/master, origin/HEAD) Merge pull
| request #24 from mbroz/dab-monobit2-ntup (10 hours ago) 
|     |\ 
|     | * d928cbf - Avoid overflow in DAB Monobit2 test. (10 hours ago)
| 
|     |/ 
|     *   2d4763a - Merge pull request #22 from mbroz/master (6 weeks ago)
| 
|     |\ 
|     | * 67989b4 - Do not report file input rewind if nothing was read
| repeatedly. (6 weeks ago) 
|     |/ 
|     * c987a15 - Fix segfault for wrongly specified test on commandline. (#
| 21) (9 weeks ago) 
|     *   a186d90 - Merge pull request #20 from mbroz/warning-fixes (2 
months
| ago) 
|     edd@rob:~/git/dieharder(master)$
| 
| Do not rely on the Debian package, it has not been updated yet.
| 
| Cheers, Dirk
| 
| --
| dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| 
| 

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1068684: bornagain: FTBFS on many architectures

[Bo YU]

Source: bornagain
Version: 21.1+ds3-4
Severity: serious
Tags: ftbfs

Dear Maintainer,

Recently upload did not fixed ftbfs on many architectures, see:
https://buildd.debian.org/status/package.php?p=bornagain


Tests failed on arm64, ppc64el, riscv64 and s390x. Build issue on
arm{el,hf} and i386.


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1068683: zmat: FTBFS: ar: blosc2/blosc/*.o: No such file or directory

[Bo YU]

Source: zmat
Version: 0.9.9+ds.1-2
Severity: serious
Tags: ftbfs

Dear Maintainer,

The package has ftbfs issue but on amd64 and i386, the common issue is
follows:

```
CC obj/conf_91c451f6ae5e059804729dd256611361/static/cover.o
CC obj/conf_91c451f6ae5e059804729dd256611361/static/divsufsort.o
CC obj/conf_91c451f6ae5e059804729dd256611361/static/fastcover.o
CC obj/conf_91c451f6ae5e059804729dd256611361/static/zdict.o
compiling single-threaded static library 1.5.5
make[4]: Leaving directory '/<>/src/blosc2/internal-complibs/zstd'
make[3]: Leaving directory '/<>/src/blosc2'
Building ../lib/libzmat.a
ar cr -o ../lib/libzmat.a zmatlib.o miniz/miniz.o easylzma/compress.o 
easylzma/decompress.o easylzma/lzma_header.o easylzma/lzip_header.o 
easylzma/common_internal.o easylzma/pavlov/LzmaEnc.o easylzma/pavlov/LzmaDec.o 
easylzma/pavlov/LzmaLib.o easylzma/pavlov/LzFind.o easylzma/pavlov/Bra.o 
easylzma/pavlov/BraIA64.o easylzma/pavlov/Alloc.o easylzma/pavlov/7zCrc.o 
blosc2/blosc/*.o blosc2/internal-complibs/zstd/obj/*/static/*.o 
ar: blosc2/blosc/*.o: No such file or directory
make[2]: *** [makefile:194: ../lib/libzmat.a] Error 1
make[2]: Leaving directory '/<>/src'
make[1]: *** [debian/rules:21: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: binary-arch] Error 2

...
```

See 
https://buildd.debian.org/status/fetch.php?pkg=zmat=arm64=0.9.9%2Bds.1-2=1712139942=0
and 
https://buildd.debian.org/status/fetch.php?pkg=zmat=riscv64=0.9.9%2Bds.1-2=1712403175=0


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1068682: dunst: Please package the new release 1.10.0

[Boyuan Yang]

Source: dunst
Version: 1.9.2-1
Severity: normal
Tags: sid trixie

Debian Debian dunst package maintainer,

The dunst upstream has released a new version 1.10.0.
Please consider packaging it in Debian.

Thanks,
Boyuan Yang


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

Bug#1054680: newsboat: FTBFS: test/cliargsparser.cpp:1:10: fatal error: 3rd-party/catch.hpp: No such file or directory

[Boyuan Yang]

Control: forwarded -1 https://github.com/newsboat/newsboat/issues/2716

On Fri, 27 Oct 2023 21:15:28 +0200 Lucas Nussbaum 
wrote:
> Source: newsboat
> Version: 2.32-3
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231027 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > g++ -std=c++11 -O2 -ggdb -Iinclude -Istfl -Ifilter -I. -Irss -
I/<>/target/cxxbridge/ -Werror -Wall -Wextra -Wunreachable-
code -DLOCALEDIR='"/usr/local/share/locale"' -I/usr/include/x86_64-linux-
gnu  -I/usr/include/libxml2  -I/usr/include/json-c  -D_DEFAULT_SOURCE -
D_XOPEN_SOURCE=600  -g -O2 -ffile-prefix-map=/<>=. -fstack-
protector-strong -fstack-clash-protection -Wformat -Werror=format-
security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MP -MF
.deps/test/controller.cpp -o test/controller.o -c test/controller.cpp
> > test/cliargsparser.cpp:1:10: fatal error: 3rd-party/catch.hpp: No
such file or directory
> > 1 | #include "3rd-party/catch.hpp"
> >   |  ^
> > compilation terminated.


This is caused by Debian's catch2 upgrading to v3.x. While newsboat
upstream is working on catch2 3.x support, a quickfix is to disable
the ln -sf lines in debian/rules and use the embedded catch2 2.x
headers.

Thanks,
Boyuan Yang


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

Bug#1068629: testng7 backport for bullseye needed for latest Java LTS releases

[Vladimir Petko]

Hi,

I have realized that I have not submitted the bug report for this
issue, so the decision to try vendoring dependencies for JTREG is not
visible anywhere.

Starting from the April OpenJDK release, JTREG 7.3 will be used for
openjdk-11 and up, which will require having it in Buster and up.

In Ubuntu, the January OpenJDK update used the vendored version, and
we have not found any test regression issues caused by it.

I have an MR open[1] that does not update the source tree and a
branch[2] with imported sources.

Best Regards,
 Vladimir.

[1] https://salsa.debian.org/java-team/jtreg7/-/merge_requests/1
[2] 
https://salsa.debian.org/vpa1977/jtreg7/-/tree/jtreg_with_sources?ref_type=heads

On Sun, Oct 22, 2023 at 10:01 AM Emmanuel Bourg  wrote:
>
> Le 21/10/2023 à 20:55, tony mancill a écrit :
>
> > My secondary concern is how we would respond to CVEs in the vendored
> > components.  We can debate whether the attack surface area in a tool
> > like jtreg warrants patching the vendored components, but as a general
> > principle, that's why we avoid vendoring in the first place.
> >
> > But if vendoring is acceptable in some circumstances,  I can imagine
> > cases where it helps with bootstrapping too, but that's probably a topic
> > for a different thread.
> >
> > In any event, I'm glad that we're having the discussion and that the
> > Security Team has taken a look.  Let's see how it goes with jtreg7.
>
> jtreg is only used to run the openjdk tests, that's not a security
> sensitive package, so embedding the package isn't a concern.
>
> Emmanuel Bourg
>

Bug#1068681: kquickcharts: Make the tests non-fatal on loong64

[zhangdandan]

Source: kquickcharts
Version: 5.107.0-1
Severity: wishlist
Tags: ftbfs patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the kquickcharts package failed for loong64 in the Debian 
Package Auto-Building environment, the error log is as follows:

```
..
The following tests FAILED:
      5 - tst_BarChart.qml (Subprocess aborted)
      6 - tst_LineChart.qml (Subprocess aborted)
      7 - tst_PieChart.qml (Subprocess aborted)
Errors while running CTest
```

The full build log can be found at 
https://buildd.debian.org/status/logs.php?pkg=kquickcharts=5.107.0-1%2Bb1=loong64.


There is no architecture-related code in the kquickcharts source code.
Refer to the processing methods of other architectures, could you set 
the tests non-fatal on loong64?

Please consider the patch I have attached.
Your opinions are welcome.

Thanks,
Dandan Zhang

diff -Nru kquickcharts-5.107.0/debian/rules kquickcharts-5.107.0/debian/rules
--- kquickcharts-5.107.0/debian/rules   2023-03-16 21:42:02.0 +
+++ kquickcharts-5.107.0/debian/rules   2023-06-18 14:08:49.0 +
@@ -5,7 +5,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
-testsuite_failing_archs := alpha hppa hurd-i386 mips64el powerpc riscv64 x32
+testsuite_failing_archs := alpha hppa hurd-i386 loong64 mips64el powerpc 
riscv64 x32
 ifneq (,$(filter $(DEB_HOST_ARCH),$(testsuite_failing_archs)))
   fail_param := || true
 endif

Bug#1068633: bookworm-pu: package cjson/1.7.15-1+deb12u1

[Maytham Alsudany]

Hi Salvatore,

On Mon, 2024-04-08 at 21:13 +0200, Salvatore Bonaccorso wrote:
> > diff -Nru cjson-1.7.15/debian/changelog cjson-1.7.15/debian/changelog
> > --- cjson-1.7.15/debian/changelog   2021-08-29 23:30:06.0 +0300
> > +++ cjson-1.7.15/debian/changelog   2024-04-03 06:57:10.0 +0300
> > @@ -1,3 +1,13 @@
> > +cjson (1.7.15-1+deb12u1) bookworm-security; urgency=medium
> 
> The target distribution should be simply bookworm.

I had already changed that but forgot to update the debdiff :)

> > +
> > +  * Update Maintainer field
> > +  * Bump Standards-Version to 4.6.2 (no changes)
> 
> This is usually not allowed to do in a stable update.
> 
> > +  * Backport patch to add NULL checkings (CVE-2023-50472, CVE-2023-50471)
> > +(Closes: #1059287)
> > +  * Add Build-Depends-Package to symbols
> 
> While this might be sensible, I'm not sure if SRM will accept it.
> 
> So you might want to adjust already the things above and seek for an
> ack from SRM.

Thank you for your feedback, attached is a revised debdiff.

Kind regards,
Maytham

diff -Nru cjson-1.7.15/debian/changelog cjson-1.7.15/debian/changelog
--- cjson-1.7.15/debian/changelog	2021-08-29 23:30:06.0 +0300
+++ cjson-1.7.15/debian/changelog	2024-04-09 04:30:29.0 +0300
@@ -1,3 +1,11 @@
+cjson (1.7.15-1+deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport patch to add NULL checkings (CVE-2023-50472, CVE-2023-50471)
+(Closes: #1059287)
+
+ -- Maytham Alsudany   Tue, 09 Apr 2024 04:30:29 +0300
+
 cjson (1.7.15-1) unstable; urgency=medium
 
   * New upstream release 1.7.15.
diff -Nru cjson-1.7.15/debian/gbp.conf cjson-1.7.15/debian/gbp.conf
--- cjson-1.7.15/debian/gbp.conf	1970-01-01 03:00:00.0 +0300
+++ cjson-1.7.15/debian/gbp.conf	2024-04-09 04:29:47.0 +0300
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = debian/bookworm
diff -Nru cjson-1.7.15/debian/patches/0001-add-null-checkings.patch cjson-1.7.15/debian/patches/0001-add-null-checkings.patch
--- cjson-1.7.15/debian/patches/0001-add-null-checkings.patch	1970-01-01 03:00:00.0 +0300
+++ cjson-1.7.15/debian/patches/0001-add-null-checkings.patch	2024-04-09 04:29:47.0 +0300
@@ -0,0 +1,101 @@
+Origin: backport, https://github.com/DaveGamble/cJSON/commit/60ff122ef5862d04b39b150541459e7f5e35add8
+From: Peter Alfred Lee 
+Bug: https://github.com/DaveGamble/cJSON/issues/803
+Bug: https://github.com/DaveGamble/cJSON/issues/802
+Bug-Debian: https://bugs.debian.org/1059287
+Acked-by: Maytham Alsudany 
+Subject: [PATCH] add NULL checkings (#809)
+ * add NULL checks in cJSON_SetValuestring
+ Fixes #803(CVE-2023-50472)
+ .
+ * add NULL check in cJSON_InsertItemInArray
+ Fixes #802(CVE-2023-50471)
+ .
+ * add tests for NULL checks
+ add tests for NULL checks in cJSON_InsertItemInArray and cJSON_SetValuestring
+
+--- a/cJSON.c
 b/cJSON.c
+@@ -401,7 +401,12 @@
+ {
+ char *copy = NULL;
+ /* if object's type is not cJSON_String or is cJSON_IsReference, it should not set valuestring */
+-if (!(object->type & cJSON_String) || (object->type & cJSON_IsReference))
++if ((object == NULL) || !(object->type & cJSON_String) || (object->type & cJSON_IsReference))
++{
++return NULL;
++}
++/* return NULL if the object is corrupted */
++if (object->valuestring == NULL)
+ {
+ return NULL;
+ }
+@@ -2260,7 +2265,7 @@
+ {
+ cJSON *after_inserted = NULL;
+ 
+-if (which < 0)
++if (which < 0 || newitem == NULL)
+ {
+ return false;
+ }
+@@ -2271,6 +2276,11 @@
+ return add_item_to_array(array, newitem);
+ }
+ 
++if (after_inserted != array->child && newitem->prev == NULL) {
++/* return false if after_inserted is a corrupted array item */
++return false;
++}
++
+ newitem->next = after_inserted;
+ newitem->prev = after_inserted->prev;
+ after_inserted->prev = newitem;
+--- a/tests/misc_tests.c
 b/tests/misc_tests.c
+@@ -353,6 +353,19 @@
+ {
+ char buffer[10];
+ cJSON *item = cJSON_CreateString("item");
++cJSON *array = cJSON_CreateArray();
++cJSON *item1 = cJSON_CreateString("item1");
++cJSON *item2 = cJSON_CreateString("corrupted array item3");
++cJSON *corruptedString = cJSON_CreateString("corrupted");
++struct cJSON *originalPrev;
++
++add_item_to_array(array, item1);
++add_item_to_array(array, item2);
++
++originalPrev = item2->prev;
++item2->prev = NULL;
++free(corruptedString->valuestring);
++corruptedString->valuestring = NULL;
+ 
+ cJSON_InitHooks(NULL);
+ TEST_ASSERT_NULL(cJSON_Parse(NULL));
+@@ -412,6 +425,8 @@
+ cJSON_DeleteItemFromObject(item, NULL);
+ cJSON_DeleteItemFromObjectCaseSensitive(NULL, "item");
+ cJSON_DeleteItemFromObjectCaseSensitive(item, NULL);
++TEST_ASSERT_FALSE(cJSON_InsertItemInArray(array, 0, NULL));
++TEST_ASSERT_FALSE(cJSON_InsertItemInArray(array, 1, item));
+ 

Bug#1068483: Bug#882511: dpkg-buildpackage: should allow caller to force inclusion of source in buildinfo

[Guillem Jover]

Control: forcemerge 882511 1068483

Hi!

After replying to Adrian's report, I recalled there being a previous one
that was similar, and then recalled that I had an even older branch that
implemented a potential solution for this. See below.

On Thu, 2017-11-23 at 16:23:29 +0100, Ximin Luo wrote:
> Package: dpkg-dev
> Version: 1.19.0.4
> Severity: wishlist
> Tags: patch

> dpkg-buildpackage currently does not automatically list the source .dsc nor
> its hash in the call to dpkg-genbuildinfo when doing a binary-only build. This
> is understandable because in a binary-only build, dpkg-buildpackage does not
> have any concept of a source package and therefore does not know (and cannot
> verify) if the working tree was actually generated from any .dsc or not.
> 
> However, the caller knows this information, and it is useful for reproducible
> builds to track exactly which (i.e. hash-wise) source code generates which
> binary packages. So it should be possible for the caller to tell
> dpkg-buildpackage, "yes please do include the .dsc hash in the buildinfo, I am
> telling you it is correct, you can assume this safely".
> 
> Tools like sbuild/pbuilder could then do this, as well as users or rebuilders.
> 
> The attached patch implements this in the simplest way possible. It allows the
> caller to run something like:
> 
>   $ dpkg-buildpackage --no-sign -b --buildinfo-option=--build=full
> 
> The resulting $pkg_$ver_$arch.buildinfo then contains the .dsc and its hash.
> 
> However this requires the caller to know which option to pass, which would 
> either be
> 
>   --buildinfo-option=--build=full
>   --buildinfo-option=--build=any,source
>   --buildinfo-option=--build=all,source
> 
> depending on whether the original build request (to dpkg-buildpackage) was a 
> -b, -B, or -A.
> 
> For this reason, it may be better (more usable) to add a 
> --force-source-in-buildinfo
> flag (or similar name) and when this is switched on, do this instead:
> 
> -push @buildinfo_opts, "--build=$build_types" if 
> build_has_none(BUILD_DEFAULT);
> +push @buildinfo_opts, "--build=$build_types,source" if 
> build_has_none(BUILD_DEFAULT);
> 
> Let me know if you like this idea and I'll be happy to implement that instead 
> of
> the attached patch.

The problem with this solution is that it is prone do accidental use,
as it is very easy for a user to unknowingly have recreated the sources
from a locally extracted tree (be that modified or not).

On Sat, 2024-04-06 at 02:57:40 +0200, Guillem Jover wrote:
> On Sat, 2024-04-06 at 02:56:02 +0300, Adrian Bunk wrote:
> > Package: dpkg-dev
> > Version: 1.22.6
> > Severity: normal
> > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> > A thought I already wrote in a recent debian-devel discussion:
> > 
> > In theory source package filenames should be eternally and globally
> > unique, but in practice there are cornercases where this assumption
> > might break like for example:
> > - *stable-security does not currently have a copy of the sources
> >   in the main archive, one always have to upload the source archive
> >   there and this might accidentally be a different orig.tar
> > - dak does not keep an eternal history of everything it ever knew,
> >   e.g. RM and later re-NEW of a source version might have a different
> >   source .orig.tar or even different sources for a Debian revision
> > - Debian and Ubuntu might have different orig.tar for the same version,
> >   if Ubuntu updated a package before Debian did, or with packages
> >   were development is completely independent in Debian and Ubuntu
> >   (e.g. OpenStack, KDE)
> > 
> > The reason for different files might be as trivial as "git archive"
> > not always producing the same output when running in different
> > environments, e.g. the autogenerated tarball for a git tag on Github
> > might have different checksums depending on whether it is downloaded
> > today or next year despite identical contents due to slightly
> > different gzip compression.
> > 
> > Should buildinfo files contain the hashes of the source package,
> > to clearly define what sources have been used?
> 
> Ideally? Yes, and I think we considered that at the time when we
> introduced the .buildinfo files. Although a ref to the .dsc does get
> included if the build is also creating the source package.
> 
> The problem is that when dpkg-buildpackage is not building the source
> package, there is no guarantee the source package is going to be
> present, or that if it is present it matches what is currently being
> built from the working directory.

I've now finished the change I had in that branch, which implements
support so that dpkg-buildpackage can be passed a .dsc or a source-dir,
and in the former will first extract it, and for both then it will
change directory to the source tree. If it got passed a .dsc then it
will instruct dpkg-genbuildinfo to include a ref to it.

Which I think accomplishes the requested behavior in a safe way? I've
attached 

Bug#1068680: din: Process 166294 (din) of user 1000 dumped core

[Cláudio Brandão]

Package: din
Version: 56-1
Severity: important
X-Debbugs-Cc: crau...@disroot.org

Dear Maintainer,

This is a crash dump of the Linux kernel, indicating that process 166294
(identified by its PID) has crashed and dumped its memory contents to disk for
analysis. The crash occurred in the module libzstd.so.1, which is part of the
zstandard compression library.

The stack traces provided show the sequence of function calls leading up to the
crash. It appears that the crash occurred in the epoll_wait function, which is
part of the Linux kernel's I/O multiplexing API. The stack traces also indicate
that other threads were running at the time of the crash, with each thread
listed having its own unique stack trace.

The modules listed as being involved in the crash are:

libzstd.so.1: The zstandard compression library.
libsystemd.so.0: Part of the systemd initialization system.
libc.so.6: The C standard library.
libspa-support.so: Support library for SPA (Simple Price Action) protocol.
libpipewire-0.3.so.0: Library for PipeWire, a low-latency audio server.

It's difficult to determine the exact cause of the crash without additional
information or context. However, based on the involvement of the epoll_wait
function and the presence of libraries related to audio processing, it's
possible that the crash was caused by an issue with the audio subsystem or a
problem with how the application was using the zstandard compression library.

Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Module libsystemd.so.0 from deb systemd-252.22-1~deb12u1.amd64
Stack trace of thread 166294:
#0  0x5617dbae42ab n/a (din + 0xc02ab)
#1  0x5617dbae4a75 n/a (din + 0xc0a75)
#2  0x5617dba8c2e4 n/a (din + 0x682e4)
#3  0x5617dbb73b55 n/a (din + 0x14fb55)
#4  0x5617dbb8aab0 n/a (din + 0x166ab0)
#5  0x5617dba5a15b main (din + 0x3615b)
#6  0x7fb191f6724a n/a (libc.so.6 + 0x2724a)
#7  0x7fb191f67305 __libc_start_main (libc.so.6 + 0x27305)
#8  0x5617dba5b1d1 n/a (din + 0x371d1)

Stack trace of thread 166306:
#0  0x7fb192048e26 epoll_wait (libc.so.6 + 0x108e26)
#1  0x7fb190c34110 n/a (libspa-support.so + 0x17110)
#2  0x7fb190c25d4b n/a (libspa-support.so + 0x8d4b)
#3  0x7fb191ab8b4a n/a (libpipewire-0.3.so.0 + 0xa5b4a)
#4  0x7fb191fc9134 n/a (libc.so.6 + 0x89134)
#5  0x7fb1920497dc n/a (libc.so.6 + 0x1097dc)

Stack trace of thread 166309:
#0  0x7fb192048e26 epoll_wait (libc.so.6 + 0x108e26)
#1  0x7fb190c34110 n/a (libspa-support.so + 0x17110)
#2  0x7fb190c25d4b n/a (libspa-support.so + 0x8d4b)
#3  0x7fb191a5b03c n/a (libpipewire-0.3.so.0 + 0x4803c)
#4  0x7fb191fc9134 n/a (libc.so.6 + 0x89134)
#5  0x7fb1920497dc n/a (libc.so.6 + 0x1097dc)

Stack trace of thread 166323:
#0  0x7fb192048e26 epoll_wait (libc.so.6 + 0x108e26)
#1  0x7fb190c34110 n/a (libspa-support.so + 0x17110)
#2  0x7fb190c25d4b n/a (libspa-support.so + 0x8d4b)
#3  0x7fb191a5b03c n/a (libpipewire-0.3.so.0 + 0x4803c)
#4  0x7fb191fc9134 n/a (libc.so.6 + 0x89134)
#5  0x7fb1920497dc n/a (libc.so.6 + 0x1097dc)

Stack trace of thread 166308:
#0  0x7fb192048e26 epoll_wait (libc.so.6 + 0x108e26)
#1  0x7fb190c34110 n/a (libspa-support.so + 0x17110)
#2  0x7fb190c25d4b n/a (libspa-support.so + 0x8d4b)
#3  0x7fb191ab8b4a n/a (libpipewire-0.3.so.0 + 0xa5b4a)
#4  0x7fb191fc9134 n/a (libc.so.6 + 0x89134)
#5  0x7fb1920497dc n/a (libc.so.6 + 0x1097dc)
ELF object binary architecture: AMD x86-64


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

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

Versions of packages din depends on:
ii  din-data 56-1
ii  jackd5+nmu1
ii  libc62.36-9+deb12u4
ii  libgcc-s114-20240201-3
ii  libgl1   1.6.0-1
ii  librtaudio6  5.2.0~ds1-2
ii  librtmidi6   5.0.0-3
ii  libsdl1.2debian  1.2.15+dfsg2-8
ii  libstdc++6   14-20240201-3
ii  libtcl8.68.6.13+dfsg-2

din recommends no packages.

din suggests no packages.

-- no debconf information

Bug#1068678: nftables: on sysvinit the init script does not start nftables at boot

[Davide Baldini]

Correction: the modified init script runs properly at boot if the 
"Default-Start" LSB tag is set to "2 3 4 5", not to "1 2 3".

Bug#1068679: port-to-libsoup3.patch looks bad

[Steve Langasek]

Package: libtimezonemap
Version: 0.4.6-6
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Hello,

This is a follow-up to bug #1037940 which is now archived.

With the move of webkit2gtk to libsoup3, this now becomes non-negotiable for
us in Ubuntu, as ubiquity requires both webkit and libtimezonemap.

I have taken a stab at fixing this patch up based on the feedback in the
other bug and have something that passes libtimezonemap's own build-time
tests, and ubiquity's tests, though it's hard to tell how much the latter
actually matters for verifying libtimezonemap correctness due to mocking.

Please consider this for inclusion in Debian as well.

Thanks,
-- 
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 libtimezonemap-0.4.6/debian/control 
libtimezonemap-0.4.6/debian/control
--- libtimezonemap-0.4.6/debian/control 2024-03-07 21:30:43.0 -0800
+++ libtimezonemap-0.4.6/debian/control 2024-04-08 16:33:09.0 -0700
@@ -1,8 +1,7 @@
 Source: libtimezonemap
 Section: misc
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Cinnamon Team 

+Maintainer: Debian Cinnamon Team 
 Uploaders:
  Maximiliano Curia ,
  Margarita Manterola ,
@@ -20,7 +19,7 @@
libgtk-3-dev (>= 3.1.4),
libcairo2-dev (>= 1.10),
libjson-glib-dev,
-   libsoup2.4-dev
+   libsoup-3.0-dev (>= 3.0.7)
 Standards-Version: 4.6.2
 Homepage: https://launchpad.net/timezonemap
 Vcs-Browser: https://salsa.debian.org/cinnamon-team/libtimezonemap
diff -Nru libtimezonemap-0.4.6/debian/patches/port-to-libsoup3.patch 
libtimezonemap-0.4.6/debian/patches/port-to-libsoup3.patch
--- libtimezonemap-0.4.6/debian/patches/port-to-libsoup3.patch  2023-06-20 
23:54:22.0 -0700
+++ libtimezonemap-0.4.6/debian/patches/port-to-libsoup3.patch  2024-04-08 
16:31:23.0 -0700
@@ -5,11 +5,11 @@
 Forwarded: not-yet
 Last-Update: 2022-08-06
 ---
-diff --git a/configure.ac b/configure.ac
-index 3f74dae..4e90e64 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -50,13 +50,13 @@ GDK_REQUIRED_VERSION=2.22
+Index: libtimezonemap/configure.ac
+===
+--- libtimezonemap.orig/configure.ac
 libtimezonemap/configure.ac
+@@ -50,13 +50,13 @@
  GLIB_REQUIRED_VERSION=2.26
  GTK3_REQUIRED_VERSION=3.1.4
  GIO_REQUIRED_VERSION=2.5.11
@@ -25,23 +25,24 @@
json-glib-1.0)
  LIBTIMEZONEMAP_LIBS="$LIBTIMEZONEMAP_LIBS $LIBM"
  
-diff --git a/src/timezone-completion.c b/src/timezone-completion.c
-index d310235..6971ae9 100644
 a/src/timezone-completion.c
-+++ b/src/timezone-completion.c
-@@ -271,8 +271,10 @@ geonames_data_ready (GObject *object, GAsyncResult *res, 
gpointer user_data)
+Index: libtimezonemap/src/timezone-completion.c
+===
+--- libtimezonemap.orig/src/timezone-completion.c
 libtimezonemap/src/timezone-completion.c
+@@ -270,9 +270,10 @@
+   CcTimezoneCompletionPrivate * priv = completion->priv;
GError * error = NULL;
GInputStream * stream;
-   SoupMessage *message;
+-  SoupMessage *message;
 +  const gchar * reason_phrase;
 +  SoupStatus status_code;
  
 -  stream = soup_request_send_finish (SOUP_REQUEST (object), res, );
-+  stream = soup_session_send_finish (SOUP_SESSION (object), res, );
++  stream = soup_session_send_finish (priv->soup_session, res, );
if (stream == NULL)
  {
if (!g_error_matches (error, G_IO_ERROR, G_IO_ERROR_CANCELLED))
-@@ -283,8 +285,9 @@ geonames_data_ready (GObject *object, GAsyncResult *res, 
gpointer user_data)
+@@ -283,8 +284,9 @@
return;
  }
  
@@ -53,7 +54,7 @@
  {
JsonParser *parser;
  
-@@ -296,7 +299,7 @@ geonames_data_ready (GObject *object, GAsyncResult *res, 
gpointer user_data)
+@@ -296,10 +298,10 @@
else
  {
g_warning ("Unable to fetch geonames (server responded with: %u %s)",
@@ -61,8 +62,12 @@
 + status_code, reason_phrase);
  }
  
-   g_object_unref (message);
-@@ -362,7 +365,7 @@ static gboolean
+-  g_object_unref (message);
++  g_object_unref (object);
+   g_object_unref (stream);
+ }
+ 
+@@ -362,7 +364,7 @@
  request_zones (CcTimezoneCompletion * completion)
  {
CcTimezoneCompletionPrivate * priv = completion->priv;
@@ -71,28 +76,17 @@
GError *error = NULL;
  
priv->queued_request = 0;
-@@ -388,13 +391,14 @@ request_zones (CcTimezoneCompletion * completion)
-   gchar * version = get_version ();
-   gchar * locale = get_locale ();
-   gchar * url = g_strdup_printf (GEONAME_URL, escaped, version, locale);
-+  GAsyncResult * res;
+@@ 

Bug#1068678: nftables: on sysvinit the init script does not start nftables at boot

[Davide Baldini]

Package: nftables
Version: 1.0.6-2+deb12u2
Severity: normal

Dear Maintainer,

the installation of nftables completed via apt from the stable repository leads 
to the creation of the following init script on a system with sysvinit without 
Systemd:


  /etc/init.d/nftables

whose LSB section is:

  ### BEGIN INIT INFO
  # Provides:  nftables
  # Required-Start:$local_fs $network
  # Required-Stop: $local_fs $network
  # Should-Start:
  # Default-Start: S
  # Default-Stop:  0 1 6
  # Short-Description: Loads nftables firewall rules
  # Description: Loads nftables firewall rules
  ### END INIT INFO

The "Default-Start" tag is set to "S", which is problematic as it causes the 
script to never run at boot. If "S" is replaced by "1 2 3" the script instead 
runs at boot as intended. This seems to be a general problem with all init 
scripts under Debian whose "Default-Start" tag is set to "S". For example, I 
created the test file


  /etc/init.d/test.sh

with the following content:

  #!/bin/bash

  ### BEGIN INIT INFO
  # Provides:  test
  # Required-Start:
  # Required-Stop:
  # Should-Start:
  # Default-Start: S
  # Default-Stop:  0 1 6
  # Short-Description: Test
  # Description: Test
  ### END INIT INFO

  echo $(date) "$@" >>/root/test.txt

and I enable it with:

  update-rc.d test.sh defaults

which results in these, and only these, rc symlinks being created:

  rc0.d/K01test.sh
  rc1.d/K01test.sh
  rc6.d/K01test.sh
  rcS.d/S01test.sh

After rebooting the system from an empty '/root/test.txt' file, the contents of 
this file become:


  Tue Apr 9 01:26:50 CEST 2024 stop

in which only one line is logged, corresponding to the time when I issued the 
reboot command, with no follow-up lines after the reboot.
My sysvinit configuration is unremarkably default and I encountered this problem 
on every Debian system under sysvinit.


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set

Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages nftables depends on:
ii  libc6 2.36-9+deb12u3
ii  libedit2  3.1-20221030-2
ii  libnftables1  1.0.6-2+deb12u2

Versions of packages nftables recommends:
ii  netbase  6.4

Versions of packages nftables suggests:
pn  firewalld  

-- Configuration Files:
/etc/nftables.conf changed [not included]

-- no debconf information

Bug#1068637: apt does not always install Recommends

[Vincent Lefevre]

On 2024-04-08 19:26:42 +0200, David Kalnischkies wrote:
> On Mon, Apr 08, 2024 at 01:05:40PM +0200, Vincent Lefevre wrote:
> > On 2024-04-08 12:29:17 +0200, Julian Andres Klode wrote:
> > > On Mon, Apr 08, 2024 at 11:50:04AM +0200, Vincent Lefevre wrote:
> > > > The lvm2 package is installed, but not thin-provisioning-tools,
> > > > though lvm2 recommends it. This can yield a broken system:
> […]
> > It is not mandatory in all cases, but it some cases. In any case,
> > the "Recommends:" must be honored.
> 
> You haven't mentioned AT ALL if we are talking about upgrade or a fresh
> install of lvm2, for the later see below. For the former:

It was not an upgrade. For one of the machines, this was the status
a bit after the installation of bookworm. For the other machine, this
was the status just a bit after the installation of a weekly build on
2024-01-05.

Then, I don't know the internals. But according to Bastian Blank[*]:
"It is installed like everything else." (but see the details below).

[*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068560#22

> > No, lvm2 was installed before the time_t transition. It actually
> > affects plain bookworm installations (on a machine where I installed
> > Debian 12.1 on 2023-10-07); you can see with the attached
> > "dpkg --get-selections" output I had at that time.
>   
> 
> What time? Before you installed lvm2? That output says lvm2 is
> installed. So after it, but what are you trying to tell us then?

A few hours after the installation of bookworm. You can see that lvm2
is installed, but not thin-provisioning-tools (which is the bug).
I mean that this has always been like that (so, if you think that
thin-provisioning-tools could have been installed as a Recommends,
then removed later, this is not the case).

> I just bootstrapped a minimal stable chroot with mmdebstrap and behold:
> | # apt install --install-recommends lvm2
> | Reading package lists... Done
> | Building dependency tree... Done
> | Reading state information... Done
> | The following additional packages will be installed:
> |   dmeventd dmsetup libaio1 libdevmapper-event1.02.1 libdevmapper1.02.1 
> liblvm2cmd2.03 thin-provisioning-tools
> | The following NEW packages will be installed:
> |   dmeventd dmsetup libaio1 libdevmapper-event1.02.1 libdevmapper1.02.1 
> liblvm2cmd2.03 lvm2 thin-provisioning-tools
> | 0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
> | Need to get 2662 kB of archives.
> | After this operation, 9729 kB of additional disk space will be used.
> | Do you want to continue? [Y/n] n
> | Abort.
> 
> In other words your issue with a "plain bookworm" install is
> unreproducible

But what about the usual Debian installation on a real machine?

For the first machine (bookworm), I used an image via
  https://cdimage.debian.org/debian-cd/current/amd64/jigdo-cd/
namely, debian-12.1.0-amd64-netinst.iso, and I did the installation
by using a USB memory stick.

> So, if you want to have any chance of us investigating your problem as
> a bug rather than as a user-error you will have to tell us what you did
> exactly, preferably with easy to follow steps and output. Failing that,
> on your bookworm install you might be lucky and still have the
> installation/upgrade and such of lvm2 in your history.log(s).
> That might shine some light on it as well.

Indeed, in /var/log/apt/history.log.6.gz (note that I did not type
this command; so it came from the Debian installer):

Start-Date: 2023-10-07  13:43:22
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o 
APT::Keep-Fds::=6 -q -y --no-remove install lvm2
Install: dmeventd:amd64 (2:1.02.185-2, automatic), libaio1:amd64 (0.3.113-4, 
automatic), liblvm2cmd2.03:amd64 (2.03.16-2, automatic), lvm2:amd64 
(2.03.16-2), libdevmapper-event1.02.1:amd64 (2:1.02.185-2, automatic)
End-Date: 2023-10-07  13:43:28

And for the second machine (weekly build):

Start-Date: 2024-01-05  16:54:09
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o 
APT::Keep-Fds::=6 -q -y --no-remove install lvm2
Install: dmeventd:amd64 (2:1.02.185-2, automatic), libaio1:amd64 (0.3.113-5, 
automatic), liblvm2cmd2.03:amd64 (2.03.16-2, automatic), lvm2:amd64 
(2.03.16-2), libdevmapper-event1.02.1:amd64 (2:1.02.185-2, automatic)
End-Date: 2024-01-05  16:54:14

Now, this is clear that the recommended thin-provisioning-tools
package was not installed together with lvm2.

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

Bug#1067957: [EXTERNAL] Re: [[maude-bugs]] Maude fails to build on armhf

[Steven Eker]

Hi Nilish,

I don't have a 32-bit machine to test on, but my understanding is that 
Linux has moved to a 64-bit signed integer for time_t and this is a long 
long on 32-bit machines which is explicitly not supported by GMP's C++ API.


https://en.wikipedia.org/wiki/Year_2038_problem
https://gmplib.org/manual/C_002b_002b-Interface-Integers

I'm not happy converting a signed value to an unsigned value for all 
architectures. But


  mpz_class nanoSeconds(static_cast(timeValue.tv_sec));

should fix the problem, at least until 2038. Can you check that this 
works? If so I'll put it in the next public alpha.


Steven

On 4/7/24 08:28, Nilesh Patra wrote:

On Sun, Apr 07, 2024 at 07:45:33PM +0530, Nilesh Patra wrote:

Hi,

Maude fails to build on armhf/arm32 arch with:

In file included from timeManagerSymbol.cc:64:
timeActions.cc: In member function ‘void 
TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode*, 
ObjectSystemRewritingContext&)’:
timeActions.cc:43:41: error: call of overloaded ‘__gmp_expr(__time64_t&)’ is 
ambiguous
43 |   mpz_class nanoSeconds(timeValue.tv_sec);
   | ^
In file included from ../../src/BuiltIn/succSymbol.hh:28,
  from timeManagerSymbol.cc:53:
/usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], 
__mpz_struct [1]>::__gmp_expr(double)’
  1646 |   __GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS
   |   ^~
/usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], 
__mpz_struct [1]>::__gmp_expr(float)’

Full long here: 
https://buildd.debian.org/status/fetch.php?pkg=maude=armhf=3.4-1=1712489526=0
And Debian bug report here: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067957

Would be great if you have the cycles to look into it.

This patch fixes the issue at hand but I am unsure if it is sensible to apply
it.

diff --git a/src/ObjectSystem/timeActions.cc b/src/ObjectSystem/timeActions.cc
index 77395aa..63aa028 100644
--- a/src/ObjectSystem/timeActions.cc
+++ b/src/ObjectSystem/timeActions.cc
@@ -40,7 +40,7 @@ TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode* message, 
ObjectSystemRewriting
DebugSave(r, clock_gettime(CLOCK_REALTIME, ));
Assert(r == 0, "clock_gettime() failed: " << strerror(errno));
  
-  mpz_class nanoSeconds(timeValue.tv_sec);

+  mpz_class nanoSeconds(static_cast(timeValue.tv_sec));
nanoSeconds *= BILLION;
nanoSeconds += timeValue.tv_nsec;
  


Best,
Nilesh

Bug#1068677: ITP: emacs-activities -- Save/restore sets of windows, tabs/frames, and their buffers in Emacs

[Xiyue Deng]

Package: wnpp
Severity: wishlist
Owner: Xiyue Deng 

* Package name: emacs-activities
  Version : 0.7
  Upstream Author : Adam Porter 
* URL or Web page : https://github.com/alphapapa/activities.el
* License : GPL-3
  Programming lang: Emacs Lisp
  Description : Save/restore sets of windows, tabs/frames, and their 
buffers in Emacs
 Inspired by Genera's and KDE's concepts of "activities", this
 library allows the user to select an "activity", the loading of
 which restores a window configuration into a `tab-bar' tab or
 frame, along with the buffers shown in each window.  Saving an
 activity saves the state for later restoration.  Switching away
 from an activity saves the last-used state for later switching back
 to, while still allowing the activity's initial or default state to
 be restored on demand.  Resuming an activity loads the last-used
 state, or the initial/default state when a universal argument is
 provided.
 .
 The implementation uses the bookmark system to save buffers'
 states--that is, any major mode that supports the bookmark system
 is compatible.  A buffer whose major mode does not support the
 bookmark system (or does not support it well enough to restore
 useful state) is not compatible and can't be fully restored, or
 perhaps not at all; but solving that is as simple as implementing
 bookmark support for the mode, which is usually trivial.
 .
 Integration with Emacs's `tab-bar-mode' is provided: a window
 configuration or can be restored to a `tab-bar' tab or to a frame.
 .
 Various hooks are provided, both globally and per-activity, so that
 the user can define functions to be called when an activity is
 saved, restored, or switched from/to.  For example, this could be
 used to limit the set of buffers offered for switching to within an
 activity, or to track the time spent in an activity.

I intend to maintain this package within the Debian Emacsen Team
.

Bug#1068676: New Upstream Release, Package Problems, vcswatch issues.

[Thomas Ward]

Source: edb-debugger
Severity: normal

Hello.

The edb-debugger software is out of date. Upstream has version 1.5.0 as 
of two weeks ago. [1] The version in the repositories is from December 
13, 2020, and is SEVERELY out of date.  Note that 1.4.0 was released in 
July 2023.


Additional observations:

d/watch: Broken, needs updated to reflect updated GitHub d/watch 
requirements. [2]


d/control: OUTDATED build depends. Replace pkg-config with pkgconf. Per 
Lintian tags.  [3]



If this package needs assistance being maintained, I can assist, but for 
now I will be providing Salsa pull reqs/patches to address the d/watch 
and d/control issues, however I am not going to handle the outdated 
software problem.




Thomas Ward


[1]: https://github.com/eteran/edb-debugger/releases

[2]: https://wiki.debian.org/debian/watch#GitHub

[3]: https://udd.debian.org/lintian/?packages=edb-debugger

Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

[Lucas Thode]

Apologies for the confusion, I didn't realize the patch in question was a
new addition.  Just confirmed that it errors out instead of segfaulting or
hanging.

On Sat, Apr 6, 2024 at 5:32 PM Dirk Eddelbuettel  wrote:

>
> Hi Lucas,
>
> As Milan suggested, please sure you are current.  If in doubt, park you
> current checkout and start from
>
> git checkout https://github.com/eddelbuettel/dieharder.git
>
> where you should see today's commit from merging PR 24.
>
> edd@rob:~/git/dieharder(master)$ git ls | head
> *   3442896 - (HEAD -> master, origin/master, origin/HEAD) Merge pull
> request #24 from mbroz/dab-monobit2-ntup (10 hours ago) 
> |\
> | * d928cbf - Avoid overflow in DAB Monobit2 test. (10 hours ago)
> 
> |/
> *   2d4763a - Merge pull request #22 from mbroz/master (6 weeks ago)
> 
> |\
> | * 67989b4 - Do not report file input rewind if nothing was read
> repeatedly. (6 weeks ago) 
> |/
> * c987a15 - Fix segfault for wrongly specified test on commandline.
> (#21) (9 weeks ago) 
> *   a186d90 - Merge pull request #20 from mbroz/warning-fixes (2
> months ago) 
> edd@rob:~/git/dieharder(master)$
>
> Do not rely on the Debian package, it has not been updated yet.
>
> Cheers, Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
>

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Cyril Brulebois]

Package: src:linux
Version: 6.1.82-1
Severity: normal

Hi,

Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64
leads to losing some SMART information, at least as queried by munin (in
Debian 12) when it comes to sensors.

I'm getting the following results on the 2 pairs of disks in this machine:
 - 2×ST4000VN008-2DR1 (sda, sdb)
 - 2×ST8000VN004-2M21 (sdc, sdd)

root@anchorage:~# /usr/sbin/smartctl -A --nocheck=standby -d ata /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-19-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

Device is in SLEEP mode, exit(2)

For some reason, the “S.M.A.R.T values” graphs is still OK, while the
“HDD temperature” graph (using the aforementioned command) isn't
anymore.

The “Device is in SLEEP mode” status getting reported is obviously a
lie, since all disks are in use (one pair does system stuff, the other
pair does media stuff).

Rebooting a couple of time with this version gives consistent negative
results. Rebooting into linux-image-6.1.0-18-amd64 gives data back.

The trace that appears below seems to happen exactly once per boot (and
not even once per disk).


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


-- Package-specific info:
** Version:
Linux version 6.1.0-19-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.82-1 (2024-03-28)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-19-amd64 root=/dev/mapper/data-root ro quiet

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[   23.726790] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   23.763253] EXT4-fs (dm-13): mounted filesystem with ordered data mode. 
Quota mode: none.
[   23.764773] input: HDA Intel PCH Front Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input5
[   23.765529] input: HDA Intel PCH Rear Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input6
[   23.765566] input: HDA Intel PCH Line as 
/devices/pci:00/:00:1b.0/sound/card0/input7
[   23.765595] input: HDA Intel PCH Line Out as 
/devices/pci:00/:00:1b.0/sound/card0/input8
[   23.765626] input: HDA Intel PCH Front Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input9
[   23.785394] [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on minor 0
[   23.786295] ACPI: video: Video Device [GFX0] (multi-head: yes  rom: no  
post: no)
[   23.786473] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10
[   23.798653] i915 :00:02.0: [drm] Cannot find any crtc or sizes
[   23.801990] SGI XFS with ACLs, security attributes, realtime, quota, no 
debug enabled
[   23.823066] i915 :00:02.0: [drm] Cannot find any crtc or sizes
[   23.825531] i915 :00:02.0: [drm] Cannot find any crtc or sizes
[   23.916595] XFS (dm-4): Deprecated V4 format (crc=0) will not be supported 
after September 2030.
[   23.920456] EXT4-fs (dm-14): mounted filesystem with ordered data mode. 
Quota mode: none.
[   23.941160] XFS (dm-4): Mounting V4 Filesystem
[   24.076883] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Quota 
mode: none.
[   24.152240] XFS (dm-4): Ending clean mount
[   24.152258] xfs filesystem being mounted at /data/media supports timestamps 
until 2038 (0x7fff)
[   24.160691] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Quota 
mode: none.
[   24.177491] intel_rapl_common: Found RAPL domain package
[   24.177494] intel_rapl_common: Found RAPL domain core
[   24.177495] intel_rapl_common: Found RAPL domain uncore
[   24.177496] intel_rapl_common: Found RAPL domain dram
[   24.177500] intel_rapl_common: RAPL package-0 domain package locked by BIOS
[   24.177505] intel_rapl_common: RAPL package-0 domain dram locked by BIOS
[   24.415347] audit: type=1400 audit(1712616841.356:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=867 
comm="apparmor_parser"
[   24.415751] audit: type=1400 audit(1712616841.356:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=868 
comm="apparmor_parser"
[   24.415755] audit: type=1400 audit(1712616841.356:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=868 comm="apparmor_parser"
[   24.430914] audit: type=1400 audit(1712616841.372:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=870 
comm="apparmor_parser"
[   24.430919] audit: type=1400 audit(1712616841.372:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=870 
comm="apparmor_parser"
[   24.430922] audit: type=1400 audit(1712616841.372:7): apparmor="STATUS" 
operation="profile_load" 

Bug#1068241: authselect: pam_lastlog.so is gone

[Sudip Mukherjee]

On Tue, 2 Apr 2024 at 15:45, Chris Hofstaedtler  wrote:
>
> Source: authselect
> Version: 1.5.0-1
>
> Hi,
>
> it appears authselect references pam_lastlog.so. However, this
> module has been disabled in PAM upstream, and is also no longer
> shipped in Debian's PAM.

Thanks for reporting this.

>
> Please adapt your package.

I think I will wait a few more days to see the outcome of the
discussion at #1068017 and #1066060. then check with upstream before
doing anything.


--
Regards
Sudip

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Sam Hartman]

I've read the wiki page.  I'm fine with the proposed approach.  I note
that by including pam_lastlog2.so in a pam-auth-update configuration,
other services (gdm, for example) will include lastlog info.

The fact that gdm and other display managers do not include
pam_lastlog.so suggests that it's usage is not all that important.

If pam_lastlog2 is also a session module,  I recommend it only be used
for interactive sessions
To do this include the following in the pam-auth-update config:

Session-Interactive-Only: yes




signature.asc
Description: PGP signature

Bug#1068660: mpv: No sound. Please backport upstream patch.

[Roman Lebedev]

Package: mpv
Version: 0.37.0-1+b1
Followup-For: Bug #1068660
X-Debbugs-Cc: maril...@deb-multimedia.org
Control: tags -1 patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Now with a patch: 
https://salsa.debian.org/multimedia-team/mpv/-/merge_requests/3


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

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

Versions of packages mpv depends on:
ii  libarchive13t64   3.7.2-2
ii  libasound2t64 1.2.11-1+b1
ii  libass9   2:0.17.1-dmo1
ii  libavcodec60  10:6.1.1-dmo4
ii  libavdevice60 10:6.1.1-dmo4
ii  libavfilter9  10:6.1.1-dmo4
ii  libavformat60 10:6.1.1-dmo4
ii  libavutil58   10:6.1.1-dmo4
ii  libbluray22:1.3.4-dmo2
ii  libc6 2.37-15.1
ii  libcaca0  0.99.beta20-4+b1
ii  libcdio-cdda2t64  10.2+2.0.1-1.1
ii  libcdio-paranoia2t64  10.2+2.0.1-1.1
ii  libcdio19t64  1:2.1.0-dmo5
ii  libdrm2   2.4.120-2
ii  libdvdnav46.1.1-3
ii  libegl1   1.7.0-1
ii  libgbm1   24.0.4-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3+b3
ii  libjpeg62-turbo   1:2.1.5-2+b2
ii  liblcms2-22.14-2+b1
ii  liblua5.2-0   5.2.4-3+b2
ii  libmujs3  1.3.3-3+b2
ii  libpipewire-0.3-0t64  1.0.4-3
ii  libplacebo338 2:6.338.2-dmo2
ii  libpulse0 16.1+dfsg1-5
ii  librubberband21:3.3.0-dmo1
ii  libsdl2-2.0-0 2.30.1+dfsg-4
ii  libsixel1 1.10.3-3
ii  libswresample410:6.1.1-dmo4
ii  libswscale7   10:6.1.1-dmo4
ii  libuchardet0  0.0.8-1+b1
ii  libva-drm22.20.0-2
ii  libva-wayland22.20.0-2
ii  libva-x11-2   2.20.0-2
ii  libva22.20.0-2
ii  libvdpau1 1.5-2
ii  libvulkan11.3.275.0-1
ii  libwayland-client01.22.0-2.1+b1
ii  libwayland-cursor01.22.0-2.1+b1
ii  libwayland-egl1   1.22.0-2.1+b1
ii  libx11-6  2:1.8.7-1
ii  libxext6  2:1.3.4-1+b1
ii  libxkbcommon0 1.6.0-1
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.4-1
ii  libxss1   1:1.2.3-1
ii  libxv12:1.0.11-1.1
ii  libzimg2  1:3.0.5-dmo1
ii  zlib1g1:1.3.dfsg-3.1

Versions of packages mpv recommends:
ii  xdg-utils  1.1.3-4.1
ii  yt-dlp 1:2024.03.10-dmo1

Versions of packages mpv suggests:
pn  libcuda1  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+UikBxeiu50LOdFYgbqkFMWfZdAFAmYUb4sACgkQgbqkFMWf
ZdAiRw//XxYbik8SngcQcRU/tW1zpk5MeNi4pPsv5Q40MHoLKwNtm9ffyvAfLJjo
8LrX2KlhQ32r9w1rC1q7chgByN8+Fv0xz0Nu3oZj/pwKy8oADElYK6l69XvHJCJx
gYFwCfGLrjnfb09ndZjlZWbAMEZYCWhWVic0e8/MPPrE/sL2cULARNlfJx63LM6/
KG15UDgk/QRx035esB4/yCkwVZe3v4ZwEg0gI0iWHDxgkahB6CJ6h2WLF7VTY8Ww
ovecGO69OQ58znicpmuLmgFxKHXCJCBRN4hF2P6keIsmq1439diXLaiB5XYp43km
4NKTD5lckpTDsuQieM63/qwC+gyYNsqUTIzUnZvGuZdUsAVjg9mNCJQLDy82dk+x
7cTGamgpFDUjqSFPLDPWPcLEcW2Dr6fHdF4YWl5fHqxwiH6G3/CMfinlfXLAezk7
pCdHnTUcYko3CAWt1qEdjBcSoT8tcMbWCfvjoSwxGIrHZmZb/CGiMoGUnN/3HTk1
VjUKnEPOmpio7N+xBNqqMDI8GqF/zshIAZcy6rZBuqD3Et4XLbxTJA7VKvoxLrEV
HgQp3JeSfoqIFhm0WhUwerKqYc2k8bMKluCW7QN4OVENa652aTmEUtiYSBuBZ3+X
4hErWKe/mqv6F4d5vXafnQQw8ZRalF6qgkRqp65w99+Yl01coqo=
=8K8L
-END PGP SIGNATURE-

Bug#1065806: pam: recent upgrade changes previous default umask

[Sam Hartman]

control: clone -1 -2
control: retitle -2 Document pam_umask change in release notes

Bug#1068673: openshot-qt: "AVERROR_EOF" errors when attempting to export h.264 video

[Paul "LeoNerd" Evans]

Package: openshot-qt
Version: 3.1.1+dfsg1-1
Severity: normal

Dear Maintainer,

When exporting using the target "MP4 (mpeg4)", all works fine.

When exporting using the target "MP4 (h.264)", the standard output
stream is full of messages of:

  Frame AVERROR_EOF

The resulting file is much smaller in size and contains only the audio
stream. The video stream is entirely missing from it; as evidenced by
mplayer output:

  Video: no video

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

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

Versions of packages openshot-qt depends on:
ii  fonts-cantarell 0.303.1-1
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  python3 3.11.6-1
ii  python3-openshot0.3.2+dfsg1-2+b1
ii  python3-pkg-resources   68.1.2-2
ii  python3-pyqt5   5.15.10+dfsg-1
ii  python3-pyqt5.qtsvg 5.15.10+dfsg-1
ii  python3-pyqt5.qtwebkit  5.15.10+dfsg-1
ii  python3-requests2.31.0+dfsg-1
ii  python3-zmq 24.0.1-5+b1

openshot-qt recommends no packages.

Versions of packages openshot-qt suggests:
ii  blender  4.0.2+dfsg-1+b1
ii  inkscape 1.2.2-2+b3
pn  openshot-qt-doc  

-- no debconf information

Bug#1067970: Forwarded upstream

[Kyle Robbertze]

forwarded -1 https://github.com/jack-mixer/jack_mixer/issues/184
thanks

Migration requested upstream.

Yes, that is incorrect and should be a Depends too (#1056662).

Cheers
Kyle
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze

Bug#1068672: RM: texworks [i386] -- ROM; Intent to drop poppler-qt6 on i386

[Hilmar Preusse]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: texwo...@packages.debian.org
Control: affects -1 + src:texworks
Control: block #1057407 by -1

In #1057407 we got a request to remove texworks for i386, which is (currently)
the only package, which needs poppler-qt6. According [1] dropping support
i386 is currently allowed.

Hilmar

[1] https://lists.debian.org/debian-devel-announce/2023/12/msg3.html


signature.asc
Description: PGP signature

Bug#1068671: rust-try-lock: please update to v0.2.5

[Jonas Smedegaard]

Source: rust-try-lock
Version: 0.2.2-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v0.2.5.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYUZUYACgkQLHwxRsGg
ASG5IA/8DJVJUns0sW/6xfDQs9hYGQW/ab4ERZDZ546clBzg9nEq8rj5a7hVu85D
M2bG2VLyrFoR7DNfYScb5qz5HK06Ay9ox/t436pfTlAoKYOBGTgM6i0cDr2IhlBS
A3Cxyu2l6Z8/bq5TXDwKXOjIjc0nrkgDYKUKrjEugD7Y+nalxroRJO/MaLjzJfyj
Xn5s4jMpsAk0pAu1bFm6CzJTN8JHEpycyKnlRK+ygdV6BEA3eIzcNuZySd6U6TUh
kElqYjcc1ARWbQPFe1aNkuzHYSRfHYDGRCQJyRdNQHNT/YBbWxGctIPD8jd8yptG
E4HeTRWpW6VV0nLcwlyxao6OUaU+op/3IQkyGv5se3B9scaC2HOHcX9/d59poN/w
ueZUINtlmbnLOHZVVGWEHJxGysxKwWT2pBUzv1nM1I8xKO+KKeKN8nGg/5hOAleV
hN2WT8R2aygKJTwPSKIkeeuYvTDS5rXubwkm2AahWwx7hNZlWoM77dq7O09EJw0S
NGfF0QnNpsehnzVBiTQGMVnjpe5ssUgNKgOvX3GwFJripEwjlllQXo5BGSbedg03
5MOKR2RWSLN/u2uKNPWzj8WJIyB64DxDlrwngMXI3koFEghFkFd4qJlSNBz++p8H
eHQDTfBhc2zf9qzWlWXAWpo56uagtJWqB2JrGZVQzFBvzDIlJWs=
=1k6R
-END PGP SIGNATURE-

Bug#1068670: rust-concurrent-queue: please provide feature loom

[Jonas Smedegaard]

Source: rust-concurrent-queue
Version: 2.3.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please provide feature loom.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYUZLgACgkQLHwxRsGg
ASGZGw/9Fygw05zPA6l0ewHRrZZGQ6Qsr1z5Hfyqow4akEhgQ7S9QAxMJLPpmpun
XYJDhloidnbFauklxkN1+8jIDfsVlYMGmMCgC6dLvx6GeTfyIE+E1ztxyn26+hdA
lF+je6Z2ckhpKEj9mGnEZc79ErRIvOVXbSGhcY5yG8FZpQ9L0wcNYo1EyYfRD49V
7GhNR3JoktMRLmWRGyx/q0Kn4h97kOagOvdNN9fRwF7ydGdV81gvWzeMofB0yXdR
+bhGgg8Dn9waREW9BL/sCcAo7VLanVGx2NtlL51vlDYOildDR7edm/hJy7V2GmQL
xoGJ7i2QtbJRm3UG/mKgf8nVeGaeupzzQsCVfpMlGcc4vikv8jfll6X7xprzawb1
04WnmvFpoxCKyg2EpoHZtmOWd/042+tneZns5d/summq8xLQfSwANga7VfwRhmsd
MYESuxzANGoVWK6i8Pdb/7n64PxJUCJG/guYT64yheYFHwbYiOknjGGo6PBiwIt8
hPJbUBaOB1C/GCyJ1SnjOpJBqriZbKUewKWZjKeKwvDx6xqKbthXz7DWAM/A99E+
ymh259g/LtruHIIuo4+KENfqpqozAEpts6XbhD6qQeeQhhwDtl1uDo0U8vMqFzUB
ZQwGqaGA9B+exkptkdi5Ced51zeerbzRbcb623vx2P1IhOJmSuw=
=wj6O
-END PGP SIGNATURE-

Bug#1068669: ITP: golang-github-mitchellh-hashstructure -- Get hash values for arbitrary values in Go (golang).

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: golang-github-mitchellh-hashstructure-v2
  Version : 2.0.2-1
  Upstream Author : Mitchell Hashimoto
* URL : https://github.com/mitchellh/hashstructure
* License : Expat
  Programming Lang: Go
  Description : generate hash values for arbitrary values in Golang

 Hashstructure is a Go library for creating a unique hash value for
 arbitrary values in Go.

Bug#1068668: rust-parking: please provide feature loom

[Jonas Smedegaard]

Source: rust-parking
Version: 2.0.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please provide feature loom, available since upstream version 2.1.0.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYUZEMACgkQLHwxRsGg
ASEHihAAkk46l4cBMZiYFifreWROvQUNM7DbTIeUZwd+AcbJ2beLrU0fJkg9x9/s
nxJOwXJOlo5AQ4mEz0EL75lKTib2eVBXlWVROeKnRH0gxSURW5jaKhwyM4juDeA2
SMqit7pkQzMRErpm+giaXajuPBB8ASvFxVYWyW3ch3r2q3dNLwVBE8bNXE02kn5I
gwBRB+G5EYiGlnWVHQXZoFMMOJENzI8fhTpM4dA83OeM2XpaMsjWmmBnuY1mUbSN
z8IySUaUU/SV8aefbpsb0PYtyz5uJpAqKHfhrwi9OmNxe5tmW/pK5RjiCvoYH0aM
1cTuIa16cM/IQaMpQqxjRC63oK6/+XZV9esWa192Fk07BWlZOJM5tKOTRWuET5gQ
dZwwHszG3kZP0PC2vqSymAT+pZ1EbynhuP94afxIaSk0maBK5B57drLnjYcyu+Sq
5vJCzvEQphF72xNt+qRtMlDmNbt7wY7FD2TSrU5rRjkvwQLvfObyxdbCGEeX3jGs
/YVErZ+cFPDzBLxjYiod3r/ObzAN1M00BGs8H+MyqLpk/xKL4nTTO4I3kSKfNZtc
kfqTsSrsqCU8tKqOv0lbtW85BtkaYDPtPSnLgXpgH0aVXl8V9wPXuQR8QTIzl4fA
KCL8VJvxIhV2/NmDc86bGjQqloTUuyUl0RJBKoMhqMCzs+0C7mw=
=v+ZG
-END PGP SIGNATURE-

Bug#306043: bash executable completion doesn't work if there is a space in the executable path

[Chet Ramey]

On 4/5/24 5:21 PM, Gioele Barabucci wrote:

Control: found -1 5.2.21-2
Control: tags -1 upstream
X-Debbugs-CC: bug-b...@gnu.org

On Sat, 23 Apr 2005 15:20:19 -0700 Frederik Eaton  wrote:

Bash executable completion doesn't work if there is a space in the
executable path.


This issue is still partially present in current version of Bash.

The most basic case has been fixed:

     $ touch "cmd with spaces"
     $ chmod +x "cmd with spaces"
     $ PATH=$PWD:$PATH
     $ cmd
     $ cmd\ with\ spaces

However there seems to be a linger issue that appears when multiple 
commands with spaces match a given prefix:


Thanks for the report. This will be fixed in the next push to the bash
devel branch.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068368: Removed package(s) from unstable

[Thorsten Alteholz]

On Mon, 8 Apr 2024, Andreas Beckmann wrote:
The python3.10 removal accidentally caused the removal of 'and', too, most 
likely because of the non-standard subject line that got misparsed.

(Hint: Using reportbug would have helped to get that formatted correctly.)


oh, thanks for catching this ...

... and accepted.

  Thorsten

Bug#1068667: rust-futures-lite: please upgrade to branch v2

[Jonas Smedegaard]

Source: rust-futures-lite
Version: 1.12.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to, or separately provide, upstream branch v2.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYUYZMACgkQLHwxRsGg
ASFSpw//YkWIfk2cU2a3nJlN09jptj1iaKhSWjELDJMpYCK5mrDZGYJYhTS1+i/D
fVmeYBtDTBD9Yyvkzzuveygy0JMXDM6Sv+svpxXqSS3TNU9Ts5lvI6sK1YjviyBW
MLwwBGtjUCjEokPcrV49eP+6P3XiOdyu0xrFf6/QK1V0aGYcZ2ogZcay2GJCDJpt
Kp+zxQjdU04cSBht5zgwlrgHV5MNB0NGhgx7vJ+brEyxZ0pdVe2fhhVwlV6egnQU
FQD0hBS9uXxWnfvE8TihDtTS7UONv7LMd8cySX0MjPaZtNH7V6OWBsiZnaOLqHA6
JxsUXhvD5fH6Q/SwQT0XvPLXExkq04KFl7FV7CAiote25PQn2aZVzdBOXIbWgKZu
4Emka8NdU7620g4M0xK6U2x7G0yh61MP8VnHHDNUQ1rvJOyhwTK+N/SKJf8m1egd
clyFzbXqU1TCOosX4dXUf1Okv9L39FD6u8lSZn3hcxH+ztxsau016pfdpFCSAvfM
tljdymPrZ7oXUN+F/pas1RBkS11VOtt0Anw6Rjm4yQ9KyYtyMYDNIl6O2Rt7G037
W3ElsmD2UhR+AS5rRlYgsV8UpgGijQdxbSJR2C3jl0Y9WuYnKCjDKHpwS/oTIyWe
cmoA8rmt+9HuLNUiFNAiK3JnraRV7YFCMM/hqtGZB1ah4x1T5/M=
=kbQg
-END PGP SIGNATURE-

Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t

[Aurelien Jarno]

Hi Helmut,

On 2024-04-08 22:19, Helmut Grohne wrote:
> Control: tags -1 + patch
> 
> Hi Aurelien and Canonical folks,
> 
> On Tue, Apr 02, 2024 at 08:53:31PM +0200, Aurelien Jarno wrote:
> > Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with
> > -D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures
> > except i386.
> > 
> > This has been partially fixed in the 2.37-15.1 NMU by adding
> > -U_TIME_BITS to CFLAGS, however it causes failures in the testsuite:
> 
> There are two subtleties about -U_TIME_BITS in a moment.
> 
> > | +-+
> > | | Encountered regressions that don't match expected failures. |
> > | +-+
> > | FAIL: conform/ISO/stdio.h/linknamespace
> 
> The detail for this failure is:
> 
> | [initial] fgetpos64
> | [initial] fopen64
> | [initial] freopen64
> | [initial] fsetpos64
>|  [initial] tmpfine64
> 
> What linknamespace.py wants to tell us here is that it expected
> fgetpos64, but no fgetpos64 was declared. It was not declared, because
> there is no difference between fgetpos and fgetpos64 after defining
> -D_FILE_OFFSET_BITS=64 (which is also in the default compiler flags).
> 
> The other failures are of very similar kind, but there also is another
> kind.
> 
> > | FAIL: conform/POSIX/sys/stat.h/conform
> 
> The detail for this failure contains:
> 
> | /tmp/tmpnzda_r9j/test.c:90:35: error: conflicting types for 'b2_8'; have 
> '__time64_t' {aka 'long long int'}
> |90 | extern __typeof__ (a2_8.st_atime) b2_8;
> |   |   ^~~~
> | /tmp/tmpnzda_r9j/test.c:89:17: note: previous declaration of 'b2_8' with 
> type '__time_t' {aka 'long int'}
> |89 | extern __time_t b2_8;
> |   | ^~~~
> 
> Here, it tells us that it expected the st_atime field of struct stat to
> have type __time_t (the 32 bit one), but it really has __time64_t.
> 
> Looking at the invocation of linknamespace.py you can see:
> 
> | python3 -B linknamespace.py --cc='arm-linux-gnueabihf-gcc-12' 
> --flags='-I../include  
> -I/build/reproducible-path/glibc-2.37/build-tree/armhf-libc  
> -I../sysdeps/unix/sysv/linux/arm/le  -I../sysdeps/unix/sysv/linux/arm  
> -I../sysdeps/arm/nptl  -I../sysdeps/unix/sysv/linux/include 
> -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  
> -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  
> -I../sysdeps/unix/arm  -I../sysdeps/unix  -I../sysdeps/posix  
> -I../sysdeps/arm/le/armv7/multiarch  -I../sysdeps/arm/armv7/multiarch  
> -I../sysdeps/arm/le/armv7  -I../sysdeps/arm/armv7  -I../sysdeps/arm/armv6t2  
> -I../sysdeps/arm/armv6  -I../sysdeps/arm/le  -I../sysdeps/arm/include 
> -I../sysdeps/arm  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/flt-32  
> -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754  -I../sysdeps/generic 
> -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabihf/12/include -isystem 
> /build/reproducible-path/glibc-2.37/debian/include -I..' ...
> 
> In particular, what you do not see is -U_TIME_BITS inside --flags.
> 
> > Ubuntu has just ignored those failures for now, but I am just afraid
> > that if we do the same, nobody will fix them.
> 
> Armed with this knowledge, I think we need two changes. For one thing
> debian/sysdeps/linux.mk needs to add -U_FILE_OFFSET_BITS to extra_cflags
> to revert any possible ABI changing effects. For another, the
> conformance tests use independent compiler flags defined in
> conform/Makefile. There, a naive patch seems to be:
> 
> -conformtest-cc-flags = -I../include $(+sysdep-includes) $(sysincludes) -I..
> +conformtest-cc-flags = -U_FILE_OFFSET_BITS -U_TIME_BITS -I../include 
> $(+sysdep-includes) $(sysincludes) -I..
> 
> With these two changes, I am able to successfully build glibc on armhf
> with the conformance test suite passing.
> 
> > In addition it means that upstream glibc does not build anymore by
> > default on a 32-bit Debian. Not really a Debian issue, but that is not
> > nice either and should probably be fixed.
> 
> I think that latter change may be applicable upstream. Running the
> conformance test suite with either _FILE_OFFSET_BITS or _TIME_BITS set
> is not expected nor supported. This is partially evident from
> conform/linknamespace.py in a comment:
> 
> | # * Header inclusions should be compiled several times with
> | # different options such as -O2, -D_FORTIFY_SOURCE and
> | # -D_FILE_OFFSET_BITS=64 to find out what symbols are undefined
> | # from such a compilation; this is not yet implemented.
> 
> The conformance test suite clearly wants to manage these macros (and its
> effects on symbols) explicitly and does not expect them to be
> pre-defined.

Thanks for you analysis and your patch. In short your proposal is to
extend the initial patch from Steve to fully hide the fact that the
compiler default to -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64.

This 

Bug#1068665: cfengine3: FTBFS on arm{el,hf}: 1 of 60 tests failed

[Sebastian Ramacher]

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

https://buildd.debian.org/status/fetch.php?pkg=cfengine3=armel=3.21.4-1=1712477798=0

==
Starting test: files_interfaces_test.c
==
test_cfreadline_valid: Starting test
test_cfreadline_valid: Test completed successfully.
test_cfreadline_corrupted: Starting test
test_cfreadline_corrupted: Test completed successfully.
All 2 tests passed
PASS: files_interfaces_test
1 != 3
ERROR: connection_management_test.c:39 Failure!
1 != 2
ERROR: connection_management_test.c:69 Failure!
1 != 2
ERROR: connection_management_test.c:99 Failure!
1 != 2
ERROR: connection_management_test.c:129 Failure!
4 out of 4 tests failed!
test_purge_old_connections_nochange
test_purge_old_connections_purge_first
test_purge_old_connections_purge_middle
test_purge_old_connections_purge_last
==
Starting test: connection_management_test.c
==
test_purge_old_connections_nochange: Starting test
test_purge_old_connections_nochange: Test failed.
test_purge_old_connections_purge_first: Starting test
test_purge_old_connections_purge_first: Test failed.
test_purge_old_connections_purge_middle: Starting test
test_purge_old_connections_purge_middle: Test failed.
test_purge_old_connections_purge_last: Starting test
test_purge_old_connections_purge_last: Test failed.
FAIL: connection_management_test

Cheers
-- 
Sebastian Ramacher

Bug#1068666: haskell-fold-debounce: FTBFS on arm{el,hf}: 14 examples, 2 failures

[Sebastian Ramacher]

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

https://buildd.debian.org/status/fetch.php?pkg=haskell-fold-debounce=armel=0.2.0.11-1%2Bb2=1712466208=0

Failures:

  test/Control/FoldDebounceSpec.hs:81:40: 
  1) Control.FoldDebounce.Trigger emits the output event 'delay' interval after 
the first input event (alwaysResetTimer = False)
   expected: Just [10,20,30,40,50]
but got: Just [10,20,30]

  To rerun use: --match "/Control.FoldDebounce/Trigger/emits the output event 
'delay' interval after the first input event (alwaysResetTimer = False)/"

  test/Control/FoldDebounceSpec.hs:143:21: 
  2) Control.FoldDebounce.Trigger emits output events even if input events are 
coming intensely
   predicate failed on: ["abc"]

  To rerun use: --match "/Control.FoldDebounce/Trigger/emits output events even 
if input events are coming intensely/"

Randomized with seed 1347232098

Finished in 2.9315 seconds
14 examples, 2 failures
Test suite spec-threaded: FAIL
Test suite logged to: dist-ghc/test/fold-debounce-0.2.0.11-spec-threaded.log
0 of 2 test suites (0 of 2 test cases) passed.
-e: error: debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct 
returned exit code 1
 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 875.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup test 
--builddir=dist-ghc --show-details"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 614
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup test 
--builddir=dist-ghc --show-details"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 477
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "test", 
"--builddir=dist-ghc", "--show-details=direct") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 692
Debian::Debhelper::Buildsystem::Haskell::Recipes::check_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:163: check-ghc-stamp] Error 25

Cheers
-- 
Sebastian Ramacher

Bug#1068664: haskell-filestore: FTBFS on arm{el,hf}: Total Cases: 42 Tried: 42 Errors: 1 Failures: 1

[Sebastian Ramacher]

Source: haskell-filestore
Version: 0.6.5-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

Running 1 test suites...
Test suite test-filestore: RUNNING...

Cases: 21  Tried: 0  Errors: 0  Failures: 0
Cases: 21  Tried: 1  Errors: 0  Failures: 0
Cases: 21  Tried: 2  Errors: 0  Failures: 0
Cases: 21  Tried: 3  Errors: 0  Failures: 0
Cases: 21  Tried: 4  Errors: 0  Failures: 0
Cases: 21  Tried: 5  Errors: 0  Failures: 0
Cases: 21  Tried: 6  Errors: 0  Failures: 0
Cases: 21  Tried: 7  Errors: 0  Failures: 0
Cases: 21  Tried: 8  Errors: 0  Failures: 0
Cases: 21  Tried: 9  Errors: 0  Failures: 0
Cases: 21  Tried: 10  Errors: 0  Failures: 0
Cases: 21  Tried: 11  Errors: 0  Failures: 0
Cases: 21  Tried: 12  Errors: 0  Failures: 0
Cases: 21  Tried: 13  Errors: 0  Failures: 0
Cases: 21  Tried: 14  Errors: 0  Failures: 0
Cases: 21  Tried: 15  Errors: 0  Failures: 0
Cases: 21  Tried: 16  Errors: 0  Failures: 0
Cases: 21  Tried: 17  Errors: 0  Failures: 0
Cases: 21  Tried: 18  Errors: 0  Failures: 0

### Failure in: 18:Git (history and revision)
tests/Tests.hs:335
history from now + 1 day onwards is empty

Cases: 21  Tried: 19  Errors: 0  Failures: 1
Cases: 21  Tried: 20  Errors: 0  Failures: 1

Cases: 21  Tried: 21  Errors: 0  Failures: 1

Cases: 21  Tried: 0  Errors: 0  Failures: 0
Cases: 21  Tried: 1  Errors: 0  Failures: 0
Cases: 21  Tried: 2  Errors: 0  Failures: 0
Cases: 21  Tried: 3  Errors: 0  Failures: 0
Cases: 21  Tried: 4  Errors: 0  Failures: 0
Cases: 21  Tried: 5  Errors: 0  Failures: 0
Cases: 21  Tried: 6  Errors: 0  Failures: 0
Cases: 21  Tried: 7  Errors: 0  Failures: 0
Cases: 21  Tried: 8  Errors: 0  Failures: 0
Cases: 21  Tried: 9  Errors: 0  Failures: 0
Cases: 21  Tried: 10  Errors: 0  Failures: 0
Cases: 21  Tried: 11  Errors: 0  Failures: 0
Cases: 21  Tried: 12  Errors: 0  Failures: 0
Cases: 21  Tried: 13  Errors: 0  Failures: 0
Cases: 21  Tried: 14  Errors: 0  Failures: 0
Cases: 21  Tried: 15  Errors: 0  Failures: 0
Cases: 21  Tried: 16  Errors: 0  Failures: 0
Cases: 21  Tried: 17  Errors: 0  Failures: 0
Cases: 21  Tried: 18  Errors: 0  Failures: 0

### Error in:   18:Mercurial (history and revision)
UnknownError: mercurial log returned error status.
hg: parse error: invalid date: '134982229649-07-10 23:17:33'


Cases: 21  Tried: 19  Errors: 1  Failures: 0
Cases: 21  Tried: 20  Errors: 1  Failures: 0

Cases: 21  Tried: 21  Errors: 1  Failures: 0
Total Cases: 42  Tried: 42  Errors: 1  Failures: 1
Test suite test-filestore: FAIL
Test suite logged to: dist-ghc/test/filestore-0.6.5-test-filestore.log
0 of 1 test suites (0 of 1 test cases) passed.
-e: error: debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct 
returned exit code 1
 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 875.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup test 
--builddir=dist-ghc --show-details"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 614
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup test 
--builddir=dist-ghc --show-details"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 477
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "test", 
"--builddir=dist-ghc", "--show-details=direct") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 692
Debian::Debhelper::Buildsystem::Haskell::Recipes::check_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:163: check-ghc-stamp] Error 25

Cheers
-- 
Sebastian Ramacher

Bug#1068663: zzuf: FTBFS on arm{el,hf}: /tmp/ccnMZahz.s:1620: Error: symbol `open64' is already defined

[Sebastian Ramacher]

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

https://buildd.debian.org/status/fetch.php?pkg=zzuf=armhf=0.15-3=1712473020=0

In file included from /usr/include/arm-linux-gnueabihf/sys/cdefs.h:24,
 from libzzuf/lib-mem.c:24:
/usr/include/features.h:195:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE 
are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
  195 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use 
_DEFAULT_SOURCE"
  |   ^~~
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
-DLIBZZUF -I./libzzuf -I./common -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -std=c99 -g -O2 -Wall 
-W -Wpointer-arith -Wcast-align -Wcast-qual -Wstrict-prototypes -Wshadow 
-Waggregate-return -Wmissing-prototypes -Wnested-externs -Wsign-compare -c 
libzzuf/lib-signal.c -o libzzuf/la-lib-signal.o >/dev/null 2>&1
/tmp/ccnMZahz.s: Assembler messages:
/tmp/ccnMZahz.s:1620: Error: symbol `open64' is already defined
/tmp/ccnMZahz.s:4926: Error: symbol `lseek64' is already defined
make[3]: *** [Makefile:708: libzzuf/la-lib-fd.lo] Error 1
make[3]: *** Waiting for unfinished jobs
/tmp/ccKhQeYR.s: Assembler messages:
/tmp/ccKhQeYR.s:1867: Error: symbol `mmap64' is already defined

Cheers
-- 
Sebastian Ramacher

Bug#1032807: [INTL:ro] Romanian debconf templates translation of mumble

[Chris Knadle]

Hello Remus-Gabriel.

I would like to know how to incorporate the Romanian translation file 
into the Mumble 1.5.517 package.


Is it as simple as renaming the mumble_debconf_ro.po file to ro.po and 
moving it to debian/po/ro.po ?


It has been some time since I've dealt with translation files and I'm 
trying to figure out if there's something special necessary to do with 
the translation file for the packaging.


Thanks
   -- Chris

--
Chris Knadle
chris.kna...@coredump.us


On 4/5/23 19:18, Remus-Gabriel Chelu wrote:

3 aprilie 2023 la 07:44, "Chris Knadle"  a scris:

[...]

Hello, Chris!

I just finished checking the status of the debconf-mumble translation file (in
Romanian) with the following commands:

$: git clone https://salsa.debian.org/pkg-voip-team/mumble
$: cp -v ../Documente/mumble_debconf_ro.po mumble/debian/po/ro.po
$: LANG=en msgfmt -c -v -o /dev/null mumble/debian/po/ro.po
8 translated messages.

and:

#: cd mumble/
#: podebconf-display-po -fdialog debian/po/ro.po

with good results; exactly as expected.

So, from my side, considering the results of the test performed, the "ro.po" 
file
can be added to mumble 1.5.517 without any problems.

Bug#1068660: mpv: No sound. Please backport upstream patch.

[Sebastian Ramacher]

Control: severity -1 minor

On 2024-04-08 23:06:17 +0300, Roman Lebedev wrote:
> Package: mpv
> Version: 0.37.0-1+b1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: maril...@deb-multimedia.org
> 
> Dear maintainers,
> an upstream fix for https://github.com/mpv-player/mpv/pull/13665
> which was not yet released in any mpv version needs to be backported
> to the current mpv version, looks like the problematic ffmpeg version
> is finally in debian (or deb-multimedia, but still.), resulting in no audio:

This version is only in experimental and mpv has not been rebuilt
against ffmpeg 7.0. As you have dmo enabled, you get to keep the pieces.

Keeping the bug open for the transiton to ffmpeg 7.0.

Cheers

> ```
> AO: [pipewire] 48000Hz 5.1(side) 6ch floatp
> VO: [gpu] 1920x960 yuv420p10
> [ffmpeg] SWR: Input channel layout "" is invalid or unsupported.
> [swresample] Cannot open Libavresample context.
> [swresample] libswresample failed to initialize.
> Cannot convert decoder/filter output to any format supported by the
> output.
> Audio: no audio
> ```
> 
> Roman.
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (500, 'unstable-debug'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.7.9-amd64 (SMP w/32 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages mpv depends on:
> ii  libarchive13t64   3.7.2-2
> ii  libasound2t64 1.2.11-1+b1
> ii  libass9   2:0.17.1-dmo1
> ii  libavcodec60  10:6.1.1-dmo4
> ii  libavdevice60 10:6.1.1-dmo4
> ii  libavfilter9  10:6.1.1-dmo4
> ii  libavformat60 10:6.1.1-dmo4
> ii  libavutil58   10:6.1.1-dmo4
> ii  libbluray22:1.3.4-dmo2
> ii  libc6 2.37-15.1
> ii  libcaca0  0.99.beta20-4+b1
> ii  libcdio-cdda2t64  10.2+2.0.1-1.1
> ii  libcdio-paranoia2t64  10.2+2.0.1-1.1
> ii  libcdio19t64  1:2.1.0-dmo5
> ii  libdrm2   2.4.120-2
> ii  libdvdnav46.1.1-3
> ii  libegl1   1.7.0-1
> ii  libgbm1   24.0.4-1
> ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3+b3
> ii  libjpeg62-turbo   1:2.1.5-2+b2
> ii  liblcms2-22.14-2+b1
> ii  liblua5.2-0   5.2.4-3+b2
> ii  libmujs3  1.3.3-3+b2
> ii  libpipewire-0.3-0t64  1.0.4-3
> ii  libplacebo338 2:6.338.2-dmo2
> ii  libpulse0 16.1+dfsg1-5
> ii  librubberband21:3.3.0-dmo1
> ii  libsdl2-2.0-0 2.30.1+dfsg-4
> ii  libsixel1 1.10.3-3
> ii  libswresample410:6.1.1-dmo4
> ii  libswscale7   10:6.1.1-dmo4
> ii  libuchardet0  0.0.8-1+b1
> ii  libva-drm22.20.0-2
> ii  libva-wayland22.20.0-2
> ii  libva-x11-2   2.20.0-2
> ii  libva22.20.0-2
> ii  libvdpau1 1.5-2
> ii  libvulkan11.3.275.0-1
> ii  libwayland-client01.22.0-2.1+b1
> ii  libwayland-cursor01.22.0-2.1+b1
> ii  libwayland-egl1   1.22.0-2.1+b1
> ii  libx11-6  2:1.8.7-1
> ii  libxext6  2:1.3.4-1+b1
> ii  libxkbcommon0 1.6.0-1
> ii  libxpresent1  1.0.0-2+b10
> ii  libxrandr22:1.5.4-1
> ii  libxss1   1:1.2.3-1
> ii  libxv12:1.0.11-1.1
> ii  libzimg2  1:3.0.5-dmo1
> ii  zlib1g1:1.3.dfsg-3.1
> 
> Versions of packages mpv recommends:
> ii  xdg-utils  1.1.3-4.1
> ii  yt-dlp 1:2024.03.10-dmo1
> 
> Versions of packages mpv suggests:
> pn  libcuda1  
> 
> -- no debconf information
> 
> 

-- 
Sebastian Ramacher

Bug#1065806: pam: recent upgrade changes previous default umask

[Sven Joachim]

On 2024-04-08 14:13 -0600, Sam Hartman wrote:

>> "Professor" == Professor Jeebs  writes:
>
>
> Professor> I prefer the way it is handled per user.  There is a related, 
> commented
> Professor> out, option in /etc/skel/.profile, which lands in new user 
> directories,
> Professor> which I have never touched the umask part until now.  I 
> uncommented the
> Professor> line to set the users' default umask settings to 022 and 
> updated users
> Professor> already on the system.
>
>
> Just confirming.  You could have modified /etc/login.defs if you chose
> and gotten a similar affect, right?

I think the file to edit is actually /etc/pam.d/common-session, adding
the "nousergroups" option in the line with pam_umask.so.  That is what I
did after reading the pam_umask(8) manpage.

Cheers,
   Sven

Bug#1068662: xsecurelock references wrong xscreensaver location

[Costin Chirvasuta]

Package: xsecurelock

The Debian 12.5 xscreensaver package installs the screensavers under
/usr/libexec/xscreensaver, but the xsecurelock package is configured
using --with-xscreensaver=/usr/lib/xscreensaver. I believe the
xsecurelock package should be updated to configure using
--with-xscreensaver=/usr/libexec/xscreensaver.

Bug#1068661: python3-scikit-build-core: needs Depends: python3-pyproject-metadata

[Drew Parsons]

Package: python3-scikit-build-core
Version: 0.8.2-1
Severity: normal

scikit-build-core imports pyproject_metadata in
/usr/lib/python3/dist-packages/scikit_build_core/settings/metadata.py
but the python3-scikit-build-core does not declare the corresponding
Depends: python3-pyproject-metadata

So the Depends should be added, or possibly
python3-scikit-build-core's pyproject.toml (or setup.py) needs to list
pyproject_metadata as required (then the source package needs
Build-Depends: python3-pyproject-metadata



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

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

Versions of packages python3-scikit-build-core depends on:
ii  python3 [python3-supported-min]  3.11.8-1
ii  python3-exceptiongroup   1.2.0-1
ii  python3-importlib-metadata   4.12.0-1
ii  python3-packaging24.0-1
ii  python3-tomli2.0.1-2
ii  python3-typing-extensions4.10.0-1

python3-scikit-build-core recommends no packages.

python3-scikit-build-core suggests no packages.

-- no debconf information

Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t

[Helmut Grohne]

Control: tags -1 + patch

Hi Aurelien and Canonical folks,

On Tue, Apr 02, 2024 at 08:53:31PM +0200, Aurelien Jarno wrote:
> Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with
> -D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures
> except i386.
> 
> This has been partially fixed in the 2.37-15.1 NMU by adding
> -U_TIME_BITS to CFLAGS, however it causes failures in the testsuite:

There are two subtleties about -U_TIME_BITS in a moment.

> | +-+
> | | Encountered regressions that don't match expected failures. |
> | +-+
> | FAIL: conform/ISO/stdio.h/linknamespace

The detail for this failure is:

| [initial] fgetpos64
| [initial] fopen64
| [initial] freopen64
| [initial] fsetpos64
| [initial] tmpfile64

What linknamespace.py wants to tell us here is that it expected
fgetpos64, but no fgetpos64 was declared. It was not declared, because
there is no difference between fgetpos and fgetpos64 after defining
-D_FILE_OFFSET_BITS=64 (which is also in the default compiler flags).

The other failures are of very similar kind, but there also is another
kind.

> | FAIL: conform/POSIX/sys/stat.h/conform

The detail for this failure contains:

| /tmp/tmpnzda_r9j/test.c:90:35: error: conflicting types for 'b2_8'; have 
'__time64_t' {aka 'long long int'}
|90 | extern __typeof__ (a2_8.st_atime) b2_8;
|   |   ^~~~
| /tmp/tmpnzda_r9j/test.c:89:17: note: previous declaration of 'b2_8' with type 
'__time_t' {aka 'long int'}
|89 | extern __time_t b2_8;
|   | ^~~~

Here, it tells us that it expected the st_atime field of struct stat to
have type __time_t (the 32 bit one), but it really has __time64_t.

Looking at the invocation of linknamespace.py you can see:

| python3 -B linknamespace.py --cc='arm-linux-gnueabihf-gcc-12' 
--flags='-I../include  
-I/build/reproducible-path/glibc-2.37/build-tree/armhf-libc  
-I../sysdeps/unix/sysv/linux/arm/le  -I../sysdeps/unix/sysv/linux/arm  
-I../sysdeps/arm/nptl  -I../sysdeps/unix/sysv/linux/include 
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  
-I../sysdeps/unix/arm  -I../sysdeps/unix  -I../sysdeps/posix  
-I../sysdeps/arm/le/armv7/multiarch  -I../sysdeps/arm/armv7/multiarch  
-I../sysdeps/arm/le/armv7  -I../sysdeps/arm/armv7  -I../sysdeps/arm/armv6t2  
-I../sysdeps/arm/armv6  -I../sysdeps/arm/le  -I../sysdeps/arm/include 
-I../sysdeps/arm  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/flt-32  
-I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754  -I../sysdeps/generic 
-nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabihf/12/include -isystem 
/build/reproducible-path/glibc-2.37/debian/include -I..' ...

In particular, what you do not see is -U_TIME_BITS inside --flags.

> Ubuntu has just ignored those failures for now, but I am just afraid
> that if we do the same, nobody will fix them.

Armed with this knowledge, I think we need two changes. For one thing
debian/sysdeps/linux.mk needs to add -U_FILE_OFFSET_BITS to extra_cflags
to revert any possible ABI changing effects. For another, the
conformance tests use independent compiler flags defined in
conform/Makefile. There, a naive patch seems to be:

-conformtest-cc-flags = -I../include $(+sysdep-includes) $(sysincludes) -I..
+conformtest-cc-flags = -U_FILE_OFFSET_BITS -U_TIME_BITS -I../include 
$(+sysdep-includes) $(sysincludes) -I..

With these two changes, I am able to successfully build glibc on armhf
with the conformance test suite passing.

> In addition it means that upstream glibc does not build anymore by
> default on a 32-bit Debian. Not really a Debian issue, but that is not
> nice either and should probably be fixed.

I think that latter change may be applicable upstream. Running the
conformance test suite with either _FILE_OFFSET_BITS or _TIME_BITS set
is not expected nor supported. This is partially evident from
conform/linknamespace.py in a comment:

| # * Header inclusions should be compiled several times with
| # different options such as -O2, -D_FORTIFY_SOURCE and
| # -D_FILE_OFFSET_BITS=64 to find out what symbols are undefined
| # from such a compilation; this is not yet implemented.

The conformance test suite clearly wants to manage these macros (and its
effects on symbols) explicitly and does not expect them to be
pre-defined.

Hope this helps

Helmut

Bug#1068312: piuparts: Error when Adding 'local diversion of /bin/sync to /bin/sync.distrib.usr-is-merged' (bullseye)

[Helmut Grohne]

Control: tags -1 + confirmd patch
Control: forwarded -1 
https://salsa.debian.org/debian/piuparts/-/merge_requests/56

On Wed, Apr 03, 2024 at 01:40:28PM +0200, Fab Stz wrote:
> I have a CI job on salsa running piuparts with bullseye.
> Recently it started failing with this error:
> 
> 0m4.3s DUMP:
>   Enabling dpkg --force-unsafe-io.
>   Adding 'local diversion of /bin/sync to /bin/sync.distrib.usr-is-merged'
>   ln: failed to create symbolic link '/bin/sync': File exists
> 0m4.3s ERROR: Command failed (status=1): ['chroot', '/tmp/tmpoj1y68a1',
> 'eatmydata', 'tmp/scripts/post_setup_force-unsafe-io']
>   Enabling dpkg --force-unsafe-io.
>   Adding 'local diversion of /bin/sync to /bin/sync.distrib.usr-is-merged'
>   ln: failed to create symbolic link '/bin/sync': File exists
> 
> 
> Maybe this is somehow related to the latest changes in 1.4.1 mentioned as 
> "also fix /bin/sync diversion for bookworm"?

I confirm the problem and understand the failure. Mea culpa.

When I adapted the code for bookworm (which is /usr-merged, but has
/bin/sync), I failed to notice that I also conditionalized the moving
code, so the unmerged-/usr path would now divert with --no-rename and
not move /bin/sync either. That makes ln unhappy as we can see.

I've created a merge request to address this regression and am sorry for
having broken piuparts so many times.

Helmut

Bug#1065806: pam: recent upgrade changes previous default umask

[Sam Hartman]

> "Professor" == Professor Jeebs  writes:


Professor> I prefer the way it is handled per user.  There is a related, 
commented
Professor> out, option in /etc/skel/.profile, which lands in new user 
directories,
Professor> which I have never touched the umask part until now.  I 
uncommented the
Professor> line to set the users' default umask settings to 022 and updated 
users
Professor> already on the system.


Just confirming.  You could have modified /etc/login.defs if you chose
and gotten a similar affect, right?

Bug#1068569: RM: nfs-ganesha-ceph [armel armhf i386] -- NBS; ceph dropped 32 bit support

[Christoph Martin]

Hi Adam,

Am 08.04.24 um 19:15 schrieb Adam D. Barratt:

On Mon, 2024-04-08 at 11:42 +0200, Christoph Martin wrote:

Hi Sebastian,

the packages are already removed from testing and unstable.
Where do you see a problem?


I'm not Sebastian, but the archive disagrees with you about the
packages having been removed from unstable.

adsb@coccia:~$ dak ls -s unstable -a armel,armhf,i386 nfs-ganesha-ceph 
nfs-ganesha-rados-grace nfs-ganesha-rgw
nfs-ganesha-ceph| 4.3-5 | unstable   | armel, armhf, i386
nfs-ganesha-rados-grace | 4.3-5 | unstable   | armel, armhf, i386
nfs-ganesha-rgw | 4.3-5 | unstable   | armel, armhf, i386


Thanks for your reply. I only took a look at the current version in 
unstable and testing. And this is 4.3-8 with binaries for amd64 arm64 
mips64el ppc64el riscv64 s390x.


So the issue is, that the leftover binaries from version 4.3-5 are still 
in the archive.


Regards
Christoph


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068474: yforth segfaults immediately on launching

[Sudip Mukherjee]

On Sat, 6 Apr 2024 at 00:50, Bdale Garbee  wrote:
>
> Sudip Mukherjee  writes:
>
> > yforth is causing a segfault immediately on startup.
>
> Thanks for the bug report.  I haven't had reason to use yforth in many
> years, (the package was last updated on 11 October 2012), so I hadn't
> noticed!

I dont use forth, just happened to notice the bug reported in Ubuntu.

>
> My guess is that this is a simple 64-bit system incompatibility, as a
> quick rebuild of the package on my current 64-bit laptop yields a large
> number of warnings about casts of pointer from integer of different size...

I tried to debug it, the first segfault is at
https://sources.debian.org/src/yforth/0.2.1-1/search.c/#L84 and is
caused by "_align();" at
https://sources.debian.org/src/yforth/0.2.1-1/search.c/#L81 which
completely changed the address and so it now tried to set NULL to an
invalid location.
I stopped after seeing there are many such macros like "_align()"
which are modifying the pointers and imho, it will be a nightmare to
fix it.


-- 
Regards
Sudip

Bug#1068660: mpv: No sound. Please backport upstream patch.

[Roman Lebedev]

Package: mpv
Version: 0.37.0-1+b1
Severity: important
Tags: upstream
X-Debbugs-Cc: maril...@deb-multimedia.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainers,
an upstream fix for https://github.com/mpv-player/mpv/pull/13665
which was not yet released in any mpv version needs to be backported
to the current mpv version, looks like the problematic ffmpeg version
is finally in debian (or deb-multimedia, but still.), resulting in no audio:
```
AO: [pipewire] 48000Hz 5.1(side) 6ch floatp
VO: [gpu] 1920x960 yuv420p10
[ffmpeg] SWR: Input channel layout "" is invalid or unsupported.
[swresample] Cannot open Libavresample context.
[swresample] libswresample failed to initialize.
Cannot convert decoder/filter output to any format supported by the
output.
Audio: no audio
```

Roman.


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

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

Versions of packages mpv depends on:
ii  libarchive13t64   3.7.2-2
ii  libasound2t64 1.2.11-1+b1
ii  libass9   2:0.17.1-dmo1
ii  libavcodec60  10:6.1.1-dmo4
ii  libavdevice60 10:6.1.1-dmo4
ii  libavfilter9  10:6.1.1-dmo4
ii  libavformat60 10:6.1.1-dmo4
ii  libavutil58   10:6.1.1-dmo4
ii  libbluray22:1.3.4-dmo2
ii  libc6 2.37-15.1
ii  libcaca0  0.99.beta20-4+b1
ii  libcdio-cdda2t64  10.2+2.0.1-1.1
ii  libcdio-paranoia2t64  10.2+2.0.1-1.1
ii  libcdio19t64  1:2.1.0-dmo5
ii  libdrm2   2.4.120-2
ii  libdvdnav46.1.1-3
ii  libegl1   1.7.0-1
ii  libgbm1   24.0.4-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3+b3
ii  libjpeg62-turbo   1:2.1.5-2+b2
ii  liblcms2-22.14-2+b1
ii  liblua5.2-0   5.2.4-3+b2
ii  libmujs3  1.3.3-3+b2
ii  libpipewire-0.3-0t64  1.0.4-3
ii  libplacebo338 2:6.338.2-dmo2
ii  libpulse0 16.1+dfsg1-5
ii  librubberband21:3.3.0-dmo1
ii  libsdl2-2.0-0 2.30.1+dfsg-4
ii  libsixel1 1.10.3-3
ii  libswresample410:6.1.1-dmo4
ii  libswscale7   10:6.1.1-dmo4
ii  libuchardet0  0.0.8-1+b1
ii  libva-drm22.20.0-2
ii  libva-wayland22.20.0-2
ii  libva-x11-2   2.20.0-2
ii  libva22.20.0-2
ii  libvdpau1 1.5-2
ii  libvulkan11.3.275.0-1
ii  libwayland-client01.22.0-2.1+b1
ii  libwayland-cursor01.22.0-2.1+b1
ii  libwayland-egl1   1.22.0-2.1+b1
ii  libx11-6  2:1.8.7-1
ii  libxext6  2:1.3.4-1+b1
ii  libxkbcommon0 1.6.0-1
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.4-1
ii  libxss1   1:1.2.3-1
ii  libxv12:1.0.11-1.1
ii  libzimg2  1:3.0.5-dmo1
ii  zlib1g1:1.3.dfsg-3.1

Versions of packages mpv recommends:
ii  xdg-utils  1.1.3-4.1
ii  yt-dlp 1:2024.03.10-dmo1

Versions of packages mpv suggests:
pn  libcuda1  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+UikBxeiu50LOdFYgbqkFMWfZdAFAmYUTjkACgkQgbqkFMWf
ZdABUQ/+Jj/yPCK2rT0auFHxe+NuyCeYNCkGK3l+i7pTrZlTzksQhcJqy+eRX1Ey
UEn7QJrWYt0BdjxMezUbL1Ayf4hCNltUerWReq4pglX5PaDWowX44Gzzo1jW0GG0
kr73AzYl289vIR3mCtrvU1KGOzyoYHL6/XWee9XG2lf3LQeHfnY8DqXvnfV8xWOu
+TL2Omvve1DIlitKYwHVkxR08wl8V5h/gXvlq7nk6JHcqtjCA50ksdqQEk8r22P9
+jTi14wIZHHYjepjg4g/ICO15B3GPWDyxfKuHBxXA8O5iexFqGV8vJKwMjoZhTdW
rTIJQSXSctCvKqEFamnkSPMYKtXzRhyYIqo4ixvMebrZREMMai9mZK5hklpNvPZg
MfbKrs3TZlRVSyMEGUhBFIfnGW+uzu/J9jliZs6uwx9F95qEnjfw0hC3kkGSEUcr
7IvSBwHt3SXnmqsGjf6s6BXIIiItYD8bkzBVpOqUtfumYY32ICJNtH/tkCQ03vlS
IRahoNYvF+bSBkJy6wDRT1irzr07xM4u/BLp7mDj9ap2epZP0AHMG9xLfcV1kKBq
pzYvpIyya4gnMNJ7eIYAkHHCs9ww4YJRXwnnJlhgSnWtBa1qrjS7YictadcFCkeo
7KXDBzzJEtGAENCxM/RjiUHSwWUcnOa8Q0x0pSKcbeDNa8GtwJY=
=ymIu
-END PGP SIGNATURE-

Bug#1068631: linux-image-6.6.15-amd64: Using monitor refreshrate above 120Hz i get random black screen for a few seconds at certain actions

[Diederik de Haas]

Control: forcemerge -1 1054889

On Monday, 8 April 2024 10:44:12 CEST dada007 wrote:
>  I had an earlier report with this bug

No need to have 2 bugs for the same problem, thus merging

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

Bug#1068633: bookworm-pu: package cjson/1.7.15-1+deb12u1

[Salvatore Bonaccorso]

Hi,

Disclaimer, this is not an authoritative answer as I'm not part of the
stable release managers.

On Mon, Apr 08, 2024 at 12:27:50PM +0300, Maytham Alsudany wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: cj...@packages.debian.org
> Control: affects -1 + src:cjson
> 
> [ Reason ]
> CVE-2023-50472, CVE-2023-50471
> 
> [ Impact ]
> Segmentation violation via the function cJSON_InsertItemInArray at cJSON.c
> 
> [ Tests ]
> Upstream's test continue to pass, and they have also added new tests to
> cover this security issue.
> 
> [ Risks ]
> Minimal, no change to API. Only minimal changes were made to fix this
> security issue.
> 
> [ Checklist ]
>   [x] *all* changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in (old)stable
>   [x] the issue is verified as fixed in unstable
> 
> [ Changes ]
> - Set myself as Maintainer (I am adopting the package, #1067510)
> - Bump Standards-Version to 4.6.2
> - Add Build-Depends-Package to symbools
> - Backport upstream's patch to 'add NULL checkings'.
>   Upstream adds a few more if statements to avoid the segmentation
>   fault, and thus resolve the security vulnerability.
> 
> [ Other info ]
> If you can spare the time, could you please upload this for me? (I need
> a sponsor, #1068624.) I'm also still waiting for someone to give me
> access to the Salsa repo.
> 
> Thanks,
> Maytham

> diff -Nru cjson-1.7.15/debian/changelog cjson-1.7.15/debian/changelog
> --- cjson-1.7.15/debian/changelog 2021-08-29 23:30:06.0 +0300
> +++ cjson-1.7.15/debian/changelog 2024-04-03 06:57:10.0 +0300
> @@ -1,3 +1,13 @@
> +cjson (1.7.15-1+deb12u1) bookworm-security; urgency=medium

The target distribution should be simply bookworm.

> +
> +  * Update Maintainer field
> +  * Bump Standards-Version to 4.6.2 (no changes)

This is usually not allowed to do in a stable update.

> +  * Backport patch to add NULL checkings (CVE-2023-50472, CVE-2023-50471)
> +(Closes: #1059287)
> +  * Add Build-Depends-Package to symbols

While this might be sensible, I'm not sure if SRM will accept it.

So you might want to adjust already the things above and seek for an
ack from SRM.

Regards,
Salvatore

Bug#1068659: O: mwclient -- MediaWiki API client in Python

[Håvard F . Aasen]

Package: wnpp
Severity: normal
X-Debbugs-Cc: mwcli...@packages.debian.org, havard.f.aa...@pfft.no
Control: affects -1 + src:mwclient

I intend to orphan the mwclient package.

The last upstream release was in 2020, lateley there has been some minor
activity.

Previosly maintainer was DPT and I was the sole uploader, no one
in the team wanted to take over maintenance [1].

The package description is:
 mwclient is a lightweight Python client library to the MediaWiki API
 which provides access to most API functionality. It works with Python
 2.7, 3.3 and above, and supports MediaWiki 1.16 and above. For
 functions not available in the current MediaWiki, a
 MediaWikiVersionError is raised.
 .
 Most properties and generators accept the same parameters as the API,
 without their two-letter prefix. Exceptions to this rule:
 .
  * Image.imageinfo is the imageinfo of the latest image. Earlier
versions can be fetched using imagehistory()
  * Site.all*: parameter  [ap]from renamed to start
  * categorymembers is implemented as Category.members
  * deletedrevs is deletedrevisions
  * usercontribs is usercontributions
  * First parameters of search and usercontributions are search and
user respectively
 .
 Properties and generators are implemented as Python generators. Their
 limit parameter is only an indication of the number of items in one
 chunk. It is not the total limit. Doing list(generator(limit =
 limit)) will return ALL items of generator, and not be limited by the
 limit value. Default chunk size is generally the maximum chunk size.


[1] https://lists.debian.org/debian-python/2024/03/msg00131.html

Bug#1068658: openssl: CVE-2024-2511

[Salvatore Bonaccorso]

Source: openssl
Version: 3.2.1-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.1.5-1
Control: found -1 3.0.11-1~deb12u2

Hi,

The following vulnerability was published for openssl.

CVE-2024-2511[0]:
| Issue summary: Some non-default TLS server configurations can cause
| unbounded memory growth when processing TLSv1.3 sessions  Impact
| summary: An attacker may exploit certain server configurations to
| trigger unbounded memory growth that would lead to a Denial of
| Service  This problem can occur in TLSv1.3 if the non-default
| SSL_OP_NO_TICKET option is being used (but not if early_data support
| is also configured and the default anti-replay protection is in
| use). In this case, under certain conditions, the session cache can
| get into an incorrect state and it will fail to flush properly as it
| fills. The session cache will continue to grow in an unbounded
| manner. A malicious client could deliberately create the scenario
| for this failure to force a Denial of Service. It may also happen by
| accident in normal operation.  This issue only affects TLS servers
| supporting TLSv1.3. It does not affect TLS clients.  The FIPS
| modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL
| 1.0.2 is also not affected by this issue.


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-2024-2511
https://www.cve.org/CVERecord?id=CVE-2024-2511
[1] https://www.openssl.org/news/secadv/20240408.txt

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1068559: [Pkg-zfsonlinux-devel] Bug#1068559: Bug#1068559: zfs-linux: isolation-machine autopkgtest fails: zfs-test-suite times out (hangs?)

[Paul Gevers]

Hi,

On 08-04-2024 3:51 a.m., 陈 晟祺 wrote:

With resources limited to one CPU (AMD EPYC 7551) and 2G memory,
my local test could now reproduce the test hang and following time out error.


Ouch.


I think it is caused by insufficient resources (e.g. OOM killer, but I am not 
sure).
Even we can work it around, the test process would be still be too slow to 
finish.

Is it possible to allocate more resources for the test? For reference, openzfs 
uses
GitHub-hosted workflow runners [1] for test. Each runner has 2 CPU cores and
7 GB memory, under which configuration the whole test still takes ~4hrs.


Our timeout is 1 seconds, so 2.47 hours, per autopkgtest stanza 
(overall it's 8 hours). If the test is going to take longer, it will 
fail anyways. So maybe it was just still running? I'm a bit hesitant, 
particularly about the memory to make much bigger VM's, because most 
tests don't need it and it limits the amount of VM's we can make. We 
need to strike a nice balance (or fix 
https://salsa.debian.org/ci-team/debci/-/issues/166#note_451831 and add 
zfs-linux to a "huge" list)



If not, is there any way to mark the test as optional (thus not causing RC bug)?
Otherwise our worst choice would be disable the test completely.


Well, if we can't run the test on our infra, we could disable it, but 
what's the point of having the autopkgtest then? (If you split the tests 
over multiple stanza, you get the 2.47 hour per set. Does that help?)


Let me try to see if I can have debci create larger VM's for us and let 
me try your package again. What are the resources you use yourself for 
the test and how long does it take in that case?


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068657: pkcs11-provider FTBFS with openssl 3.2.1-3

[Adrian Bunk]

Source: pkcs11-provider
Version: 0.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=pkcs11-provider=ppc64el=0.3-1%2Bb2=1712517987=0

...
FAIL: basic-softhsm
===

Executing ./tbasic

## Raw Sign check error
 openssl 
pkeyutl -sign -inkey "${BASEURI}"
  -pkeyopt pad-mode:none
  -in ${TMPPDIR}/64Brandom.bin
  -out ${TMPPDIR}/raw-sig.bin
Public Key operation error
00493C8EFF7F:error:027A:rsa routines:p11prov_sig_operate:data too small 
for key size:signature.c:894:


## Sign and Verify with provided Hash and RSA
 openssl dgst -sha256 -binary -out ${TMPPDIR}/sha256.bin ${SEEDFILE}

 openssl 
pkeyutl -sign -inkey "${PRIURI}"
  -in ${TMPPDIR}/sha256.bin
  -out ${TMPPDIR}/sha256-sig.bin

 openssl 
pkeyutl -verify -inkey "${PUBURI}"
-pubin
-in ${TMPPDIR}/sha256.bin
-sigfile ${TMPPDIR}/sha256-sig.bin
Signature Verified Successfully

## Sign and Verify with provided Hash and RSA with DigestInfo struct
 openssl dgst -sha256 -binary -out ${TMPPDIR}/sha256.bin ${SEEDFILE}

 openssl 
pkeyutl -sign -inkey "${PRIURI}" -pkeyopt digest:sha256
  -in ${TMPPDIR}/sha256.bin
  -out ${TMPPDIR}/sha256-sig.bin

 openssl 
pkeyutl -verify -inkey "${PUBURI}" -pkeyopt digest:sha256
-pubin
-in ${TMPPDIR}/sha256.bin
-sigfile ${TMPPDIR}/sha256-sig.bin
Signature Verified Successfully

## DigestSign and DigestVerify with RSA
 openssl 
pkeyutl -sign -inkey "${BASEURI}"
  -digest sha256
  -in ${RAND64FILE}
  -rawin
  -out ${TMPPDIR}/sha256-dgstsig.bin

 openssl 
pkeyutl -verify -inkey "${BASEURI}" -pubin
-digest sha256
-in ${RAND64FILE}
-rawin
-sigfile ${TMPPDIR}/sha256-dgstsig.bin
Signature Verified Successfully
 openssl 
pkeyutl -verify -inkey "${PUBURI}"
-pubin
-digest sha256
-in ${RAND64FILE}
-rawin
-sigfile ${TMPPDIR}/sha256-dgstsig.bin
Signature Verified Successfully
RSA basic encrypt and decrypt
 openssl 
pkeyutl -encrypt -inkey "${PUBURI}" -pubin
 -in ${SECRETFILE}
 -out ${SECRETFILE}.enc

 openssl 
pkeyutl -decrypt -inkey "${PRIURI}"
 -in ${SECRETFILE}.enc
 -out ${SECRETFILE}.dec


## Test Disallow Public Export
 openssl pkey -in $PUBURI -pubin -pubout -text

## Test CSR generation from RSA private keys
 openssl 
req -new -batch -key "${PRIURI}" -out ${TMPPDIR}/rsa_csr.pem

 openssl 
req -in ${TMPPDIR}/rsa_csr.pem -verify -noout
Certificate request self-signature verify OK

## Test fetching public keys without PIN in config files
 openssl pkey -in $PUBURI -pubin -pubout -out ${TMPPDIR}/rsa.pub.nopin.pem

 openssl pkey -in $ECPUBURI -pubin -pubout -out ${TMPPDIR}/ec.pub.nopin.pem

 openssl pkey -in $ECXPUBURI -pubin -pubout -out ${TMPPDIR}/ecx.pub.nopin.pem


## Test fetching public keys with a PIN in URI
 openssl pkey -in $BASEURIWITHPIN -pubin -pubout -out 
${TMPPDIR}/rsa.pub.uripin.pem

 openssl pkey -in $ECBASEURIWITHPIN -pubin -pubout -out 
${TMPPDIR}/ec.pub.uripin.pem

 openssl pkey -in $ECXBASEURIWITHPIN -pubin -pubout -out 
${TMPPDIR}/ecx.pub.uripin.pem


## Test prompting without PIN in config files

## Test EVP_PKEY_eq on public RSA key both on token

## Test EVP_PKEY_eq on public EC key both on token

## Test EVP_PKEY_eq on public explicit EC key both on token
Failed to load key from URI: pkcs11:type=public;id=%00%07

FAIL basic-softhsm.t (exit status: 1)
...

Testsuite summary for pkcs11-provider 0.3

# TOTAL: 34
# PASS:  15
# SKIP:  18
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log
Please report to s...@redhat.com

make[4]: *** [Makefile:1070: test-suite.log] Error 1

Bug#1068656: pgsql-http accesses the internet during the build

[Adrian Bunk]

Source: pgsql-http
Version: 1.6.0-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Debian PostgreSQL Maintainers 

https://buildd.debian.org/status/fetch.php?pkg=pgsql-http=arm64=1.6.0-1=1712600451=0

...
 regression.diffs 
diff -U3 /<>/expected/http.out /<>/results/http.out
--- /<>/expected/http.out  2023-08-10 16:17:30.0 +
+++ /<>/results/http.out   2024-04-08 18:20:45.564039027 +
@@ -9,11 +9,7 @@
 -- Status code
 SELECT status
 FROM http_get('https://httpbun.org/status/202');
- status 
-
-202
-(1 row)
-
+ERROR:  Could not resolve host: httpbun.org
...

Bug#1068631: linux-image-6.6.15-amd64: Using monitor refreshrate above 120Hz i get random black screen for a few seconds at certain actions

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Mon, Apr 08, 2024 at 04:44:12PM +0800, dada007 wrote:
> Package: src:linux
> Version: 6.6.15-2
> Severity: important
> X-Debbugs-Cc: peter_malmb...@proton.me
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation? has been the same problem since kernel 6.5
> came out, just opening a browser with or another app makes the screen go 
> black,
> like it is switching mode or graphics card or something. Not all apps give 
> this
> problem, but many.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? I had an earlier report with this bug. I came in contact
> with Diederik de Haas, he told me to install apt install ./linux-
> image-6.5.0-0-rt-amd64_6.5~rc4-1~exp1_amd64.deb, I did and with that kernel
> there was no problem. But i guess it never got upstreamed to the next real
> kernel?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***

Can you confirm, does the same happen with the kernel currently in
unstable? (6.7.9-2).

Regards,
Salvatore

Bug#1068543: [Pkg-swan-devel] Bug#1068543: strongswan: isolation-machine autopkgtest fails: starter IS NOT RUNNING

[Paul Gevers]

Hi Yves-Alexis,

On 08-04-2024 10:13 a.m., Yves-Alexis Perez wrote:

thanks for the report. I might try to investigate a bit but at that point
honestly I don't have much clue what happens.


Can we try and find out together?


Could you please provide a bit more context in the bug report so we have a bit
more data?


What kind of context are you looking for? Your package has an 
autopkgtest (which I assume was added such that it can run). It declares 
a isolation-machine restriction, so until yesterday, the test was never 
executed on ci.debian.net. I just realized that I could have looked at 
Ubuntu too, which uses qemu already longer. The test passes there, so 
we're looking for delta's.



Because at that point I didn't really ask for anything and you're
making your problem my problem, which doesn't feel really fair, to be honest.


It makes me sad that you see it like that. I had the impression I was 
running ci.d.n as a service to Debian maintainers.



And if enabling isolation-machine breaks the test, then maybe isolation-
machine needs to be fixed, or just not enabled?


Enabling isolation-machine doesn't break tests. It enables more tests to 
run and the test that previously didn't run now fails. Now I think we 
should be interested to learn why (personally even more so because it 
passes on Ubuntu's infrastructure [1]). Honestly, looking at the log it 
appeared to me that the test was never tried and you simple had 
forgotten to start the daemon, but given it works in Ubuntu, might this 
be a race condition?



I cant say for sure but it
looks like the easiest way for me.


If you don't want your isolation-machine restricted tests to run, I can 
trivially disable it again. I was rather hoping to fix either the test, 
or the setup at ci.d.n or both.


Paul

[1] https://autopkgtest.ubuntu.com/packages/s/strongswan


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068368: Removed package(s) from unstable

[Andreas Beckmann]

Control: retitle -1 RM: python3.10 -- RoM; superseded by 3.11 and 3.12

On Fri, 05 Apr 2024 18:00:35 + Debian FTP Masters 
 wrote:

We believe that the bug you reported is now fixed; the following
package(s) have been removed from unstable:

   and |  1.2.2-4.2 | source, amd64, arm64, armel, armhf, i386, mips64el, 
ppc64el, s390x
   and | 1.2.2-4.2+b1 | riscv64
idle-python3.10 |  3.10.13-1 | all
libpython3.10 | 3.10.13-1+b3 | amd64, arm64, armel, armhf, i386, ppc64el, s390x
libpython3.10 | 3.10.13-1+b4 | mips64el, riscv64

...> python3.10 |  3.10.13-1 | source

python3.10 | 3.10.13-1+b3 | amd64, arm64, armel, armhf, i386, ppc64el, s390x
python3.10 | 3.10.13-1+b4 | mips64el, riscv64

...

python3.10-venv | 3.10.13-1+b3 | amd64, arm64, armel, armhf, i386, ppc64el, 
s390x
python3.10-venv | 3.10.13-1+b4 | mips64el, riscv64

--- Reason ---
3.12
--


The python3.10 removal accidentally caused the removal of 'and', too, 
most likely because of the non-standard subject line that got misparsed.

(Hint: Using reportbug would have helped to get that formatted correctly.)


Andreas

PS: I've just NMUed 'and' back into sid, waiting in NEW.
PPS: I noticed this unwanted removal by chance when looking for the 
python3.10 removal bug to reference that when closing the leftover bugs 
from python3.10.

PPPS: I have no interest at all in 'and'

Bug#1068655: lomiri-telephony-service FTBFS with abseil 20230802.1

[Adrian Bunk]

Source: lomiri-telephony-service
Version: 0.5.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=lomiri-telephony-service=amd64=0.5.3-1%2Bb3=1712518065=0

...
/<>/libtelephonyservice/contactwatcher.cpp: In member function 
‘void ContactWatcher::updateAlias()’:
/<>/libtelephonyservice/contactwatcher.cpp:157:21: error: 
‘dgettext’ is not a member of ‘C’; did you mean ‘dgettext’?
  157 | setAlias(C::dgettext("telephony-service", "Private Number"));
  | ^~~~
In file included from 
/usr/include/x86_64-linux-gnu/c++/13/bits/messages_members.h:36,
 from /usr/include/c++/13/bits/locale_facets_nonio.h:2064,
 from /usr/include/c++/13/locale:43,
 from /usr/include/c++/13/iomanip:45,
 from /usr/include/absl/strings/internal/str_format/arg.h:23,
 from /usr/include/absl/strings/str_format.h:78,
 from /usr/include/absl/crc/crc32c.h:32,
 from /usr/include/absl/crc/internal/crc_cord_state.h:23,
 from /usr/include/absl/strings/cord.h:79,
 from 
/usr/include/absl/container/internal/hash_function_defaults.h:56,
 from /usr/include/absl/container/node_hash_set.h:42,
 from /usr/include/phonenumbers/phonenumberutil.h:33,
 from /<>/libtelephonyservice/phoneutils.h:27,
 from 
/<>/libtelephonyservice/contactwatcher.cpp:25:
/usr/include/libintl.h:44:14: note: ‘dgettext’ declared here
   44 | extern char *dgettext (const char *__domainname, const char *__msgid)
  |  ^~~~
/<>/libtelephonyservice/contactwatcher.cpp:159:21: error: 
‘dgettext’ is not a member of ‘C’; did you mean ‘dgettext’?
  159 | setAlias(C::dgettext("telephony-service", "Unknown Number"));
  | ^~~~
/usr/include/libintl.h:44:14: note: ‘dgettext’ declared here
   44 | extern char *dgettext (const char *__domainname, const char *__msgid)
  |  ^~~~
...

Bug#1068654: bookworm-pu: package bioawk/1.0-4+deb12u1

[Santiago Vila]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: bio...@packages.debian.org, sanv...@debian.org
Control: affects -1 + src:bioawk

[ Reason ]
Fix random FTBFS bug (#1068341).

[ Impact ]
Any user who tries to build from source using more than one CPU
may find that the package unexpectedly FTBFS in a random way.

[ Tests ]
I've built the package in unstable a lot of times, and it does
no longer FTBFS randomly.

[ Risks ]
Very low, given that the fix is to add --no-parallel to dh invocation.

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

[ Changes ]
Add --no-parallel to dh invocation.

[ Other info ]
I'm going to make the upload now, but will wait for confirmation before
pushing to salsa.diff -Nru bioawk-1.0/debian/changelog bioawk-1.0/debian/changelog
--- bioawk-1.0/debian/changelog 2021-03-17 17:53:42.0 +0100
+++ bioawk-1.0/debian/changelog 2024-04-08 19:40:00.0 +0200
@@ -1,3 +1,11 @@
+bioawk (1.0-4+deb12u1) bookworm; urgency=medium
+
+  * Team upload.
+  * debian/rules: Add --no-parallel to avoid the effects of a Makefile bug 
which
+makes the package to FTBFS randomly. Closes: #1068341.
+
+ -- Santiago Vila   Mon, 08 Apr 2024 19:40:00 +0200
+
 bioawk (1.0-4) unstable; urgency=medium
 
   * d/p/cross.patch: Fix non-cross buildability
diff -Nru bioawk-1.0/debian/rules bioawk-1.0/debian/rules
--- bioawk-1.0/debian/rules 2021-03-17 17:53:42.0 +0100
+++ bioawk-1.0/debian/rules 2024-04-08 19:39:55.0 +0200
@@ -5,7 +5,7 @@
 include /usr/share/dpkg/buildtools.mk
 
 %:
-   dh $@
+   dh $@ --no-parallel
 
 override_dh_auto_configure:
 

Bug#1068637: apt does not always install Recommends

[David Kalnischkies]

On Mon, Apr 08, 2024 at 01:05:40PM +0200, Vincent Lefevre wrote:
> On 2024-04-08 12:29:17 +0200, Julian Andres Klode wrote:
> > On Mon, Apr 08, 2024 at 11:50:04AM +0200, Vincent Lefevre wrote:
> > > The lvm2 package is installed, but not thin-provisioning-tools,
> > > though lvm2 recommends it. This can yield a broken system:
[…]
> It is not mandatory in all cases, but it some cases. In any case,
> the "Recommends:" must be honored.

You haven't mentioned AT ALL if we are talking about upgrade or a fresh
install of lvm2, for the later see below. For the former:

Are you absolutely, positively sure that you haven't ignored apt
(aptitude) telling you that it wont install that recommends while
installing lvm2?

APT (and aptitude?) do not install old unsatisfied recommends on an
upgrade, so the only way of not getting thin-provisioning-tools
installed is either to not have it installed while it was new in which
case apt (and I think aptitude has somewhat similar) output contains:
| Recommended packages:
|  thin-provisioning-tools
Same for Suggests btw which aren't installed by default (but lvm2 has
none). Or you have removed thin-provisioning-tools at some point after
it was once installed.

And yes, as Julian explained, if a package is not installable, that
also leads to a recommends not being installed but same output.

(I somewhat doubt you have managed to install an lvm2 which had not yet
 a recommends on thin-provisioning-tools and upgraded that now to
 a version with that recommends. That would be a new recommends that apt
 tries to install, but might fail for reasons Julian mentioned already.
 Different upgrade-commands-implementations have different approaches to
 that – 'apt upgrade' e.g. tries to detect that and holds the upgrade
 off it does, while 'apt full-upgrade' ignores that. Both work better
 if the archive is a stable state… which tends to be the case with
 stable for obvious reasons. Less so for unstable.)


> No, lvm2 was installed before the time_t transition. It actually
> affects plain bookworm installations (on a machine where I installed
> Debian 12.1 on 2023-10-07); you can see with the attached
> "dpkg --get-selections" output I had at that time.
  

What time? Before you installed lvm2? That output says lvm2 is
installed. So after it, but what are you trying to tell us then?

That you had lvm2 installed, upgraded it and it still didn't install
thin-provisioning-tools? Well, as explained above, working as intended.


I just bootstrapped a minimal stable chroot with mmdebstrap and behold:
| # apt install --install-recommends lvm2
| Reading package lists... Done
| Building dependency tree... Done
| Reading state information... Done
| The following additional packages will be installed:
|   dmeventd dmsetup libaio1 libdevmapper-event1.02.1 libdevmapper1.02.1 
liblvm2cmd2.03 thin-provisioning-tools
| The following NEW packages will be installed:
|   dmeventd dmsetup libaio1 libdevmapper-event1.02.1 libdevmapper1.02.1 
liblvm2cmd2.03 lvm2 thin-provisioning-tools
| 0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
| Need to get 2662 kB of archives.
| After this operation, 9729 kB of additional disk space will be used.
| Do you want to continue? [Y/n] n
| Abort.

In other words your issue with a "plain bookworm" install is
unreproducible (My chroots are configured to not install recommends by
default, so I enable it explicitly on the command line here. There is no
difference in behaviour for apt. I think aptitude reacts differently, but
who knows). If I leave out the flag apt tells me it wont install the
recommends as shown above. What am I doing wrong, where is the bug?


So, if you want to have any chance of us investigating your problem as
a bug rather than as a user-error you will have to tell us what you did
exactly, preferably with easy to follow steps and output. Failing that,
on your bookworm install you might be lucky and still have the
installation/upgrade and such of lvm2 in your history.log(s).
That might shine some light on it as well.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1051024: bookworm-pu: package igtf-policy-bundle/1.22-1~deb12u1

[Adam D. Barratt]

On Mon, 2024-04-08 at 14:26 +0200, Dennis van Dok wrote:
> I've uploaded a new version since unstable is already at 1.128-1.

The package you've uploaded is versioned 1.128-1+deb12u1, which is
higher than the version in unstable. The stable upload needs to have a
lower version number, conventionally 1.128-1~deb12u1.

It appears you've also uploaded a 1.128-1~deb12u1 package, which
confusingly seems to be a rebuild of 1.12_7_-1 from unstable.

I'm going to flag both uploads for rejection. Once you get confirmation
of that having been actioned, if what you're actually aiming for is to
get a rebuild of 1.128-1 into stable then please:
- use 1.128-1~deb12u1 as the package version
- attach a revised debdiff to this bug

Regards,

Adam

Bug#1067233: python-pomegranate: autopkgtest regression with NumPy 1.26

[Graham Inggs]

Control: tags -1 + patch

Hi Maintainer

The attached patch fixes the test failures for me.

I noticed in this package's changelog that its only purpose is to work
with cnvkit.  I have not tested whether cnvkit still functions with
this patch in place.

Regards
Graham
Description: Only compare init as a string after determining its type
 Avoids the following with error NumPy 1.26:
 ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
Bug-Debian: https://bugs.debian.org/1067233
Author: Graham Inggs 
Last-Update: 2024-04-06

--- a/pomegranate/kmeans.pyx
+++ b/pomegranate/kmeans.pyx
@@ -229,10 +229,6 @@
 
 	def __init__(self, k, init='kmeans++', n_init=10):
 		self.k = k
-		if init != 'first-k':
-			self.n_init = n_init
-		else:
-			self.n_init = 1
 		self.centroid_norms =  calloc(self.k, sizeof(double))
 
 		if isinstance(init, (list, numpy.ndarray)):
@@ -246,8 +242,14 @@
 self.centroid_norms[i] = self.centroids[i].dot(self.centroids[i])
 
 			self.init = 'fixed'
+			self.n_init = n_init
 		elif isinstance(init, str):
 			self.init = init
+			if init != 'first-k':
+self.n_init = n_init
+			else:
+self.n_init = 1
+
 
 	def __dealloc__(self):
 		free(self.centroid_norms)

Bug#1068569: RM: nfs-ganesha-ceph [armel armhf i386] -- NBS; ceph dropped 32 bit support

[Adam D. Barratt]

On Mon, 2024-04-08 at 11:42 +0200, Christoph Martin wrote:
> Hi Sebastian,
> 
> the packages are already removed from testing and unstable.
> Where do you see a problem?

I'm not Sebastian, but the archive disagrees with you about the
packages having been removed from unstable.

adsb@coccia:~$ dak ls -s unstable -a armel,armhf,i386 nfs-ganesha-ceph 
nfs-ganesha-rados-grace nfs-ganesha-rgw 
nfs-ganesha-ceph| 4.3-5 | unstable   | armel, armhf, i386
nfs-ganesha-rados-grace | 4.3-5 | unstable   | armel, armhf, i386
nfs-ganesha-rgw | 4.3-5 | unstable   | armel, armhf, i386

Regards,

Adam

Bug#1067845: adduser: Reserving uid/gid from the uid/gid pools

[Marc Haber]

On Mon, Apr 01, 2024 at 04:49:40PM +0300, Yair Yarom wrote:
> Attached is a patch to uidgidpool.t that tests several cases of the
> reserved uids.
> I'm not really proficient in these test tools, so I hope it works
> properly...

Thank you! I'll try those in the next weeks. Unfortunately, quite busy
at the moment.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Salvatore Bonaccorso]

Hi Sebastian,

On Mon, Apr 08, 2024 at 06:43:01PM +0200, Sebastian Andrzej Siewior wrote:
> control: tags -1 patch
> control: reassign -1 yapet 2.6-1
> 
> On 2024-04-08 08:32:58 [+0200], Kurt Roeckx wrote:
> > There might be a related change that doesn't allow restarting the
> > operation with the same context without setting things up again.
> 
> Yapet is broken and the openssl update revealed the problem. I
> reassigned it to yapet 2.6 but probably affects earlier versions.
> But then the 1.1.1 series is no longer maintained so…
> 
> Patches attached and they hold the details of why and such.
> 
> This needs to be applied to unstable and Bookworm.
> The testsuite passes and I can open Sean's test file.
> Further testing is welcome by actual users ;)

Thanks for the investigation and bringing the fixes to upstream
already: https://github.com/RafaelOstertag/yapet/pull/29
> 
> I can NMU if needed just yell.

No need for that, will take it with my maintainers hat on from here.

Regards,
Salvatore

Bug#1067234: symfit: autopkgtest regression with NumPy 1.26

[Graham Inggs]

Control: tags -1 + patch

Hi Maintainer

While asserting that no warnings are raised is a useful test for the
upstream developers, I don't think it makes sense for downstreams.

I propose to disable the assertion as follows:

--- a/tests/test_minimizers.py
+++ b/tests/test_minimizers.py
@@ -117,7 +117,7 @@
 # Should no longer raise warnings, because internally we practice
 # what we preach.
 fit_custom = BFGS(chi_squared, [a, b])
-assert len(recwarn) == 0
+#assert len(recwarn) == 0

 fit_custom_result = fit_custom.execute()

Please let me know if you are happy with a team upload and I will proceed.
As a bonus, I attach a patch that fixes several SyntaxWarnings that
occur with Python 3.12.

Regards
Graham
Description: Fix several SyntaxWarnings
 Use raw strings to avoid invalid escape sequence
Author: Graham Inggs 
Last-Update: 2024-04-06

--- a/symfit/core/operators.py
+++ b/symfit/core/operators.py
@@ -45,7 +45,7 @@
 # return orig_ne(self.__class__, other)
 
 def call(self, *values, **named_values):
-"""
+r"""
 Call an expression to evaluate it at the given point.
 
 Future improvements: I would like if func and signature could be buffered after the
--- a/symfit/core/support.py
+++ b/symfit/core/support.py
@@ -293,7 +293,7 @@
 return jac
 
 def key2str(target):
-"""
+r"""
 In ``symfit`` there are many dicts with symbol: value pairs.
 These can not be used immediately as \*\*kwargs, even though this would make
 a lot of sense from the context.
@@ -321,4 +321,4 @@
 base_str += 'd{}{}'.format(var,  count if count > 1 else '')
 return base_str
 
-sympy.Derivative.name = property(name)
\ No newline at end of file
+sympy.Derivative.name = property(name)
--- a/symfit/core/fit.py
+++ b/symfit/core/fit.py
@@ -29,7 +29,7 @@
 from the model.
 """
 def __init__(self, model, *ordered_data, absolute_sigma=None, **named_data):
-"""
+r"""
 :param model: (dict of) sympy expression or ``Model`` object.
 :param bool absolute_sigma: True by default. If the sigma is only used
 for relative weights in your problem, you could consider setting it to
--- a/symfit/core/minimizers.py
+++ b/symfit/core/minimizers.py
@@ -208,7 +208,7 @@
 :class:`~symfit.core.minimizers.DifferentialEvolution`.
 """
 def __init__(self, *args, minimizers=None, **kwargs):
-'''
+r'''
 :param minimizers: a :class:`~collections.abc.Sequence` of
 :class:`~symfit.core.minimizers.BaseMinimizer` objects, which need
 to be run in order.
@@ -324,7 +324,7 @@
 
 def execute(self, bounds=None, jacobian=None, hessian=None,
 constraints=None, *, tol=1e-9, **minimize_options):
-"""
+r"""
 Calls the wrapped algorithm.
 
 :param bounds: The bounds for the parameters. Usually filled by
@@ -790,7 +790,7 @@
 return lbounds, ubounds
 
 def execute(self, jacobian=None, method='trf', **minpack_options):
-"""
+r"""
 :param \*\*minpack_options: Any named arguments to be passed to
 :func:`scipy.optimize.least_squares`
 """
--- a/symfit/core/fit_results.py
+++ b/symfit/core/fit_results.py
@@ -26,7 +26,7 @@
 :class:`~symfit.core.models.Model`'s.
 """
 def __init__(self, model, popt, covariance_matrix, minimizer, objective, message, *, constraints=None, **minimizer_output):
-"""
+r"""
 :param model: :class:`~symfit.core.models.Model` that was fit to.
 :param popt: best fit parameters, same ordering as in model.params.
 :param covariance_matrix: covariance matrix.
@@ -276,4 +276,4 @@
 f_is = [f_is[var] for var in model.dependent_vars]
 SS_res = np.sum([np.sum((y_i - f_i)**2) for y_i, f_i in zip(y_is, f_is) if y_i is not None])
 SS_tot = np.sum([np.sum((y_i - y_bar)**2) for y_i, y_bar in zip(y_is, y_bars) if y_i is not None])
-return 1 - SS_res/SS_tot
\ No newline at end of file
+return 1 - SS_res/SS_tot
--- a/symfit/core/objectives.py
+++ b/symfit/core/objectives.py
@@ -386,7 +386,7 @@
 
 
 class HessianObjectiveJacApprox(HessianObjective):
-"""
+r"""
 This object should only be used as a Mixin for covariance matrix estimation.
 Since the covariance matrix for the least-squares method is proportional to
 the Hessian of :math:`S`, this function attempts to return the Hessian
@@ -552,4 +552,4 @@
 )
 return np.array(evaluated_hess[0])
 else:
-return None
\ No newline at end of file
+return None

Bug#1066146: morph's abandoned packages (list)

[Daniele Tricoli]

Hello Alexandre,

On 3/16/24 18:37, Alexandre Detiste wrote:

CCing Daniele who uploads bespoken flask-login and Carsten who manage
whole flaks ecosystem.


Sorry for the late reply, just for public archive I was also +1 to 
remove flask-basicauth.


Thanks!

Ciao,

Daniele

Bug#1068045: [Pkg-openssl-devel] Bug#1068045: libssl3: breaks YAPET

[Sebastian Andrzej Siewior]

control: tags -1 patch
control: reassign -1 yapet 2.6-1

On 2024-04-08 08:32:58 [+0200], Kurt Roeckx wrote:
> There might be a related change that doesn't allow restarting the
> operation with the same context without setting things up again.

Yapet is broken and the openssl update revealed the problem. I
reassigned it to yapet 2.6 but probably affects earlier versions.
But then the 1.1.1 series is no longer maintained so…

Patches attached and they hold the details of why and such.

This needs to be applied to unstable and Bookworm.
The testsuite passes and I can open Sean's test file.
Further testing is welcome by actual users ;)

I can NMU if needed just yell.

Sebastian
From a54b5e81a61aa7e77e45a970ce88b9b4269fde7d Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Mon, 8 Apr 2024 18:03:30 +0200
Subject: [PATCH 1/2] crypt/blowfish: Remove EVP_CIPHER_CTX_set_key_length().
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

yapet did for blowfish:

| EVP_CipherInit_ex(ctx, cipher, NULL, KEY, iv, mode);
| EVP_CIPHER_CTX_set_key_length(ctx, KEY_LENGTH);
| EVP_CipherUpdate(ctx, …);

this worked in earlier OpenSSL versions and stopped working in
openssl-3.0.13. The problem here is that the
EVP_CIPHER_CTX_set_key_length() is ignored and the later OpenSSL version
returns rightfully an error "Provider routines::no key set" here.

Blowfish does support variable key lenghts but the key length has to be
set first followed by the actual key. Otherwise the blocksize (16) will
be used.
The correct way to deal with this would be:
| EVP_CipherInit_ex(ctx, cipher, NULL, NULL, NULL, mode);
| EVP_CIPHER_CTX_set_key_length(ctx, KEY_LENGTH);
| EVP_CipherInit_ex(ctx, NULL, NULL, KEY, IV, mode);
| EVP_CipherUpdate(ctx, …);

Using now the proper way will break earlier databases because in the
blowfish case, always the default blocksize / 16 has been used.

In order to keep compatibility with earlier versions of the database and
openssl remove the EVP_CIPHER_CTX_set_key_length() invocation.

Fixes #26
Fixes #24

Signed-off-by: Sebastian Andrzej Siewior 
---
 src/libs/crypt/crypto.cc | 10 --
 1 file changed, 10 deletions(-)

diff --git a/src/libs/crypt/crypto.cc b/src/libs/crypt/crypto.cc
index ade991edf961a..139e0823e753a 100644
--- a/src/libs/crypt/crypto.cc
+++ b/src/libs/crypt/crypto.cc
@@ -98,16 +98,6 @@ EVP_CIPHER_CTX* Crypto::initializeOrThrow(MODE mode) {
 throw CipherError{_("Error initializing cipher")};
 }
 
-success = EVP_CIPHER_CTX_set_key_length(context, _key->keySize());
-if (success != SSL_SUCCESS) {
-destroyContext(context);
-char msg[YAPET::Consts::EXCEPTION_MESSAGE_BUFFER_SIZE];
-std::snprintf(msg, YAPET::Consts::EXCEPTION_MESSAGE_BUFFER_SIZE,
-  _("Cannot set key length on context to %d"),
-  _key->keySize());
-throw CipherError{msg};
-}
-
 return context;
 }
 
-- 
2.43.0

>From aaa573b14bafcc9a6b46495bd4ffc15b90d35902 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Mon, 8 Apr 2024 18:19:12 +0200
Subject: [PATCH 2/2] crypt/aes: Remove EVP_CIPHER_CTX_set_key_length().

The EVP_CIPHER_CTX_set_key_length() in the AES-256-CBC case is pointless
because the key here is fixed EVP_CIPHER_CTX_set_key_length() and the
function does not change the size.

Remove the EVP_CIPHER_CTX_set_key_length() invocation.

Signed-off-by: Sebastian Andrzej Siewior 
---
 src/libs/crypt/aes256.cc | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/src/libs/crypt/aes256.cc b/src/libs/crypt/aes256.cc
index 1041b9c57347c..e105b1a5beddd 100644
--- a/src/libs/crypt/aes256.cc
+++ b/src/libs/crypt/aes256.cc
@@ -113,17 +113,6 @@ EVP_CIPHER_CTX* Aes256::initializeOrThrow(const SecureArray& ivec, MODE mode) {
 throw CipherError{_("Error initializing cipher")};
 }
 
-success = EVP_CIPHER_CTX_set_key_length(context, getKey()->keySize());
-if (success != SSL_SUCCESS) {
-LOG_MESSAGE(std::string{__func__} + ": Error setting key length");
-destroyContext(context);
-char msg[YAPET::Consts::EXCEPTION_MESSAGE_BUFFER_SIZE];
-std::snprintf(msg, YAPET::Consts::EXCEPTION_MESSAGE_BUFFER_SIZE,
-  _("Cannot set key length on context to %d"),
-  getKey()->keySize());
-throw CipherError{msg};
-}
-
 return context;
 }
 
-- 
2.43.0

Bug#1068553: ITP: python-overrides -- Python decorator to verify that expected overrides are maintained

[Julian Gilbey]

Oh, oops.  Not sure what to suggest at this point; perhaps I could
drop a note to the ftpmasters?  There's not much difference between
them (except that I used pytest to get autopkgtest to work and my
package description was much less detailed).

Whichever one is accepted, we should certainly drop or archive the
salsa repo for the other!  I don't have any views either way.

Best wishes,

   Julian

On Mon, Apr 08, 2024 at 04:59:13PM +0200, Roland Mas wrote:
> overrides is already in NEW, with packaging hosted on
> https://salsa.debian.org/python-team/packages/overrides. Sorry, I should
> have filed an ITP for that.
> 
> Roland.
> 
> Le 07/04/2024 à 11:02, Julian Gilbey a écrit :
> > Package: wnpp
> > Severity: wishlist
> > Owner: Julian Gilbey 
> > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
> > 
> > * Package name: python-overrides
> >Version : 7.7.0
> >Upstream Author : Copyright: Mikko Korpela
> > * URL : https://github.com/mkorpela/overrides
> > * License : Apache-2.0
> >Programming Lang: Python
> >Description : Python decorator to verify that expected overrides are 
> > maintained
> >   Provides a decorator @override that verifies that a method that
> >   should override an inherited method actually does it.  Python has no
> >   standard mechanism by which to guarantee that (1) a method that
> >   previously overrode an inherited method continues to do so, and (2) a
> >   method that previously did not override an inherited will not
> >   override now.  This package allows this to be addressed in an automated
> >   manner.
> > 
> > This package is a (recursive) dependency of the new version of
> > jupyter-server.
> > 
> > It will be team-maintained within the Debian Python Team.  The Debian
> > packaging is on salsa at
> > https://salsa.debian.org/python-team/packages/python-overrides
> > 
> 


   Julian

Bug#1068644: gnutls-bin: "Fatal error: The encryption algorithm is not supported" appeared with 3.8.5 upgrade

[Andreas Metzler]

Control: severity -1 serious
Control: forwarded -1 https://gitlab.com/gnutls/gnutls/-/issues/1540

On 2024-04-08 Sanjoy Mahajan  wrote:
> Package: gnutls-bin
> Version: 3.8.5-1
> Severity: normal
> X-Debbugs-Cc: none, Sanjoy Mahajan 
> File: /usr/bin/gnutls-cli

> After dist-upgrading today, exim4 could no longer talk to my usual
> outgoing mail server.  I reproduced the problem using just gnutls-cli.
> The problem started after today's upgrade of the various gnutls
> packages.  They were upgraded from 3.8.4-2 to 3.8.5-1.

> The following command with the given input lines reproduces the problem:

>   $ gnutls-cli -V -d 9 --starttls --crlf --port 587 -V outgoing.mit.edu
>   EHLO randomhost
>   STARTTLS
>   ctrl-D [to send EOF]

> It fails with "*** Fatal error: The encryption algorithm is not supported."
[...]

Thank you and sorry. I have done a bisect and will try reverting the
offending upstream commit as a hotfix.

cu Andreas

Bug#1068653: evolution: Can't use google accounts

[Mark A. Hershberger]

Package: evolution
Version: 3.50.3-1+b1
Severity: grave

I have two accounts (personal and work) and both of them are returning
“Timeout was reached”.  I have tried removing the accounts and re-adding
them without success.

personal account is @gmail.com

work account is @EMPLOYER'S-DOMAIN

-- System Information
Debian Release: 12.5
Kernel Version: Linux gabriel 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.76-1 (2024-02-01) x86_64 GNU/Linux

-- 
http://hexmode.com/

Don't ask me who's influenced me. A lion is made up of the
lambs he's digested, and I've been reading all my life.
-- Giorgos Seferis

Bug#1068607: coreutils: Please publish VCS/git package sources

[cacin]

Package: coreutils
Followup-For: Bug #1068607

It was asked for 12 years ago in #694105 hence a duplicate.

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Sven Joachim]

On 2024-04-08 15:46 +0200, Chris Hofstaedtler wrote:

> To clarify, because I think there is still some ongoing
> confusion regarding binary files and binary packages, here a table:
>
> Debian package name  | (primary) file(s)
> 
> liblastlog2-0| /usr/lib/.../liblastlog2.so.*
> libpam-lastlog2  | /usr/lib/.../pam_lastlog2.so
> lastlog2 | /usr/bin/lastlog2 (probably + symlink "last")

I think you mean "lastlog" rather than "last" here, the latter displays
wtmp entries.

> I think my biggest open questions for the packaging itself are:
>
> * Which package will pull in lastlog2 and libpam-lastlog2, for
>   for upgrades from bookworm?

If lastlog2 takes over the lastlog binary, the logical package seems to
be login which is currently shipping it.  The only question is if it
that should be done via Depends or Recommends, I would prefer the latter
to avoid pulling in libsqlite3 in every container/chroot.

> * Should /usr/bin/lastlog2 be in a separate lastlog2 package or not?

It could be in its own package or in util-linux-extra, I have no
particular preference.

> * Should lastlog2 Depend: libpam-lastlog2? Vice versa? Only
>   Recommends?

I think lastlog2 needs to depend on libpam-lastlog2, because it is not
useful otherwise.  There may be a few cornercases such as having
installed lastlog2 and login or sshd from different architectures, but
then the local admin should know what they are doing and install
libpam-lastlog2 for all architectures.  There does not seem to be any
particular reason why libpam-lastlog2 should recommend lastlog2.

Cheers,
   Sven

Bug#1068608: tfortune dependencies unsatisfiable on 32-bit non-i386 architectures.

[Andre Noll]

[Cc Steve]

On Sun, Apr 07, 22:02, Peter Michael Green wrote:

> After being rebuilt for the time64 transition, tfortune
> depends on both liblopsub1 and liblopsub1t64. As a
> result it is uninstallable on architectures that are undergoing
> the time64 transition (armel, armhf and some debian-ports
> architectures).
> 
> Ubuntu has already fixed this issue by removing the hardcoded
> dependency on liblopsub1.
> 
> https://launchpadlibrarian.net/720835658/tfortune_1.0.1-1build1_1.0.1-1ubuntu1.diff.gz

This was fixed already on February 2nd as suggested by Steve, see
upstream commit f40f0aae211f. Please let me know if any further action
is required on my part.

Thanks
Andre
-- 
Max Planck Institute for Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

Bug#1068652: Patch to fix pkexec not working in TTY

[Teh404Gal]

Package: pkexec
Version: 124-2

Hello, i want to submit this patch from upstream to fix the pkexec failing in 
tty only environment, this has been merged into upstream's master but there was 
no release

patch's link: 
https://patch-diff.githubusercontent.com/raw/polkit-org/polkit/pull/423.patch

thanks for reading :3c

Bug#1066396: lftp: FTBFS: ./config.h:2540:11: fatal error: trio.h: No such file or directory

[Chris Hofstaedtler]

On Sun, Mar 24, 2024 at 03:42:18PM +0500, Andrey Rakhmatullin wrote:
> On Wed, Mar 13, 2024 at 01:03:20PM +0100, Lucas Nussbaum wrote:
> > > ./config.h:2540:11: fatal error: trio.h: No such file or directory
> > >  2540 | # include "trio.h"
> > >   |   ^~~~
> (this suggests that using trio is not actually supported but that's
> irrelevant)
> This is caused by the stdio detection failing and should be fixed by
> adding #include  to the test case code in m4/needtrio.m4 but this
> package doesn't run autoreconf so fixing d/rules to at least do that is
> also needed.

I gave the following a try, but it makes `make install` fail with an error
suggesting a variable was left empty.

Making install in po
make[3]: Entering directory '/<>/po'
/<>/debian/lftp/usr/share
make[3]: /<>/debian/lftp/usr/share: Permission denied
make[3]: *** [Makefile:304: install-data-yes] Error 127
make[3]: Leaving directory '/<>/po'
...


diff -Nru lftp-4.9.2/debian/rules lftp-4.9.2/debian/rules
--- lftp-4.9.2/debian/rules 2018-09-17 09:33:33.0 +0200
+++ lftp-4.9.2/debian/rules 2024-04-08 16:46:06.0 +0200
@@ -20,6 +20,8 @@
 #configure: configure-stamp
 configure-stamp:
dh_testdir
+   dh_update_autotools_config
+   dh_autoreconf
# Add here commands to configure the package.
CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" CPPFLAGS="$(CPPFLAGS)" 
LDFLAGS="$(LDFLAGS)" ./configure \
--prefix=/usr \
@@ -56,6 +58,7 @@
[ ! -f Makefile ] || $(MAKE) distclean
rm -f doc/lftp.inf*

+   dh_autoreconf_clean
dh_clean

 install: build

Bug#1068651: RFS: bisect-ppx/2.8.3-1 [ITP] -- Code coverage for OCaml and ReScript (dev files)

[Bo YU]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "bisect-ppx":

 * Package name : bisect-ppx
   Version  : 2.8.3-1
   Upstream contact : Xavier Clerc ,
 * URL  : https://github.com/aantron/bisect_ppx
 * License  : Expat
 * Vcs  : https://salsa.debian.org/ocaml-team/bisect-ppx
   Section  : ocaml

The source builds the following binary packages:

  libbisect-ppx-ocaml - Code coverage for OCaml and ReScript (runtime files)
  libbisect-ppx-ocaml-dev - Code coverage for OCaml and ReScript (dev files)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/bisect-ppx/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bisect-ppx/bisect-ppx_2.8.3-1.dsc

Changes for the initial release:

 bisect-ppx (2.8.3-1) UNRELEASED; urgency=low
 .
   * Initial release. (Closes: #1068621)


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1068553: ITP: python-overrides -- Python decorator to verify that expected overrides are maintained

[Roland Mas]

overrides is already in NEW, with packaging hosted on 
https://salsa.debian.org/python-team/packages/overrides. Sorry, I should 
have filed an ITP for that.


Roland.

Le 07/04/2024 à 11:02, Julian Gilbey a écrit :

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

* Package name: python-overrides
   Version : 7.7.0
   Upstream Author : Copyright: Mikko Korpela
* URL : https://github.com/mkorpela/overrides
* License : Apache-2.0
   Programming Lang: Python
   Description : Python decorator to verify that expected overrides are 
maintained
  Provides a decorator @override that verifies that a method that
  should override an inherited method actually does it.  Python has no
  standard mechanism by which to guarantee that (1) a method that
  previously overrode an inherited method continues to do so, and (2) a
  method that previously did not override an inherited will not
  override now.  This package allows this to be addressed in an automated
  manner.

This package is a (recursive) dependency of the new version of
jupyter-server.

It will be team-maintained within the Debian Python Team.  The Debian
packaging is on salsa at
https://salsa.debian.org/python-team/packages/python-overrides

Bug#1068615: pbuilder will overwrite LANG/LC_ALL if they are set via config file

[Sergio Durigan Junior]

On Sunday, April 07 2024, Thorsten Glaser wrote:

> Sergio Durigan Junior dixit:
>
>>-export LANG=C
>>-export LC_ALL=C
>>+export LANG="${LANG:-C}"
>>+export LC_ALL="${LC_ALL:-C}"
>
> Ouch, no.

I'd be disappointed if this was accepted as is :-).

> IMHO, they ought to really be unset for sane build environments,
> and if the thing to be built needs locales, it can set its own.

IIRC our buildds will set $LANG as C.UTF-8.  pbuilder should try to
stick to what the official infrastructure does.

Thanks,

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

Bug#1068444: (no subject)

[Pierre Neyron]

Hello,

This bug is known and fixed in Debian testing.

Indeed, the create_function function was removed from PHP 8: it must be 
replaced.


Also, there is another bug arising with PHP8: static methods must be 
declared static, otherwise the program still does not work and the 
following message shows up in the apache logs:



[Mon Apr 08 14:05:42.179046 2024] [php:error] [pid 15211] [client 
192.168.40.1:59772] PHP Fatal error:  Uncaught Error: Non-static method 
Shuffle::get_int() cannot be called statically in 
/usr/share/oar-web-status/drawgantt-svg/drawgantt-svg.php:482\nStack 
trace:\n#0 
/usr/share/oar-web-status/drawgantt-svg/drawgantt-svg.php(804): 
Job->color()\n#1 
/usr/share/oar-web-status/drawgantt-svg/drawgantt-svg.php(1165): 
Resource->svg_jobs()\n#2 {main}\n  thrown in 
/usr/share/oar-web-status/drawgantt-svg/drawgantt-svg.php on line 482, 
referer: http://192.168.40.4/drawgantt-svg/


Thanks for the bug report.
Pierre

Bug#1068650: reportbug: armagetronad (Armagetron Advanced) - changes in SDL libs

[Andreas Doll]

Subject: reportbug: armagetronad (Armagetron Advanced) - changes in SDL libs
Package: armagetronad
Version: 0.2.9.1.0-3
Severity: normal

Hi;
Armagetron Advanced now relies on libsdl1.2, an SDL2 compat package, since SDL1 
is no longer a viable option. With this, a few changes in how applications 
function have occurred.
First, vsync needs to be disabled. This is handled in the .desktop link, by 
means of an exec parameter:
__GL_SYNC_TO_VBLANK=0 armagetronad
Second, without disabling the compositor, the application will not perform 
properly, dropping frames and causing key input errors. I handle this with Kwin 
window rules, but it may be advisable to do this in the exec parameter also.
Finally, there is a minor issue with full-screen, in that entering full-screen 
mode disables any secondary, tertiary, or additional monitors. On some 
platforms, armagetron cannot see individual monitors, and instead sprawls 
across all available monitors. I'm not sure if this is something that can be 
fixed with a launch or build parameter, or if that's something we have to fix 
ourselves.
I am a member of the armagetronad community, so if this requires an alteration 
in how armagetronad is written or packaged, please let me/us know. 
Alternatively, #armagetron on both Libera and OFTC are bridged together with 
the semi-official discord community where the development team is active (and 
hopefully soon with other chat-based communities for complete coverage). The 
old forums (https://forums3.armagetronad.net/) are also still up and 
semi-active.
Best;
Andreas Doll (aka Delinquent)
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-18-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 armagetronad depends on:
ii armagetronad-common 0.2.9.1.0-3
ii libc6 2.36-9+deb12u4
ii libgcc-s1 14-20240221-2.1
ii libgl1 1.6.0-1
ii libglu1-mesa [libglu1] 9.0.2-1.1
ii libpng16-16 1.6.39-2
ii libsdl-image1.2 1.2.12-13+b2
ii libsdl1.2debian 1.2.15+dfsg2-8
ii libstdc++6 14-20240221-2.1
ii libxml2 2.9.14+dfsg-1.3~deb12u1

armagetronad recommends no packages.
armagetronad suggests no packages.
-- no debconf information

Bug#1068649: winbind: Should be wanted by and ordered before nss-user-lookup.target

[Magnus Holmgren]

Package: winbind
Version: 2:4.17.12+dfsg-0+deb12u1

I'm not entirely sure, but I think winbind.service should include

[Unit]
Wants=nss-user-lookup.target
Before=nss-user-lookup.target

systemd.special(7) says:

"All services which provide parts of the user/group database should be ordered 
before this target, and pull it in."

and winbind does provide parts of the user/group database (as long as it's 
mentioned in nsswitch.conf, but typically that's the point, isn't it?).

We've had trouble with cron not running some jobs for a good while, and I just 
now figured out that it's because we have some jobs configured to run as Samba 
users, and cron started before winbind on boot and complained about invalid 
users.

-- 
Magnus Holmgren
./¯\_/¯\. Milient Software
(also holmg...@debian.org)

Bug#1068476: RM: rlog -- leaf package

[Eduard Bloch]

reassign 1068476 ftp.debian.org
retitle 1068476 RM: rlog -- ROM; obsolete dependency of encfs
thanks

Hallo FTP masters,

please remove the source package rlog and all binary packages
originating from it (librlog-dev, librlog5v5).

This library has been a custom logging framework from the encfs author(s)
but it seems like has never been widely accepted and even encfs has
transitioned to a more popular solution (elpp) over a decade ago.

Therefore, no loss of functionality to expect here, IMHO. Thank you.

Best regards,
Eduard.

* Bastian Germann [Fri, Apr 05 2024, 11:46:56PM]:
> Source: rlog
> Version: 1.4-4.2
> Severity: wishlist
>
> clamfs has just lost its dependency on rlog and therefore, rlog is now a leaf 
> package.
> The last upstream release was 15 years ago, so now would be the perfect time 
> to remove it.
> Please consider filing a RM bug on ftp.debian.org.

Bug#1068648: RFP: feenox -- finite-element PDE solver

[Jeremy Theler]

Package: wnpp
Severity: wishlist

* Package name: feenox
  Version : 1.0.8
  Upstream Author : Jeremy Theler 
* URL : https://github.com/seamplex/feenox
* License : GPL
  Programming Lang: C
  Description : finite-element(ish) computational engineering tool

FeenoX is a cloud-first free no-X uniX-like finite-element(ish)
computational engineering tool designed to solve engineering-related
problems using cloud servers in parallel in such a way that the problem
is defined in a plain-text near-English self descriptive input file
read at run time, without requiring further user intervention after the
invocation.

The software and its design basis is described in this JOSS paper:
https://doi.org/10.21105/joss.05846

So far it can solve 

 * Basic mathematics
 * Systems of ODEs/DAEs
 * Laplace’s equation
 * Heat conduction
 * Linear elasticity
 * Modal analysis
 * Neutron diffusion
 * Neutron SN

Other PDEs can be added by providing compile-time entry points as C
functions that build the elemental objects. The binary depends on

 * GNU Scientific Library
 * PETSc
 * SLEPc
 
The usage depends on Gmsh to create the meshes.
Optionally, FeenoX's output can be post-processed with Paraview.

I can maintain de package, provided a sponsor helps me through the
initial process.
Or, the package can be either maintained by the debian-hpc or pkg-
scicomp.

Bug#1068640: clevis-initramfs: clevis early boot DNS fail, no resolv.conf created by ipconfig

[Christoph Biedl]

anon2529 wrote...

> The early boot fails to unlock a volume automatically. We get a
> prompt to unlock a volume (it's a swap volume) but clevis is
> unable to unlock it automatically because it cannot resolve
> the Tang server's hostname.

That ought to be fixed in clevis 20 (not uploaded yet, will do in the
next days). If you have the skills and the time, you could try to
backport

https://github.com/latchset/clevis/commit/bebb037d664185769c12cd061c2221c2d2bdb432

Christoph


signature.asc
Description: PGP signature

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

* Iker Pedrosa  [240408 09:19]:
> > >- Did you consider using a systemd service to upgrade from lastlog to
> > >lastlog2 data?
> >
> > No, I did not consider this, as I wasn't aware of any
> > implementations for this. Does u-l upstream ship such a service?
> >
> 
> Yes,
> https://github.com/util-linux/util-linux/blob/master/misc-utils/lastlog2-import.service.in

Thanks!

ISTM we could do this in the postinst script instead, to avoid
installing single-use services on all systems.

Chris

Bug#1068017: [Pkg-shadow-devel] Bug#1068017: util-linux: please ship liblastlog2 packages

[Chris Hofstaedtler]

* Colin Watson  [240408 10:55]:
> On Mon, Apr 08, 2024 at 09:19:09AM +0200, Iker Pedrosa wrote:
> > On Sat, Apr 6, 2024 at 11:48 PM Chris Hofstaedtler  wrote:
> > > util-linux upstream provides three binary objects to be built:
> > > - liblastlog2.so
> > > - pam_lastlog2.so
> > > - lastlog2 (program)
> > >
> > > Debian's PAM policy says to put PAM modules into their own package,
> > > thus libpam-lastlog2. liblastlog2.so would go into the
> > >
> > liblastlog2(-0) package. The lastlog2 program either into its own
> > > lastlog2 package, or elsewhere.
> > >
> > 
> > Please, let's call this pam_lastlog2 and not libpam-lastlog2. AFAIK, all
> > pam modules start with the prefix pam_*.
> 
> The file names do, but the package names almost always start with
> "libpam-".  (Also, Debian package names may not contain "_".)
> 
>   $ apt-file search security/pam_ | grep -v libpam-modules | grep --count 
> ^libpam-
>   68
>   $ apt-file search security/pam_ | grep -v libpam-modules | grep --count 
> ^pam-
>   1
> 
> And the Debian PAM mini-policy says:
> 
>   1) Packages should use the naming scheme of `libpam-' (eg.
>   libpam-ldap).

Indeed. To clarify, because I think there is still some ongoing
confusion regarding binary files and binary packages, here a table:

Debian package name  | (primary) file(s)

liblastlog2-0| /usr/lib/.../liblastlog2.so.*
libpam-lastlog2  | /usr/lib/.../pam_lastlog2.so
lastlog2 | /usr/bin/lastlog2 (probably + symlink "last")

I think my biggest open questions for the packaging itself are:

* Which package will pull in lastlog2 and libpam-lastlog2, for
  for upgrades from bookworm?

* Should /usr/bin/lastlog2 be in a separate lastlog2 package or not?

* Should lastlog2 Depend: libpam-lastlog2? Vice versa? Only
  Recommends?

Chris

Bug#1068024: revert to version that does not contain changes by bad actor

[ashim gena]

On Fri, 29 Mar 2024 22:32:23 +0100 Aurelien Jarno 
wrote:
> On 2024-03-29 16:25, Joey Hess wrote:
> > I'd suggest reverting to 5.3.1. Bearing in mind that there were security
> > fixes after that point for ZDI-CAN-16587 that would need to be
reapplied.
>
> Note that reverted to such an old version will break packages that use
> new symbols introduced since then. From a quick look, this is at least:
> - dpkg
> - erofs-utils
> - kmod
>
> Having dpkg in that list means that such downgrade has to be planned
> carefully.
>
> Regards
> Aurelien
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://aurel32.net


mobile