Bug#1068365: util-linux: FTBFS on mips64el in lsfd/mkfds-multiplexing-pselect6 test et al

[YunQiang Su]

Chris Hofstaedtler  于2024年4月4日周四 16:27写道：
>
> Source: util-linux
> Version: 2.40-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: debian-m...@lists.debian.org
> Control: forwarded -1 https://github.com/util-linux/util-linux/issues/2867
>
> Apparently on mips64el we have a kernel issue that make
> mkfds-multiplexing-{pselect6,poll,ppoll} fail.
> Upstream discussion here: https://github.com/util-linux/util-linux/issues/2867
>
> FlyGoat commented last week:
> > Thanks for reporting, will ask for stable backport after getting this 
> > merged.
>
> MIPS porters, please also check the upstream discussion and if possible
> see if we can get this into the Debian kernels.
>

Yes. I talked with Jiaxun. I think that we should accept this patch to Debian.

> Thanks,
> Chris
>


-- 
YunQiang Su

Bug#1068599: ruby-xapian - still depends on old libruby3.1 after binnmu

[Olly Betts]

On Sun, Apr 07, 2024 at 08:22:37PM +0100, Peter Michael Green wrote:
> The following lines in the build log look like a likely culprit.
> 
> > # The module(s) are linked against libruby2.x but use none of its
> > # symbols, so there's no dependency generated.  That's unhelpful for
> > # users and for transitions (https://bugs.debian.org/816775) so
> > # generate a suitable dependency.
> > #
> > # If RUBY_VERSIONS is 2.1 2.2 2.3, Depends: libruby2.3|libruby2.1 
> > |libruby2.2
> > echo "ruby:Depends=libruby3.1" \
> >  >> debian/ruby-xapian.substvars

Yes, thanks for identifying that.

We can't rely on the automated machinery (see ticket linked above
if you want the gory details) but the ruby team (quite reasonably)
wanted a dependency and suggested essentially what we do now.

We could just hardcode t64 here, but probably better to try to extract
the actual library from the matching ruby version's dependencies so we
don't have to do this for future suffix changes (the next librubyX.Y
to be packaged won't need it).

This works, but maybe there's a better way:

dpkg -s ruby3.1|sed -n 's/^Depends:.*\(libruby3.1[a-z0-9]*\).*/\1/p;d'

I'll try to get a fix uploaded in the next day or two.

Cheers,
Olly

Bug#1068619: grub2: please enable grub2 for loong64

[liu shiwei]

Source: grub2
Severity: important

Dear Maintainer,

grub 2.12 already supports loong64 (loongarch64), please enable it to
support loong64 under sid.

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 6.8.4-loongarch-2-g1f0b9c599185 (SMP w/4 CPU threads;
PREEMPT)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
-- 
liu shiwei
--- grub2-2.12/debian/rules	2024-01-15 09:54:55.0 +
+++ grub2-2.12.x/debian/rules	2024-04-01 17:41:42.866677265 +
@@ -136,6 +136,9 @@
 ifeq ($(DEB_HOST_ARCH),amd64)
 SB_PACKAGE := grub-efi-amd64
 endif
+ifeq ($(DEB_HOST_ARCH),loong64)
+SB_PACKAGE := grub-efi-loongarch64
+endif
 ifeq ($(DEB_HOST_ARCH),arm64)
 SB_PACKAGE := grub-efi-arm64
 endif
--- grub2-2.12/debian/control	2024-01-15 09:54:55.0 +
+++ grub2-2.12.x/debian/control	2024-04-01 17:50:12.827968327 +
@@ -34,8 +34,8 @@
  libparted-dev [any-powerpc any-ppc64 any-ppc64el],
  pkg-config,
  bash-completion,
- libefiboot-dev [i386 amd64 ia64 x32 armel armhf arm64 riscv64],
- libefivar-dev [i386 amd64 ia64 x32 armel armhf arm64 riscv64],
+ libefiboot-dev [i386 amd64 ia64 x32 armel armhf arm64 riscv64 loong64],
+ libefivar-dev [i386 amd64 ia64 x32 armel armhf arm64 riscv64 loong64],
 Build-Conflicts: autoconf2.13, libzfs-dev, libnvpair-dev
 Standards-Version: 3.9.6
 Homepage: https://www.gnu.org/software/grub/
@@ -63,9 +63,9 @@
  This is a dummy transitional package that depends on grub-coreboot.
 
 Package: grub-efi
-Architecture: any-i386 any-amd64 any-arm64 any-ia64 any-arm any-riscv64
+Architecture: any-i386 any-amd64 any-arm64 any-ia64 any-arm any-riscv64 loong64
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ${misc:Depends}, grub-efi-ia32 (= ${binary:Version}) [any-i386], grub-efi-amd64 (= ${binary:Version}) [any-amd64], grub-efi-arm64 (= ${binary:Version}) [any-arm64], grub-efi-ia64 (= ${binary:Version}) [any-ia64], grub-efi-arm (= ${binary:Version}) [any-arm], grub-efi-riscv64 (= ${binary:Version}) [any-riscv64]
+Depends: ${misc:Depends}, grub-efi-ia32 (= ${binary:Version}) [any-i386], grub-efi-amd64 (= ${binary:Version}) [any-amd64], grub-efi-arm64 (= ${binary:Version}) [any-arm64], grub-efi-ia64 (= ${binary:Version}) [any-ia64], grub-efi-arm (= ${binary:Version}) [any-arm], grub-efi-riscv64 (= ${binary:Version}) [any-riscv64], grub-efi-loongarch64 (= ${binary:Version}) [loong64]
 Multi-Arch: foreign
 Description: GRand Unified Bootloader, version 2 (dummy package)
  This is a dummy package that depends on the grub-efi-$ARCH package most likely
@@ -77,7 +77,7 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}, gettext-base, ${lsb-base-depends}
 Replaces: grub-pc (<< 2.00-4), grub-ieee1275 (<< 2.00-4), grub-efi (<< 1.99-1), grub-coreboot (<< 2.00-4), grub-linuxbios (<< 1.96+20080831-1), grub-efi-ia32 (<< 2.00-4), grub-efi-amd64 (<< 2.00-4), grub-efi-ia64 (<< 2.00-4), grub-yeeloong (<< 2.00-4), init-select
 Recommends: os-prober (>= 1.33)
-Suggests: multiboot-doc, grub-emu [any-i386 any-amd64 any-powerpc], mtools [any-i386 any-amd64 any-ia64 any-arm any-arm64 riscv64], xorriso (>= 0.5.6.pl00), desktop-base (>= 4.0.6), console-setup
+Suggests: multiboot-doc, grub-emu [any-i386 any-amd64 any-powerpc], mtools [any-i386 any-amd64 any-ia64 any-arm any-arm64 riscv64 loong64], xorriso (>= 0.5.6.pl00), desktop-base (>= 4.0.6), console-setup
 Conflicts: init-select
 # mdadm: See bugs #435983 and #455746
 Breaks: mdadm (<< 2.6.7-2), lupin-support (<< 0.55), friendly-recovery (<< 0.2.13), apport (<< 2.1.1)
@@ -94,7 +94,7 @@
 # Not Architecture: any because this package contains some things which are
 # only built when there is a real platform (e.g. grub-install), and the rest
 # of the package is not very useful in a utilities-only build.
-Architecture: any-i386 any-amd64 any-powerpc any-ppc64 any-ppc64el any-sparc any-sparc64 any-mipsel any-ia64 any-arm any-arm64 any-riscv64
+Architecture: any-i386 any-amd64 any-powerpc any-ppc64 any-ppc64el any-sparc any-sparc64 any-mipsel any-ia64 any-arm any-arm64 any-riscv64 loong64
 Depends: grub-common (= ${binary:Version}), dpkg (>= 1.15.4), ${shlibs:Depends}, ${misc:Depends}
 Replaces: grub, grub-legacy, ${legacy-doc-br}, grub-common (<< 1.99-1), grub-pc (<< 2.02+dfsg1-7), grub-coreboot (<< 2.02+dfsg1-7), grub-efi-ia32 (<< 2.02+dfsg1-7), grub-efi-amd64 (<< 2.02+dfsg1-7), grub-efi-ia64 (<< 2.02+dfsg1-7), grub-efi-arm (<< 2.02+dfsg1-7), grub-efi-arm64 (<< 2.02+dfsg1-7), grub-ieee1275 (<< 2.02+dfsg1-7), grub-uboot (<< 2.02+dfsg1-7), grub-xen (<< 2.02+dfsg1-7), grub-yeeloong (<< 2.02+dfsg1-7), grub-cloud-amd64 (<< 0.0.4)
 Conflicts: grub-legacy
@@ -582,6 +582,57 @@
  use on RISC-V 64-bit systems with UEFI.  Installing this package indicates that
  this version of GRUB should be the active boot loader.
 
+
+Package: 

Bug#1068583: libgav1: FTBFS on s390x: test failures

[Sebastiaan Couwenberg]

I've added architecture-is-little-endian to the build dependency in git 
to make the lack of big endian support explicit.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1068617: Acknowledgement (dh-dlang: please enable d-lang for loong64.)

[liu shiwei]

patch

Debian Bug Tracking System  于2024年4月8日周一 13:03写道：

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1068617:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068617.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian D Language Group 
>
> If you wish to submit further information on this problem, please
> send it to 1068...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1068617: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068617
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>


-- 
刘世伟
diff -uNra a/debian/control b/debian/control
--- a/debian/control	2024-04-08 03:42:37.811907563 +
+++ b/debian/control	2024-04-08 03:43:05.503973197 +
@@ -25,7 +25,7 @@
  for the current architecture.
 
 Package: default-d-compiler
-Architecture: amd64 arm64 i386 armhf s390x riscv64 ppc64el x32
+Architecture: amd64 arm64 i386 armhf s390x riscv64 ppc64el x32 loong64
 Depends: gdc (>= 4:12) [armhf s390x ppc64el x32],
  ldc (>= 1:1.36) [amd64 arm64 i386 riscv64],
  ${misc:Depends}

Bug#1068618: lld: please enable lld package for loong64

[liu shiwei]

Package: lld
Version: 1:16.0-58.1
Severity: normal

Dear Maintainer,

   * firefox build depend lld, please enable lld package for loong64.

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 6.8.4-loongarch-2-g1f0b9c599185 (SMP w/4 CPU threads;
PREEMPT)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lld depends on:
ii  lld-16  1:16.0.6-24

lld recommends no packages.

lld suggests no packages.

-- no debconf information
-- 
liu shiwei
diff -uNra a/debian/rules b/debian/rules
--- a/debian/rules	2024-03-29 12:11:45.0 +
+++ b/debian/rules	2024-04-08 02:03:01.763022494 +
@@ -111,14 +111,14 @@
 no_packages += lldb liblldb-dev python3-lldb
 endif
 
-LLD_SUPPORTED=amd64 arm64 armel armhf i386 mips mipsel mips64el ppc64el kfreebsd-amd64 kfreebsd-i386 s390 s390x sparc alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32 riscv64
+LLD_SUPPORTED=amd64 arm64 armel armhf i386 mips mipsel mips64el ppc64el kfreebsd-amd64 kfreebsd-i386 s390 s390x sparc alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32 riscv64 loong64
 ifneq (,$(filter $(DEB_HOST_ARCH),$(LLD_SUPPORTED)))
 all_packages += lld liblld-dev
 else
 no_packages += lld liblld-dev
 endif
 
-FLANG_SUPPORTED=amd64 arm64 mips64el ppc64el kfreebsd-amd64 ppc64 sparc64 riscv64
+FLANG_SUPPORTED=amd64 arm64 mips64el ppc64el kfreebsd-amd64 ppc64 sparc64 riscv64 loong64
 ifneq (,$(filter $(DEB_HOST_ARCH),$(FLANG_SUPPORTED)))
 all_packages += flang libflang-dev
 else

Bug#1068617: dh-dlang: please enable d-lang for loong64.

[liu shiwei]

Package: dh-dlang
Version: 0.6.6
Severity: normal

Dear Maintainer,

* Some packages need to be compiled using the loong64 architecture

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 6.8.4-loongarch-2-g1f0b9c599185 (SMP w/4 CPU threads;
PREEMPT)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-dlang depends on:
ii  debhelper   13.15.3
ii  default-d-compiler  0.6.6
ii  python3 3.11.8-1

dh-dlang recommends no packages.
-- 
liu shiwei

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

[Thorsten Glaser]

Sergio Durigan Junior dixit:

>-export LANG=C
>-export LC_ALL=C
>+export LANG="${LANG:-C}"
>+export LC_ALL="${LC_ALL:-C}"

Ouch, no.

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.

Passing environment variables, even “just” the locale, from the
outside into the build environment is a dark path.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1068614: gmt: please add support for loong64

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 4/8/24 4:55 AM, wuruilong wrote:

gmt compiles incorrectly on loong64 architectures, the attached patch solves 
the problem and is verified.

Thanks for the patch and forwarding it upstream, it's applied in git.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1068616: libanyevent-i3-perl: Version is outdated compared to the gitrepo

[Wesley Schwengle]

Package: libanyevent-i3-perl
Version: 0.17-3
Severity: important
Tags: upstream
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,


See: https://github.com/i3/i3/issues/5986

The version of AnyEvent::I3 is 0.17 on CPAN while the git repo has version
0.18.

Could you grab the version from the git repo?

Many thanks!



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'testing'), (100, 'experimental'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libanyevent-i3-perl depends on:
ii  libanyevent-perl  7.170-2+b5
ii  libjson-xs-perl   4.030-2+b3
ii  perl  5.38.2-3.2

libanyevent-i3-perl recommends no packages.

libanyevent-i3-perl suggests no packages.

-- debconf-show failed

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

[Sergio Durigan Junior]

Source: pbuilder
Version: 0.231
Severity: important
Affects: curl trurl
Tags: patch

Hi,

Charles from the Debian curl team noticed that curl and trurl have been
failing to build in the reproducible-builds environment:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/curl.html

He also found that the problem happens because the build environment
doesn't seem to have UTF-8 support, which is required by the upstream
testsuite of both packages.  The $LANG environment variable is set to
"C", as can be checked in the logs:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/curl.html

--8<---cut here---start->8---
I: user script /srv/workspace/pbuilder/3967986/tmp/hooks/D02_print_environment 
starting
I: set
...
  LANG='C'
  LANGUAGE='en_US:en'
  LC_ALL='C'
...
--8<---cut here---end--->8---

This is strange, because the same build succeeds when done locally (with
sbuild) or in the archive (which also uses sbuild).  So we joined
efforts this afternoon and tracked down the bug to pbuild, which happens
to be used in the reproducible-builds setup.

Long story short, the problem comes from this excerpt found in the
pbuilder-modules script:

  
https://salsa.debian.org/pbuilder-team/pbuilder/-/blob/master/pbuilder-modules?ref_type=heads#L1180-1183

Interestingly, these lines were added 22 years ago by this commit,
according to git-blame:

  
https://salsa.debian.org/pbuilder-team/pbuilder/-/commit/296a5a338a397c6cf8c77a813dc29bd1b7ce8b19

They interfere with the way reproducible-builds sets $LANG for builds:

  
https://salsa.debian.org/qa/jenkins.debian.net/-/blob/master/bin/reproducible_build.sh?ref_type=heads#L627-638

and end up overriding the variable.

It's also important to note that this problem is not specific to
reproducible-builds; the FTBFS can be easily reproduced by just trying
to build curl or trurl locally, without any changes.  And as explained
above, setting $LANG via --configfile doesn't work.

The patch below fixes the problem, but I'm not sure it's the right
approach when it comes to $LC_ALL, given its idiosyncrasies.  It may be
better to reassess whether setting these variables at the end of the
script is still the right thing to do.

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/

diff --git a/pbuilder-modules b/pbuilder-modules
index aca876de..47807f84 100644
--- a/pbuilder-modules
+++ b/pbuilder-modules
@@ -1179,5 +1179,5 @@ function executehooks () {
 
 #Setting environmental variables that are really required:
 #required for some packages to install...
-export LANG=C
-export LC_ALL=C
+export LANG="${LANG:-C}"
+export LC_ALL="${LC_ALL:-C}"


signature.asc
Description: PGP signature

Bug#1068614: gmt: please add support for loong64

[wuruilong]

Source: gmt
Severity: normal
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

gmt compiles incorrectly on loong64 architectures, the attached patch solves 
the problem and is verified.

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 gmt (6.5.0+dfsg-3) unstable; urgency=medium
 .
   * Add dpkg-dev (>= 1.22.5) to build dependencies for t64 changes.
Author: Bas Couwenberg 

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2024-04-08

--- gmt-6.5.0+dfsg.orig/src/gmt_common_sighandler.c
+++ gmt-6.5.0+dfsg/src/gmt_common_sighandler.c
@@ -109,6 +109,8 @@ GMT_LOCAL void backtrace_symbols_fd(void
 #  define UC_IP(uc) ((void *) (uc)->uc_mcontext.sc_pc)
 # elif defined( __arm__)
 #  define UC_IP(uc) ((void *) (uc)->uc_mcontext.arm_pc)
+# elif defined( __loongarch__)
+#  define UC_IP(uc) ((void *) (uc)->uc_mcontext.__pc)
 # elif defined( __hppa__)
 #  define UC_IP(uc) ((void *) (uc)->uc_mcontext.sc_iaoq[0])
 # elif defined(__m68k__)

Bug#772204: Package upload repository policy

[Ben Finney]

On 08-Apr-2024, Osamu Aoki wrote:
> * Adjust message to address rejection condition and repository policy

Where (what URL) can I find the current repository policy, with enough
precision to implement a conformant upload program?

-- 
 \   “It is wrong to think that the task of physics is to find out |
  `\ how nature *is*. Physics concerns what we can *say* about |
_o__) nature…” —Niels Bohr |
Ben Finney 


signature.asc
Description: PGP signature

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

[陈 晟祺]

Hi Paul,

> 2024年4月7日 21:10，Paul Gevers  写道：
> 
> Hi,
> 
> The host that runs this is an m3-large instance at equinix [1].
> 
> We create the qemu image with autopkgtest-build-qemu (default settings as far 
> as I know).
> 
> From within the testbed:
> root@host:~# lscpu
> lscpu
> Architecture:x86_64
>  CPU op-mode(s):32-bit, 64-bit
>  Address sizes: 48 bits physical, 48 bits virtual
>  Byte Order:Little Endian
> CPU(s):  1
>  On-line CPU(s) list:   0
> Vendor ID:   AuthenticAMD
>  BIOS Vendor ID:QEMU
>  Model name:AMD EPYC 7502P 32-Core Processor
>BIOS Model name: pc-i440fx-7.2  CPU @ 2.0GHz
>BIOS CPU family: 1
>CPU family:  23
>Model:   49
>Thread(s) per core:  1
>Core(s) per socket:  1
>Socket(s):   1
> 
> root@host:~# lsmem
> lsmem
> RANGE SIZE  STATE REMOVABLE BLOCK
> 0x-0x7fff   2G online   yes  0-15
> 
> Memory block size:   128M
> Total online memory:   2G
> Total offline memory:  0B
> 

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.

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.

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.

[1]: 
https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-private-repositories
[2]: 
https://github.com/openzfs/zfs/blob/master/.github/workflows/scripts/setup-functional.sh


Thanks,
Shengqi Chen

Bug#772204: dput: .orig.tar.gz for non -1 package for security-master

[Osamu Aoki]

Hi Ben,

Thanks for thinking about dput.

(TBH, I don't use dput/dupload much since I use dgit)

On Mon, 2024-04-08 at 07:46 +1000, Ben Finney wrote:
> Control: severity -1 minor
> Control: tags -1 - moreinfo
> Control: merge 706607 -1
> 
> On 28-Aug-2016, Ben Finney wrote:
> 
> > Is this behaviour the same problem reported in [bug#706607], or is that a
> > separate problem?

FYI:

These 2 bug reports are not talking the same triggering conditions.  But fix may
be a single path since these are around the same message.  So merging these are
valid action :-)

* https://bugs.debian.org/772204
  * This is for security upload situation
  * Upload requires to have orig.tar.gz for all security uploads
  * Adjusting message is requested to be clear.

* https://bugs.debian.org/706607#21
  * This is for normal upload case.
  * Upload doesn't require to have orig.tar.gz for usual uploads.
  * Bug hits when used for derivative dists which uses -0 or similar as
"revision"

Here, "revision" means string matched for P.

If I understand correctly, requiring orig.tar.gz upload for "revision" -1 is
only for uploading to Debian repository.  Ubuntu or other derivatives such as
Kali start their "revision" from -0 or similar.

706607 talks interesting corner case for the upstream version which may contain
"-" in it.

706607 talks valid phrase adjustment but that's not enough to address situation
described in 772204.

In light of these, I think following are needed.

Action 1:
* Fix REGEX to accommodate -0 variants and upstream version with "-".

Action 2:
* Adjust message to address rejection condition and repository policy


I hope you addressed both pending actions.

Regards,

Osamu

Bug#1067916: FTBFS: tests failed

[tony mancill]

On Sun, Apr 07, 2024 at 02:43:20PM +, tony mancill wrote:
> > > > Source: capnproto
> > > > Version: 1.0.1-3
> > > > Severity: serious
> > > > Tags: ftbfs
> > > > 
> > > > https://buildd.debian.org/status/fetch.php?pkg=capnproto=armhf=1.0.1-3%2Bb2=1711652087=0
> 
> I am assuming that if the futux syscall here:
> 
> https://sources.debian.org/src/capnproto/1.0.1-3/src/kj/mutex.c%2B%2B/#L250
> 
> which also gets passed a timespec, was the culprit, that more things would be
> broken on armhf than just a few tests.  But that's an area I need to explore
> further.

So assumptions can be wrong... :)  Many thanks to Tom Lee for creating
a simple test case [1] that demonstrates the futex syscall returning
early on armhf + t64, while being successful on the same architecture
with the pre-t64 userspace and other architectures.

Results on the porter box with t64 userspace:

(sid_armhf-dchroot)$ uname -a
Linux abel 4.19.0-21-armmp-lpae #1 SMP Debian 4.19.249-2 (2022-06-30) armv7l 
GNU/Linux
(sid_armhf-dchroot)$ ./futex-test
futex returned too early: 26640 ns
(sid_armhf-dchroot)$ ./futex-test
futex returned too early: 34560 ns
(sid_armhf-dchroot)$ ./futex-test
futex returned too early: 23920 ns
(sid_armhf-dchroot)$ ./futex-test
futex returned too early: 33560 ns

Running the same code compiled against the bookworm userspace on the
same armhf porterbox is successful:

(bookworm_armhf-dchroot)$ uname -a
Linux abel 4.19.0-21-armmp-lpae #1 SMP Debian 4.19.249-2 (2022-06-30) armv7l 
GNU/Linux
(bookworm_armhf-dchroot)$ ./futex-test-bookworm
ok: 10069107
(bookworm_armhf-dchroot)$ ./futex-test-bookworm
ok: 10067586
(bookworm_armhf-dchroot)$ ./futex-test-bookworm
ok: 10068587
(bookworm_armhf-dchroot)$ ./futex-test-bookworm
ok: 10068187
(bookworm_armhf-dchroot)$ ./futex-test-bookworm
ok: 10069026


This may be a naive question, but since we're dealing with a syscall
that passes a timespec, is there a minimum kernel version required for
the time_t 64 userspace?

In any event, I'm not sure about the next steps here.  Any suggestions?
Should I work with DSA to try to get a porter box with a newer kernel to
confirm that that resolves the issue with the test?  (I think this would
have eventual implications for the buildds.)

Thank you,
tony

[1] 
https://gist.githubusercontent.com/thomaslee/e8484eeae64004e2a3be8be88e2e25e8/raw/e9edc3025d54afbff6b0492998ee624d8b2ac317/futex-test.c


signature.asc
Description: PGP signature

Bug#1068613: lomiri-history-service FTBFS with abseil 20230802.1

[Adrian Bunk]

Source: lomiri-history-service
Version: 0.5-1
Severity: serious
Tags: ftbfs
Forwarded: 
https://gitlab.com/ubports/development/core/history-service/-/merge_requests/35

https://buildd.debian.org/status/fetch.php?pkg=lomiri-history-service=amd64=0.5-1%2Bb2=1712518035=0

...
In file included from /usr/include/absl/base/config.h:86,
 from /usr/include/absl/algorithm/algorithm.h:29,
 from /usr/include/absl/algorithm/container.h:53,
 from /usr/include/absl/container/node_hash_set.h:40,
 from /usr/include/phonenumbers/phonenumberutil.h:33,
 from /<>/src/phoneutils.cpp:28:
/usr/include/absl/base/policy_checks.h:79:2: error: #error "C++ versions less 
than C++14 are not supported."
   79 | #error "C++ versions less than C++14 are not supported."
  |  ^
...

Bug#1065221: O: py7zr -- pure Python 7-zip library

[yokota]

Hello,

> When writing this I'm wondering whether it might be better to remove
> this in Files-Excluded.  On one hand this saves us from mentioning the
> copyright on the other hand we could be really sure that it is not used.
> What do you think - should I override the previous upload without that
> code copy?  I did not wanted to be too invasive with your packaging
> but I would have done so in my packages.

Thanks for your suggestion.
I was dropped embedded library code from brotlicffi and pyzstd, and push
them to salsa.debian.org repository.

I was also fix some copyright issues.

--
YOKOTA Hiroshi

Bug#1067858: reset SuperSpeed USB device number 2 using xhci_hcd

[Pierre Tomon]

Control: found 1067858 6.1.82+1
Control: notfound 1067858 6.1.76+1
Control: notfound 1067858 6.6.15+2

Stable-p-u is also affected by this bug.

Bug#1068612: libopenmpi3t64: mca_pmix_pmix3x.so: undefined symbol: pmix_value_load on 32bit

[Adrian Bunk]

Package: libopenmpi3t64
Version: 4.1.6-8
Severity: serious
Tags: ftbfs
Control: affects -1 src:hypre src:h5py src:fenics-dolfinx src:dune-uggrid 
src:dolfinx-mpc src:dolfin src:liggghts

https://buildd.debian.org/status/fetch.php?pkg=dune-uggrid=i386=2.9.0-2%2Bb3=1712511034=0

...
orted: symbol lookup error: 
/usr/lib/i386-linux-gnu/openmpi/lib/openmpi3/mca_pmix_pmix3x.so: undefined 
symbol: pmix_value_load
...

Bug#1068611: python3-editables: bacport to stable

[mike]

Package: python3-editables
Version: 0.5-1
Severity: wishlist
X-Debbugs-Cc: okgomdjgbm...@gmail.com

Dear Maintainer,


This is needed to build yt-dlp. It would be nice to backport it.

Bug#1021392: dput: Ambiguity when dput thinks package is already uploaded

[Ben Finney]

Control: severity -1 minor
Control: merge 941784 -1

On 07-Oct-2022, Moritz Schlarb wrote:

> This bit me recently

You're not alone; bug#941784 describes this same behaviour. I'm merging
this report with that one.

-- 
 \  “Very few things happen at the right time, and the rest do not |
  `\ happen at all. The conscientious historian will correct these |
_o__)  defects.” —Mark Twain, _A Horse's Tale_ |
Ben Finney 

signature.asc
Description: PGP signature

Bug#1068610: dico: binary-all FTBFS

[Adrian Bunk]

Source: dico
Version: 2.11-4
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Helmut Grohne 

https://buildd.debian.org/status/logs.php?pkg=dico=all

...
   debian/rules execute_after_dh_installsystemd
make[1]: Entering directory '/<>'
ln -s dicod.service debian/dicod/`test -e 
debian/dicod/lib/systemd/system/dicod.service || echo 
usr/`lib/systemd/system/dictd.service
ln: failed to create symbolic link 
'debian/dicod/usr/lib/systemd/system/dictd.service': No such file or directory
make[1]: *** [debian/rules:52: execute_after_dh_installsystemd] Error 1

Bug#1068574: bookworm-pu: package icinga2/2.13.6-2+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

Please go ahead.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#987943: www.debian.org: Developers Reference: Sphinx search non-functional: searchindex.js missing

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sat, 25 Nov 2023 12:43:24 +0100):
> In the meantime things have evolved, Sphinx has changed its way to
> deal with this; see 
> 
> 
> Thus, the current developers-reference built on a bookworm or later system
> leads to a output, where the search is working.
> Can be viewed at 
> 
> (also with a different html theme, BTW)
> 
> 
> So, when wolkenstein gets updates to bookworm (currently on bullseye)
> it will just, I guess.

Sorry, the above was complete nonsens, since for Developers Reference on the 
website we use the binary Debian package as a basis, which is built by
buildds, so on unstable. Thus the Sphinx version on wolkenstein is completely 
irrelevant.

I mixed that up with the release-notes, which I have worked on to migrate to
Sphinx: since there is no such package like 'release-notes' in the archive,
they in fact need to be built from scratch on wolkenstein.

So ...

$ time_machine start target=submitting-date

... we are back to the beginning:

Stefano Rivera  wrote:
> Sphinx search is broken on the developers reference:
> https://www.debian.org/doc/manuals/developers-reference/searchindex.js
> is 404.

Note: I'm working on debian-policy now, which has also switched to Sphinx;
as debian-policy shows the same problem, I think it's a systematic issue and
thus a solution for this will work for other sphinx-based manuals as well
(hopefully).

First, I focused on the symlinks to several .js scripts in _static, which point
to not existing targets. That has been mentioned at several places, and drawed
my attention.
After several attempts I have all those scripts existing now on the relevant 
place at https://www.debian.org/doc/debian-policy/_static/,
however the search is still not working :-((

But then --- guess what: the subject says it all:
"searchindex.js is missing" !

Indeed, that file is existing here after a local build of the package, but
is missing on our webserver.
That's because the 7doc script in webmaster's cron repo (to push /doc content on
the website) does only process html files in the root directoriy of the manual, 
no .js files.

I have prepared a build of debian-policy with all needed javascript scripts
and that searchindex.js file at
https://people.debian.org/~holgerw/new-rtd-sphinx-theme-for-debian/debian-policy/debian-policy/

Everything works fine there as far a I see (with a desktop firefox and brave
browser, as well as with the mobile versions of those browsers on my 
smartphone).
Feel free to test with more browsers/platforms/whatever.

I guess I will need to trim the 7doc script once again - h ...


So long
Holger


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

Bug#1055802: qtbase-opensource-src 5.15.8+dfsg-11+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1055802 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: qtbase-opensource-src
Version: 5.15.8+dfsg-11+deb12u1

Explanation: fix regression in patch for CVE-2023-24607; avoid using system CA 
certificates when not wanted [CVE-2023-34410]; fix buffer overflow 
[CVE-2023-37369]; fix infinite loop in XML recursive entity expansion 
[CVE-2023-38197]

Bug#1055966: openvpn-dco-dkms 0.0+git20231103-1~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1055966 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: openvpn-dco-dkms
Version: 0.0+git20231103-1~deb12u1

Explanation: build for Linux >= 6.5; install compat-include directory; fix 
refcount imbalance

Bug#1067956: rocalution: FTBFS on armhf (test failure with memory allocation)

[Cordell Bloor]

Control: severity 1067956 important

The rocalution package has never successfully built for armhf, so I 
don't think this qualifies as release-critical.


It's great to see that the rocalution package gets all the way into the 
tests before failing, though. The upstream project only officially 
supports amd64, so that's better than I was expecting. The tests should 
probably skip anything requiring more than ~2 GB of memory when running 
on 32-bit architectures. Patches are welcome.


Sincerely,
Cory Bloor

Bug#1057407: texworks: Intent to drop poppler-qt6 on i386

[Preuße]

On 20.12.2023 15:25, Jeremy Bícha wrote:

On Sat, Dec 16, 2023 at 6:02 PM Hilmar Preuße  wrote:


Hi,


As no package depend on texworks, I'll drop i386 as requested. If you
have a patch for me I'll be glad.


My plan is to first get a newer poppler from Experimental into
Unstable. After that poppler transition completes, then I can stop
building poppler qt6 on i386 and ask the ftpmasters to remove poppler
qt6 on i386 and texworks on i386. I don't think there is anything we
need to do to the texworks packaging; texworks will just be in depwait
status on i386.



OK, fine. So I guess there is nothing to do from my side regarding 
packaging, we have just to remove the texworks packages for i386 from 
the archive, else you won't be able to remove your packages, right?


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#772204: dput: .orig.tar.gz for non -1 package for security-master

[Ben Finney]

Control: severity -1 minor
Control: tags -1 - moreinfo
Control: merge 706607 -1

On 28-Aug-2016, Ben Finney wrote:

> Is this behaviour the same problem reported in [bug#706607], or is that a
> separate problem?

On the assumption that bug#706607 reports the same problem, I am merging
this bug report with that one.

If there is a change needed, that is not covered by the report in
bug#706607 (and that I did not parse correctly from this bug report),
please feel free to describe it separately in a new bug report.

-- 
 \  “Progress might have been all right once, but it's gone on too |
  `\long.” —Ogden Nash |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1068609: (no subject)

[Rene Engelhard]

fixed 1068609 4:24.2.2-2
notfixed 1068609 4:24.2.2-3
thanks

4:24.2.2-2 has it fixed of course, not 4:24.2.2-3:

libreoffice (4:24.2.2-2) unstable; urgency=medium

  * debian/patches/split-sdbc-firebird-mariadb.diff: create extra
{mysqlc,firebird_sdbc}.xcd as for evoab. Otherwise configuration
parts of it ends up (or not in indep builds) in libreoffice-commons
main.xcd
  * debian/rules:
- install new {mysqlc,firebird_sdbc}.xcd into the respective
  packages
- build-depend on liborcus-dev (>> 0.19.2-3+b1) as for libxmlsec1-dev
  * debian/libreoffice-sdbc-{mysql,firebird}.ucf: add
  * debian/control.in: add Breaks: -sdbc-{mysql,firebird} (<< 4:24.2.2-2)
to libreoffice-common

 -- Rene Engelhard   Sat, 30 Mar 2024 09:30:30 +

even though -2 was never attempted on armhf due to that build-dep (-3 
was built then)

Bug#1065413: bookworm-pu: package openssl/3.0.13-1~deb12u1

[Sebastian Andrzej Siewior]

On 2024-03-24 20:06:12 [+], Adam D. Barratt wrote:
> 
> Sorry for not getting to this sooner. Is this still the case?

So. This happened #1068045 (yapet broke with 1.0 format) due to the
update. On the bright side it has been broken in unstable but unnoticed.
Looking into it but also sleeping (but making progress).

> Regards,
> 
> Adam

Sebastian

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

[Sebastian Andrzej Siewior]

On 2024-04-07 15:36:37 [+0800], Sean Whitton wrote:
> Hello,
Hi,

> On Sat 06 Apr 2024 at 03:24pm +02, Salvatore Bonaccorso wrote:
> 
> > As it is a regression caused by libssl3 3.0.11 based to 3.0.13, why is
> > it reassigned to yapet? (the regression is as well present in
> > unstable).
> 
> I was just thinking that it may be a flaw in how YAPET calls into
> openssl, and we don't have evidence either way atm.

The failure is due to openssl upstream commit
3a95d1e41abf ("update/final: Return error if key is not set")

and openssl complains with "error:1C800072:Provider routines::no key
set". I need to figure out if openssl forgot to account that a key has
been set or if something is wrong with the key.

Sebastian

Bug#1024532: gjs allocates 237 GB of RAM during build (!)

[Santiago Vila]

tags 1024532 - moreinfo
close 1024532 1.79.3-1
thanks

I can verify that the version currently in trixie does not show this
behaviour anymore (maximum allocated memory is now below 1 GB).

Therefore I'm closing this bug myself.

(It would have been interesting maybe to know in which version it
was fixed and how, but I'll leave that to bug archeologists).

Thanks.

Bug#1056936: bookworm-pu: package glewlwyd/2.7.5-3

[Nicolas Mora]

Le 2024-04-06 à 18 h 38, Jonathan Wiltshire a écrit :


Sorry for the delay; please go ahead.


Thanks, it's uploaded!

/Nicolas

Bug#1068609: failure log for reference

[Rene Engelhard]

Hi,

for the sake of this bug (since it misses the mail history) this is the 
FTBFS:


Test name: testContentGnumeric::TestBody
assertion failed
- Expression: 
xServiceInfo->supportsService("com.sun.star.sheet.SpreadsheetDocument")


Failures !!!
Run: 64   Failure total: 1   Failures: 1   Errors: 0

4:24.2.2-1 build failed with an orcus not rebult for time_t and after 
that it succeeded (-3 forced an appropriate build-dep)


4:24.2.0-1 from testing now fails in that way after the orcus bin-NMU 
(0.19.2-3+b2) migrated.


Regards,

Rene

Bug#1057648: synadm: Add bash completion script to synadm

[Sebastien Badia]

On Wed, Dec 06, 2023 at 03:51:19PM (+0100), Nicolas Peugnet wrote:
> Dear Maintainer,
> 
> In case you didn't see, I made a merge request on salsa [1] to generate
> the bash completion script from Click and to add it to the binary
> package.
> I'm trying to also send the patch via reportbug, but as this is the
> first time I am trying to do it I am not entirely sure to succeed.
> 
> [1] https://salsa.debian.org/matrix-team/synadm/-/merge_requests/1

Hi Nicolas !

Sorry for the late reply, but thank you for this patch !

0.46 is now merged upstream with your patch, I've just imported this
version in Debian.

Cheers,

Sebastien


signature.asc
Description: PGP signature

Bug#1068076: libssh2: FTBFS on hurd-any

[Nicolas Mora]

Hello,

On Sat, 30 Mar 2024 09:55:07 +0100 Mattias Ellert 
 wrote:


The package fails to build on hurd due to the use of MAXPATHEN:

session_fixture.c:231:36: error: ‘MAXPATHLEN’ undeclared (first use in
this function)
  231 | static char filepath[NUMPATHS][MAXPATHLEN];
  |^~

PATH_MAX and MAXPATHLEN are on purpose not defined on hurd.



I think the best way is to forward to upstream.

Are there any alternatives to MAXPATHLEN on Hurd or any workaround you 
know of?


/Nicolas

Bug#1068609: libreoffice: FTBFS on arrmhf: testContentGnumeric assertion failed,- Expression: xServiceInfo->supportsService("com.sun.star.sheet.SpreadsheetDocument")

[Rene Engelhard]

Source: libreoffice

Version: 4:24.2.0-1

Severity: serious

Tags: trixie ftbfs


Hi,

Am 30.03.24 um 12:56 schrieb Rene Engelhard:

Am 30.03.24 um 08:49 schrieb Rene Engelhard:
That would mean a bin-NMU of liborcus would work and then a rebuild 
of libreoffice (gb, but I need a new upload anyway)


So we probably missed a rename? (Or more for stuff silently using 
time-date?)


boost1.83 (iostream)? liborcus? Both?


I prepared a time_t rename of liborcus. Can upload it (to NEW...) any 
time.
A bin-NMU would also work, except for a needed runtime dependency, 
then again it's "only" the gnumeric filter...). I wouldn't mind a 
simple bin-NMU at least.


That one got done on April 1 :)

> Ran the full tests with it. Passed.

(Unfortunately) that (expectedly) now causes the reverse issue in 
testing. Just verified in a local build.


Fortunately the startup of LO works fine (tried on my machine here) so 
it's probably "just" gnumeric (and maybe other gnumeric-using filters) 
affected.



Filing a bug for reference. This is fixed in 4:24.2.2-3, will mark it as 
such when I get the bug number.



Regards,

Rene

Bug#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean

[Rebecca N. Palmer]

Control: unblock 1068104 by -1
Control: unblock 1068104 by 1068422

To avoid being blocked by this bug, the pandas version I just uploaded 
temporarily disables the documentation.


This is also an option for any other affected packages that urgently 
need to be uploaded.  (I don't know whether the other two listed 
Blocks/Affects are that urgent.)

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

[Peter Michael Green]

Package: tfortune
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, 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

Bug#1004866: ITP: cppinsights -- see your source code with the eyes of a compiler

[Victor Westerhuis]

In case anyone wants to pick this up: I packaged this for my own use at 
https://salsa.debian.org/viccie30/cppinsights. The packaging works, I 
just haven't gone through all the files to check for copyright and 
license statements, so it's not in a state to go into the archive.


Anyone who wants to get this into Debian is welcome to use it as a 
starting point. If I have some more time in the future and nobody steps 
up, I might try to get it into Debian myself.

--
Vriendelijke groet, Kind regards,

Victor Westerhuis


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Sylvestre Ledru]

Package: coreutils
Version: 9.4-2+b1
Severity: wishlist

Dear Maintainer,

As it is a key package for Debian and the context of the xz recent issue,
it would be nice to have it available on salsa as a git repo.

Cheers,
Sylvestre


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

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

Versions of packages coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.37-12
ii  libgmp10 2:6.3.0+dfsg-2
ii  libselinux1  3.5-1+b1
ii  libssl3  3.1.4-2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#1068606: rust-alacritty: New upstream release

[Sylvestre Ledru]

Source: rust-alacritty
Severity: wishlist

Dear Maintainer,

Could you please package 0.13.2 ?

Thanks
Sylvestre

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

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

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

[Xiyue Deng]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "web-mode":

 * Package name : web-mode
   Version  : 17.3.13-1
   Upstream contact : François-Xavier Bois 
 * URL  : https://web-mode.org
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/emacsen-team/web-mode
   Section  : lisp

The source builds the following binary packages:

  elpa-web-mode - major emacs mode for editing web templates

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

  https://mentors.debian.net/package/web-mode/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/web-mode/web-mode_17.3.13-1.dsc

Changes since the last upload:

 web-mode (17.3.13-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream release
   * Set upstream metadata fields: Bug-Database, Bug-Submit,
 Repository-Browse
   * Update standards version to 4.6.2; no changes needed
   * Use https link of homepage in d/control
   * Modernize d/watch using special substitute strings to be more robust
   * Fix issues in d/copyright
 - Clarify license to be GPL-3+ to be consistent with upstream
 - Update copyright year info for upstream
 - Add copyright info for debian/*
 - Add Upstream-Contact

Regards,
-- 
Xiyue Deng

Bug#1068604: nmu: pnc_0.9.4-3

[plugwash]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

The virtual package libphonenumber8-protobuf32 was renamed to
libphonenumber8t64-protobuf32 as part of the time_t transition.

Most reverse depedencies seem to have already been rebuilt, but four packages
still depend on the old virtual package. libebook-contacts-1.2-4,
kamailio-phonenum-modules, mmsd-tng and pnc

libebook-contacts-1.2-4 is a cruft package
kamailio already has a binnmu scheduled
mmsd-tng has a FTBFS bug.

That leaves pnc as being ready for a binnmu.

nmu pnc_0.9.4-3 . ANY . unstable . -m "rebuild against 
libphonenumber8t64-protobuf32 for time64 transition"

-- System Information:
Debian Release: 10.13
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Bug#1068603: clevis-luks: jq should be either a dependency or recommended package to prevent 'clevis luks edit' fail

[anon2529]

Package: clevis-luks
Version: 19-2
Severity: normal
X-Debbugs-Cc: spamthath...@gmail.com

Example of the problem:

$ sudo clevis luks edit -d /dev/sda1 -s 1
/usr/bin/clevis-luks-edit: line 116: jq: command not found
Error reading the configuration from /dev/sda1:1

Workaround: install 'jq' manually and it will work.

It seems 'jq' should be a dependency or recommended package so users do not 
have to install 'jq' manually. Fedora lists 'jq' as a dependency of the 
'clevis' package, but I guess it's okay if we make it a dependency of the 
'clevis-luks' package, since that package provides the 'clevis luks' subcommand.


-- System Information:
Debian Release: 12.2
  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/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clevis-luks depends on:
ii  clevis  19-2
ii  cryptsetup-bin  2:2.6.1-4~deb12u2
ii  luksmeta9-4

clevis-luks recommends no packages.

clevis-luks suggests no packages.

-- no debconf information

Bug#1068601: Acknowledgement (selinux-policy-default: /var with nosuid and SELinux enabled breaks dpkg)

[Blake Lee]

The following dpkg.te seems to have solved the problem for me.

```
module dpkg 1.0; 

require { 
   type dpkg_script_t; 
   type dpkg_t; 
   class process2 nosuid_transition; 
}
```

On Sun, Apr 7, 2024, at 2:42 PM, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 1068601: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068601.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   bl...@volian.org
> (after having been given a Bug report number, if it did not have one).
> 
> Your message has been sent to the package maintainer(s):
> Debian SELinux maintainers 
> 
> If you wish to submit further information on this problem, please
> send it to 1068...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 1068601: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068601
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> 

Bug#1067246: Please provide version 5.0.x

[Jonas Smedegaard]

Quoting Matthias Geiger (2024-03-20 20:49:16)
> Package: librust-event-listener-dev
> Severity: wishlist
> X-Debbugs-Cc: werdah...@riseup.net, plugw...@debian.org
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> The newer async-broadcast (needed for a newer zbus) will require a newer 
> librust-event-listener-dev.
> Affected packages:  rust-async-broadcast, rust-async-lock, 
> rust-async-process, rust-event-listener, rust-async-channel, rust-sqlx-core, 
> rust-async-mutex, rust-zbus, rust-isahc
> 
> I will look into whether I can patch zbus for now. 5.x being available
> in experimental would help a lot.

Thanks for reporting, and for the dependency analysis - that's helpful.

I have a half-baked upgrade to v3 lying around locally.  I will try wrap
that up and update to v5.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1068580: collected: FTBFS on arm{el,hf}: configure: error: "Some plugins are missing dependencies - see the summary above for details"

[Sebastian Ramacher]

Hi Bernd

On 2024-04-07 21:47:58 +0200, Bernd Zeimetz wrote:
> Hi Sebastian,
> 
> https://buildd.debian.org/status/package.php?p=grpc
> 
> its just not built on armel yet and the old version is most likely not
> installable anymore due to the time_t change.

The last build of grpc was done successfully on April 1st. See
https://buildd.debian.org/status/fetch.php?pkg=grpc=armel=1.51.1-4.1%2Bb1=1711980213=0

Also reverse dependencies were rebuilt with 64-bit time_t-aware grpc
packages in the past. See
https://release.debian.org/transitions/html/auto-grpc.html.

The logs also have:

configure:26065: checking for grpc++/grpc++.h
configure:26065: arm-linux-gnueabi-g++ -c -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -Wall 
-Wno-error=deprecated-declarations -std=c++11  -DNOMINMAX  -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
-I/<>/debian/include -UCONFIGFILE 
-DCONFIGFILE='"/etc/collectd/collectd.conf"' conftest.cpp >&5
In file included from /usr/include/absl/base/config.h:86,
 from /usr/include/absl/base/const_init.h:25,
 from /usr/include/absl/synchronization/mutex.h:67,
 from /usr/include/grpcpp/impl/codegen/sync.h:32,
 from /usr/include/grpcpp/completion_queue.h:41,
 from /usr/include/grpcpp/channel.h:25,
 from /usr/include/grpcpp/grpcpp.h:52,
 from /usr/include/grpc++/grpc++.h:26,
 from conftest.cpp:167:
/usr/include/absl/base/policy_checks.h:79:2: error: #error "C++ versions less 
than C++14 are not supported."
   79 | #error "C++ versions less than C++14 are not supported."
  |  ^

So somewhere there is a -std=c++14 missing.

Cheers

> 
> Bernd
> 
> On Sun, 2024-04-07 at 14:48 +0200, Sebastian Ramacher wrote:
> > Source: collectd
> > Version: 5.12.0-17.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=collectd=armhf=5.12.0-17.1=1712493429=0
> > 
> > 
> > Configuration:
> >   Build:
> >     Platform  . . . . . . Linux
> >     Compiler vendor . . . gnu
> >     CC  . . . . . . . . . arm-linux-gnueabihf-gcc
> >     CFLAGS  . . . . . . . -Wall -Werror -g -O2 -Werror=implicit-
> > function-declaration -ffile-prefix-map=/<>=. -fstack-
> > protector-strong -fstack-clash-protection -Wformat -Werror=format-
> > security -Wall -Wno-error=deprecated-declarations -Wno-error=address-
> > of-packed-member -Wno-stringop-truncation -Wno-cpp -Wno-error=format-
> > truncation
> >     CXXFLAGS  . . . . . . -Wall -Werror -g -O2 -ffile-prefix-
> > map=/<>=. -fstack-protector-strong -fstack-clash-
> > protection -Wformat -Werror=format-security -Wall -Wno-
> > error=deprecated-declarations
> >     CPP . . . . . . . . . arm-linux-gnueabihf-gcc -E
> >     CPPFLAGS  . . . . . . -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> > -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -
> > I/<>/debian/include -UCONFIGFILE -
> > DCONFIGFILE='"/etc/collectd/collectd.conf"'
> >     GRPC_CPP_PLUGIN . . . /usr/bin/grpc_cpp_plugin
> >     LD  . . . . . . . . . /usr/bin/ld
> >     LDFLAGS . . . . . . . -Wl,-z,relro -Wl,-z,now
> >     PROTOC  . . . . . . . /usr/bin/protoc
> >     YACC  . . . . . . . . bison -y
> >     YFLAGS  . . . . . . . 
> > 
> >   Libraries:
> >     intel mic . . . . . . no (MicAccessApi not found)
> >     libaquaero5 . . . . . no (libaquaero5.h not found)
> >     libatasmart . . . . . yes
> >     libcurl . . . . . . . yes
> >     libdbi  . . . . . . . yes
> >     libdpdk . . . . . . . no (rte_config.h not found)
> >     libesmtp  . . . . . . yes
> >     libganglia  . . . . . no (gm_protocol.h not found)
> >     libgcrypt . . . . . . yes
> >     libgps  . . . . . . . yes
> >     libgrpc++ . . . . . . no ( not found)
> >     libhiredis  . . . . . yes
> >     libi2c-dev  . . . . . yes
> >     libiokit  . . . . . . no
> >     libiptc . . . . . . . yes
> >     libjansson  . . . . . yes
> >     libjevents  . . . . . no (jevents.h not found)
> >     libjvm  . . . . . . . yes
> >     libkstat  . . . . . . no (Solaris only)
> >     libkvm  . . . . . . . no
> >     libldap . . . . . . . yes
> >     liblua  . . . . . . . yes
> >     libmemcached  . . . . yes
> >     libmicrohttpd . . . . yes
> >     libmnl  . . . . . . . yes
> >     libmodbus . . . . . . yes
> >     libmongoc . . . . . . yes
> >     libmosquitto  . . . . yes
> >     libmysql  . . . . . . yes
> >     libnetapp . . . . . . no (netapp_api.h not found)
> >     libnetsnmp  . . . . . yes
> >     libnetsnmpagent . . . yes
> >     libnotify . . . . . . yes
> >     libnvidia-ml  . . . . no
> >     libopenipmi . . . . . yes
> >     liboping  . . . . . . yes
> >     libowcapi . . . . . . yes
> >     libpcap . . . . . . . yes
> >     libperfstat . . . . . no (AIX 

Bug#1068597: quodlibet: most Explore options are brain damaged

[Martin]

Control: retitle -1 quodlibet: please add other, better explore options
Control: severity -1 wishlist

On 2024-04-07 20:42, José Luis González wrote:
> Important severity because the program is unmanageable with more than
> just a beginner collection.

I respect your opinion, but mind, that use cases can be different.

E.g. I use quodlibet for years, with more than 45k tracks, but use
"Track List" and "Playlists" only, and do not care about albums at all.

Your feature request might be valid for your specific use case, but to
others the program is perfectly usable as it is.

Bug#1068580: collected: FTBFS on arm{el,hf}: configure: error: "Some plugins are missing dependencies - see the summary above for details"

[Bernd Zeimetz]

Hi Sebastian,

https://buildd.debian.org/status/package.php?p=grpc

its just not built on armel yet and the old version is most likely not
installable anymore due to the time_t change.

Bernd

On Sun, 2024-04-07 at 14:48 +0200, Sebastian Ramacher wrote:
> Source: collectd
> Version: 5.12.0-17.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=collectd=armhf=5.12.0-17.1=1712493429=0
> 
> 
> Configuration:
>   Build:
>     Platform  . . . . . . Linux
>     Compiler vendor . . . gnu
>     CC  . . . . . . . . . arm-linux-gnueabihf-gcc
>     CFLAGS  . . . . . . . -Wall -Werror -g -O2 -Werror=implicit-
> function-declaration -ffile-prefix-map=/<>=. -fstack-
> protector-strong -fstack-clash-protection -Wformat -Werror=format-
> security -Wall -Wno-error=deprecated-declarations -Wno-error=address-
> of-packed-member -Wno-stringop-truncation -Wno-cpp -Wno-error=format-
> truncation
>     CXXFLAGS  . . . . . . -Wall -Werror -g -O2 -ffile-prefix-
> map=/<>=. -fstack-protector-strong -fstack-clash-
> protection -Wformat -Werror=format-security -Wall -Wno-
> error=deprecated-declarations
>     CPP . . . . . . . . . arm-linux-gnueabihf-gcc -E
>     CPPFLAGS  . . . . . . -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -
> I/<>/debian/include -UCONFIGFILE -
> DCONFIGFILE='"/etc/collectd/collectd.conf"'
>     GRPC_CPP_PLUGIN . . . /usr/bin/grpc_cpp_plugin
>     LD  . . . . . . . . . /usr/bin/ld
>     LDFLAGS . . . . . . . -Wl,-z,relro -Wl,-z,now
>     PROTOC  . . . . . . . /usr/bin/protoc
>     YACC  . . . . . . . . bison -y
>     YFLAGS  . . . . . . . 
> 
>   Libraries:
>     intel mic . . . . . . no (MicAccessApi not found)
>     libaquaero5 . . . . . no (libaquaero5.h not found)
>     libatasmart . . . . . yes
>     libcurl . . . . . . . yes
>     libdbi  . . . . . . . yes
>     libdpdk . . . . . . . no (rte_config.h not found)
>     libesmtp  . . . . . . yes
>     libganglia  . . . . . no (gm_protocol.h not found)
>     libgcrypt . . . . . . yes
>     libgps  . . . . . . . yes
>     libgrpc++ . . . . . . no ( not found)
>     libhiredis  . . . . . yes
>     libi2c-dev  . . . . . yes
>     libiokit  . . . . . . no
>     libiptc . . . . . . . yes
>     libjansson  . . . . . yes
>     libjevents  . . . . . no (jevents.h not found)
>     libjvm  . . . . . . . yes
>     libkstat  . . . . . . no (Solaris only)
>     libkvm  . . . . . . . no
>     libldap . . . . . . . yes
>     liblua  . . . . . . . yes
>     libmemcached  . . . . yes
>     libmicrohttpd . . . . yes
>     libmnl  . . . . . . . yes
>     libmodbus . . . . . . yes
>     libmongoc . . . . . . yes
>     libmosquitto  . . . . yes
>     libmysql  . . . . . . yes
>     libnetapp . . . . . . no (netapp_api.h not found)
>     libnetsnmp  . . . . . yes
>     libnetsnmpagent . . . yes
>     libnotify . . . . . . yes
>     libnvidia-ml  . . . . no
>     libopenipmi . . . . . yes
>     liboping  . . . . . . yes
>     libowcapi . . . . . . yes
>     libpcap . . . . . . . yes
>     libperfstat . . . . . no (AIX only)
>     libperl . . . . . . . yes (version 5.38.2)
>     libpmwapi . . . . . . no (pmw_api.h not found)
>     libpq . . . . . . . . yes
>     libpqos . . . . . . . no (pqos.h not found)
>     libprotobuf . . . . . yes
>     libprotobuf-c . . . . yes
>     libpython . . . . . . yes
>     libqpid-proton .  . . yes
>     librabbitmq . . . . . yes
>     libriemann-client . . yes
>     librdkafka  . . . . . yes
>     librouteros . . . . . no (routeros_api.h not found)
>     librrd  . . . . . . . yes
>     libsensors  . . . . . yes
>     libsigrok   . . . . . no (pkg-config could not find libsigrok)
>     libssl  . . . . . . . yes
>     libslurm .  . . . . . no (pkg-config doesn't know libslurm)
>     libstatgrab . . . . . no
>     libtokyotyrant  . . . no (tcrdb.h not found)
>     libudev . . . . . . . yes
>     libupsclient  . . . . yes
>     libvarnish  . . . . . no (pkg-config doesn't know varnishapi)
>     libvirt . . . . . . . yes
>     libxenctrl  . . . . . yes
>     libxml2 . . . . . . . yes
>     libxmms . . . . . . . no
>     libyajl . . . . . . . yes
>     oracle  . . . . . . . no (ORACLE_HOME is not set)
>     protobuf-c  . . . . . yes
>     protoc 3  . . . . . . yes
> 
>   Features:
>     daemon mode . . . . . yes
>     debug . . . . . . . . no
> 
>   Bindings:
>     perl  . . . . . . . . yes (INSTALLDIRS=vendor INSTALL_BASE=)
> 
>   Modules:
>     aggregation . . . . . yes
>     amqp    . . . . . . . yes
>     amqp1   . . . . . . . yes
>     apache  . . . . . . . yes
>     apcups  . . . . . . . yes
>     apple_sensors . . . . no (disabled on command line)
>     aquaero . . . . . . . no (disabled on command line)
>     ascent  . . . . . . . yes
>     barometer . . . . . . yes
>     battery . . . . . . . yes
>     bind  . . . . . . . . yes
>     buddyinfo . 

Bug#1068602: swtpm-libs - still depends on old libglib2.0-0 after binnmu

[Peter Michael Green]

Package: swtpm-libs
Version: 0.7.1-1.3
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, swtpm-libs still depends
on libglib2.0-0 rather than libglib2.0-0t64. As a result swtpm-tools
is uninstallable on architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports architectures).

https://qa.debian.org/dose/debcheck/unstable_main/1712466002/packages/swtpm-tools.html#d4ad4752e7c19dd554b6071ae9396bd1

Bug#1068601: selinux-policy-default: /var with nosuid and SELinux enabled breaks dpkg

[Blake Lee]

Package: selinux-policy-default 
X-Debbugs-Cc: bl...@volian.org 
Version: 2:2.20240202-1 
Severity: important 

Hello, 

I have been messing around with configuring Debian with CIS controls and using 
SELinux.

The first problem I've encountered is that having `/var` configured with 
`nosuid` option causes dpkg to break for scripts. An example of the error 
message with `apt install vim`.

```
dpkg (subprocess): unable to execute new vim-runtime package pre-installation 
script (/var/lib/dpkg/tmp.ci/preinst): Permission denied 
dpkg: error processing archive 
/var/cache/apt/archives/vim-runtime_2%3a9.1.0199-1_all.deb (--unpack): 
new vim-runtime package pre-installation script subprocess returned error exit 
status 2 
dpkg (subprocess): unable to execute new vim-runtime package post-removal 
script (/var/lib/dpkg/tmp.ci/postrm): Permission denied 
dpkg: error while cleaning up:  
new vim-runtime package post-removal script subprocess returned error exit 
status 2
```

`audit2why -a` gives me

```
type=AVC msg=audit(1712517197.064:359): avc:  denied  { nosuid_transition } for 
 pid=5633 comm="dpkg" scontext=unconfined_u:unconfined_r:dpkg_t:s0-s0:c0.c1023 
tcontext=unconfined_u:unconfined_r:dpkg_script_t
:s0-s0:c0.c1023 tclass=process2 permissive=0
```

and then `audit2why -a` gives me

```
#= dpkg_t == 
allow dpkg_t dpkg_script_t:process2 nosuid_transition;
```

I think due to the importance of dpkg in the Debian ecosystem this should 
probably be allowed in the global policy.

Also it seems that the salsa repository for refpolicy is not up-to-date with 
the package that is being distributed. Salsa still shows refpolicy 2022, but 
I'm seeing 2024 installed on my system. If this could be resolved I'd like to 
fork the repo and tinker with the policy.

Thanks,
Blake

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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) 
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
set 
Shell: /bin/sh linked to /usr/bin/dash 
Init: systemd (via /run/systemd/system) 
LSM: SELinux: enabled - Mode: Permissive - Policy name: default 

Versions of packages selinux-policy-default depends on: 
ii  libselinux1  3.5-2+b1 
ii  libsemanage2 3.5-1+b3 
ii  libsepol23.5-2 
ii  policycoreutils  3.5-2 
ii  selinux-utils3.5-2+b1 

Versions of packages selinux-policy-default recommends: 
ii  checkpolicy  3.5-1 
pn  setools   

Versions of packages selinux-policy-default suggests: 
pn  logcheck 
pn  syslog-summary   

-- no debconf information

Bug#1068600: swi-prolog, uninstallable on 32-bit non-i386 architectures.

[plugwash]

Package: swi-prolog
Version: 9.0.4+dfsg-3.1
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t

It looks like the adjustments for the time64 transition in the 
9.0.4+dfsg-3.1

NMU were incomplete. Resulting in unsatisfiable dependencies on armel
and armhf at least (and probablly some debian-ports architectures too).

swi-prolog (9.0.4+dfsg-3.1) [PTS 
] [ctrl 
]

   ↓ swi-prolog-doc (>= 9.0.4+dfsg-3.1)
swi-prolog-doc 
 
(9.0.4+dfsg-3.1) [PTS ] [ctrl 
]

   ↓ swi-prolog-core (>= 9.0.4+dfsg-3.1)
swi-prolog-core 
 
(9.0.4+dfsg-3.1) [PTS ] [ctrl 
]

   ↓ libswipl9
MISSING

Ubuntu seem to have fixed this.

http://launchpadlibrarian.net/721003900/swi-prolog_9.0.4+dfsg-3.1ubuntu2_9.0.4+dfsg-3.1ubuntu3.diff.gz

Bug#1068599: ruby-xapian - still depends on old libruby3.1 after binnmu

[Peter Michael Green]

Package: ruby-xapian
Version: 1.4.22-1
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, ruby-xapian
still depends on libruby3.1 rather than libruby3.1t64.
As a result it is uninstallable on architectures that are
undergoing the time64 transition
(armel, armhf and some debian-ports architectures).

The following lines in the build log look like a likely culprit.


# The module(s) are linked against libruby2.x but use none of its
# symbols, so there's no dependency generated.  That's unhelpful for
# users and for transitions (https://bugs.debian.org/816775) so
# generate a suitable dependency.
#
# If RUBY_VERSIONS is 2.1 2.2 2.3, Depends: libruby2.3|libruby2.1 |libruby2.2
echo "ruby:Depends=libruby3.1" \
 >> debian/ruby-xapian.substvars

Bug#1068479: cynically closed by Rene Engelhard (Re: Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation)

[Rene Engelhard]

Hi,

Am 07.04.24 um 20:59 schrieb José Luis González:

Am 06.04.24 um 00:34 schrieb José Luis González:

The setting for spacing between paragraphs is missing in the spacing
and indentation tab of the paragraph dialog.

?

  It's definitely there. Format -> Paragraph has spacing "after/before".

I meant spacing between paragraphs, not spacing after and before
paragraphs. The report was crystal clear.

No, it wasn't.

The difference, for those who didn't realize is space after paragraph
happens always, and between only between them, being the regular
separation between paragraphs (the other is formatting, and isn't
useful as a substitute because it adds something undesirable at the end
of the document or between paragraphs and other kinds of block
elements).


Aha.


Still not RC.


You could have replied to my mails, though.


As said here and proved by screenshots in en,de and es this is present.

Why should anybody provide a screenshot of a feature that is missing?
What would be the screenshot of? Vacuum?


Read again, I didn't ask for screenshots.



Closing this non-bug.

The non-bug that should be closed is your brain pretending a RC bug
doesn't exist, especially since you fully knew it was a bug, and you
closed it just because it bothers you having a RC one in the package.
If you don't want to maintain the package leave the position for other
who does, and stop ruining Debian's Quality and bothering me.


Even if there was a bug it's not RC.


From: José Luis González 
To: sub...@bugs.debian.org
Subject: libreoffice-writer: space between paragraphs missing in spacing and 
indentation
Date: Sat, 6 Apr 2024 00:34:12 +0200
X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu)

Package: libreoffice-writer
Version: 4:7.4.7-1+deb12u1
Severity: serious

The setting for spacing between paragraphs is missing in the spacing
and indentation tab of the paragraph dialog.

Serious severity because the bug has a major effect on the usability of
the package, without rendering it completely unusable, considering
paragraphs are a key feature in a word processor, and spacing is
something very very basic for them and incredibly necessary.


And again: That is the definition of important at most, not serious.


Read the bug severities.


Regards,


Rene

Bug#1068598: spice-client-gtk - still depends on old libusbredir packages after binnmu

[Peter Michael Green]

Package: spice-client-gtk
Version: 0.42-2
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition,
spice-client-gtk still depends on libusbredirhost1 and libusbredirparser1,
rather than the t64 versions of those libraries. As a result it is 
uninstallable on

architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports architectures).

Ubuntu has applied a fix for this extracting the package names from 
dpkg-query.


http://launchpadlibrarian.net/720831479/spice-gtk_0.42-2build2_0.42-2ubuntu1.diff.gz

Alternatively I wonder if the dependencies should simply be dropped, 
spice-client-gtk
depends on libspice-client-glib-2.0-8, which depends on both 
libusbredirhost1t64 and

libusbredirparser1t64.

Bug#1068513: dablin: FTBFS on arm{el,hf}: manually disables mpg123's large file API

[Stefan Pöschel]

Hello Sebastian,

it turns out that (Cygwin) compilation no longer needs the large file 
API to be disabled. Hence I re-enabled it and released version 1.16.0.


Best regards,
Stefan

Am 06.04.24 um 22:22 schrieb Sebastian Ramacher:

Source: dablin
Version: 1.15.0-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=dablin=armel=1.15.0-1%2Bb2=1712391165=0

[ 97%] Linking CXX executable dablin
cd /<>/obj-arm-linux-gnueabi/src && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/dablin.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -pie -z now -rdynamic CMakeFiles/dablin.dir/sdl_output.cpp.o 
CMakeFiles/dablin.dir/dabplus_decoder.cpp.o CMakeFiles/dablin.dir/ensemble_source.cpp.o 
CMakeFiles/dablin.dir/ensemble_player.cpp.o CMakeFiles/dablin.dir/edi_source.cpp.o 
CMakeFiles/dablin.dir/edi_player.cpp.o CMakeFiles/dablin.dir/eti_source.cpp.o 
CMakeFiles/dablin.dir/eti_player.cpp.o CMakeFiles/dablin.dir/dab_decoder.cpp.o 
CMakeFiles/dablin.dir/fic_decoder.cpp.o CMakeFiles/dablin.dir/pcm_output.cpp.o 
CMakeFiles/dablin.dir/tools.cpp.o CMakeFiles/dablin.dir/version.cpp.o 
CMakeFiles/dablin.dir/dablin.cpp.o -o dablin  ../fec/libfec.a 
/usr/lib/arm-linux-gnueabi/libatomic.so.1 -lmpg123 -lSDL2 -lfaad -lc -lm
/usr/bin/ld: CMakeFiles/dablin.dir/dab_decoder.cpp.o: in function 
`MP2Decoder::DecodeFrame(unsigned char**)':
./obj-arm-linux-gnueabi/src/./src/dab_decoder.cpp:166:(.text+0x1bb4): undefined 
reference to `mpg123_framebyframe_decode'
collect2: error: ld returned 1 exit status
make[3]: *** [src/CMakeFiles/dablin.dir/build.make:313: src/dablin] Error 1
make[3]: Leaving directory '/<>/obj-arm-linux-gnueabi'
make[2]: *** [CMakeFiles/Makefile2:263: src/CMakeFiles/dablin.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs
[100%] Linking CXX executable dablin_gtk
cd /<>/obj-arm-linux-gnueabi/src && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/dablin_gtk.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -pie -z now -rdynamic CMakeFiles/dablin_gtk.dir/sdl_output.cpp.o 
CMakeFiles/dablin_gtk.dir/dabplus_decoder.cpp.o 
CMakeFiles/dablin_gtk.dir/ensemble_source.cpp.o 
CMakeFiles/dablin_gtk.dir/ensemble_player.cpp.o CMakeFiles/dablin_gtk.dir/edi_source.cpp.o 
CMakeFiles/dablin_gtk.dir/edi_player.cpp.o CMakeFiles/dablin_gtk.dir/eti_source.cpp.o 
CMakeFiles/dablin_gtk.dir/eti_player.cpp.o CMakeFiles/dablin_gtk.dir/dab_decoder.cpp.o 
CMakeFiles/dablin_gtk.dir/fic_decoder.cpp.o CMakeFiles/dablin_gtk.dir/pcm_output.cpp.o 
CMakeFiles/dablin_gtk.dir/tools.cpp.o CMakeFiles/dablin_gtk.dir/version.cpp.o 
CMakeFiles/dablin_gtk.dir/mot_manager.cpp.o CMakeFiles/dablin_gtk.dir/pad_decoder.cpp.o 
CMakeFiles/dablin_gtk.dir/dablin_gtk.cpp.o 
CMakeFiles/dablin_gtk.dir/dablin_gtk_dl_plus.cpp.o 
CMakeFiles/dablin_gtk.dir/dablin_gtk_sls.cpp.o -o dablin_gtk  ../fec/libfec.a 
/usr/lib/arm-linux-gnueabi/libatomic.so.1 -lmpg123 -lSDL2 -lfaad -lc -lgtkmm-3.0 
-latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lgtk-3 -lgdk-3 -lz -latk-1.0 -lcairo-gobject -lgio-2.0 
-lpangomm-1.4 -lglibmm-2.4 -lcairomm-1.0 -lsigc-2.0 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz 
-lcairo -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lm
/usr/bin/ld: CMakeFiles/dablin_gtk.dir/dab_decoder.cpp.o: in function 
`MP2Decoder::DecodeFrame(unsigned char**)':
./obj-arm-linux-gnueabi/src/./src/dab_decoder.cpp:166:(.text+0x1bb4): undefined 
reference to `mpg123_framebyframe_decode'
collect2: error: ld returned 1 exit status
make[3]: *** [src/CMakeFiles/dablin_gtk.dir/build.make:377: src/dablin_gtk] 
Error 1

This is caused by

#define MPG123_NO_LARGENAME // disable large file API here

in src/dab_decoder.h

Cheers

Bug#1068597: quodlibet: most Explore options are brain damaged

[José Luis González]

Package: quodlibet
Version: 4.5.0-2
Severity: important

Most Explore options are unsuitable for a collection or records that is
larger than just infimal. Browsing just by album, which is essentially
the view available besides filesystem, is unmanageable with a regular
collection. A tree interface is mandatory for music, including the
regular views: Genre, Album artist, Artist, Album, File, etc..
Obviously only the Album and File views are the ones that should be
flat, otherwise Artist views have a second level of Albums, and Genre
has a second view of Album artist, Artist, Album, or File views, etc.

Important severity because the program is unmanageable with more than
just a beginner collection.

Bug#1007439: g2p-sk: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.
Please find the debdiff attached.diff -Nru g2p-sk-0.4.2/README g2p-sk-0.4.2/README
--- g2p-sk-0.4.2/README 2024-04-07 18:32:17.0 +
+++ g2p-sk-0.4.2/README 1970-01-01 00:00:00.0 +
@@ -1,45 +0,0 @@
-G2P-SK 0.4.2
-=
-
-
-ABOUT G2P-SK

-
-The phonetic transcription is essential for some linguistic or speech
-recognition applications. Depending on the language either rule based
-or statistical approach is being used. g2p-sk implements the rule 
-based approach but in the future it may be replaced by statistical one.
-
-Each input word consisting of the sequence of graphemes is transcribed
-in to the sequence of phones in the SAMPA coding. If no input file is 
-specified, the standard input is expected. 
-
-The first version was written in 2003 and for syllabic segmentation
-uses the statistical syllabic segmentation included in the sylseg-sk
-package. For the morphematic segmentation the simple morphematic
-dictionary is being used.
-
-Please see the man page, `g2p-sk.1', for information on how to 
-use it.
-
-
-G2P-SK HOME PAGE

-For latest distributions, bug reports, and other stuff, see the
-g2p-sk home page at
-
-   http://www.ivanecky.sk/projects/g2p/
-
-BUGS, SUGGESTIONS, ETC.

-Please write me if you have trouble using or running g2p-sk, or if
-you have suggestions or (preferably) patches.
-
-   Ďoďo Ivanecký
-   dodo...@gmail.com
-   http://www.ivanecky.sk
-
-AUTHORS

-   Ďoďo Ivanecký
-
diff -Nru g2p-sk-0.4.2/debian/README g2p-sk-0.4.2/debian/README
--- g2p-sk-0.4.2/debian/README  1970-01-01 00:00:00.0 +
+++ g2p-sk-0.4.2/debian/README  2024-04-07 18:26:09.0 +
@@ -0,0 +1,45 @@
+G2P-SK 0.4.2
+=
+
+
+ABOUT G2P-SK
+---
+
+The phonetic transcription is essential for some linguistic or speech
+recognition applications. Depending on the language either rule based
+or statistical approach is being used. g2p-sk implements the rule 
+based approach but in the future it may be replaced by statistical one.
+
+Each input word consisting of the sequence of graphemes is transcribed
+in to the sequence of phones in the SAMPA coding. If no input file is 
+specified, the standard input is expected. 
+
+The first version was written in 2003 and for syllabic segmentation
+uses the statistical syllabic segmentation included in the sylseg-sk
+package. For the morphematic segmentation the simple morphematic
+dictionary is being used.
+
+Please see the man page, `g2p-sk.1', for information on how to 
+use it.
+
+
+G2P-SK HOME PAGE
+---
+For latest distributions, bug reports, and other stuff, see the
+g2p-sk home page at
+
+   http://www.ivanecky.sk/projects/g2p/
+
+BUGS, SUGGESTIONS, ETC.
+---
+Please write me if you have trouble using or running g2p-sk, or if
+you have suggestions or (preferably) patches.
+
+   Ďoďo Ivanecký
+   dodo...@gmail.com
+   http://www.ivanecky.sk
+
+AUTHORS
+---
+   Ďoďo Ivanecký
+
diff -Nru g2p-sk-0.4.2/debian/changelog g2p-sk-0.4.2/debian/changelog
--- g2p-sk-0.4.2/debian/changelog   2024-04-07 18:32:17.0 +
+++ g2p-sk-0.4.2/debian/changelog   2024-04-07 18:26:09.0 +
@@ -1,3 +1,11 @@
+g2p-sk (0.4.2-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0. Closes: #1007439
+  * d/copyright: Convert to machine-readable format.
+
+ -- Bastian Germann   Sun, 07 Apr 2024 18:26:09 +
+
 g2p-sk (0.4.2-4) unstable; urgency=low
 
   * Removal of obsolete debhelper compat (closes:#965532).
diff -Nru g2p-sk-0.4.2/debian/copyright g2p-sk-0.4.2/debian/copyright
--- g2p-sk-0.4.2/debian/copyright   2024-04-07 18:32:17.0 +
+++ g2p-sk-0.4.2/debian/copyright   2024-04-07 18:25:54.0 +
@@ -1,26 +1,24 @@
-This is g2p-sk, written and maintained by Ďoďo 
-debianized on Mon, 28 Aug 2006 19:19:47 +0200.
-
-The original source can always be found at:
-   ftp://ftp.debian.org/dists/unstable/main/source/
-
-Copyright Holder:  Ďoďo Ivanecký
-
-License:
-
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This is g2p-sk, written and maintained by Ďoďo 
+ debianized on Mon, 28 Aug 2006 19:19:47 +0200.
+
+Files: *
+Copyright:  Ďoďo Ivanecký
+License: GPL-2+
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.
-
+ .
   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.
-
+ .
   You should have received a copy of the 

Bug#1068595: libreoffice-writer: insert space missing

[Rene Engelhard]

tag 1068595 + moreinfo

thanks


Am 07.04.24 um 20:02 schrieb José Luis González:

Space insertion is missing in the insert menu.


Huh? What?


Normal space is "Space".

Non breaking space is Insert -> Formatting Mark -> Non breaking space if 
you want to use the menu. One can argue that it's not visible enough but 
that's by no means important.



Or what space do you  mean?


What are you aiming at with your non-bugs?


Regards,


Rene

Bug#1066649: libtritonus-java: diff for NMU version 20070428-14.2

[tony mancill]

On Fri, Mar 29, 2024 at 12:50:03AM +0500, Andrey Rakhmatullin wrote:
> Control: tags 1066649 + patch
> Control: tags 1066649 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for libtritonus-java (versioned as 20070428-14.2) and
> uploaded it to unstable.

Thank you for the NMU.  The debdiff has been applied to the Salsa repo.

Bug#1007396: funnelweb-doc: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.
Please find the debdiff attached.diff -Nru funnelweb-doc-3.2d/debian/changelog 
funnelweb-doc-3.2d/debian/changelog
--- funnelweb-doc-3.2d/debian/changelog 2024-04-07 18:13:23.0 +
+++ funnelweb-doc-3.2d/debian/changelog 2024-04-07 18:05:02.0 +
@@ -1,3 +1,11 @@
+funnelweb-doc (3.2d-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0 (Closes: #1007396).
+  * d/copyright: Convert to machine-readable format.
+
+ -- Bastian Germann   Sun, 07 Apr 2024 18:05:02 +
+
 funnelweb-doc (3.2d-4.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru funnelweb-doc-3.2d/debian/copyright 
funnelweb-doc-3.2d/debian/copyright
--- funnelweb-doc-3.2d/debian/copyright 2024-04-07 18:13:23.0 +
+++ funnelweb-doc-3.2d/debian/copyright 2024-04-07 18:05:02.0 +
@@ -1,24 +1,25 @@
-This package was debianized by Yann Dirson 
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment: This package was debianized by Yann Dirson 
+Source:
+ ftp://ftp.ross.net/clients/ross/funnelweb/
+Upstream-Contact:
+ Ross Williams 
 
-It was downloaded from ftp://ftp.ross.net/clients/ross/funnelweb/
-
-Upstream Author: Ross Williams 
-
-
-Copyright (c) Ross N. Williams 1992,1999. All rights reserved.
-
-Permission is granted to redistribute and use this manual in
-any medium, with or without modification, provided that all
-notices (including, without limitation, the copyright
-notice, this permission notice, any record of modification,
-and all legal notices) are preserved on all copies, that all
-modifications are clearly marked, and that modified versions
-are not represented as the original version unless all the
-modifications since the manual's original release by Ross N.
-Williams (www.ross.net) consist of translations or other
-transformations that alter only the manual's form, not its
-content. THIS MANUAL IS PROVIDED "AS IS" AND WITHOUT ANY
-EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT
-LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND
-FITNESS FOR A PARTICULAR PURPOSE. TO THE EXTENT PERMITTED BY
-LAW THERE IS ABSOLUTELY NO WARRANTY.
+Files: *
+Copyright: (c) Ross N. Williams 1992,1999. All rights reserved.
+License: Permissive-RossWilliams
+ Permission is granted to redistribute and use this manual in
+ any medium, with or without modification, provided that all
+ notices (including, without limitation, the copyright
+ notice, this permission notice, any record of modification,
+ and all legal notices) are preserved on all copies, that all
+ modifications are clearly marked, and that modified versions
+ are not represented as the original version unless all the
+ modifications since the manual's original release by Ross N.
+ Williams (www.ross.net) consist of translations or other
+ transformations that alter only the manual's form, not its
+ content. THIS MANUAL IS PROVIDED "AS IS" AND WITHOUT ANY
+ EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT
+ LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND
+ FITNESS FOR A PARTICULAR PURPOSE. TO THE EXTENT PERMITTED BY
+ LAW THERE IS ABSOLUTELY NO WARRANTY.
diff -Nru funnelweb-doc-3.2d/debian/patches/0fw.patch 
funnelweb-doc-3.2d/debian/patches/0fw.patch
--- funnelweb-doc-3.2d/debian/patches/0fw.patch 1970-01-01 00:00:00.0 
+
+++ funnelweb-doc-3.2d/debian/patches/0fw.patch 2024-04-07 18:05:02.0 
+
@@ -0,0 +1,53 @@
+Description: Use relative links
+---
+--- funnelweb-doc-3.2d.orig/developer/0fw_dev.fw
 funnelweb-doc-3.2d/developer/0fw_dev.fw
+@@ -4337,10 +4337,10 @@ eneo *.pl
+ @! MacOS   : @i ::0fw_inc.fwi
+ @! OpenVMS : @i [-]0fw_inc.fwi
+ 
+-@i ::0fw_inc.fwi
+-@i ::0www_style.fwi
+-@i ::0www_links.fwi
+-@i ::0www_ross.fwi
++@i ../0fw_inc.fwi
++@i ../0www_style.fwi
++@i ../0www_links.fwi
++@i ../0www_ross.fwi
+ 
+ 
@!**
+ 
@!**
+--- funnelweb-doc-3.2d.orig/reference/0fw_ref.fw
 funnelweb-doc-3.2d/reference/0fw_ref.fw
+@@ -5095,10 +5095,10 @@ eneo *.pl
+ @! MacOS   : @i ::0fw_inc.fwi
+ @! OpenVMS : @i [-]0fw_inc.fwi
+ 
+-@i ::0fw_inc.fwi
+-@i ::0www_style.fwi
+-@i ::0www_links.fwi
+-@i ::0www_ross.fwi
++@i ../0fw_inc.fwi
++@i ../0www_style.fwi
++@i ../0www_links.fwi
++@i ../0www_ross.fwi
+ 
+ 
@!**
+ 
@!**
+--- funnelweb-doc-3.2d.orig/tutorial/0fw_tut.fw
 funnelweb-doc-3.2d/tutorial/0fw_tut.fw
+@@ -6436,10 +6436,10 @@ eneo *.pl
+ @! MacOS   : @i ::0fw_inc.fwi
+ @! OpenVMS : @i [-]0fw_inc.fwi
+ 
+-@i ::0fw_inc.fwi
+-@i ::0www_style.fwi
+-@i ::0www_links.fwi
+-@i ::0www_ross.fwi
++@i ../0fw_inc.fwi
++@i ../0www_style.fwi
++@i 

Bug#1068596: less: word line wrap missing

[José Luis González]

Package: less
Version: 590-2
Severity: important

The option to wrap lines by words, not characters, is missing from v 12
less. This must has been in less, at least, at some point. If not feel
free to lower severity to whishlist.

Bug#1068595: libreoffice-writer: insert space missing

[José Luis González]

Package: libreoffice-writer
Version: 4:7.4.7-1+deb12u1
Severity: important

Hi,

Space insertion is missing in the insert menu.

Best regards,
JL

Bug#1043156: floatbg: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.
Please find the debdiff attached.diff -Nru floatbg-1.0/Imakefile floatbg-1.0/Imakefile
--- floatbg-1.0/Imakefile   2024-04-07 17:59:00.0 +
+++ floatbg-1.0/Imakefile   1996-10-27 00:16:23.0 +
@@ -1,4 +1,4 @@
-  LOCAL_LIBRARIES = $(XLIB) -lm
+  LOCAL_LIBRARIES = $(XLIB)
  SRCS = floatbg.c
  OBJS = floatbg.o
 SYSLAST_LIBRARIES = -lm
diff -Nru floatbg-1.0/Makefile floatbg-1.0/Makefile
--- floatbg-1.0/Makefile2024-04-07 17:59:00.0 +
+++ floatbg-1.0/Makefile1996-10-27 00:16:23.0 +
@@ -1,1267 +1,12 @@
-# Makefile generated by imake - do not edit!
 
-# --
-# Makefile generated from "Imake.tmpl" and 
-# $Xorg: Imake.tmpl,v 1.4 2000/08/17 19:41:46 cpqbld Exp $
-# $XdotOrg: xc/config/cf/Imake.tmpl,v 1.9 2005/01/24 06:37:31 daniels Exp $
-#
-#
-#
-#
-# $XFree86: xc/config/cf/Imake.tmpl,v 3.155 2003/12/24 18:58:41 dickey Exp $
-# --
+floatbg: floatbg.o
+   cc -O -o floatbg floatbg.o -lX11 -lm
 
-all::
+floatbg.o: floatbg.c
+   cc -O -c floatbg.c
 
-.SUFFIXES: .i
+clean:
+   rm -f floatbg floatbg.o floatbg.shar core a.out
 
-# $XdotOrg: xc/config/cf/Imake.cf,v 1.7 2005/03/02 11:20:29 gisburn Exp $
-# $Xorg: Imake.cf,v 1.4 2000/08/17 19:41:45 cpqbld Exp $
-
-# $XFree86: xc/config/cf/Imake.cf,v 3.88 2003/12/16 21:30:21 herrb Exp $
-
-# ---
-# site-specific configuration parameters that need to come before
-# the platform-specific parameters - edit site.def to change
-
-# site:  $TOG: site.sample /main/r64_final/1 1998/02/05 16:28:49 kaleb $
-
-# site:  $XFree86: xc/config/cf/site.def,v 3.24 2000/06/25 20:17:29 dawes Exp $
-
-# $XFree86: xc/config/cf/xf86site.def,v 3.186 2003/06/25 18:06:22 eich Exp $
-
-# --
-# platform-specific configuration parameters - edit linux.cf to change
-
-# $XdotOrg: xc/config/cf/linux.cf,v 1.24 2005/03/06 01:05:00 branden Exp $
-# platform:  $Xorg: linux.cf,v 1.3 2000/08/17 19:41:47 cpqbld Exp $
-
-# platform:  $XFree86: xc/config/cf/linux.cf,v 3.220 2003/12/30 22:38:33 tsi 
Exp $
-
-# operating system:  Linux 5.10.0-13-amd64 x86_64 [ELF] (5.10.0)
-# libc:(6.36.0)
-# binutils:(239)
-
-# $Xorg: lnxLib.rules,v 1.3 2000/08/17 19:41:47 cpqbld Exp $
-# $XFree86: xc/config/cf/lnxLib.rules,v 3.52 2003/10/31 20:49:03 herrb Exp $
-
-# $XdotOrg: xc/config/cf/xorg.cf,v 1.44 2005/01/27 03:50:46 ajax Exp $
-
-# $Xorg: xfree86.cf,v 1.4 2000/08/17 19:41:49 cpqbld Exp $
-
-XORG_VERSION_CURRENT = (((7) * 1000) + ((7) * 10) + ((0) * 1000) + 0)
-RELEASE_VERSION = RELEASE-1
-
-AFB_DEFS = -DUSE_AFB
-
-DRIVERSDKDIR = $(USRLIBDIR)/Server
-DRIVERSDKMODULEDIR = $(USRLIBDIR)/Server/modules
-DRIVERSDKINCLUDEDIR = $(USRLIBDIR)/Server/include
-
-   XF86SRC = $(SERVERSRC)/hw/xfree86
-XF86COMSRC = $(XF86SRC)/common
- XF86PARSERSRC = $(XF86SRC)/parser
- XF86OSSRC = $(XF86SRC)/os-support
- XF86DRIVERSRC = $(XF86SRC)/drivers
- DRIVERSRC = $(XF86DRIVERSRC)
-
-XFREE86DOCDIR = $(DOCDIR)
-  XFREE86PSDOCDIR = $(DOCPSDIR)
- XFREE86PDFDOCDIR = $(DOCPDFDIR)
-XFREE86HTMLDOCDIR = $(DOCHTMLDIR)
-XFREE86JAPANESEDOCDIR = $(DOCDIR)/Japanese
-
-# $Xorg: xf86.rules,v 1.3 2000/08/17 19:41:48 cpqbld Exp $
-
-# $XFree86: xc/config/cf/xf86.rules,v 3.34tsi Exp $
-
-   SELINUX_LDFLAGS =
-
-   SELINUX_INCLUDES = -I/usr/include/selinux
-
-   SELINUX_CFLAGS =  -DHAVE_SELINUX
-
-   SELINUX_LIBS = -lselinux
-
-# --
-# site-specific configuration parameters that go after
-# the platform-specific parameters - edit site.def to change
-
-# site:  $TOG: site.sample /main/r64_final/1 1998/02/05 16:28:49 kaleb $
-
-# site:  $XFree86: xc/config/cf/site.def,v 3.24 2000/06/25 20:17:29 dawes Exp $
-
-# -
-# Imake rules for building libraries, programs, scripts, and data files
-# rules:  $Xorg: Imake.rules,v 1.3 2000/08/17 19:41:46 cpqbld Exp $
-# rules:  $XdotOrg: xc/config/cf/Imake.rules,v 1.8 2005/02/01 22:27:00 ajax 
Exp $
-#
-#
-#
-#
-# rules:  $XFree86: xc/config/cf/Imake.rules,v 3.128 2003/11/15 03:25:17 dawes 
Exp $
-
-.PHONY: all interfaces install install.man install.lib install.sdk depend 
includes cleandir
-
- _NULLCMD_ = @ echo -n
-
-X_BYTE_ORDER = X_LITTLE_ENDIAN
-
-GLIDE2INCDIR =
-
-GLIDE3INCDIR = /usr/include/glide3
-
-GLIDE3LIBNAME = glide3
-
-TKLIBNAME = tk8.4
-
-TKLIBDIR = /usr/lib
-
-TCLLIBNAME = tcl8.4
-
-TCLIBDIR = /usr/lib
-
-  PATHSEP = /
-SHELL = /bin/sh -e
-
-  TOP = .
-  CURRENT_DIR = .
-
-IMAKE = imake
-   DEPEND = gccmakedep
-MKDIRHIER = mkdir -p
- 

Bug#1068588: redesign of how autopkgtest talks to the testbed

[Paul Gevers]

Hi,

On 07-04-2024 7:20 p.m., Christian Kastner wrote:

I'm not a maintainer but I use autopkgtest a lot. I hope it's OK if I
contribute input.


Yes, absolutely. Comments from all people that want to contribute 
constructively are welcome. Even more so from users and contributors.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068594: gpg: 100% CPU endless loop after mkdir /etc/gnupg/gpg.conf

[Valentin Hilbig]

Package: gpg
Version: 2.4.5-1
Severity: important
X-Debbugs-Cc: debian-bug-re...@03.softkill.org

Dear Maintainer,

following creates an endless loop:

sudo apt install gpg
sudo mkdir -p /etc/gnupg/gpg.conf
gpg --version

Afterwards gpg becomes unusable system wide.
To create the directory you usually need privileges, however my expectation is,
that some empty directory like shown above should never do this type of harm!

I mark this important, as this loop affects all gpg processes system wide
and hence might be used to create a DoS if somebody somehow manages
to create this file as a directory instead.

Also the path /etc/gnupg/gpg.conf is not documented in man gpg.
Undocumented paths should not be exploitable to create harm.
Hence my expectation is that

- this file should be documented
- there should be a way to ignore this file such that gpg does not access this 
file
- gpg should ignore errors this file if it is unreadable (like being a 
directory)

I do not have any expectation about what happens when this is a file which
includes errors.  This should be part of the documentation.

I tried to report this upstream, but failed, as I was unable to register.

The bug affects stable, unstable and experimental and was tested on a VM.


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

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.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 gpg depends on:
ii  gpgconf  2.4.5-1
ii  libassuan0   2.5.5-5
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-9+deb12u4
ii  libgcrypt20  1.10.3-2
ii  libgpg-error01.46-1
ii  libnpth0t64  1.6-3.1
ii  libreadline8t64  8.2-4
ii  libsqlite3-0 3.40.1-2
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages gpg recommends:
ii  gnupg  2.4.5-1

gpg suggests no packages.

-- no debconf information

Bug#1068593: slib: Please package version 3c1

[Gwen Weinholt]

Package: slib
Version: 3b6-3
Severity: wishlist
X-Debbugs-Cc: debian-sch...@lists.debian.org

I've done some work (in salsa) to update scm to version 5f4 and
noticed that it uses catalog:expand-path, which is apparently new in
slib 3c1. So please package slib 3c1.

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

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

Versions of packages slib depends on:
ii  dpkg1.22.6
ii  install-info7.1-3+b1
ii  sensible-utils  0.0.22

slib recommends no packages.

slib suggests no packages.

-- no debconf information

Bug#1068591: systemd-container: doesn't list a default package for default-dbus-system-bus dependency

[Michael Biebl]

Am 07.04.24 um 18:19 schrieb Raphaël Halimi:

Note 1: one could think that it's debootstrap's fault for not resolving 
dependencies on virtual packages; indeed, it has already been reported 
several times (#878961, merged with #827602 and #931760; as well as 
Launchpad #86536) unfortunately never fixed yet; but, IMHO, since 
systemd-container is usually needed in systemd-nspawn containers, and 
(except for the host) is usually installed via debootstrap, it makes it 
kind of a special case, in the sense that systemd (as a whole) should 
take care that systemd-nspawn containers can be built and started easily.


As you correctly noticed, this is a bug/fault in debootstrap.
I don't think individual packages should work around that, so I'm 
included to close this as wontfix (or reassign/merge to debootstrap).


Fwiw, you might use an alternative debootstrap tool like mmdebstrap 
which works properly in that regard.






OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1043154: falselogin: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru falselogin-0.3/Makefile falselogin-0.3/Makefile
--- falselogin-0.3/Makefile 2024-04-07 17:18:36.0 +
+++ falselogin-0.3/Makefile 2006-08-24 04:23:17.0 +
@@ -6,7 +6,7 @@
 all:   falselogin
 
 install: falselogin
-   $(INS) -D -o root -g root -m 0755 falselogin 
$(DESTDIR)/usr/bin/falselogin
+   $(INS) -D -o root -g root -m 0755 -s falselogin 
$(DESTDIR)/usr/bin/falselogin
$(INS) -D -o root -g root -m 0644 falselogin.conf 
$(DESTDIR)/etc/falselogin.conf
 
 clean:
diff -Nru falselogin-0.3/debian/README.debian 
falselogin-0.3/debian/README.debian
--- falselogin-0.3/debian/README.debian 2024-04-07 17:18:36.0 +
+++ falselogin-0.3/debian/README.debian 2024-04-07 17:07:14.0 +
@@ -1,6 +1,6 @@
 falselogin for Debian
 --
 
-With falselogin you can deny the user to log in the system but gives him/her 
some info.
+With falselogin you can deny the user to log in the system but give him/her 
some info.
 
 Tibor Koleszar , Wed,  8 Sep 1999 18:19:05 +0200
diff -Nru falselogin-0.3/debian/changelog falselogin-0.3/debian/changelog
--- falselogin-0.3/debian/changelog 2024-04-07 17:18:36.0 +
+++ falselogin-0.3/debian/changelog 2024-04-07 17:07:14.0 +
@@ -1,3 +1,16 @@
+falselogin (0.3-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0. (Closes: #1043154)
+  * d/copyright: Convert to machine-readable format.
+  * README: Fix typo.
+
+  [ Helmut Grohne ]
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #928065)
+
+ -- Bastian Germann   Sun, 07 Apr 2024 17:07:14 +
+
 falselogin (0.3-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru falselogin-0.3/debian/copyright falselogin-0.3/debian/copyright
--- falselogin-0.3/debian/copyright 2024-04-07 17:18:36.0 +
+++ falselogin-0.3/debian/copyright 2024-04-07 17:07:14.0 +
@@ -1,23 +1,26 @@
-This package was debianized by Tibor Koleszar  on
-Wed,  8 Sep 1999 18:19:05 +0200.
-
-Tibor Koleszar is also the upstream author.
-
-Copyright (C) 1999-2001  Tibor Koleszar
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
-
-On Debian systems, the complete text of the GNU General Public License
-can be found in `/usr/share/common-licenses/GPL'.
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This package was debianized by Tibor Koleszar  on
+ Wed,  8 Sep 1999 18:19:05 +0200.
+Upstream-Contact:
+ Tibor Koleszar 
+
+Files: *
+Copyright: (C) 1999-2001  Tibor Koleszar
+License: GPL-2+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+ .
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+ .
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+Comment:
+ On Debian systems, the complete text of the GNU General Public License
+ version 2 can be found in `/usr/share/common-licenses/GPL-2'.
diff -Nru falselogin-0.3/debian/patches/debian.patch 
falselogin-0.3/debian/patches/debian.patch
--- falselogin-0.3/debian/patches/debian.patch  1970-01-01 00:00:00.0 
+
+++ falselogin-0.3/debian/patches/debian.patch  2024-04-07 17:07:14.0 
+
@@ -0,0 +1,124 @@
+--- falselogin-0.3.orig/Makefile
 falselogin-0.3/Makefile
+@@ -6,7 +6,7 @@ INS = /usr/bin/install
+ all:  falselogin
+ 
+ install: falselogin
+-  $(INS) -D -o root -g root -m 0755 -s falselogin 
$(DESTDIR)/usr/bin/falselogin
++  $(INS) -D -o root -g root -m 0755 falselogin 
$(DESTDIR)/usr/bin/falselogin
+   $(INS) -D -o root -g root -m 0644 falselogin.conf 
$(DESTDIR)/etc/falselogin.conf
+ 
+ clean:
+--- falselogin-0.3.orig/falselogin.c
 falselogin-0.3/falselogin.c

Bug#1068588: redesign of how autopkgtest talks to the testbed

[Christian Kastner]

Hi Paul,

On 2024-04-07 16:42, Paul Gevers wrote:
> The following issues have come up several times over the years. I
> propose to discuss them in one place (this bug report) to define the
> solution strategy. I haven't gone through all the details myself, so I
> might be thinking in the wrong direction, please correct me if you think
> so. Please also voice agreement, if not on the details, then on the
> general concept.

I'm not a maintainer but I use autopkgtest a lot. I hope it's OK if I
contribute input.

I generally agree with all of what you said, and would add the following:

> * [mostly orthogonal] currently the autopkgtest code has a lot of state
> in a non-Pythonic way. Reasoning about what goes on and debugging
> autopkgtest code flow is non-trivial.

It is indeed very difficult to keep track of what's going on. A lot of
state is kept in/communicated through globals, and it can be challenging
to remember which role the running threads are playing, and in which
relationship.

(smcv put this into historical context once.)

> Solution direction
> ==
> * handle communication between runner/autopkgtest and the virt servers
> and the ssh driver via Python classes instead of the text based
> protocol. Do this in a "plugin" friendly way such that backends can
> still easily be used without changes to src:autopkgtest.

I would add to this that testbed I/O and test I/O could benefit from
separate communications channels.

Example: the Debian ROCm Team requested the --timeout-poweroff option
for the QEMU backend because the hardware we pass in needs a clean
shutdown procedure. But it is not possible to trigger a shutdown when a
test is running, because on the I/O channel is being waited on for
output. So a timeout still ends with a SIGTERM of the testbed.

Best,
Christian

Bug#1068561: ITS: argtable2

[Andreas Tille]

Hi Shachar,

Am Sun, Apr 07, 2024 at 02:39:24PM +0300 schrieb Shachar Shemesh:
> 
> Go ahead. I'm swamped beyond words. You can take formal ownership, if you 
> like.

Thanks a lot and sorry if my further mails might have offended you
due the fingerpointing.  I think I've learned that for future cases.

Kind regards
Andreas.

> Shachar
> 
> 
> On 07/04/2024 12:46, Andreas Tille wrote:
> 
> Source: argtable2
> Version: 13-1.1
> Severity: important
> X-Debbugs-Cc: Shachar Shemesh , Debian Med Packaging 
> Team , 1066...@bugs.debian.org, 
> m...@qa.debian.org
> 
> Hi,
> 
> on behalf of the Debian Med team I intend to salvage[1] this package 
> since the
> following criteria from Wiki[2] are met
> 
>   There is no visible activity regarding the package for six months
>   A previous NMU was not acknowledged, and a bug justifying another NMU 
> is pending for one month
>   The last upload was an NMU and there was no maintainer upload within 
> one year
>   Bugs exist for more than one major missing upstream version (bug 
> #1066377)
> 
> I have prepared the package I intend to upload inside the Debian Med
> team space
> 
>   https://salsa.debian.org/med-team/argtable2
> 
> The rationale to move this package into Debian Med team is that it
> affects a tree of dependencies in this team which maintains clustalo
> that depends from libargtable2-dev.
> 
> Kind regards
>Andreas.
> 
> [1] 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> [2] https://wiki.debian.org/PackageSalvaging
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (50, 
> 'buildd-unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 

-- 
https://fam-tille.de

Bug#1068590: steam-installer: Impossible installation

[Tobias Frost]

Am 7. April 2024 15:39:03 UTC schrieb Serge Kilimoff :
>Package: steam-installer
>Version: 1:1.0.0.79~ds-2
>Severity: grave
>Justification: renders package unusable
>X-Debbugs-Cc: serge.kilim...@gmail.com
>
>Dear Maintainer,
>
>when I try to install the package I get the following error :
>
>The following packages have unmet dependencies:
> libgl1-mesa-dri:i386 : Depends: libllvm17t64:i386 but it is not installable
>E: Unable to correct problems, you have held broken packages.
>
>
>-- System Information:
>Debian Release: trixie/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
>
>Kernel: Linux 6.7.9-amd64 (SMP w/12 CPU threads; PREEMPT)
>Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
>TAINT_UNSIGNED_MODULE
>Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
>Shell: /bin/sh linked to /usr/bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled
>
>Versions of packages steam-installer depends on:
>ii  debconf [debconf-2.0]  1.5.86
>pn  steam-libs 
>pn  steam-libs-i386
>ii  zenity 4.0.1-1+b1
>
>steam-installer recommends no packages.
>
>steam-installer suggests no packages.
>

Control: close -1 

this is due to the active time_t transition and will sort itself out once it 
has been finished. 

unfortunately there is nothing that can be done atm, so closing. 

(you might want to check if you can install it when tracking testing, but no 
guarantees)

Bug#1066010: dvdisaster: diff for NMU version 0.79.10-3.1

[Andreas Metzler]

Control: tags 1066010 + patch
Control: tags 1066010 + pending

Dear maintainer,

I've prepared an NMU for dvdisaster (versioned as 0.79.10-3.1) and
uploaded it to DELAYED/00.

Kind regards
Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru dvdisaster-0.79.10/debian/changelog dvdisaster-0.79.10/debian/changelog
--- dvdisaster-0.79.10/debian/changelog	2024-01-13 16:05:58.0 +0100
+++ dvdisaster-0.79.10/debian/changelog	2024-04-07 18:38:18.0 +0200
@@ -1,3 +1,10 @@
+dvdisaster (0.79.10-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with -Werror=implicit-function-declaration Closes: #1066010
+
+ -- Andreas Metzler   Sun, 07 Apr 2024 18:38:18 +0200
+
 dvdisaster (0.79.10-3) unstable; urgency=medium
 
   * Team upload
diff -Nru dvdisaster-0.79.10/debian/patches/38-ftbfs-implicit-functions.diff dvdisaster-0.79.10/debian/patches/38-ftbfs-implicit-functions.diff
--- dvdisaster-0.79.10/debian/patches/38-ftbfs-implicit-functions.diff	1970-01-01 01:00:00.0 +0100
+++ dvdisaster-0.79.10/debian/patches/38-ftbfs-implicit-functions.diff	2024-04-07 18:37:13.0 +0200
@@ -0,0 +1,33 @@
+Description: Fix FTBFS with -Werror=implicit-function-declaration
+Author: Andreas Metzler 
+Bug-Debian: https://bugs.debian.org/1066010
+Origin: vendor
+Forwarded: no
+Last-Update: 2024-04-07
+
+--- dvdisaster-0.79.10.orig/scripts/bash-based-configure
 dvdisaster-0.79.10/scripts/bash-based-configure
+@@ -1188,6 +1188,7 @@ function REQUIRE_MOTIF()
+ 
+cat >conftest.c <
++#include 
+ int main()
+ {  printf("%d.%d.%d\n",XmVERSION,XmREVISION,XmUPDATE_LEVEL);
+ }
+@@ -1215,6 +1216,7 @@ EOF
+ 
+cat >conftest.c <
++#include 
+ int main()
+ {  printf("%s\n",LesstifVERSION_STRING);
+ }
+@@ -1373,6 +1375,7 @@ EOF
+ 
+cat >conftest.c <
++#include 
+ int main(int argc, char *argv[])
+ { g_malloc(1024); 
+ 
diff -Nru dvdisaster-0.79.10/debian/patches/series dvdisaster-0.79.10/debian/patches/series
--- dvdisaster-0.79.10/debian/patches/series	2024-01-13 16:05:58.0 +0100
+++ dvdisaster-0.79.10/debian/patches/series	2024-04-07 18:35:42.0 +0200
@@ -17,3 +17,4 @@
 36-fix-parallelism.patch
 37-suggest-dvdisaster-doc.patch
 0032-Fix-for-compilation-error-under-gcc-10.patch
+38-ftbfs-implicit-functions.diff


signature.asc
Description: PGP signature

Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment

[Daniel Kahn Gillmor]

On Sat 2024-04-06 16:20:33 +0800, Sean Whitton wrote:
> Thanks!  Just to note that I also had to add python3-gssapi as a b-d.

That sounds reasonable.  thanks for taking care of that, Sean!

 --dkg


signature.asc
Description: PGP signature

Bug#1068540: chromium: depends on pre-t64 library

[Andres Salomon]

On 4/7/24 04:28, Sebastian Ramacher wrote:

Source: chromium
Version: 123.0.6312.105-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

chromium has a hard-coded dependency on libgtk-3-0 which changed the
package name as part of the time_t transition. Please update the
dependency accordingly - or even better - derive the dependency from the
corresponding -dev package installed during the build.



Unfortunately I can't derive the dependency during build, because 
chromium dlopens gtk3 (or 4) at runtime instead of linking against it at 
build.


I'll upload a new version shortly.


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1036799: sylpheed: unable to send or read email after upgrading to Debian 12

[Nicholas Bamber]

I am a long term gmail user and I have tried sylpheed in the past, long  
before Debian 12. I could not get it to work.


From my investigations gmail works with relatively few email clients on 
Linux. It does however work with Thunderbird. From what I understand it 
takes a considerable amount of effort (and money) to get an email client 
to work with gmail. As such it is probably unreasonable to demand any 
specific email client to do that work.



I suggest that the bug be renamed to change "email" to "gmail" and 
remove "after upgrading to Debian 12".

Bug#1068591: systemd-container: doesn't list a default package for default-dbus-system-bus dependency

[Raphaël Halimi]

Package: systemd-container
Version: 249.6-1
Severity: minor

Dear developers,

systemd-container lists "default-dbus-system-bus | dbus-system-bus" as a 
dependency. This is usually correct since APT is smart enough to resolve 
the dependency, but that's not the case with debootstrap.


Since systemd-container is usually needed in systemd-nspawn containers, 
it should be installed at debootstrap time, but currently, running 
debootstrap with "--include=systemd-container" fails because no D-Bus 
implementation is pulled in as dependency. It used to work in versions 
older than 249.6-1 (before the dependency was changed from the real 
"dbus" package to "default-dbus-system-bus | dbus-system-bus" virtual 
packages, so it may qualify as a regression). Using 
"--include=systemd-container,dbus" (or dbus-broker) works.


Could the real dbus package (since it's currently the default D-Bus 
implementation in Debian) be listed as an alternative dependency (and 
ideally, in bookworm too) ?


Note 1: one could think that it's debootstrap's fault for not resolving 
dependencies on virtual packages; indeed, it has already been reported 
several times (#878961, merged with #827602 and #931760; as well as 
Launchpad #86536) unfortunately never fixed yet; but, IMHO, since 
systemd-container is usually needed in systemd-nspawn containers, and 
(except for the host) is usually installed via debootstrap, it makes it 
kind of a special case, in the sense that systemd (as a whole) should 
take care that systemd-nspawn containers can be built and started easily.


Note 2: dbus-broker has the reputation of being better than dbus on 
various points, and could be considered as a clever choice for 
containers, but systemd-container currently lists 
"default-dbus-system-bus" as first alternative, which is provided by "dbus".


Regards,

--
Raphaël Halimi

Bug#1033352: Not pending

[Christian Kastner]

Control: tags -1 - pending

I close the proposed MR implementing this as in light of the recently
published workaround, it is too invasive.

Bug#1055655: rebuild fails with node-typescript 4.9.5 in experimental

[Ananthu C V]

Control: close 1055655

Bug#1055655: rebuild fails with node-typescript 4.9.5 in experimental

[Ananthu C V]

Control: close 1055655 node-js-sdsl/4.1.4-3

Hi Paul, only now after rebuidling the package and
coming to close the bug after noticing the issue is fixed did I notice
your mail. Thanks for the fix.

Best,
Ananthu

Bug#1067067: ruby-rdiscount: FTBFS: rdiscount.c:50:17: error: implicit declaration of function ‘rb_rdiscount__get_flags’ [-Werror=implicit-function-declaration]

[Paul Gevers]

Hi,

On Sun, 17 Mar 2024 23:37:03 +0100 Sebastian Ramacher 
 wrote:

Justification: fails to build from source (but built successfully in the past)


This package is a key package (hence we can't trivially remove it from 
testing) and the failure is blocking the time_t transition. Can this 
please be looked into ASAP?


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068590: steam-installer: Impossible installation

[Serge Kilimoff]

Package: steam-installer
Version: 1:1.0.0.79~ds-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: serge.kilim...@gmail.com

Dear Maintainer,

when I try to install the package I get the following error :

The following packages have unmet dependencies:
 libgl1-mesa-dri:i386 : Depends: libllvm17t64:i386 but it is not installable
E: Unable to correct problems, you have held broken packages.


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

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

Versions of packages steam-installer depends on:
ii  debconf [debconf-2.0]  1.5.86
pn  steam-libs 
pn  steam-libs-i386
ii  zenity 4.0.1-1+b1

steam-installer recommends no packages.

steam-installer suggests no packages.

Bug#1067957: Maude fails to build on armhf

[Nilesh Patra]

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


signature.asc
Description: PGP signature

Bug#1068589: gem2deb: autopkgtest needs update for new version of ruby3.1: "libc6 (>= 2.2.5)", "libruby3.1t64 (>= 3.1.0~preview1)", "ruby | ruby-interpreter\n"] expected to include 'ruby (>= something

[Paul Gevers]

Source: gem2deb
Version: 2.2.2
Severity: serious
X-Debbugs-CC: ruby...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:ruby3.1

Dear maintainer(s),

With a recent upload of ruby3.1 (in the time_t transition) the 
autopkgtest of gem2deb fails in testing when that autopkgtest is run 
with the binary packages of ruby3.1 from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
ruby3.1from testing3.1.2-8.3
gem2debfrom testing2.2.2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

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


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


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

Paul

[1] https://qa.debian.org/excuses.php?package=ruby3.1

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gem2deb/44893387/log.gz

 42s W: Inconsistent version numbers: lib/gem2deb/version.rb says 2.1, 
debian/changelog says 2.2.2

 42s => Unit tests

...

108s test: multibinary source package should inject dependency on 
ruby (>= something). :	F
108s 
===
108s Failure: test: multibinary source package should inject dependency 
on ruby (>= something). (Gem2DebTest):
108s   ["libc6 (>= 2.2.5)", "libruby3.1t64 (>= 3.1.0~preview1)", "ruby | 
ruby-interpreter\n"] expected to include 'ruby (>= something)'.

108sis not true.
108s 
/tmp/autopkgtest-lxc.f1vq6prr/downtmp/build.NZh/src/test/integration/gem2deb_test.rb:83:in 
`block (3 levels) in '
108s 
/tmp/autopkgtest-lxc.f1vq6prr/downtmp/build.NZh/src/test/integration/gem2deb_test.rb:87:in 
`instance_exec'
108s 
/tmp/autopkgtest-lxc.f1vq6prr/downtmp/build.NZh/src/test/integration/gem2deb_test.rb:87:in 
`block in create_test_from_should_hash'
108s 
===


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068436: transmission RFS

[Barak A. Pearlmutter]

Well, it's not a *violation* of the DFSG to include derived files in
the upstream sources, as long as the source needed to regenerate them
is also included. That's often done for bootstrapping compilers.
Source tarballs also often include documentation PDFs and such so
people installing the software can read the documentation without
having to have that part of the build working.

That said, since you've already done the work to get that stuff
generated and debian-build time, I certainly have no objections to
just doing that, and even removing them from the source tarball if you
so desire.

Can't believe I missed the debian/control broken lines. Thanks.

Barring issues, will upload.

Bug#1068588: redesign of how autopkgtest talks to the testbed

[Paul Gevers]

Package: autopkgtest
Severity: wishlist

Hi all,

The following issues have come up several times over the years. I 
propose to discuss them in one place (this bug report) to define the 
solution strategy. I haven't gone through all the details myself, so I 
might be thinking in the wrong direction, please correct me if you think 
so. Please also voice agreement, if not on the details, then on the 
general concept.


Problem statements
==

* runner/autopkgtest talks to the backend with a simple text protocol. 
While this enables users to add another backend without changes to the 
src:autopkgtest code trivially, the drawback of that is loosing all 
nuance of what really is going on on both sides of the communication. 
That is particularly bad when unexpected events happen. All events need 
handling on both sides, including unexpected events.


* every backend has its own virt server that does the real communication 
with the testbed. A result of that is subtle differences in test results 
between different backends when they don't do exactly the same (code 
easily goes out of sync).


* most backends don't automatically provide a testbed as a user would 
see when working on a system. I recall smcv saying words like "user 
session", "dbus something-something" and the like.


* [mostly orthogonal] currently the autopkgtest code has a lot of state 
in a non-Pythonic way. Reasoning about what goes on and debugging 
autopkgtest code flow is non-trivial.


Solution direction
==

* unify the communication with test beds via ssh. This ensures that the 
environment is much more likely to be the same across the different 
backends and also ensures the right session.


* each virt server would only need to ensure an ssh server is setup and 
running in the testbed and leaving the rest of the communication to a 
common driver. (Maybe with the exception of the null, chroot and schroot 
virt servers, to be investigated.) Obviously it's still responsible for 
the tear down of the testbed.


* handle communication between runner/autopkgtest and the virt servers 
and the ssh driver via Python classes instead of the text based 
protocol. Do this in a "plugin" friendly way such that backends can 
still easily be used without changes to src:autopkgtest.


Alternatives


* make the change to use ssh for communication, without a change of the 
virt server protocol.


Open Questions
==

* we could consider supporting the current protocol in parallel, which 
would enable us to migrate one backend at a time and enable our users to 
migrate their own backends at their own pace. However, it means we'd 
need to support two code paths. So the open question is: (how long) do 
we want to maintain the current protocol. I wonder how many other 
backends are out there.


* although I don't know where it hooks in, but sbuild is using 
autopkgtest's backends for some of its functionality. We don't want to 
break sbuild, so the question is how the connection works.


* we already have an ssh virtual server, is that good enough to be the 
ssh driver, or is it missing functionality and/or deserves a rewrite by 
itself? To answer the last question, probably yes if we want to move 
away from the current protocol.


Tasks
=

[ ] discuss this idea and get consensus on the way forward
[ ] create working branch and generate a PoC with one of the backends
[ ] figure out how sbuild hooks into our backends
[ ] while changing code, add Python typing where applicable
[ ] ...

Paul
PS: would it be worth it to enable dashboards for autopkgtest on salsa 
to manage this project? I assume issues on salsa are disabled on purpose 
to avoid bug reports in multiple places. Could we make adding issues 
project members only?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067916: FTBFS: tests failed

[tony mancill]

On Sun, Apr 07, 2024 at 01:49:35PM +0500, Andrey Rakhmatullin wrote:
> On Sat, Apr 06, 2024 at 10:31:52PM +, tony mancill wrote:
> > On Fri, Mar 29, 2024 at 12:13:57AM +0500, Andrey Rakhmatullin wrote:
> > > Source: capnproto
> > > Version: 1.0.1-3
> > > Severity: serious
> > > Tags: ftbfs
> > > 
> > > https://buildd.debian.org/status/fetch.php?pkg=capnproto=armhf=1.0.1-3%2Bb2=1711652087=0
> > 
> > Thank you for the bug report.  I'm not able to reproduce the test
> > failure when cross-building on amd64, so am in the process of triaging
> > on a porter box.
> Does it fail on a porter box?
> As a (useless?) data point I've just tried building it in a qemu chroot
> and some other tests failed, e.g. AsyncIo/AncillaryMessageHandler and
> AsyncIo/ScmRightsTruncatedOdd so it's not useful.

Yes, the failure is consistent on the porter box.  It's still quite
early in my investigation (and I'm not slow at this sort of stuff).

My first hypothesis was that usleep() might behave differently, but
there is no evidence to support that.

Now I'm trying to decide whether the difference in the timespec struct
contributes to the issue:

on armhf:
Size of timespec.tz_sec: 8 byte
Size of timespec.tz_nsec: 4 byte

Everywhere else:
Size of timespec.tz_sec: 8 byte
Size of timespec.tz_nsec: 8 byte

I'm focused on this code:

https://sources.debian.org/src/capnproto/1.0.1-3/src/kj/mutex.c%2B%2B/#L157-L173

But I'm haven't yet found a clear issue, or an explanation as why this
is behaving differently now, since this code has worked on 32-bit
architectures in the past.

I am assuming that if the futux syscall here:

https://sources.debian.org/src/capnproto/1.0.1-3/src/kj/mutex.c%2B%2B/#L250

which also gets passed a timespec, was the culprit, that more things would be
broken on armhf than just a few tests.  But that's an area I need to explore
further.

Thank you,
tony


signature.asc
Description: PGP signature

Bug#1068587: RFA: graide -- IDE for Graphite GDL font description development

[Bastian Germann]

Package: wnpp

Please consider adopting graide. I am no longer interested in maintaining it.
Upstream does not release very often, so this is not too much work.

Bug#1068586: ghc: Broken on arm{el,hf} because of time_t transition

[Ilias Tsitsimpis]

Package: ghc
Version: 9.4.7-3
Severity: grave
Justification: renders package unusable

I recently uploaded a new version of GHC to unstable, in order to fix
#1068179. As a result, GHC got rebuilt taking into account the new size
for time_t on arm{el,hf}. This is evident from the build logs, where
we now see:

  
https://buildd.debian.org/status/fetch.php?pkg=ghc=armel=9.4.7-4=1712410679=0

  checking Haskell type for time_t... Int64

whereas previously we had:

  
https://buildd.debian.org/status/fetch.php?pkg=ghc=armel=9.4.7-3=1708366014=0

  checking Haskell type for time_t... Int32


After this change, a number of Haskell packages have started to FTBFS:

* 
https://buildd.debian.org/status/fetch.php?pkg=haskell-filestore=armel=0.6.5-3%2Bb2=1712457355=0
* 
https://buildd.debian.org/status/fetch.php?pkg=haskell-fold-debounce=armel=0.2.0.11-1%2Bb2=1712466208=0
* 
https://buildd.debian.org/status/fetch.php?pkg=haskell-hourglass=armel=0.2.12-5%2Bb2=1712462130=0

Looking into this, I see that (at least) the getPOSIXTime method is
broken on arm{el,hf}. Compiling the following program on armel:

  $ cat Time.hs
  import Data.Time.Clock.POSIX

  main = do
t <- getPOSIXTime
print t

  $ ghc -o time Time.hs
  $ ./time
  3590884976642664859s

whereas on an amd64 system it returns:

  $ ./time
  1712499127.06215219s

This bug blocks the time_t transition (#1036884).

-- 
Ilias

Bug#1068585: inkscape: crash

[Janusz S . Bień]

Package: inkscape
Version: 1.2.2-2+b1
Severity: normal
X-Debbugs-Cc: none, Janusz S. Bień 

Dear Maintainer,

When trying to compile https://github.com/rmast/revealshapes I get the
crash described here:
https://github.com/rmast/revealshapes/discussions/1#discussioncomment-9034291,
namely

Emergency save document locations:
/home/jsbien/git/revealshapes/desktopfiles/djvu.svg.2024_04_07_09_35_35.0.svg
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at 
https://inkscape.org/report
with a detailed description of the steps leading to the crash, so we can
fix it.

It was followed by
make[2]: *** [Makefile:597: 16x16/mimetypes/image-vnd.djvu.png] Segmentation 
fault


Following the instruction I reported the problem here:

https://gitlab.com/inkscape/inbox/-/issues/10195

Best regards

JSB

-- 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/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages inkscape depends on:
ii  lib2geom1.2.0  1.2.2-3
ii  libatkmm-1.6-1v5   2.28.3-1
ii  libboost-filesystem1.74.0  1.74.0+ds1-21
ii  libc6  2.36-9+deb12u4
ii  libcairo-gobject2  1.16.0-7
ii  libcairo2  1.16.0-7
ii  libcairomm-1.0-1v5 1.14.4-2
ii  libcdr-0.1-1   0.1.6-2+b2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-5
ii  libgc1 1:8.2.2-3
ii  libgcc-s1  12.2.0-14
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1
ii  libglib2.0-0   2.74.6-2
ii  libglibmm-2.4-1v5  2.66.5-2
ii  libgomp1   12.2.0-14
ii  libgsl27   2.7.1+dfsg-5
ii  libgspell-1-2  1.12.0-1+b2
ii  libgtk-3-0 3.24.38-2~deb12u1
ii  libgtkmm-3.0-1v5   3.24.7-1
ii  libharfbuzz0b  6.0.0+dfsg-3
ii  libjpeg62-turbo1:2.1.5-2
ii  liblcms2-2 2.14-2
ii  libmagick++-6.q16-88:6.9.11.60+dfsg-1.6+deb12u1
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpangocairo-1.0-01.50.12+ds-1
ii  libpangoft2-1.0-0  1.50.12+ds-1
ii  libpangomm-1.4-1v5 2.46.3-1
ii  libpng16-161.6.39-2
ii  libpoppler-glib8   22.12.0-2+b1
ii  libpoppler126  22.12.0-2+b1
ii  libpotrace01.16-2
ii  libreadline8   8.2-1.3
ii  librevenge-0.0-0   0.0.5-3
ii  librsvg2-common2.54.7+dfsg-1~deb12u1
ii  libsigc++-2.0-0v5  2.12.0-1
ii  libsoup2.4-1   2.74.3-1
ii  libstdc++6 12.2.0-14
ii  libvisio-0.1-1 0.1.7-1+b3
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxml22.9.14+dfsg-1.3~deb12u1
ii  libxslt1.1 1.1.35-1
ii  python33.11.2-1+b1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages inkscape recommends:
ii  aspell   0.60.8-4+b1
ii  fig2dev  1:3.2.8b-3
ii  imagemagick  8:6.9.11.60+dfsg-1.6+deb12u1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.6+deb12u1
ii  libimage-magick-perl 8:6.9.11.60+dfsg-1.6+deb12u1
ii  libwmf-bin   0.2.12-5.1
ii  python3-cssselect1.2.0-2
ii  python3-lxml 4.9.2-1+b1
ii  python3-numpy1:1.24.2-1
ii  python3-scour0.38.2-2

Versions of packages inkscape suggests:
pn  dia   
pn  inkscape-tutorials
pn  libsvg-perl   
pn  pstoedit  
ii  python3-packaging 23.0-1
pn  python3-uniconvertor  
ii  ruby  1:3.1

-- no debconf information

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#1068584: RM: libgav1 [s390x] -- ROM; no longer builds on big-endian architectures

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: libg...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:libgav1
User: ftp.debian@packages.debian.org
Usertags: remove

The new upstream release of libgav1 no longer supports big-endian
architectures (see #1068583). Builds failed in the same way on the other
big-endian architectures on the ports.

I have uploaded a new version of libavif (1.0.4-2) to disable the
dependency on s390. After it built, libgav1 can be removed from s390x.

Cheers
-- 
Sebastian Ramacher

Bug#1068018: Perhaps resolved

[ael]

This morning the display blanked and flittered shortly after a boot.
This appears to be an ongoing problem with xfce4-power-manager
version  4.18.3-2.

I could not regain control and had to reboot.

The immediate problem did not recur on that reboot, and I investigated
the settings to see if something had changed. There I discovered
that the "Handle display brightness keys" toggle was off. I turned it
on, and the brightness keys then worked again. So that would seem to
have cleared this bug. However it apears that something changed those
settings, perhaps during the upgrade.

There is clearly a bug here somewhere, but perhaps not with the plugins.
So with some hesitation, I will provisionally close this bug.

ael

Bug#1068583: libgav1: FTBFS on s390x: test failures

[Sebastian Ramacher]

Source: libgav1
Version: 0.19.0-2
Severity: important
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=libgav1=s390x=0.19.0-2=1712030294=0

The following tests FAILED:
  8 - film_grain_test (Failed)
 20 - average_blend_test (Failed)
 22 - cdef_test (Failed)
 23 - convolve_test (Failed)
 28 - distance_weighted_blend_test (Failed)
 31 - intrapred_cfl_test (Failed)
 32 - intrapred_directional_test (Failed)
 33 - intrapred_filter_test (Failed)
 34 - intrapred_test (Failed)
 35 - intra_edge_test (Failed)
 38 - loop_filter_test (Failed)
 39 - loop_restoration_test (Failed)
 40 - mask_blend_test (Failed)
 41 - motion_field_projection_test (Failed)
 42 - motion_vector_search_test (Failed)
 43 - obmc_test (Failed)
 45 - post_filter_test (Failed)
 52 - super_res_test (Failed)
 54 - warp_test (Failed)
Errors while running CTest

Cheers
-- 
Sebastian Ramacher

Bug#1068582: python3-mercantile: dpkg fails upgrading from mercantile 1.1.5

[Tomas Janousek]

Package: python3-mercantile
Version: 1.2.1-1
Severity: normal

The new "python3-mercantile" package contains files conflicting with the 
old "mercantile" package but the package metadata doesn't specify this, 
so upgrading from the old package fails:

Unpacking python3-mercantile (1.2.1-1) over (1.1.5-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-fL3mNH/44-python3-mercantile_1.2.1-1_all.deb (--unpack):
 trying to overwrite '/usr/bin/mercantile', which is also in package 
mercantile 1.1.5-1

See 
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces.

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER
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 python3-mercantile depends on:
ii  python33.11.6-1
ii  python3-attr   23.2.0-2
ii  python3-certifi2023.11.17-1
ii  python3-chardet5.2.0+dfsg-1
ii  python3-click  8.1.7-1
ii  python3-coverage   7.2.7+dfsg1-1+b1
ii  python3-docopt 0.6.2-6
ii  python3-hypothesis 6.98.4-1
ii  python3-idna   3.6-2
ii  python3-iniconfig  1.1.1-2
ii  python3-packaging  23.2-1
ii  python3-pluggy 1.4.0-1
ii  python3-py 1.11.0-2
ii  python3-pydocstyle 6.3.0-1.1
ii  python3-pyparsing  3.1.1-1
ii  python3-requests   2.31.0+dfsg-1
ii  python3-snowballstemmer2.2.0-4
ii  python3-sortedcontainers   2.4.0-2
ii  python3-toml   0.10.2-1
ii  python3-typing-extensions  4.10.0-1
ii  python3-urllib31.26.18-2
ii  python3-zipp   1.0.0-6

python3-mercantile recommends no packages.

python3-mercantile suggests no packages.

-- no debconf information

-- 
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/

Bug#1068572: tgt: ceph no longer supports 32 bit architectures

[Chris Hofstaedtler]

Control: tags -1 + patch

Hi,

On Sun, Apr 07, 2024 at 01:28:11PM +0200, Sebastian Ramacher wrote:
> Source: tgt
> Version: 1:1.0.85-1.1
> Severity: serious
> Control: block #1065470 by -1
> X-Debbugs-Cc: sramac...@debian.org
> 
> ceph no longer supports 32 bit architectures. Please stop build
> depending on librbd-dev on 32 bit architectures and please also stop
> building tgt-rbd on 32 bit architectures.

I've pushed a potential patch here: 
https://salsa.debian.org/debian/tgt/-/merge_requests/3/diffs

I also propose to NMU within the next few days. Let me know if this
is not desired.

Chris

Bug#1052561: bookworm-pu: package nfdump/1.7.3-1 (pre-discussion)

[Bernhard Schmidt]

On 08/10/23 10:19 PM, Bernhard Schmidt wrote:

Hi,

> > On Sun, Sep 24, 2023 at 09:36:00PM +0200, Bernhard Schmidt wrote:
> > > [ Other info ]
> > > I did not attach the debdiff because it would be too large and only 
> > > consist
> > > of upstream changes. No changes to debian/ (except dropping a backported 
> > > fix
> > > already in 12.1) are necessary.
> > 
> > What does diffstat look like, possibly with translations and tests
> > excluded? Let's see what sort of scale we're talking here.
> 
> Plain debdiff
> 
>  185 files changed, 25810 insertions(+), 28068 deletions(-)

Gentle ping about this. I'm totally fine if you think this is too risky,
I would go for bookworm-backports then.

[...]

> I'll reach out to upstream about those embedded lz4 copy, right now it does
> not look like one could build against an external library, in contrast to
> zstd and bz2 support.

Upstream has released 1.7.4 which supports building against the system
lz4 copy. I don't want to upload this to unstable until it's clear how
to proceed with this bug. So

1.) Drop this request and keep the old version in bookworm, upload
1.7.3+ to bookworm-backports
2.) Upload 1.7.3 to one of the next bookworm point releases
3.) Upload 1.7.4 to unstable, then target that for one of the next
bookworm point releases (but the diff will become even larger)

What's your take on this?

Thanks,
Bernhard

Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)

[Bernhard Schmidt]

> > > Considering the version in unstable is currently
> > > 
> > > 0.0+git20231103-1
> > > 
> > > should the upload be versioned
> > > 
> > > 0.0+git20231103-0+deb12u1 (like originally proposed) or
> > > 0.0+git20231103-1~deb12u1
> > 
> > As originally proposed please. You're not backporting 0.0+git20231103-1
> > directly as far as I know, because you have intermediate changes which
> > should not be included (correct me if I'm wrong about that).
> 
> There have been no changes in unstable other than the new upstream version,
> so technically it would be a backport of 0.0+git20231103-1. This is a diff
> between 0.0+git20230324-1 and 0.0+git20231103-1.
> 
>  Makefile| 13 ++---
>  compat-include/net/gso.h| 20 
>  debian/changelog| 21 +
>  debian/rules|  2 +-
>  drivers/net/ovpn-dco/ovpn.c |  1 +
>  drivers/net/ovpn-dco/tcp.c  | 14 +++---
>  linux-compat.h  |  4 ++--
>  7 files changed, 66 insertions(+), 9 deletions(-)
> 
> The change in d/rules is a new directory in the new upstream version.
> 
> I would just add a d/gbp.conf for the bookworm branch.
> 
> So 0.0+git20231103-1~deb12u1 ?

Uploaded as this version.

Final diff against the version in bookworm is attached

 Makefile| 13 ++---
 compat-include/net/gso.h| 20 
 debian/changelog| 28 
 debian/gbp.conf |  2 ++
 debian/rules|  2 +-
 drivers/net/ovpn-dco/ovpn.c |  1 +
 drivers/net/ovpn-dco/tcp.c  | 14 +++---
 linux-compat.h  |  4 ++--
 8 files changed, 75 insertions(+), 9 deletions(-)

FTR, the diff between 0.0+git20231103-1 and 0.0+git20231103-1~deb12u1 is

 debian/changelog | 7 +++
 debian/gbp.conf  | 2 ++
 2 files changed, 9 insertions(+)

Bernhard
diffstat for openvpn-dco-dkms-0.0+git20230324 openvpn-dco-dkms-0.0+git20231103

 Makefile|   13 ++---
 compat-include/net/gso.h|   20 
 debian/changelog|   28 
 debian/gbp.conf |2 ++
 debian/rules|2 +-
 drivers/net/ovpn-dco/ovpn.c |1 +
 drivers/net/ovpn-dco/tcp.c  |   14 +++---
 linux-compat.h  |4 ++--
 8 files changed, 75 insertions(+), 9 deletions(-)

diff -Nru openvpn-dco-dkms-0.0+git20230324/compat-include/net/gso.h openvpn-dco-dkms-0.0+git20231103/compat-include/net/gso.h
--- openvpn-dco-dkms-0.0+git20230324/compat-include/net/gso.h	1970-01-01 01:00:00.0 +0100
+++ openvpn-dco-dkms-0.0+git20231103/compat-include/net/gso.h	2023-11-11 22:20:11.0 +0100
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/* OpenVPN data channel accelerator
+ *
+ *  Copyright (C) 2023 OpenVPN, Inc.
+ *
+ *  Author:	Antonio Quartulli 
+ */
+
+#ifndef _NET_OVPN_COMPAT_NET_GSO_H
+#define _NET_OVPN_COMPAT_NET_GSO_H
+
+#include 
+
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 10)
+#include_next 
+#else
+#include 
+#endif
+
+#endif /* _NET_OVPN_COMPAT_NET_GSO_H */
diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/changelog openvpn-dco-dkms-0.0+git20231103/debian/changelog
--- openvpn-dco-dkms-0.0+git20230324/debian/changelog	2023-04-13 09:47:41.0 +0200
+++ openvpn-dco-dkms-0.0+git20231103/debian/changelog	2024-04-07 15:20:37.0 +0200
@@ -1,3 +1,31 @@
+openvpn-dco-dkms (0.0+git20231103-1~deb12u1) bookworm; urgency=medium
+
+  * Upload 0.0+git20231103-1 to Debian Bookworm
+  * Add d/gbp.conf for debian/bookworm branch
+
+ -- Bernhard Schmidt   Sun, 07 Apr 2024 15:20:37 +0200
+
+openvpn-dco-dkms (0.0+git20231103-1) unstable; urgency=medium
+
+  * New upstream version 0.0+git20231103
+- fixes refcount imbalance ("waiting for tunxxx to become free") seen
+  on heavy loaded TCP servers
+
+ -- Bernhard Schmidt   Sat, 11 Nov 2023 22:20:21 +0100
+
+openvpn-dco-dkms (0.0+git20230816-2) unstable; urgency=medium
+
+  * Install compat-include directory (Closes: #1050211)
+
+ -- Bernhard Schmidt   Tue, 22 Aug 2023 18:00:24 +0200
+
+openvpn-dco-dkms (0.0+git20230816-1) unstable; urgency=medium
+
+  * New upstream version 0.0+git20230816
+- fix build error on kernel 6.5+ (Closes: #1043116)
+
+ -- Bernhard Schmidt   Mon, 21 Aug 2023 22:51:04 +0200
+
 openvpn-dco-dkms (0.0+git20230324-1) unstable; urgency=medium
 
   * Release to unstable targetting bookworm.
diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf openvpn-dco-dkms-0.0+git20231103/debian/gbp.conf
--- openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf	1970-01-01 01:00:00.0 +0100
+++ openvpn-dco-dkms-0.0+git20231103/debian/gbp.conf	2024-04-07 15:20:37.0 +0200
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch=debian/bookworm
diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/rules openvpn-dco-dkms-0.0+git20231103/debian/rules
--- openvpn-dco-dkms-0.0+git20230324/debian/rules	2023-04-13 09:47:41.0 +0200