Bug#1060857: squid: updating to 4.6-1+deb10u9 causes empty responses for some HTTP requests

[Lucas Nussbaum]

Hi,

Adding debian-lts@l.d.o in the email loop, as asked on IRC.

On 15/01/24 at 21:16 +0100, Lucas Nussbaum wrote:
> On 15/01/24 at 20:31 +0100, Lucas Nussbaum wrote:
> > Package: squid
> > Version: 4.6-1+deb10u9
> > Severity: important
> > 
> > Hi,
> > 
> > After updating to 4.6-1+deb10u9, squid returns empty responses for some
> > URLs.

I also confirmed that the regression is between 4.6-1+deb10u8 and 4.6-1+deb10u9 
(4.6-1+deb10u8 is OK)

Lucas

Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)

[Shengjing Zhu]

On Tue, Jan 16, 2024 at 4:28 AM Simon Josefsson  wrote:
>
> Shengjing Zhu  writes:
>
> > On Mon, Jan 15, 2024 at 8:51 PM Simon Josefsson  wrote:
> >>
> >> Package: wnpp
> >> Severity: wishlist
> >> Owner: Simon Josefsson 
> >>
> >> * Package name: golang-github-adamkorcz-go-fuzz-headers-1
> >>   Version : 0.0~git20230919.8b5d3ce-1
> >>   Upstream Author : Adam Korcz 
> >> * URL : https://github.com/AdamKorcz/go-fuzz-headers-1
> >> * License : Apache-2.0
> >>   Programming Lang: Go
> >>   Description : helper functions for Go fuzzing (library)
> >>
> >>  Various helper functions for go fuzzing. It is mostly used in combination
> >>  with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with
> >>  fuzzing in the standard library will also be supported. Any coverage 
> >> guided
> >>  fuzzing engine that provides an array or slice of bytes can be used with
> >>  go-fuzz-headers.
> >>  .
> >>  go-fuzz-headers' approach to fuzzing structs is strongly inspired by
> >>  gofuzz (https://github.com/google/gofuzz).
> >>
> >> I hope to maintain this package as part of Debian Go Packaging Team:
> >>
> >> https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/
> >>
> >
> > Usually we don't run fuzz test when building packages, because it
> > would waste a lot of buildd resource.
> >
> > In theory we don't need any fuzz related libraries. But upstream may
> > mix their unit tests and fuzz tests in one source file, which makes it
> > difficult to strip such tests and their libraries.
> > The Go compiler by default wouldn't run fuzz tests.
> >
> > For packaging rekor, I think all these fuzz tests can be stripped by
> > file names. It seems upstream just puts all fuzz tests in
> > "fuzz_test.go".
>
> What is the best method to modify rekor to not need this dependency?
>
> If rekor can work without this package, I'm happy to avoid packaging it,
> although it is already in NEW.
>
> Looking at code, it seems to be used here:
>
> go.sum:github.com/AdamKorcz/go-fuzz-headers-1 
> v0.0.0-20230618160516-e936619f9f18 
> h1:rd389Q26LMy03gG4anandGFC2LW/xvjga5GezeeaxQk=
> go.sum:github.com/AdamKorcz/go-fuzz-headers-1 
> v0.0.0-20230618160516-e936619f9f18/go.mod 
> h1:fgJuSBrJP5qZtKqaMJE0hmhS2tmRH+44IkfZvjtaf1M=
> hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1 
> v0.0.0-2023032938-12e09aba5ebd 
> h1:1tbEqR4NyQLgiod7vLXSswHteGetAVZrMGCqrJxLKRs=
> hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1 
> v0.0.0-2023032938-12e09aba5ebd/go.mod 
> h1:0vOOKsOMKPThRu9lQMAxcQ8D60f8U+wHXl07SyUw0+U=
> hack/tools/tools.go:_ "github.com/AdamKorcz/go-fuzz-headers-1"
> hack/tools/go.mod:  github.com/AdamKorcz/go-fuzz-headers-1 
> v0.0.0-2023032938-12e09aba5ebd
> pkg/types/hashedrekord/v0.0.1/fuzz_test.go: fuzz 
> "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/types/rpm/v0.0.1/fuzz_test.go:  fuzz 
> "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/types/alpine/v0.0.1/fuzz_test.go:   fuzz 
> "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/types/alpine/fuzz_test.go:  fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/types/cose/v0.0.1/fuzz_test.go: fuzz 
> "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/types/jar/v0.0.1/fuzz_test.go:  fuzz 
> "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/types/rekord/v0.0.1/fuzz_test.go:   fuzz 
> "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/types/intoto/v0.0.1/fuzz_test.go:   fuzz 
> "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/types/intoto/v0.0.2/fuzz_test.go:   fuzz 
> "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/types/tuf/v0.0.1/fuzz_test.go:  fuzz 
> "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/types/helm/v0.0.1/fuzz_test.go: fuzz 
> "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/types/dsse/v0.0.1/fuzz_test.go: fuzz 
> "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/types/rfc3161/v0.0.1/fuzz_test.go:  fuzz 
> "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/fuzz/alpine_utils.go:   fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/fuzz/fuzz_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
> pkg/fuzz/jar_utils.go:  fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
> go.mod: github.com/AdamKorcz/go-fuzz-headers-1 
> v0.0.0-20230618160516-e936619f9f18
>
> Would we have to patch all of these files?  Or disable building them
> somehow?
>

Just remove these files, either via Files-Excluded in
debian/copyright, or rm in builddir in debian/rules.

> Let's see if we can develop a workaround before ftp-master approves the
> packages...  otherwise maybe it doesn't hurt to use it anyway, and may
> save us time maintaining patches.
>
> /Simon


-- 
Shengjing Zhu

Bug#1060891: O: pacparser -- library to parse proxy auto-config files (development files)

[Alexandre Detiste]

Package: wnpp
Severity: normal
X-Debbugs-Cc: pacpar...@packages.debian.org
Control: affects -1 + src:pacparser

pacparser is orphaned

https://github.com/manugarg/pacparser/issues/185

Bug#1060890: mpv: dbus related error when running under KDE on Wayland

[Russell Coker]

Package: mpv
Version: 0.37.0-1
Severity: normal

Jan 16 18:01:29 cupcakke plasmashell[1512]: kde.dataengine.mpris: 
"org.mpris.MediaPlayer2.mpv" does not implement org.freedesktop.DBus.Properties 
correctly

I get the above error in the systemd journal as shown by "journalctl -f"
either shortly after starting or on exiting the mpv program.

What I expect is to have it operate correctly without errors being logged.

-- System Information:
Debian Release: trixie/sid
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.11-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages mpv depends on:
ii  libarchive13  3.7.2-1
ii  libasound21.2.10-3
ii  libass9   1:0.17.1-2
ii  libavcodec60  7:6.1.1-1
ii  libavdevice60 7:6.1.1-1
ii  libavfilter9  7:6.1.1-1
ii  libavformat60 7:6.1.1-1
ii  libavutil58   7:6.1.1-1
ii  libbluray21:1.3.4-1
ii  libc6 2.37-13
ii  libcaca0  0.99.beta20-4
ii  libcdio-cdda2 10.2+2.0.1-1
ii  libcdio-paranoia2 10.2+2.0.1-1
ii  libcdio19 2.1.0-4
ii  libdrm2   2.4.117-1
ii  libdvdnav46.1.1-1
ii  libegl1   1.7.0-1
ii  libgbm1   23.3.3-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3
ii  libjpeg62-turbo   1:2.1.5-2+b2
ii  liblcms2-22.14-2
ii  liblua5.2-0   5.2.4-3
ii  libmujs3  1.3.3-3
ii  libpipewire-0.3-0 1.0.1-1
ii  libplacebo338 6.338.1-2
ii  libpulse0 16.1+dfsg1-3
ii  librubberband23.3.0+dfsg-2
ii  libsdl2-2.0-0 2.28.5+dfsg-3
ii  libsixel1 1.10.3-3
ii  libswresample47:6.1.1-1
ii  libswscale7   7:6.1.1-1
ii  libuchardet0  0.0.8-1
ii  libva-drm22.20.0-2
ii  libva-wayland22.20.0-2
ii  libva-x11-2   2.20.0-2
ii  libva22.20.0-2
ii  libvdpau1 1.5-2
ii  libvulkan11.3.268.0-1
ii  libwayland-client01.22.0-2.1
ii  libwayland-cursor01.22.0-2.1
ii  libwayland-egl1   1.22.0-2.1
ii  libx11-6  2:1.8.7-1
ii  libxext6  2:1.3.4-1+b1
ii  libxkbcommon0 1.6.0-1
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.2-2+b1
ii  libxss1   1:1.2.3-1
ii  libxv12:1.0.11-1.1
ii  libzimg2  3.0.5+ds1-1
ii  zlib1g1:1.3.dfsg-3+b1

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

Versions of packages mpv suggests:
pn  libcuda1  

-- debconf-show failed

Bug#1060889: clamav cannot be cross-arch installed?

[Trent W. Buck]

Package: clamav-base
Version: 1.0.3+dfsg-1~deb12u1
Severity: minor

When trying to install clamav for non-default architecture,
I get this error from apt:

The following packages have unmet dependencies:
 clamav-daemon:i386 : Depends: clamav-base:i386 (= 1.0.3+dfsg-1~deb12u1) 
but it is not installable
 clamav-freshclam:i386 : Depends: clamav-base:i386 (>= 
1.0.3+dfsg-1~deb12u1) but it is not installable

This is really weird and confusing, because clamav-base is
an Architecture: all package, not
an Architecture: any package.

I speculate that either:

1. apt has a bug that clamav happens to trigger; or
2. clamav's Depends/Conflicts/Replaces are subtly bugged, and should be 
"fixed"; or
3. I've misunderstood something fundamental about how to use multiple 
architectures in apt.

Here are the full commands I ran.


These all complete without error:

bash5$ mmdebstrap bookworm /dev/null --quiet --architecture=amd64 
--include=clamav,clamav-daemon

bash5$ mmdebstrap bookworm /dev/null --quiet --architecture=i386 
--include=clamav:i386,clamav-daemon:i386

bash5$ mmdebstrap bookworm /dev/null --quiet --architecture=i386,amd64 
--include=clamav:i386,clamav-daemon:i386

bash5$ mmdebstrap bookworm /dev/null --quiet --architecture=amd64,i386 
--include=curl:i386   # some non-clamav cross-arch install


These fail with the weird bug:

bash5$ mmdebstrap bookworm /dev/null --architecture=amd64,i386 
--include=clamav:i386,clamav-daemon:i386
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: finding correct signed-by value...
done
I: automatically chosen format: null
I: using /tmp/mmdebstrap.W2DIp_TEfi as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: installing remaining packages inside the chroot...
done
Reading package lists...
Building dependency tree...
debconf is already the newest version (1.5.82).
libpam-runtime is already the newest version (1.5.2-6+deb12u1).
mawk is already the newest version (1.3.4.20200120-3.1).
libpam-modules is already the newest version (1.5.2-6+deb12u1).
libpam-modules-bin is already the newest version (1.5.2-6+deb12u1).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 clamav-daemon:i386 : Depends: clamav-base:i386 (= 1.0.3+dfsg-1~deb12u1) 
but it is not installable
 clamav-freshclam:i386 : Depends: clamav-base:i386 (>= 
1.0.3+dfsg-1~deb12u1) but it is not installable
E: Unable to correct problems, you have held broken packages.
E: setup failed: E: apt-get -o Dir::Bin::dpkg=env -o 
DPkg::Options::=--unset=TMPDIR -o DPkg::Options::=dpkg -o 
DPkg::Chroot-Directory=/tmp/mmdebstrap.W2DIp_TEfi --yes install 
-oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false clamav:i386 clamav-daemon:i386 
?narrow(?or(?archive(^bookworm$),?codename(^bookworm$)),?architecture(amd64),?and(?or(?priority(required),?priority(important)),?not(?essential)))
 failed
I: main() received signal PIPE: waiting for setup...
I: removing tempdir /tmp/mmdebstrap.W2DIp_TEfi...
E: mmdebstrap failed to run

bash5$ mmdebstrap bookworm /dev/null --architecture=i386,amd64 
--include=clamav:amd64,clamav-daemon:amd64
I: automatically chosen mode: unshare
I: i386 is different from amd64 but can be executed natively
I: finding correct signed-by value...
done
I: automatically chosen format: null
I: using /tmp/mmdebstrap.oM_yCF_dpY as tempdir
I: running apt-get update...
done
I: downloading packages with apt...
done
I: extracting archives...
done
I: installing essential packages...
done
I: installing remaining packages inside the chroot...
done
Reading package lists...
Building dependency tree...
debconf is already the newest version (1.5.82).
libpam-runtime is already the newest version (1.5.2-6+deb12u1).
mawk is already the newest version (1.3.4.20200120-3.1).
libpam-modules is already the newest version (1.5.2-6+deb12u1).
libpam-modules-bin is already the newest version (1.5.2-6+deb12u1).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 clamav-daemon:amd64 : Depends: clamav-base:amd64 (= 1.0.3+dfsg-1~deb12u1)

Bug#1060888: RFP: typst -- A new markup-based typesetting system that is powerful and easy to learn.

[Pierre Marshall]

Package: wnpp
Severity: wishlist

* Package name  : typst
  Version : 0.10.0
  Upstream Contact: Martin Haug 
* URL : https://github.com/typst/typst
* License : Apache 2.0
  Programming Lang: Rust
  Description : A new markup-based typesetting system that is
powerful and easy to learn.

Typst is a new typesetting system based on Rust, designed as a modern
alternative to LaTeX. It's relatively new, only released last year,
but growing in popularity (almost 25k stars on Github), and it's
usable enough that myself and others have adopted it for writing
academic papers. Typst can be used via a web app, but this submission
is for the command line interface: typst-cli.

I am neither a Typst developer nor an existing Debian maintainer, but
I am submitting this for consideration by the Debian Rust packaging
team.

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Helmut Grohne]

On Tue, Jan 16, 2024 at 12:21:46AM +0100, Francesco Poli wrote:
> Why is my first subuid not my user, but a different user?
> Is it by design?

Yes, this is by design. The use of subuids provides isolation. It's not
that you have just one, but you have a whole range of uids - the first
of which happens to be mapped to root. In particular, this mapping must
be constructed in such a way that every uid inside the namespace is
mapped to a different uid outside the namespace. Hence, you really need
a lot of uids to construct such a namespace. Then the use of different
uids serves isolation: Processes that use the namespace have uids inside
your subuid range outside and then regular permission rules prevent such
processes from doing bad things with your user (such as killing your
processes or messing with your files). While we do not technically need
this property here (as e.g. fakeroot/fakechroot does not provide such
isolation either), it still is a safety-net for things that might go
wrong that we'd like to not give up.

> Or can my first subuid be forced to become my user?

In principle, yes. The mapping currently is:

0 - 65535 -> first_subuid - first_subuid+65535

This is the same mapping that you get with unshare --map-auto.

Instead we could also map like this:

0 -> your_uid
1 - 65535 -> first_subuid - first_subuid+65534

This is roughly what you get with unshare --map-root-user --map-auto.
mmdebstrap does not allow you to configure this aspect at this time.

> Well, performance was not an issue here.
> The copy of
> 
>   $ ls -lFs --si sid_amd64.img 
>   690M -rw-r-xrwx 1 $USER $USER 2.3G Jan 15 23:26 sid_amd64.img*
> 
> was really quick.

Probably. Copying huge chunks of data probably just feels wrong and
technically isn't. We could also generate the file in $TMPDIR in general
(hoping it is backed by tmpfs and that the system performing the image
build has at least 4GB ram) and then copy it to the final destination in
general. That's usability beating performance.

> However, even on a mechanical hard disk drive, I would be more than
> willing to spend some more time in the copy operation. After all, if I
> understand correctly, the image will only be created once, and then kept
> up-to-date with "sbuild-qemu-update" (which does not require superuser
> privileges, does it?).

Alternatively, you may periodically recreate your image. The official
Debian buildd network could also be using sbuild-update to update its
chroots, but instead they periodically recreate them.

> Would the use of the .qcow2 format even further help in this?

The qcow2 format is not using sparseness. Hence, copying cannot inflate
its size. Also qcow2 can be inline-compressed which can further reduce
the image size. autopkgtest will produce an overlay image in any case
rather than modify your base image, so you don't grow it over time while
using it.

>   d.  configure sbuild-qemu and learn to use it to build Debian packages

Does this provide significant advantages over sbuild in unshare mode?

>   e.  report to you and/or Christian Kastner (and suggest possible
>   improvements for mmdebstrap-autopkgtest-build-qemu and/or
>   sbuild-qemu)

I suspect mmdebstrap-autopkgtest-build-qemu very much is unfinished. We
got it into a barely-works.

I think making this all more useful eventually requires finding a
solution for crossing uid boundaries in a sane way. At this time, I see
two fairly generic ways to do this:

a) Have a very simple proxy fuse driver in the initial namespace and
   mount it inside the target namespace. That way an individual
   directory from a different user can be exposed to the namespace
   without granting full access. (Good containment, non-trivial setup,
   slight performance degradation.)

b) Map the calling user in the user namespace. We don't have to map the
   user to root. We can map it to some high uid > 65535. Any process
   that has CAP_DAC_OVERRIDE (and that capability is initially available
   and typically available to any process running as uid 0 inside) can
   also access files by your user. (Bad containment, easy setup, no
   performance impact.)

Helmut

Bug#1060887: postgresql-server-dev-16 fails to install as build-dep during cross-build

[Лухнов Андрей Олегович]

Package: postgresql-server-dev-16 
Severity: normal 
X-Debbugs-Cc: loukh...@lotes-tm.ru 

Dear Maintainer, 

I have postgresql-server-dev-16 as a build dependency in my package, minimal 
debian/control file to reproduce the problem is as follows: 

Source: cross-deps-problem 
Build-Depends: debhelper (>= 13.3.4), 
postgresql-server-dev-16 
Section: libs 
Priority: optional 
Standards-Version: 4.3.0 

I'm using official debian:trixie docker image and issuing the following 
commands to prepare build: 

root@e93cc49d3bff:/code/dep-problem-tracking# dpkg --add-architecture armhf 
root@e93cc49d3bff:/code/dep-problem-tracking# apt-get update 
[ mailto:root@e93cc49d3bff:/code/dep-problem-tracking# | 
root@e93cc49d3bff:/code/dep-problem-tracking#  ] apt-get dist-upgrade 
root@e93cc49d3bff:/code/dep-problem-tracking# apt-get build-dep -aarmhf . 
Note, using directory '.' to get the build dependencies 
Reading package lists... Done 
Building dependency tree... Done 
Reading state information... Done 
Some packages could not be installed. This may mean that you have 
requested an impossible situation or if you are using the unstable 
distribution that some required packages have not yet been created 
or been moved out of Incoming. 
The following information may help to resolve the situation: 

The following packages have unmet dependencies: 
clang-16:armhf : Depends: binutils:armhf but it is not installable 
E: Unable to correct problems, you have held broken packages. 

Full apt diagnostics follows: 

root@e93cc49d3bff:/code/dep-problem-tracking# apt-get -o 
APT::Get::Build-Dep-Automatic=yes -o Debug::pkgProblemResolver=yes build-dep 
--host-architecture=armhf -y . 
Note, using directory '.' to get the build dependencies 
Reading package lists... Done 
Building dependency tree... Done 
Reading state information... Done 
Starting pkgProblemResolver with broken count: 1 
Starting 2 pkgProblemResolver with broken count: 1 
Investigating (0) clang-16:armhf < none -> 1:16.0.6-19 @un puN Ib > 
Broken clang-16:armhf Depends on binutils:armhf < none @un pH > 
Considering binutils:armhf 0 as a solution to clang-16:armhf 0 
Done 
Some packages could not be installed. This may mean that you have 
requested an impossible situation or if you are using the unstable 
distribution that some required packages have not yet been created 
or been moved out of Incoming. 
The following information may help to resolve the situation: 

The following packages have unmet dependencies: 
clang-16:armhf : Depends: binutils:armhf but it is not installable 
E: Unable to correct problems, you have held broken packages. 
root@e93cc49d3bff:/code/dep-problem-tracking# 

Despite that, if I issue `apt-get install postgresql-server-dev-16:armhf` 
command everythins resolves and installs just fine, but `apt-get build-dep 
-aarmhf .` still fails with the following (same) diagnostics: 

root@e93cc49d3bff:/code/dep-problem-tracking# apt-get -o 
APT::Get::Build-Dep-Automatic=yes -o Debug::pkgProblemResolver=yes build-dep 
--host-architecture=armhf -y . 
Note, using directory '.' to get the build dependencies 
Reading package lists... Done 
Building dependency tree... Done 
Reading state information... Done 
Starting pkgProblemResolver with broken count: 1 
Starting 2 pkgProblemResolver with broken count: 1 
Investigating (0) clang-16:armhf < 1:16.0.6-19 @ii pK Ib > 
Broken clang-16:armhf Depends on binutils:armhf < 2.41.50.20231227-1 @ii pR > 
Considering binutils:armhf 0 as a solution to clang-16:armhf 2 
Added binutils:armhf to the remove list 
Investigating (1) clang-16:armhf < 1:16.0.6-19 @ii pK Ib > 
Broken clang-16:armhf Depends on binutils:armhf < 2.41.50.20231227-1 @ii pR > 
Considering binutils:armhf 2 as a solution to clang-16:armhf 2 
Done 
Some packages could not be installed. This may mean that you have 
requested an impossible situation or if you are using the unstable 
distribution that some required packages have not yet been created 
or been moved out of Incoming. 
The following information may help to resolve the situation: 

The following packages have unmet dependencies: 
clang-16:armhf : Depends: binutils:armhf but it is not installable 
E: Unable to correct problems, you have held broken packages. 

root@e93cc49d3bff:/code/dep-problem-tracking# apt-cache policy 
postgresql-server-dev-16:armhf 
postgresql-server-dev-16:armhf: 
Installed: 16.1-1 
Candidate: 16.1-1 
Version table: 
*** 16.1-1 500 
500 http://deb.debian.org/debian trixie/main armhf Packages 
100 /var/lib/dpkg/status 
root@e93cc49d3bff:/code/dep-problem-tracking# 

It is worth to mention, this issue also exists in earlier releases. I'm having 
similar issue with postgresql-server-dev-15 in bookworm, but it is failing with 
another dependencies: 

root@f4a15821be16:/code/dep-problem-tracking# cat /etc/debian_version 
12.4 
root@f4a15821be16:/code/dep-problem-tracking# apt-get build-dep -aarmhf . 
Note, using directory '.' to get the build dependencies 
Reading package lists..

Bug#1060886: swupdate: Additional dependency support may need to be added

[zhangdandan]

Source: swupdate
Version: 2023.12+dfsg-1
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The swupdate source package (pull from sid) was compiled successfully on 
my local loong64 rootfs environment.
But refer to other architectures, maybe we need to add additional 
dependency support in d/control and d/rules.
I would like to remind you there is no package for loong64 yet about the 
additional dependency.


I reported this phenomenon (whether additional dependency support is 
needed?) in advance and hope to get suggestions from the maintainers.

Please consider the patch (my local patch) I have attached.
If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

diff --git a/debian/control b/debian/control
index acbecd4..62c39ff 100644
--- a/debian/control
+++ b/debian/control
@@ -36,7 +36,7 @@ Build-Depends: debhelper-compat (= 13),
libwebsockets-dev (>= 3.2.0) ,
liburiparser-dev,
libubootenv-dev (>= 0.3.5) [linux-any],
-   libebgenv-dev [any-amd64 any-i386 any-arm64 armhf any-riscv64 any-ia64],
+   libebgenv-dev [any-amd64 any-i386 any-arm64 armhf any-loong64 any-riscv64 any-ia64],
libcmocka-dev,
node-jquery,
pkg-config,
diff --git a/debian/rules b/debian/rules
index 3b1cc0f..8444b49 100755
--- a/debian/rules
+++ b/debian/rules
@@ -41,7 +41,7 @@ endif
 ifeq (,$(filter pkg.swupdate.bpo,$(DEB_BUILD_PROFILES)))
 	echo CONFIG_DELTA=y >> configs/debian_defconfig
 endif
-ifneq (,$(findstring $(DEB_HOST_ARCH),amd64 i386 arm64 armhf riscv64 ia64))
+ifneq (,$(findstring $(DEB_HOST_ARCH),amd64 i386 arm64 armhf loong64 riscv64 ia64))
 	echo CONFIG_BOOTLOADER_EBG=y>> configs/debian_defconfig
 endif
 ifeq (,$(filter pkg.swupdate.nohwcompat,$(DEB_BUILD_PROFILES)))
-- 
2.43.0

Bug#1060885: gambc: Please add loongarch support

[yalingfang]

Source:  gambc
Version: 4.9.3-1.2
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear Maintainer,
     Error happenes when compiling gambc in Loongarch env.
The buildd link is following:
https://buildd.debian.org/status/fetch.php?pkg=gambc&arch=loong64&ver=4.9.3-1.2&stamp=1704952464&raw=0

I have  compiled and all cases passed by adding loongarch support  in my 
local env.

Attach the control patch.

Please add support for it. Thanks!
Any question, contact me!


add_loongarch_support.patch
Description: Binary data

Bug#1060884: efibootguard: add support for loongarch64

[zhangdandan]

Source: efibootguard
Version: 0.15-1
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Maybe we need to add loongarch64 support in configure.ac.
Please consider the patch I have attached.

I would like to remind you that the compilation dependency of 
efibootguard is not yet satisfied. Depends on the gnu-efi package when 
compiling efibootguard.
We hope that the gnu-efi source package can support the loongarch 
architecture (LoongArch patch has been merged in upstream).
We have submitted the Bug request to Debian BTS, please see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025787.


If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

diff --git a/configure.ac b/configure.ac
index 90d70b0..cd02a11 100644
--- a/configure.ac
+++ b/configure.ac
@@ -88,6 +88,7 @@ SET_ARCH(IA64, ia64*)
 SET_ARCH(AARCH64, aarch64*)
 SET_ARCH(ARM, arm*)
 SET_ARCH(RISCV64, riscv64*)
+SET_ARCH(LOONGARCH64, loongarch64*)
 
 ARCH=$(echo $host | sed "s/\(-\).*$//")
 
@@ -107,6 +108,9 @@ AM_COND_IF(ARCH_ARM, [
 AM_COND_IF(ARCH_RISCV64, [
   MACHINE_TYPE_NAME=riscv64])
 
+AM_COND_IF(ARCH_LOONGARCH64, [
+  MACHINE_TYPE_NAME=loongarch64])
+
 AC_SUBST([ARCH])
 AC_SUBST([MACHINE_TYPE_NAME])
 AM_CONDITIONAL([ARCH_IS_X86], [test "$ARCH" = "ia32" -o "$ARCH" = "x86_64"])

Bug#1060883: golang-github-containers-toolbox: please add support for loong64

[wuruilong]

Source: golang-github-containers-toolbox
Version: 0.0.99.3+git20230118+446d7bfdef6a-2
Severity: normal
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

Please refer to the attached patch to support the loong64 arch.

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.
 .
 golang-github-containers-toolbox (0.0.99.3+git20230118+446d7bfdef6a-2) 
unstable; urgency=medium
 .
   * Add community images for Debian and Ubuntu.
   * Clarify the community image status in README.Debian.
Author: Andrej Shadura 

---
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-01-16

--- 
golang-github-containers-toolbox-0.0.99.3+git20230118+446d7bfdef6a.orig/src/meson.build
+++ 
golang-github-containers-toolbox-0.0.99.3+git20230118+446d7bfdef6a/src/meson.build
@@ -43,6 +43,8 @@ elif cpu_family == 'x86_64' and endian =
   dynamic_linker = '/lib64/ld-linux-x86-64.so.2'
 elif cpu_family == 'riscv64' and endian == 'little'
   dynamic_linker = '/lib/ld-linux-riscv64-lp64d.so.1'
+elif cpu_family == 'loongarch64' and endian == 'little'
+  dynamic_linker = '/lib/ld-linux-loongarch-lp64d.so.1'
 else
   host_machine_description = cpu_family + ' (' + endian + ' endian)'
   error('Please specify dynamic linker for:', host_machine_description)

Bug#1060882: lintian: Document path for Lintian User’s Manual in lintian(1)

[Tianyu Chen]

Package: lintian
Version: 2.112.0
Severity: wishlist
X-Debbugs-Cc: sweetyf...@deepin.org

Hi,

When looking for documentation for `lintian-overrides', lintian(1) says
`See the Lintian User’s Manual for the syntax of overrides'. However the
User’s Manual is located in /usr/share/doc/lintian/lintian.txt.gz which
is hard to find. The only way to find that path is via `dpkg -L lintian`.

Please consider document the path in lintian(1).

Thanks!
Tianyu Chen @ deepin

Bug#1057484: pelican: "ModuleNotFoundError: No module named 'watchfiles"

[Louis-Philippe Véronneau]

It seems this library isn't currently packaged in Debian?


I've just ITPed the package and will be uploading it to NEW ASAP.

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060881: resfinder: please stop build-depending on python3-pdm and use python3-pdm-backend instead

[Louis-Philippe Véronneau]

Package: src:resfinder
Severity: important

Dear maintainers,

This package build-depends on python3-pdm, a management tool. It should 
instead build-depend on python3-pdm-backend, the package that provides 
the PEP517-style build backend for PDM.


The python3-pdm package itself it not really maintained and will 
probably be removed from the archive soon. Fixing this issue quickly 
would thus be helpful.


Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058127: python-mpiplus: FTBFS: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?

[Yogeswaran Umasankar]

Hi Andrius,
I have removed the hard-coded version number from setup.py. I found that
the issue was due to changes in PEP440 version naming convention in
versioneer. For this package no need python3-versioneer, upstream has
its own versioneer.py. The work around is, once have everything in
master branch create a tag with just the version number (0.0.2-1)
instead of debian/version number (debian/0.0.2-1).

I have forked python-mpiplus [0] for you to check the changes and to see
how it works before you decide to incorporate the changes. Feel free to
MR the fork and make any further changes needed.

[0] https://salsa.debian.org/yogu/python-mpiplus

Best,
Yogeswaran.


signature.asc
Description: PGP signature

Bug#1043332: gcr-ssh-agent crash has been fixed upstream

[Рустам Заитов]

Dear maintainer of gcr package,

I also have been caught by this crash of gcr-ssh-agent. I strongly believe
that this issue is attributed to gnome's gcr-ssh-agent. This issue has
already been fixed upstream. In the following I am going to provide
arguments to support my conclusion.

I can reproduce this issue when I try to test ssh connection:
```
# test rig
$ export SSH_AUTH_SOCK=/run/user/1000/gcr/ssh
$ ssh -T g...@github.com

# crash confirmation
$ journalctl --no-pager -f
Jan 15 08:42:07 pc-debian systemd[629]: gcr-ssh-agent.service: Main process
exited, code=killed, status=11/SEGV
Jan 15 08:42:07 pc-debian systemd[629]: gcr-ssh-agent.service: Failed with
result 'signal'.
Jan 15 08:42:08 pc-debian systemd[629]: gcr-ssh-agent.service: Scheduled
restart job, restart counter is at 1.
Jan 15 08:42:08 pc-debian systemd[629]: Stopped gcr-ssh-agent.service - GCR
ssh-agent wrapper.
Jan 15 08:42:08 pc-debian systemd[629]: Started gcr-ssh-agent.service - GCR
ssh-agent wrapper.
```

I decided to attach a dbg to the running service in order to find the cause
of the problem.
```
$ export DEBUGINFOD_URLS="https://debuginfod.debian.net";
$ gdb  /usr/libexec/gcr-ssh-agent -p 
GNU gdb (Debian 13.1-3) 13.1
...
This GDB supports auto-downloading debuginfo from the following URLs:
  
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
...
(gdb) set pagination 0
(gdb) run /run/user/1000/gcr/
Starting program: /usr/libexec/gcr-ssh-agent /run/user/1000/gcr/
Downloading separate debug info for system-supplied DSO at 0x77fc9000
...
[New Thread 0x771f66c0 (LWP 2330)]
[New Thread 0x769f56c0 (LWP 2366)]
[Detaching after fork from child process 2367]

Thread 3 "pool" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x769f56c0 (LWP 2366)]
0x77e5ffc0 in ascii_table_data () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0  0x77e5ffc0 in ascii_table_data () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0xb25a in handle_request
(error=0x769f4718, cancellable=0x55574620 [GCancellable],
resp=0x769f4750, req=0x769f4720, connection=0x7fffe8006450
[GUnixConnection], self=0x55566b60 [GcrSshAgentService])
at ../gcr/gcr-ssh-agent-service.c:197
#2  on_run (service=, connection=connection@entry=0x555814f0
[GUnixConnection], source_object=source_object@entry=0x0,
user_data=user_data@entry=0x55566b60)
at ../gcr/gcr-ssh-agent-service.c:326
#3  0x77bea19e in _g_cclosure_marshal_BOOLEAN__OBJECT_OBJECTv
(closure=0x55580660, return_value=0x769f4940,
instance=, args=, marshal_data=, n_params=, param_types=0x5557c4c0)
at ../../../gio/gmarshal-internal.c:335
#4  0x77d5d5a9 in _g_closure_invoke_va
(closure=closure@entry=0x55580660,
return_value=return_value@entry=0x769f4940,
instance=instance@entry=0x555775d0, args=args@entry=0x769f4a10,
n_params=2, param_types=0x5557c4c0)
at ../../../gobject/gclosure.c:895
#5  0x77d7605e in g_signal_emit_valist (instance=0x555775d0,
signal_id=8, detail=, var_args=var_args@entry=0x769f4a10)
at ../../../gobject/gsignal.c:3456
#6  0x77d76dbf in g_signal_emit (instance=,
signal_id=, detail=detail@entry=0) at
../../../gobject/gsignal.c:3606
#7  0x77c1c71d in g_threaded_socket_service_func
(job_data=0x55576400, user_data=) at
../../../gio/gthreadedsocketservice.c:98
#8  0x77e256ca in g_thread_pool_thread_proxy (data=)
at ../../../glib/gthreadpool.c:352
#9  0x77e24cfd in g_thread_proxy (data=0x555671e0) at
../../../glib/gthread.c:831
#10 0x778dd044 in start_thread (arg=) at
./nptl/pthread_create.c:442
#11 0x7795d61c in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) Quit
(gdb)
```

This have lead me to the source code of gcr-ssh-agent-service.c at line 197
https://gitlab.gnome.org/GNOME/gcr/-/blob/gcr-3-41/gcr/gcr-ssh-agent-service.c?ref_type=heads#L191

According to backtrace the crash appears at line 197, but there is an `if`
branch above with wrong comparison `op <= GCR_SSH_OP_MAX` should be `op <
GCR_SSH_OP_MAX`. I was ready to report a bug report to gcr project when I
suddenly found that this issue has been fixed already:
https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/47/diffs

I built the gcr-ssh-agent from the 4.2.0 branch and I can confirm that the
issue is resolved with the new binary.

I guess it might be possible to apply this patch to the gcr debian package
also in order to publish a new version of the package.

---
Rustam

Bug#1060880: ITP: altdns -- Subdomain discovery through alterations and permutations

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: altdns
  Version : 1.0.2
  Upstream Contact: Shubham Shah 
* URL : https://github.com/infosec-au/altdns
* License : GPL-2.0
  Programming Lang: Python
  Description : Subdomain discovery through alterations and permutations

 This package contains a DNS recon tool that allows for the discovery of
 subdomains that conform to patterns. Altdns takes in words that could be
 present in subdomains under a domain (such as test, dev, staging) as well as
 takes in a list of subdomains that you know of.
 .
 From these two lists that are provided as input to altdns, the tool then
 generates a massive output of "altered" or "mutated" potential subdomains that
 could be present. It saves this output so that it can then be used by your
 favourite DNS bruteforcing tool.

Bug#1060879: python3-pyutil: syntax warning on installation

[Alexandre Detiste]

Package: python3-pyutil
Version: 3.3.2-2
Severity: normal



Get:1 http://ftp.be.debian.org/debian testing/main amd64 python3-pyutil all 
3.3.2-2 [105 kB]
Fetched 105 kB in 5s (20,5 kB/s)   
Sélection du paquet python3-pyutil précédemment désélectionné.
(Lecture de la base de données... 435174 fichiers et répertoires déjà 
installés.)
Préparation du dépaquetage de .../python3-pyutil_3.3.2-2_all.deb ...
Dépaquetage de python3-pyutil (3.3.2-2) ...
Paramétrage de python3-pyutil (3.3.2-2) ...
/usr/lib/python3/dist-packages/pyutil/test/deprecated/test_dictutil.py:82: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  _assert(any(x for x in d.values() if x is 8))
/usr/lib/python3/dist-packages/pyutil/test/deprecated/test_dictutil.py:84: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  _assert(not any(x for x in d.values() if x is 7)) # The real 7 should have 
been ejected by the d[3] = 8.
/usr/lib/python3/dist-packages/pyutil/test/deprecated/test_dictutil.py:86: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  _assert(any(x for x in d if x is 3))
/usr/lib/python3/dist-packages/pyutil/test/deprecated/test_dictutil.py:95: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  _assert(any(x for x in d.values() if x is 8))
/usr/lib/python3/dist-packages/pyutil/test/deprecated/test_dictutil.py:97: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  _assert(not any(x for x in d.values() if x is 7)) # The real 7 should have 
been ejected by the d[3] = 8.
/usr/lib/python3/dist-packages/pyutil/test/deprecated/test_dictutil.py:99: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  _assert(any(x for x in d if x is 3))



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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-pyutil depends on:
ii  python3  3.11.4-5+b1

python3-pyutil recommends no packages.

python3-pyutil suggests no packages.

-- no debconf information

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli]

On Sun, 14 Jan 2024 20:27:58 +0100 Helmut Grohne wrote:

> On Sun, Jan 14, 2024 at 06:36:29PM +0100, Francesco Poli wrote:
> > Of course, I have!   ;-)
> > 
> > For privacy reasons: I don't want other users to be able to enter my
> > home directory and to read any file within it that I might have
> > forgotten with world-readable permissions!
> 
> I agree that this is good practice. It's just that working with
> namespaces tends to make this annoying. We're still in search for a more
> satisfying solution. For now, I'm happy to have identified the cause of
> your failure.

Indeed!
Without understanding the cause of the failure, nobody can find a
(good) fix. Hence, identifying the cause is the first step.

> 
> > the final touches to sid_amd64.img will be put with the file in its
> > intended destination directory, which is /home/${USER}/mysubdir, since
> > the command-line argument was "sid_amd64.img", a relative path to a
> > file directly within the current working directory (~/mysubdir).
> 
> That command that fails is mkfs.ext4. This command is run inside the
> user namespace that mmdebstrap creates for constructing the chroot. The
> uids 0 to 65535 inside the user namespace correspond to your first
> subuid range that is large enough. The mkfs.ext4 operation is performed
> by the root user inside the user namespace. In the initial namespace
> that root user is your first subuid. In particular, it is not your user
> but a different user and this user has no permission to access your
> output image.

Why is my first subuid not my user, but a different user?
Is it by design?
Or can my first subuid be forced to become my user?

[...]
> Let me suggest
> some alternatives. One is storing the output image outside $HOME. If you
> put it into /tmp and the move it from /tmp into your home, that should
> work as well.

I attempted to do this by running mmdebstrap-autopkgtest-build-qemu
from within /dev/shm (and it works, more on this below...).

[...]
> The available options to improve this are not super nice. A simple
> workaround is creating the output image as a temporary file inside the
> namespace and then copying it out. This will perform a 1GB copy
> operation that we'd like to avoid (and rather construct the filesystem
> in-place) for performance reasons, but maybe usability beats
> performance?

Well, performance was not an issue here.
The copy of

  $ ls -lFs --si sid_amd64.img 
  690M -rw-r-xrwx 1 $USER $USER 2.3G Jan 15 23:26 sid_amd64.img*

was really quick.

Maybe it's because my home directory is on an SSD...

However, even on a mechanical hard disk drive, I would be more than
willing to spend some more time in the copy operation. After all, if I
understand correctly, the image will only be created once, and then kept
up-to-date with "sbuild-qemu-update" (which does not require superuser
privileges, does it?).

> I'm also not sure how mmdebstrap downloads sparse files. It
> might make them un-sparse and that'd be quite bad for this use case as
> you'd write 25GB of zeros.

I still have to test with a --size=25G (which is the default size):
a file with actual allocated size of 25 GiB would not fit within
my /dev/shm, but the above-mentioned test with --size=2G produced an
image with an allocated size of about 690 MB, so maybe it can work even
with --size=25G ?!?

Would the use of the .qcow2 format even further help in this?

[...]
> > It looks like it worked, but, unfortunately, it (again) fails to be
> > usable with autopkgtest:
> > 
> >   $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out  --summary 
> > ./${SRCPKG}_autopkgtest.summary --apt-upgrade -B ./${SRCPKG}_amd64.changes 
> > -- qemu --overlay-dir /dev/shm ~/Downloads/sid_amd64.img
> >   autopkgtest [18:24:23]: starting date and time: 2024-01-14 18:24:23+0100
> >   autopkgtest [18:24:23]: version 5.32
> >   autopkgtest [18:24:23]: host ${HOST}; command line: /usr/bin/autopkgtest 
> > --output-dir './${SRCPKG}_autopkgtest.out' --summary 
> > './${SRCPKG}_autopkgtest.summary' --apt-upgrade -B 
> > './${SRCPKG}_amd64.changes' -- qemu --overlay-dir /dev/shm 
> > ${HOME}/Downloads/sid_amd64.img
> >   qemu-system-x86_64: terminating on signal 15 from pid 115770 
> > (/usr/bin/python3)
> >   : failure: timed out waiting for 'login prompt on serial 
> > console'
> >   autopkgtest [18:25:24]: ERROR: testbed failure: unexpected eof from the 
> > testbed
> > 
> > 
> > What did I fail to understand?
> 
> The difficulty resides in making a bootable image with no root
> privileges. mmdebstrap-autopkgtest-build-qemu is not fully compatible
> with autopkgtest-build-qemu. It specifically required you to pass
> --boot=efi, right? On amd64, autopkgtest-virt-qemu defaults to bios
> boot. In order to use this image, you likewise have to pass --boot=efi
> to the virtualization backend.

Adding the --boot=efi option made it work!   :-)

  $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out  --summary 
./${SRCPKG}_autopkgtest.summary --apt-upgrade -B ./${S

Bug#1057775: [INTL:sv] Swedish strings for pam debconf

[Sam Hartman]

> "Anders" == Anders Jonsson  writes:

Anders> Hi Martin, one change in this one (fixed spelling of
Anders> "användare").

I don't think you attached a .po file.

Bug#1060878: zint: Please install library files under multiarch location

[Boyuan Yang]

Source: zint
Version: 2.13.0-1
Severity: normal
X-Debbugs-CC: only...@debian.org su...@debian.org

Hi,

Currently libzint is one of the very few packages that still install their
library files under non-multiarch /usr/lib/ location instead of
/usr/lib// . Please consider working with upstream to make
the installation to multiarch location possible. Given that upstream is
using CMake as buildsystem, such migration should not be difficult with
the help of CMake GNUInstallDirs module.

Thanks,
Boyuan Yang


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

Bug#1060877: dateparser: 5 timezone related test failures while building

[Alexandre Detiste]

Source: dateparser
Severity: normal

Salsa CI will likely fail too:

https://salsa.debian.org/python-team/packages/dateparser/-/pipelines/626417



Local build:

=== FAILURES ===
_ TestLocalTZOffset.test_timezone_offset_calculation_0 _

a = (,)

@wraps(func)
def standalone_func(*a):
>   return func(*(a + p.args), **p.kwargs)

/usr/lib/python3/dist-packages/parameterized/parameterized.py:637: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/tmp/dateparser/.pybuild/cpython3_3.11_dateparser/build/tests/test_timezone_parser.py:143:
 in test_timezone_offset_calculation
self.then_offset_is(offset)
/tmp/dateparser/.pybuild/cpython3_3.11_dateparser/build/tests/test_timezone_parser.py:154:
 in then_offset_is
self.assertEqual(delta, self.timezone_offset)
E   AssertionError: datetime.timedelta(seconds=14400) != 
datetime.timedelta(seconds=21600)
_ TestLocalTZOffset.test_timezone_offset_calculation_1 _

a = (,)

@wraps(func)
def standalone_func(*a):
>   return func(*(a + p.args), **p.kwargs)

/usr/lib/python3/dist-packages/parameterized/parameterized.py:637: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/tmp/dateparser/.pybuild/cpython3_3.11_dateparser/build/tests/test_timezone_parser.py:143:
 in test_timezone_offset_calculation
self.then_offset_is(offset)
/tmp/dateparser/.pybuild/cpython3_3.11_dateparser/build/tests/test_timezone_parser.py:154:
 in then_offset_is
self.assertEqual(delta, self.timezone_offset)
E   AssertionError: datetime.timedelta(days=-1, seconds=82800) != 
datetime.timedelta(0)
_ TestLocalTZOffset.test_timezone_offset_calculation_2 _

a = (,)

@wraps(func)
def standalone_func(*a):
>   return func(*(a + p.args), **p.kwargs)

/usr/lib/python3/dist-packages/parameterized/parameterized.py:637: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/tmp/dateparser/.pybuild/cpython3_3.11_dateparser/build/tests/test_timezone_parser.py:143:
 in test_timezone_offset_calculation
self.then_offset_is(offset)
/tmp/dateparser/.pybuild/cpython3_3.11_dateparser/build/tests/test_timezone_parser.py:154:
 in then_offset_is
self.assertEqual(delta, self.timezone_offset)
E   AssertionError: datetime.timedelta(seconds=1800) != 
datetime.timedelta(seconds=5400)
_ TestLocalTZOffset.test_timezone_offset_calculation_3 _

a = (,)

@wraps(func)
def standalone_func(*a):
>   return func(*(a + p.args), **p.kwargs)

/usr/lib/python3/dist-packages/parameterized/parameterized.py:637: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/tmp/dateparser/.pybuild/cpython3_3.11_dateparser/build/tests/test_timezone_parser.py:143:
 in test_timezone_offset_calculation
self.then_offset_is(offset)
/tmp/dateparser/.pybuild/cpython3_3.11_dateparser/build/tests/test_timezone_parser.py:154:
 in then_offset_is
self.assertEqual(delta, self.timezone_offset)
E   AssertionError: datetime.timedelta(days=-1, seconds=43200) != 
datetime.timedelta(days=-1, seconds=50400)
_ TestLocalTZOffset.test_timezone_offset_calculation_4 _

a = (,)

@wraps(func)
def standalone_func(*a):
>   return func(*(a + p.args), **p.kwargs)

/usr/lib/python3/dist-packages/parameterized/parameterized.py:637: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/tmp/dateparser/.pybuild/cpython3_3.11_dateparser/build/tests/test_timezone_parser.py:143:
 in test_timezone_offset_calculation
self.then_offset_is(offset)
/tmp/dateparser/.pybuild/cpython3_3.11_dateparser/build/tests/test_timezone_parser.py:154:
 in then_offset_is
self.assertEqual(delta, self.timezone_offset)
E   AssertionError: datetime.timedelta(0) != datetime.timedelta(seconds=7200)
=== short test summary info 
FAILED 
tests/test_timezone_parser.py::TestLocalTZOffset::test_timezone_offset_calculation_0
FAILED 
tests/test_timezone_parser.py::TestLocalTZOffset::test_timezone_offset_calculation_1
FAILED 
tests/test_timezone_parser.py::TestLocalTZOffset::test_timezone_offset_calculation_2
FAILED 
tests/test_timezone_parser.py::TestLocalTZOffset::test_timezone_offset_calculation_3
FAILED 
tests/test_timezone_parser.py::TestLocalTZOffset::test_timezone_offset_calculation_4
= 5 failed, 23912 passed, 2 skipped, 3 deselected in 496.78s (0:08:16) =



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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked

Bug#1060859: [Pkg-nagios-devel] Bug#1060859: monitoring-plugins-check-logfiles: Add abiltiy to search systemd journals by syslog identifiers

[Hilmar Preuße]

On 15.01.24 20:32, John Lines wrote:

Hi,


The attached patch allows an argument of
  --type=journald:identifier='postfix/smtp'
to be specified.

The patch can't be applied as it is: the check_logfiles file is 
generated during build. I moved the code to the appropriate source 
files, new package is here. Please test:


https://www.preining.info/~hille42/

Hilmar
--
Testmail



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060876: latexmk: Homepage has moved

[Stuart Prescott]

Package: latexmk
Version: 1:4.79-1
Severity: minor
X-Debbugs-Cc: stu...@debian.org

Dear Maintainer,

The web site listed in the Homepage field of latexmk indicates that the
project has moved:

> On July 28, 2023, the Personal web server was retired as a service. This
> change aligns with the retirement of the PASS service upon which it depended
> to store web content.
>
> ACTION: Please update your bookmarks before July 28, 2025.

The page offers a new URL for the site that is incorrect. The new site is:

https://www.cantab.net/users/johncollins/latexmk/index.html

The URL in d/watch will also need updating.

regards
Stuart

Bug#1019925: backblaze-b2: new upstream 3.5.0 available

[Alexandre Detiste]

phx-class-registry is now packaged but rst2ansi is not

https://github.com/Snaipe/python-rst2ansi

Bug#1060875: rust-itertools: please upgrade to v0.12

[Jonas Smedegaard]

Source: rust-itertools
Version: 0.10.5-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to (or separately provide) branch v0.12.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWlp4cACgkQLHwxRsGg
ASH/Bg//SJAxHtEdsiD9a2ev3Tun3xV7KjTcNhqbw3LChu0vxMHOzkn+xTzhbFiX
wFqVsBijTMwvO922I3I1u27ScwMN4/PO+6iQLFW2mSPuIOds6+D1nQZs6ohgXBh3
iEOETVpuIidsBfdJa7gkaf0LWTSebFANaDnB/BliGLn6QPavqpn61R1qpPQsT44u
DMg9bugJIzm78Lxe8zO0d4DlhAacH4pNuOBEP2v20zgxNIy2o3P0woLO8pjsgRjc
c0D2kRBZCtYaCbHbbtAA24iTnf00Dz2JPtome9mfJwrd6/Ixnot2rHPVzstlTifc
KbznStBYfLTzZ+L+WdlVy7aU1yDgnKIzRgxEDQIjGAC1tAVCCZYISfHAkuABFo+R
N3+9E6yLT1m557KQUwZX+jB61fUGo37AtAfLCO+oV9dCvhFVHvq4traewH/tWQPL
pmkL20GTWl1DilKis0kQ1DB6hkFCbw3i+uG9qeeqSa+OpgAzmjfCt0LWuL6WSaQQ
VVlwllxwx6ZJ1ReHwguJouQ+ZVkTVrge+sUSFiEPdnaKw29Wm0edBwR1LDxV1/U6
GJaQW+lDscSMZzR9+Nr5lTiTJdLUcYSQOB9tva+tewEQcs4cE/0JQQn0/GO9Lt/1
ZlGqE8T83z6qQCtBQwfAYUHroP4r1chTSs1RXxau5565Nk3cP0o=
=DKop
-END PGP SIGNATURE-

Bug#1060874: rust-which: please upgrade to branch v5

[Jonas Smedegaard]

Source: rust-which
Version: 4.2.5-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to branch v5.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWlpugACgkQLHwxRsGg
ASGFiw/8CBtpZQNMpmbRVf+ShwNcTdZbzT3XqxIJkYgYgGQ9E1fqLEsgImZQHWbq
orBH4yNVcOT9C+i0P4rDqJ+tX+5KGGqu0Sel2Tws7iGvObV2Mhy+l3PApm2RITmX
kU16vNAwQeM/PbF3nGY5oKvc466DnewFfXBbqtBaUjChLLP1S1aBpn+Pu1kZ1Qgs
KVaF+4+ufIfcdHvMbP/hbeJzW7pa3nM2PtTARWNWnvn+sS57z5XNoTf545H0ZH9K
7QICMywT3RSspBQug/7loW+aA+GQOf8RdFeC1i1K6wsxnKPHX7QeGV0whsLl636j
qeAf14hDyoxY46+/j2q5HEwhUrwaizxkovhYXSwhMuhV7xaY4cSfPUk3slvRI9XU
PsbQdaofXy3wQHqRUb+adZbFZWBUaSdJOmPzn8jIF1RiZ2Vwaos8E9qle7OsO0hc
caszelEKJFWE3K0t1VdqCglQstIL/yA8KXQqPpm474u/xIBcHzzt1rZKb9zKZLJ5
sZ7JSHD8ZR2ehbDy8wQMTv04cKzgCm+YURHRXC3t4BEXCmg5FGksFto3OXwE9xwT
nUNSbWUG2iWuayPGaJl8QHR+k0b+4uk3YfcGOOZ4KwGJb+LKVBK64gacH+YIM5SG
XIrJT20ZnV3KzTXQM/oAZIpC0iHMYQ5eGQM5x6+ouVAPJbOIWM8=
=gPUs
-END PGP SIGNATURE-

Bug#1060873: rust-uuid: please update to v1.6.0

[Jonas Smedegaard]

Source: rust-uuid
Version: 1.4.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v1.6.0.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWlpoAACgkQLHwxRsGg
ASFIbg//VviLs9RCDIzBv+dkpcFaVSnktgYCcIP7cJUu+er3f28K1fsiqZvj1fF/
DLlbPAoVegeEW4wSYeX2YA6I3l454HGeGHkhsVNjS/ZiO9nyF+Yjc7+KwmhzOBrr
S29mH2z9H0XJkMw0p2lhZsWsaIRWT8SfaW6AWqz8hCQQwKTYPdRpHq/HSyuuzIyx
uC5Cbtu3alqV8KWE1ENj5MW3T+CD3QDZeuXKUaeWZIH0iKH6Ut/teVseJsG4n7+/
DftEqxOQpxC1745rJjD8JY2/JYinqfHoZsLfEqrwl89o3d5mKJ7fjn0or6McxnOq
pR+q51SyLA7YobFybKAVNc7y5k0a/UvSAkpH4xQiedKatGIz+CsFEdjapbv+xznk
WV2NgrlOwi8LbN4We4vb1rBeQoQdQfQNvAmKg8esax6t4fwzQbl7GfEmmYQZ6yip
I5GZPSwxGSqCfekjDQ1/taiMkVliANRZCJTOpO/4NzxuGz8FGaIJLroedvqboZQZ
z6OXopA4jIV8j+qVzWV57HKSc53CJcKwC23ULT/xOEaspIi6ASX+fYbsmeQj7TfZ
iiA1Gcy66TcNWKl12uC7lE1BHbQ+ACJSEow+xa7seAyE/FscXjv9Pc5FKDtysHLD
KMZ3NCN+F6ERStDA5fjdBZniCof1JuMz/x8RtSHnBtiUCQFhOaw=
=w9Cr
-END PGP SIGNATURE-

Bug#1060872: rust-trust-dns-resolver: please upgrade to v0.23

[Jonas Smedegaard]

Source: rust-trust-dns-resolver
Version: 0.22.0-4
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to branch v0.23.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWlpe4ACgkQLHwxRsGg
ASHOvg//QZ/H+JoDtvUr/7/c1ftJxOxS5VgQjiF1r39busGZKHmvSifGXK9fEodN
WWD8Xh51A4zR/rlmK5rSsPL7ocEwxcC1FhqgPgjI1vJo89Ib4dNmd4dQEqD4VYAD
f5HKwdYS28OP1X2jvoHojXrMz6ekm9NMFFcmXgO1sJOFdDpBzVdiXns61SUypYEF
UCVQ7A5dvTzSm/AUQZVruEK548srCtO3ppfQblijoYB1Nn9danmQSHbxywn4R6/V
4N/1NxY8aqOhxWIq1gxwbucKvtUEl9DNWSdtXn8ItjltBkaoNeBfj2BUxfmw+CXx
XwZMhOzLKAVg44eJA4tzWPd4KkFcQg7t6m0kNgXcRtSDBbY0AWlBCv5MdxZl1Gqa
YtEe/u9cTgwfOJiS4E9UIJddXfXCOCS4IGguBpmsJmJ8ucmfnB2SaWRL0oAWIa1N
Av9dcIhTz3iXR2JOrV5/nCiG9diPKwu5Gr0m/fw5f9Rzg36jujsG7AGqKhI5Gj8M
3OapWn7LLQu/hL8xX0yKgVxlEmCAVB+b5LqRAfFu+Ea0onlebe4+bIPw58eI08/t
C3hLX36iVDtbG4njBPalXkdgEfOMZaXkZ5pwymNopTgq1bJFkKCR+ZppK7p+7RrM
i0iDAr0vyoTfsxWZGhekAQk3OzTmB15POT34PRcMVhJuhcaHTg8=
=kuF+
-END PGP SIGNATURE-

Bug#1060871: rust-tar: please update to v0.4.40

[Jonas Smedegaard]

Source: rust-tar
Version: 0.4.38-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v0.4.40.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWlpWYACgkQLHwxRsGg
ASFavA//cOzWWIWN0Pi2zJBjl8QfGMhmmaiploqEsrAIxjm6Vb/LJ/9MZq6ykpQs
5eJbozijLqqq6T7uQDQldFOG4B9BNSzf00eKjgq5xjL4U/MwOyP7qtL38bugSDI2
xqeLZH27CvXIoJS79wLiIdFgZHdxm+kjp+CC68NyjTcGGjgQ4ky0AJC2rKSBBcyC
rBWgNMJFucD8CRCQS9nuhuP/GfvQ7siiOy+t1eFLn1LhJXO1zyUU6X6l0ETkWpnc
rdiygsVRmv6ieMRoiKuJkkquyupArdKP6pkmAg7rINvdtdo9P9q8s8j4XfOI22Ci
DvRUZXt01ueCRy5pp1JTXSizgZMZVrfB/sPtLI4DMhK2NMnLcog+AkHET7GxL8C7
bzxy1bsR0Ne19m3WHv2SvPJqHhLe+UAvSNxFLSIM8VNdr2jWj+MADOUQWaf2kwva
ULPJcu2ljCDElvpjfEv1a98hCVCdKT28CzFo+m9dI1YDejFmVjLRUDbF5gZilbzs
4qaCpAmGInlJBKpg6nseFM6es8dtgYbuBqsOYYfciqdmFj9hYMjJgA4dcb4qcXWF
juH6USQPZ2ggFUMd2mC79jaoGoRoWRAON+9BX7NmaG403G54WItnztX9711CQgF5
t2OX2zF9Y0G7P1FdcJm/gvYmdoJGh01B8iYr4a0AX10L01PmKug=
=Dy91
-END PGP SIGNATURE-

Bug#1060870: rust-strip-ansi-escapes: please upgrade to v0.2

[Jonas Smedegaard]

Source: rust-strip-ansi-escapes
Version: 0.1.1-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to (or separately provide) branch v0.2.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWlpLIACgkQLHwxRsGg
ASF09A//WJ/j+P5Fq/tE9A1Cfqy2LRCTVvfkbyEYRqOS9EbSmFkoEuyP5rpb0HjU
39C9bd6W6H5Kfgj+GOfVinPOb1p8ThgneyDb0FewtpEq3BSjD0/of+EJjX1FjTKU
f/pOxdz+BUI04v3mLeaPj/hDT7+MBbBVAAcklw+UQXazUdzmuUoVOGAoRJeBr/zD
3QWIci/dD9L47VnDm9Z8irhDVestUrNSgiQ7xq+yviWSLoqEK/7nyZAc5ZmFKz5M
ECxTlXMTzvQhrW8SIyhBTwQkbxdbNNcXL7X/Wq0ysxTsbsvXW6ffQ+0YMns55KD3
cdrwtnAJl3FcQEJCxYpoMp2Zu9edRLIFet4gbAHZXy6Z3jxPSGSRUwZ/Wj/Pijf3
CKKgkJSJ823M6KYzxoN1lDrJbPnmebn1kF3cwtjgCt08X9KCvMIW3g1Hi8Qv5ZwK
7ypynafn4HFWtOqaXsbfGwEPxtxytw/U4YMHlkrqwW/DKXexkzVQ4aPDwZxPRmWd
VccJ+heI7BtK8VKn9RE0cWyAB3Jx8auhcLTBu/h3dhJLlvLj3i1pXYUjYWLxZmaz
Y8BEvfjBPR8JY7nm1ysCj24uOhVNzwvy7E1vdDu8+Gavi40DpGhwUsT7FjKY667x
trQFnLeQ723x5hecaY6Y67jlGvjuo8fGIl0oJQfRaxu9UTfPe5c=
=TL/l
-END PGP SIGNATURE-

Bug#1059272: transition: tango

[Sebastian Ramacher]

Hi Santiago

On 2023-12-27 21:16:02 +0100, Sebastian Ramacher wrote:
> On 2023-12-22 08:36:17 -0300, Santiago Ruano Rincón wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: ta...@packages.debian.org, thomas.br...@byte-physics.de
> > Control: affects -1 + src:tango
> > 
> > Dear Release Team,
> > 
> > I would like to upload tango 9.5.0 to unstable. There has been a SONAME
> > bump from 9.4.2. Its reverse dependency pytango 9.5.0 builds and works
> > well. Both are available in experimental.
> > 
> > This set of uploads are needed to fix the pytango FTBFS bugs in unstable
> > related to python3.12:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055733
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049843
> > 
> > Even if there is only one reverse dependency, I prefer to ask: May I go
> > ahead?
> 
> Please go ahead.

The autopkgtests of pytango fail on s390x: 
https://ci.debian.net/packages/p/pytango/testing/s390x/
Could you please take a lookg?

Cheers
-- 
Sebastian Ramacher

Bug#1060077: transition: g2clib

[Sebastian Ramacher]

Control: tags -1 ocnfirmed

On 2024-01-05 17:11:23 +, Alastair McKinstry wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: g2c...@packages.debian.org, sramac...@debian.org
> Control: affects -1 + src:g2clib
> 
> 
> There is a minor transition I wish to proceed. g2clib upstream have added an 
> SOVERSION of .0

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1059066: transition: nauty

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2023-12-19 23:02:13 +, Torrance, Douglas wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: dtorra...@piedmont.edu
> Severity: normal
> 
> Hello!
> 
> I am requesting a transition slot for nauty.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1053359: rsyslog-mysql: Data too long for column 'FromHost'

[Heinrich Schuchardt]

Package: rsyslog-mysql
Version: 8.2312.0-3
Severity: normal

In Launchpad autopkgtests fail with Data too long for column 'FromHost' 
on a system with a hostname of 63 characters.


I hope to resolve this with merge request
https://github.com/rsyslog/rsyslog/issues/5309
testing is still ongoing.

These are the relevant syslog messages:

2500s Jan 15 17:49:22 autopkgtest rsyslogd[2317]: rsyslogd: ommysql: db 
error (1406): Data too long for column 'FromHost' at row 1  [v8.2312.0]
2500s Jan 15 17:49:22 autopkgtest rsyslogd[2317]: rsyslogd: The error 
statement was: insert into SystemEvents (Message, Facility, FromHost, 
Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values 
(' rsyslogd: action \'action-7-ommysql\' (module \'ommysql\') message 
lost, could not be processed. Check for additional error messages before 
this one. [v8.2312.0 try https://www.rsyslog.com/e/2218 ]', 3, 
'adt-noble-amd64-rsyslog-20240115-160328-juju-7f2275-prod-propos', 6, 
'20240115174920', '20240115174920', 1, 'rsyslogd[2317]:') [v8.2312.0 try 
https://www.rsyslog.com/e/2218 ]
2500s Jan 15 17:49:22 autopkgtest rsyslogd[2317]: rsyslogd: action 
'action-7-ommysql' (module 'ommysql') message lost, could not be 
processed. Check for additional error messages before this one. 
[v8.2312.0 try https://www.rsyslog.com/e/2218 ]


Best regards

Heinrich

Bug#1060869: rust-memmap2: please update to v0.9.3

[Jonas Smedegaard]

Source: rust-memmap2
Version: 0.9.0-3
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v0.9.3.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWloJ8ACgkQLHwxRsGg
ASHD7A/8DuJu0m02BumCrr97FZe2iFSesJsUBYhSphdEyUrSUAV8rTlxhi9HWoG8
YgTxwEG9J8gz4VNbL92q2uzhXLlKzX7bDPbDNy98jS4BFFdc+5/GdVGconcosUrJ
hhpg5Y7UrqHtSIbpSOAGw3yg0sdOPxMi4ydM47eZJiBqZ3+b6jhhstXah3qgUfr6
fgFPFqQfbBRUQK6xm9+v/ypvj9q+imZ5JbNnF77Ph9ilL7WjjW6/akRAcONewIFP
oXtLSzFwfp5Wq6GJNcfyBboxZIF2tXmJmv7bA9WdZ/8K/n1R1xhndwyEQl5L03nJ
nl/Oex6gkAttgJdEENC3R6lRe2jpIe2cXhgT7ANEVfVuMw+uPBsEG1++1C10nWEI
GITAGEpw2qFELHlQe5rOowJLXS8aGqI6yaEfICzYS5jdQb4MdSywyjqooToVGFJ7
6+HoaSsbLEIG3AseYk7xzzKFGfrO0We7jGWmTNjvL69qetv4H/my99HYh88iXhTI
6hw8eWaQoAAT7kW1lOUGzHC0ztcto4EJNUQkgx+5omwe6uM8y404F/DCnqhL9vYP
fMYPDQhcpBHfIIJdkDyTS2IFmLGek9hOBA5k9GIn6FVcqnkbQwaTlO5XpXqO710r
aQ3GdkmbNuPbGxACJAvW/4GcP26flAyMrus25wmmcym//TZiKSA=
=5RRO
-END PGP SIGNATURE-

Bug#1060868: rsyslog-mysql: Data too long for column 'FromHost'

[Heinrich Schuchardt]

Package: rsyslog-mysql
Version: 8.2312.0-3
Severity: normal

In Launchpad autopkgtests fail with Data too long for column 'FromHost' 
on a system with a hostname of 63 characters.


I hope to resolve this with merge request
https://github.com/rsyslog/rsyslog/issues/5310
testing is still ongoing.

These are the relevant syslog messages:

2500s Jan 15 17:49:22 autopkgtest rsyslogd[2317]: rsyslogd: ommysql: db 
error (1406): Data too long for column 'FromHost' at row 1  [v8.2312.0]
2500s Jan 15 17:49:22 autopkgtest rsyslogd[2317]: rsyslogd: The error 
statement was: insert into SystemEvents (Message, Facility, FromHost, 
Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values 
(' rsyslogd: action \'action-7-ommysql\' (module \'ommysql\') message 
lost, could not be processed. Check for additional error messages before 
this one. [v8.2312.0 try https://www.rsyslog.com/e/2218 ]', 3, 
'adt-noble-amd64-rsyslog-20240115-160328-juju-7f2275-prod-propos', 6, 
'20240115174920', '20240115174920', 1, 'rsyslogd[2317]:') [v8.2312.0 try 
https://www.rsyslog.com/e/2218 ]
2500s Jan 15 17:49:22 autopkgtest rsyslogd[2317]: rsyslogd: action 
'action-7-ommysql' (module 'ommysql') message lost, could not be 
processed. Check for additional error messages before this one. 
[v8.2312.0 try https://www.rsyslog.com/e/2218 ]


Best regards

Heinrich

Bug#1060785: libspa-audioconvert: Crash sometimes due to misaligned load to YMM register.

[K.Ohta]

Dear Dylan-San,

I forwarded to upstream.
See, https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3790 .
Thank you for your suggestion.
 
Ohta.

On Mon, 15 Jan 2024 18:21:56 +0100
Dylan Aïssi  wrote:

> Hi Ohta,
> 
> Le dim. 14 janv. 2024 à 10:24, Kyuma Ohta
>  a écrit :
> >
> > Sometimes ...mostly be load growth a lot..., pipe-wire daemon or
> > pipewire-pulse daemon crashes with below message [1].
> >
> > This happens misalign of loading to YMM register [2][3].
> >
> > This crash seems to happen at "vlddqu -0x20(%rcx),%ymm2" [2],
> > this need align at 256bit (but, Older Ryzen may be need only align
> > of 128bit).
> > But, RCX register didn't align of 256bits [3].
> > Value is 0x5650f98e99c4 .
> >
> > So, software related libspa-audioconvert crashes sometime and
> > randomly. I think.
> 
> Thank you for this bug report. May I ask you to forward it upstream?
> at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues
> 
> Thank you!
> Best regards,
> Dylan
> 

Bug#1060856: [Pkg-xmpp-devel] Bug#1060856: gajim: needs gtk3 >= 3.24.30 (found 3.24.24) to run, not reflected in dependencies

[Martin]

Hi Christian,

On 2024-01-15 19:49, Christian Häggström wrote:
> Versions of packages gajim depends on:
> ii  gir1.2-gtk-3.0   3.24.24-3

bookworm-backports, including gajim 1.8.4-1~bpo12+1, targets Debian 12
bookworm, which had gtk+3.0 3.24.37-2 from the start, if I'm not
mistaken. (Now it even has 3.24.38-2~deb12u1.) I.e. for a normal,
up-to-date system (or even not up-to-date, like Debian 12.0), there
shouldn't be any issue. I assume, you should do that:

sudo apt update && sudo apt full-upgrade

Cheers

Bug#1060867: rust-fs-err: please update to v2.11.0

[Jonas Smedegaard]

Source: rust-fs-err
Version: 2.9.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v2.11.0.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWlmyIACgkQLHwxRsGg
ASHwEQ/+O179+lJf0keQFoxJXbsJK+RpI9lPmNmqdt1Q+gusSOrrI2sY+bq/DJd4
iwai6h6NMl8zL9LI0tYV3i9uGmz8LOS50RdhxGOCRHJb/DfpA4tJ/lMKKTnM1KOK
LhTW4mkvFglAM+dZeoqV2vAO7dnA9d+ToAcYlfZNCj3/mEVdwYTncHzbZVCNmWL3
9tmyez5Pe2rft66kAp+Bu9rHEE8sfQb9ieS6ayLt/Wc8KFiEp58pF06zrDO1FToJ
WEmnnNdjSDDxQMKT0a6JHiYOxdg0WXlAPnlVbM3iXAQpogaYTURdzegF84xqzAPK
o2qcp9CoQPy0ncDP4MoFJaKfPMZfJVBrFy+yLsVO1C8Cp4GGdhog9pos1wA/yCQ0
nGQP6m6s7jS+MC/tDsMZlfjKaVvWbGb4lYJSfgkfDGK/tR+uIR3S4b6lkp+eAtqA
SvRnP3xBxd3ENBMrXgdnNdIrOww0HTl1KSf54n583IpsJ9LBWiwZ/rLJwDksq1qA
5pd5/g8GZl2oAA+VjPy1MhnykxtgI2c9xYWl7353VFJvQ/RVgwxuqAkg8tqxKBba
VzU0f2JSqKaRYBxkaz8sFXDUjM4nPUCO8X3SLRdY1DCwsKZBqd46voQmGDRqyFZM
W6DOLi4H+Iwjq2ZpfRXOi7LddDfExqeNmOWIkS0+jBoPKsQA2Bs=
=xgtF
-END PGP SIGNATURE-

Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator

[John Paul Adrian Glaubitz]

On Mon, 2024-01-15 at 19:29 +0100, Richard wrote:
> I second this report. The app did use to work actually, but recently - not 
> sure with
> transitioning to ausweisapp with v2.0 or later, this breaks for me too.

What breaks? Please be more specific!

> This renders the app completely unusable, at least using Gnome, which should 
> justify a
> severity of important. It's quite irrelevant if the app is a Gnome, Gt or 
> whatever app.

It is actually quite relevant because it is up to the upstream developer which 
configurations
they support and which not. There is an endless number of Linux distributions 
and desktop
environments, so it's naturally impossible to support all of them.

> Like any app, if it's included in Debian it should not be broken beyond 
> usability.

It's not broken beyond usability. It works for me perfectly fine. There is no 
guarantee
you though that it will work in your particular configuration. And, as you can 
read from
the license, Debian comes with absolutely no warranty whatsoever, so I am not 
sure what
you are expecting.

> Sure, the newer version right now is only available in testing and sid 
> (tested both, same
> result).

Errm, you shouldn't be installing packages from unstable on a stable system [1].

> But that just makes it more important that this is sorted out before this 
> package is made
> available in stable or stable-backports. Especially since running it as 
> Flatpak would
> probably render half the app unusable since the communication with the 
> browser would
> probably not work.

FWIW, I am merely packaging the software for Debian. I am not the upstream 
developer. If
you have problems with the software itself which is not related to packaging, 
you should
direct your bug reports upstream.

Unfortunately though, upstream actually does not officially support Linux, so 
they don't
really care if it breaks. Thus, if you are really so annoyed by the software 
not working
on your particular system, I am happy to request a removal of the package from 
the Debian
archive mirrors so that I don't have to bother with such entitled bug reports 
anymore.

Thanks,
Adrian

> [1] https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1014722: ansible: CVE-2021-3532

[Salvatore Bonaccorso]

On Sun, Jul 10, 2022 at 10:27:06PM +0200, Moritz Mühlenhoff wrote:
> Source: ansible
> X-Debbugs-CC: t...@security.debian.org
> Severity: normal
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for ansible.
> 
> CVE-2021-3532[0]:
> | A flaw was found in Ansible where the secret information present in
> | async_files are getting disclosed when the user changes the jobdir to
> | a world readable directory. Any secret information in an async status
> | file will be readable by a malicious user on that system. This flaw
> | affects Ansible Tower 3.7 and Ansible Automation Platform 1.2.
> 
> Red Hat Bugzilla seems the original report here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1956464
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2021-3532
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3532
> 
> Please adjust the affected versions in the BTS as needed.

This CVE was rejected by the assigning CNA (RedHat) with "This CVE is
marked as INVALID and not a bug ".

Regards,
Salvatore

Bug#1060866: librust-quote-dev: fails to build as transitive dependency of tailspin

[Jonas Smedegaard]

Package: librust-quote-dev
Version: 1.0.35-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Attempting to build tailspin-2.4.0+dfsg fails like this:

   Compiling quote v1.0.35
 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=quote 
CARGO_MANIFEST_DIR=/build/tailspin-2.4.0+dfsg/debian/cargo_registry/quote-1.0.35
 CARGO_PKG_AUTHORS='David Tolnay ' 
CARGO_PKG_DESCRIPTION='Quasi-quoting macro quote'\!'(...)' 
CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='MIT OR Apache-2.0' 
CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=quote 
CARGO_PKG_REPOSITORY='https://github.com/dtolnay/quote' 
CARGO_PKG_RUST_VERSION=1.56 CARGO_PKG_VERSION=1.0.35 CARGO_PKG_VERSION_MAJOR=1 
CARGO_PKG_VERSION_MINOR=0 CARGO_PKG_VERSION_PATCH=35 CARGO_PKG_VERSION_PRE='' 
LD_LIBRARY_PATH='/build/tailspin-2.4.0+dfsg/target/release/deps:/usr/lib:/usr/lib/libeatmydata'
 /usr/bin/sccache rustc --crate-name quote --edition=2018 
/build/tailspin-2.4.0+dfsg/debian/cargo_registry/quote-1.0.35/src/lib.rs 
--error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat 
--crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C 
debug-assertions=off --cfg 'feature="default"' --cfg 'feature="proc-macro"' -C 
metadata=7530c576d4e7ba0a -C extra-filename=-7530c576d4e7ba0a --out-dir 
/build/tailspin-2.4.0+dfsg/target/release/deps -L 
dependency=/build/tailspin-2.4.0+dfsg/target/release/deps --extern 
proc_macro2=/build/tailspin-2.4.0+dfsg/target/release/deps/libproc_macro2-a00577f3a9f545bb.rmeta
 --cap-lints warn`
error[E0519]: the current crate is indistinguishable from one of its 
dependencies: it has the same crate-name `proc_macro2` and was compiled with 
the same `-C metadata` arguments. This will result in symbol conflicts between 
the two.
 --> 
/build/tailspin-2.4.0+dfsg/debian/cargo_registry/quote-1.0.35/src/ext.rs:3:5
  |
3 | use proc_macro2::{TokenStream, TokenTree};
  | ^^^

error[E0519]: the current crate is indistinguishable from one of its 
dependencies: it has the same crate-name `proc_macro2` and was compiled with 
the same `-C metadata` arguments. This will result in symbol conflicts between 
the two.
   --> 
/build/tailspin-2.4.0+dfsg/debian/cargo_registry/quote-1.0.35/src/ext.rs:105:9
|
105 | use proc_macro2::TokenStream;
| ^^^

error[E0519]: the current crate is indistinguishable from one of its 
dependencies: it has the same crate-name `proc_macro2` and was compiled with 
the same `-C metadata` arguments. This will result in symbol conflicts between 
the two.
   --> 
/build/tailspin-2.4.0+dfsg/debian/cargo_registry/quote-1.0.35/src/runtime.rs:192:9
|
192 | use proc_macro2::extra::DelimSpan;
| ^^^

error[E0519]: the current crate is indistinguishable from one of its 
dependencies: it has the same crate-name `proc_macro2` and was compiled with 
the same `-C metadata` arguments. This will result in symbol conflicts between 
the two.
   --> 
/build/tailspin-2.4.0+dfsg/debian/cargo_registry/quote-1.0.35/src/runtime.rs:193:9
|
193 | use proc_macro2::Span;
| ^^^

error[E0519]: the current crate is indistinguishable from one of its 
dependencies: it has the same crate-name `proc_macro2` and was compiled with 
the same `-C metadata` arguments. This will result in symbol conflicts between 
the two.
 --> 
/build/tailspin-2.4.0+dfsg/debian/cargo_registry/quote-1.0.35/src/spanned.rs:2:5
  |
2 | use proc_macro2::extra::DelimSpan;
  | ^^^

error[E0519]: the current crate is indistinguishable from one of its 
dependencies: it has the same crate-name `proc_macro2` and was compiled with 
the same `-C metadata` arguments. This will result in symbol conflicts between 
the two.
 --> 
/build/tailspin-2.4.0+dfsg/debian/cargo_registry/quote-1.0.35/src/spanned.rs:3:5
  |
3 | use proc_macro2::{Span, TokenStream};
  | ^^^

error[E0519]: the current crate is indistinguishable from one of its 
dependencies: it has the same crate-name `proc_macro2` and was compiled with 
the same `-C metadata` arguments. This will result in symbol conflicts between 
the two.
  --> 
/build/tailspin-2.4.0+dfsg/debian/cargo_registry/quote-1.0.35/src/spanned.rs:43:9
   |
43 | use proc_macro2::extra::DelimSpan;
   | ^^^

error[E0519]: the current crate is indistinguishable from one of its 
dependencies: it has the same crate-name `proc_macro2` and was compiled with 
the same `-C metadata` arguments. This will result in symbol conflicts between 
the two.
  --> 
/build/tailspin-2.4.0+dfsg/debian/cargo_registry/quote-1.0.35/src/spanned.rs:44:9
   |
44 | use proc_macro2::Span;
   | ^^^

error[E0519]: the current crate is indistinguishable from one of its 
dependencies: it has the same crate-name `proc_macro2` and was compiled with 
the same `-C metadata` arguments. This will result in symbol conflicts between 
the two.
 --> 
/build/tailspin-2.4.0+dfsg/debian/cargo_registry/quote-1.0.35/src/iden

Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)

[Simon Josefsson]

Shengjing Zhu  writes:

> On Mon, Jan 15, 2024 at 8:51 PM Simon Josefsson  wrote:
>>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Simon Josefsson 
>>
>> * Package name: golang-github-adamkorcz-go-fuzz-headers-1
>>   Version : 0.0~git20230919.8b5d3ce-1
>>   Upstream Author : Adam Korcz 
>> * URL : https://github.com/AdamKorcz/go-fuzz-headers-1
>> * License : Apache-2.0
>>   Programming Lang: Go
>>   Description : helper functions for Go fuzzing (library)
>>
>>  Various helper functions for go fuzzing. It is mostly used in combination
>>  with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with
>>  fuzzing in the standard library will also be supported. Any coverage guided
>>  fuzzing engine that provides an array or slice of bytes can be used with
>>  go-fuzz-headers.
>>  .
>>  go-fuzz-headers' approach to fuzzing structs is strongly inspired by
>>  gofuzz (https://github.com/google/gofuzz).
>>
>> I hope to maintain this package as part of Debian Go Packaging Team:
>>
>> https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/
>>
>
> Usually we don't run fuzz test when building packages, because it
> would waste a lot of buildd resource.
>
> In theory we don't need any fuzz related libraries. But upstream may
> mix their unit tests and fuzz tests in one source file, which makes it
> difficult to strip such tests and their libraries.
> The Go compiler by default wouldn't run fuzz tests.
>
> For packaging rekor, I think all these fuzz tests can be stripped by
> file names. It seems upstream just puts all fuzz tests in
> "fuzz_test.go".

What is the best method to modify rekor to not need this dependency?

If rekor can work without this package, I'm happy to avoid packaging it,
although it is already in NEW.

Looking at code, it seems to be used here:

go.sum:github.com/AdamKorcz/go-fuzz-headers-1 
v0.0.0-20230618160516-e936619f9f18 
h1:rd389Q26LMy03gG4anandGFC2LW/xvjga5GezeeaxQk=
go.sum:github.com/AdamKorcz/go-fuzz-headers-1 
v0.0.0-20230618160516-e936619f9f18/go.mod 
h1:fgJuSBrJP5qZtKqaMJE0hmhS2tmRH+44IkfZvjtaf1M=
hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1 
v0.0.0-2023032938-12e09aba5ebd 
h1:1tbEqR4NyQLgiod7vLXSswHteGetAVZrMGCqrJxLKRs=
hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1 
v0.0.0-2023032938-12e09aba5ebd/go.mod 
h1:0vOOKsOMKPThRu9lQMAxcQ8D60f8U+wHXl07SyUw0+U=
hack/tools/tools.go:_ "github.com/AdamKorcz/go-fuzz-headers-1"
hack/tools/go.mod:  github.com/AdamKorcz/go-fuzz-headers-1 
v0.0.0-2023032938-12e09aba5ebd
pkg/types/hashedrekord/v0.0.1/fuzz_test.go: fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/rpm/v0.0.1/fuzz_test.go:  fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/alpine/v0.0.1/fuzz_test.go:   fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/alpine/fuzz_test.go:  fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/cose/v0.0.1/fuzz_test.go: fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/jar/v0.0.1/fuzz_test.go:  fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/rekord/v0.0.1/fuzz_test.go:   fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/intoto/v0.0.1/fuzz_test.go:   fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/intoto/v0.0.2/fuzz_test.go:   fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/tuf/v0.0.1/fuzz_test.go:  fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/helm/v0.0.1/fuzz_test.go: fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/dsse/v0.0.1/fuzz_test.go: fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/types/rfc3161/v0.0.1/fuzz_test.go:  fuzz 
"github.com/AdamKorcz/go-fuzz-headers-1"
pkg/fuzz/alpine_utils.go:   fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
pkg/fuzz/fuzz_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
pkg/fuzz/jar_utils.go:  fuzz "github.com/AdamKorcz/go-fuzz-headers-1"
go.mod: github.com/AdamKorcz/go-fuzz-headers-1 
v0.0.0-20230618160516-e936619f9f18

Would we have to patch all of these files?  Or disable building them
somehow?

Let's see if we can develop a workaround before ftp-master approves the
packages...  otherwise maybe it doesn't hurt to use it anyway, and may
save us time maintaining patches.

/Simon


signature.asc
Description: PGP signature

Bug#1060865: poppler FTCBFS: gtk-doc fails

[Helmut Grohne]

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

poppler fails to cross build from source, due to something related to
gtk-doc. This is a little suprising given that poppler has split its
documentation into an arch:all package and a cross build always being
arch-only. Rather than looking into fixing this, I looked into disabling
gtk-doc in arch-only builds. I compared a full build to an arch-only
build and notice that build-ids change unfortunately. Other than that,
this change seems to be good. And of course, it fixes the cross build as
well as slightly speeding up the native arch-only build. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru poppler-22.12.0/debian/changelog 
poppler-22.12.0/debian/changelog
--- poppler-22.12.0/debian/changelog2023-01-10 22:36:05.0 +0100
+++ poppler-22.12.0/debian/changelog2024-01-15 20:37:17.0 +0100
@@ -1,3 +1,10 @@
+poppler (22.12.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Disable gtkdoc in arch-only build. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 15 Jan 2024 20:37:17 +0100
+
 poppler (22.12.0-2) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru poppler-22.12.0/debian/rules poppler-22.12.0/debian/rules
--- poppler-22.12.0/debian/rules2023-01-10 22:36:05.0 +0100
+++ poppler-22.12.0/debian/rules2024-01-15 20:37:14.0 +0100
@@ -20,7 +20,7 @@
-DENABLE_QT5=ON \
-DENABLE_QT6=ON \
-DENABLE_CPP=ON \
-   -DENABLE_GTK_DOC=ON \
+   -DENABLE_GTK_DOC=$(if $(filter libpoppler-glib-doc,$(shell 
dh_listpackages)),ON,OFF) \
-DENABLE_UNSTABLE_API_ABI_HEADERS=ON\
-DENABLE_CMS=lcms2  \
-DENABLE_LIBOPENJPEG=openjpeg2  \

Bug#1060857: squid: updating to 4.6-1+deb10u9 causes empty responses for some HTTP requests

[Lucas Nussbaum]

On 15/01/24 at 20:31 +0100, Lucas Nussbaum wrote:
> Package: squid
> Version: 4.6-1+deb10u9
> Severity: important
> 
> Hi,
> 
> After updating to 4.6-1+deb10u9, squid returns empty responses for some
> URLs.
> 
> To reproduce:
> - install squid 4.6-1+deb10u9
> - http_proxy=http://localhost:3128/ curl -v 
> http://cdimage.debian.org/cdimage/archive/
> => empty response (no content)
> 
> Same issue with:
> http://mirror.in2p3.fr/linux/centos-stream/9-stream/BaseOS/x86_64/iso/
> http://archive.ubuntu.com/ubuntu/dists/

Some more analysis using cdimage.debian.org:

Some requests to cdimage.debian.org get a reply with Transfer-Encoding:
chunked and no Content-Length, some get a reply without
Transfer-Encoding and a Content-Length.

[[ quick and dirty one-liner:
for i in $(seq 1 10); do echo -e "GET /cdimage/ HTTP/1.1\r\nHost: 
cdimage.debian.org\r\nConnection: close\r\nUser-Agent: curl/7.64.0\r\n\r\n" | 
nc cdimage.debian.org 80 > resp11_$i.txt; done
]]

Replies with a Content-Length get processed correctly. Replies without
don't.

(can be verified using nc -l -q 0 -p 8000 < resp11_2.txt
and curl http://localhost:8000)

This also means that it might be needed to perform several requests
(with curl -H "Cache-Control: no-cache") to reproduce, even if for some
reason the first request always get chunked.

Lucas

Bug#1060861: RUSTSEC-2023-0078

[Salvatore Bonaccorso]

Hi Moritz,

On Mon, Jan 15, 2024 at 08:49:04PM +0100, Moritz Muehlenhoff wrote:
> Source: rust-tracing
> Version: 0.1.37-1
> Severity: important
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> https://rustsec.org/advisories/RUSTSEC-2023-0078.html
> https://github.com/tokio-rs/tracing/pull/2765
> Fixed by: 
> https://github.com/tokio-rs/tracing/commit/20a1762b3fd5f1fafead198fd18e469c68683721
>  (tracing-0.1.40)

Please double-check but I think no Debian released version was ever
affected. The issue is fixed in 0.1.40 already upstream, with the
above commit (backed by
https://rustsec.org/advisories/RUSTSEC-2023-0078.html). The issue on
the other hand is introduced in
https://github.com/tokio-rs/tracing/commit/3a65354837a0f176178e15787fc700dd6fa11a92
which is first in 0.1.38. 

In unstable we ever had only 0.1.37-1, then moved to 0.1.40-1.

Regards,
Salvatore

Bug#1060666: Update to podman-compose from bookworm-backports

[Stefan Weil]

podman-compose 1.0.6-1~bpo12+1 from bookworm-backports works fine.

I suggest to update bookworm to that version.

Bug#1060863: ocsinventory-server: CVE-2023-3726

[Salvatore Bonaccorso]

Source: ocsinventory-server
Version: 2.8.1+dfsg1+~2.11.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/OCSInventory-NG/OCSInventory-ocsreports/pull/1545
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ocsinventory-server.

CVE-2023-3726[0]:
| OCSInventory allow stored email template with special characters
| that lead to a Stored cross-site Scripting.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-3726
https://www.cve.org/CVERecord?id=CVE-2023-3726
[1] https://github.com/OCSInventory-NG/OCSInventory-ocsreports/pull/1545
[2] 
https://github.com/OCSInventory-NG/OCSInventory-ocsreports/commit/78b5545b0a2e3e484605d9364424d6b924897aaf
[3] 
https://github.com/OCSInventory-NG/OCSInventory-ocsreports/commit/91780aefb904c9eac114e99246b3bef0d4e7d83c

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1060864: RM: mathlibtools -- ROM; abandoned upstream

[Christopher Hoskin]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: mathlibto...@packages.debian.org
Control: affects -1 + src:mathlibtools

reportbug seems insistent that I edit this report

Bug#1060862: freeimage: CVE-2023-47995

[Salvatore Bonaccorso]

Source: freeimage
Version: 3.18.0+ds2-10
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for freeimage.

CVE-2023-47995[0]:
| Buffer Overflow vulnerability in
| BitmapAccess.cpp::FreeImage_AllocateBitmap in FreeImage 3.18.0
| allows attackers to cause a denial of service.

The only reference for now is [1] unclear if there is some development
around it.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-47995
https://www.cve.org/CVERecord?id=CVE-2023-47995
[1] https://github.com/thelastede/FreeImage-cve-poc/tree/master/CVE-2023-47995

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1056484: python-molotov's autopkg tests fail with Python 3.12

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/tarekziade/molotov/issues/164


-- 
http://fam-tille.de

Bug#1060861: RUSTSEC-2023-0078

[Moritz Muehlenhoff]

Source: rust-tracing
Version: 0.1.37-1
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

https://rustsec.org/advisories/RUSTSEC-2023-0078.html
https://github.com/tokio-rs/tracing/pull/2765
Fixed by: 
https://github.com/tokio-rs/tracing/commit/20a1762b3fd5f1fafead198fd18e469c68683721
 (tracing-0.1.40)

Bug#1060860: rust-vmm-sys-util: CVE-2023-50711

[Moritz Mühlenhoff]

Source: rust-vmm-sys-util
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for rust-vmm-sys-util.

CVE-2023-50711[0]:
| vmm-sys-util is a collection of modules that provides helpers and
| utilities used by multiple rust-vmm components. Starting in version
| 0.5.0 and prior to version 0.12.0, an issue in the
| `FamStructWrapper::deserialize` implementation provided by the crate
| for `vmm_sys_util::fam::FamStructWrapper` can lead to out of bounds
| memory accesses. The deserialization does not check that the length
| stored in the header matches the flexible array length. Mismatch in
| the lengths might allow out of bounds memory access through Rust-
| safe methods. The issue was corrected in version 0.12.0 by inserting
| a check that verifies the lengths of compared flexible arrays are
| equal for any deserialized header and aborting deserialization
| otherwise. Moreover, the API was changed so that header length can
| only be modified through Rust-unsafe code. This ensures that users
| cannot trigger out-of-bounds memory access from Rust-safe code.

https://rustsec.org/advisories/RUSTSEC-2024-0002.html
https://github.com/advisories/GHSA-875g-mfp6-g7f9
https://github.com/rust-vmm/vmm-sys-util/commit/30172fca2a8e0a38667d934ee56682247e13f167
 (v0.12.1)


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-50711
https://www.cve.org/CVERecord?id=CVE-2023-50711

Please adjust the affected versions in the BTS as needed.

Bug#1060859: monitoring-plugins-check-logfiles: Add abiltiy to search systemd journals by syslog identifiers

[John Lines]

Package: monitoring-plugins-check-logfiles
Version: 4.1.1-3
Severity: wishlist
Tags: patch upstream

Dear Maintainer,

I scan mail logs for Deliverable Status Notifications for 'dsn=5.7" on
my delivery server, so if some recipient starts blocking the server I
can start investigating and switch to a different outbound server before
users start to report that 'mail is not working'.

For systems where mail logs are in /var/log/mail.log this is simple, but
where they are in the systemd journal a scan which looks only at, in
this case, entries with a SYSLOG_IDENTIFIER of 'postfix/smtp' is more
effective.

The attached patch allows an argument of 
 --type=journald:identifier='postfix/smtp'
to be specified.

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

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

Versions of packages monitoring-plugins-check-logfiles depends on:
ii  perl  5.36.0-7+deb12u1

monitoring-plugins-check-logfiles recommends no packages.

monitoring-plugins-check-logfiles suggests no packages.

-- no debconf information
--- check_logfiles  2023-01-20 22:18:33.0 +
+++ check_logfiles_journal_identifier   2024-01-15 18:10:54.103892826 +
@@ -8,6 +8,8 @@
 #  tivoli config files and
 #  return it as hash structure
 #
+# John Lines  update to filter on journald:identifier
+#  to allow, for example --type=journald:identifier='postfix/smtp'
 package Nagios::Tivoli::Config::Logfile;
 
 use strict;
@@ -5685,6 +5687,7 @@
   if ($self->{journaldunit} and $self->{tag} eq "default") {
 $self->{tag} = $self->{journaldunit};
   }
+  $self->{journaldidentifier} = $params->{journald}->{identifier};
   $self->default_options({ exeargs => "", });
   $self->SUPER::init($params);
 }
@@ -5708,6 +5711,9 @@
 if ($self->{journaldunit}) {
   $cmdline = $cmdline." --unit '".$self->{journaldunit}."'";
 }
+if ($self->{journaldidentifier}) {
+  $cmdline = $cmdline." --identifier '".$self->{journaldidentifier}."'";
+}
 $cmdline = $cmdline." --since '".strftime("%Y-%m-%d %H:%M:%S", 
localtime($self->{journald}->{since}))."'|";
 if ($fh->open($cmdline)) {
   push(@{$self->{relevantfiles}},

Bug#1060858: openssl: CVE-2023-6237: Checking excessively long invalid RSA public keys may take a long time

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for openssl.

CVE-2023-6237[0]:
| Checking excessively long invalid RSA public keys may take a long
| time


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-6237
https://www.cve.org/CVERecord?id=CVE-2023-6237
[1] https://www.openssl.org/news/secadv/20240115.txt

Regards,
Salvatore

Bug#1060857: squid: updating to 4.6-1+deb10u9 causes empty responses for some HTTP requests

[Lucas Nussbaum]

Package: squid
Version: 4.6-1+deb10u9
Severity: important

Hi,

After updating to 4.6-1+deb10u9, squid returns empty responses for some
URLs.

To reproduce:
- install squid 4.6-1+deb10u9
- http_proxy=http://localhost:3128/ curl -v 
http://cdimage.debian.org/cdimage/archive/
=> empty response (no content)

Same issue with:
http://mirror.in2p3.fr/linux/centos-stream/9-stream/BaseOS/x86_64/iso/
http://archive.ubuntu.com/ubuntu/dists/

Downgrading to 4.6-1+deb10u7 restores the correct behaviour.

Lucas


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

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

Versions of packages squid depends on:
ii  adduser  3.118
ii  libc62.28-10+deb10u2
ii  libcap2  1:2.25-2
ii  libcom-err2  1.44.5-1+deb10u3
ii  libdb5.3 5.3.28+dfsg1-0.5
ii  libdbi-perl  1.642-1+deb10u2
ii  libecap3 1.0.1-3.2
ii  libexpat12.2.6-2+deb10u6
ii  libgcc1  1:8.3.0-6
ii  libgnutls30  3.6.7-4+deb10u11
ii  libgssapi-krb5-2 1.17-3+deb10u6
ii  libkrb5-31.17-3+deb10u6
ii  libldap-2.4-22.4.47+dfsg-3+deb10u7
ii  libltdl7 2.4.6-9
ii  libnetfilter-conntrack3  1.0.7-1
ii  libnettle6   3.4.1-1+deb10u1
ii  libpam0g 1.3.1-5
ii  libsasl2-2   2.1.27+dfsg-1+deb10u2
ii  libstdc++6   8.3.0-6
ii  libxml2  2.9.4+dfsg1-7+deb10u6
ii  logrotate3.14.0-4
ii  lsb-base 10.2019051400
ii  netbase  5.6
ii  squid-common 4.6-1+deb10u9

Versions of packages squid recommends:
ii  ca-certificates  20200601~deb10u2
ii  libcap2-bin  1:2.25-2

Versions of packages squid suggests:
pn  resolvconf   
pn  smbclient
pn  squid-cgi
pn  squid-purge  
pn  squidclient  
pn  ufw  
pn  winbind  

-- no debconf information

Bug#1060856: (no subject)

[Christian Häggström]

Upgrading gtk3 gives the next error "Gajim needs glib >= 2.66.0 (found 
2.62.5) to run"


Upgrading gir1.2-glib-2.0 helped that error and gajim starts. I found 
the full list of requirements in 
/usr/lib/python3/dist-packages/gajim/main.py :


_MIN_NBXMPP_VER = '4.5.3'
_MIN_GTK_VER = '3.24.30'
_MIN_CAIRO_VER = '1.16.0'
_MIN_PYGOBJECT_VER = '3.42.0'
_MIN_GLIB_VER = '2.66.0'
_MIN_PANGO_VER = '1.50.0'
_MIN_SQLITE_VER = '3.33.0'

Bug#1056673: [Help] Re: build-depends on atlas, which is obsolete and scheduled for removal

[Andreas Tille]

Hi Sébastien,

Am Mon, Jan 15, 2024 at 05:42:49PM +0100 schrieb Sébastien Villemot:
> I have made a merge request that fixes the build against LAPACKE:
> https://salsa.debian.org/med-team/ghmm/-/merge_requests/1

Thanks a lot.
 
> Note that I verified that it builds correctly, but not that it delivers
> correct results at runtime.

That's fine.  I'll wait merging the MR until the autopkgtest against
clapack is ready, test the results and compare with your MR afterwards.

Thanks a lot for your support
Andreas.

-- 
http://fam-tille.de

Bug#1060856: gajim: needs gtk3 >= 3.24.30 (found 3.24.24) to run, not reflected in dependencies

[Christian Häggström]

Package: gajim
Version: 1.8.4-1~bpo12+1
Severity: minor
X-Debbugs-Cc: debb...@kalvdans.no-ip.org

Dear Maintainer,

I upgraded gajim just to find that it didn't start afterwards. The Debian
metadata does not reflect the gtk3 version it needs.

A workaround is easy, I just update gtk3.


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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: 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)

Versions of packages gajim depends on:
ii  desktop-file-utils   0.24-1
ii  gir1.2-gst-plugins-base-1.0  1.22.0-3+deb12u1
ii  gir1.2-gtk-3.0   3.24.24-3
ii  gir1.2-gtksource-4   4.8.4-4
ii  python3  3.11.2-1+b1
ii  python3-cairo1.20.1-5+b1
ii  python3-cryptography 38.0.4-3
ii  python3-css-parser   1.0.8-1
ii  python3-gi   3.42.2-3+b1
ii  python3-gi-cairo 3.42.2-3+b1
ii  python3-idna 2.8-1
ii  python3-keyring  23.9.3-2
ii  python3-nbxmpp   4.5.3-1~bpo12+1
ii  python3-omemo-dr 1.0.1-2~bpo12+1
ii  python3-packaging19.1-2
ii  python3-pil  9.4.0-1.1+b1
ii  python3-precis-i18n  1.0.5-2
ii  python3-qrcode   7.4.2-2

Versions of packages gajim recommends:
ii  alsa-utils1.2.4-1
ii  aspell-en [aspell-dictionary] 2018.04.16-0-1
ii  ca-certificates   20190110
ii  dbus  1.12.20-2
pn  fonts-noto-color-emoji
pn  gajim-openpgp 
pn  gir1.2-ayatanaappindicator3-0.1   
pn  gir1.2-farstream-0.2  
pn  gir1.2-geoclue-2.0
pn  gir1.2-gsound-1.0 
pn  gir1.2-gspell-1   
ii  gir1.2-gstreamer-1.0  1.22.0-2
pn  gir1.2-secret-1   
pn  gstreamer1.0-gl   
pn  gstreamer1.0-nice 
ii  gstreamer1.0-plugins-ugly 1:1.16.2-dmo2
ii  lxqt-notificationd [notification-daemon]  1.2.0-1
pn  python3-dbus  
pn  python3-gssapi
pn  python3-sentry-sdk
ii  sox   14.4.2+git20190427-2

Versions of packages gajim suggests:
ii  libxss1  1:1.2.3-1
pn  nautilus-sendto  

-- no debconf information

Bug#1031956: ausweisapp2: App starts hidden in the background on gnome-shell + appindicator

[Richard]

I second this report. The app did use to work actually, but recently - not
sure with transitioning to ausweisapp with v2.0 or later, this breaks for
me too. This renders the app completely unusable, at least using Gnome,
which should justify a severity of important. It's quite irrelevant if the
app is a Gnome, Gt or whatever app. Like any app, if it's included in
Debian it should not be broken beyond usability. Sure, the newer version
right now is only available in testing and sid (tested both, same result).
But that just makes it more important that this is sorted out before this
package is made available in stable or stable-backports. Especially since
running it as Flatpak would probably render half the app unusable since the
communication with the browser would probably not work.

Bug#1060855: RM: nxcl -- RoQA; orphaned; dead upstream

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: n...@packages.debian.org, alexandre.deti...@gmail.com
Control: affects -1 + src:nxcl

Please remove nxcl from the archive. It is orphaned since 2014 and dead 
upstream.
It also has a very low popcon, so it is most probably unused.
With nx-libs, there is a maintained alternative.

Am 15.01.24 um 12:14 schrieb Alexandre Detiste:

$ apt rdepends libnxcl1
libnxcl1
Reverse Depends:
   Depends: libnxcl-dev (= 0.9-3.1+b1)
   Depends: libnxcl-bin

https://qa.debian.org/popcon.php?package=nxcl

Bug#1060854: reportbug: @example.com is rejected

[Askar Safin]

Package: reportbug
Version: 12.0.0
Severity: normal

When I try to specify a...@example.com as my email address, it is rejected.
I don't like this. Such addresses should be supported. They are good
for testing "reportbug" util.

Full log:

# reportbug
Welcome to reportbug!  Since it looks like this is the first time you have used 
reportbug, we are configuring its behavior.  These settings will be saved to 
the file "/root/.reportbugrc", which you will be
free to edit further.
Please choose the default operating mode for reportbug.

1 noviceOffer simple prompts, bypassing technical questions.

2 standard  Offer more extensive prompts, including asking about things that a 
moderately sophisticated user would be expected to know about Debian.

3 advanced  Like standard, but assumes you know a bit more about Debian, 
including "incoming".

4 expertBypass most handholding measures and preliminary triage routines. 
This mode should not be used by people unfamiliar with Debian's policies and 
operating procedures.

Select mode: [novice] 3
Will reportbug often have direct Internet access? (You should answer yes to 
this question unless you know what you are doing and plan to check whether 
duplicate reports have been filed via some other channel.)
[Y|n|q|?]? 
What real name should be used for sending bug reports?
[root]> a
Which of your email addresses should be used when sending bug reports? (Note 
that this address will be visible in the bug tracking system, so you may want 
to use a webmail address or another address with good
spam filtering capabilities.)
[root@fc2e0df8e121]> a...@example.com
Your email address is not valid; please try another one.
Which of your email addresses should be used when sending bug reports? (Note 
that this address will be visible in the bug tracking system, so you may want 
to use a webmail address or another address with good
spam filtering capabilities.)
[root@fc2e0df8e121]> a...@exammppllee.com
Do you have a "mail transport agent" (MTA) like Exim, Postfix or SSMTP 
configured on this computer to send mail to the Internet [y|N|q|?]?



-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /root/.reportbugrc:
reportbug_version "12.0.0"
mode advanced
ui text
realname "Askar Safin"
email "safinas...@gmail.com"
no-check-uid
no-cc
list-cc-me
smtphost reportbug.debian.org

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

Kernel: Linux 5.10.0-0.deb9.24-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages reportbug depends on:
ii  apt2.7.7
ii  python33.11.4-5+b1
ii  python3-reportbug  12.0.0
ii  sensible-utils 0.0.20

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
ii  debconf   1.5.82
pn  debsums   
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.45-2
ii  gnupg 2.2.40-1.1
pn  python3-urwid 
pn  reportbug-gtk 
pn  xdg-utils 

Versions of packages python3-reportbug depends on:
ii  apt2.7.7
ii  file   1:5.45-2
ii  python33.11.4-5+b1
ii  python3-apt2.7.0
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.2
ii  python3-requests   2.31.0+dfsg-1
ii  sensible-utils 0.0.20

python3-reportbug suggests no packages.

-- no debconf information

Bug#1059576: geophar: please make the build reproducible

[James Addison]

Source: geophar
Followup-For: Bug #1059576
X-Debbugs-Cc: georges.khazna...@orange.fr

Ok, thanks Georges.

Please note: there is a possible bug with reprotest reported on Salsa CI[1]
that means that reprotest does not vary the timezone between its comparison
builds.

If you begin seeing reprotest failing for geophar again in future due to
changelog date timezone problems, then the fix from this bug may help.

[1] - https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/309

Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)

[Simon Josefsson]

Shengjing Zhu  writes:

>> https://salsa.debian.org/jas/golang-github-sigstore-rekor/-/jobs/5160982
>>
>> src/github.com/sigstore/rekor/cmd/backfill-redis/main.go:44:2:
>> cannot find package "sigs.k8s.io/release-utils/version" in any of:
>> /usr/lib/go-1.21/src/sigs.k8s.io/release-utils/version (from $GOROOT)
>> 
>> /builds/jas/golang-github-sigstore-rekor/debian/output/source_dir/_build/src/sigs.k8s.io/release-utils/version
>> (from $GOPATH)
>>
>> Use is here:
>>
>> https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L44
>
> Hmm, then this library is needed.
>
> However I just checked the code in sigs.k8s.io/release-utils/version,
> I'm afraid it's not compatible with how we build Go binaries in
> Debian.
> We don't have any VCS info when building the binaries. And we use
> GOPATH mde as well. So the Go compiler can't inject any version info
> in the binaries.
> This code 
> https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L103
> would probably just print "unknown, unknown"...

Can we patch rekor to not use sigs.k8s.io?  Deciding matters like that
is a bit beyond my focus right now, but very happy to discuss and take
advice (or patches) here.

That sigs.k8s.io/release-utils package needs the following dependencies
that we wouldn't have to package if we can someohow get rid of it as a
depedency for rekor.

https://salsa.debian.org/jas/golang-k8s-sigs-release-utils/-/jobs/5161034

src/sigs.k8s.io/release-utils/mage/cosign.go:24:2: cannot find package 
"github.com/uwu-tools/magex/pkg" in any of:
src/sigs.k8s.io/release-utils/version/version.go:30:2: cannot find package 
"github.com/common-nighthawk/go-figure" in any of:

/Simon


signature.asc
Description: PGP signature

Bug#1060774: bullseye-pu: netatalk/3.1.12~ds-8+deb11u2

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2024-01-14 at 06:23 +, Daniel Markstedt wrote:
> CVE-2022-22995
> Ref. advisory: https://netatalk.sourceforge.io/CVE-2022-22995.php
> 
> The attached patch can be applied to Debian oldstable to address the
> vulnerability.
> 

In order to approve an upload, we need to see a full source debdiff of
the proposed new package, not just the isolated patch. Please remove
the moreinfo tag when providing that.

> I'm proposing an oldstable out-of-release-cycle upload: 3.1.12~ds-
> 8+deb11u2

I'm not entirely sure what you mean by an "out-of-release-cycle upload"
here.

Regards,

Adam

Bug#725312: Ohai does not detect python3

[Vivek K J]

Hello,

It appears that this is not a bug. Ohai is identifying the presence of
Python by executing the command[1]:

python -c "import sys; print(sys.version)"


However, this method does not detect python3. To address this issue, a
workaround would be to install the python-is-python3 package.



[1] -
https://github.com/chef/ohai/blob/6d64237f9987c3bf51805e19884e6e710c3a40f6/lib/ohai/plugins/python.rb#L26


-- 
Regards,

Vivek K J
Debian Maintainer
---
 .''`.
Personal Website:  https://vivekkj.in   : :'  :
GPG Key: D017 9263 E202 0E40 7157  4073 A5FF 4BB3 EA53 C5DF `. `'`
  `-

OpenPGP_0xA5FF4BB3EA53C5DF.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060853: ITP: golang-github-sigstore-protobuf-specs -- Sigstore Protocol Buffer code (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-sigstore-protobuf-specs
  Version : 0.2.1-1
  Upstream Author : sigstore
* URL : https://github.com/sigstore/protobuf-specs
* License : Apache-2.0
  Programming Lang: Go
  Description : Sigstore Protocol Buffer code (library)

 This repository holds protobuf specifications for Sigstore messages.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-github-sigstore-protobuf-specs

/Simon


signature.asc
Description: PGP signature

Bug#1060785: libspa-audioconvert: Crash sometimes due to misaligned load to YMM register.

[Dylan Aïssi]

Hi Ohta,

Le dim. 14 janv. 2024 à 10:24, Kyuma Ohta
 a écrit :
>
> Sometimes ...mostly be load growth a lot..., pipe-wire daemon or
> pipewire-pulse daemon crashes with below message [1].
>
> This happens misalign of loading to YMM register [2][3].
>
> This crash seems to happen at "vlddqu -0x20(%rcx),%ymm2" [2],
> this need align at 256bit (but, Older Ryzen may be need only align of
> 128bit).
> But, RCX register didn't align of 256bits [3].
> Value is 0x5650f98e99c4 .
>
> So, software related libspa-audioconvert crashes sometime and randomly.
> I think.

Thank you for this bug report. May I ask you to forward it upstream?
at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

Thank you!
Best regards,
Dylan

Bug#1060852: ITP: golang-bitbucket-creachadair-shell -- implements basic shell command-line splitting for Go (library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-bitbucket-creachadair-shell
  Version : 0.0.8-1
  Upstream Author : Michael J. Fromberger
* URL : https://bitbucket.org/creachadair/shell/
* License : BSD-3-Clause
  Programming Lang: Go
  Description : implements basic shell command-line splitting for Go 
(library)

 Provides supports for splitting and joining of shell command strings.
 .
 The Split function divides a string into whitespace-separated fields,
 respecting single and double quotation marks as defined by the Shell Command
 Language section of IEEE Std 1003.1 2013.  The Quote function quotes
 characters that would otherwise be subject to shell evaluation, and the Join
 function concatenates quoted strings with spaces between them.

I hope to maintain this package as part of Debian Go Packaging Team:

https://salsa.debian.org/go-team/packages/golang-bitbucket-creachadair-shell/

/Simon


signature.asc
Description: PGP signature

Bug#1060851: bookworm-pu: package pypdf/3.4.1-1

[Scott Kitterman]

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

(Please provide enough information to help the release team
to judge the request efficiently. E.g. by filling in the
sections below.)

[ Reason ]
This upload adds a patch to address CVE-2023-36464.  It was assessed by
the security team as no-dsa, so I think we ought to fix it in a stable
update.

[ Impact ]
Users remain vulnerable to the DoS attack described in the CVE.

[ Tests ]
There is a pypdf test suite that runs during package build and
autopkgtest.  Upstream did add a test for this issue, but since it
requires test assets not available in Debian, I did not include it in
the patch.

[ Risks ]
Code is trivial and the risk of regression is negligible.  This is the
exact fix upstream used.  The fix has been in the wild for 8 months, so
I think if it was going to cause a problem, we'd know by now.

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

[ Changes ]
Added the upstream change to fix the CVE (only the change to
pypdf/generic/_data_structures.py is relevant):
https://github.com/py-pdf/pypdf/commit/b0e5c689df689ab173df84dacd77b6fc3c161932

Updated gbp.conf to point at the bookworm branch

[ Other info ]
This will look like an NMU in tools that look at stable.  I just adopted
the package due to the original maintainer's RFA and have uploaded to
unstable (including this fix).  I elected not to change the maintainer
in this upload since that didn't fit with a minimal change in stable.

Scott K
diff -Nru pypdf-3.4.1/debian/changelog pypdf-3.4.1/debian/changelog
--- pypdf-3.4.1/debian/changelog2023-02-14 16:58:00.0 -0500
+++ pypdf-3.4.1/debian/changelog2024-01-15 11:28:43.0 -0500
@@ -1,3 +1,13 @@
+pypdf (3.4.1-1+deb12u1) bookworm; urgency=medium
+
+  * Update debian/gbp.conf to point at bookworm branch
+  * Prevent infinite loop when no character follows after a comment (Closes:
+#1040338)
+- Addresses CVE-2023-36464
+- Add d/p/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch
+
+ -- Scott Kitterman   Mon, 15 Jan 2024 11:28:43 -0500
+
 pypdf (3.4.1-1) unstable; urgency=medium
 
   * New upstream version 3.4.1
diff -Nru pypdf-3.4.1/debian/gbp.conf pypdf-3.4.1/debian/gbp.conf
--- pypdf-3.4.1/debian/gbp.conf 2023-02-14 16:58:00.0 -0500
+++ pypdf-3.4.1/debian/gbp.conf 2024-01-15 11:28:20.0 -0500
@@ -1,3 +1,3 @@
 [DEFAULT]
-debian-branch = debian/unstable
+debian-branch = debian/bookworm
 pristine-tar = True
diff -Nru 
pypdf-3.4.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch
 
pypdf-3.4.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch
--- 
pypdf-3.4.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch
  1969-12-31 19:00:00.0 -0500
+++ 
pypdf-3.4.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch
  2024-01-15 11:28:43.0 -0500
@@ -0,0 +1,21 @@
+From: Scott Kitterman 
+Date: Mon, 15 Jan 2024 11:34:11 -0500
+Subject: Prevent infinite loop when no character follows after a comment
+https://security-tracker.debian.org/tracker/CVE-2023-36464
+---
+ pypdf/generic/_data_structures.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/pypdf/generic/_data_structures.py 
b/pypdf/generic/_data_structures.py
+index bb2e028..524d4e0 100644
+--- a/pypdf/generic/_data_structures.py
 b/pypdf/generic/_data_structures.py
+@@ -979,7 +979,7 @@ class ContentStream(DecodedStreamObject):
+ # encountering a comment -- but read_object assumes that
+ # following the comment must be the object we're trying to
+ # read.  In this case, it could be an operator instead.
+-while peek not in (b"\r", b"\n"):
++while peek not in (b"\r", b"\n", b""):
+ peek = stream.read(1)
+ else:
+ operands.append(read_object(stream, None, 
self.forced_encoding))
diff -Nru pypdf-3.4.1/debian/patches/series pypdf-3.4.1/debian/patches/series
--- pypdf-3.4.1/debian/patches/series   2023-02-14 16:58:00.0 -0500
+++ pypdf-3.4.1/debian/patches/series   2024-01-15 11:28:43.0 -0500
@@ -1,2 +1,3 @@
 0001-Use-formal-Cryptodome-namespace.patch
 0002-mark-new-external-tests-appropriately.patch
+0003-Prevent-infinite-loop-when-no-character-follows-afte.patch

Bug#1053472: starts w/o writing pid file, leading systemd to kill it

[Joey Hess]

Correction: Not the default configuration per se, just the configuration
that is necessary to interoperate with the default (chrooted) 
configuration of postfix.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (2024-01-14 18:33:14)
>   The partition table has been altered.
>   Syncing disks.
>   $ echo $?
>   0
>   $ ls -lF --si sid_amd64.img 
>   -rw-r-xrwx 1 $USER $USER 670M Jan 14 17:21 sid_amd64.img*
> 
> However, if I attempt to use the resulting image, autopkgtest
> fails:
> 
>   $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out  --summary 
> ./${SRCPKG}_autopkgtest.summary --apt-upgrade -B ./${SRCPKG}_amd64.changes -- 
> qemu --overlay-dir /dev/shm ~/Downloads/sid_amd64.img
>   autopkgtest [17:27:29]: starting date and time: 2024-01-14 17:27:29+0100
>   autopkgtest [17:27:29]: version 5.32
>   autopkgtest [17:27:29]: host ${HOST}; command line: /usr/bin/autopkgtest 
> --output-dir './${SRCPKG}_autopkgtest.out' --summary 
> './${SRCPKG}_autopkgtest.summary' --apt-upgrade -B 
> './${SRCPKG}_amd64.changes' -- qemu --overlay-dir /dev/shm 
> ${HOME}/Downloads/sid_amd64.img
>   qemu-system-x86_64: terminating on signal 15 from pid 115770 
> (/usr/bin/python3)
>   : failure: timed out waiting for 'login prompt on serial 
> console'
>   autopkgtest [17:28:29]: ERROR: testbed failure: unexpected eof from the 
> testbed
> 
> 
> Was it just a test to investigate further?
> Or did it have a chance to produce a usable image?

The qemu image you built uses efi booting. Try to add --boot=efi. The default
is --boot=auto which chooses bios boot on amd64.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1056673: [Help] Re: build-depends on atlas, which is obsolete and scheduled for removal

[Sébastien Villemot]

Control: tags -1 + patch

Hi Andreas,

Le jeudi 11 janvier 2024 à 17:52 +0100, Andreas Tille a écrit :
> Control: tags -1 help
> 
> Hi Sébastien,
> 
> I tried my luck in Git[1] but this is obviously not sufficient to port
> to LAPACKE[2].  I'd be really happy if you could spent some of your
> valuable time on this issue as you managed with emmax for intance.

I have made a merge request that fixes the build against LAPACKE:
https://salsa.debian.org/med-team/ghmm/-/merge_requests/1

Note that I verified that it builds correctly, but not that it delivers
correct results at runtime.

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



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

Bug#1060850: jtdx: FTBFS on armel: Error: bad immediate value for offset (4096)

[Emanuele Rocca]

Source: jtdx
Version: 2.2.159-1
Severity: serious
Tags: ftbfs, patch
User: debian-...@lists.debian.org
Usertags: 32bit-stackclash

Dear Maintainer,

jtdx currently fails to build from source on armel. To address the
immediate issue, please disable stack-clash-protection with the
following snippet in debian/rules:

  ifeq ($(DEB_TARGET_ARCH),armel)
export DEB_BUILD_MAINT_OPTIONS = hardening=-stackclash
  endif

The error message is:

/tmp/ccWOfy1w.s: Assembler messages:
/tmp/ccWOfy1w.s:51: Error: bad immediate value for offset (4096)
make[3]: *** [CMakeFiles/wsjt_fort_omp.dir/build.make:2802: 
CMakeFiles/wsjt_fort_omp.dir/lib/sync8.f90.o] Error 1
make[3]: *** Waiting for unfinished jobs

Full build logs at:
http://qa-logs.debian.net/2024/01/11/armel/jtdx_2.2.159-1_unstable-armel.log

Bug#1056116: llvm-toolchain-17 ftbfs on mips64el

[Simon McVittie]

Control: forwarded -1 https://github.com/llvm/llvm-project/pull/76894

On Fri, 17 Nov 2023 at 16:31:24 +0800, YunQiang Su wrote:
> On Fri, Nov 17, 2023 at 09:28:38AM +0100, Sylvestre Ledru wrote:
> > We (llvm) moved to github for contributions
> > 
> > please move [https://reviews.llvm.org/D158491] on this platform
>
> The red banner on Phabricator tells us don't do so.

This situation seems to have changed. The LLVM Phabricator now has a banner
that reads:

This is an archive of the discontinued LLVM Phabricator instance

and pull requests seem to be happening in
.

Please could the MIPS porting team follow up on this, responding to prior
review in https://reviews.llvm.org/D158491 where appropriate? This has
been holding back migration of important packages like mesa for quite
a long time.

It looks as though https://github.com/llvm/llvm-project/pull/76894 might be
the new upstream location for this change. Is that correct? If not, please
adjust bug metadata as necessary.

Thanks,
smcv

Bug#1060779: src:mesa: fails to migrate to testing for too long: unavailable Build-Depends on mips64el

[Simon McVittie]

On Sun, 14 Jan 2024 at 08:39:52 +0100, Paul Gevers wrote:
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:mesa has been trying to migrate for 31 days [2].
> Hence, I am filing this bug. The version in unstable build depends on
> binaries from llvm-toolchain-17, which haven't been built on mips64el yet
> (reported in bug 1056116).

Adding mips64el porting team to Cc for visibility.

Mesa could probably work around this by disabling the LLVM parts on
mips64el (removing mips64 from LLVM_ARCHS in d/rules and from various
lists of LLVM-capable architectures in d/control).

The cost would be that most mips64el users would have to use slow
fallback software rendering, because disabling LLVM support would
disable llvmpipe (which it seems doesn't actually work properly
on mips* in any case) but also the AMD driver (which is what
graphical MIPS users rely on in practice, according to discussion on
https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/71).

That's a high cost for mips64el users, but the alternative seems to be
letting mips64el hold back all of our other architectures, and I don't
think that's really viable.

Thanks,
smcv

Bug#1056680: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#1056680: fixed in odin 2.0.5-4)

[Andreas Tille]

Hi Sébastien,

Am Mon, Jan 15, 2024 at 04:40:48PM +0100 schrieb Sébastien Villemot:
> Note that libatlas-base-dev is still listed as an alternative
> dependency of odin.

Argh, I did not checked for *-dev package in binary package depends ...
Its just fixed by new upload.
 
> This does not prevent the removal of src:atlas, so I’m not reopening
> this bug, but you might still want to fix this.

Status from my side.  Our outreachy student is just crafting an
autopkgtest for ghmm which is the last remaining package of Debian Med
team that needs liblapack-dev.  Once we have a sensible test we'd
probably need your help to finalise the port to lapacke which I tried in
a currently deactivated patch in Git.  The patch is not complete and we
deactivated it for the moment to know the intended behaviour of the
original code first and than see whether the port to lapacke will
behave identically.

Kind regards
   Andreas.

[1] 
https://salsa.debian.org/med-team/ghmm/-/blob/master/debian/patches/lapacke.patch?ref_type=heads

-- 
http://fam-tille.de

Bug#1060849: mesa: FTBFS on armel: static assertion failed: "vn_ring_shared requires lock-free 32-bit atomic_uint"

[Simon McVittie]

Source: mesa
Version: 23.3.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-...@lists.debian.org
User: debian-...@lists.debian.org
Usertags: armel
Control: block 1060779 by -1

The armel baseline does not have lock-free atomic operation opcodes. The
result is a build failure:

https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=armel&ver=23.3.3-1&stamp=1705055313&raw=0
> In file included from ../src/util/u_math.h:43,
>  from ../src/virtio/vulkan/vn_common.h:35,
>  from ../src/virtio/vulkan/vn_buffer.h:14,
>  from ../src/virtio/vulkan/vn_buffer.c:11:
> ../src/virtio/vulkan/vn_ring.h:40:1: error: static assertion failed: 
> "vn_ring_shared requires lock-free 32-bit atomic_uint"
>40 | static_assert(ATOMIC_INT_LOCK_FREE == 2 && sizeof(atomic_uint) == 4,

Could this perhaps be solved by disabling the virtio driver on armel?

Thanks,
smcv

Bug#1060838: meson: should use the host gobject-introspection-1.0.pc for looking up g-ir-scanner

[Simon McVittie]

On Mon, 15 Jan 2024 at 14:32:44 +0100, Helmut Grohne wrote:
> On Mon, Jan 15, 2024 at 12:38:54PM +, Simon McVittie wrote:
> > in general the
> > host g-ir-scanner will not even be executable during a cross-build
> 
> I question this. g-ir-scanner is written in Python and it is fairly
> unlikely that /usr/bin/python3 will end up being the host Python that
> cannot be run. Hence using the g-ir-scanner from the host typically
> should work (or not) the same way as the one from the build

If it was pure Python, then this would be
true, but it loads a private module written in C
(/usr/lib/*/gobject-introspection/giscanner/_giscanner.cpython-311-*.so)
and that module needs to match the architecture of the python3
interpreter.

The result is that g-ir-scanner has two orthogonal architecture
dependencies:

1. It needs to be loading a _giscanner module whose
   architecture matches python3: in practice this means adding
   /usr/lib/${DEB_BUILD_MULTIARCH}/gobject-introspection to sys.path
2. Meanwhile it also needs to be using a $CC, $PKG_CONFIG, and search
   paths that are appropriate for ${DEB_HOST_MULTIARCH}, and eventually
   run a temporary host-architecture dumper binary, possibly via qemu

This makes it "the same shape" as gcc or ld, which are build-architecture
executables that have host-architecture object code as their
input/output. Unlike gcc, there is no built-in upstream way to build
a cross-g-ir-scanner analogous to a cross-compiler, and there does not
seem to be any interest in adding that upstream, which is why I had to
do this as a Debian-specific change.

However, reasoning similar to what's quoted above *does* work for tools
like gdbus-codegen, which *is* pure Python, avoiding the first of those
architecture dependencies. (As it happens, gdbus-codegen also operates
at the level of source code rather than binaries, so it avoids the second
architecture dependency too.)

smcv

Bug#1058127: python-mpiplus: FTBFS: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?

[Andrius Merkys]

Hi Yogeswaran,

On 2024-01-14 18:46, Yogeswaran Umasankar wrote:

I created a patch for fixing AttributeError: module 'configparser' has
no attribute 'SafeConfigParser'. In the process I have updated it to the
latest upstream too. I’ve attached the debdiff for you to check out.


I noticed you have hard-coded the version number in setup.py. I would 
suggest against doing that as maintainer(s) will have to refresh this 
patch each time a new upstream release is imported. Manual tasks tend to 
be easily overlooked.


I think a better fix would be to use versioneer packaged in Debian 
package python3-versioneer, although I have not tried that.


Best wishes,
Andrius

Bug#1060848: rust-isahc: Autopkgtest failures

[Matthias Geiger]

Source: rust-isahc
Version: 1.7.2+ds-24
Severity: serious
Justification: fails to migrate to testing
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

See
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-isahc/40410753/log.gz.

snip:

842s error: cannot determine resolution for the macro `mock`
842s--> tests/redirects.rs:268:9
842s |
842s 268 | mock! {
842s | 
842s |
842s = note: import resolution is stuck, try simplifying macro imports
842s 
842s error: cannot determine resolution for the macro `mock`
842s--> tests/redirects.rs:292:14
842s |
842s 292 | let m2 = mock! {
842s |  
842s |
842s = note: import resolution is stuck, try simplifying macro imports
842s 
842s error: cannot determine resolution for the macro `mock`
842s--> tests/redirects.rs:300:14
842s |
842s 300 | let m1 = mock! {
842s |  
842s |
842s = note: import resolution is stuck, try simplifying macro imports
842s 
842s error: could not compile `isahc` due to 3 previous errors
==

This blocks testing migration for rust-transmission-client, please fix
isahc accordingly.

best,

werdahias


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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 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: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmWlU6EVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1/BAQAK4PodKtnigscZNZi9NpEEDs56rT
qsheNo3a6AzaN/3uwpjfcN7otzMxarKmS+oPgNoEDId9q4zlS0zRAAL95jT2XrSq
VayXKyGJuiU0dw6V6J4wdjjBGDAs/NgSxNSaGnrKPOjDyLUgyJunp7iW/6Oiec6p
UnfTMx8RtuJbVICtpocvLr5RsDFfusRAlncnKZ5m3sILqPAQizTyohoy3/BJRSfh
aLmefKNvLikVSUYiwIeccG+Fyclp+O+LfNroMfHNbbEJHy0UMXZaYWZmfn/nD7F5
Id6wkBxYnckV5JXZ4xRMCBHq8cPHQMQOfLe0HOZEvFkAxBEICGs8nkbLb+HWup/1
ZczOX4thxoTqSypVI3ZuFFN3c3LWUFEzeOuWjcJsy+1vIa8Kp+Ivk0P3wzMp/DNj
AVMfsUE5pB5QjQ5lU4uCK43nPXSuElmhNAyMsow3+dxSpA/hwig+pmq9DMLbLVYf
75suhPWYx4UeVbrLEmY82dDT4kPOa8FdzmOxvN/z9JDD6MOPerynU+CqAlgzQvdm
lQNfPdbBLF2ZB73UP5YL+3GxfmSM0o15xR19REfs2aZf81GzBL2+OSW2s7efMo2t
p3xGjz2j9Osf8qMz7FuiAyidKRBhGstpZx6B3erPHm5pSKijrM+l/rKNW3jBh20i
NYzu/ciejRBoGBjf
=ccy6
-END PGP SIGNATURE-

Bug#1054974: behave: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andrius Merkys]

Hi,

On 2024-01-15 17:34, Christoph Berg wrote:

Re: Andrius Merkys

The patch proposed in #1042610 does not fix test failure. Interestingly, the
failure seems to be nondeterministic: after patching #1042610 some builds
succeed. However, I did not manage to find the root cause.


The difference between a working and a failing run is this diff:

 dh_auto_test -O--buildsystem=pybuild
-I: pybuild base:305: cd 
/home/myon/debian/nmu/behave/behave/.pybuild/cpython3_3.12_behave/build; 
python3.12 -m pytest test
+I: pybuild base:305: cd 
/home/myon/debian/nmu/behave/behave/.pybuild/cpython3_3.12_behave/build; 
python3.12 -m pytest tests

I.e. pybuild invokes either
"python3.12 -m pytest test" (good)
or "python3.12 -m pytest tests" (bad)


Great catch! I tried diff'ing working and failing buildlogs as well, but 
probably was not that attentive to spot this.



I tried to drill down where this decision is made but couldn't spot
it.


This might be a bug in dh-python.


As a workaround, we can move the "tests" directory aside. Then it will
reliably run the "test" target. (Not pretty, but I want to get the
package unstuck.)


Yes, this makes sense.

Best,
Andrius

Bug#1056680: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#1056680: fixed in odin 2.0.5-4)

[Sébastien Villemot]

Le jeudi 11 janvier 2024 à 17:39 +, Debian Bug Tracking System a
écrit :
> This is an automatic notification regarding your Bug report
> which was filed against the src:odin package:
> 
> #1056680: (build-)depends on atlas, which is obsolete and scheduled for 
> removal
> 
> It has been closed by Debian FTP Masters  
> (reply to Andreas Tille ).

Thanks for fixing this bug.

Note that libatlas-base-dev is still listed as an alternative
dependency of odin.

This does not prevent the removal of src:atlas, so I’m not reopening
this bug, but you might still want to fix this.

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



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

Bug#1054974: behave: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Christoph Berg]

Re: Andrius Merkys
> The patch proposed in #1042610 does not fix test failure. Interestingly, the
> failure seems to be nondeterministic: after patching #1042610 some builds
> succeed. However, I did not manage to find the root cause.

The difference between a working and a failing run is this diff:

dh_auto_test -O--buildsystem=pybuild
-I: pybuild base:305: cd 
/home/myon/debian/nmu/behave/behave/.pybuild/cpython3_3.12_behave/build; 
python3.12 -m pytest test
+I: pybuild base:305: cd 
/home/myon/debian/nmu/behave/behave/.pybuild/cpython3_3.12_behave/build; 
python3.12 -m pytest tests

I.e. pybuild invokes either
   "python3.12 -m pytest test" (good)
or "python3.12 -m pytest tests" (bad)

I tried to drill down where this decision is made but couldn't spot
it.

As a workaround, we can move the "tests" directory aside. Then it will
reliably run the "test" target. (Not pretty, but I want to get the
package unstuck.)

Christoph

Bug#988164: rdiff-backup: obsolete conffile not removed

[Sébastien Villemot]

Le vendredi 12 janvier 2024 à 15:06 -0800, Otto Kekäläinen a écrit :
> Thanks Sebastien for bringing this up. Would you like to file a MR at
> https://salsa.debian.org/python-team/packages/rdiff-backup/-/merge_requests
> to get this fixed?

Done in:
https://salsa.debian.org/python-team/packages/rdiff-backup/-/merge_requests/3

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



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

Bug#1055515: ldc: diff for NMU version 1:1.35.0-1.1

[Gianfranco Costamagna]

Control: tags 1055515 + patch
Control: tags 1055515 + pending

Dear maintainer,

I've prepared an NMU for ldc (versioned as 1:1.35.0-1.1) and
uploaded it to DELAYED/15. Please feel free to delete it from queue if
you think it isn't useful.

Regards.

Gianfranco

diff -Nru ldc-1.35.0/debian/changelog ldc-1.35.0/debian/changelog
--- ldc-1.35.0/debian/changelog 2023-11-04 18:40:54.0 +0100
+++ ldc-1.35.0/debian/changelog 2023-11-07 16:15:22.0 +0100
@@ -1,3 +1,11 @@
+ldc (1:1.35.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Add bash-completion dependency to let cmake helper do the right job
+(Closes: #1055515)
+
+ -- Gianfranco Costamagna   Tue, 07 Nov 2023 
16:15:22 +0100
+
 ldc (1:1.35.0-1) unstable; urgency=medium

   [ Matthias Klumpp ]
diff -Nru ldc-1.35.0/debian/control ldc-1.35.0/debian/control
--- ldc-1.35.0/debian/control   2023-11-04 18:40:54.0 +0100
+++ ldc-1.35.0/debian/control   2023-11-07 16:15:22.0 +0100
@@ -4,7 +4,8 @@
 Maintainer: Debian D Language Group 
 Uploaders: Konstantinos Margaritis ,
Matthias Klumpp 
-Build-Depends: cmake,
+Build-Depends: bash-completion,
+   cmake,
debhelper-compat (= 12),
dh-exec,
gdmd,


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060847: planets: Typo in package description

[Sam Lee]

Package: planets
Version: 0.1.13-20+b5
Severity: minor

There is a minor typo in the package's description. Excerpt from `apt-cache show
planets`:

"The user interface is aimed at being simple enough for a fairly young
 kid to enjoy it, their is a special kid-mode for this purpose."

Notice that "their" should be "there" instead. Fixed sentence:

"The user interface is aimed at being simple enough for a fairly young
 kid to enjoy it. There is a special kid-mode for this purpose."


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

Bug#1060846: freecad: Include fcinfo script in the built package

[Nicolas Peugnet]

Package: freecad
Version: 0.20.2+dfsg1-4
Severity: wishlist

Dear Maintainer,

It would be convenient if the freecad binary package (or the maybe the
freecad-python3 one) included the `fcinfo` python script [1].
This tool is recomended in FreeCAD's wiki as a way to view
human-readable diffs of .FCStd files [2]. It does not have to be in the
path, though I think it could be useful.

[1] https://github.com/FreeCAD/FreeCAD/blob/main/src/Tools/fcinfo
[2] 
https://wiki.freecad.org/WebTools_Git#Enabling_human-readable_diffs_for_FCStd_files_with_the_fcinfo_utility

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

Kernel: Linux 6.1.0-13-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=fr_FR.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 freecad depends on:
ii  freecad-python3  0.20.2+dfsg1-4

Versions of packages freecad recommends:
ii  calculix-ccx  2.20-1
ii  graphviz  2.42.2-7+b3

Versions of packages freecad suggests:
pn  povray  

-- no debconf information

Bug#1060845: ghostscript: Add AppArmor profile

[Sam Lee]

Package: ghostscript
Version: 10.0.0~dfsg-11+deb12u3
Severity: wishlist

Please consider shipping an AppArmor profile in the "ghostscript" package.  It
might be prudent to add an AppArmor profile to reduce the potential damage of
Ghostscript bugs because:

1. Ghostscript is commonly used to process untrusted input (e.g. before PDF
   files are sent to a printer).
2. A relatively large number of security vulnerabilities have been found in
   Ghostscript over the years [1].

[1]: https://security-tracker.debian.org/tracker/source-package/ghostscript


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

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

Versions of packages ghostscript depends on:
ii  libc6    2.36-9+deb12u3
ii  libgs10  10.0.0~dfsg-11+deb12u3

ghostscript recommends no packages.

ghostscript suggests no packages.

-- no debconf information

Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)

[Shengjing Zhu]

On Mon, Jan 15, 2024 at 8:51 PM Simon Josefsson  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Simon Josefsson 
>
> * Package name: golang-github-adamkorcz-go-fuzz-headers-1
>   Version : 0.0~git20230919.8b5d3ce-1
>   Upstream Author : Adam Korcz 
> * URL : https://github.com/AdamKorcz/go-fuzz-headers-1
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : helper functions for Go fuzzing (library)
>
>  Various helper functions for go fuzzing. It is mostly used in combination
>  with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with
>  fuzzing in the standard library will also be supported. Any coverage guided
>  fuzzing engine that provides an array or slice of bytes can be used with
>  go-fuzz-headers.
>  .
>  go-fuzz-headers' approach to fuzzing structs is strongly inspired by
>  gofuzz (https://github.com/google/gofuzz).
>
> I hope to maintain this package as part of Debian Go Packaging Team:
>
> https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/
>

Usually we don't run fuzz test when building packages, because it
would waste a lot of buildd resource.

In theory we don't need any fuzz related libraries. But upstream may
mix their unit tests and fuzz tests in one source file, which makes it
difficult to strip such tests and their libraries.
The Go compiler by default wouldn't run fuzz tests.

For packaging rekor, I think all these fuzz tests can be stripped by
file names. It seems upstream just puts all fuzz tests in
"fuzz_test.go".

-- 
Shengjing Zhu

Bug#1060844: paryfor: please add support for riscv64 build

[Bo YU]

Source: paryfor
Version: 0.1-5
Severity: wishlist
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

The package fail to build on riscv64 in the past:
https://buildd.debian.org/status/logs.php?pkg=paryfor&arch=riscv64

But now the package can be built on riscv64 from upstream support:
https://github.com/ekg/paryfor/commit/2383b62f53175950a5fcd75bdf6d68774311b496

I can built it on my local riscv64 hardware with the commit, so could
you include it on next upload?

Please let me know any issues.

-- 
Regards,
--
  Bo YU

diff -Nru paryfor-0.1/debian/changelog paryfor-0.1/debian/changelog
--- paryfor-0.1/debian/changelog2022-11-28 04:38:43.0 +0800
+++ paryfor-0.1/debian/changelog2024-01-15 15:36:05.0 +0800
@@ -1,3 +1,10 @@
+paryfor (0.1-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support riscv64 build. (Closes: #-1)
+
+ -- Bo YU   Mon, 15 Jan 2024 15:36:05 +0800
+
 paryfor (0.1-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru paryfor-0.1/debian/patches/series paryfor-0.1/debian/patches/series
--- paryfor-0.1/debian/patches/series   2022-11-28 04:38:43.0 +0800
+++ paryfor-0.1/debian/patches/series   2024-01-15 15:32:58.0 +0800
@@ -1 +1,2 @@
 Fix-compilation-flags.patch
+support_riscv64.patch
diff -Nru paryfor-0.1/debian/patches/support_riscv64.patch 
paryfor-0.1/debian/patches/support_riscv64.patch
--- paryfor-0.1/debian/patches/support_riscv64.patch1970-01-01 
07:30:00.0 +0730
+++ paryfor-0.1/debian/patches/support_riscv64.patch2024-01-15 
15:36:05.0 +0800
@@ -0,0 +1,23 @@
+Description: support riscv64 build 
+Applied-Upstream: 
https://github.com/ekg/paryfor/commit/2383b62f53175950a5fcd75bdf6d68774311b496 
+Last-Update: 2024-01-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/paryfor.hpp
 b/paryfor.hpp
+@@ -51,6 +51,15 @@
+ }
+ } // namespace atomic_queue
+ } // namespace paryfor
++#elif defined(__riscv) && (__riscv_xlen == 64)
++namespace paryfor {
++namespace atomic_queue {
++constexpr int CACHE_LINE_SIZE = 64;
++static inline void spin_loop_pause() noexcept {
++asm volatile ("nop" ::: "memory");
++}
++} // namespace atomic_queue
++} // namespace paryfor
+ #else
+ #error "Unknown CPU architecture."
+ #endif


signature.asc
Description: PGP signature

Bug#1007343: python-hglib: please consider upgrading to 3.0 source format

[Julien Cristau]

Control: tag -1 wontfix

On Tue, Mar 15, 2022 at 08:52:04 +0100, Lucas Nussbaum wrote:

> Source: python-hglib
> Version: 2.6.2-1
> Severity: wishlist
> Tags: bookworm sid
> Usertags: format1.0 format1.0-nkp-nv
> 
> Dear maintainer,
> 
> This package is among the few (1.9%) that still use source format 1.0 in
> bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
> advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
> this contributes to standardization of packaging practices.
> 
> Please note that this is also a sign that the packaging of this software
> could maybe benefit from a refresh. It might be a good opportunity to
> look at other aspects as well.
> 
> It was noticed in https://lists.debian.org/debian-devel/2022/03/msg00096.html
> that the conversion for this package is likely trivial, and builds bit-by-bit
> identical binary packages.
> 
In my opinions the downside of 3.0 (quilt) outweigh the advantages so do
not expect I'll switch to it.

Cheers,
Julien

Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)

[Shengjing Zhu]

On Mon, Jan 15, 2024 at 10:25 PM Simon Josefsson  wrote:
>
> Shengjing Zhu  writes:
>
> > On Mon, Jan 15, 2024 at 9:27 PM Simon Josefsson  wrote:
> >>
> >> Package: wnpp
> >> Severity: wishlist
> >> Owner: Simon Josefsson 
> >>
> >> * Package name: golang-k8s-sigs-release-utils
> >>   Version : 0.7.7-1
> >>   Upstream Author : Kubernetes SIGs
> >> * URL : https://github.com/kubernetes-sigs/release-utils
> >> * License : Apache-2.0
> >>   Programming Lang: Go
> >>   Description : utilities for kubernetes Go release engineering 
> >> (library)
> >>
> >>  Tiny utilities for use by the Release Engineering subproject and
> >>  kubernetes/release (https://github.com/kubernetes/release/).
> >>
> >
> > Which package will need this library? It looks strange by the name and
> > description. We certainly don't do the release stuff for kubernetes.
>
> Sigstore's rekor complained:
>
> https://salsa.debian.org/jas/golang-github-sigstore-rekor/-/jobs/5160982
>
> src/github.com/sigstore/rekor/cmd/backfill-redis/main.go:44:2: cannot find 
> package "sigs.k8s.io/release-utils/version" in any of:
> /usr/lib/go-1.21/src/sigs.k8s.io/release-utils/version (from $GOROOT)
> 
> /builds/jas/golang-github-sigstore-rekor/debian/output/source_dir/_build/src/sigs.k8s.io/release-utils/version
>  (from $GOPATH)
>
> Use is here:
>
> https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L44
>

Hmm, then this library is needed.

However I just checked the code in sigs.k8s.io/release-utils/version,
I'm afraid it's not compatible with how we build Go binaries in
Debian.
We don't have any VCS info when building the binaries. And we use
GOPATH mde as well. So the Go compiler can't inject any version info
in the binaries.
This code 
https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L103
would probably just print "unknown, unknown"...

> Can you think of some other solution than packaging
> golang-k8s-sigs-release-utils?  I would be happy to learn about
> alternative approaches to reduce golang dependencies.
>
> /Simon



-- 
Shengjing Zhu

Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)

[Simon Josefsson]

Shengjing Zhu  writes:

> On Mon, Jan 15, 2024 at 9:27 PM Simon Josefsson  wrote:
>>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Simon Josefsson 
>>
>> * Package name: golang-k8s-sigs-release-utils
>>   Version : 0.7.7-1
>>   Upstream Author : Kubernetes SIGs
>> * URL : https://github.com/kubernetes-sigs/release-utils
>> * License : Apache-2.0
>>   Programming Lang: Go
>>   Description : utilities for kubernetes Go release engineering (library)
>>
>>  Tiny utilities for use by the Release Engineering subproject and
>>  kubernetes/release (https://github.com/kubernetes/release/).
>>
>
> Which package will need this library? It looks strange by the name and
> description. We certainly don't do the release stuff for kubernetes.

Sigstore's rekor complained:

https://salsa.debian.org/jas/golang-github-sigstore-rekor/-/jobs/5160982

src/github.com/sigstore/rekor/cmd/backfill-redis/main.go:44:2: cannot find 
package "sigs.k8s.io/release-utils/version" in any of:
/usr/lib/go-1.21/src/sigs.k8s.io/release-utils/version (from $GOROOT)

/builds/jas/golang-github-sigstore-rekor/debian/output/source_dir/_build/src/sigs.k8s.io/release-utils/version
 (from $GOPATH)

Use is here:

https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L44

Can you think of some other solution than packaging
golang-k8s-sigs-release-utils?  I would be happy to learn about
alternative approaches to reduce golang dependencies.

/Simon


signature.asc
Description: PGP signature

Bug#1060843: imath FTCBFS: python3 build dependencies not satisfiable

[Johannes Schauer Marin Rodrigues]

Source: imath
Version: 3.1.9-3
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

Hi,

imath currently fails to cross build from source because it doesn't declare its
dependencies correctly. The patch at the bottom fixes this problem.

 - it marks those build dependencies that are just used to create
   Architecture:all documentation packages with  (no need to
   cross-build these)
 - it picks the native architecture python3-numpy package (host architecture is
   the default)
 - it turns python3-dev:any into python3-dev:native, libpython3-dev

Thanks!

cheers, josch

diff -Nru imath-3.1.9/debian/control imath-3.1.9/debian/control
--- imath-3.1.9/debian/control  2023-09-04 14:09:31.0 +0200
+++ imath-3.1.9/debian/control  2024-01-15 13:08:40.0 +0100
@@ -10,11 +10,11 @@
  doxygen,
  libboost-python-dev,
  pkg-config,
- python3-breathe,
- python3-dev:any,
- python3-numpy,
- python3-sphinx,
- python3-sphinx-press-theme
+ python3-breathe ,
+ python3-dev:native, libpython3-dev,
+ python3-numpy:native,
+ python3-sphinx ,
+ python3-sphinx-press-theme 
 Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Homepage: https://www.openexr.com
@@ -74,6 +73,7 @@
 Section: doc
 Architecture: all
 Multi-Arch: foreign
+Build-Profiles: 
 Depends:
  libjs-jquery,
  sphinx-common,

Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)

[Shengjing Zhu]

On Mon, Jan 15, 2024 at 9:27 PM Simon Josefsson  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Simon Josefsson 
>
> * Package name: golang-k8s-sigs-release-utils
>   Version : 0.7.7-1
>   Upstream Author : Kubernetes SIGs
> * URL : https://github.com/kubernetes-sigs/release-utils
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : utilities for kubernetes Go release engineering (library)
>
>  Tiny utilities for use by the Release Engineering subproject and
>  kubernetes/release (https://github.com/kubernetes/release/).
>

Which package will need this library? It looks strange by the name and
description. We certainly don't do the release stuff for kubernetes.

-- 
Shengjing Zhu

Bug#1060842: ITP: trillian -- A transparent, highly scalable and cryptographically verifiable data store

[Simon Josefsson]

Alexandre Detiste  writes:

> People using the non-free trillian.deb (the chat client)
> will have a nasty surprise
>
> https://forums.debian.net/viewtopic.php?t=146679

Ouch, good catch, this needs some planning.  However it is not packaged
in Debian nor are there any signs of it inside the official Debian as
far as I can tell.

My primary use-case is the trillian golang libraries, for sigstore's
rekor.  I'll see about starting with them only.  The 'trillian' binary
package can be added later, under that name or another.

/Simon

> Le lun. 15 janv. 2024 à 15:03, Simon Josefsson  a écrit :
>>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Simon Josefsson 
>>
>> * Package name: trillian


signature.asc
Description: PGP signature

Bug#1060838: meson: should use the host gobject-introspection-1.0.pc for looking up g-ir-scanner

[Helmut Grohne]

On Mon, Jan 15, 2024 at 12:38:54PM +, Simon McVittie wrote:
> On Mon, 15 Jan 2024 at 13:04:27 +0100, Helmut Grohne wrote:
> > Among other things, Simon introduced new programs
> > /usr/bin/-g-ir-scanner. When cross building, these should be
> > used and they'll automatically employ qemu-user when needed. He also
> > updated gobject-introspection-1.0.pc to have g_ir_scanner point at this
> > rather than plain /usr/bin/g-ir-scanner. Unfortunately, meson looks up
> > the gobject-introspection-1.0 dependency with native set to true. Hence,
> > it does not pick up the host triplet but the build triplet here and that
> > doesn't go well.
> 
> I believe this was done intentionally in Meson, because in general the
> host g-ir-scanner will not even be executable during a cross-build. The
> fact that we have made it work is Debian-specific. If I understand
> upstream's position correctly, the way to force this sort of thing is
> via cross-files.

I question this. g-ir-scanner is written in Python and it is fairly
unlikely that /usr/bin/python3 will end up being the host Python that
cannot be run. Hence using the g-ir-scanner from the host typically
should work (or not) the same way as the one from the build - unless one
has specifically changed it (as you've done for the benefit of Debian).

Possibly, some builds are performed with no gobject-introspection-1.0.pc
being installed for the host architecture. In such cases, we could fall
back from host architecture to build architecture. I don't see a
plausible failure scenario arising from using the g_ir_scanner variable
from the host file when available though.

Independently of whether it breaks stuff or not, the proposed patch may
still go against upstream's position, yes.

> Debian's gobject-introspection does provide a cross-file that does what we
> want (--cross-file=${DEB_HOST_GNU_TYPE}-gobject-introspection.ini). See
> src:graphene for an example of this being used. Ideally, this would
> be used automatically for all cross-builds that involve g-i, to avoid
> needing to make sourceful changes in all packages that run g-i, but
> unfortunately I am not aware of any currently available way to ask an
> appropriate layer (debhelper?) to add a category of non-core cross files
> to all cross-builds.
> 
> Perhaps a possible route for the future would be to teach debhelper's
> meson build system to add a --cross-file to all cross-builds, automatically,
> for each file matching /usr/share/meson/cross/${DEB_HOST_GNU_TYPE}-*.ini?
> But I have not yet discussed that idea with the debhelper maintainers.

Let me express an argument against this approach. Being hooked into
debhelper means that things will just work in Debian package builds.
However, Debian is also used as a development platform for building
other things than packages. When you perform your build by running meson
and ninja directly, you'll have to remember to also pass these
crossfiles for every cross build performed on Debian. In order for this
to benefit non-package builds, meson itself would have to automatically
consume those crossfiles.

I actually see this as a problem in the rust ecosystem currently. Debian
package builds are somehow enhanced to dependencies from Debian packages
rather than downloading stuff from cargo. Replicating this offline
experience without building Debian packages is a non-trivial affair.

For this reasons, I still prefer a solution at the meson-level (even if
it is not the solution I am proposing here).

Still, if everyone else thinks that debhelper is the better place, I'm
going out of the way and can supply the relevant debhelper patch.

> I think we are going to need a similar mechanism in future for at
> least Vala's vapigen (which is the reason why e.g. libportal can't be
> cross-compiled by making changes similar to the ones in graphene).
> 
> >  def find_tool(self, name: str, depname: str, varname: str, required: 
> > bool = True,
> > -  wanted: T.Optional[str] = None) -> 
> > T.Union['build.Executable', ExternalProgram, 'OverrideProgram']:
> > +  wanted: T.Optional[str] = None, native: bool = True) -> 
> > T.Union['build.Executable', ExternalProgram, 'OverrideProgram']:
> 
> Is find_tool intended to be analogous to Autoconf AC_CHECK_TOOL,
> which automatically checks for a cross-tool using the convention that a
> cross-tool that works with binaries for the host architecture ${HOST} (but
> runnable on the build architecture) is usually named ${HOST}-${tool_name},
> falling back to ${tool_name} only if ${HOST}-${tool_name} is not found?
> 
> (In Debian terms, ${HOST} is ${DEB_HOST_GNU_TYPE})
> 
> Or is find_tool intended to be more like Autoconf AC_CHECK_PROG, which is
> appropriate for tools that have no particular architecture dependency, like
> documentation generators, but not appropriate for compilers, linkers and
> other tools that might have different behaviour and outputs per-architecture?

Thanks for asking the question I also