Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install

[Niels Thykier]

Control: retitle -1 debhelper: dh_install, globs vs. executable files
Control: tags -1 -moreinfo

Gioele Barabucci:

On 12/10/23 14:54, Niels Thykier wrote:

Gioele Barabucci:

On 12/10/23 14:11, Niels Thykier wrote:

```
debian/tmp/usr/share/man/*/man1/foo.1
```

is correctly expanded by dh_install (`d/pkg.install`) but it causes 
dh_installman (`d/pkg.manpages`) to fail.


Whatever problem you are experiencing, it is *not* that 
`dh_installman`does not support globs, because definitely does as 
debhelper itself would FTBFS otherwise (`debian/debhelper.mapages` 
includes globs).


maybe it is the combination of dh_installman + dh-exec?


    When  using executable debhelper config files, please be aware of
    the following:

    Otherwise,  the  output will be used exactly as‐is.  Notably,
    debhelper will **not expand  wildcards** or  strip  comments
    or strip whitespace in the output.


This surprises me a bit. util-linux currently uses both dh-exec and 
wildcards in `d/util-linux-locales.install` and it works as "expected" 
(but not as documented?):


https://salsa.debian.org/debian/util-linux/-/blob/f7d972e9d/debian/util-linux-locales.install

Doesn't this mean that `dh_install` expands the globs found in the 
output of the executable `foo.install`?


Regards,



It does; `dh_install` is a special snowflake of doing everything 
differently than anything else. The `dh_install` helper manually does 
the glob'ing rather than using the `filedoublearray` for glob expansion. 
 As a historical artefact, it never knew whether the `install` file 
executable and therefore the restriction never fully applied there.


This artefact has (also) been there since the introduction of executable 
debhelper config files.


I will accept this as a bug for dh_install not behaving as documented. I 
am probably going to end with ratifying the current behaviour rather 
than removing glob support (because removing glob support would require 
more code and break anyone relying on it even though it should not work).


For everything else, glob support should be done by the executable 
itself (possibly indirectly via dh-exec).


Best regards,
Niels

Bug#1053812: Pretty sure #1053812 is fixed in 4.2

[Jonathan Kamens]

So, Russ sent me his apt-listchanges database and I took a lot at it and 
it was very messed up.


There was a bug in 4.1 which was uncovered and fixed a couple of days 
ago as a result of Alexandre Detiste's push to add typing hints to the 
program. This bug would have caused the type of corruption that I saw in 
Russ's database, so I'm pretty sure it will go away in 4.2.


In addition, the structure of the database has been revamped in 4.2 so 
when upgrading to 4.1 to 4.2 the program is going to throw away the old 
database and start from scratch, which will clear out the corruption.


In addition, to facilitate debugging issues like this in the future, 
I've added new state snapshotting functionality to the program which 
will only be deployed in experimental releases. Here's 
 
the commit if you're curious. Here's 
 
the changelog showing everything significant that will be in 4.2.


  jik

Bug#1030743: help is welcome about the 'source-is-missing' error with the cherrytree packaging

[Andrius Merkys]

Hello,

On Mon, 15 May 2023 15:54:23 +0300 Andrius Merkys  wrote:

On 2023-05-12 21:34, Patrice Duroux wrote:
> What is astonishing me is that the Perl code of lintian uses calls to 
encode_utf8/decode_uf8 in many places of different modules instead of fixing utf8 
IO once in each.
> I finally got lost in translation. 

There might be reasons for such usage we are not aware of. Nevertheless 
lintian should output correct Unicode and use it for override matching. 
I suspect there is double encoding problem somewhere, as when I replace 
line 74 of /usr/share/lintian/lib/Lintian/Pointer/Item.pm with


 my $text = decode_utf8($self->item->name);

I no longer have either source-is-missing nor mismatched-override.


I attempted rebuilding lintian with this change and got a bunch of test 
failures:


> Test Summary Report
> ---
> 
debian/test-out/eval/checks/documentation/manual/manpage-errors-from-man/generic.t 
 (Wstat: 256 (exited 1) 
Tests: 1 Failed: 1)

>   Failed test:  1
>   Non-zero exit status: 1
> 
debian/test-out/eval/checks/documentation/manual/manpages-general/generic.t 
(Wstat: 256 
(exited 1) Tests: 1 Failed: 1)

>   Failed test:  1
>   Non-zero exit status: 1
> 
debian/test-out/eval/checks/documentation/manual/surplus-manpage/generic.t 
 (Wstat: 256 
(exited 1) Tests: 1 Failed: 1)

>   Failed test:  1
>   Non-zero exit status: 1

I cannot see how the above are related to my change.

> debian/test-out/eval/checks/files/names/files-general/generic.t 
  (Wstat: 
65280 (exited 255) Tests: 0 Failed: 0)

>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 1 tests but ran 0.
> debian/test-out/eval/checks/files/names/legacy-filenames/generic.t 
  (Wstat: 
65280 (exited 255) Tests: 0 Failed: 0)

>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 1 tests but ran 0.
> 
debian/test-out/eval/checks/files/names/national-encoding-in-orig/generic.t 
(Wstat: 65280 
(exited 255) Tests: 0 Failed: 0)

>   Non-zero exit status: 255
>   Parse errors: Bad plan.  You planned 1 tests but ran 0.
> 
debian/test-out/eval/checks/files/unicode/trojan/exe-vs-gif-in-patched-filename/generic.t 
  (Wstat: 256 (exited 1) Tests: 
1 Failed: 1)

>   Failed test:  1
>   Non-zero exit status: 1
> Files=1486, Tests=63476, 1441 wallclock secs (10.63 usr  6.15 sys + 
4448.39 cusr 876.07 csys = 5341.24 CPU)

> Result: FAIL

These seem to show that lintian intentionally omits decode_utf8() to 
catch and process various ill-formatted utf8 octet sequences. 
Nevertheless I would suggest calling decode_utf8() in try/catch block 
reverting to the old behavior should the decoding fail. I will try that 
and report how it goes.


Best,
Andrius

Bug#941352: normal user's password is sufficient

[Andreas B. Mundt]

Control: severity -1 wishlist
Control: title -1 make clear the password query asks for the user's password 

Hi,

on bookworm, KDE/plasma, things work fine here with the user's
password entered.  It is not clear from the query text that the user's
password is sufficient, perhaps this could be improved.

Best regards,

  Andi

Bug#1053855: false positive for Python top_level.txt files: package-contains-documentation-outside-usr-share-doc

[Julian Gilbey]

On Fri, Oct 13, 2023 at 12:18:58AM +0530, Nilesh Patra wrote:
> Control: tags -1 patch
> 
> Hello,
> 
> It seems that .dist-info and .egg-info are always ignored for this
> warning anyway. However dist-info should contain
> [...]
> 
> On digging into dh-python changelog, I see the entry:
> 
>   * Remove RECORD files from dist-info, these are incompatible with
>   multi-arch.
> 
> Then, I think it makes sense to remove this check from lintian as well.
> 
> I've anyway opened an MR to fix this:
> 
>   https://salsa.debian.org/lintian/lintian/-/merge_requests/482

Amazingly fast deductive work there, Nilesh - thank you!

Best wishes,

   Julian

Bug#1053864: libdrm-amdgpu1: gpu crash on graphics start with Radeon 760M (both sway and gdm3)

[Simon Heath]

Package: libdrm-amdgpu1
Version: 2.4.115-1
Severity: normal
X-Debbugs-Cc: ice...@dreamquest.io

Dear Maintainer,

When GDM3 starts, or when I turn it off and log into the console by hand
and then start sway or another WM, often the graphics mode switch will
hang for a few seconds on an unresponsive black screen, then go back to
a text console for an instant and try again.  This seems to repeat 0-3
times until eventually it works successfully.  Sometimes it works on the
first try, often on the second try, etc.

Once Sway or GDM3 and Xorg have actually started, it *seems* perfectly
stable, as far as I've seen so far.

This is a brand new GPU chipset afaik so graphics bugs are pretty
understandable.

CPU: AMD Ryzen 5 7640U w/ Radeon 760M Graphics
Extended renderer info from `glxinfo`:
Device: AMD Radeon Graphics (gfx1103_r1, LLVM 16.0.6, DRM 3.54, 
6.5.0-1-amd64) (0x15bf)
Version: 23.2.1

I also see the following errors in dmesg associated with the
apparent-crash-and-restart:

[   26.625039] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, 
signaled seq=23, emitted seq=25
[   26.625482] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: 
process  pid 0 thread  pid 0
[   26.625820] amdgpu :c1:00.0: amdgpu: GPU reset begin!
[   26.810595] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   26.810761] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to 
unmap legacy queue
[   26.944169] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   26.944310] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to 
unmap legacy queue
[   27.077693] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   27.077834] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to 
unmap legacy queue
[   27.211163] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   27.211303] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to 
unmap legacy queue
[   27.344634] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   27.344776] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to 
unmap legacy queue
[   27.478028] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   27.478175] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to 
unmap legacy queue
[   27.611499] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   27.611640] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to 
unmap legacy queue
[   27.744960] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   27.745097] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to 
unmap legacy queue
[   27.878425] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 
[amdgpu]] *ERROR* MES failed to response msg=3
[   27.878564] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to 
unmap legacy queue
[   27.880086] amdgpu :c1:00.0: amdgpu: MODE2 reset
[   27.909811] amdgpu :c1:00.0: amdgpu: GPU reset succeeded, trying to 
resume
[   27.910426] [drm] PCIE GART of 512M enabled (table at 0x00801FD0).
[   27.910540] amdgpu :c1:00.0: amdgpu: SMU is resuming...
[   27.911480] amdgpu :c1:00.0: amdgpu: SMU is resumed successfully!
[   27.913327] [drm] DMUB hardware initialized: version=0x08000E00
[   27.918776] [drm] REG_WAIT timeout 1us * 1000 tries - dcn314_dsc_pg_control 
line:264
[   27.921376] [drm] REG_WAIT timeout 1us * 1000 tries - dcn314_dsc_pg_control 
line:272
[   27.923969] [drm] REG_WAIT timeout 1us * 1000 tries - dcn314_dsc_pg_control 
line:280
[   27.926566] [drm] REG_WAIT timeout 1us * 1000 tries - dcn314_dsc_pg_control 
line:288
[   27.934650] [drm] REG_WAIT timeout 1us * 1000 tries - dcn314_dsc_pg_control 
line:264
[   27.937248] [drm] REG_WAIT timeout 1us * 1000 tries - dcn314_dsc_pg_control 
line:272
[   27.939841] [drm] REG_WAIT timeout 1us * 1000 tries - dcn314_dsc_pg_control 
line:280
[   27.942439] [drm] REG_WAIT timeout 1us * 1000 tries - dcn314_dsc_pg_control 
line:288
[   28.328853] [drm] kiq ring mec 3 pipe 1 q 0
[   28.331133] [drm] VCN decode and encode initialized successfully(under DPG 
Mode).
[   28.331252] amdgpu :c1:00.0: [drm:jpeg_v4_0_hw_init [amdgpu]] JPEG 
decode initialized successfully.
[   28.331965] amdgpu :c1:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on 
hub 0
[   28.331968] amdgpu :c1:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 
on hub 0
[   28.331971] amdgpu :c1:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 
on hub 0
[   28.331973] amdgpu :c1:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 
on hub 0
[   28.331975] amdgpu 

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Kyle Fazzari]

On 10/11/23 22:45, Antoine Beaupré wrote:

On 2023-10-11 22:30:16, Kyle Fazzari wrote:

On 10/11/23 19:24, Antoine Beaupré wrote:


[...]


Yeah I won't lie, my immediate thought was "huh, I've never seen that
happen." Then my follow-up was "actually, how would I even know?" But at
the same time, I could make that argument for a lot of collectors! Is
there an established pattern for gathering this kind of data?


Filing a timestamp and duration of the last run is typical.


Very good.

By the way, I came across this Ubuntu bug today, which sounds eerily 
familiar, no?


https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003851

Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager

[Mathias Gibbens]

On Sun, 2023-10-08 at 12:19 +0100, Free Ekanayaka wrote:
> It seems that v6 of golang-github-checkpoint-restore-go-criu is in
> experimental:
> 
> https://packages.debian.org/experimental/golang-github-checkpoint-restore-go-criu-dev
> 
> Not sure if there are blockers for it to move to unstable (maybe we'd
> need to drop the patch currently applied to the LXD package?).

  31/35 of the rdeps of golang-github-checkpoint-restore-go-criu build
fine with v6.3.0 from experimental -- the big blocker is runc. Its most
recent release (1.1.9) still depends on v5, although in the upstream
main branch it's been switched to v6. Given that runc is a fundamental
container library, I'll want to confer with the Go Packaging Team on
how to move forward with this.

  (And LXD currently has a patch to revert the simple use of go-criu,
so when v6 lands in unstable that's a simple thing to remove.)

> Yes, agrred. Incus 0.1 has now been released, and I've updated the
> salsa repository accordingly.
> 
> I've also switched the packaging branch from debian/experimental to
> debian/unstable, as actually I don't see a reason for not uploading
> to unstable at this stage.

  Fine by me -- for a brand new package there doesn't seem to be much
reason to first target experimental, in my opinion.

> Once Incus 1.0 LTS is out we could opt for uploading only LTS updates
> to unstable and development releases to experimental.

  That's the mental idea I've had for LXD as well, although I haven't
actually done that yet. One of the tricky things would be managing two
distinct upstream branches (upstream-lts and upstream-dev maybe?) and
then merging Debian-specific packaging changes from unstable <->
experimental.

> >   Just a minor note -- if LXD keeps its established release
> > schedule, I'm expecting LXD 6.0.x to ship in trixie.
> 
> Yes, although I would personally keep Debian's LXD at version 5.0.x
> for trixie and point users to the lxd-to-incus migration tool, to
> migrate from LXD 5.0.x to Incus 1.0.x, which should be be a superset
> of LXD 6.0.x.
> 
> That's of course just [my] take, I understand that there might be
> interest from other DDs/users (e.g. you) to update the Debian's
> package to LXD 6.0.x.

  With my DD hat on, I don't want to artificially hold back the version
of LXD in trixie solely to make life easier for Incus -- especially if
there's a 6.0 LTS release out with plenty of time before freezes start.
Doing so would be a disservice to users wishing to run LXD and have the
latest LTS release available in trixie.

  I know there will be a growing delta between LXD and Incus as time
goes on, but I would also suspect Incus will want to support migrations
from newer versions of LXD as best as it can.
> 

> >   Currently in unstable there are only three rdeps of src:raft:
> > dqlite, golang-github-canonical-go-dqlite, and lxd. So it would
> > certainly be doable to switch the upstream of src:raft -- if Laszlo
> > is open to doing so, it should be a pretty easy transition.
> > Probably the trickiest thing would be the versions: I'd like to
> > avoid a package epoch bump if possible, and we'd also have to
> > consider the .so versioning.
> 
> Why do think an epoch is needed? I believe it can be done without
> epochs. Anyway, if the idea gets consenus I'll coordinate with Laszlo
> about that.

  Looks like you've picked an initial release version of 0.17.7, so I
guess that side-steps the epoch bump issue in Debian's packaging, but I
don't know about resetting the .so version back to zero. Is there
anything in Policy about a "backwards" transition? While there wouldn't
be API compatibility, this would introduce two different "libraft.so.0"
files into the archive. (And a future ".so.1" and ".so.2".) Maybe we
could find another C library that changed its upstream to see how they
handled it? Mostly I just don't want to accidentally cause a (subtle)
mess somewhere down the road.

  This evening I created an initial wiki page as well, which at the
moment is just tracking some of the remaining dependencies for Incus'
packaging: https://wiki.debian.org/Incus.

Mathias


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

Bug#1053804: filezilla: Filezilla aborts with invalid opcode at i386

[Phil Wyett]

On Wed, 11 Oct 2023 17:03:42 +0200 Gert van de Kraats
 wrote:
> Package: filezilla
> Version: 3.63.0-1+deb12u2
> Severity: important
> Tags: patch
> 
> Dear Maintainer,
> 
> Since https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034195 is
solved,
> filezilla can be compiled and now is available at Debian Bookworm
12.0 
> i386 32
> bit.
> Unfortunately it aborts with invalid opcode:
> 
> 2023-10-10T00:17:58.773980+02:00 debian systemd[16997]: Started app-
gnome-
> filezilla-20364.scope - Application launched by gnome-shell.
> 2023-10-10T00:17:59.784902+02:00 debian kernel: [53450.659012] traps:
> filezilla[20364] trap invalid opcode ip:b7df84c3 sp:bff7eaa0 error:0
in
> libfzclient-private-3.63.0.so[b7d1a000+128000]
> 
> This is caused by compiling all source with -msse4.1.
> This causes at some sources generation of instructions, that cannot
be 
> executed
> by my current hardware and are not skipped by software tests.
> 
> In fact the compile problem is solved if only the Makefile at
src/putty is
> changed.
> 
> Therefore the latest change at debian/rules is deleted and replaced
by
> editing src/putty/Makefile at override_dh_auto_configure.
> This is not nice, but at least it works.
> 
> The change can be removed again as soon as gcc release 14 is
available.
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109504
> Modified debian/rules :
> 
> #!/usr/bin/make -f
> # Uncomment this to turn on verbose mode.
> #export DH_VERBOSE=1
> 
> export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> 
> # ifeq ($(DEB_HOST_ARCH_CPU),i386)
> # Workaround GCC bug on i386
> # export DEB_CFLAGS_MAINT_APPEND = -msse4.1
> # export DEB_CXXFLAGS_MAINT_APPEND = -msse4.1
> # endif
> 
> %:
> dh $@
> 
> override_dh_autoreconf:
> ifeq ($(shell dpkg-vendor --derives-from Ubuntu  echo
yes),yes)
> patch -p1  debian/patches/11_use-decimal-si-by-default.patch
> touch debian/applied
> endif
> dh_autoreconf
> 
> override_dh_auto_clean:
> dh_auto_clean
> ifeq ($(shell dpkg-vendor --derives-from Ubuntu  echo
yes),yes)

Hi,

What specific hardware are you using to trigger this issue? This will
hopefully help me reproduce in a VM.

With regard GCC 14 and the future of filezilla builds. Debian 13 will
not have an i386 or other x86 32-bit build. The time for support to end
has been a long time coming and I feel the effort to support it and
associated libraries is not worth it.

Thank you for the fix snippet, I will look at this as soon as I am
able.

Regards

Phil

-- 
Playing the game for the games sake.

* Debian Maintainer

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org

Social:

* Twitter: kathenasorg
* Instagram: kathenasorg




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

Bug#1052191: unicode-data: Please update for the new 15.1 release

[Mathias Gibbens]

Hi,

  Is there a plan for the transition from 15.0 -> 15.1? golang-github-
mattn-go-runewidth has FTBFS bug #1052819 fixed in unstable, but
blocked on migration to testing. It's on the AUTORM list about a month
out, and I'd like to avoid its removal from testing if possible.

Thanks,
Mathias


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

Bug#1052803: golang-github-gosexy-gettext: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/gosexy/gettext returned exit code 1

[Mathias Gibbens]

Hi Steve,

  This library is a dependency of LXD and the hopefully soon to be
packaged Incus, so I'd like to prevent it from being AUTORM'ed from
testing in a month. Have you had a chance to look into this build
failure?

  Also, if you'd like to move the package to being team-maintained with
the Go Packaging Team, I'd be happy to help with any further attention
this package might need in the future.

Thanks,
Mathias


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

Bug#1053705: dpkg-dev: please use a different word than Maintainer from dpkg-parsechangelog

[Guillem Jover]

On Mon, 2023-10-09 at 07:59:05 -0300, David Bremner wrote:
> Package: dpkg-dev
> Version: 1.22.0
> Severity: minor

> The use of Maintainer in the output of dpkg-parsechangelog is
> confusing, because it suggests that dpkg-parsechangelog is reporting
> the Maintainer field from debian/control. I suggest Changed-By for
> consistency with changes files.

While that might have perhaps been a better field name, this is now
part of interfaces, both for the command line tool, and the perl
modules. So the only way I can see this could be renamed, if desired,
would be by introducing some kind of versioning for the output, which
could not be the default anyway, so the confusion would linger around
(or might be made worse).

The naming is also used in the description of the debian/changelog
format both in deb-changelog(5) and in the Debian Policy.

In any case, for now, I'm thinking about queueing the attached
documentation patch to try to clarify a bit things, and will ponder
about a possible versioned output.

Regards,
Guillem
diff --git i/man/dpkg-parsechangelog.pod w/man/dpkg-parsechangelog.pod
index 52026ed04..4a6ffb182 100644
--- i/man/dpkg-parsechangelog.pod
+++ w/man/dpkg-parsechangelog.pod
@@ -109,6 +109,10 @@ concatenated (space-separated) comments from all the versions requested.
 
 =item B I
 
+The name and email address of the person who prepared these changes,
+they are B necessarily those of the uploader or the usual package
+maintainer.
+
 =item B I
 
 The date of the entry as a string, as it appears in the changelog.
@@ -272,6 +276,13 @@ number itself.
 
 =back
 
+=head1 BUGS
+
+The B field has a confusing name matching the field in
+the F file but not its exact semantics,
+where its meaning would be better represented by the B field
+name used in the F<.changes> file.
+
 =head1 SEE ALSO
 
 B(5).

Bug#1053778: dpkg: add loong64 to mask builtin feature list

[Guillem Jover]

Hi!

[ In the future make sure to send mails to the Debian bug tracker as
  plain not-flowed text, otherwise that messes up with the pseudo-header
  formatting. Thanks! ]

On Wed, 2023-10-11 at 09:31:01 +0800, yalingfang wrote:
> Package: dpkg Version: 1.22.0 Severity: normal Tags: patch User:
> debian-de...@lists.debian.org Usertags: loongarch64 Dear maintainers,

> We need add loong64 to mask builtin feature list for pie flag wrong
> during compiling.

> We have added loong64 for dpkg, the patch
> 
> can be found in the attachment. If you have any questions, you can contact
> me at any time. Thanks!

I've queued this patch, and it will be part of my next git push
targeting the next release.

> diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
> index 1cc2393..0ac3ebe 100644
> --- a/scripts/Dpkg/Vendor/Debian.pm
> +++ b/scripts/Dpkg/Vendor/Debian.pm
> @@ -184,6 +184,7 @@ sub set_build_features {
>  i386
>  kfreebsd-amd64
>  kfreebsd-i386
> + loong64
>  mips
>  mips64
>  mips64el

I've replaced the tab with spaces.

Thanks,
Guillem

Bug#1053863: Terminal problems after suspending less during apt-listchanges output

[Russ Allbery]

Package: apt-listchanges
Version: 4.1
Severity: normal
X-Debbugs-Cc: r...@debian.org

As of apt-listchanges 4.1, if I suspend the less command showing the
report with Ctrl-Z and then resume with fg or %, the terminal state
is incorrect. The report screen is not refreshed, Ctrl-L doesn't work,
and q doesn't work to exit unless it's followed by Enter.

I suspect that this may be due to setting LESSSECURE, which I talked
you into. If so, I think I was wrong that it wouldn't cause problems.
I'm not sure that's the issue, but it feels like the most relevant
change.


-- Package-specific info:
==> /etc/apt/listchanges.conf <==
[apt]
frontend=pager
email_address=none
confirm=0
save_seen=/var/lib/apt/listchanges
which=both
no_network=false
headers=false
reverse=false


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

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

Versions of packages apt-listchanges depends on:
ii  apt2.7.6
ii  debconf [debconf-2.0]  1.5.82
ii  python33.11.4-5+b1
ii  python3-apt2.6.0
ii  python3-debconf1.5.82
ii  sensible-utils 0.0.20
ii  ucf3.0043+nmu1

apt-listchanges recommends no packages.

Versions of packages apt-listchanges suggests:
ii  chromium [www-browser]  118.0.5993.70-1
ii  firefox [www-browser]   118.0.2-1
ii  google-chrome-stable [www-browser]  118.0.5993.70-1
ii  links [www-browser] 2.29-1+b1
ii  lynx [www-browser]  2.9.0dev.12-1
ii  postfix [mail-transport-agent]  3.8.2-1
ii  python3-gi  3.46.0-1
ii  w3m [www-browser]   0.5.3+git20230121-2
ii  xterm [x-terminal-emulator] 385-1

-- debconf information:
* apt-listchanges/which: both
* apt-listchanges/headers: false
* apt-listchanges/frontend: pager
* apt-listchanges/reverse: false
* apt-listchanges/save-seen: true
* apt-listchanges/email-address:
* apt-listchanges/no-network: false
  apt-listchanges/email-format: text
* apt-listchanges/confirm: false

Bug#1053862: libcue: Please package new upstream version 2.3.0

[Boyuan Yang]

Source: libcue
Version: 2.2.1-4.1
Severity: normal

Dear Debian libcue package maintainer,

 The libcue upstream is releasing a new release 2.3.0 at
https://github.com/lipnitsk/libcue/releases as a response
of the recent CVE issue. Packaging it could help us no longer
carry custom patches and refresh packaging. Please consider
making a new package upload for it. Thanks!

Best,
Boyuan Yang


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

Bug#1053812: apt-listchanges showing old changelog entries during upgrade

[Russ Allbery]

Jonathan Kamens  writes:

> Again, I hate to do this, but until we've figured this out, can the two
> of you please do me a favor? Before you run each apt upgrade, please
> save a backup copy of /var/lib/apt/listchanges, then if the problem
> happens during the upgrade, please send me the backup copy of the file
> as well as the new version of the same file that should have been
> modified during the upgrade. I think this must have something to do with
> what's in your seen database but I am unable to recreate a database that
> triggers the issue, so I think I need to see yours.

I'm sending you this via direct mail.  I'm now seeing the problem with
each apt upgrade (in other words, I feel like 4.1 might be worse than 4.0,
which seemed to exhibit the problem only with some packages).

-- 
Russ Allbery (r...@debian.org)  

Bug#1053861: systemd-journal-remote: systemd-joural-uploading killed by watchdog every 3 minutes

[Tom Cameron]

Package: systemd-journal-remote
Version: 254.5-1
Severity: normal

Dear Maintainer,

After upgrading a test host from stable to testing, I noticed 
systemd-journal-upload
stopped sending logs to my logging host running Debian stable. The test
host notes that the service is killed for watchdog failure, and when the
service restarts the receiver logs a message about handshake message out
of context.

I have attempted to remove the upload state file, in the event there was
an issue with the last log data uploaded. This did not change the
status.


Source Host:
systemd 254 (254.5-1)

Log entries:
Oct 09 23:40:51 host-04 systemd[1]: Started systemd-journal-upload.service - 
Journal Remote Upload Service.
Oct 09 23:43:51 host-04 systemd[1]: systemd-journal-upload.service: Watchdog 
timeout (limit 3min)!
Oct 09 23:43:51 host-04 systemd[1]: systemd-journal-upload.service: Killing 
process 4709 (systemd-journal) with signal SIGABRT.
Oct 09 23:43:51 host-04 systemd[1]: systemd-journal-upload.service: Main 
process exited, code=killed, status=6/ABRT
Oct 09 23:43:51 host-04 systemd[1]: systemd-journal-upload.service: Failed with 
result 'watchdog'.


Destination Host:
systemd 252 (252.17-1~deb12u1)

Log entries:
Oct 09 19:43:51 rhodes systemd-journal-remote[6125]: microhttpd: Error: 
received handshake message out of context.


I can confirm that no log lines appear from this host on the target
host, while log lines from other Debian stable hosts do appear. The
journal files for this particular host don't seem have any updates since
around the time the upgrade from stable to testing completed.

I have checked the libmicrohttpd bug tracker to see if anything recent
seemed to matchi this behavior in the event that the hosts aren't
handshaking due to incompatible crypto settings, but nothing stands out
to me.

I have also looked at the systemd issue tracker on github, and while
there has historically be several issues with journal-upload, none of
them seem to have been reported recently.



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

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

Versions of packages systemd-journal-remote depends on:
ii  libc6  2.37-12
ii  libcurl4   8.3.0-2
ii  libmicrohttpd120.9.77-3
ii  libsystemd-shared  254.5-1
ii  systemd254.5-1

systemd-journal-remote recommends no packages.

systemd-journal-remote suggests no packages.

-- no debconf information

Bug#1053860: /usr/share/bash-completion/completions/ethtool: completes with ^[[36m at the start

[наб]

Package: ethtool
Version: 1:6.4-1
Severity: normal
File: /usr/share/bash-completion/completions/ethtool

Dear Maintainer,

  $ ethtool -g 
yields
  $ ethtool -g ^[[36m

  $ ethtool -g ^[[36m
yields
  $ ethtool -g ^[[36m
  ^[[36mbond1  ^[[36mcard1  ^[[36mcard2  ^[[36mlo 
^[[36monboard1


Typing "ethtool -g ^[[36m" in and then tabbing yields nothing,
so this is probably a control sequence?
Indeed, typing control-[, [, 3, 6, m, dupa into cat shows dupa in blue.

Why?

Best,
наб

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

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

Versions of packages ethtool depends on:
ii  libc62.37-12
ii  libmnl0  1.0.4-3

ethtool recommends no packages.

ethtool suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1040057: python3.11: segmentation fault triggered by slixmpp unittest suite

[Martin]

Control: reassign -1 src:python3.11
Control: retitle -1 python3.11: segmentation fault triggered by slixmpp 
unittest suite
Control: tags -1 -help -moreinfo
Control: affects -1 src:slixmpp

It looks like a bug in Python 3.10 and 3.11, triggered by the slixmpp
unittest suite. With Python 3.12, the problem is gone.

Bug#1023047: wsjtx: No transmit audio

[erebion]

According to Pavucontrol there is no audio, as wsjtx does not show up. 
That is while transmitting, haven't tried to receive last time as I did 
not have the required cable with me.


I think input was broken as well, but to be sure I'd need to have 
another look.


On 12.10.23 22:35, Christoph Berg wrote:

Can you fire up pavucontrol to check if there's 1) any audio 2) on the
correct sound card while transmitting?


--
erebion

Matrix: @erebion:erebion.eu

My languages: German, English, Swedish, Norwegian, Danish
Yes, I'm a language nerd. Feel free to write to me in any of the aforementioned 
languages.



OpenPGP_0x8EAF40326E02AE7D.asc
Description: OpenPGP public key
BEGIN:VCARD
VERSION:4.0
N:;erebion;;;
FN:erebion
EMAIL;PREF=1:ereb...@erebion.eu
IMPP:matrix:u/erebion:erebion.eu
URL:https://erebion.eu
TZ:Europe/Berlin
END:VCARD


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install

[Gioele Barabucci]

On 12/10/23 14:54, Niels Thykier wrote:

Gioele Barabucci:

On 12/10/23 14:11, Niels Thykier wrote:

```
debian/tmp/usr/share/man/*/man1/foo.1
```

is correctly expanded by dh_install (`d/pkg.install`) but it causes 
dh_installman (`d/pkg.manpages`) to fail.


Whatever problem you are experiencing, it is *not* that 
`dh_installman`does not support globs, because definitely does as 
debhelper itself would FTBFS otherwise (`debian/debhelper.mapages` 
includes globs).


maybe it is the combination of dh_installman + dh-exec?


    When  using executable debhelper config files, please be aware of
    the following:

    Otherwise,  the  output will be used exactly as‐is.  Notably,
    debhelper will **not expand  wildcards** or  strip  comments
    or strip whitespace in the output.


This surprises me a bit. util-linux currently uses both dh-exec and 
wildcards in `d/util-linux-locales.install` and it works as "expected" 
(but not as documented?):


https://salsa.debian.org/debian/util-linux/-/blob/f7d972e9d/debian/util-linux-locales.install

Doesn't this mean that `dh_install` expands the globs found in the 
output of the executable `foo.install`?


Regards,

--
Gioele Barabucci

Bug#1053106: please create a debian-za list for our Debian local user group in South Africa

[Jonathan Carter]

On 2023/09/27 17:11, Jonathan Carter wrote:

Name: debian-za


Hi, any news on my request?

Bug#1023047: wsjtx: No transmit audio

[Christoph Berg]

Re: erebion
> Is there anything specific I could check?

Can you fire up pavucontrol to check if there's 1) any audio 2) on the
correct sound card while transmitting?

Is the TX gain slider at something between -20dB and 0dB and not at
the very bottom?

Christoph DF7CB

Bug#1053859: bugs.debian.org: Audio not working on a Apollo Lake Chromebook (Celeron N3350)

[Esteban]

Package: bugs.debian.org
Severity: important
X-Debbugs-Cc: kolot...@gmail.com

Dear Maintainer,

Hi, im trying to enable audio in my Chromebook with debian 12, kernel 6.1., the
lspci command recognizes the card as """Multimedia audio controller: Intel
Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster (rev
0b)
"""

In Linux Mint 21.1 and 21.2 with kernel 5.15 i can enable audio with the
instructions of this website:

https://www.reddit.com/r/chrultrabook/comments/uc0b6i/howto_audio_on_apollolake_devices_under_linux/?rdt=37174

But with debian 11 and 12 i havent had sucess.

I also tried to enable audio in debian 12 with these instructions
(https://github.com/WeirdTreeThing/chromebook-linux-audio) but the terminal
gave me the following message:

"""Looks like your kernel doesn't have the avs modules. Make sure you are on at
least 6.0 with avs enabled"""

I know that both drivers (in the previous url's included) will enable only
speakers (no jack or hdmi audio), but i can't get debian to work with these

This is the url of the specs of the machine:

https://support.hp.com/us-en/document/c06657652

Bug#1053858: ITP: node-tiptap-core -- headless rich text editor

[Ananthu C V]

Package: wnpp
Severity: wishlist
Owner: Ananthu C V 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: node-tiptap-core
  Version : 2.1.12
  Upstream Author : Tiptap GmbH
* URL : https://tiptap.dev
* License : Expat
  Programming Lang: JavaScript
  Description : headless rich text editor

 A headless, framework-agnostic and extendable rich text editor, 
 based on ProseMirror.

@tiptap/core is one of the dependencies used by gitlab.

I am intending to maintain this as part of the javascript team.
As I do not have uploading rights, I will be needing a sponspor.

Bug#1021646: blender: enable HIP in Cycles (2023 Update)

[Cordell Bloor]

Hello Maintainer,

Would you be open to a patch or merge request that enabled HIP support 
to the blender package?


HIP has been available in Debian for over a year now and the packaging 
is a bit more mature. It is now possible to build for HIP just by adding 
hipcc to the build dependencies and setting 
-DWITH_CYCLES_HIP_BINARIES=ON 
-DCYCLES_HIP_BINARIES_ARCH="gfx900;gfx902;gfx906;gfx1010;gfx1011;gfx1012;gfx1030;gfx1031;gfx1032;gfx1034".


Christian Kastner and I have also been setting up a CI system for 
packages with GPU acceleration [1]. If there are autopkgtests for 
rendering on AMD GPUs, we would be happy to run them. We are working 
towards having every modern discrete AMD GPU architecture covered on the CI.


Sincerely,
Cory Bloor

[1]: https://lists.debian.org/debian-ai/2023/08/msg3.html

Bug#1053856: (no subject)

[Mario Limonciello]

The specific issue here is that there is a firmware binary in upstream 
linux-firwmare.git, also documented in WHENCE upstream but not installed 
in Debian's package.

Bug#1053855: false positive for Python top_level.txt files: package-contains-documentation-outside-usr-share-doc

[Nilesh Patra]

Control: tags -1 patch

Hello,

It seems that .dist-info and .egg-info are always ignored for this
warning anyway. However dist-info should contain

$ cat -n lib/Lintian/Screen/Python/Egg/Metadata.pm
...
35  return 1
36if $item->dirname =~ m{ [^/] [.] dist-info / $}x
37&& defined $item->parent_dir->child('METADATA')
38&& defined $item->parent_dir->child('WHEEL')
39&& defined $item->parent_dir->child('RECORD');

Now, your packages seems to be missing "RECORD" file in .dist-info due
to which this tag is again shown.

$ debc | grep -E '(WHEEL|RECORD|METADATA)'
-rw-r--r-- root/root  4575 2023-06-23 05:30 
./usr/lib/python3/dist-packages/bytecode-0.14.2.dist-info/METADATA
-rw-r--r-- root/root92 2023-06-23 05:30 
./usr/lib/python3/dist-packages/bytecode-0.14.2.dist-info/WHEEL

On digging into dh-python changelog, I see the entry:

* Remove RECORD files from dist-info, these are incompatible with
multi-arch.

Then, I think it makes sense to remove this check from lintian as well.

I've anyway opened an MR to fix this:

https://salsa.debian.org/lintian/lintian/-/merge_requests/482

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1053852: btrfsd: Segfault in libgobject-2.0.so.0.7800.0[7fcec2dff000+34000]

[Vincent Blut]

Le 2023-10-12 19:24, Matthias Klumpp a écrit :
> Hi!
> 
> Thank you for the issue report!

You're welcome!

> How did you run btrfsd exactly? Did you set anything specific in its
> configuration file?

This is a default install, i.e. running btrfsd through systemd without any 
changes
to the configuration file.

>Can you generate a backtrace with debug symbols for btrfsd installed?

Oh, my bad. I was in a hurry and I totally forgot to install btrfsd-dbgsym.
Here is another run after installing it:

Thread 1 "btrfsd" received signal SIGSEGV, Segmentation fault.
0x77e40c01 in g_type_check_instance_is_fundamentally_a ()
   from /lib/x86_64-linux-gnu/libgobject-2.0.so.0

(gdb) thread apply all bt

Thread 4 (Thread 0x767fe6c0 (LWP 53845) "gdbus"):
#0  0x779b1a1f in __GI___poll (fds=0x7fffeb90, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x77ec1237 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77ec1bdf in g_main_loop_run () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77d3bdfa in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x77eee9e1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7793e3ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x779bea4c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 3 (Thread 0x7fffee7fe6c0 (LWP 53844) "gmain"):
#0  0x779b1a1f in __GI___poll (fds=0x55575a40, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x77ec1237 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77ec18f0 in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77ec1941 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77eee9e1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7793e3ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x779bea4c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 2 (Thread 0x76fff6c0 (LWP 53843) "pool-spawner"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x77f1c9a4 in g_cond_wait () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77e8b15b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77eef06a in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77eee9e1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7793e3ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x779bea4c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 1 (Thread 0x773e5900 (LWP 53839) "btrfsd"):
#0  0x77e40c01 in g_type_check_instance_is_fundamentally_a () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1  0x77e2187d in g_object_unref () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2  0xa119 in glib_autoptr_clear_GDBusConnection 
(_ptr=0x5557c2d0) at /usr/include/glib-2.0/gio/gio-autocleanups.h:49
#3  glib_autoptr_cleanup_GDBusConnection (_ptr=) at 
/usr/include/glib-2.0/gio/gio-autocleanups.h:49
#4  btd_machine_is_on_battery () at ../src/btd-utils.c:365
#5  0x8b35 in btd_scheduler_run_for_mount (bfs=0x55573fa0, 
self=0x5556e420) at ../src/btd-scheduler.c:436
#6  btd_scheduler_run (self=self@entry=0x5556e420, 
error=error@entry=0x7fffc778) at ../src/btd-scheduler.c:497
#7  0x7a5b in main (argc=, argv=) at 
../src/btrfsd.c:81

> Cheers,
> Matthias

Thanks for your time,
Vincent


signature.asc
Description: PGP signature

Bug#1053122: Fwd: Bug#1053122: linux-image-6.5.0-1-amd64: using smp_processor_id() in preemptible

[Gabriel Francisco]

-- Forwarded message -
From: Gabriel Francisco 
Date: Thu, Oct 12, 2023 at 8:23 PM
Subject: Re: Bug#1053122: linux-image-6.5.0-1-amd64: using
smp_processor_id() in preemptible
To: Ben Hutchings 


Hi,

> The CPU registers contain several addresses starting 89, except for
> rbx which starts 99 (and is the faulting address).  That looks like
> a single bit got flipped.

Thanks for the explanation! (now I know how to detect bit flips) :D

> The first BUG message should be more meaningful that what comes after.
> This shows the kernel tried to access non-existent memory.

Yes, I should have reported the first one indeed, I thought too much and
ended reporting the second one. Sorry about that.

> This could be due to a kernel bug, but is more likely a hardware
> problem.  Please test the RAM with memtest86+.  Also if you've enabled
> any overclocking options, turn those off.

Even with XMP(3000@1.35v) enabled (F4-3000C16-16GISB), memtest86+ ran for 3
hours and printed PASS in the screen.
I removed the XMP profile from my memories and ordered new rams to check if
my current ones are faulty (or not).

The message in dmesg was only one occasion. (but I reported it anyways)

The hang does still happens with/without XMP when running 6.5.x kernel
series. It happens when maximizing a video (or time-to-time when my cursor
enters the video area) when using kernel 6.5.x. It does not happen with
kernel 6.1.x series.

I'm using amgpu module.

Greetings,

*Gabriel Francisco*
Linux User #507840
email: frc.gabriel[at]gmail.com 


On Thu, Oct 5, 2023 at 1:15 AM Ben Hutchings  wrote:

> Control: retitle -1 linux-image-6.5.0-1-amd64: Kernel page fault in
> process exit due to bit flip
> Control: tag -1 moreinfo
>
> On Wed, 2023-09-27 at 20:45 +0200, Gabriel Francisco wrote:
> > Package: src:linux
> > Version: 6.5.3-1
> > Severity: important
> > Tags: upstream
> > X-Debbugs-Cc: frc.gabr...@gmail.com
> >
> > Dear Maintainer,
> >
> > First of all thanks for your hard work!
> >
> > I noticed my computer started freezing for few seconds when
> entering/exiting
> > full screen videos in youtube using firefox and while trying to check if
> the
> > issue also afected chromium I saw the following message in dmesg:
> >
> > [12569.564300] BUG: unable to handle page fault for address:
> 991989e936b8
> > [12569.564304] #PF: supervisor write access in kernel mode
> > [12569.564306] #PF: error_code(0x0002) - not-present page
>
> The first BUG message should be more meaningful that what comes after.
> This shows the kernel tried to access non-existent memory.
>
> > [12569.564308] PGD 0 P4D 0
> > [12569.564311] Oops: 0002 [#1] PREEMPT SMP NOPTI
> > [12569.564314] CPU: 10 PID: 328649 Comm: Chroot Helper Not tainted
> 6.5.0-1-amd64 #1  Debian 6.5.3-1
> > [12569.564317] Hardware name: ASUS System Product Name/ROG STRIX B550-F
> GAMING WIFI II, BIOS 3205 08/14/2023
> > [12569.564318] RIP: 0010:down_write+0x23/0x70
> > [12569.564324] Code: 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 53
> 48 89 fb e8 2e bc ff ff bf 01 00 00 00 e8 74 3a 53 ff 31 c0 ba 01 00 00 00
>  48 0f b1 13 75 33 65 48 8b 04 25 80 29 03 00 48 89 43 08 bf 01
> > [12569.564326] RSP: 0018:a189d736fc70 EFLAGS: 00010246
> > [12569.564328] RAX:  RBX: 991989e936b8 RCX:
> 891797aaef00
> > [12569.564330] RDX: 0001 RSI: 891989e645c0 RDI:
> 8e7c95dc
> > [12569.564331] RBP:  R08: 0060 R09:
> 80400014
> > [12569.564333] R10: 8918cbfeb7f8 R11: 0006 R12:
> 7f7e5fd0
> > [12569.564334] R13: 0001 R14: 891989e645c0 R15:
> 891989e64958
>
> The CPU registers contain several addresses starting 89, except for
> rbx which starts 99 (and is the faulting address).  That looks like
> a single bit got flipped.
>
> This could be due to a kernel bug, but is more likely a hardware
> problem.  Please test the RAM with memtest86+.  Also if you've enabled
> any overclocking options, turn those off.
>
> [...]
> > After that the computer can't shutdown and systemd keeps waiting on
> process PID 328649 (Chroot Helper).
>
> This (and the other BUG messages) are because that process crashed in
> kernel mode and couldn't properly exit.
>
> Ben.
>
> --
> Ben Hutchings
> Beware of bugs in the above code;
> I have only proved it correct, not tried it. - Donald Knuth
>
>

Bug#1028722: prody: FTBFS: AssertionError: 3205 != 3211 : selection 'abs(x) == sqrt(sq(x))' for Selection 'all' failed, expected 3211, selected 3205

[Santiago Vila]

tags 1028722 + patch
thanks

Hello.

I asked Drew Parsons to look at this bug because he reported a similar
bug with severity:serious here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053265

In both cases the failure happens while comparing floating
point numbers using the equality comparison operator (==),
or something similarly dangerous.

It's true that in a first look it might seem that it's comparing
integer numbers, but as upstream explains here:

https://github.com/prody/ProDy/issues/1594#issuecomment-1748400116

it's actually comparing vectors of floating point numbers and
after that it's counting the number of matches between those vectors.

This is known to be a bad practice and should be avoided, as
machines with different floating point implementations
may yield different results for the "same" math operation.

This is why it fails 100% of the time in the virtual
machines from Hetzner where I tried, and for this reason
I would consider this to be a violation of Policy 4.2.

As an experiment (suggested by Drew) I ran today
"autopkgtest -B -- null" on a Hetzner machine using the
installed packages from the archive (built by the official buildds)
and as expected it also fails that way (see first attach).

To summarize: The failing test is buggy because when it fails
it does not necessarily mean that the package was misbuilt,
and in my opinion the best thing to do would be to disable it,
both in stable and unstable.

Trivial patch in the second attach.

Thanks.=== FAILURES ===
__ TestSelect.testFunctionSelection13 __

self = 
pdb = 'pdb3mht', test = ('abs(x) == sqrt(sq(x))', 3211), type_ = 'function'
kwargs = {}, atoms = 
selstr = 'abs(x) == sqrt(sq(x))', natoms = 3211, selstr2 = None
sel = array([   0,1,2, ..., 3208, 3209, 3210])

def func(self, pdb=case, test=test, type_=type_, **kwargs):

atoms = SELECTION_TESTS[pdb]['ag']

selstr = test[0]
natoms = test[1]
selstr2 = None
kwargs = EMPTYDICT
if len(test) == 3:
selstr2 = test[2]
if len(test) == 4:
kwargs = test[3]

if natoms is None:
self.assertRaises(prody.select.SelectionError,
SELECT.getIndices, atoms, selstr, **kwargs)
elif selstr2 is None:
sel = SELECT.getIndices(atoms, selstr, **kwargs)
>   self.assertEqual(len(sel), natoms,
'selection {0} for {1} failed, expected '
'{2}, selected {3}'.format(repr(selstr),
str(atoms), natoms, len(sel)))
E   AssertionError: 3205 != 3211 : selection 'abs(x) == sqrt(sq(x))' 
for AtomGroup 3mht failed, expected 3211, selected 3205

tests/atomic/test_select.py:442: AssertionError
__ TestSelect.testFunctionSelection14 __

self = 
pdb = 'pdb3mht', test = ('abs(x) == sqrt(sq(x))', 3211), type_ = 'function'
kwargs = {}, atoms = 
selstr = 'abs(x) == sqrt(sq(x))', natoms = 3211, selstr2 = None
sel = array([   0,1,2, ..., 3208, 3209, 3210])

@dec.slow
def func(self, pdb=case, test=test, type_=type_, **kwargs):

atoms = SELECTION_TESTS[pdb]['all']

selstr = test[0]
natoms = test[1]
selstr2 = None
kwargs = EMPTYDICT
if len(test) == 3:
selstr2 = test[2]
if len(test) == 4:
kwargs = test[3]

if natoms is None:
self.assertRaises(prody.select.SelectionError,
SELECT.getIndices, atoms, selstr, **kwargs)
elif selstr2 is None:
sel = SELECT.getIndices(atoms, selstr, **kwargs)
>   self.assertEqual(len(sel), natoms,
'selection {0} for {1} failed, expected '
'{2}, selected {3}'.format(repr(selstr),
str(atoms), natoms, len(sel)))
E   AssertionError: 3205 != 3211 : selection 'abs(x) == sqrt(sq(x))' 
for Selection 'all' failed, expected 3211, selected 3205

tests/atomic/test_select.py:483: AssertionError
=== warnings summary ===
utilities/misctools.py:424
  /usr/lib/python3/dist-packages/prody/utilities/misctools.py:424: 
DeprecationWarning: pkg_resources is deprecated as an API. See 
https://setuptools.pypa.io/en/latest/pkg_resources.html
import pkg_resources

../Bio/pairwise2.py:278
  /usr/lib/python3/dist-packages/Bio/pairwise2.py:278: 
BiopythonDeprecationWarning: Bio.pairwise2 has been deprecated, and we intend 
to remove it in a future release of Biopython. As an alternative, please 
consider using Bio.Align.PairwiseAligner as a replacement, and contact the 
Biopython developers if you still need the Bio.pairwise2 module.
warnings.warn(

apps/evol_apps/__init__.py:3
  /usr/lib/python3/dist-packages/prody/apps/evol_apps/__init__.py:3: 
DeprecationWarning: the imp module is 

Bug#1053857: cups: CVE-2023-32360 instructions in NEWS have a typo and are unclear

[Jonathan Kamens]

Package: cups
Version: 2.4.7-1
Severity: important

Dear Maintainer,

The NEWS entry for CVE-2023-32360 says /etc/cups/cupds.conf when ite
should say /etc/cups/cupsd.conf.

In addition, after reading the NEWS entry and reviewing the contents
of my cupsd.conf file, I'm left completely clueless about whether I
actually need to change anything, or if doing so will break cups.

Two reasons for this:

* I don't have any "" stanzas in my
cupsd.conf. all of the stanzas that reference CUPS-Get-Document
reference many other commands at the same time. For example:

  

I don't know whether changing one of these stanzas will break
something because it will affect things other than CUPS-Get-Document.

* There are three different  blocks in my cupsd.conf that
reference CUPS-Get-Document, under , , and . The first has no "AuthType
Default" line, the second says "AuthType Default", and the third says
"AuthType Negotiate". I don't know whether I need to add "AuthType
Default" to the first one or if the fact that the second one already
has "AuthType Default" means I'm protected.

This isn't great.

  jik

Bug#1053551: ftbfs on amd64 when building binary-arch

[Simon Richter]

Hi,

On 10/12/23 19:14, Simon Richter wrote:

I cannot reproduce this, and I would rather not investigate time into 
that. Please check if you see this with gcc-13 as well.


I suspect it's a missing dependency, so the failure is more dependent on 
"number of threads", and that it succeeds for -b might be coincidence.


I'll try adding a sleep statement to the rule generating this file and 
see if I can get it to reproduce always.


Confirmed:

--- a/src/gcc/Makefile.in.orig  2023-10-12 12:20:46.349633453 +0200
+++ b/src/gcc/Makefile.in   2023-10-12 12:21:08.087623131 +0200
@@ -2431,6 +2431,7 @@
 $(simple_generated_h:insn-%.h=s-%): s-%: build/gen%$(build_exeext)
$(RUN_GEN) build/gen$*$(build_exeext) $(md_file) \
  $(filter insn-conditions.md,$^) > tmp-$*.h
+   if test "$*" = "attr-common"; then sleep 300; fi
$(SHELL) $(srcdir)/../move-if-change tmp-$*.h insn-$*.h
$(STAMP) s-$*

makes the problem reproducible even when building with -j2, and 
regardless of whether building _all packages in the same build or not. 
I'll check tomorrow about gcc 13 and if that also happens upstream.


   Simon

Bug#1053856: firmware-amd-graphics: Inconsistent firmware snapshot for Zen4/Phoenix1 GPUs

[Diederik de Haas]

Control: notfound -1 20230210-5
Control: found -1 20230515-3

On Thursday, 12 October 2023 18:52:26 CEST Wiktor Janas wrote:
> Package: firmware-amd-graphics
> Version: 20230210-5
> 
> firmware-amd-graphics version 20230515-3 (currently in unstable and testing)
> ships an inconsistent snapshot of the firmware files, which make
> Zen4/Phoenix1 GPU crash when starting Xorg. That renders any GUI unusable.
> 
> The firmware currently in linux-firmware works correctly. The snapshot
> shipped in stable (package version 20230210-5) also works correctly.

Updated metadata as 20230210-5 work, while 20230515-3 doesn't.

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

Bug#1053849: base-files: Allow .d for issue and issue.net

[Santiago Vila]

El 12/10/23 a las 14:41, Bardot Jerome escribió:

Is there is a way to use the conf.d mecanism for files in base-files.

In my case it's for issue and issue.net.

For explanation i will imagine the directory issue.d .

Maybe it's need an option to concatenate or erase default file.
And maybe the same way to load 10- 20- etc.


The files "issue" and "issue.net" have a single line of text.
I'd like to keep base-files simple. Creating a .d mechanism for
files with one line of text seems a little bit overkill to me.


Why asking ?

- to separate my own legal issue and the default one


Well. Good news: The file containing the legal issue is /etc/motd
and it's not contained in base-files.deb. This means that it's not
a conffile in the dpkg sense. There will be no questions about it
if you change it, because base-files creates it only once in
the very first install (from debootstrap) and then does not
touch it at all ever again.


- no more dpkg question on update/upgrade.


Well, you can avoid all questions by using the
"unattended-upgrades" package. This usually
works triggered by cron, but you can also
disable the cron part and run it whenever
you want to do the upgrade. It upgrades
everything but without any questions.

What would make /etc/issue so special that
we have to change the way we handle it when
people have a generic way to avoid all sort
of questions? (not just the ones in base-files).

Do you consider unattended-upgrades not enough
for your particular needs?

Thanks.

Bug#1053852: btrfsd: Segfault in libgobject-2.0.so.0.7800.0[7fcec2dff000+34000]

[Matthias Klumpp]

Hi!

Thank you for the issue report!
How did you run btrfsd exactly? Did you set anything specific in its
configuration file? Can you generate a backtrace with debug symbols
for btrfsd installed?

Cheers,
Matthias

Bug#1053856: firmware-amd-graphics: Inconsistent firmware snapshot for Zen4/Phoenix1 GPUs

[Wiktor Janas]

Package: firmware-amd-graphics
Version: 20230210-5
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: mario.limoncie...@amd.com, wixorp...@gmail.com

firmware-amd-graphics version 20230515-3 (currently in unstable and testing) 
ships
an inconsistent snapshot of the firmware files, which make Zen4/Phoenix1 GPU
crash when starting Xorg. That renders any GUI unusable.

Investigation and confirmation from AMD devs:
https://gitlab.freedesktop.org/drm/amd/-/issues/2908#note_2125041

The firmware currently in linux-firmware works correctly. The snapshot
shipped in stable (package version 20230210-5) also works correctly.

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

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

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
pn  initramfs-tools  

-- no debconf information

Bug#1051418: obs-studio: clicking on an xcomposite window source makes obs segfault

[thah...@t-online.de]

Same story on xorg.
 
-- System Information:
Debian Release: trixie/sid
APT prefers oldoldstable-updates
APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages obs-studio depends on:
ii libavcodec60 7:6.0-7+b1
ii libavdevice60 7:6.0-7+b1
ii libavformat60 7:6.0-7+b1
ii libavutil58 7:6.0-7+b1
ii libc6 2.37-12
ii libcurl3-gnutls 8.3.0-3
ii libfontconfig1 2.14.2-6
ii libfreetype6 2.13.2+dfsg-1
ii libgcc-s1 13.2.0-5
ii libjansson4 2.14-2
ii libluajit-5.1-2 2.1.0~beta3+git20220320+dfsg-4.1
ii libmbedcrypto7 2.28.5-1
ii libmbedtls14 2.28.5-1
ii libmbedx509-1 2.28.5-1
ii libobs0 29.1.3+dfsg-2
ii libpci3 1:3.10.0-2
ii libpulse0 16.1+dfsg1-2+b1
ii libpython3.11 3.11.6-3
ii libqt5core5a 5.15.10+dfsg-3
ii libqt5gui5 5.15.10+dfsg-3
ii libqt5network5 5.15.10+dfsg-3
ii libqt5svg5 5.15.10-2
ii libqt5widgets5 5.15.10+dfsg-3
ii libqt5xml5 5.15.10+dfsg-3
ii librist4 0.2.8+dfsg+really0.2.7+dfsg-1
ii libspeexdsp1 1.2.1-1
ii libsrt1.5-openssl 1.5.3-1
ii libstdc++6 13.2.0-5
ii libswscale7 7:6.0-7+b1
ii libudev1 254.5-1
ii libv4l-0 1.24.1-4
ii libva-drm2 2.20.0-2
ii libva2 2.20.0-2
ii libx11-6 2:1.8.7-1
ii libx264-164 2:0.164.3095+gitbaee400-3+b1
ii libxcb-composite0 1.15-1
ii libxcb-randr0 1.15-1
ii libxcb-shm0 1.15-1
ii libxcb-xfixes0 1.15-1
ii libxcb-xinerama0 1.15-1
ii libxcb1 1.15-1
ii python3 3.11.4-5+b1
ii python3.11 3.11.6-3
Versions of packages obs-studio recommends:
ii obs-plugins 29.1.3+dfsg-2
Versions of packages obs-studio suggests:
ii pkexec 123-1
ii policykit-1 123-1
pn v4l2loopback-dkms 
-- no debconf information
 
...
info: - source: 'Window Capture (Xcomposite)' (xcomposite_input)
info: 
[Thread 0x7ffeebfff6c0 (LWP 1793192) exited]
[New Thread 0x7ffeebfff6c0 (LWP 1793194)]
[New Thread 0x7fff0cff96c0 (LWP 1793195)]
[New Thread 0x7fff06c0 (LWP 1793196)]
[Thread 0x7fff15dff6c0 (LWP 1793191) exited]
info: adding 21 milliseconds of audio buffering, total audio buffering is 
now 21 milliseconds (source: Desktop Audio)

Thread 1 "obs" received signal SIGSEGV, Segmentation fault.
__strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:287
287 ../sysdeps/x86_64/multiarch/strcmp-avx2.S: No such file or directory
 
 


Bug#1053855: false positive for Python top_level.txt files: package-contains-documentation-outside-usr-share-doc

[Julian Gilbey]

Package: lintian
Version: 2.116.3
Severity: normal

Just building a Python package with this version, and I receive the
info tag:

I: python3-bytecode: package-contains-documentation-outside-usr-share-doc 
[usr/lib/python3/dist-packages/bytecode-0.15.0.dist-info/top_level.txt]

I think (almost) every Python package has a top_level.txt file that is
automatically built, naming the top-level Python package, so this file
should be excluded from this test.  (The file always lives in a
*.dist-info or *.egg-info directory.)

Best wishes,

   Julian

Bug#989125: lists.debian.org: Request a mailing list named "debian-loongarch64"

[Alexander Wirt]

Hi, 

> Rationale:We have a new architecture named loongarch64, We have alreadly
> compelted loongarch64 debian port in our local workspace. Now, We plane to 
> post
> it to debian for becomeing a offical debian port. We need a mailing list for
> Discussions on the loongarch64 port(s) of Debian.
> Name: debian-loongarch64
> Short description: Discussions on the loongarch64 port(s) of Debian.
> Long description:
> Discussions on the loongarch64 port(s) of Debian.
> For more information see: https://wiki.debian.org/loongarch64
> This list is not moderated; posting is allowed by anyone.
> 
> Subscription Policy: open
> Post Policy: open
> Web Archive : yes

I created your new list. 

https://lists.debian.org/debian-loongarch/

Thanks

Alex
 


signature.asc
Description: PGP signature

Bug#1052881: embree: FTBFS: ! LaTeX Error: File `puenc-greek.def' not found.

[Bastian Germann]

The missing file is in texlive-lang-greek, however it might be a good idea to trigger puenc.def's condition 
\ifx\textBeta\@undefined so that it is not included.

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Santiago Vila]

El 10/10/23 a las 13:46, Luca Boccassi escribió:

Given the list of affected packages is short (and it's all about
tzdata IIRC), how about we wait until that list is down to zero (and
if you have time, maybe you could help with that?), and then merge
this change? That way we don't add instability, and fix the issue at
the same time.


Hello.

In my opinion, the main problem here is the discrepancy between
policy saying "packages must build from source after BD are installed"
and what actually happens in the buildds (packages with missing BD
not always failing in the buildds).

When there is a category of bugs which are considered important
and we want to make it serious, we report the bugs first,
we give plenty of time to fix them, and we finally raise
the severities.

We usually don't wait for the bug number to become zero,
because the number of affected packages usually decays exponentially.

In general, when the list of affected packages is short enough, that's
usually a sign that it's already ok to make the bugs RC.

Johannes has asked the RMs in this thread:

https://lists.debian.org/debian-release/2023/10/msg00425.html

if they are ready to consider the bugs as RC. I believe it would be better
if we can make the bugs "factually" RC by uploading the fixed debootstrap first.

After that, complains about this kind of bugs not happening in the buildds
or being difficult to reproduce should stop completely, and as far as I'm
concerned, the underlying problem will be solved.

In fact, we could upload deboostrap already and still have a moratorium
on already reported bugs. For example, we could agree on not raising the
severities for three months on old bugs.

This way we give even more time for people to fix those bugs, NMUs
would not be needed, but anybody trying to upload an affected package
without fixing the bug will see that it will not work in the buildds.

That was, after all, the whole idea in this bug, to optimize the way
these kind of bugs are detected by detecting them in the buildds.

I believe we would be nice enough to people if we do that (i.e. fixing
debootstrap now, and delaying severity change a little more if we
really want to give more time).

Thanks.

Bug#1053854: xsimd: error: ‘aligned_mode’ in namespace ‘xsimd’ does not name a type

[Drew Parsons]

Source: xsimd
Version: 10.0.0-3
Severity: important
Control: forwarded -1 https://github.com/xtensor-stack/xsimd/issues/954
Control: affects -1 libxtensor-dev

xtensor 0.24.7 tests are exposing an error in xsimd 10.0.0 on less
common architectures armel, ppc64el and s390x, seen in debian CI tests at
https://ci.debian.net/packages/x/xtensor/

Test logs
https://ci.debian.net/data/autopkgtest/unstable/riscv64/x/xtensor/38875117/log.gz
https://ci.debian.net/data/autopkgtest/unstable/s390x/x/xtensor/38875118/log.gz

The same xtensor code is passing on other architectures (arm has other
problems), so I guess the problem is in the definitions included via
xsimd/xsimd.hpp when xtensor is used with use XTENSOR_USE_XSIMD on
these architectures.

The affected arches seem to be all XSIMD_NO_SUPPORTED_ARCHITECTURE

The error message on riscv64 is

217s /usr/bin/g++ -DXSIMD_ENABLE_XTL_COMPLEX -DXTENSOR_USE_XSIMD  
-DXSIMD_ENABLE_XTL_COMPLEX=1 -std=c++14 -Wunused-parameter -Wextra -Wreorder 
-Wconversion -Wno-sign-conversion  -Wold-style-cast -Wunused-variable 
-ftemplate-backtrace-limit=0 -O3 -DNDEBUG -MD -MT 
CMakeFiles/test_xtensor_lib.dir/test_xarray.cpp.o -MF 
CMakeFiles/test_xtensor_lib.dir/test_xarray.cpp.o.d -o 
CMakeFiles/test_xtensor_lib.dir/test_xarray.cpp.o -c 
/tmp/autopkgtest-lxc.w6l32789/downtmp/autopkgtest_tmp/test_xarray.cpp
223s In file included from /usr/include/xtensor/xstorage.hpp:23,
223s  from /usr/include/xtensor/xshape.hpp:23,
223s  from /usr/include/xtensor/xstrides.hpp:21,
223s  from /usr/include/xtensor/xaccessible.hpp:14,
223s  from /usr/include/xtensor/xbroadcast.hpp:23,
223s  from /usr/include/xtensor/xbuilder.hpp:29,
223s  from /usr/include/xtensor/xmanipulation.hpp:19,
223s  from 
/tmp/autopkgtest-lxc.w6l32789/downtmp/autopkgtest_tmp/test_common.hpp:16,
223s  from 
/tmp/autopkgtest-lxc.w6l32789/downtmp/autopkgtest_tmp/test_xadaptor_semantic.cpp:10:
223s /usr/include/xtensor/xtensor_simd.hpp:37:33: error: ‘aligned_mode’ in 
namespace ‘xsimd’ does not name a type; did you mean ‘aligned_free’?
223s37 | using aligned_mode = xsimd::aligned_mode;
223s   | ^~~~
223s   | aligned_free
223s /usr/include/xtensor/xtensor_simd.hpp:38:35: error: ‘unaligned_mode’ in 
namespace ‘xsimd’ does not name a type; did you mean ‘aligned_free’?
223s38 | using unaligned_mode = xsimd::unaligned_mode;
223s   |   ^~
223s   |   aligned_free
223s /usr/include/xtensor/xtensor_simd.hpp:41:40: error: ‘allocator_alignment’ 
in namespace ‘xsimd’ does not name a template type
223s41 | using allocator_alignment = xsimd::allocator_alignment;
223s   |^~~
223s /usr/include/xtensor/xtensor_simd.hpp:44:42: error: 
‘allocator_alignment_t’ in namespace ‘xsimd’ does not name a template type
223s44 | using allocator_alignment_t = xsimd::allocator_alignment_t;
223s   |  ^
223s /usr/include/xtensor/xtensor_simd.hpp:47:40: error: ‘container_alignment’ 
in namespace ‘xsimd’ does not name a template type
223s47 | using container_alignment = xsimd::container_alignment;
223s   |^~~
223s /usr/include/xtensor/xtensor_simd.hpp:50:42: error: 
‘container_alignment_t’ in namespace ‘xsimd’ does not name a template type
223s50 | using container_alignment_t = xsimd::container_alignment_t;
223s   |  ^
223s /usr/include/xtensor/xtensor_simd.hpp:53:32: error: ‘simd_traits’ in 
namespace ‘xsimd’ does not name a template type
223s53 | using simd_traits = xsimd::simd_traits;
223s   |^~~
223s /usr/include/xtensor/xtensor_simd.hpp:56:39: error: ‘revert_simd_traits’ 
in namespace ‘xsimd’ does not name a template type
223s56 | using revert_simd_traits = xsimd::revert_simd_traits;
223s   |   ^~
223s /usr/include/xtensor/xtensor_simd.hpp:59:30: error: ‘simd_type’ in 
namespace ‘xsimd’ does not name a template type



Not marking Severity: Serious since xsimd's own tests pass,
indicating the affected functionality is not critical.

Bug#1053853: RM: xgnokii -- RoQA; NBS; xgnokii has been dropped due to its GTK2 dependency

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal


please remove the cruft xgnokii binary package from sid.


Andreas

Bug#1033012:

[Charles Slivkoff]

I'm going to check the upstream  repository,  but there is definitely one
or more problems here with the systemd unit.

https://github.com/miniupnp/miniupnp

Bug#1012722: wireguard-tools: wg-quick DNS server setup should remove existing /etc/resolv.conf lines

[Daniel Gröber]

Hi Celejar, Mathias,

On Thu, Oct 12, 2023 at 03:36:12PM +0200, Mathias Behrle wrote:
> On Sun, 12 Jun 2022 17:13:29 -0400 Celejar  wrote:
> > I would think that the correct behavior would be for wg-quick to *replace*
> > the existing contents of resolv.conf, rather than just *prepending*
>
> For you this behavior is the desired one, for me not ;). Because I am losing 
> my
> local DNS configuration poiting to my local hosts.

Since you both seem to have a sense of what you want your DNS config to
look like you may want to consider cutting out the middleman and asserting
control of resolv.conf directly. The state of resolv.conf managment on
Linux is unfortunately a huge mess. Me personally I've lost confidence and
patience in the current crop of common tools
(resolvconf/openresolv/systemd-resolved) and so I feel it's worth it for my
purposes.

Here's two approaches I've used to bypass them with caveats and
workarounds:

1) Hand edit /etc/resolv.conf plus chattr +i

This works very well in my testing, none of the managment tools try to lift
the "i" (immutable) fs attribute so the contents stay the way you want them
and any rogue tool just fails to replace/write-to resolv.conf.

One nasty caveat is the current dhclient-script that fails to cleanup the
resolv.conf.tmpXXX file it uses to atomically replace resolv.conf. This can
cause serious blowup in /etc and ENOSPC problems (ask me how I know ;). I
dealt with this by installing a dhclient-enter-hook like so:

$ cat /etc/dhcp/dhclient-enter-hooks.d/disable-resolv-conf
#!/bin/sh
# NOP out function updating resolv.conf as our upstreams like to force DNS
# related dhcp options on us despite not asking for them. Woohoo.
make_resolv_conf() :

Ofc. other tools may fail in similarly hilarious ways, but at least they
wont break DNS ;)

2) Install a symlink to your config at /etc/resolv.conf

AFAICT most mangmagment tools seem to back off when resolv.conf is a
symlink to a location they don't recognize (I've only really tested with
systemd-resolved). This works ok, but the main problem is apparmor (which
only affects some programs). /etc/apparmor.d/abstractions/nameservice has
an explicit list of files programs may read and this doesn't really
allocate any namespace for local system additions:

@{etc_ro}/resolv.conf r,
# On systems where /etc/resolv.conf is managed programmatically, it is
# a symlink to @{run}/(whatever program is managing it)/resolv.conf.

@{run}/{resolvconf,NetworkManager,systemd/resolve,connman,netconfig}/resolv.conf
 r,
@{etc_ro}/resolvconf/run/resolv.conf  r,
@{run}/systemd/resolve/stub-resolv.conf r,
/mnt/wsl/resolv.conf r,

This can be fixed by installing a drop-in such as

$ cat /etc/apparmor.d/abstractions/nameservice.d/local-resolv-conf
  abi ,

@{etc_ro}/resolv.conf.local.* r,

3) apt-get purge-with-a-vengeance resolvconf openresolv systemd-resolveconf && 
apt-pinning

I've had the problem that the offending DNS managment tools get installed
through recommends even though I don't intend for them to be used, I
haven't worked this out yet but I think it'd be reasonably easy to write an
apt preferences snippet to prevent them being installed in all cases.

A final note: I use ifupdown for my network interface managment needs:
ethernet, wifi, vpn (on/off switch) etc. This way I can easily integrate
hooks to configure the DNS on a per-network basis, but if you use something
like NetworkManage as-is this approach means you have to have one static
config you're happy with -- well you can always just copy/symlink
per-network templates into place manually but that seems a hassle.

Let me know your use cases though maybe I can figure something out even for
that case.

--Daniel


signature.asc
Description: PGP signature

Bug#1053852: btrfsd: Segfault in libgobject-2.0.so.0.7800.0[7fcec2dff000+34000]

[Vincent Blut]

Package: btrfsd
Version: 0.2.0-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Matthias,

btrfsd fails to start on my system:

[…]
oct. 12 00:44:41 lamella kernel: btrfsd[29326]: segfault at 5625ebe5fe33 ip 
7f0bf91bec01 sp 7ffc992c1fb8 error 4 in 
libgobject-2.0.so.0.7800.0[7f0bf9193000+34000] likely on CPU 3 (core 1, socket 
0)
oct. 12 13:05:16 lamella kernel: btrfsd[33302]: segfault at 55c2402dc51d ip 
7f8fbe68ec01 sp 7ffc586d53f8 error 4 in 
libgobject-2.0.so.0.7800.0[7f8fbe663000+34000] likely on CPU 2 (core 0, socket 
0)
oct. 12 14:06:03 lamella kernel: btrfsd[36063]: segfault at 5583eef6893b ip 
7f358c23ec01 sp 7ffc0253e1d8 error 4 in 
libgobject-2.0.so.0.7800.0[7f358c213000+34000] likely on CPU 0 (core 0, socket 
0)
oct. 12 15:06:44 lamella kernel: btrfsd[39068]: segfault at 55f98253392b ip 
7f6bc3b89c01 sp 7fff7597e4f8 error 4 in 
libgobject-2.0.so.0.7800.0[7f6bc3b5e000+34000] likely on CPU 2 (core 0, socket 
0)
oct. 12 16:06:46 lamella kernel: btrfsd[40261]: segfault at 55a61769a534 ip 
7fcec2e2ac01 sp 7ffcaad664a8 error 4 in 
libgobject-2.0.so.0.7800.0[7fcec2dff000+34000] likely on CPU 2 (core 0, socket 
0)


Here is the backtrace:

(gdb) thread apply all bt

Thread 4 (Thread 0x75ffd6c0 (LWP 45447) "gdbus"):
#0  0x779b1a1f in __GI___poll (fds=0x7fffec000b90, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x77ec1237 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77ec1bdf in g_main_loop_run () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77d3bdfa in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x77eee9e1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7793e3ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x779bea4c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 3 (Thread 0x767fe6c0 (LWP 45446) "gmain"):
#0  0x779b1a1f in __GI___poll (fds=0x55575a40, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x77ec1237 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77ec18f0 in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77ec1941 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77eee9e1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7793e3ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x779bea4c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 2 (Thread 0x76fff6c0 (LWP 45445) "pool-spawner"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x77f1c9a4 in g_cond_wait () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
- --Type  for more, q to quit, c to continue without paging--c
#2  0x77e8b15b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77eef06a in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77eee9e1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7793e3ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x779bea4c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 1 (Thread 0x773e5900 (LWP 45441) "btrfsd"):
#0  0x77e40c01 in g_type_check_instance_is_fundamentally_a () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1  0x77e2187d in g_object_unref () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2  0xa119 in ?? ()
#3  0x8b35 in ?? ()
#4  0x7a5b in ?? ()
#5  0x778dd6ca in __libc_start_call_main 
(main=main@entry=0x78a0, argc=argc@entry=1, 
argv=argv@entry=0x7fffc988) at ../sysdeps/nptl/libc_start_call_main.h:58
#6  0x778dd785 in __libc_start_main_impl (main=0x78a0, argc=1, 
argv=0x7fffc988, init=, fini=, 
rtld_fini=, stack_end=0x7fffc978) at ../csu/libc-start.c:360
#7  0x7ba1 in ?? ()

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZSgLGQAKCRAQn1qAt/bg
AZeRAQDeJWUcwAOPFd//0QXVJx+hwTyUpFsJFoJqBnWsiApA5gD9Gws81Xw6zrDY
V8fjtAM1ebiJBPksIkOnK+9AVF61zg4=
=wiTQ
-END PGP SIGNATURE-

Bug#733647: Closing old gnome bugs

[Jeremy Bícha]

Unfortunately, we are not always able to respond to bug reports quickly.

The version of Debian that this issue was reported against is no
longer supported and I was unable to duplicate this issue on the
latest Debian stable release with the information provided here.
Therefore, I am closing this bug.

Feel free to create a new bug report if you are still experiencing
this issue or a similar one on a supported Debian release.

Thank you,
Jeremy Bícha

Bug#723104: Closing old gnome bugs

[Jeremy Bícha]

Unfortunately, we are not always able to respond to bug reports quickly.

The version of Debian that this issue was reported against is no
longer supported and I was unable to duplicate this issue on the
latest Debian stable release with the information provided here.
Therefore, I am closing this bug.

Feel free to create a new bug report if you are still experiencing
this issue or a similar one on a supported Debian release.

Thank you,
Jeremy Bícha

Bug#1053851: glx-diversions generates a dangling symlink for libGLX_indirect.so.0

[Andreas Beckmann]

Control: tag -1 wontfix
Control: close -1

On 12/10/2023 16.34, Vincent Lefevre wrote:

/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 is
a symbolic link that points to an inexistent target:

cventin% ls -l /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0
lrwxrwxrwx 1 root root 16 2023-09-29 07:38:02 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 -> libGLX_mesa.so.0
cventin% ls -lL /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0
ls: cannot access 
'/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0': No such file or 
directory


Which does not really matter, since the symlink at this location is not 
being used at all. It's only needed to restore the correct link once the 
diversion gets removed.


glx-alternatives installs a replacement alternative as 
/usr/lib//libGLX_indirect.so.0 which is getting used.



Andreas

Bug#1053851: glx-diversions generates a dangling symlink for libGLX_indirect.so.0

[Vincent Lefevre]

Package: glx-diversions
Version: 1.2.2
Severity: normal

/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 is
a symbolic link that points to an inexistent target:

cventin% ls -l /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0
lrwxrwxrwx 1 root root 16 2023-09-29 07:38:02 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 -> libGLX_mesa.so.0
cventin% ls -lL /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0
ls: cannot access 
'/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0': No such file or 
directory

and it comes from glx-diversions:

cventin% dlocate /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0
diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx-diversions

-- Package-specific info:
Diversions:
diversion of /usr/lib/aarch64-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.0.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.0.0 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.7.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.7.0 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1.2.0 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.0.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.7.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.7.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLX_indirect.so.0 by 
glx-diversions
diversion 

Bug#1053413: RFP: tox-current-env -- tox plugin to run tests in current Python environment

[Bo YU]

Control: retitle -1 ITP: tox-current-env -- tox plugin to run tests in
current Python environment
Control: owner -1 Bo YU 

On Wed, Oct 4, 2023 at 12:15 AM Antoine Beaupre  wrote:
>
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: debian-pyt...@lists.debian.org
>
> * Package name: tox-current-env
>   Version : 0.0.11
>   Upstream Contact: Miro Hrončok 
> * URL : https://github.com/fedora-python/tox-current-env
> * License : MIT
>   Programming Lang: Python
>   Description : tox plugin to run tests in current Python environment
>
> The tox-current-env plugin adds these options:
>
> tox --current-env
> Runs the tox testenv's commands in the current Python environment
> (that is, the environment where tox is invoked from and installed
> in). Unlike regular tox invocation, this installs no dependencies
> declared in deps. An attempt to run this with a Python version
> that doesn't match will fail (if tox is invoked from an Python 3.7
> environment, any non 3.7 testenv will fail).
>
> tox --print-deps-to=FILE
> Instead of running any commands, simply prints the declared
> dependencies in deps to the specified FILE. This is useful for
> preparing the current environment for tox --current-env. Use - for
> FILE to print to standard output.
>
> tox --print-extras-to=FILE
> Instead of running any commands, simply prints the names of the
> declared extras in extras to the specified FILE. This is useful
> for preparing the current environment for tox --current-env. Use -
> for FILE to print to standard output.
>
> It is possible to use the two printing options together, as long as
> the FILE is different.
>
> Invoking tox without any of the above options should behave as regular
> tox invocation without this plugin. Any deviation from this behavior
> is considered a bug.
>
> The plugin disables tox's way of providing a testing environment, but
> assumes that you supply one in some other way. Always run tox with
> this plugin in a fresh isolated environment, such as Python
> virtualenv, Linux container or chroot. See other caveats below.
>
> Obviously, tox was created to run tests in isolated Python virtual
> environments. The --current-env flag totally defeats the purpose of
> tox. Why would anybody do that, you might ask?
>
> Well, it turns out that tox became too popular and gained another purpose.
>
> The Python ecosystem now has formal specifications for many pieces of
> package metadata like versions or dependencies. However, there is no
> standardization yet for declaring test dependencies or running
> tests. The most popular de-facto standard for that today is tox, and
> we expect a future standard to evolve from tox.ini. This plugin lets
> us use tox's dependency lists and testing commands for environments
> other than Python venvs.
>
> We hope this plugin will enable community best practices around tox
> configuration to grow to better accomodate non-virtualenv environments
> in general – for example, Linux distros, Conda, or containers.
>
> Specifically, this plugin was created for Fedora's needs. When we
> package Python software as RPM packages, we try to run the project's
> test suite during package build. However, we need to test if the
> software works integrated into Fedora, not with packages downloaded
> from PyPI into a fresh environment. By running the tests in current
> environment, we can achieve that.
>
> 
>
> In my case, I want to avoid constantly downloading unverified code
> from the internet, or, even worse, *compile* code (e.g. for
> python3-ldap, in my case) which involves a whole other pile of stuff
> to install.
>
> Other Tox plugins are currently maintained by the Python team (and
> Peter Pentchev), so it would probably be the same for this one.

OK, I will package it and maintain under DPT, thanks.

BR,
Bo

Bug#1053812: apt-listchanges showing old changelog entries during upgrade

[Jonathan Kamens]

Again, I hate to do this, but until we've figured this out, can the two 
of you please do me a favor? Before you run each apt upgrade, please 
save a backup copy of /var/lib/apt/listchanges, then if the problem 
happens during the upgrade, please send me the backup copy of the file 
as well as the new version of the same file that should have been 
modified during the upgrade. I think this must have something to do with 
what's in your seen database but I am unable to recreate a database that 
triggers the issue, so I think I need to see yours.


There's nothing private in the database, it's just package names, MD5 
checksums of changelog entries, and timestamps, though I suppose if you 
have packages on your computer you don't want people to know you've 
installed then that's private. :shrug: Your call. If you don't want to 
post it in the bug you can email it to me privately and I certainly 
won't post it anywhere.


Sorry for the trouble and thanks for the help.

jik

Bug#1033130: Info received (gcc-snapshot: FTBFS on hppa - sys/mman.h: No such file or directory)

[John David Anglin]

On 2023-10-12 2:09 a.m., Matthias Klose wrote:

On 07.10.23 21:43, John David Anglin wrote:

This problem seems to have disappeared. Last build of gcc-13 and last couple of 
builds of gcc-snapshot
have been successful.


yes, that because of a local patch:

https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/patches/hppa64-libgcov-fallback.diff

Thanks for adding the patch.

Technically, |_PA_RISC2_0 is not specific to hppa64. You also need __LP64__. 
But as long as the 32-bit
compiler is not built with a PA 2.0 option, _PA_RISC2_0 will work.

So,there's still an issue with the include directories for builds done using 
buildd. As I mentioned
previously, the error doesn't occur for builds done outside buildd using 
dpkg-buildpackage.
|

--
John David Anglin  dave.ang...@bell.net

Bug#967706: pommed: depends on deprecated GTK 2

[Bastian Germann]

On Sat, 12 Aug 2023 15:00:08 +0200 Bastian Germann  wrote:
Please just drop gpomme. The rest of the packages seem to be working 
without it.


I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru pommed-1.39~dfsg/debian/changelog pommed-1.39~dfsg/debian/changelog
--- pommed-1.39~dfsg/debian/changelog   2020-08-04 19:18:05.0 +
+++ pommed-1.39~dfsg/debian/changelog   2023-10-12 13:58:10.0 +
@@ -1,3 +1,10 @@
+pommed (1.39~dfsg-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop gpomme. (Closes: #967706, #405936)
+
+ -- Bastian Germann   Thu, 12 Oct 2023 13:58:10 +
+
 pommed (1.39~dfsg-5.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pommed-1.39~dfsg/debian/control pommed-1.39~dfsg/debian/control
--- pommed-1.39~dfsg/debian/control 2020-08-04 18:53:25.0 +
+++ pommed-1.39~dfsg/debian/control 2023-10-12 13:57:22.0 +
@@ -6,7 +6,7 @@
   Thibaut Paumard 
 Build-Depends: debhelper (>= 11), libpci-dev [i386 amd64],
libofapi-dev (>= 0git20070620) [powerpc], libconfuse-dev, 
libasound2-dev,
-   libaudiofile-dev, libgtk2.0-dev, libdbus-1-dev, libdbus-glib-1-dev,
+   libaudiofile-dev, pkg-config, libdbus-1-dev, libdbus-glib-1-dev,
libx11-dev, libxext-dev, libxpm-dev
 Standards-Version: 4.1.4
 
@@ -22,18 +22,6 @@
  pommed also monitors the ambient light sensors to automatically
  light up the keyboard backlight on machines that support it.
 
-Package: gpomme
-Architecture: i386 amd64 powerpc
-Depends: ${shlibs:Depends}, ${misc:Depends}, pommed (>= 1.29~dfsg-1), dbus
-Description: graphical client for pommed
- pommed handles the hotkeys found on the Apple MacBook Pro, MacBook Air,
- MacBook, PowerBook and iBook laptops and adjusts the LCD backlight, sound
- volume, keyboard backlight or ejects the CD-ROM drive accordingly.
- .
- gpomme is a graphical client for pommed. It listens for signals sent by
- pommed on D-Bus and displays the action taken by pommed along with the
- current state associated to this action.
-
 Package: wmpomme
 Architecture: i386 amd64 powerpc
 Depends: ${shlibs:Depends}, ${misc:Depends}, pommed (>= 1.29~dfsg-1), dbus
diff -Nru pommed-1.39~dfsg/debian/gpomme.dirs 
pommed-1.39~dfsg/debian/gpomme.dirs
--- pommed-1.39~dfsg/debian/gpomme.dirs 2020-08-04 18:53:25.0 +
+++ pommed-1.39~dfsg/debian/gpomme.dirs 1970-01-01 00:00:00.0 +
@@ -1,3 +0,0 @@
-usr/bin
-usr/share/pixmaps
-
diff -Nru pommed-1.39~dfsg/debian/gpomme.docs 
pommed-1.39~dfsg/debian/gpomme.docs
--- pommed-1.39~dfsg/debian/gpomme.docs 2020-08-04 18:53:25.0 +
+++ pommed-1.39~dfsg/debian/gpomme.docs 1970-01-01 00:00:00.0 +
@@ -1,2 +0,0 @@
-README
-
diff -Nru pommed-1.39~dfsg/debian/gpomme.manpages 
pommed-1.39~dfsg/debian/gpomme.manpages
--- pommed-1.39~dfsg/debian/gpomme.manpages 2020-08-04 18:53:25.0 
+
+++ pommed-1.39~dfsg/debian/gpomme.manpages 1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-gpomme/gpomme.1
diff -Nru pommed-1.39~dfsg/debian/gpomme.menu 
pommed-1.39~dfsg/debian/gpomme.menu
--- pommed-1.39~dfsg/debian/gpomme.menu 2020-08-04 18:53:25.0 +
+++ pommed-1.39~dfsg/debian/gpomme.menu 1970-01-01 00:00:00.0 +
@@ -1,13 +0,0 @@
-?package(gpomme):needs="X11" section="Applications/System/Monitoring"\
-  title="gpomme" command="/usr/bin/gpomme" \
-  icon="/usr/share/pixmaps/gpomme.xpm" \
-  description="gpomme provides visual feedback in the form of an \
-  On-Screen Display (OSD) when adjusting LCD brightness, sound level \
-  and keyboard brightness on Apple laptops, in conjunction with the \
-  pommed daemon"
-
-?package(gpomme):needs="X11" section="Applications/System/Monitoring"\
-  title="gpomme configuration GUI" command="/usr/bin/gpomme -c" \
-  icon="/usr/share/pixmaps/gpomme.xpm" \
-  description="The configuration GUI for gpomme allows tweaking some \
-  parameters for the On-Screen Display (OSD) displayed by gpomme"
diff -Nru pommed-1.39~dfsg/debian/rules pommed-1.39~dfsg/debian/rules
--- pommed-1.39~dfsg/debian/rules   2020-08-04 18:53:25.0 +
+++ pommed-1.39~dfsg/debian/rules   2023-10-12 13:58:10.0 +
@@ -2,6 +2,9 @@
 %:
dh $@
 
+override_dh_auto_build:
+   dh_auto_build -- pommed wmpomme
+
 override_dh_auto_install:
# Install pommed
cp pommed/pommed $(CURDIR)/debian/pommed/usr/sbin/
@@ -18,33 +21,6 @@
 endif
cp dbus-policy.conf 
$(CURDIR)/debian/pommed/etc/dbus-1/system.d/pommed.conf
 
-   # Install gpomme
-   cp gpomme/gpomme $(CURDIR)/debian/gpomme/usr/bin/
-
-   mkdir -p $(CURDIR)/debian/gpomme/usr/share/applications
-   cp gpomme/gpomme.desktop $(CURDIR)/debian/gpomme/usr/share/applications/
-   cp gpomme/gpomme-c.desktop 
$(CURDIR)/debian/gpomme/usr/share/applications/
-
-   for s in 16x16 22x22 24x24 32x32 36x36 48x48 64x64 72x72 96x96 128x128 
192x192; do \
-

Bug#1053812: apt-listchanges showing old changelog entries during upgrade

[Niko Sandschneider]

I'm afraid it really does happen with 4.1:


niko@niko-desktop:~$ cat /var/log/dpkg.log | grep apt-listchanges | tail -3
2023-10-10 11:28:51 status unpacked apt-listchanges:all 4.1
2023-10-10 11:28:51 status half-configured apt-listchanges:all 4.1
2023-10-10 11:28:52 status installed apt-listchanges:all 4.1


And the issue is still there. It happened e.g. with today's chromium update.

Bug#1040057: slixmpp: autopkgtest regression on arm64: Segmentation fault

[Martin]

On 2023-10-12 12:31, Paul Gevers wrote:
> If I rename tests/test_stanza_error.py to something else such that
> it's not automatically run as test, the segfault doesn't happen.

Thanks, Paul, that helped a lot!

In xmpp:slix...@muc.poez.io?join Link Mauve came up with the idea to run
the test in pdb, and that's how it segfaults on amd64, too, not only on
arm64:

$ python3 -m pdb ./run_tests.py tests/test_stanza_error.py
> /usr/local/src/debian/xmpp-team/slixmpp/run_tests.py(3)()
-> import sys
(Pdb) r
Using slower stringprep, consider compiling the faster cython/libidn one.
testCondition (tests.test_stanza_error.TestErrorStanzas.testCondition)
Test modifying the error condition. ... ok
testDelCondition (tests.test_stanza_error.TestErrorStanzas.testDelCondition)
Test that deleting error conditions doesn't remove extra elements. ... ok
testDelText (tests.test_stanza_error.TestErrorStanzas.testDelText)
Test deleting the text of an error. ... ok
testSetup (tests.test_stanza_error.TestErrorStanzas.testSetup)
Test setting initial values in error stanza. ... ok

--
Ran 4 tests in 1.149s

OK

--Return--
> /usr/local/src/debian/xmpp-team/slixmpp/run_tests.py(73)()->None
-> sys.exit(not result.wasSuccessful())
(Pdb) quit
Segmentation fault

This is the backtrace:

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
PyObject_CallOneArg (func=0x0, arg=0x7fffefacd7e0) at ../Objects/call.c:376
376 ../Objects/call.c: Bad file descriptor.
(gdb) bt
#0  PyObject_CallOneArg (func=0x0, arg=0x7fffefacd7e0) at ../Objects/call.c:376
#1  0x0056fcea in PyObject_Repr (v=0x7fffefacd7e0) at 
../Objects/object.c:433
#2  0x00521179 in unicode_fromformat_arg (vargs=0x7fffe160, 
f=, writer=0x7fffe180) at ../Objects/unicodeobject.c:3036
#3  PyUnicode_FromFormatV (format=, vargs=) at 
../Objects/unicodeobject.c:3100
#4  0x00560da7 in _PyErr_FormatV (vargs=0x7fffe200, format=0x858991 
"%R is not in deque", 
exception=0x947140 <_PyExc_ValueError.lto_priv.0>, tstate=0xa840d8 
<_PyRuntime+166328>) at ../Python/errors.c:1078
#5  PyErr_Format (exception=0x947140 <_PyExc_ValueError.lto_priv.0>, 
format=0x858991 "%R is not in deque") at ../Python/errors.c:1120
#6  0x00480988 in deque_remove (deque=0x7fffef951e40, 
value=0x7fffefacd7e0) at ../Modules/_collectionsmodule.c:1256
#7  0x00567b4f in method_vectorcall_O (func=0x774823e0, 
args=0x7fffef9aca98, nargsf=, kwnames=0x0)
at ../Objects/descrobject.c:481
#8  0x0053ac2c in _PyObject_VectorcallTstate (kwnames=, 
nargsf=, args=, 
callable=0x774823e0, tstate=0xa840d8 <_PyRuntime+166328>) at 
../Include/internal/pycore_call.h:92
#9  PyObject_Vectorcall (callable=0x774823e0, args=, 
nargsf=, kwnames=) at ../Objects/call.c:299
#10 0x0052b940 in _PyEval_EvalFrameDefault (tstate=, 
frame=, throwflag=)
at ../Python/ceval.c:4772
#11 0x00641aaa in _PyEval_EvalFrame (throwflag=, 
frame=0x7fffef9aca30, tstate=0xa840d8 <_PyRuntime+166328>)
at ../Include/internal/pycore_ceval.h:73
#12 gen_send_ex2 (gen=gen@entry=0x7fffef9ac9e0, arg=0x959cc0 <_Py_NoneStruct>, 
presult=presult@entry=0x7fffe588, exc=exc@entry=1, 
closing=closing@entry=1) at ../Objects/genobject.c:219
#13 0x00642588 in gen_send_ex (gen=gen@entry=0x7fffef9ac9e0, 
arg=, exc=exc@entry=1, closing=closing@entry=1)
at ../Objects/genobject.c:287
#14 0x005859e8 in gen_close (gen=0x7fffef9ac9e0, args=) 
at ../Objects/genobject.c:391
#15 0x006a32ef in gen_close_iter (yf=) at 
../Objects/genobject.c:327
#16 0x00585a44 in gen_close (gen=gen@entry=0x74258c20, 
args=args@entry=0x0) at ../Objects/genobject.c:385
#17 0x00585249 in _PyGen_Finalize (self=0x74258c20) at 
../Objects/genobject.c:96
#18 0x0050b543 in finalize_garbage (tstate=0xa840d8 
<_PyRuntime+166328>, collectable=0x7fffe710) at ../Modules/gcmodule.c:978
#19 gc_collect_main (tstate=0xa840d8 <_PyRuntime+166328>, generation=2, 
n_collected=0x0, n_uncollectable=0x0, nofail=1) at ../Modules/gcmodule.c:1274
#20 0x0065570c in _PyGC_CollectNoFail.isra.0 (tstate=) 
at ../Modules/gcmodule.c:2110
#21 0x0064698a in Py_FinalizeEx () at ../Python/pylifecycle.c:1833
#22 0x0064f974 in Py_RunMain () at ../Modules/main.c:682
#23 0x006275c7 in Py_BytesMain (argc=, argv=) at ../Modules/main.c:734
#24 0x77cc31ca in __libc_start_call_main (main=main@entry=0x627530 
, argc=argc@entry=5, argv=argv@entry=0x7fffea78)
at ../sysdeps/nptl/libc_start_call_main.h:58
#25 0x77cc3285 in __libc_start_main_impl (main=0x627530 , argc=5, 
argv=0x7fffea78, init=, fini=, 
rtld_fini=, stack_end=0x7fffea68) at 
../csu/libc-start.c:360
#26 0x00627461 in _start ()

Am I right, that the error is in Python itself?

And maybe it is already solved: The error does not occur with
Python 3.12 anymore, at least not on 

Bug#1053812: apt-listchanges showing old changelog entries during upgrade

[Jonathan Kamens]

I really hate to do this, but I have spent hours constructing test cases 
and poring over the code and I can't reproduce this or figure out how it 
happened, so I need to ask... can you both please check your 
/var/log/dpkg.log and make 100% certain that you had apt-listchanges 4.1 
(not 4.0) installed before the apt run which showed you old changelog 
entries? Before I spend even more time pulling my hair out trying to 
figure out how this happened I need to make absolutely sure it really 
happened in 4.1, not 4.0. Thanks.


On 10/11/23 15:45, Niko Sandschneider wrote:

I see similar issues with apt-listchanges 4.1 while updating several
other packages:

For the curl update from 8.3.0-2 to 8.3.0-3 apt-listchanges shows all
changes starting from curl 7.65.1-1.

For the debianutils update from 5.13 to 5.14  apt-listchanges shows all
changes starting from debianutils 4.8.6.2.

For the firefox update from 118.0-1 to 118.0.2-1 apt-listchanges shows
all changes starting from firefox 68.0-1.

Bug#967709: presage: depends on deprecated GTK 2

[Bastian Germann]

I am going to upload a NMU to DELAYED/10 with the enclosed changes to fix this.diff -Nru presage-0.9.1/debian/changelog presage-0.9.1/debian/changelog
--- presage-0.9.1/debian/changelog  2022-11-27 13:02:27.0 +
+++ presage-0.9.1/debian/changelog  2023-10-12 13:24:57.0 +
@@ -1,3 +1,10 @@
+presage (0.9.1-2.6) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop gprompter. (Closes: #967709)
+
+ -- Bastian Germann   Thu, 12 Oct 2023 13:24:57 +
+
 presage (0.9.1-2.5) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru presage-0.9.1/debian/control presage-0.9.1/debian/control
--- presage-0.9.1/debian/control2022-11-27 13:02:27.0 +
+++ presage-0.9.1/debian/control2023-10-12 13:24:57.0 +
@@ -9,7 +9,6 @@
  libncurses5-dev | libncurses-dev,
  help2man,
  libcppunit-dev (>= 1.9.6) ,
- libgtk2.0-dev (>= 2.12),
 Build-Depends-Indep: doxygen, graphviz
 Standards-Version: 4.6.1
 Homepage: https://presage.sourceforge.net/
@@ -95,16 +94,3 @@
  .
  This package contains the header files needed to compile applications
  or shared objects that use libpresage.
-
-Package: gprompter
-Section: misc
-Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Description: intelligent predictive GTK+ text editor
- gprompter is a cross-platform predictive text editor, based on
- presage, the intelligent predictive text entry platform.
- .
- gprompter displays predictions in a contextual pop-up box as each
- letter is typed. Predictions can be easily selected and inserted in
- the document.
-
diff -Nru presage-0.9.1/debian/gprompter.docs 
presage-0.9.1/debian/gprompter.docs
--- presage-0.9.1/debian/gprompter.docs 2022-11-27 13:02:27.0 +
+++ presage-0.9.1/debian/gprompter.docs 1970-01-01 00:00:00.0 +
@@ -1,5 +0,0 @@
-AUTHORS
-README
-NEWS
-THANKS
-TODO
diff -Nru presage-0.9.1/debian/gprompter.install 
presage-0.9.1/debian/gprompter.install
--- presage-0.9.1/debian/gprompter.install  2022-11-27 13:02:27.0 
+
+++ presage-0.9.1/debian/gprompter.install  1970-01-01 00:00:00.0 
+
@@ -1,6 +0,0 @@
-usr/bin/gprompter
-usr/share/man/man1/gprompter.1
-usr/share/pixmaps/gprompter.xpm
-usr/share/pixmaps/gprompter.png
-usr/share/icons/hicolor/scalable/apps/gprompter.svg
-usr/share/applications/gprompter.desktop
diff -Nru presage-0.9.1/debian/patches/series 
presage-0.9.1/debian/patches/series
--- presage-0.9.1/debian/patches/series 2022-11-27 13:02:27.0 +
+++ presage-0.9.1/debian/patches/series 2023-10-12 13:24:57.0 +
@@ -1,4 +1,3 @@
-fix-bug-776720.patch
 fix-bug-811758-gcc6.patch
 c++17.patch
 format-security.patch

Bug#1053535: Add support for timestamps with nanoseconds [patch]

[markus]

Hello,

> i'm not at all convinced that this is a useful change, in particular
> in a backup/restore tool.

A restore tool should, as its name says, restore the backup as most pristine as 
possible. Currently dump/restore (on linux) restores timestamps only with 
seconds, dropping micro- or nanoseconds.

> please provide more information as to what benefits this change is
> expected to provide,

For more than a decade linux kernels and ext2/3/4 filesystems support 
timestamps with nanoseconds. Most userland utilities have been updated to use 
it. dump/restore is overdue. It is a severe deficit loosing a part of time 
information when restoring a backup. I believe nowadays most expect that a 
backup tool uses all facilities the underlying system supports.

> and how those benefits are supposed to outweight
> the massive downside of complete incompatibility with existing backups.

Incompatibility with existing backups is an issue only, if backups are 
archived. Usually backups are overwritten regularly. (In my case every two 
months.)

In order to prevent a mismatch a version information at the beginng of a 
dumpfile (or tape) would be useful. I did not manage to find the code locations 
where dump begins to write resp. where restore begins to read.

I have found restore contains some code to convert "old headers". I could not 
figure out, what this means. The code for opening and reading a dumpfile is 
rather complicated and not well documented.

Please note the patch does not introduce a "complete incompatibility". I did 
some tests with mixed combinations with old/new dumps and old/new restores. 
Directories and files where restored correctly but with erroneous timestamps.

Please note there already is a mismatch between sizeof(dinode) and 
sizeof(ext2_inode) before applying the patch. assert(sizeof(dinode_old) <= 
sizeof(ext2_inode)) failes. See compat/include/bsdcompat.h and dump/traverse.c.

I have sent my patch in in order to share it with the community.
May be someone else picks it up and adds version information to the dumpfile.

Markus

Bug#1012722: wireguard-tools: wg-quick DNS server setup should remove existing /etc/resolv.conf lines

[Mathias Behrle]

On Sun, 12 Jun 2022 17:13:29 -0400 Celejar  wrote:
> Package: wireguard-tools
> Version: 1.0.20210914-1
> Severity: normal
> 
> I use wg-quick to setup a tunnel to my home LAN from various wireless
> (WiFi) networks that I don't control. My /etc/wireguard/wg0.conf
> contains the line:
> 
> DNS = yy.yy.yy.yy
> 
> where yy.yy.yy.yy is a DNS server on my LAN.
> 
> With a typical WiFi network, when I initially connect to it,
> /etc/resolv.conf becomes populated with something like the following:
> 
> nameserver xx.xx.xx.xx
> search nnn.nnn.nnn
> 
> When I then do 'wg-quick' up, resolv.conf ends up like this:
> 
> nameserver yy.yy.yy.yy
> nameserver xx.xx.xx.xx
> search nnn.nnn.nnn
> 
> So DNS queries will generally go through my designated DNS server, which
> is good, but if something goes wrong with my server, queries will leak
> out to the DNS server supplied by the WiFi network, which is not good.
> Similarly, queries for addresses like 'example.com.nnn.nnn.nnn'
> sometimes end up going out into the DNS system, which is also not good.
> 
> I would think that the correct behavior would be for wg-quick to *replace*
> the existing contents of resolv.conf, rather than just *prepending* the
> specified DNS server. I understand that as per the man page, I can
> presumably get this behavior by using the PostUp and PostDown keys, but
> I think the default should be changed, or at least that users should be
> warned of the leak potential in the documentation.


I just have setup wireguard-tools together with openresolv and it behaves
exactly as you like it: it replaces completely the DNS servers in resolv.conf.

For you this behavior is the desired one, for me not ;). Because I am losing my
local DNS configuration poiting to my local hosts.

Anyway I think we see, that there is no general behavior that suits all users...

Cheers,
Mathias

Bug#1053745: dateutils: broken symlinks: dateutils.dround -> dateroud, dateutils.dround.1.gz -> dateroud.1.gz

[Vincent Lefevre]

Control: tags -1 patch

On 2023-10-10 14:14:59 +0800, Paul Wise wrote:
> dateutils 0.4.10-2 introduced two broken symlinks:
>
>    /usr/bin/dateutils.dround -> dateroud
>/usr/share/man/man1/dateutils.dround.1.gz -> dateroud.1.gz
> 
> This appears to be because of a typo in the symlink creation,
> since the target is dateroud but dateround exists instead.

I've found that too. This makes the dateutils.dround command and
"man dateutils.dround" fail (since the target doesn't exist).

I've attached a patch.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--- a/debian/links
+++ b/debian/links
@@ -2,7 +2,7 @@
 ./usr/bin/dateconv ./usr/bin/dateutils.dconv
 ./usr/bin/datediff ./usr/bin/dateutils.ddiff
 ./usr/bin/dategrep ./usr/bin/dateutils.dgrep
-./usr/bin/dateroud ./usr/bin/dateutils.dround
+./usr/bin/dateround./usr/bin/dateutils.dround
 ./usr/bin/dateseq  ./usr/bin/dateutils.dseq
 ./usr/bin/datesort ./usr/bin/dateutils.dsort
 ./usr/bin/datetest ./usr/bin/dateutils.dtest
@@ -12,7 +12,7 @@
 ./usr/share/man/man1/dateconv.1.gz 
./usr/share/man/man1/dateutils.dconv.1.gz
 ./usr/share/man/man1/datediff.1.gz 
./usr/share/man/man1/dateutils.ddiff.1.gz
 ./usr/share/man/man1/dategrep.1.gz 
./usr/share/man/man1/dateutils.dgrep.1.gz
-./usr/share/man/man1/dateroud.1.gz 
./usr/share/man/man1/dateutils.dround.1.gz
+./usr/share/man/man1/dateround.1.gz
./usr/share/man/man1/dateutils.dround.1.gz
 ./usr/share/man/man1/dateseq.1.gz  ./usr/share/man/man1/dateutils.dseq.1.gz
 ./usr/share/man/man1/datesort.1.gz 
./usr/share/man/man1/dateutils.dsort.1.gz
 ./usr/share/man/man1/datetest.1.gz 
./usr/share/man/man1/dateutils.dtest.1.gz

Bug#1043070: dh-make-golang: FTBFS

[Paul Mars]

I investigated this and opened an issue here
https://github.com/Debian/dh-make-golang/issues/200 to suggest some
solutions.


Paul Mars

Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install

[Niels Thykier]

Gioele Barabucci:

On 12/10/23 14:11, Niels Thykier wrote:

```
debian/tmp/usr/share/man/*/man1/foo.1
```

is correctly expanded by dh_install (`d/pkg.install`) but it causes 
dh_installman (`d/pkg.manpages`) to fail.


Whatever problem you are experiencing, it is *not* that 
`dh_installman`does not support globs, because definitely does as 
debhelper itself would FTBFS otherwise (`debian/debhelper.mapages` 
includes globs).


Hi,

maybe it is the combination of dh_installman + dh-exec?

[...]

Regards,



Behaviour is as documented in `man 7 debhelper` under the "Executable 
debhelper config files":


"""
Executable debhelper config files


   When  using executable debhelper config files, please be aware of
   the following:

 * [...]

   Otherwise,  the  output will be used exactly as‐is.  Notably,
   debhelper will **not expand  wildcards** or  strip  comments
   or strip whitespace in the output.
"""
(emphasis mine)


As I see it, debhelper is working exactly as it is documented and 
therefore as it is expected to do.  This restriction of the executable 
config feature has been there from "day 1" of supporting executable 
files (from the days of debhelper/9) and is unlikely to change given the 
current architecture of debhelper.


Best regards,
Niels

Bug#1053850: RM: showq -- ROM; depends on gtkmm2.4

[Bastian Germann]

Source: showq

Please remove showq. It depends on the obsolete gtkmm2.4.
I am going to file a RM bug in a month if nobody comlains.

Bug#885346: clicking mailto link in chromium silently sends empty mail

[Carlos Henrique Lima Melara]

Hey, guys.

I'm going through the bugs opened against neomutt to see what the state
of them are and maybe hopefully close some bugs :-)

Currently on testing, I'm not able to reproduce this bug. So I think it
might have been fixed in chromium, neomutt or xdg (although the bugs
sent here, mutt and xdg, are still open.

I'll wait for more info or someone to double check if it's actually
fixed or the result of some different config I have.

Cheers,
Charles


signature.asc
Description: PGP signature

Bug#1053849: base-files: Allow .d for issue and issue.net

[Bardot Jerome]

Package: base-files
Version: 13
Severity: wishlist
X-Debbugs-Cc: bardot.jer...@gmail.com

Dear Maintainer,

Is there is a way to use the conf.d mecanism for files in base-files.

In my case it's for issue and issue.net.

For explanation i will imagine the directory issue.d .

Maybe it's need an option to concatenate or erase default file.
And maybe the same way to load 10- 20- etc.

Why asking ? 

- to separate my own legal issue and the default one
- no more dpkg question on update/upgrade.



Please let me know if a more relevant place for that new feature exist.
thx for your work


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

Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages base-files depends on:
ii  gawk [awk]  1:5.2.1-2
ii  mawk [awk]  1.3.4.20230808-1

base-files recommends no packages.

base-files suggests no packages.

-- no debconf information

Bug#1053848: RM: seq24 -- ROM; depends on gtkmm2.4

[Bastian Germann]

Source: seq24

Please remove seq24. It depends on the obsolete gtkmm2.4.
I am going to file a RM bug in a month if nobody comlains.

Bug#1053846: src:icingaweb2-module-nagvis: fails to migrate to testing for too long: fails to install

[Paul Gevers]

Source: icingaweb2-module-nagvis
Version: 1.1.1-3
Severity: serious
Control: close -1 1.1.1-4
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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:icingaweb2-module-nagvis has been trying 
to migrate for 31 days [2]. Hence, I am filing this bug. The version in 
unstable fails to install according to piuparts (see [2]).


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=icingaweb2-module-nagvis



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053847: src:golang-github-gocql-gocql: fails to migrate to testing for too long: uploader built arch:all

[Paul Gevers]

Source: golang-github-gocql-gocql
Version: 1.5.2-1
Severity: serious
Control: close -1 1.6.0-1
Tags: sid trixie pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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:golang-github-gocql-gocql has been trying 
to migrate for 31 days [2]. Hence, I am filing this bug.


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


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


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


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=golang-github-gocql-gocql



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053845: src:r-cran-rcppannoy: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: r-cran-rcppannoy
Version: 0.0.20-1
Severity: serious
Control: close -1 0.0.21-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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:r-cran-rcppannoy has been trying to 
migrate for 31 days [2]. Hence, I am filing this bug. The version in 
unstable fails its own autopkgtest.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=r-cran-rcppannoy



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053670: libreoffice-gtk3: Color changes in Libreoffice Draw stopped working with libreoffice-gtk3 installed

[Kerstin Hoef-Emden]

Hi,

Am 11.10.23 um 17:53 schrieb Rene Engelhard:

tag 1053670 + unreproducible

tag 1053670 + moreinfo

thanks


Hi,

Am 08.10.23 um 15:08 schrieb Kerstin Hoef-Emden:

Probably an update of libreoffice and its components.


Probably?

The last update of "libreoffice and its components" was for 12.1 in July.


Actually I didn't use Libreoffice Draw for months, so I don't know when 
this bug appeared. I used Libreoffce Writer and it behaved normally.




If it appeared recently I'd guess some library update... Maybe in 12.2?



  I wanted to prepare a
single picture for a presentation with Libreoffice Draw and realized that
changes of text color stopped working.

Works here. Both in my normal system and in a clean stable VM.

Also filled areas of e.g. circles did
not show the chosen color. Instead all fillings appeared white, colored text
remained black.


Dito.



Also I realized that input
becomes extremely slow, with libreoffice-gtk3 installed. The fan of my cpu
speeds up and letters appear with a long delay while typing in.
That suggests some graphics driver issue? Did something get updated with 
that?


I've got a Radeon Lexa Pro RX550. Package firmware-amd-graphics 
20210315-3 is installed. Driver in use is amdgpu.


Best wishes,

Kerstin


* What exactly did you do (or not do) that was effective (or
  ineffective)?

I purged libreoffice with "apt purge libreoffice*" from the system and
reinstalled it. Thereafter the problem was gone, but the windows and menus had
tiny hardly readable text and low contrast due to a gray background.


Well, yes, that's how LO looks without Gtk3 integration.


Regards,


Rene

Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install

[Gioele Barabucci]

On 12/10/23 14:11, Niels Thykier wrote:

```
debian/tmp/usr/share/man/*/man1/foo.1
```

is correctly expanded by dh_install (`d/pkg.install`) but it causes 
dh_installman (`d/pkg.manpages`) to fail.


Whatever problem you are experiencing, it is *not* that 
`dh_installman`does not support globs, because definitely does as 
debhelper itself would FTBFS otherwise (`debian/debhelper.mapages` 
includes globs).


Hi,

maybe it is the combination of dh_installman + dh-exec?

This is the error message 
:


```
dh_installman: error: open debian/tmp/usr/share/man/*/man1/col.1 failed: 
No such file or directory

install -m0755 -d debian/util-linux-locales/usr/share/man/man1/
	install -p -m0644 
debian/tmp/dh-exec.czfddtTB/usr/share/man/de/man1/rename.ul.1 
debian/util-linux-locales/usr/share/man/man1/rename.ul.1

install -m0755 -d debian/util-linux-locales/usr/share/man/man1/
	install -p -m0644 debian/tmp/usr/share/man/uk/man1/col.1 
debian/util-linux-locales/usr/share/man/man1/col.1

dh_installman: error: Aborting due to earlier error
```

The `manpages` file starts with:

```
#!/usr/bin/dh-exec
debian/tmp/usr/share/man/de/man1/rename.1 => 
/usr/share/man/de/man1/rename.ul.1

debian/tmp/usr/share/man/uk/man1/col.1
debian/tmp/usr/share/man/*/man1/col.1
```

And the files are definitely there:

https://salsa.debian.org/gioele/util-linux/-/jobs/4799773#L2146

```
$ find debian/ | grep man | grep col.1 | sort
debian/tmp/usr/share/man/de/man1/col.1
debian/tmp/usr/share/man/man1/col.1
debian/tmp/usr/share/man/sr/man1/col.1
debian/tmp/usr/share/man/uk/man1/col.1
```

Regards,

--
Gioele Barabucci

Bug#1053844: src:buildlog-consultant: fails to migrate to testing for too long: triggers autopkgtest failures

[Paul Gevers]

Source: buildlog-consultant
Version: 0.0.21-2
Severity: serious
Control: close -1 0.0.34-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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:buildlog-consultant has been trying to 
migrate for 34 days [2]. Hence, I am filing this bug. The version in 
unstable causes the autopkgtest of ognibuild to start failing.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=buildlog-consultant



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053836: libwaffle-dev: missing dependency on libdrm-dev, required by waffle-1.pc

[Simon McVittie]

On Thu, 12 Oct 2023 at 13:04:39 +0100, Simon McVittie wrote:
> libwaffle-dev should depend on libdrm-dev: see attached patch 0001-*
> (it should be amended to fill in the bug number, which I can't know
> in advance).
> 
> However, it no longer needs to depend on libudev-dev: 0002-*.
> 
> I would suggest adding some superficial autopkgtests, which are a
> surprisingly effective way to detect this sort of packaging issue: if run
> before upload, they would also have detected #987940, #987879 and #986517.
> The attached patch 0003-* adds some tests that I originally developed
> for the Steam Runtime - sorry I didn't get round to upstreaming these
> until now.

Patches forwarded to
https://salsa.debian.org/xorg-team/lib/waffle/-/merge_requests/5
with the bug number filled in, now that I have it.

Thanks,
smcv

Bug#1053843: src:user-mode-linux: unsatisfied build dependency in testing: linux-source-6.4

[Paul Gevers]

Source: user-mode-linux
Version: 6.4um1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053842: src:flask-dance: unsatisfied build dependency in testing: python3-sphinxcontrib.seqdiag

[Paul Gevers]

Source: flask-dance
Version: 6.2.0-2.1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053841: src:ironic: unsatisfied build dependency in testing: python3-sphinxcontrib.seqdiag

[Paul Gevers]

Source: ironic
Version: 1:21.4.0-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install

[Niels Thykier]

Control: tags -1 moreinfo

Gioele Barabucci:

Package: debhelper
Version: 13.11.6
Severity: minor

Dear debhelper maintainer,

the line

```
debian/tmp/usr/share/man/*/man1/foo.1
```

is correctly expanded by dh_install (`d/pkg.install`) but it causes 
dh_installman (`d/pkg.manpages`) to fail.


[...]

Regards,



Whatever problem you are experiencing, it is *not* that 
`dh_installman`does not support globs, because definitely does as 
debhelper itself would FTBFS otherwise (`debian/debhelper.mapages` 
includes globs).


Best regards,
Niels

Bug#1053840: src:python-ws4py: unsatisfied build dependency in testing: python3-sphinxcontrib.seqdiag

[Paul Gevers]

Source: python-ws4py
Version: 0.5.1+dfsg1-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053838: src:ruby-gitlab-markup: unsatisfied build dependency in testing: ruby-sanitize

[Paul Gevers]

Source: ruby-gitlab-markup
Version: 1.9.0-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053839: src:ruby-github-markup: unsatisfied build dependency in testing: ruby-sanitize

[Paul Gevers]

Source: ruby-github-markup
Version: 1.7.0+dfsg-6
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053837: src:ruby-html-pipeline: unsatisfied build dependency in testing: ruby-sanitize

[Paul Gevers]

Source: ruby-html-pipeline
Version: 2.14.3-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053836: libwaffle-dev: missing dependency on libdrm-dev, required by waffle-1.pc

[Simon McVittie]

Package: libwaffle-dev
Version: 1.8.0-1
Severity: serious
Tags: patch
Justification: can easily cause FTBFS in related packages

waffle-1.pc now has a dependency on libdrm.pc, but the -dev package that
contains waffle-1.pc does not depend on libdrm-dev, leading to a build
failure similar to #987940, #987879, #986517 in locally-developed software
(in my case the steam-runtime-tools package in Valve's Steam Runtime,
I haven't verified whether piglit has the same problem).

Steps to reproduce
--

In a minimal chroot/container (I used podman), install libwaffle-dev
and try to link a trivial binary to it:

$ podman pull debian:sid-slim
$ podman run --rm -it debian:sid-slim
# apt install build-essential libwaffle-dev pkgconf
# cat > trivial.c <<'EOF'
#undef NDEBUG
#include 
#include 
int main (void)
{
  assert (waffle_enum_to_string (WAFFLE_DONT_CARE) != NULL);
  return 0;
}
EOF
# gcc -otrivial trivial.c $(pkgconf --cflags --libs waffle-1)
# ./trivial

Expected result
---

The test binary compiles, links and runs successfully.

Actual result
-

> Package libdrm was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libdrm.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'libdrm', required by 'waffle-1', not found
> trivial.c:3:10: fatal error: waffle.h: No such file or directory

Workaround
--

Install libdrm-dev, or explicitly build-depend on it in packages that
use waffle.

Solution


libwaffle-dev should depend on libdrm-dev: see attached patch 0001-*
(it should be amended to fill in the bug number, which I can't know
in advance).

However, it no longer needs to depend on libudev-dev: 0002-*.

I would suggest adding some superficial autopkgtests, which are a
surprisingly effective way to detect this sort of packaging issue: if run
before upload, they would also have detected #987940, #987879 and #986517.
The attached patch 0003-* adds some tests that I originally developed
for the Steam Runtime - sorry I didn't get round to upstreaming these
until now.

Thanks,
smcv

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

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

Versions of packages libwaffle-dev depends on:
ii  libegl-dev  1.6.0-1
ii  libgbm-dev  23.2.1-1
ii  libgl-dev   1.6.0-1
ii  libudev-dev 254.5-1
ii  libwaffle-1-0   1.8.0-1
ii  libwayland-dev  1.22.0-2.1
ii  libx11-xcb-dev  2:1.8.7-1

libwaffle-dev recommends no packages.

Versions of packages libwaffle-dev suggests:
pn  libwaffle-doc  

-- no debconf information
>From 11a871f2a49939b00f0e36173c6adeaeec6b551a Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 12 Oct 2023 12:47:39 +0100
Subject: [PATCH 1/3] d/control: Add missing dependency libwaffle-dev ->
 libdrm-dev

libwaffle-dev contains waffle-1.pc, which has a Requires on libdrm;
therefore libwaffle-dev should depend on the package that contains
libdrm.pc, which is libdrm-dev.

I've verified that this is sufficient to allow a simple test program
to be linked to libwaffle in an otherwise minimal container.

Fixes: 5ab2d5a2 "d/control: Upstream replaced libudev dep with libdrm"
Closes: #-1
Signed-off-by: Simon McVittie 
---
 debian/control | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 5e9470a..6d7279f 100644
--- a/debian/control
+++ b/debian/control
@@ -40,7 +40,8 @@ Package: libwaffle-dev
 Architecture: any
 Multi-Arch: same
 Section: libdevel
-Depends: libegl-dev,
+Depends: libdrm-dev,
+ libegl-dev,
  libgbm-dev,
  libgl-dev,
  libudev-dev,
-- 
2.42.0

>From c07071db1f68bdc17738115c4b106dfcc5c03896 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 12 Oct 2023 12:49:53 +0100
Subject: [PATCH 2/3] d/control: libwaffle-dev no longer needs to depend on
 libudev-dev

waffle-1.pc no longer depends on udev.pc.

Fixes: 5ab2d5a2 "d/control: Upstream replaced libudev dep with libdrm"
Signed-off-by: Simon McVittie 
---
 debian/control | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/control b/debian/control
index 6d7279f..1dcb1b6 100644
--- a/debian/control
+++ b/debian/control
@@ -44,7 +44,6 @@ Depends: libdrm-dev,
  libegl-dev,
  libgbm-dev,
  libgl-dev,
- libudev-dev,
  libwaffle-1-0 (= ${binary:Version}),
  libwayland-dev,
  libx11-xcb-dev,
-- 
2.42.0

>From f58220bc366d3c4660febf782baf4ac8eebc23ed Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 12 Oct 2023 12:35:02 

Bug#1053806: Saving user account causes shadow fields to be set to 0 (in LDAP) which causes the account to be expired.

[Daniel Teichmann]

Also I want to clarify that not only the shadowExpire is set to 0 but 
instead all of the following:


shadowMin: 0
shadowMax: 0
shadowWarning: 0
shadowInactive: 0
shadowExpire: 0

Also this isn't bound to the locadm user but to all accounts/users!

--
Daniel Teichmann
DAS-NETZWERKTEAM
GnuPG Key ID 0x8100A778
mail: daniel.teichm...@das-netzwerkteam.de, https://das-netzwerkteam.de

Bug#1053806: Acknowledgement (Saving locadm user causes shadowExpire to be set to 0 (in LDAP) which causes the account to be expired.)

[Daniel Teichmann]

Just confirming, that this issue is not fixed with the newest 
fixes/patches on salsa. (ce6138eb0bbad71795bd3d1eb45874c19bbab76c)



--
Daniel Teichmann
DAS-NETZWERKTEAM
GnuPG Key ID 0x8100A778
mail:daniel.teichm...@das-netzwerkteam.de,https://das-netzwerkteam.de

Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3

[Luca Boccassi]

On Thu, 12 Oct 2023 13:11:05 +0200 Michael Biebl 
wrote:
> On Wed, 20 Sep 2023 21:41:59 +0200 Michael Biebl 
wrote:
> > FYI:
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/216
> > 
> 
> To mitigate this issue for the time being, I suggest we simply remove
> /usr/lib/kernel/install.d/60-ukify.install from the systemd package
(or 
> ship in /usr/share/doc/systemd/examples, so users could copy it to 
> /etc/kernel/install.d/)

There's no need to do that and break everyone else, if somebody doesn't
want to install python3 for some bogus reason they can just mask the
script in /etc/kernel/install.d/ using the usual pattern.

-- 
Kind regards,
Luca Boccassi


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

Bug#1053835: a patch for loong64 in python3.12

[liuxiang]

Package: python3.12
Version: 3.12.0
Severity: wishlist
Tags: patch
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear python3.12 maintainers,

 There need a patch for loong64 arch in debian/multiarch.h.
 If you have any questions, you can contact me at any time.


thanks,
Xiang Liu

--- a/multiarch.h	2023-10-12 11:33:34.300368389 +
+++ b/multiarch.h	2023-10-12 11:28:42.874335964 +
@@ -19,6 +19,20 @@
 #  include 
 # elif defined(__ia64__)
 #  include 
+# elif defined(__loongarch__)
+#  if defined(__loongarch_lp64)
+#   if defined(__loongarch_soft_float)
+#	include 
+#   elif defined(__loongarch_single_float)
+#	include 
+#   elif defined(__loongarch_double_float)
+#	include 
+#   else
+#   	error unknown multiarch location for @header@
+#   endif
+#  else
+#   	error unknown multiarch location for @header@
+#  endif
 # elif defined(__m68k__) && !defined(__mcoldfire__)
 #  include 
 # elif defined(__mips_hard_float) && defined(__mips_isa_rev) && (__mips_isa_rev >=6) && defined(_MIPSEL)

Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3

[Christopher Obbard]

On Thu, 2023-10-12 at 13:11 +0200, Michael Biebl wrote:
> On Wed, 20 Sep 2023 21:41:59 +0200 Michael Biebl  wrote:
> > FYI: https://salsa.debian.org/systemd-team/systemd/-/merge_requests/216
> > 
> 
> To mitigate this issue for the time being, I suggest we simply remove 
> /usr/lib/kernel/install.d/60-ukify.install from the systemd package (or 
> ship in /usr/share/doc/systemd/examples, so users could copy it to 
> /etc/kernel/install.d/)

For what it may be worth, that sounds sensible to me as we don't use
ukify as yet. Do we have any plans to enable that for trixie we could
work on as a follow-up ?

> 
> Splitting off systemd-ukify turns out to be a larger change and with the 
> /usr merge change going on, maybe something we want to avoid/postpone.
> 
> Michael

Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3

[Michael Biebl]

On Wed, 20 Sep 2023 21:41:59 +0200 Michael Biebl  wrote:

FYI: https://salsa.debian.org/systemd-team/systemd/-/merge_requests/216



To mitigate this issue for the time being, I suggest we simply remove 
/usr/lib/kernel/install.d/60-ukify.install from the systemd package (or 
ship in /usr/share/doc/systemd/examples, so users could copy it to 
/etc/kernel/install.d/)


Splitting off systemd-ukify turns out to be a larger change and with the 
/usr merge change going on, maybe something we want to avoid/postpone.


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install

[Gioele Barabucci]

Package: debhelper
Version: 13.11.6
Severity: minor

Dear debhelper maintainer,

the line

```
debian/tmp/usr/share/man/*/man1/foo.1
```

is correctly expanded by dh_install (`d/pkg.install`) but it causes 
dh_installman (`d/pkg.manpages`) to fail.


While it is technically possible to install manpages via d/pkg.install, 
doing so skips all the man-specific processing done by dh_installman, 
for instance handling the  build profile.


It would be nice if dh_installman expanded glob patterns in the same way 
dh_install and other dh helpers do.


Regards,

--
Gioele Barabucci

Bug#1040057: #1040057: slixmpp: autopkgtest regression on arm64: Segmentation fault

[Paul Gevers]

Hi Martin,

On 02-10-2023 08:42, Martin wrote:

Finally, I had some time to run the autopkgtest suite on my own arm64
machine (MNT reform). It did not segfault, so I assume a specific
problem with the C/I system. I have no idea how to debug this, help is
appreciated!


If I rename tests/test_stanza_error.py to something else such that it's 
not automatically run as test, the segfault doesn't happen.


If I run only that test $(./run_tests.py ./tests/test_stanza_error.py) 
or $(./run_tests.py -d ./tests/test_stanza_error.py) the segfault happens.


Because I couldn't spot what would be interesting in the debugging 
output, I decided to run the test with -d on armhf as well... segfault 
when run alone, but only when the test runs isolated.


Obviously then I tried on amd64: when run in isolation also there the 
segfault occurs.


I hope you now have enough leads to pick it up again.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053820: libtomcat9-java: ERR_HTTP2_PROTOCOL_ERROR in browsers after upgrade 9.0.43-2~deb11u7 over u6

[Markus Koschany]

Hello and thanks for the report,

I am currently looking into some test failures caused by the recent changes to
Tomcat's HTTP2 stack. The following tests fail for Tomcat9 now. Your issue
might be related. If we can find out more about the problem, we will address it
in a future update as soon as possible.

[concat] TEST-org.apache.coyote.http2.TestAsync.NIO.txt
[concat] TEST-org.apache.coyote.http2.TestAsync.NIO2.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_5_1.NIO.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_5_1.NIO2.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_5_2.NIO.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_5_2.NIO2.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_6_4.NIO.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_6_4.NIO2.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_6_5.NIO.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Section_6_5.NIO2.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Timeouts.NIO.txt
[concat] TEST-org.apache.coyote.http2.TestHttp2Timeouts.NIO2.txt   



Markus



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

Bug#1046800: texinfo: Fails to build source after successful build

[Preuße]

Control: reopen 1046800

On 13.08.2023 21:21, Lucas Nussbaum wrote:

Hi,


This package fails to build a source package after a successful build
(dpkg-buildpackage ; dpkg-buildpackage -S).


This bug has been closed due to a mistake in a changelog. Reopening.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053551: ftbfs on amd64 when building binary-arch

[Simon Richter]

Hi,

On 10/12/23 15:17, Matthias Klose wrote:

I cannot reproduce this, and I would rather not investigate time into 
that. Please check if you see this with gcc-13 as well.


I suspect it's a missing dependency, so the failure is more dependent on 
"number of threads", and that it succeeds for -b might be coincidence.


I'll try adding a sleep statement to the rule generating this file and 
see if I can get it to reproduce always.


   Simon

Bug#968683: wireguard-tools: missing dependency in wireguard-tools resolvconf - wg-quick up

[Daniel Gröber]

Hi Mathias,

On Thu, Oct 12, 2023 at 11:14:58AM +0200, Mathias Behrle wrote:
> I also ran into this problem, a resolvconf command is required for
> wg-quick

Saying that resolvconf is _required_ for wg-quick is a bit of a stretch,
it's only needed when a DNS= line is present in the config.

> Please promote the Suggests for the resolvers to at least Recommends.

The problem I see with a recommends is that wireguard is frequently used on
servers/routers but openresolv/resolvconf have various problems on such
systems.

I've personally had problems with them breaking an unbound server, but
#761050 "openresolv sets local bind to always forward requests, even when
local bind is authoritative" discusses a similar problem with BIND.

What is your exact use-case? I assume it's for a desktop VPN, in which case
adding systemd-resolved support to wg-quick might be less
problematic.

--Daniel


signature.asc
Description: PGP signature

Bug#1037029: spyder: Saving files window does not respect current active Gnome dark mode

[Julian Gilbey]

On Wed, Oct 11, 2023 at 06:56:02PM -0300, sergio wrote:
> El jue, 17 de ago de 2023 a las 11:36:58 AM, Julian Gilbey 
> 
> escribi
> 
>   spyder
> 
> Hi Julian,
> any way of doing this from the stable release ? I've installed from testing 
> some
> very, very minimal/specific packages before, but looks like this is going to
> update some other packages on stable release. Any possible arrive to backports
> repository in the near future ?
> Thank you for time
> Regards.
> Sergio

Hi Sergio,

As you say, spyder has a lot of dependencies, and I don't know exactly
which ones would need backporting to get a working spyder in
backports, and how many of these backports might break other things in
other packages along the way.  I don't have the capacity to take on
this level of responsibility for backports, so I do not intend to
backport spyder.

If someone else would like to take on this task, though, they are more
than welcome to do so!

(If this bug is really annoying you, you can always run the PyPI
version of spyder in a virtual environment.)

Best wishes,

   Julian

Bug#1049700: texlive-extra: Fails to build binary packages again after successful build

[Preuße]

Version: 2023.20231007-1

On 16.08.2023 09:42, Lucas Nussbaum wrote:

Hi,


This package fails to do build a binary-only build (not source) after a
successful build (dpkg-buildpackage ; dpkg-buildpackage -b).



Fixed in latest upload.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053833: 503 errors [Server reports unexpected range] when cascading acngs

[Michael Tokarev]

After looking into the source, I found this brilliant comment in acng.conf.in:

# There some broken HTTP servers and proxy servers in the wild which don't
# support the If-Range header correctly and return incorrect data when the
# contents of a (volatile) file changed. This also applies to incomplete
# resumed downloads.  Setting VfileUseRangeOps to 0 disables Range-based
# requests (using purely If-Modified-Since and requesting the complete file
# instead, if changed). Setting it to a negative value removes even this check
# and means fetching the whole file from the beginning.
#
# VfileUseRangeOps: 1

The thing is that acng is such a broken HTTP proxy server *itself*, it does
weird thing with If-Range header exactly as outlined in this comment.

After setting VfileUseRangeOps to 0 things started working.

This obviously needs to be fixed still.

/mjt

Bug#1033870: sogo: CalDAV/calendar not working with Apple Calendar on macOS Ventura/Sonoma

[Manfred Stock]

Package: sogo
Version: 5.8.0-1
Followup-For: Bug #1033870
Control: tags -1 patch upstream

Dear Maintainer,

as expected, the Apple Calendar on the new macOS Sonoma is also not
fully able to talk to SOGo in the versions provided by Debian in
Bullseye and Bookworm. There's also an upstream bug report [1] regarding
macOS Sonoma in addition to the original report [2] about macOS Ventura.
According to these, the latest version of SOGo (5.9.0 at the time of
this writing) fixes the support for macOS Ventura and Sonoma. The
original bug report also contains a message which says that the original
issue was found and fixed [3] and links to the corresponding commit [4].

When looking at the SOGo repo on Salsa, I noticed there's a 'bookworm'
branch which contains the patches to add macOS Ventura support.
Unfortunately, I wasn't able to build that branch (patch didn't seem to
apply, might also be my fault though) and because of the way the
original upstream fix was implemented, it wouldn't have solved the issue
for macOS Sonoma anyway without further changes. However, the
aforementioned patch [4] which seems to solve the original issue
basically removed the original approach to fixing the issue and replaced
it with a simpler solution. So I tried to extract the essence of this
patch and built the package based on version 5.8.0-1 of the sources on
Salsa [6]. And according to our (limited) tests with macOS Ventura and
Sonoma, this indeed solves the issue. My patch should be attached to
this email.


Cheers,
Manfred

[1] https://bugs.sogo.nu/view.php?id=5870
[2] https://bugs.sogo.nu/view.php?id=5639
[3] https://bugs.sogo.nu/view.php?id=5639#c17217
[4] 
https://github.com/Alinto/sogo/commit/4f7c73143f38b1e7e00a51b9457b55ce609a02a9
[5] https://salsa.debian.org/debian/sogo/-/tree/bookworm
[6] https://salsa.debian.org/debian/sogo/-/tree/debian/5.8.0-1
From: Manfred Stock 
Date: Mon, 9 Oct 2023 15:35:00 +0200
Subject: fix(calendar): Fix MacOS X Ventura calendar support. Fixes #5639

This patch is based on upstream commit 4f7c73143f which fixes support
for macOS Ventura, Sonoma and maybe future macOS versions. Apparently,
the upstream commit also removes the older approach to fix that support,
so this patch only contains what is assumed to be the essence of the
fix.
---
 SoObjects/Appointments/SOGoAppointmentFolder.m |  2 +-
 SoObjects/SOGo/WORequest+SOGo.h|  1 +
 SoObjects/SOGo/WORequest+SOGo.m| 17 +
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/SoObjects/Appointments/SOGoAppointmentFolder.m 
b/SoObjects/Appointments/SOGoAppointmentFolder.m
index 2c43800..bd3dae6 100644
--- a/SoObjects/Appointments/SOGoAppointmentFolder.m
+++ b/SoObjects/Appointments/SOGoAppointmentFolder.m
@@ -2529,7 +2529,7 @@ firstInstanceCalendarDateRange: (NGCalendarDateRange *) 
fir
  resourcetype. Anything else will prevent the iPhone from querying the
  collection. */
   request = [context request];
-  if (!([request isIPhone] || [request isICal4]))
+  if (!([request isIPhone] || [request isICal4] || [request isMacOSXCalendar]))
 {
   gdRT = (NSArray *) [self groupDavResourceType];
   gdVEventCol = [NSArray arrayWithObjects: [gdRT objectAtIndex: 0],
diff --git a/SoObjects/SOGo/WORequest+SOGo.h b/SoObjects/SOGo/WORequest+SOGo.h
index 9ae6c91..6199eb9 100644
--- a/SoObjects/SOGo/WORequest+SOGo.h
+++ b/SoObjects/SOGo/WORequest+SOGo.h
@@ -35,6 +35,7 @@
 - (BOOL) isMacOSXAddressBookApp;
 - (BOOL) isIPhoneAddressBookApp;
 - (BOOL) isAndroid;
+- (BOOL) isMacOSXCalendar;
 
 @end
 
diff --git a/SoObjects/SOGo/WORequest+SOGo.m b/SoObjects/SOGo/WORequest+SOGo.m
index 1091650..c6f76d4 100644
--- a/SoObjects/SOGo/WORequest+SOGo.m
+++ b/SoObjects/SOGo/WORequest+SOGo.m
@@ -242,5 +242,22 @@
   return ([[cc userAgent] rangeOfString: @"Android"].location != NSNotFound);
 }
 
+- (BOOL) isMacOSXCalendar
+{
+  WEClientCapabilities *cc;
+  BOOL b;
+
+  cc = [self clientCapabilities];
+
+  b = (
+(
+  nil != [cc userAgent]
+  && [[cc userAgent] rangeOfString: @"macOS"].location != NSNotFound
+  && [[cc userAgent] rangeOfString: @"dataaccessd"].location != 
NSNotFound
+)
+   );
+
+  return b;
+}
 
 @end