Bug#1013153: camitk: vtk[6,7] removal

[Andreas Tille]

Control: tags -1 upstream
Control: tags -1 help
Control: forwarded -1 Emmanuel Promayon 
, Celine Fouard 


Hi Emmanuel and Celine,

Debian has dropped support for VTK 6/7 and camitk needs to be ported to VTK9.
Currently libvtk9-qt-dev is not installable to do a test build.  It would be
great if you could confirm that camitk builds with VTK9.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1027937: gwenview: Under Bookworm, Gwenview no longer displays NEF images (RAW images)

[Aurélien COUDERC]

control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=463132


Dear Cropper,


Le 4 janvier 2023 22:28:53 GMT+01:00, Cropper  a écrit :
>Package: gwenview
>Version: 4:22.12.0-1+b1
>Severity: important
>X-Debbugs-Cc: crop...@acm.org

Thank you for your bug report.

This has been fixed upstream and will be part of version 22.12.2 planned to be 
released on Feb 2.


Happy hacking,
--
Aurélien

Bug#1028645: lsd: Lack of completion files

[Hacci Maru]

Package: lsd
Version: 0.23.1
Severity: normal
X-Debbugs-Cc: bitbuck...@gmail.com

Dear Maintainer,

lsd package doesn't contain the completion files.

-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.15.84-v8+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP:ja
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#1028644: warzone2100: warzone sometimes fails to save a skirmish game

[Russell Coker]

Package: warzone2100
Version: 4.3.3-2
Severity: minor
Tags: upstream

Sometimes it fails to save with errors like the following:


error   |15:38:41: [saveGame:3376] saveGame: 
writeMapFile("savegames/skirmish/k/game.map") failed
info|15:38:41: [renderLoop:276] Mid Mission: saveGame Failed
info|15:38:41: [renderLoop:276] Assert in Warzone: ./src/loop.cpp:276 
(!"saveGame(sRequestResult, GTYPE_SAVE_MIDMISSION) failed"), last script event: 
''
error   |15:59:49: [writeMapData:261] Error writing maptile; tile height (511) 
exceeds maximum tile height (510)
error   |15:59:49: [saveGame:3376] saveGame: 
writeMapFile("savegames/skirmish/auto/Entropy_2023-01-14_155949/game.map") 
failed
error   |16:17:48: [writeMapData:261] Error writing maptile; tile height (511) 
exceeds maximum tile height (510)
error   |16:17:48: [saveGame:3376] saveGame: 
writeMapFile("savegames/skirmish/auto/Entropy_2023-01-14_161748/game.map") 
failed


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

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

Versions of packages warzone2100 depends on:
ii  libasound2  1.2.8-1+b1
ii  libc6   2.36-7
ii  libcurl3-gnutls 7.87.0-1
ii  libdecor-0-00.1.1-1
ii  libdrm2 2.4.114-1
ii  libfreetype62.12.1+dfsg-3
ii  libfribidi0 1.0.8-2.1
ii  libgbm1 22.3.2-1
ii  libgcc-s1   12.2.0-13
ii  libharfbuzz0b   6.0.0-1
ii  libminiupnpc17  2.2.4-1
ii  libogg0 1.3.5-3
ii  libopenal1  1:1.19.1-2
ii  libopus01.3.1-2
ii  libphysfs1  3.0.2-6
ii  libpng16-16 1.6.39-2
ii  libpulse0   16.1+dfsg1-2+b1
ii  libsamplerate0  0.2.2-3
ii  libsodium23 1.0.18-1
ii  libsqlite3-03.40.1-1
ii  libstdc++6  12.2.0-13
ii  libtheora0  1.1.1+dfsg.1-16.1
ii  libvorbis0a 1.3.7-1
ii  libvorbisfile3  1.3.7-1
ii  libwayland-client0  1.21.0-1
ii  libwayland-cursor0  1.21.0-1
ii  libwayland-egl1 1.21.0-1
ii  libx11-62:1.8.3-3
ii  libxcursor1 1:1.2.1-1
ii  libxext62:1.3.4-1+b1
ii  libxfixes3  1:6.0.0-2
ii  libxi6  2:1.8-1+b1
ii  libxkbcommon0   1.4.1-1
ii  libxrandr2  2:1.5.2-2+b1
ii  libxss1 1:1.2.3-1
ii  warzone2100-data4.3.3-2
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages warzone2100 recommends:
ii  warzone2100-music  4.3.3-1

warzone2100 suggests no packages.

-- no debconf information

Bug#1028619: rich: autopkgtest is failng after updating pygments to 2.14.0+dfsg-1

[Carsten Schoenert]

tags -1 patch + upstream
forwarded -1 https://github.com/Textualize/rich/pull/2751

Am 13.01.23 um 19:25 schrieb Sandro Tosi:

yeah i'm wondering why you keep updating packages you dont maintain to
new upstream releases and breaking revdeps as consequence


It's seems to me you are the only person who who disagrees on the work I do.

That rdeps are will fail on package update is quite normal not only to 
me. But it's a difference if a upstream project is doing a major version 
bump or some usual minor update.
And we are not in any freeze state yet there I agree no uncoordinated 
and unneeded version updates should happen.


So far possible I pointed in other reports I did open to the upstream 
fix that adjust the local tests for the different behavior pygments 
2.14.0 is producing.
Within rich this doesn't did happen yet by any other reporter or by 
upstream itself.


So I created a PR [1] that will fix the issues within the tests.

For your convenience I added the same patch here where I can rebuild the 
current version of rich in unstable successful again.


[1] https://github.com/Textualize/rich/pull/2751

--
Regards
CarstenFrom bea71b3ca0f7b5c22f0ed050eb125b32e8085a65 Mon Sep 17 00:00:00 2001
From: Carsten Schoenert 
Date: Sat, 14 Jan 2023 07:38:57 +0100
Subject: [PATCH] tests: Adjustments to run tests with pygments 2.14.0

The current most recent version of pygments produces some different
output which provoke failing some of the the existing tests.
---
 tests/test_syntax.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/test_syntax.py b/tests/test_syntax.py
index 5eff05ee..6b8cfd8b 100644
--- a/tests/test_syntax.py
+++ b/tests/test_syntax.py
@@ -110,7 +110,7 @@ def test_python_render_simple_indent_guides():
 )
 rendered_syntax = render(syntax)
 print(repr(rendered_syntax))
-expected = '\x1b[34mdef\x1b[0m \x1b[32mloop_first_last\x1b[0m(values: Iterable[T]) -> Iterable[Tuple[\x1b[36mb\x1b[0m\n\x1b[2m│   \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│   \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n\x1b[2m│   \x1b[0m\x1b[34mtry\x1b[0m:\n\x1b[2m│   │   \x1b[0mprevious_value = \x1b[36mnext\x1b[0m(iter_values)\n\x1b[2m│   \x1b[0m\x1b[34mexcept\x1b[0m \x1b[36mStopIteration\x1b[0m:\n\x1b[2m│   │   \x1b[0m\x1b[34mreturn\x1b[0m\n\x1b[2m│   \x1b[0mfirst = \x1b[34mTrue\x1b[0m\n\x1b[2m│   \x1b[0m\x1b[34mfor\x1b[0m value \x1b[35min\x1b[0m iter_values:\n\x1b[2m│   │   \x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mFalse\x1b[0m, previous_value\n\x1b[2m│   │   \x1b[0mfirst = \x1b[34mFalse\x1b[0m\n\x1b[2m│   │   \x1b[0mprevious_value = value\n\x1b[2m│   \x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mTrue\x1b[0m, previous_value\n'
+expected = '\x1b[34mdef\x1b[0m \x1b[32mloop_first_last\x1b[0m(values: Iterable[T]) -> Iterable[Tuple[\x1b[36mb\x1b[0m\n\x1b[2;37m│   \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│   \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n\x1b[2m│   \x1b[0m\x1b[34mtry\x1b[0m:\n\x1b[2m│   │   \x1b[0mprevious_value = \x1b[36mnext\x1b[0m(iter_values)\n\x1b[2m│   \x1b[0m\x1b[34mexcept\x1b[0m \x1b[36mStopIteration\x1b[0m:\n\x1b[2m│   │   \x1b[0m\x1b[34mreturn\x1b[0m\n\x1b[2m│   \x1b[0mfirst = \x1b[34mTrue\x1b[0m\n\x1b[2m│   \x1b[0m\x1b[34mfor\x1b[0m value \x1b[35min\x1b[0m iter_values:\n\x1b[2m│   │   \x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mFalse\x1b[0m, previous_value\n\x1b[2m│   │   \x1b[0mfirst = \x1b[34mFalse\x1b[0m\n\x1b[2m│   │   \x1b[0mprevious_value = value\n\x1b[2m│   \x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mTrue\x1b[0m, previous_value\n'
 assert rendered_syntax == expected
 
 
@@ -127,7 +127,7 @@ def test_python_render_line_range_indent_guides():
 )
 rendered_syntax = render(syntax)
 print(repr(rendered_syntax))
-expected = '\x1b[2m│   \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│   \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n'
+expected = '\x1b[2;37m│   \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│   \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n'
 assert rendered_syntax == expected
 
 
-- 
2.39.0

Bug#1027790: Bug 1027790:nvidia-kernel-dkms: kernel driver 525.60.13 fails to build on kernel linux-6.2-rc2

[vmxevilstar]

Dear Mantainer,

version NVIDIA-Linux-x86_64-525.78.01.run compiles well for kernel
6.2.rc2 nd 6.2-rc3

I am daily using it to work and play games

nvidia-smi
Sat Jan 14 07:59:20 2023 
+--
---+
| NVIDIA-SMI 525.78.01 Driver Version: 525.78.01 CUDA Version: 12.0 |
|---+--+---
---+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===+==+===
===|
| 0 NVIDIA GeForce ... Off | :01:00.0 On | N/A |
| N/A 38C P8 14W / 115W | 628MiB / 8192MiB | 4% Default |
| | | N/A |
+---+--+---
---+
+--
---+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|==
===|
| 0 N/A N/A 10641 G /usr/lib/xorg/Xorg 299MiB |
| 0 N/A N/A 10895 G /usr/bin/gnome-shell 127MiB |
| 0 N/A N/A 11355 G gnome-control-center 7MiB |
| 0 N/A N/A 11802 G ...plications/Zoiper5/zoiper 10MiB |
| 0 N/A N/A 11835 C+G ...180056620158566841,131072 126MiB |
| 0 N/A N/A 12085 G ...RendererForSitePerProcess 51MiB |
+--
---+


please add it to nvidia-dkms
is there a way I can make the nvidia-dkms version change myself and
send it to mentors ?

Thanks

Bug#1028597: depthcharge-tools-installer: [INTL:de] initial German debconf translation

[Helge Kreutzmann]

Hello Holger,
On Sat, Jan 14, 2023 at 12:38:46AM +0100, Holger Wansing wrote:
> Helge Kreutzmann  wrote (Fri, 13 Jan 2023 13:49:39 
> +0100):
> > Package: depthcharge-tools-installer
> > Version: 2
> > Severity: wishlist
> > Tags: patch l10n
> > 
> > Please find the initial German debconf translation for 
> > depthcharge-tools-installer
> > attached.
> 
> Thanks for your translation work.
> 
> However, I'm a bit disappointed about this.

I'm sorry.

> This package is part of debian-installer, and therefore it's a special package
> (to some degree).
> I sent a message to debian-i18n , to warn 
> translators about this package (plus another one - partman-cros), to not work
> at these packages:
> https://lists.debian.org/debian-i18n/2022/12/msg5.html

I've received this e-mail, but somehow it did not cause any impact on
me.

> I've also added a note in the templates.pot file for these packages, which 
> should
> warn translators to not work on these files directly.

This note is not present. To double check, I just issued
wget 
https://i18n.debian.org/material/po/unstable/main/d/depthcharge-tools-installer/debian/po/depthcharge-tools-installer_2_templates.pot.gz

And reviewed the the file again. No note.

Maybe you could merge this translation over. Or if you cannot, then
this is not you to blame.

> Apparently this did not work as intended :-((

I was a little bit wondering when I saw that you worked on the package
and you are usually working on d-i. But given the many last minute
requests for translations, this did not trigger a big warning with me.

> Anyway, I have decided to release depthcharge-tools-installer and partman-cros
> without any translations in Bookworm, so this bug is for Trixie.

This is a pitty. I'm currently putting in quite some effort to get
everything translated to German in Bookworm, including i18n-NMUs via
my sponsor (which include all available translations, of course). 

Also the German translator communitiy is currentently very active, we
have at least 5 translators working towards better localization at the
moment - a fact we haven't seen for a long time. 

Thus if you could kindly revisit this decicision and include the
German translation in an upload for bookworm, this would be highly
welcome, most likely also from users. If there is any help I can do,
please let me know.

Thanks for reconsidering.

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1028642: neochat: FTBFS with libquotient 0.7

[Hubert Chathi]

Package: neochat
Severity: normal

Dear Maintainer,

The neochat package fails to build with the latest version of
libquotient (0.7), which is now in experimental.  This is due to the
tests failing, with the following error:

,
| qt.qpa.xcb: could not connect to display 
| qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though 
it was found.
| This application failed to start because no Qt platform plugin could be 
initialized. Reinstalling the application may fix this problem.
| 
| Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, 
offscreen, vnc, xcb.
`

Obviously, we can't expect access to a display on a build machine.

Looking at the build log for the current package (built with libquotient
0.6), the tests don't seem to run at all, which is why the test doesn't
fail on that build.

I don't know if there's a way to run the tests without a display, but if
I disable the tests, e.g. by adding

,
| override_dh_auto_test:
|   # skip tests because they need a display, which we don't have
`

to debian/rules, the package builds correctly and seems to run fine.

Bug#1025537: nfsd: Kernel Oops while serving NFS

[Olivier Mehani]

Package: linux-image-5.19.0-10315-g310d9d5a5009
Followup-For: Bug #1025537

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Olivier Mehani 
To: Debian Bug Tracking System <1025...@bugs.debian.org>
Subject: Re: nfsd: Kernel Oops while serving NFS
Message-ID: 
<167361292314.1643173.3991370234085262557.report...@supahwinch.narf.ssji.net>
X-Mailer: reportbug 11.6.0
Date: Fri, 13 Jan 2023 23:28:43 +1100

Package: linux-image-5.19.0-10316-gf0f6b614f83d
Followup-For: Bug #1025537

OK, I think I have a strong suspect [0]: 

   f0f6b614f83dbae99d283b7b12ab5dd2e04df979 (tags/v6.0-rc1~55^2~2)

This is a pretty generic commit, that doesn't seem to touch the nfs 
stack, but changes something that looks deep enough in the iovec code 
that it could have an impact.

I have solidly re-tested the preceding commit,
310d9d5a5009a93377200b98daa2d84aa2bd8160 (tags/v6.0-rc1~55^2~3), and 
the Oops doesn't happen there.

There is a series of commits that were suggested as part of the `git 
bisect`, that I wasn't able to build and had to skip. The error was

   FAILED: load BTF from vmlinux: Invalid argument

but no amount of cajoling `pahole` has helped.

The merge parent for the series is at 
8447d0e75099eb54eea9306c2d43ecfc956d09ed (tags/v6.0-rc1~56^2), which is 
the preceding merge to the one containing the first bad commit above. I 
think this is noteworthy as a lot of the commits on this branch are 
labeled as `remoteproc` which I, as a lay person, think might be related 
to RPCs.

Is there any other tests that I can perform to help diagnose / fix this 
further?

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f0f6b614f83dbae99d283b7b12ab5dd2e04df97
 (but dockerd Oops, 10623384), nah, BAD


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

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

-- no debconf information

Bug#1028251: New Patch (Was: Re: Bug#1028251: xen: FTBFS when building xen binary packages for sid on x86_64)

[Chuck Zmudzinski]

On 1/13/23 6:59 PM, Hans van Kranenburg wrote:
> Hi,
> 
> On 1/13/23 22:45, Chuck Zmudzinski wrote:
>> On 1/13/23 7:39 AM, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2023 at 12:58:29AM -0500, Chuck Zmudzinski wrote:
 On 1/11/2023 10:58 PM, Chuck Zmudzinski wrote:
> On 1/9/23 12:55 PM, Hans van Kranenburg wrote:
>> Hi!
> [...]
> Yolo style cutting out lines here...
> [...]

 Regarding the systemd files causing ftbfs, this explains it:

 https://salsa.debian.org/xen-team/debian-xen/-/blob/master/m4/systemd.m4#L119

 and this:

 https://salsa.debian.org/xen-team/debian-xen/-/blob/master/tools/configure.ac#L480

 The comments indicate that using AX_AVAILABLE_SYSTEMD() will
 by default enable systemd if systemd development files are on the
 build system, and AX_ALLOW_SYSTEMD() means --enable-systemd
 must explicitly be passed to tools/configure to enable it. Upstream
 uses the former, so build systems with systemd development files
 by default will ftbfs because that produces missing files that dh_missing
 in debian/rules does not like.

 So the reason there is ftbfs on my system is that my system has
 the systemd development package installed.
>>>
>>> By the way, maybe a better fix would be to pass --enable-systemd, add 
>>> libsystemd-dev
>>> build-dep and list them in the package? They might require patching to
>>> support Debian-specific upgrade machinery, though...
>>>
>>> Not installing xendriverdomain.service is one of things missing for
>>> driver domains support
>>> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922033).
>>>
>> 
>> Hi Marek,
>> 
>> I wouldn't be against fixing it that way. In fact, I would prefer
>> that Debian packaged Xen with full support for native systemd units.
>> I am willing to wait until if/when the package maintainers have
>> full systemd support in the Xen packages.
>> 
>> Perhaps this is an opportunity for you to try to fix 922033 again.
>> I see it has been sitting there for a few years now. Let's see
>> what Hans thinks.
> 
> Yeah, well, so, the thing here is...
> 
> When Debian started to package Xen (thanks! Bastian, in 200X), the
> upstream init scripts were copy pasted, and adjusted to have the ability
> to have different Hypervisor-ABI-incompatible versions installed at the
> same time. Also, this is related to the collection of Makefile patches
> we carry around to have ABI-incompatible stuff end up in a directory
> like /usr/lib/xen-4.14/ and /usr/lib/xen-4.17/ !

That is a nice feature of the Xen Debian packages, to have the ability
to manage guests on different versions of the hypervisor.

> 
> What does this mean? Well, in the most basic sense it means that you
> could apt-get (dist-)upgrade and then still be able to xl shutdown a
> domU afterwards before doing reboot, because it will choose the right
> tools which match with the ABI of the *now* running hypervisor instead
> of being left with a dumpster fire, which in the end causes you to shout
> curse words and cause you to have to go to the machine and hold the
> power button for 5 seconds to force power it off.
> 
> This is the thing about where you upgrade from Xen 4.14 to Xen 4.17
> during the upgrade from Debian 11/Bullseye to Debian 12/Bookworm, it
> will allow you, if booting the whole new thing is a huge failure, to
> reset the computer, and in grub, choose to use the previous Xen (and
> possibly do that in combination with previous Debian linux kernel) and
> then have a system where you again at least can start your domUs again
> *) and first have a good rest, night of sleep before starting to dig
> into what's going wrong.
> 
> So, this is exactly the same way of doing stuff like how you can also
> reboot back into the previous Linux kernel (ABI-compatible) one during a
> system upgrade, even if you're not using Xen at all!
> 
> I like this very much. This is the kind of thing that helps admins of
> systems that have just local disks and a few domUs. Like, the case where
> you support some non-profit organization with their server stuff running
> on donated hardware. (Yes, I also do some of those, I do!) And, in case
> something does fail (there could always be something like a misbehaving
> mpt3sas card in the hardware or anything that no one else spotted yet),
> the admin does not have to end up in total panic mode after doing the
> upgrade on a Friday afternoon lying upside down inside a broom closet,
> but they can just at least recover from the situation and have something
> that's running again, and then a day later, or 2 or 3 days or a week
> later return on another planned moment to fix it, after asking around.
> 
> Upstream Xen stuff doesn't have anything like that.
> 
> But, they actually look at us, and they think, ooh, this is actually
> nice, we should have that also by default.
> 
> The fact that we have this changed/altered/divergent init scripts in
> Debian is the main reason that w

Bug#1028641: libquazip1-qt5-dev: Missing dependencies on "qtbase5-dev, zlib1g-dev"

[Adrian Bunk]

Package: libquazip1-qt5-dev
Version: 1.3-1
Severity: serious

/usr/lib/x86_64-linux-gnu/cmake/QuaZip-Qt5-1.3/QuaZip-Qt5_SharedTargets.cmake:
INTERFACE_LINK_LIBRARIES "Qt5::Core;ZLIB::ZLIB"


I am not sure the cmake file should add these to the linker line
for rdeps, but if it does then libquazip1-qt5-dev needs dependencies on
  qtbase5-dev, zlib1g-dev

With the missing dependencies added, users like reverse dependencies
will no longer have to manually copy such implementation details of
libquazip to their own build dependencies.

Bug#1028640: libquazip1-qt6-dev: Missing dependencies on "qt6-base-dev, libqt6core5compat6-dev, zlib1g-dev"

[Adrian Bunk]

Package: libquazip1-qt6-dev
Version: 1.3-2
Severity: serious
Control: affects -1 src:libodsstream src:minexpert2

/usr/lib/x86_64-linux-gnu/cmake/QuaZip-Qt6-1.3/QuaZip-Qt6_SharedTargets.cmake:  
INTERFACE_LINK_LIBRARIES "Qt6::Core;Qt6::Core5Compat;ZLIB::ZLIB"


I am not sure the cmake file should add these to the linker line
for rdeps, but if it does then libquazip1-qt6-dev needs dependencies on
  qt6-base-dev, libqt6core5compat6-dev, zlib1g-dev

With the missing dependencies added, users like reverse dependencies
(currently libodsstream and minexpert2) will no longer have to manually copy
such implementation details of libquazip to their own build dependencies.

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Nick Hastings]

* Bastian Germann  [230113 18:05]:
> Am 13.01.23 um 03:40 schrieb Nick Hastings:
> > This debian/copyright file was originally produced by decopy and I
> > adjusted it wherever I found problems. I hesitate to change things that
> > I do not know to be wrong, at the risk of introducing errors simply to
> > reduce the number of lines in the file.
> 
> If you want this to be sponsored by me, please do so.

I spent a couple of hours grinding through the LGPL-2.1 section of
lib/libc/include and was able reduce the copyright file by about 760
lines. I was also able to save a few lines from the APSL-2 an GPL-2
sections.

> I will not review a non-reviewable copyright file.

I'm not clear on what constitutes a reviewable vs non-reviewable
copyright file. If there are other specific parts of the copyright file
that you think need more work please let me know.

Bug#996799: twitterwatch - upload needed

[Emmanuel Arias]

Hi,


On Fri, Jan 13, 2023 at 09:49:15PM +0100, Malik wrote:
> Hello DPT,
> 
> I have created a patch to close #996799 in twitterwatch package [1]
> I need a mainter to upload the current version (0.1-3) to the tftp-master

As Timo mentioned in the bug report. It would be great if the Homepage can
be updated as well.

Also, the package doesn't have tests (if I'm not wrong). Could you add
autopkgtests?

Cheers,
Emmanuel
> 
> [1] https://salsa.debian.org/python-team/packages/twitterwatch
> 
> Thank you in  advance
> -- 
> Malik Mlitat




signature.asc
Description: PGP signature

Bug#1028254: hippotat build is not reproducibl in compiled Rust)

[Ian Jackson]

I suspect the cause (or at least one of them) is

  Non-reproducible builds when depending on local crates
  https://github.com/rust-lang/rust/issues/98185

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1028639: RFS: sioyek/2.0.0+dfsg-2 -- PDF viewer with a focus on technical books and research papers

[Victor Westerhuis]

Package: sponsorship-requests
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

I am looking for a sponsor for my package "sioyek":

 * Package name : sioyek
   Version  : 2.0.0+dfsg-2
   Upstream contact : https://github.com/ahrm/sioyek/issues
 * URL  : https://sioyek.info/
 * License  : BSL-1.0, GFDL-NIV-1.2+ or CC-BY-SA-3.0 or CC-BY-SA-2.5 
and CC-BY-SA-2.0 and CC-BY-SA-1.0, GPL-3.0+, forrest-smith-license
 * Vcs  : https://salsa.debian.org/viccie30/sioyek
   Section  : misc

The source builds the following binary packages:

  sioyek - PDF viewer with a focus on technical books and research papers

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

  https://mentors.debian.net/package/sioyek/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sioyek/sioyek_2.0.0+dfsg-2.dsc

Changes since the last upload:

 sioyek (2.0.0+dfsg-2) unstable; urgency=medium
 .
   * Forward upstreamable patches upstream.
   * Do not download intersphinx inventories.
   * Clean auxiliary files from tutorial build.
   * Define fallback for GL_CLAMP to fix build on armel.

Regards,
- -- 
  Victor Westerhuis

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmPB+PETHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+7tHD/4xFTDFxvgGmI2pLAl2qzHZRYvfq3ED
0hrsNG2j/a/XtD9NgHD8bK6D0EgGIWZKeYqiFV7eSSilk6FRf59BjvOlZ8oBm6+P
wq6dq8trpSDIXMNGZ3FuBP01TmZ9Ah0EBoCBjA5W7d0q8ylj3OJcBmFnuui/tvIx
X2saGBmTVsvaLs84sagno2kzc14rHR52fhxP/l84A8HGIvFGdJN2VLqdpx8C+YwL
BuLR04dSQs6k2oRIyEc4N7Bq48HeNNZSzA2bZinFw3x1olHH1pGHuKowl6Y26IfJ
onRDfhAeaigpwuh7ajSdaZmvbUjgg4z0qBafZrN+xRKVujbASj2xolUNqff13jL8
BqR6Ts0RmR8cxHs8kLtj88kLWU/GE7zLyQ5G26geZJvQNRWse9gmpN0PkvgCafZ1
WK7UackZVNEockbRTpfArqqMYzVN4O7xEDRb6N8S4i3NU3XzA74pNe+mYuqDa0az
tJmGINdoXOLlp2zLAi03gHnu4oOaR273ucrCDctYyZb7JjWlc9qhcrGjb+LLAdsy
pB32miZspH9uDvPc9JkRZkQBnuLcXpJNSOcdGIs8EMKt02JgsEnSqbHuIKhjXBpZ
aV6Si/snPFGTnfygBhX4kVKDFlsmebrGdtWZ83aa2IWrnv49z0rB9LSwO8GYKVgv
jT4k0PWpxkftuw==
=19Wh
-END PGP SIGNATURE-

Bug#1028610: tracker.debian.org: shows the short description of the binary package, which is meaningless for the source package

[Vincent Lefevre]

On 2023-01-13 19:21:58 -0500, Boyuan Yang wrote:
> > https://tracker.debian.org/pkg/emacs (which is about the source package)
> > contains at the top
> > 
> >     emacs
> >    GNU Emacs editor (metapackage)
> > 
> > This is the description of the "emacs" binary package, which
> > is indeed a metapackage. But this makes no sense for the
> > source package.
> 
> (Disclaimer: I am neither the maintainer of tracker.d.o nor emacs)
> 
> Out of curiosity: what do you expect to display?

Probably nothing, just like for packages that do not have a binary
package with the same name as the source package. Example:

  https://tracker.debian.org/pkg/glibc

Otherwise, if there is a rule about the description in the case where
there is a binary package with the same name as the source package,
some filtering could be done based on the requirements. For instance,
specific strings such as "(metapackage)" (or more generally, the whole
parenthesized text) could be removed.

> You know that the source package itself does not have a description
> field at all.

Couldn't this be a future feature?

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

Bug#1028624: libdeflate: Please build with -O1 on alpha to fix FTBFS

[Michael Cree]

> I suspect this might be better worked around with -Wl,-no-relax on the
> linking only rather than disabling compiler optimisations.  I intend to
> run a test of that today.

Nice idea, but, it didn't solve the linker errors.  Stick with reducing
compiler optimisation to -O1.

Cheers
Michael.

Bug#1028610: tracker.debian.org: shows the short description of the binary package, which is meaningless for the source package

[Boyuan Yang]

Hi,

在 2023-01-13星期五的 16:36 +0100，Vincent Lefevre写道：
> Package: tracker.debian.org
> Severity: normal
> 
> https://tracker.debian.org/pkg/emacs (which is about the source package)
> contains at the top
> 
>     emacs
>    GNU Emacs editor (metapackage)
> 
> This is the description of the "emacs" binary package, which
> is indeed a metapackage. But this makes no sense for the
> source package.

(Disclaimer: I am neither the maintainer of tracker.d.o nor emacs)

Out of curiosity: what do you expect to display? You know that the source
package itself does not have a description field at all.

Thanks,
Boyuan Yang


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

Bug#977665: inkscape: the grid spacing should be saved on saving the document

[Vincent Lefevre]

Control: retitle -1 inkscape: the grid is not updated immediately when changing 
document scale
Control: found -1 1.2.2-2
Control: tags -1 fixed-upstream

Retitled according to comments

  https://gitlab.com/inkscape/inbox/-/issues/4205#note_470326556

and

  https://gitlab.com/inkscape/inbox/-/issues/4205#note_1224138272
  "The grid now updates when scale is changed, in line with
  #4205 (comment 470326556)"

The testcase for 1.2.2-2:

1. Run inkscape
2. Go to File → Document Properties
3. Go to Grids, then click on New
4. Set Spacing X & Y to 10
5. Go to Display, then set Scale to 2 (default was 1)
6. Close the "Document Properties" window
7. Save and quit
8. Run "inkscape drawing.svg" to reopen the document

The grid has not changed at steps 5 and 6, but it has changed only
at step 8.

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

Bug#1028251: New Patch (Was: Re: Bug#1028251: xen: FTBFS when building xen binary packages for sid on x86_64)

[Hans van Kranenburg]

Hi,

On 1/13/23 22:45, Chuck Zmudzinski wrote:
> On 1/13/23 7:39 AM, Marek Marczykowski-Górecki wrote:
>> On Fri, Jan 13, 2023 at 12:58:29AM -0500, Chuck Zmudzinski wrote:
>>> On 1/11/2023 10:58 PM, Chuck Zmudzinski wrote:
 On 1/9/23 12:55 PM, Hans van Kranenburg wrote:
> Hi!
[...]
Yolo style cutting out lines here...
[...]
>>>
>>> Regarding the systemd files causing ftbfs, this explains it:
>>>
>>> https://salsa.debian.org/xen-team/debian-xen/-/blob/master/m4/systemd.m4#L119
>>>
>>> and this:
>>>
>>> https://salsa.debian.org/xen-team/debian-xen/-/blob/master/tools/configure.ac#L480
>>>
>>> The comments indicate that using AX_AVAILABLE_SYSTEMD() will
>>> by default enable systemd if systemd development files are on the
>>> build system, and AX_ALLOW_SYSTEMD() means --enable-systemd
>>> must explicitly be passed to tools/configure to enable it. Upstream
>>> uses the former, so build systems with systemd development files
>>> by default will ftbfs because that produces missing files that dh_missing
>>> in debian/rules does not like.
>>>
>>> So the reason there is ftbfs on my system is that my system has
>>> the systemd development package installed.
>>
>> By the way, maybe a better fix would be to pass --enable-systemd, add 
>> libsystemd-dev
>> build-dep and list them in the package? They might require patching to
>> support Debian-specific upgrade machinery, though...
>>
>> Not installing xendriverdomain.service is one of things missing for
>> driver domains support
>> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922033).
>>
> 
> Hi Marek,
> 
> I wouldn't be against fixing it that way. In fact, I would prefer
> that Debian packaged Xen with full support for native systemd units.
> I am willing to wait until if/when the package maintainers have
> full systemd support in the Xen packages.
> 
> Perhaps this is an opportunity for you to try to fix 922033 again.
> I see it has been sitting there for a few years now. Let's see
> what Hans thinks.

Yeah, well, so, the thing here is...

When Debian started to package Xen (thanks! Bastian, in 200X), the
upstream init scripts were copy pasted, and adjusted to have the ability
to have different Hypervisor-ABI-incompatible versions installed at the
same time. Also, this is related to the collection of Makefile patches
we carry around to have ABI-incompatible stuff end up in a directory
like /usr/lib/xen-4.14/ and /usr/lib/xen-4.17/ !

What does this mean? Well, in the most basic sense it means that you
could apt-get (dist-)upgrade and then still be able to xl shutdown a
domU afterwards before doing reboot, because it will choose the right
tools which match with the ABI of the *now* running hypervisor instead
of being left with a dumpster fire, which in the end causes you to shout
curse words and cause you to have to go to the machine and hold the
power button for 5 seconds to force power it off.

This is the thing about where you upgrade from Xen 4.14 to Xen 4.17
during the upgrade from Debian 11/Bullseye to Debian 12/Bookworm, it
will allow you, if booting the whole new thing is a huge failure, to
reset the computer, and in grub, choose to use the previous Xen (and
possibly do that in combination with previous Debian linux kernel) and
then have a system where you again at least can start your domUs again
*) and first have a good rest, night of sleep before starting to dig
into what's going wrong.

So, this is exactly the same way of doing stuff like how you can also
reboot back into the previous Linux kernel (ABI-compatible) one during a
system upgrade, even if you're not using Xen at all!

I like this very much. This is the kind of thing that helps admins of
systems that have just local disks and a few domUs. Like, the case where
you support some non-profit organization with their server stuff running
on donated hardware. (Yes, I also do some of those, I do!) And, in case
something does fail (there could always be something like a misbehaving
mpt3sas card in the hardware or anything that no one else spotted yet),
the admin does not have to end up in total panic mode after doing the
upgrade on a Friday afternoon lying upside down inside a broom closet,
but they can just at least recover from the situation and have something
that's running again, and then a day later, or 2 or 3 days or a week
later return on another planned moment to fix it, after asking around.

Upstream Xen stuff doesn't have anything like that.

But, they actually look at us, and they think, ooh, this is actually
nice, we should have that also by default.

The fact that we have this changed/altered/divergent init scripts in
Debian is the main reason that we cannot just enable systemd things
which will put upstream whatever on the system.

So, what could we do about this?

The project plan (that could be drafted on an A4 paper) could look like,
gather around all distro maintainers of Linux distro's that are shipping
Xen, and then search for a 'Project owner', which we totally need to b

Bug#1028637: Spyder stops showing indent guides after restart

[local10]

Jan 13, 2023, 23:38 by loca...@tutanota.com:

More info:

If I close the tab with "/usr/lib/python3.10/subprocess.py" file an then reopen 
the file again in a new tab then the indent guides will be shown again properly 
(until Spyder is restarted again, then they will disappear again).

Bug#1028615: tracker.debian.org: tracker.d.o should display results of reproducible rebuilds, not just reproducible CI results

[Holger Levsen]

On Fri, Jan 13, 2023 at 06:49:48PM +0100, Holger Levsen wrote:
> But there is a new service, which rebuilds packages and compares the results
> against the binaries we publish at ftp.d.o, which is 
> https://rebuild.notset.fr/debian

 pollo: hmpf, i ment https://rebuild.notset.fr/

thanks, pollo.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The devel is in the details.


signature.asc
Description: PGP signature

Bug#1028192: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call

[Martin]

Control: clone -1 -2
Control: reassign -2 libproxy1v5 0.4.18-1
Control: retitle -2 libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call

This is the backtrace with a debian.org account:

(gdb) bt
#0  read_encoded_value_with_base(unsigned char, _Unwind_Ptr, unsigned char 
const*, _Unwind_Ptr*)
(encoding=160 '\240', base=, p=0x7fffd106e799 
"\351\006\321\377\177", val=0x7fffd106ded8)
at 
/build/gcc-12-PBog5r/gcc-12-12.2.0/src/libstdc++-v3/../libgcc/unwind-pe.h:284
#1  0x734a8511 in read_encoded_value (val=0x7fffd106ded8, 
p=0x7fffd106e791 "\n\001\264\377\177", encoding=160 '\240', 
context=0x7fffd106e380)
at 
/build/gcc-12-PBog5r/gcc-12-12.2.0/src/libstdc++-v3/../libgcc/unwind-pe.h:304
#2  parse_lsda_header(_Unwind_Context*, unsigned char const*, lsda_header_info*)
(context=context@entry=0x7fffd106e380, p=0x7fffd106e791 
"\n\001\264\377\177", 
p@entry=0x7fffd106e790 "\240\n\001\264\377\177", 
info=info@entry=0x7fffd106ded0) at 
../../../../src/libstdc++-v3/libsupc++/eh_personality.cc:60
#3  0x734a8607 in __cxxabiv1::__gxx_personality_v0(int, _Unwind_Action, 
_Unwind_Exception_Class, _Unwind_Exception*, _Unwind_Context*)
(version=, actions=2, exception_class=5138137972254386944, 
ue_header=0x7fffb4010aa0, context=0x7fffd106e380)
at ../../../../src/libstdc++-v3/libsupc++/eh_personality.cc:454
#4  0x71313131 in _Unwind_Phase2 (context=0x7fffd106e380, 
exception_object=0x7fffb4010aa0) at unwind/unwind-internal.h:118
#5  _Unwind_Resume (exception_object=0x7fffb4010aa0) at unwind/Resume.c:37
#6  0x7fffbdaa334a in 
__gnu_cxx::new_allocator::~new_allocator() (this=, __in_chrg=)
at /usr/include/c++/11/ext/new_allocator.h:89
#7  std::allocator::~allocator() (this=, 
__in_chrg=) at /usr/include/c++/11/bits/allocator.h:174
#8  std::_Vector_base 
>::_Vector_impl::~_Vector_impl() (this=, __in_chrg=)
at /usr/include/c++/11/bits/stl_vector.h:128
#9  std::_Vector_base 
>::~_Vector_base() (this=, __in_chrg=)
at /usr/include/c++/11/bits/stl_vector.h:337
#10 std::vector >::~vector() 
(this=, __in_chrg=)
at /usr/include/c++/11/bits/stl_vector.h:683
#11 envvar_config_extension::get_config(libproxy::url const&) (this=, dst=) at ./libproxy/modules/config_envvar.cpp:60
#12 0x7fffbda99e52 in libproxy::proxy_factory::get_config(libproxy::url&, 
std::vector >&, 
std::__cxx11::basic_string, std::allocator 
>&)
(this=0x3a26320, realurl=..., config=std::vector of length 0, capacity 0, 
ignore="") at ./libproxy/proxy.cpp:265
#13 0x7fffbda9a287 in 
libproxy::proxy_factory::get_proxies(std::__cxx11::basic_string, std::allocator > const&) (this=0x3a26320, 
realurl="https://debian.org:443";) at ./libproxy/proxy.cpp:206
#14 0x7fffbda9a751 in px_proxy_factory_get_proxies(pxProxyFactory_*, char 
const*)
(self=0x3a26320, url=url@entry=0x3cb9170 "https://debian.org:443";) at 
./libproxy/proxy.cpp:465
#15 0x7fffbdace61f in get_libproxy_proxies (task=0x39e56c0 [GTask], 
source_object=0x282b580, task_data=0x3cb9170, cancellable=)
at ../proxy/libproxy/glibproxyresolver.c:153
#16 0x769c7793 in g_task_thread_pool_thread (thread_data=0x39e56c0, 
pool_data=) at ../../../gio/gtask.c:1454
#17 0x76ca46da in g_thread_pool_thread_proxy (data=) at 
../../../glib/gthreadpool.c:352
#18 0x76ca3d0d in g_thread_proxy (data=0x2f96a40) at 
../../../glib/gthread.c:831
#19 0x77d25fd4 in start_thread (arg=) at 
./nptl/pthread_create.c:442
#20 0x77da666c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) 

Bug#1028597: depthcharge-tools-installer: [INTL:de] initial German debconf translation

[Holger Wansing]

Hi,

Helge Kreutzmann  wrote (Fri, 13 Jan 2023 13:49:39 +0100):
> Package: depthcharge-tools-installer
> Version: 2
> Severity: wishlist
> Tags: patch l10n
> 
> Please find the initial German debconf translation for 
> depthcharge-tools-installer
> attached.

Thanks for your translation work.

However, I'm a bit disappointed about this.

This package is part of debian-installer, and therefore it's a special package
(to some degree).
I sent a message to debian-i18n , to warn 
translators about this package (plus another one - partman-cros), to not work
at these packages:
https://lists.debian.org/debian-i18n/2022/12/msg5.html

I've also added a note in the templates.pot file for these packages, which 
should
warn translators to not work on these files directly.

Apparently this did not work as intended :-((



Anyway, I have decided to release depthcharge-tools-installer and partman-cros
without any translations in Bookworm, so this bug is for Trixie.



Holger





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

Bug#1028637: Spyder stops showing indent guides after restart

[local10]

Package: spyder  
Version: 5.4.1+ds-1

Spyder stops showing indent guides after restart. To reproduce the issue:

1. Start with a clean Spyder profile, that is, remove the 
"/home/luser/.config/spyder-py3" dir, if  it exists
2. Start Spyder
3. Open the following file "/usr/lib/python3.10/subprocess.py"
4. Goto Menu > Source and enable the following:
    [x] Show indent guides
    [x] Show selector for classes and functions
    [x] Underline errors and warnings
5. Indent guides should be properly shown
6. Shut down Spyder
7. Start Spyer, go to tab with /usr/lib/python3.10/subprocess.py, indent guides 
are not shown.

Thanks

Bug#1028631: media-types: rss is associated with application/x-rss+xml instead of application/rss+xml

[Charles Plessy]

Dear Giuseppe,

thank you for your report,

registration to IANA is not difficult, can you find somebody who is
willing to do it ?

https://www.iana.org/form/media-types

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1028636: pocl: FTBFS on arm64: ***** The testsuite has failed! *****

[Sebastian Ramacher]

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

https://buildd.debian.org/status/fetch.php?pkg=pocl&arch=arm64&ver=3.1-1&stamp=1673537413&raw=0

dpkg-gensymbols: warning: debian/libpocl2/DEBIAN/symbols doesn't match 
completely debian/libpocl2.symbols
--- debian/libpocl2.symbols (libpocl2_3.1-1_arm64)
+++ dpkg-gensymbolsR76HBy   2023-01-12 15:29:59.848720577 +
@@ -23,28 +23,28 @@
  
_ZGVZNKSt8__detail11_AnyMatcherINSt7__cxx1112regex_traitsIcEELb0ELb1ELb0EEclEcE5__nul@Base
 3.0
  
_ZGVZNKSt8__detail11_AnyMatcherINSt7__cxx1112regex_traitsIcEELb0ELb1ELb1EEclEcE5__nul@Base
 3.0
  _ZN4pocl23eraseFunctionAndCallersEPN4llvm8FunctionE@Base 1.8-3~visibility
-#MISSING: 1.8# 
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE12emplace_backIJS5_EEEvDpOT_@Base
 0.11
-#MISSING: 1.8# 
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJRKS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
-#MISSING: 1.8# 
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
-#MISSING: 1.8# 
(optional=templinst)_ZNSt6vectorIPKcSaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
-#MISSING: 1.8# 
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceE{size_t}{size_t}PKc{size_t}@Base
 1.6-2~hardening
+#MISSING: 3.1-1# 
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE12emplace_backIJS5_EEEvDpOT_@Base
 0.11
+#MISSING: 3.1-1# 
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJRKS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
+#MISSING: 3.1-1# 
(optional=templinst)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
+#MISSING: 3.1-1# 
(optional=templinst)_ZNSt6vectorIPKcSaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 0.13-9~llvm3.8+gcc7
+#MISSING: 3.1-1# 
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceE{size_t}{size_t}PKc{size_t}@Base
 1.6-2~hardening
 #MISSING: 1.8# 
(optional=templinst|arch=mipsel)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@Base
 1.1-6~llvm6.0+gcc8
-#MISSING: 1.8# 
(optional=templinst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE4swapERS4_@Base
 1.6-2~hardening
-#MISSING: 1.8# 
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_appendEPKc{size_t}@Base
 1.6-2~hardening
-#MISSING: 1.8# 
(optional=templinst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_assignERKS4_@Base
 1.6-2~hardening
-#MISSING: 1.8# 
(optional=templinst|subst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_mutateE{size_t}{size_t}PKc{size_t}@Base
 1.6-2~hardening
-#MISSING: 1.8# 
(optional=templinst)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE24_M_get_insert_unique_posERKS5_@Base
 1.0
-#MISSING: 1.8# 
(optional=templinst)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS5_ERKS5_@Base
 1.0
-#MISSING: 1.8# 
(optional=templinst)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE8_M_eraseEPSt13_Rb_tree_nodeIS5_E@Base
 1.0
-#MISSING: 1.8# 
(optional=templinst)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E@Base
 1.1-2~llvm5.0
-#MISSING: 1.8# 
(optional=templinst)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIvESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E@Base
 1.7-3~llvm10
-#MISSING: 1.8# 
(optional=templinst)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_iESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE24_M_get_insert_unique_posERS7_@Base
 0.11
-#MISSING: 1.8# 
(optional=templinst)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_iESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS8_ERS7_@Base
 0.11
-#MISSING: 1.8# 
(optional=templinst)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_jESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE24_M_get_insert_unique_posERS7_@Base
 1.0
-#MISSING: 1.8# 
(optional=te

Bug#1028635: dnf FTBFS: ERROR: test_do_transaction (tests.api.test_dnf_base.DnfBaseApiTest.test_do_transaction)

[Adrian Bunk]

Source: dnf
Version: 4.14.0-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=dnf&arch=all&ver=4.14.0-2&stamp=1673468063&raw=0

==
ERROR: test_do_transaction 
(tests.api.test_dnf_base.DnfBaseApiTest.test_do_transaction)
--
Traceback (most recent call last):
  File "/<>/tests/api/test_dnf_base.py", line 160, in 
test_do_transaction
self.base.do_transaction(display=None)
  File "/<>/dnf/base.py", line 951, in do_transaction
self._moduleContainer.save()
  File "/usr/lib/python3/dist-packages/libdnf/module.py", line 1241, in save
return _module.ModulePackageContainer_save(self)
   ^
libdnf._error.Error: Failed to create directory "/etc/dnf": 13 - Permission 
denied

--
Ran 796 tests in 7.199s

FAILED (errors=1, skipped=1)


0% tests passed, 1 tests failed out of 1

Total Test time (real) =   7.96 sec

The following tests FAILED:
  1 - test (Failed)
Errors while running CTest
make[2]: *** [Makefile:74: test] Error 8

Bug#997222: libexplain: FTBFS in bullseye

[Santiago Vila]

reopen 997222
found 997222 1.4.D001-11
fixed 997222 1.4.D001-12
thanks

Note: There is a fix proposal for bullseye in Bug #1025703.

Bug#1027619: gh: FTBFS: tests fail

[Andreas Henriksson]

Hello Lucas Nussbaum,

Could you please provide some additional input? See below.

On Sun, Jan 01, 2023 at 03:33:44PM +0100, Lucas Nussbaum wrote:
> Source: gh
> Version: 2.18.1+dfsg1-1
> Severity: serious
> Justification: FTBFS
[...]
> > === RUN   TestStartJupyterServerFailure
> > client_test.go:70: error connecting to internal server: failed to share 
> > remote port 16634: dial tcp 127.0.0.1:50051: connect: connection refused
> > --- FAIL: TestStartJupyterServerFailure (0.00s)
> > FAIL
> > FAILgithub.com/cli/cli/v2/internal/codespaces/grpc  0.039s
> > ?   github.com/cli/cli/v2/internal/codespaces/grpc/jupyter  [no 
> > test files]
> > ?   github.com/cli/cli/v2/internal/codespaces/grpc/test [no 
> > test files]
> > ?   github.com/cli/cli/v2/internal/config   [no test files]
[...]

Port 16634 is hardcoded at:
./internal/codespaces/grpc/client.go:   codespacesInternalPort=
16634

If this port is not available I presume things will just fail.

I've rebuilt the package locally and it succeeds for me. It also
succeded on the official buildds.

If you are able to reproduce the problem it would be great if you could
check what is using the port to identify if it's some external program
using this port and thus making the test fail or if it possibly is the
test-suite racing against itself somehow.

As far as I can tell right now, this issue doesn't seem release-critical to me
so consider if maybe the severity should be downgraded.

Regards,
Andreas Henriksson

Bug#1025183: silx: (autopkgtest) needs update for python3.11: Segmentation fault

[Adrian Bunk]

On Sat, Dec 03, 2022 at 10:06:21PM +1100, Stuart Prescott wrote:
> It appears that src:silx FTBFS at present too. The failure is during
> building the docs with python3.10, meaning that this failure predates
> python3.11.
> 
> The failing line is:
> 
> # build the documentation
> pybuild --build -s custom -p 3.10 --build-args="cd doc && env
> PYTHONPATH={build_dir} http_proxy='127.0.0.1:9' xvfb-run -a
> --server-args=\"-screen 0 1024x768x24\" {interpreter} -m sphinx -N -bhtml
> source build/html"
> I: pybuild base:240: cd doc && env 
> PYTHONPATH=/build/silx-pvssnu/silx-1.1.0+dfsg/.pybuild/cpython3_3.10_silx/build
> http_proxy='127.0.0.1:9' xvfb-run -a --server-args="-screen 0 1024x768x24"
> python3.10 -m sphinx -N -bhtml source build/html
> Running Sphinx v4.5.0
> [...snip...]
> reading sources... [ 92%] modules/sx
> qt.qpa.xcb: could not connect to display :109
> qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though
> it was found.
> This application failed to start because no Qt platform plugin could be
> initialized. Reinstalling the application may fix this problem.
> 
> Available platform plugins are: eglfs, linuxfb, minimal, minimalegl,
> offscreen, vnc, xcb.
> 
> Aborted (core dumped)

This doesn't happen for me or in the reproducible CI,
it might be (or was) a bug that only triggers in some setups?

cu
Adrian

Bug#1019790: eviacam: diff for NMU version 2.1.4-2.1

[Bastian Germann]

On Thu, 5 Jan 2023 09:43:48 +1300 Olly Betts  wrote:

I can't test the patch I attached earlier due to the other bug.  If
that bug is specific to some webcams/systems I could NMU the patch
without testing if you think that's useful (let me know).  I'm hesitant
to try applying the PR too as I'm not at all familiar with this package,
- it seems better for the maintainer to do that.


I have just tested the patch and uploaded it as-is as NMU to DELAYED/10.

Bug#1028633: mlpack: FTBFS: mkdir: cannot create directory ‘/usr/lib/python3.11/site-packages/’: Permission denied

[Sebastian Ramacher]

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

https://buildd.debian.org/status/fetch.php?pkg=mlpack&arch=amd64&ver=4.0.1-1&stamp=1673622675&raw=0

-- Installing: 
/<>/debian/tmp/usr/include/mlpack/methods/CMakeLists.txt
mkdir: cannot create directory ‘/usr/lib/python3.11/site-packages/’: Permission 
denied
/usr/bin/python3: No module named pip
CMake Error at 
/<>/src/mlpack/bindings/python/PythonInstall.cmake:23 (message):
  Error installing Python bindings!
Call Stack (most recent call first):
  src/mlpack/bindings/python/cmake_install.cmake:66 (include)
  src/mlpack/bindings/cmake_install.cmake:50 (include)
  src/mlpack/cmake_install.cmake:68 (include)
  cmake_install.cmake:55 (include)


make[1]: *** [Makefile:113: install] Error 1


Cheers
-- 
Sebastian Ramacher

Bug#1028634: tiledarray: FTBFS: Could not find a package configuration file provided by "blaspp"

[Sebastian Ramacher]

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

https://buildd.debian.org/status/fetch.php?pkg=tiledarray&arch=amd64&ver=1.0.0-1&stamp=1673359717&raw=0


-- Performing Test EIGEN3_COMPILES - Success
CMake Error at /usr/share/cmake-3.25/Modules/CMakeFindDependencyMacro.cmake:47 
(find_package):
  Could not find a package configuration file provided by "blaspp" with any
  of the following names:

blasppConfig.cmake
blaspp-config.cmake

  Add the installation prefix of "blaspp" to CMAKE_PREFIX_PATH or set
  "blaspp_DIR" to a directory containing one of the above files.  If "blaspp"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  /usr/lib/cmake/BTAS/btas-config.cmake:104 (find_dependency)
  cmake/modules/FindOrFetchBTAS.cmake:1 (find_package)
  CMakeLists.txt:279 (include)

Cheers
-- 
Sebastian Ramacher

Bug#1028624: libdeflate: Please build with -O1 on alpha to fix FTBFS

[Michael Cree]

On Fri, Jan 13, 2023 at 08:05:43PM +0100, John Paul Adrian Glaubitz wrote:
> libdeflate currently FTBFS on alpha due to linker issues:
> 
> cc -o libdeflate.so.0 -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro 
> -Wl,-z,now -fprofile-generate -O2 -fomit-frame-pointer -std=c99 -I. -Wall 
> -Wundef -Wdeclaration-after-statement -Wimplicit-fallthrough 
> -Wmissing-prototypes -Wpedantic -Wshadow -Wstrict-prototypes -Wvla -g -O2 
> -ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs 
> -Wformat -Werror=format-security -fprofile-generate -fvisibility=hidden 
> -D_ANSI_SOURCE \
>   -Wl,-soname=libdeflate.so.0 -shared lib/deflate_decompress.shlib.o 
> lib/utils.shlib.o lib/arm/cpu_features.shlib.o lib/x86/cpu_features.shlib.o 
> lib/deflate_compress.shlib.o lib/adler32.shlib.o lib/zlib_decompress.shlib.o 
> lib/zlib_compress.shlib.o lib/crc32.shlib.o lib/gzip_decompress.shlib.o 
> lib/gzip_compress.shlib.o
> lib/deflate_compress.shlib.o: in function `deflate_choose_match':
> ./lib/deflate_compress.c:2185:(.text+0x832c): relocation truncated to fit: 
> GPRELHIGH against `.rodata'

I suspect this might be better worked around with -Wl,-no-relax on the
linking only rather than disabling compiler optimisations.  I intend to
run a test of that today.

Cheers,
Michael.

Bug#1027803: src:fakeroot: fails to migrate to testing for too long: ftbfs on mipsel

[Andreas Henriksson]

Hello,

So the mipsel FTBFS is because of a failing test-case that was added in
the 1.30-1 version of fakeroot.

For more information on this issue see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023286#48

Regards,
Andreas Henriksson

Bug#1028559: pypdf2: replace with pypdf

[Daniel Kahn Gillmor]

On Fri 2023-01-13 14:24:12 -0500, Daniel Kahn Gillmor wrote:
> Works for me.  I'll change the repository description to remove the term
> "prospective" (it's currently "proposed packaging history for pypdf2 and
> its successor, pypdf")

This is now done, and i've uploaded 2.12.1 of pypdf2 with baseline
packaging fixes, including a cleanup of debian/watch to only look for
versions on the 2.x series.  (took me three tries -- i had to correct my
own mistake for the Vcs-* fields, and to disable two more network tests,
sorry for the sloppiness)

> I'll take a crack at that.  I'll probably do it with two separate
> branches in a single repository, so we can just have one place where the
> work on the two packages is happening.

I'm working on this now, but...

> At the moment, i suspect the biggest challenge for getting a pypdf
> package into debian is related to #1028570: the licensing for the sample
> documents is not DFSG-free

I've taken the approach for now that we'll just skip the sample-files.
Looks like we can use the pytest annotations to do that, as well as
skipping the externally-fetched files.  (there are some missing upstream
annotations, but upstream will hopefully accept those fixes directly:
https://github.com/py-pdf/pypdf/pull/1551)

I've pushed that work to debian/unstable in the same repository, and i
should have an upload for pypdf 3.2.1 in NEW by the time you receive
this.  Please let me know if you have any concerns with the choices i've
made here.

 --dkg


signature.asc
Description: PGP signature

Bug#1028278: dh-cmake FTBFS with Python 3.11 as default version

[Andreas Henriksson]

On Mon, Jan 09, 2023 at 08:02:05AM +0200, Adrian Bunk wrote:
> Source: dh-cmake
> Version: 0.6.1
> Severity: serious
> Tags: ftbfs bookworm sid
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dh-cmake.html
[...]
> 
>   File "/build/1st/dh-cmake-0.6.1/dhcmake/tests/source_check.py", line 25, in 
> 
> self.foreach_py(lambda a, r, c: self.assertEqual(autopep8.fix_code(c), c,
> ^
> AssertionError: '# Th[204 chars]\n\n# from unittest import skip\n\nimport 
> os\n[9838 chars]e)\n' != '# Th[204 chars]\n\n#from unittest import 
> skip\n\nimport os\nf[9837 chars]e)\n'
> Diff is 10430 characters long. Set self.maxDiff to None to see it. : File 
> dhcmake/tests/common.py is incorrectly formatted
[...]

So same as above, but in my own words:
It seems autopep8.fix_code() has changed it's opinion on formatting and
now thinks dhcmake/tests/common.py line 5 should have a space after
the hash (#) character (before `from unittest import skip`).

The new style looks better IMHO and this might be a bugfix in
autopep8.fix_code(), but at the same time changes like these might cause
alot of breakage (atleast if used in tests like in this case).

Regards,
Andreas Henriksson

Bug#1028632: tomcat10: Catalina fails to load due to missing MbeansDescriptorsIntrospectionSource

[Jorge Moraleda]

Package: tomcat10
Version: 10.0.0~M7-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: jorge.moral...@gmail.com

Dear Maintainer,

I just tested the tomcat 10 version packaged in the "debian/experimental".
(10.0.0~M7-1) on top of a recent debian 12 (bookworm) installation.

It failed with "java.lang.ClassNotFoundException:
org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource".

I don't think detailed logs are necessary because:

(1) This bug is the same as https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=964908 (that one is against tomcat9).

(2) From the above it seems that it has to do with the format of "bnd" and from
this package changelogs, I believe the maintainers are already familiar with
this issue. (https://metadata.ftp-
master.debian.org/changelogs//main/t/tomcat10/tomcat10_10.0.0~M7-1_changelog)

Thank you


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tomcat10 depends on:
ii  lsb-base   11.5
ii  systemd252.4-1
ii  sysvinit-utils [lsb-base]  3.06-2
ii  tomcat10-common10.0.0~M7-1
ii  ucf3.0043

Versions of packages tomcat10 recommends:
ii  libtcnative-1  1.2.32-1+b1

Versions of packages tomcat10 suggests:
pn  tomcat10-admin 
pn  tomcat10-docs  
pn  tomcat10-examples  
pn  tomcat10-user  

-- Configuration Files:
/etc/tomcat10/policy.d/01system.policy [Errno 13] Permission denied: 
'/etc/tomcat10/policy.d/01system.policy'
/etc/tomcat10/policy.d/02debian.policy [Errno 13] Permission denied: 
'/etc/tomcat10/policy.d/02debian.policy'
/etc/tomcat10/policy.d/03catalina.policy [Errno 13] Permission denied: 
'/etc/tomcat10/policy.d/03catalina.policy'
/etc/tomcat10/policy.d/04webapps.policy [Errno 13] Permission denied: 
'/etc/tomcat10/policy.d/04webapps.policy'
/etc/tomcat10/policy.d/50local.policy [Errno 13] Permission denied: 
'/etc/tomcat10/policy.d/50local.policy'

-- no debconf information

Bug#1028631: media-types: rss is associated with application/x-rss+xml instead of application/rss+xml

[Giuseppe Bilotta]

Package: media-types
Version: 8.0.0
Severity: normal

Although the IANA registratio was apparently never finished, it is de facto 
used everywhere today.

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

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

-- no debconf information

Bug#946434: /usr/games/ace-freecell: feature request: add undo funktion

[Markus Koschany]

Control: severity -1 wishlist

This is a feature request. Unfortunately upstream is no longer active. Patches
are welcome.

Markus


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

Bug#1028630: RFP: proftpd-mod-sftp-ldap -- module for ProFTPD supports retrieving/using user SSH public keys from LDAP

[Paweł Tomulik]

Package: proftpd-dfsg

Severity: wishlist

ProFTPD mod_sftp_ldap may be very useful for ProFTPD installations with 
virtual users stored in LDAP database together with SSH keys. It enables 
the authentication based on these keys stored in LDAP.


The upstream project is here: 
https://github.com/Castaglia/proftpd-mod_sftp_ldap


I've initially packaged it for Debian, and put here: 
https://gitlab.com/ptomulik/proftpd-mod_sftp_ldap


I'd love to see it appear in official Debian repos. The upstream has no 
tags yet, so I created dummy 0.1.0 in my project (at gitlab.com).


Regards!

--
Paweł Tomulik

Bug#1028629: rustc: (some) atomic intrinsics on armel broken

[Fabian Grünbichler]

Package: rustc
Version: 1.63.0+dfsg1-1
Severity: important
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net

rustc fails to (successfully) link crates using parts of
std::sync::atomic, e.g. the following code in (lib) crate bar:

--8<-
use std::sync::atomic::AtomicU32;
use std::sync::atomic::Ordering;

pub fn max(left: AtomicU32, right: u32) -> u32 {
left.fetch_max(right, Ordering::SeqCst)
}
-->8-

and the following code in (bin) crate foo:

--8<-
use std::sync::atomic::AtomicU32;

use bar;

fn main() {
println!("{}", bar::max(AtomicU32::new(7), 5));
}
-->8-

will lead to the following linking error on armel:

--8<-
# cargo run --release
   Compiling foo v0.1.0 (/build/test/foo)
error: linking with `cc` failed: exit status: 12: foo(bin)
  |
  = note: "cc" "/tmp/rustcTFx4i9/symbols.o" 
"/build/test/foo/target/release/deps/foo-59f27b1de92f2acd.foo.1afac17f-cgu.0.rcgu.o"
 
"/build/test/foo/target/release/deps/foo-59f27b1de92f2acd.foo.1afac17f-cgu.1.rcgu.o"
 
"/build/test/foo/target/release/deps/foo-59f27b1de92f2acd.foo.1afac17f-cgu.2.rcgu.o"
 
"/build/test/foo/target/release/deps/foo-59f27b1de92f2acd.20wjxsqwz98t4wkq.rcgu.o"
 "-Wl,--as-needed" "-L" "/build/test/foo/target/release/deps" "-L" 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib" "-Wl,-Bstatic" 
"/build/test/foo/target/release/deps/libbar-7fb8e41530f4ad06.rlib" 
"-Wl,--start-group" 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libstd-6a651d83c44843bb.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libpanic_unwind-98224a094117fb61.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libobject-6353760ce6c6ab47.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libmemchr-b7d0d45279218739.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libaddr2line-eda5e1e22d9f768c.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libgimli-f2321664649c6488.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/librustc_demangle-1882c2f330ea3722.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libstd_detect-1e9ab0673b70075d.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libhashbrown-a18bf1b0b60baadc.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libminiz_oxide-eb7e10deb950ff71.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libadler-ebe0d9eb71624a17.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/librustc_std_workspace_alloc-d0b17dce6de8f743.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libunwind-b85b839502ab2b62.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libcfg_if-2adecf55c5fb13fa.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/liblibc-3cb92b5edcc2e566.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/liballoc-657f47a57064518b.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/librustc_std_workspace_core-bc3b35b3d32be632.rlib"
 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libcore-c809391b20961e50.rlib"
 "-Wl,--end-group" 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib/libcompiler_builtins-bc99d51bba3f7a8e.rlib"
 "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" 
"-Wl,--eh-frame-hdr" "-Wl,-znoexecstack" "-L" 
"/usr/lib/rustlib/armv5te-unknown-linux-gnueabi/lib" "-o" 
"/build/test/foo/target/release/deps/foo-59f27b1de92f2acd" "-Wl,--gc-sections" 
"-pie" "-Wl,-zrelro,-znow" "-Wl,-O1" "-nodefaultlibs"
  = note: /usr/bin/ld: 
/build/test/foo/target/release/deps/libbar-7fb8e41530f4ad06.rlib(bar-7fb8e41530f4ad06.bar.b0a8f44d-cgu.0.rcgu.o):
 in function `bar::add':
  bar.b0a8f44d-cgu.0:(.text._ZN3bar3add17hce88dc9d839331b9E+0x24): 
undefined reference to `__sync_fetch_and_umax_4'
  collect2: error: ld returned 1 exit status

  = help: some `extern` functions couldn't be found; some native libraries may 
need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native 
libraries to link with Cargo (see 
https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `foo` due to previous error
(debian-test-armel-sbuild)root@zen:/build/test/foo# cargo clean
(debian-test-armel-sbuild)root@zen:/build/test/foo# cargo run
   Compiling bar v0.1.0 (/build/test/bar)
   Compiling foo v0.1.0 (/build/test/foo)  ] 0/2: bar
error: linking with `cc` failed: exit status: 12: foo(bin)
  |
  = note: "cc" "/tmp/rustckvzoGP/symbols.o" 
"/build/test/foo/target/debug/deps/foo-f1598fa86eee5ab8.2e9m1dxvxhlpjv6f.rcgu.o"
 
"/build/test/foo/target/debug/deps/foo-f1598fa86eee5ab8.2kv2r3chzehpy591.rcgu.o"
 
"/build/test/foo/target/debug/deps/foo-f1598fa86eee5ab8.2w6od5db0a6s353m.rcgu.o"
 
"/build/test/foo/target/debug/deps/foo-f1598fa86eee5ab8.35evzsnqbqvn39ld.rcgu.o"
 
"/build/test/foo/target/debug/deps/foo-f1598fa86eee5ab8.3yygjnxroz9tmefv.

Bug#1028251: [Pkg-xen-devel] Bug#1028251: New Patch (Was: Re: Bug#1028251: xen: FTBFS when building xen binary packages for sid on x86_64)

[Chuck Zmudzinski]

On 1/13/23 7:39 AM, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2023 at 12:58:29AM -0500, Chuck Zmudzinski wrote:
>> On 1/11/2023 10:58 PM, Chuck Zmudzinski wrote:
>> > On 1/9/23 12:55 PM, Hans van Kranenburg wrote:
>> > > Hi!
>> > > 
>> > > On 09/01/2023 18:44, Chuck Zmudzinski wrote:
>> > >> Control: tag -1 + moreinfo
>> > >> 
>> > >> thanks
>> > >> 
>> > >> On 1/9/23 8:09 AM, Hans van Kranenburg wrote:
>> > >>> Hi Chuck,
>> > >>>
>> > >>> On 1/8/23 23:18, Chuck Zmudzinski wrote:
>> >  [...]
>> > 
>> >  The build failed:
>> > 
>> > debian/rules override_dh_missing
>> >  make[1]: Entering directory '/home/chuckz/sources-sid/xen/xen-4.17.0'
>> >  dh_missing --list-missing
>> >  dh_missing: warning: usr/lib/modules-load.d/xen.conf exists in 
>> >  debian/tmp but is not installed to anywhere
>> >  dh_missing: warning: usr/lib/systemd/system/proc-xen.mount exists in 
>> >  debian/tmp but is not installed to anywhere
>> >  dh_missing: warning: usr/lib/systemd/system/xen-init-dom0.service 
>> >  exists in debian/tmp but is not installed to anywhere
>> >  dh_missing: warning: 
>> >  usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service exists in 
>> >  debian/tmp but is not installed to anywhere
>> >  dh_missing: warning: usr/lib/systemd/system/xen-watchdog.service 
>> >  exists in debian/tmp but is not installed to anywhere
>> >  dh_missing: warning: usr/lib/systemd/system/xenconsoled.service 
>> >  exists in debian/tmp but is not installed to anywhere
>> >  dh_missing: warning: usr/lib/systemd/system/xendomains.service exists 
>> >  in debian/tmp but is not installed to anywhere
>> >  dh_missing: warning: usr/lib/systemd/system/xendriverdomain.service 
>> >  exists in debian/tmp but is not installed to anywhere
>> >  dh_missing: warning: usr/lib/systemd/system/xenstored.service exists 
>> >  in debian/tmp but is not installed to anywhere
>> > >>>
>> > >>> I cannot reproduce this error here locally and the CI build also 
>> > >>> succeeds:
>> > >>>
>> > >>> https://salsa.debian.org/xen-team/debian-xen/-/pipelines/481577
>> > >> 
>> > >> I thought I had a fairly clean sid install, but I think the problem
>> > >> on my system could be caused by some obscure grandfathered in
>> > >> setting because the sid I am using was updated from all the way back to
>> > >> an original install of jessie many years ago...
>> > >> 
>> > >> It might be time for me to refresh my sid with a clean installation.
>> > >> 
>> > >> Out of curiosity and if you have time, can you answer a couple of
>> > >> question if you know the answer?
>> > >> 
>> > >> 1. Do the builds on a clean environment produce the missing files
>> > >> listed in my build?
>> > > 
>> > > No, after my local package build, there's no such things in there:
>> > > 
>> > > ~/build/xen/debian-xen/debian/tmp/usr/lib m (master) 1-$ ll
>> > > total 0
>> > > drwxr-xr-x 1 knorrie knorrie  110 Jan  8 23:51 debug
>> > > drwxr-xr-x 1 knorrie knorrie 2048 Jan  8 23:50 x86_64-linux-gnu
>> > > drwxr-xr-x 1 knorrie knorrie   20 Jan  8 23:51 xen-4.17
>> > > 
>> > >> 
>> > >> 2. Are those systemd service files installed anywhere in the xen
>> > >> binary packages, either in arch=x86_64 packages or for the arch=all
>> > >> packages such as xen-utils-common?
>> > > 
>> > > No, they are not:
>> > > 
>> > > https://packages.debian.org/search?searchon=contents&keywords=xenconsoled.service&mode=path&suite=unstable&arch=any
>> > > 
>> > >> If you don't know the answer to these questions I will investigate
>> > >> myself to find the answers, so you can work on more important things.
>> > >> 
>> > >>>
>> > >>> How are you building the packages? In a clean build environment, using
>> > >>> for example sbuild or pbuilder, or in an environment where unrelated
>> > >>> other build dependencies could be present, that are not included in the
>> > >>> xen list, but maybe 'wake up and do something' if they're present?
>> > >> 
>> > >> As I said, I am building on a sid install that might have some
>> > >> stuff grandfathered in from old releases going back to jessie.
>> > >> I also might have some stale stuff around from my private builds
>> > >> of the traditional device model available from xen that is not
>> > >> part of the Debian packages. I will investigate these possible causes.
>> > >> 
>> > >> I use debuild as a frontend to dpkg-buildpackage to build the packages.
>> > > 
>> > > Yes. So (I'm not entirely sure how it works, but as example, just making
>> > > something up here): After doing something else first, you might end up
>> > > with a system that has for example dh-systemd-yolo-all-the-things-helper
>> > > installed. And, it might be that only it being present means that the
>> > > package build process changes. It might even be a 'feature' of that
>> > > helper... "just add it to your build depends, and it will automatically
>> > > do all the things for you!!!~``1"
>>

Bug#1025884: src:ddnet: fails to migrate to testing for too long: FTBFS on s390x

[Andreas Henriksson]

Hello,

The upstream PR fixing big endian builds that Adrian Bunk previously
set in the forwarded control message is now merged upstream.
It would be great if this commit could be cherry-picked as a patch
into the ddnet package to fix build os s390x (big endian):

https://github.com/ddnet/ddnet/commit/abb1979d20d9a3290442d5d0ed304ce24c0a710e

Regards,
Andreas Henriksson

Bug#1028146: collectd FTBFS with Python 3.11 as default version

[Andreas Henriksson]

Control: tags -1 + fixed-upstream
Control: forwarded -1 
https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/11

Hello,

The python 3.11 issue is fixed upstream in this commit:
https://github.com/collectd/collectd/commit/623e95394e0e62e7f9ced2104b786d21e9c0bf53

A merge-request against the debian collectd packaging git repo has been
opened, albeit with a different patch than upstreams:
https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/11

Regards,
Andreas Henriksson

Bug#1028523: dpkg-dev: No obvious way to include upstream signature in dpkg-genchanges

[Sven Joachim]

Am 13.01.2023 um 21:50 schrieb Helge Kreutzmann:

> Hello Sven,
> On Fri, Jan 13, 2023 at 09:36:47PM +0100, Sven Joachim wrote:
>> Am 13.01.2023 um 21:16 schrieb Helge Kreutzmann:
>> > Maybe we use the tools differently?
>> >
>> > Since we use source only uploads, I run:
>> > dpkg-buildpackage --changes-option=-S
>>
>> I was a bit lazier and ran "dpkg-buildpackage -S", not even bothering to
>> build binaries.  But it does not really matter, as ultimately every tool
>> eventually runs "dpkg-source -b ." to create the .dsc file.  Here is
>> what I got with your command:
>>
>> ,
>> | $ LANG=C dpkg-buildpackage -uc -us --changes-option=-S
>> | dpkg-buildpackage: info: source package linuxinfo
>> | dpkg-buildpackage: info: source version 4.1.2-3
>> | dpkg-buildpackage: info: source distribution unstable
>> | dpkg-buildpackage: info: source changed by Helge Kreutzmann 
>> 
>> |  dpkg-source --before-build .
>> | dpkg-buildpackage: info: host architecture amd64
>> |  debian/rules clean
>> | dh clean
>> |dh_clean
>> |  dpkg-source -b .
>> | dpkg-source: info: using source format '3.0 (quilt)'
>> | dpkg-source: info: verifying ./linuxinfo_4.1.2.orig.tar.xz.asc
>> | dpkg-source: info: building linuxinfo using existing 
>> ./linuxinfo_4.1.2.orig.tar.xz
>> | dpkg-source: info: building linuxinfo using existing 
>> ./linuxinfo_4.1.2.orig.tar.xz.asc
>> | dpkg-source: info: building linuxinfo in linuxinfo_4.1.2-3.debian.tar.xz
>> | dpkg-source: info: building linuxinfo in linuxinfo_4.1.2-3.dsc
>> | [...]
>> `
>>
>> As you can see, dpkg-source included the orig.tar.xz.asc file.
>>
>> > And I screwed up linuxinfo 4.1.2-1, thus I decided to also include the
>> > signature and tried to do 4.1.2-2 (which failed) and manually added it
>> > in 4.1.2-3 (which is now in the archive).
>> >
>> > For now, I noticed down to add the asc file manually, but I don't
>> > think this is a desirable solution.
>>
>> Can you please send a build log?
>
> Please find it attached.
>
> As you can see, "linuxinfo_4.1.2.orig.tar.xz.asc" is contained in the
> .dsc file, but not in the .changes file.

This is the opposite of what you wrote in the original report (where the
.asc file was in the changes file and not in the .dsc), and is in fact
normal as you did not include the upstream sources (the default if
debian/changelog indicates that this is not the first debian revision).

> When I uploaded this (with -2) the archive rejected this.

Yes, because your .dsc file referenced the .asc file, but the changes
file did not include it, nor was the file already in the archive.

> I manually edited the .changes to add
> "linuxinfo_4.1.2.orig.tar.xz.asc", and this worked.

I guess could also have passed "-sa" to dpkg-buildpackage to include the
full sources again, but whatever worked for you.

Still I am unable to reproduce your original problem.

Cheers,
   Sven

Bug#1028628: rust-lsd: ftbfs, build-depends on librust-lscolors-0.12+default-dev

[Jeremy Bicha]

Source: rust-lsd
Version: 0.23.1-1
Severity: serious
Tags: ftbfs

rust-lsd fails to build from source because it Build-Depends on
librust-lscolors-0.12+default-dev but the current version of
rust-lscolors in Debian is 0.13

Thank you,
Jeremy Bicha

Bug#1028627: live-tools: Typo in a kernel parameter name

[Adam Vodopjan]

Package: live-tools
Version: 1:20190831
Severity: normal
Tags: patch
X-Debbugs-Cc: adam.vodop...@gmail.com

Dear Maintainer,

I've found a typo in a kernel parameter name in live-tools package:
'find_iso' instead of 'findiso'. It affects reboot/shutdown process in a
multiboot scenario.

So I created a multiboot disk image based on grub config from
https://wiki.debian.org/DebianLive/MultibootISO and put there latest
debian 8, 9, 10, 11 iso.

Next I boot into some iso with the disk and try to reboot or shutdown. In
case of debian 8/9 it just works (because of another bug fixed in debian
10: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831830), in case of
debian 10/11 there is a 90 secs countdown for the user to press Enter.

Let me outline it clearly: the problem dates to the times 'findiso' thing
was implemented, it was NOT introduced in debian 10.

So in debian 10 on reboot/shutdown I get such message with a countdown:

A stop job is running for live-tools - System Support Scripts (xx /
1min 30s)

If I press Enter during the countdown, it proceeds immediately.

In debian 11 case there is no visible countdown, but such message:

Please remove the live-medium, close the tray (if any) and press ENTER
to continue

The message goes away in 90 secs by itself so there is a countdown similar
to the debian 10 case but a hidden one.

Here is the source of the problem:

/bin/live-medium-eject:

18: # Exit if system is findiso
19: grep -qs "find_iso" /proc/cmdline || \

Evidently, it should be 'findiso'. With the typo fixed reboot/shutdown
performs flawlessly.

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

Kernel: Linux 5.10.0-20-amd64 (SMP w/2 CPU threads)
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 live-tools depends on:
ii initramfs-tools 0.140
ii lsb-base 11.1.0

live-tools recommends no packages.

Versions of packages live-tools suggests:
pn debian-installer-launcher 
ii eject 2.36.1-8+deb11u1
ii perl 5.32.1-4+deb11u2
ii procps 2:3.3.17-5
ii rsync 3.2.3-4+deb11u1
ii uuid-runtime 2.36.1-8+deb11u1

-- no debconf information

diff --git a/bin/live-medium-eject b/bin/live-medium-eject
index f4f37c4..2414b2d 100755
--- a/bin/live-medium-eject
+++ b/bin/live-medium-eject
@@ -16,7 +16,7 @@ if ! grep -qs "boot=live" /proc/cmdline || \
grep -qs "root=/dev/nfs" /proc/cmdline || \
grep -qs "root=/dev/cifs" /proc/cmdline || \
 # Exit if system is findiso
-   grep -qs "find_iso" /proc/cmdline || \
+   grep -qs "findiso" /proc/cmdline || \
 # Exit if system is toram
grep -qs "toram" /proc/cmdline || \
 # Exit if user disabled medium eject

Bug#1028523: dpkg-dev: No obvious way to include upstream signature in dpkg-genchanges

[Helge Kreutzmann]

Hello Sven,
On Fri, Jan 13, 2023 at 09:36:47PM +0100, Sven Joachim wrote:
> Am 13.01.2023 um 21:16 schrieb Helge Kreutzmann:
> > On Fri, Jan 13, 2023 at 09:05:21PM +0100, Sven Joachim wrote:
> >> Am 12.01.2023 um 11:29 schrieb Helge Kreutzmann:
> >>
> >> > Package: dpkg-dev
> >> > Version: 1.21.17
> >> > Severity: normal
> >> >
> >> > I got a linitian error for my package (linuxinfo) that the upstream
> >> > signature is missing and should be put alongside the .orig.tar.xz
> >> > during the build.
> >> >
> >> > This worked, the signature was included in the .changes file. However,
> >> > it is not included in the .dsc file.
> >>
> >> I cannot reproduce this.  If I provide the upstream signature as
> >> linuxinfo_4.1.2.orig.tar.xz.asc, it ends up in both the .changes and the
> >> .dsc files.  The .changes file for linuxinfo 4.1.2-1 which you uploaded[1]
> >> does not contain it.
> >
> > Maybe we use the tools differently?
> >
> > Since we use source only uploads, I run:
> > dpkg-buildpackage --changes-option=-S
> 
> I was a bit lazier and ran "dpkg-buildpackage -S", not even bothering to
> build binaries.  But it does not really matter, as ultimately every tool
> eventually runs "dpkg-source -b ." to create the .dsc file.  Here is
> what I got with your command:
> 
> ,
> | $ LANG=C dpkg-buildpackage -uc -us --changes-option=-S
> | dpkg-buildpackage: info: source package linuxinfo
> | dpkg-buildpackage: info: source version 4.1.2-3
> | dpkg-buildpackage: info: source distribution unstable
> | dpkg-buildpackage: info: source changed by Helge Kreutzmann 
> 
> |  dpkg-source --before-build .
> | dpkg-buildpackage: info: host architecture amd64
> |  debian/rules clean
> | dh clean
> |dh_clean
> |  dpkg-source -b .
> | dpkg-source: info: using source format '3.0 (quilt)'
> | dpkg-source: info: verifying ./linuxinfo_4.1.2.orig.tar.xz.asc
> | dpkg-source: info: building linuxinfo using existing 
> ./linuxinfo_4.1.2.orig.tar.xz
> | dpkg-source: info: building linuxinfo using existing 
> ./linuxinfo_4.1.2.orig.tar.xz.asc
> | dpkg-source: info: building linuxinfo in linuxinfo_4.1.2-3.debian.tar.xz
> | dpkg-source: info: building linuxinfo in linuxinfo_4.1.2-3.dsc
> | [...]
> `
> 
> As you can see, dpkg-source included the orig.tar.xz.asc file.
> 
> > And I screwed up linuxinfo 4.1.2-1, thus I decided to also include the
> > signature and tried to do 4.1.2-2 (which failed) and manually added it
> > in 4.1.2-3 (which is now in the archive).
> >
> > For now, I noticed down to add the asc file manually, but I don't
> > think this is a desirable solution.
> 
> Can you please send a build log?

Please find it attached.

As you can see, "linuxinfo_4.1.2.orig.tar.xz.asc" is contained in the
.dsc file, but not in the .changes file.

When I uploaded this (with -2) the archive rejected this.

I manually edited the .changes to add
"linuxinfo_4.1.2.orig.tar.xz.asc", and this worked.

Greetings

   Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
Script started on 2023-01-13 21:46:32+01:00 [TERM="linux" TTY="/dev/tty11" 
COLUMNS="240" LINES="75"]
[?2004hhelge@twentytwo:/tmp/libuild$ dpkg-buildpackage --changes-option=-S
cd
 linuxinfo-4.1.2-3/
[?2004l
[?2004hhelge@twentytwo:/tmp/libuild/linuxinfo-4.1.2-3$ dpkg-buildpackage 
--changes-option=-S
[?2004l
dpkg-buildpackage: Information: Quellpaket linuxinfo
dpkg-buildpackage: Information: Quellversion 4.1.2-3
dpkg-buildpackage: Information: Quelldistribution unstable
dpkg-buildpackage: Information: Quelle geändert durch Helge 
Kreutzmann 
dpkg-buildpackage: Information: Host-Architektur amd64
 dpkg-source --before-build .
 debian/rules clean
dh clean
   dh_clean
 dpkg-source -b .
dpkg-source: Information: Quellformat »3.0 (quilt)« wird 
verwendet
dpkg-source: Information: ./linuxinfo_4.1.2.orig.tar.xz.asc 
wird überprüft
dpkg-source: Information: linuxinfo wird unter Benutzung des 
existierenden ./linuxinfo_4.1.2.orig.tar.xz gebaut
dpkg-source: Information: linuxinfo wird unter Benutzung des 
existierenden ./linuxinfo_4.1.2.orig.tar.xz.asc gebaut
dpkg-source: Information: linuxinfo wird in 
linuxinfo_4.1.2-3.debian.tar.xz gebaut
dpkg-source: Information: linuxinfo wird in 
linuxinfo_4.1.2-3.dsc gebaut
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
Copying file m4/codeset.m4
Copying file m4/fcntl-o.m4
Copying file m4/glibc2.m4
Copying file m4/glibc21.m4
Copying file m4/intdiv0.

Bug#996799: twitterwatch - upload needed

[Malik]

Hello DPT,

I have created a patch to close #996799 in twitterwatch package [1]
I need a mainter to upload the current version (0.1-3) to the tftp-master

[1] https://salsa.debian.org/python-team/packages/twitterwatch

Thank you in  advance
-- 
Malik Mlitat

Bug#965006:

[Markus Koschany]

Am Freitag, dem 13.01.2023 um 12:47 -0600 schrieb Jorge Moraleda:
> I think getting tomcat 10 into unstable so it is in a path to eventually
> making into testing and then stable has become a higher priority now that
> tomcat 10 is required when using webapps developed using the latest Spring
> framework version
> (https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-6.x
> )

[...]

Tomcat 10 coming to unstable this weekend. Stay tuned!

Markus


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

Bug#1027283: transition: tiff

[Sebastiaan Couwenberg]

Please also binNMU grass in experimental.

Kind Regards,

Bas

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

Bug#1028523: dpkg-dev: No obvious way to include upstream signature in dpkg-genchanges

[Sven Joachim]

Hello Helge,

Am 13.01.2023 um 21:16 schrieb Helge Kreutzmann:

> Hello Sven,
> On Fri, Jan 13, 2023 at 09:05:21PM +0100, Sven Joachim wrote:
>> Am 12.01.2023 um 11:29 schrieb Helge Kreutzmann:
>>
>> > Package: dpkg-dev
>> > Version: 1.21.17
>> > Severity: normal
>> >
>> > I got a linitian error for my package (linuxinfo) that the upstream
>> > signature is missing and should be put alongside the .orig.tar.xz
>> > during the build.
>> >
>> > This worked, the signature was included in the .changes file. However,
>> > it is not included in the .dsc file.
>>
>> I cannot reproduce this.  If I provide the upstream signature as
>> linuxinfo_4.1.2.orig.tar.xz.asc, it ends up in both the .changes and the
>> .dsc files.  The .changes file for linuxinfo 4.1.2-1 which you uploaded[1]
>> does not contain it.
>
> Maybe we use the tools differently?
>
> Since we use source only uploads, I run:
> dpkg-buildpackage --changes-option=-S

I was a bit lazier and ran "dpkg-buildpackage -S", not even bothering to
build binaries.  But it does not really matter, as ultimately every tool
eventually runs "dpkg-source -b ." to create the .dsc file.  Here is
what I got with your command:

,
| $ LANG=C dpkg-buildpackage -uc -us --changes-option=-S
| dpkg-buildpackage: info: source package linuxinfo
| dpkg-buildpackage: info: source version 4.1.2-3
| dpkg-buildpackage: info: source distribution unstable
| dpkg-buildpackage: info: source changed by Helge Kreutzmann 

|  dpkg-source --before-build .
| dpkg-buildpackage: info: host architecture amd64
|  debian/rules clean
| dh clean
|dh_clean
|  dpkg-source -b .
| dpkg-source: info: using source format '3.0 (quilt)'
| dpkg-source: info: verifying ./linuxinfo_4.1.2.orig.tar.xz.asc
| dpkg-source: info: building linuxinfo using existing 
./linuxinfo_4.1.2.orig.tar.xz
| dpkg-source: info: building linuxinfo using existing 
./linuxinfo_4.1.2.orig.tar.xz.asc
| dpkg-source: info: building linuxinfo in linuxinfo_4.1.2-3.debian.tar.xz
| dpkg-source: info: building linuxinfo in linuxinfo_4.1.2-3.dsc
| [...]
`

As you can see, dpkg-source included the orig.tar.xz.asc file.

> And I screwed up linuxinfo 4.1.2-1, thus I decided to also include the
> signature and tried to do 4.1.2-2 (which failed) and manually added it
> in 4.1.2-3 (which is now in the archive).
>
> For now, I noticed down to add the asc file manually, but I don't
> think this is a desirable solution.

Can you please send a build log?

Cheers,
   Sven

Bug#1028626: ITP: parsec-service -- Abstraction layer for secure storage and operations

[Emanuele Rocca]

Package: wnpp
Severity: wishlist
Owner: Emanuele Rocca 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: parsec-service
  Version : 1.1.0
  Upstream Author : Parsec Project Contributors
* URL : https://github.com/parallaxsecond/parsec
* License : Apache-2.0
  Programming Lang: Rust
  Description : Abstraction layer for secure storage and operations

 Parsec is an abstraction layer that can be used to interact with
 hardware-backed security facilities such as the Hardware Security Module (HSM),
 the Trusted Platform Module (TPM), firmware-backed, and isolated software
 services.
 .
 The core component of Parsec is the security service, provided by this package.
 The service is a background process that runs on the host platform and provides
 connectivity with the secure facilities of that host, exposing a
 platform-neutral API that can be consumed into different programming languages
 using a client library.

This package will be maintained under the umbrella of the Debian Rust Team.

Bug#965215: Use --max-parallel based on available ram

[Markus Blatt]

Hi,

On Sat, 18 Jul 2020 19:54:07 +0200 Gianfranco Costamagna 
 wrote:

On Sat, 18 Jul 2020 10:09:34 +0200 Ansgar  wrote:
> On Fri, 2020-07-17 at 20:03 +0200, Gianfranco Costamagna wrote:
> > Hello, dune-common is FTBFS in Ubuntu and on systems where there is not 
enough ram, because of OOM killer.
> 


I don't think this problem is limited to dune-common or Ubuntu. It occurs for
e.g. dealii or OPM even for some Debian build machines (e.g. arm). That is
quite unfortunate.


> > Can you please consider adding --max-parallel=3 to dh invocation?
> > 
> > People might want to rebuild on their system without having to swap during the build process.
> 
> That might require parallel=1 depending on the system anyway.  I

> usually build with parallel=8 without problems, so I don't want to
> limit it to 3.
mmm what about doing something like this?
ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes),yes)
dh $@ --builddirectory=build --max-parallel=3
else
dh $@ --builddirectory=build
endif


Maybe we should rather base that on the assumed max ram needed per process.
Say that is e.g. 4 Gigabyte then one could do something similar to

free_ram = $(shell free -g | sed -n 2p| sed "s/ \+/ /g"| cut -d " " -f 2)
max_procs = $(shell echo $(free_ram)/4 | bc)
%:
dh $@ --builddirectory=build --max-parallel=$(max_procs)

Would that work?
Would need some trial and error of course...

Best,

Markus

Bug#1028523: dpkg-dev: No obvious way to include upstream signature in dpkg-genchanges

[Helge Kreutzmann]

Hello Sven,
On Fri, Jan 13, 2023 at 09:05:21PM +0100, Sven Joachim wrote:
> Am 12.01.2023 um 11:29 schrieb Helge Kreutzmann:
> 
> > Package: dpkg-dev
> > Version: 1.21.17
> > Severity: normal
> >
> > I got a linitian error for my package (linuxinfo) that the upstream
> > signature is missing and should be put alongside the .orig.tar.xz
> > during the build.
> >
> > This worked, the signature was included in the .changes file. However,
> > it is not included in the .dsc file.
> 
> I cannot reproduce this.  If I provide the upstream signature as
> linuxinfo_4.1.2.orig.tar.xz.asc, it ends up in both the .changes and the
> .dsc files.  The .changes file for linuxinfo 4.1.2-1 which you uploaded[1]
> does not contain it.

Maybe we use the tools differently?

Since we use source only uploads, I run:
dpkg-buildpackage --changes-option=-S

And I screwed up linuxinfo 4.1.2-1, thus I decided to also include the
signature and tried to do 4.1.2-2 (which failed) and manually added it
in 4.1.2-3 (which is now in the archive).

> > No I need to inform dpkg-buildpackage how to add this, however, I
> > cannot find any option to do so.
> 
> Neither can I, but I do not really see the need for it.

For now, I noticed down to add the asc file manually, but I don't
think this is a desirable solution.

Greetings

 Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1028523: dpkg-dev: No obvious way to include upstream signature in dpkg-genchanges

[Sven Joachim]

Hi Helge,

Am 12.01.2023 um 11:29 schrieb Helge Kreutzmann:

> Package: dpkg-dev
> Version: 1.21.17
> Severity: normal
>
> I got a linitian error for my package (linuxinfo) that the upstream
> signature is missing and should be put alongside the .orig.tar.xz
> during the build.
>
> This worked, the signature was included in the .changes file. However,
> it is not included in the .dsc file.

I cannot reproduce this.  If I provide the upstream signature as
linuxinfo_4.1.2.orig.tar.xz.asc, it ends up in both the .changes and the
.dsc files.  The .changes file for linuxinfo 4.1.2-1 which you uploaded[1]
does not contain it.

> No I need to inform dpkg-buildpackage how to add this, however, I
> cannot find any option to do so.

Neither can I, but I do not really see the need for it.

Cheers,
   Sven


1. 
https://tracker.debian.org/news/1407992/accepted-linuxinfo-412-1-source-into-unstable/

Bug#1028625: src:x-loader: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: x-loader
Version: 1.5.1+git20110715+fca7cd2-2
Severity: serious
Control: close -1 1.5.1+git20110715+fca7cd2-3
X-Debbugs-CC: Marcos Talau 
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1026364

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:x-loader has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. The package failed to build from 
source, which was reported in bug 1026364.


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 bookworm, 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/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=x-loader



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028559: pypdf2: replace with pypdf

[Daniel Kahn Gillmor]

hi László--

Sounds like we're roughly on the same page on this.

On Fri 2023-01-13 18:51:14 +0100, László Böszörményi (GCS) wrote:
>  I'm not sure if we know each other, but I have the knowledge that you
> are a nice guy. Sure, I'm open to collaboration and Salsa is a good
> place to start.

Works for me.  I'll change the repository description to remove the term
"prospective" (it's currently "proposed packaging history for pypdf2 and
its successor, pypdf")

>  I'm not sure what would be the best practices for this case, but
> definitely a continued packaging is preferred from my side.

I'll take a crack at that.  I'll probably do it with two separate
branches in a single repository, so we can just have one place where the
work on the two packages is happening.

>  I'm even open to you taking over the package and making me an uploader.

I'd rather not do that -- i'm happy to be an additional uploader for
now, but i don't want to be the only one responsible, as i'm kind of
under water on other work too (debian and non-debian work).  Maybe we
can collaborate to find someone else who is interested and willing to
take point on it.

At the moment, i suspect the biggest challenge for getting a pypdf
package into debian is related to #1028570: the licensing for the sample
documents is not DFSG-free, which means that the ftp team is likely to
reject any package that comes through NEW (even though it has slipped
through in the current archive).  I've opened
https://github.com/py-pdf/sample-files/issues/18 to ask upstream about
relicensing, but if that doesn't work we probably need to strategize
about other approaches for the renamed package.

One approach would be to simply upload the package without any tests.
This would be disappointing.

Another approach could be to upload the pypdf-sample-files as a separate
package, directly to non-free under the current BY-NC-ND license.  Then,
the packaging could run tests conditionally on whether that package was
installed.  This wouldn't help any of the CI or buildd networks, but it
would at least give maintainers a way to run the tests manually before
upload, and auditors a way to confirm the same in a repeatable fashion.

What do you think makes sense?

 --dkg


signature.asc
Description: PGP signature

Bug#1028624: libdeflate: Please build with -O1 on alpha to fix FTBFS

[John Paul Adrian Glaubitz]

Source: libdeflate
Version: 1.14-1
Severity: normal
Tags: patch
User: debian-al...@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian-al...@lists.debian.org

Hi!

libdeflate currently FTBFS on alpha due to linker issues:

cc -o libdeflate.so.0 -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro 
-Wl,-z,now -fprofile-generate -O2 -fomit-frame-pointer -std=c99 -I. -Wall 
-Wundef -Wdeclaration-after-statement -Wimplicit-fallthrough 
-Wmissing-prototypes -Wpedantic -Wshadow -Wstrict-prototypes -Wvla -g -O2 
-ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs 
-Wformat -Werror=format-security -fprofile-generate -fvisibility=hidden 
-D_ANSI_SOURCE \
-Wl,-soname=libdeflate.so.0 -shared lib/deflate_decompress.shlib.o 
lib/utils.shlib.o lib/arm/cpu_features.shlib.o lib/x86/cpu_features.shlib.o 
lib/deflate_compress.shlib.o lib/adler32.shlib.o lib/zlib_decompress.shlib.o 
lib/zlib_compress.shlib.o lib/crc32.shlib.o lib/gzip_decompress.shlib.o 
lib/gzip_compress.shlib.o
lib/deflate_compress.shlib.o: in function `deflate_choose_match':
./lib/deflate_compress.c:2185:(.text+0x832c): relocation truncated to fit: 
GPRELHIGH against `.rodata'
./lib/deflate_compress.c:2185:(.text+0xa28c): relocation truncated to fit: 
GPRELHIGH against `.rodata'
./lib/deflate_compress.c:2185:(.text+0xbfa0): relocation truncated to fit: 
GPRELHIGH against `.rodata'
collect2: error: ld returned 1 exit status

This problem can be worked around by building the source -O1 which is what the 
attached patch does.

Could you apply it for the next upload?

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=libdeflate&arch=alpha&ver=1.14-1&stamp=1673418504&raw=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig   2022-10-03 13:55:19.0 +0200
+++ debian/rules2023-01-13 16:48:12.970221727 +0100
@@ -4,6 +4,10 @@
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+ifeq (alpha,$(DEB_HOST_ARCH))
+   export DEB_CFLAGS_MAINT_APPEND=-O1
+endif
+
 %:
dh $@
 

Bug#1027529: gnote: FTBFS: ../src/test/unit/datetimeutests.cpp:97:1: error: Failure in pretty_print_date: Expected Yesterday but was Dec 31 2022

[Jeremy Bicha]

On Fri, Jan 13, 2023 at 9:58 AM Santiago Vila  wrote:
> El 13/1/23 a las 15:36, Jeremy Bicha escribió:
> > Control: severity -1 minor
> > Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnote/-/issues/145
> >
> > I'm downgrading the severity since the package builds fine today;
> > might build fine every day except January 1.
>
> Why don't you disable the test instead? It's clearly wrong.
>
> If we start allowing packages to FTBFS one day a year,
> building the 34231 source packages in bookworm
> might result in 93 completely gratuitous failures.
>
> I don't think that's the standard of quality we want for bookworm.

The test failure might be showing an actual behavior bug. I reported
the issue upstream so they can figure out whether the app needs to be
fixed or the test needs to be fixed.

The test failure on January 1 is a minor issue since that day is a
global holiday. It's rare to build or rebuild this package on that
day: this FTBFS bug may have existed for more than 8 years.

Thank you,
Jeremy Bicha

Bug#1028623: apt: "apt info" should report Multi-Arch fields

[Dima Kogan]

Package: apt
Version: 2.5.2
Severity: normal
X-Debbugs-Cc: Dima Kogan 

Hi. Currently "apt info" doesn't show all the fields describing a
package. In particular, the Multi-Arch fields are omitted, which makes
it challenging to debug issues involving those tags. Can we please add
this logic? I don't even see any other tools to do this, and I'm having
to 'apt source' the package and then look at the debian/control

Thanks!

Bug#965006:

[Jorge Moraleda]

I think getting tomcat 10 into unstable so it is in a path to eventually
making into testing and then stable has become a higher priority now that
tomcat 10 is required when using webapps developed using the latest Spring
framework version (
https://github.com/spring-projects/spring-framework/wiki/Upgrading-to-Spring-Framework-6.x
)

Thus IMHO we should resolve this issue by adding the Breaks+Replaces to
libtomcat10-java and give up co-instalability. Of course we should
immediately open a feature request to get co-instalability back, but that
would not stop the package from going into unstable and, after bookworm is
released, testing.

Bug#1028622: sphinx-prompt: autopkgtest is failng after updating pygments to 2.14.0+dfsg-1

[Carsten Schoenert]

Source: sphinx-prompt
Version: 1.5.0-2
Severity: serious

Dear Maintainer,

after the upload of pygments 2.14.0+dfsg-1 your package is failung while
running the autopkgtest.

Some of the failing parts are:

autopkgtest [03:25:03]: test unittests: [---
= test session starts ==
platform linux -- Python 3.11.1, pytest-7.2.0, pluggy-1.0.0+repack
rootdir: /tmp/autopkgtest-lxc.k5oqcgm7/downtmp/build.h5g/src
collected 12 items

../build.h5g/src/tests/test_sphinx_prompt.py .FF...F.[100%]

=== FAILURES ===
_ test[arguments1-options1-content1-\nspan.prompt1:before {\n  content: "$ ";\n}\none line\n] _

arguments = ['bash'], options = {'language': 'bash'}, content = ['one line']
expected = '\nspan.prompt1:before {\n  
content: "$ ";\n}\none 
line\n'

@pytest.mark.parametrize("arguments, options, content, expected", testdata)
def test(arguments, options, content, expected):
sphinx_prompt._cache.next_index = 1
sphinx_prompt._cache.prompts.clear()
stream = StringIO()
reporter = docutils.utils.Reporter("test data", 2, 4, stream, 1)
statemachine = docutils.statemachine.StateMachine([], None)
setattr(statemachine, "reporter", reporter)
directive = sphinx_prompt.PromptDirective(
"prompt", arguments, options, content, 0, 0, "", None, statemachine
)
result = directive.run()
>   assert result[0].astext() == expected
E   assert ''
E Skipping 159 identical leading characters in diff, use -v to show
E - ompt1">one line
E + ompt1">one line
E   

../build.h5g/src/tests/test_sphinx_prompt.py:165: AssertionError
_ test[arguments2-options2-content2-\nspan.prompt1:before {\n  content: "$ ";\n}\none line\n] _

arguments = [], options = {'language': 'bash'}, content = ['one line']
expected = '\nspan.prompt1:before {\n  
content: "$ ";\n}\none 
line\n'

@pytest.mark.parametrize("arguments, options, content, expected", testdata)
def test(arguments, options, content, expected):
sphinx_prompt._cache.next_index = 1
sphinx_prompt._cache.prompts.clear()
stream = StringIO()
reporter = docutils.utils.Reporter("test data", 2, 4, stream, 1)
statemachine = docutils.statemachine.StateMachine([], None)
setattr(statemachine, "reporter", reporter)
directive = sphinx_prompt.PromptDirective(
"prompt", arguments, options, content, 0, 0, "", None, statemachine
)
result = directive.run()
>   assert result[0].astext() == expected
E   assert ''
E Skipping 159 identical leading characters in diff, use -v to show
E - ompt1">one line
E + ompt1">one line
E   
...

It might be enough to pick

https://github.com/sbrunner/sphinx-prompt/commit/f996f7ab96ec63b08e27f96559b759143ccff214

from the upstream git tree to fix the issues.

Regards
Carsten

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

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

Bug#1013935: [Pkg-freeipa-devel] Bug#1013935: dogtag-pki: flaky autopkgtest: regularly times out on amd64, armhf and s390x

[Timo Aaltonen]

Timo Aaltonen kirjoitti 12.1.2023 klo 20.57:

Paul Gevers kirjoitti 27.6.2022 klo 21.31:

Source: dogtag-pki
Version: 11.0.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package because it 
was showing up on our "slow" page [1]. I noticed that there were 
several runs that took 2:47 (our timeout time), while successful runs 
more in the order of minutes.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

On top of that, when a test just hangs that's not good for our 
infrastructure. I'll put dogtag-pki on our reject_list for amd64, 
armhf, and s390x.


Don't hesitate to reach out if you need help and some more information
from our infrastructure. E.g. I note that the runs on amd64 that I 
happen to check are run on ci-worker13 that, together with our armhf 
worker is running on a host with lots of CPUs (64 and 160) and RAM 
(256GB and 511GB) and also our s390x has 10 CPUs and 32 GB.


Paul

[1] https://ci.debian.net/status/slow/


Hi,

I've finally updated dogtag-pki to fix some grave bugs, but this still 
remains. I don't know if the update fixes these racy tests (which they 
are, something goes wrong and it gets stuck), but is there a way for me 
to manually trigger them on ci.debian.net? They do pass on salsa-ci, but 
it's not the same thing..


Looks like the tests are still being run, which at least shows that they 
seem to be just as racy still :/ I need to reproduce the failure 
locally, which has been impossible so far.


--
t

Bug#1028621: sphinx: autopkgtest is failng after updating pygments to 2.14.0+dfsg-1

[Carsten Schoenert]

Source: sphinx
Severity: serious

Dear Maintainer,

after the upload of pygments 2.14.0+dfsg-1 your package is failung while
running the autopkgtest.

As the output of the failing parts are noisy it's not useful to paste
them here.
The full log of the autopkgtest on amd64 run can be found here:

https://ci.debian.net/data/autopkgtest/testing/amd64/s/sphinx/30313691/log.gz

Regards
Carsten

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

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

Bug#1028620: ruby-pygments: autopkgtest is failng after updating pygments to 2.14.0+dfsg-1

[Carsten Schoenert]

Source: ruby-pygments
Version: 2.3.0+ds-2.1
Severity: serious

Dear Maintainer,

after the upload of pygments 2.14.0+dfsg-1 your package is failung while
running the autopkgtest.

The failed part in detail is:

RUBYLIB=. GEM_PATH= ruby3.1 -S rake -f debian/ruby-tests.rake
mv lib ./.gem2deb.lib
/usr/bin/ruby3.1 -w -I"test" 
/usr/lib/ruby/gems/3.1.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb 
"test/test_pygments.rb"  -v
Loaded suite /usr/lib/ruby/gems/3.1.0/gems/rake-13.0.6/lib/rake/rake_test_loader
Started
PygmentsConfigTest:
  test_filters: .: (0.064462)
  test_formatters:  .: (0.006962)
  test_lexers:  .: (0.021366)
  test_styles:  .: (0.000854)
PygmentsCssTest:
  test_css: .: (0.001624)
  test_css_colorful:.: (0.001286)
  test_css_default: .: (0.000903)
  test_css_options: .: (0.000823)
  test_css_prefix:  .: (0.000833)
  test_css_prefix_and_options:  .: (0.000772)
PygmentsHighlightTest:
  test_full_html_highlight: F
===
Failure: test_full_html_highlight(PygmentsHighlightTest)
/tmp/autopkgtest-lxc.wcymigwk/downtmp/build.qG9/src/test/test_pygments.rb:31:in 
`test_full_html_highlight'
 28:   def test_full_html_highlight
 29: code = P.highlight(RUBY_CODE)
 30: assert_match '#!/usr/bin/ruby', code
  => 31: assert_equal %(#!/usr/bin/ruby
 32: puts 'foo'
 33: ), code
 34:   end
<"#!/usr/bin/ruby\n" +
"puts 'foo'\n" +
""> expected but was
<"#!/usr/bin/ruby\n" +
"puts 'foo'\n" +
"">

diff:
  #!/usr/bin/ruby
? puts  'foo'
  
===
: (0.154840)
  test_highlight_defaults_to_html:  .: (0.002140)
  test_highlight_formatter_bbcode:  .: (0.001620)
  test_highlight_formatter_terminal:.: (0.001277)
  test_highlight_on_multi_threads:  O
===
Omission: We do not actually support multithreading 
[test_highlight_on_multi_threads(PygmentsHighlightTest)]
/tmp/autopkgtest-lxc.wcymigwk/downtmp/build.qG9/src/test/test_pygments.rb:114:in
 `test_highlight_on_multi_threads'
===
: (0.000826)
  test_highlight_options:   .: (0.001922)
  test_highlight_still_works_with_invalid_code: .: (0.046896)
  test_highlight_works_on_utf8: .: (0.000949)
  test_highlight_works_on_utf8_all_chars_automatically: .: (0.000811)
  test_highlight_works_on_utf8_automatically:   .: (0.000834)
  test_highlight_works_with_larger_files:   .: (0.033287)
  test_highlight_works_with_multiple_newlines:  .: (0.001873)
  test_highlight_works_with_multiple_utf8:  .: (0.000864)
  test_highlight_works_with_multiple_utf8_and_trailing_newline: .: (0.000906)
  test_highlight_works_with_null_bytes: .: (0.000902)
  test_highlight_works_with_trailing_cr:.: (0.001775)
  test_highlight_works_with_trailing_newline:   .: (0.001717)
  test_version: .: (0.000343)
PygmentsLexerClassTest:
  test_find:.: (0.000268)
  test_find_by_alias:   .: (0.000152)
  test_find_by_name:.: (0.000124)
  test_find_lexer_by_extname:   .: (0.000178)
  test_find_lexer_by_mimetype:  .: (0.000122)
PygmentsLexerTest:
  test_lexer_by_content:.: (0.001258)
  test_lexer_by_filename:   .: (0.420205)
  test_lexer_by_filename_and_content:   .: (0.084091)
  test_lexer_by_mimetype:   .: (0.000676)
  test_lexer_by_name:   .: (0.014858)
  test_lexer_by_nothing:.: (0.002577)

Finished in 0.881532932 seconds.
---
39 tests, 60 assertions, 1 failures, 0 errors, 0 pendings, 1 omissions, 0 
notifications
97.3684% passed
---
44.24 tests/s, 68.06 assertions/s

Updating to 2.3.1 and adding this commit might solve this issue.

https://github.com/pygments/pygments.rb/commit/fe03c274a4b01fc9657a90dba5f16b3e9401082a

Regards
Carsten


-- System Information:
Debian Release: bookworm/

Bug#1028619: rich: autopkgtest is failng after updating pygments to 2.14.0+dfsg-1

[Sandro Tosi]

On Fri, Jan 13, 2023 at 1:24 PM Carsten Schoenert
 wrote:
>
> Source: rich
> Version: 13.0.0-1
> Severity: serious
>
> Dear Maintainer,
>
> after the upload of pygments 2.14.0+dfsg-1 your package is failung while
> running the autopkgtest.

yeah i'm wondering why you keep updating packages you dont maintain to
new upstream releases and breaking revdeps as consequence



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1028619: rich: autopkgtest is failng after updating pygments to 2.14.0+dfsg-1

[Carsten Schoenert]

Source: rich
Version: 13.0.0-1
Severity: serious

Dear Maintainer,

after the upload of pygments 2.14.0+dfsg-1 your package is failung while
running the autopkgtest.

The failed part in detail is:

=== FAILURES ===
___ test_python_render_simple_indent_guides 

def test_python_render_simple_indent_guides():
syntax = Syntax(
CODE,
lexer="python",
line_numbers=False,
theme="ansi_light",
code_width=60,
word_wrap=False,
indent_guides=True,
)
rendered_syntax = render(syntax)
print(repr(rendered_syntax))
expected = '\x1b[34mdef\x1b[0m \x1b[32mloop_first_last\x1b[0m(values: 
Iterable[T]) -> Iterable[Tuple[\x1b[36mb\x1b[0m\n\x1b[2m│   
\x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first 
an\x1b[0m\n\x1b[2m│   \x1b[0miter_values = 
\x1b[36miter\x1b[0m(values)\n\x1b[2m│   \x1b[0m\x1b[34mtry\x1b[0m:\n\x1b[2m│   
│   \x1b[0mprevious_value = \x1b[36mnext\x1b[0m(iter_values)\n\x1b[2m│   
\x1b[0m\x1b[34mexcept\x1b[0m \x1b[36mStopIteration\x1b[0m:\n\x1b[2m│   │   
\x1b[0m\x1b[34mreturn\x1b[0m\n\x1b[2m│   \x1b[0mfirst = 
\x1b[34mTrue\x1b[0m\n\x1b[2m│   \x1b[0m\x1b[34mfor\x1b[0m value 
\x1b[35min\x1b[0m iter_values:\n\x1b[2m│   │   \x1b[0m\x1b[34myield\x1b[0m 
first, \x1b[34mFalse\x1b[0m, previous_value\n\x1b[2m│   │   \x1b[0mfirst = 
\x1b[34mFalse\x1b[0m\n\x1b[2m│   │   \x1b[0mprevious_value = value\n\x1b[2m│   
\x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mTrue\x1b[0m, previous_value\n'
>   assert rendered_syntax == expected
E   assert '\x1b[34mdef\...vious_value\n' == '\x1b[34mdef\...vious_value\n'
E Skipping 81 identical leading characters in diff, use -v to show
E   mb␛[0m
E - ␛[2m│   ␛[0m␛[33m"""Iterate and generate a tuple with a flag for 
first an␛[0m
E + ␛[2;37m│   ␛[0m␛[33m"""Iterate and generate a tuple with a flag for 
first an␛[0m
E ?+++
E   ␛[2m│   ␛[0miter_values = ␛[36miter␛[0m(values)
E   ␛[2m│   ␛[0m␛[34mtry␛[0m:...
E 
E ...Full output truncated (10 lines hidden), use '-vv' to show

tests/test_syntax.py:114: AssertionError
- Captured stdout call -
'\x1b[34mdef\x1b[0m \x1b[32mloop_first_last\x1b[0m(values: Iterable[T]) -> 
Iterable[Tuple[\x1b[36mb\x1b[0m\n\x1b[2;37m│   \x1b[0m\x1b[33m"""Iterate and 
generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│   \x1b[0miter_values 
= \x1b[36miter\x1b[0m(values)\n\x1b[2m│   \x1b[0m\x1b[34mtry\x1b[0m:\n\x1b[2m│  
 │   \x1b[0mprevious_value = \x1b[36mnext\x1b[0m(iter_values)\n\x1b[2m│   
\x1b[0m\x1b[34mexcept\x1b[0m \x1b[36mStopIteration\x1b[0m:\n\x1b[2m│   │   
\x1b[0m\x1b[34mreturn\x1b[0m\n\x1b[2m│   \x1b[0mfirst = 
\x1b[34mTrue\x1b[0m\n\x1b[2m│   \x1b[0m\x1b[34mfor\x1b[0m value 
\x1b[35min\x1b[0m iter_values:\n\x1b[2m│   │   \x1b[0m\x1b[34myield\x1b[0m 
first, \x1b[34mFalse\x1b[0m, previous_value\n\x1b[2m│   │   \x1b[0mfirst = 
\x1b[34mFalse\x1b[0m\n\x1b[2m│   │   \x1b[0mprevious_value = value\n\x1b[2m│   
\x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mTrue\x1b[0m, previous_value\n'
_ test_python_render_line_range_indent_guides __

def test_python_render_line_range_indent_guides():
syntax = Syntax(
CODE,
lexer="python",
line_numbers=False,
theme="ansi_light",
code_width=60,
word_wrap=False,
line_range=(2, 3),
indent_guides=True,
)
rendered_syntax = render(syntax)
print(repr(rendered_syntax))
expected = '\x1b[2m│   \x1b[0m\x1b[33m"""Iterate and generate a tuple 
with a flag for first an\x1b[0m\n\x1b[2m│   \x1b[0miter_values = 
\x1b[36miter\x1b[0m(values)\n'
>   assert rendered_syntax == expected
E   assert '\x1b[2;37m│ ...[0m(values)\n' == '\x1b[2m│   \...[0m(values)\n'
E - ␛[2m│   ␛[0m␛[33m"""Iterate and generate a tuple with a flag for 
first an␛[0m
E + ␛[2;37m│   ␛[0m␛[33m"""Iterate and generate a tuple with a flag for 
first an␛[0m
E ?+++
E   ␛[2m│   ␛[0miter_values = ␛[36miter␛[0m(values)

tests/test_syntax.py:131: AssertionError
- Captured stdout call -
'\x1b[2;37m│   \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for 
first an\x1b[0m\n\x1b[2m│   \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n'
=== short test summary info 
FAILED tests/test_syntax.py::test_python_render_simple_indent_guides - assert...
FAILED tests/test_syntax.py::test_python_render_line_range_indent_guides - as...
== 2 failed, 765 passed, 23 skipped in 5.86s ===
E: pybuild pybuild:388: test: plugin pyproject failed with: exit code=1: cd 
/tmp/autopkgtest

Bug#1028618: retext: autopkgtest on s390x is failng after updating pygments to 2.14.0+dfsg-1

[Carsten Schoenert]

Source: retext
Version: 8.0.0-1
Severity: serious

Dear Maintainer,

after the upload of pygments 2.14.0+dfsg-1 your package is failung while
running the autopkgtest on s390x with python 3.10.

The failed part in detail is:

==
FAIL: test_autoSave (test_window.TestWindow)
--
Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/mock.py", line 1379, in patched
return func(*newargs, **newkeywargs)
  File 
"/tmp/autopkgtest-lxc.ay0gd1cu/downtmp/autopkgtest_tmp/tests/test_window.py", 
line 382, in test_autoSave
self.assertEqual(tempFile.read(), 'second content')
AssertionError: 'first content' != 'second content'
- first content
+ second content


--

Regards
Carsten

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

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

Bug#1028617: ipython: autopkgtest is faling after updating pygments to 2.14.0+dfsg-1

[Carsten Schoenert]

Source: ipython
Version: 8.5.0-3
Severity: serious

Dear Maintainer,

after the upload of pygments 2.14.0+dfsg-1 your package is failung while
running the autopkgtest.

The failed part in detail is:

=== FAILURES ===
_ TestLexers.testIPythonLexer __

self = 

def testIPythonLexer(self):
fragment = '!echo $HOME\n'
tokens = [
(Token.Operator, '!'),
]
tokens.extend(self.bash_lexer.get_tokens(fragment[1:]))
>   self.assertEqual(tokens, list(self.lexer.get_tokens(fragment)))
E   AssertionError: Lists differ: [(Tok[78 chars] (Token.Name.Variable, 
'$HOME'), (Token.Text.Whitespace, '\n')] != [(Tok[78 chars] 
(Token.Name.Variable, '$HOME'), (Token.Text, '\n')]
E
E   First differing element 4:
E   (Token.Text.Whitespace, '\n')
E   (Token.Text, '\n')
E
E [(Token.Operator, '!'),
E  (Token.Name.Builtin, 'echo'),
E  (Token.Text.Whitespace, ' '),
E  (Token.Name.Variable, '$HOME'),
E   -  (Token.Text.Whitespace, '\n')]
E   ? ---
E
E   +  (Token.Text, '\n')]

IPython/lib/tests/test_lexers.py:25: AssertionError

Updating the package to version 8.8.0 should fix the issue, it's
containing the commit

https://github.com/ipython/ipython/commit/ed7f35f8b721d4b4dcafea173ce724bee25704c7

which addresses the changes done by recent pygments.

Regards
Carsten

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

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

Bug#1028616: hovercraft: autopkgtest is faling after updating pygments to 2.14.0+dfsg-1

[Carsten Schoenert]

Source: hovercraft
Version: 2.7-4
Severity: serious

Dear Maintainer,

after the upload of pygments 2.14.0+dfsg-1 your package is failung while
running the autopkgtest.

The failed part in detail is:

autopkgtest [03:24:50]: test hovercraft: [---
[*] testing python3.11:
= test session starts ==
platform linux -- Python 3.11.1, pytest-7.2.0, pluggy-1.0.0+repack -- 
/usr/bin/python3.11
cachedir: .pytest_cache
rootdir: /tmp/autopkgtest-lxc.74de8cqg/downtmp/build.58j/src
collecting ... collected 35 items

tests/test_generator.py::GeneratorTests::test_big FAILED [  2%]

=== FAILURES ===
___ GeneratorTests.test_big 

self = 

def test_big(self):
template = Template(os.path.join(TEST_DATA, "maximal"))
html, deps = rst2html(os.path.join(TEST_DATA, "advanced.rst"), template)
>   self.assertEqual(html, HTML_OUTPUTS["advanced"])
E   AssertionError: b'\n
' != b'\n# 
Comment\n[1236 chars]tml>'

tests/test_generator.py:24: AssertionError
=== short test summary info 
FAILED tests/test_generator.py::GeneratorTests::test_big - AssertionError: b'...
!! stopping after 1 failures !!!
== 1 failed in 0.25s ===


Regards
Carsten

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

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

Bug#1028559: pypdf2: replace with pypdf

[GCS]

Hi Daniel,

On Fri, Jan 13, 2023 at 1:36 AM Daniel Kahn Gillmor
 wrote:
> looks like PyPDF2 2.12.1 is the last version before a major
> (backward-incompatible) change in 3.0.0.  and PyPDF2 3.0.0 itself
> indicates that it is deprecated in favor of pypdf 3.x
 Indeed, that's the last backward compatible release.

> I've prepared some packaging for PyPDF2 2.12.1-0.1 and put it in salsa
> at https://salsa.debian.org/debian/pypdf
 Cool! But I still haven't checked. Hopefully I will check tomorrow morning.

> If that's someplace that you'd be up for collaborating, i'd be happy to
> help out on it with you there.
 I'm not sure if we know each other, but I have the knowledge that you
are a nice guy. Sure, I'm open to collaboration and Salsa is a good
place to start.

> We can probably also use the same repository (just different branches)
> for packaging pypdf, since i would expect that packaging to just inherit
> directly from the pypdf2 packaging, and it can be nice to have the
> history in the same location.
 I'm not sure what would be the best practices for this case, but
definitely a continued packaging is preferred from my side.

> Let me know if that's something you'd be up for collaboratong on,
> László!
 I'm even open to you taking over the package and making me an uploader.

> If you don't like it, i'm also happy to remove the repo from salsa.  I
> defer to you as the maintainer here.
 To be honest, I was going to look for an adopter for this package
this summer, probably after migrating it to src:pypdf. If you are
interested, even contributed already to the project then you are the
best candidate. As noted, you can take over immediately while leaving
me as an uploader for a while.

Best,
Laszlo/GCS

Bug#1028565: upgrade-reports: Audio breaks between 5.10.0-19-amd64 and 5.10.0-20-amd64

[KM]

Thank you very much, I'm switching the laptop that had that problem (Huawei
matebook ryzen 2500u) to a (Lenovo yoga 6 ryzen 5500u), I'm not sure I will
have the same problem again.

On Fri, Jan 13, 2023, 18:45 Markus Kramer 
wrote:

> Thank you, Salvator,
> I will look into the two issues and will come back.
> Best regards Markus
>
> On Fri, Jan 13, 2023 at 6:21 AM Salvatore Bonaccorso 
> wrote:
>
>> Hi Markus,
>>
>> On Thu, Jan 12, 2023 at 10:11:12PM +0100, Markus wrote:
>> > Package: upgrade-reports
>> > Severity: important
>> > X-Debbugs-Cc: markuskramerig...@gmail.com
>> >
>> > (Please provide enough information to help the Debian
>> > maintainers evaluate the report efficiently - e.g., by filling
>> > in the sections below.)
>> >
>> > My previous release is: Debian 11 Gnome 5.10.0-19-amd64
>> > I am upgrading to: Debian 11 Gnome 5.10.0-20-amd64
>> > Archive date: unclear
>> > Upgrade date: Going back and forth between 5.10.0-19-amd64 and
>> 5.10.0-20-amd64 at GRUB
>> > uname -a before upgrade: Linux debNXP 5.10.0-19-amd64 #1 SMP Debian
>> 5.10.149-2 (2022-10-21) x86_64 GNU/Linux
>> > uname -a after upgrade: Linux debNXP 5.10.0-20-amd64 #1 SMP Debian
>> 5.10.158-2 (2022-12-13) x86_64 GNU/Linux
>> > Method: sudo apt
>> >
>> > Contents of /etc/apt/sources.list:
>> > # See https://wiki.debian.org/SourcesList for more information.
>> > deb http://deb.debian.org/debian bullseye main
>> > deb-src http://deb.debian.org/debian bullseye main
>> >
>> > deb http://deb.debian.org/debian bullseye-updates main
>> > deb-src http://deb.debian.org/debian bullseye-updates main
>> >
>> > deb http://security.debian.org/debian-security/ bullseye-security main
>> > deb-src http://security.debian.org/debian-security/ bullseye-security
>> main
>> >
>> >
>> > - Were there any non-Debian packages installed before the upgrade?  No
>> >
>> > - Was the system pre-update a pure sarge system? No
>> >
>> > - which packages were not from sarge? I dont understand
>> >
>> > - Did any packages fail to upgrade? No
>> >
>> > - Were there any problems with the system after upgrading?
>> > Yes: Audio stopped working.
>> >
>> > Further Comments/Problems:
>> > For testing audio I use 2 methods:
>> > Method 1) In terminal pressing "backspace" at the beginning of the
>> line, which should produce a "Drip" sound.
>> > Method 2) In terminal executing aplay /usr/share/sounds/alsa/Noise.wav
>> >
>> > On an HP EliteBook 840 G8 Notebook
>> > - With kernel 5.10.0-20-amd64:
>> > - Test case 1: audio stops working within 10 seconds
>> > - Test case 2: audio stops working after one execution
>> > - With kernel 5.10.0-19-amd64 audio works fine
>> > Reports for Thinkpad T14 with Intel Comet Lake, or Dell Inspiron 15 are
>> here https://forums.debian.net/viewtopic.php?p=765136#p765136
>>
>> This is possibly the same as #1027430 and #1027483. Fixes for that
>> would be pending.
>>
>> Regards,
>> Salvatore
>>
>

Bug#1028615: tracker.debian.org: tracker.d.o should display results of reproducible rebuilds, not just reproducible CI results

[Holger Levsen]

Package: tracker.debian.org
Severity: normal
X-Debbugs-Cc: frederic.pier...@qubes-os.org, 
reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

since some years, tracker.d.o is thankfully showing results from
https://tests.reproducible-builds.org/debian - which was and is awesome!
However, these are just continious integration test results and
not based on the binaries we publish on ftp.debian.org

But there is a new service, which rebuilds packages and compares the results
against the binaries we publish at ftp.d.o, which is 
https://rebuild.notset.fr/debian

The data is available in json format here:

- https://rebuild.notset.fr/debian/results/debian_unstable.json
- https://rebuild.notset.fr/debian/results/debian_bookworm.json
- https://rebuild.notset.fr/debian/results/debian_bullseye.json

It would be great, if tracker.d.o could display both kind of results, CI *and*
rebuild results.


Thank you for maintaining tracker.d.o!

-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

First they ignore you, then they laugh at you, and then it's too late.
Don't look up!


signature.asc
Description: PGP signature

Bug#1028565: upgrade-reports: Audio breaks between 5.10.0-19-amd64 and 5.10.0-20-amd64

[Markus Kramer]

Thank you, Salvator,
I will look into the two issues and will come back.
Best regards Markus

On Fri, Jan 13, 2023 at 6:21 AM Salvatore Bonaccorso 
wrote:

> Hi Markus,
>
> On Thu, Jan 12, 2023 at 10:11:12PM +0100, Markus wrote:
> > Package: upgrade-reports
> > Severity: important
> > X-Debbugs-Cc: markuskramerig...@gmail.com
> >
> > (Please provide enough information to help the Debian
> > maintainers evaluate the report efficiently - e.g., by filling
> > in the sections below.)
> >
> > My previous release is: Debian 11 Gnome 5.10.0-19-amd64
> > I am upgrading to: Debian 11 Gnome 5.10.0-20-amd64
> > Archive date: unclear
> > Upgrade date: Going back and forth between 5.10.0-19-amd64 and
> 5.10.0-20-amd64 at GRUB
> > uname -a before upgrade: Linux debNXP 5.10.0-19-amd64 #1 SMP Debian
> 5.10.149-2 (2022-10-21) x86_64 GNU/Linux
> > uname -a after upgrade: Linux debNXP 5.10.0-20-amd64 #1 SMP Debian
> 5.10.158-2 (2022-12-13) x86_64 GNU/Linux
> > Method: sudo apt
> >
> > Contents of /etc/apt/sources.list:
> > # See https://wiki.debian.org/SourcesList for more information.
> > deb http://deb.debian.org/debian bullseye main
> > deb-src http://deb.debian.org/debian bullseye main
> >
> > deb http://deb.debian.org/debian bullseye-updates main
> > deb-src http://deb.debian.org/debian bullseye-updates main
> >
> > deb http://security.debian.org/debian-security/ bullseye-security main
> > deb-src http://security.debian.org/debian-security/ bullseye-security
> main
> >
> >
> > - Were there any non-Debian packages installed before the upgrade?  No
> >
> > - Was the system pre-update a pure sarge system? No
> >
> > - which packages were not from sarge? I dont understand
> >
> > - Did any packages fail to upgrade? No
> >
> > - Were there any problems with the system after upgrading?
> > Yes: Audio stopped working.
> >
> > Further Comments/Problems:
> > For testing audio I use 2 methods:
> > Method 1) In terminal pressing "backspace" at the beginning of the line,
> which should produce a "Drip" sound.
> > Method 2) In terminal executing aplay /usr/share/sounds/alsa/Noise.wav
> >
> > On an HP EliteBook 840 G8 Notebook
> > - With kernel 5.10.0-20-amd64:
> > - Test case 1: audio stops working within 10 seconds
> > - Test case 2: audio stops working after one execution
> > - With kernel 5.10.0-19-amd64 audio works fine
> > Reports for Thinkpad T14 with Intel Comet Lake, or Dell Inspiron 15 are
> here https://forums.debian.net/viewtopic.php?p=765136#p765136
>
> This is possibly the same as #1027430 and #1027483. Fixes for that
> would be pending.
>
> Regards,
> Salvatore
>

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Soren Stoutner]

I would recommend you install the debian-policy package and review the 
documentation on the format of the copyright file at /usr/share/doc/debian-
policy/copyright-format-1.0.html.  With that as a reference, I do not find it 
difficult to manually edit copyright files.

On Thursday, January 12, 2023 7:40:02 PM MST Nick Hastings wrote:
> * Bastian Germann  [230104 02:20]:
> > Control: tags -1 moreinfo
> > 
> > Am 15.12.22 um 06:40 schrieb Nick Hastings:
> > > > d/copyright
> > > > ===
> > > > Please use more wildcards so you do not have to list so many files.
> > > 
> > > This is where it gets tricky for me. As I understand it the last match
> > > in d/copyright file is the one that applies. So for example, the block
> > > starting at line 253 specifies a LGPL-2.1+ license for a bunch of files
> > > under lib/libc/include/. Lines 253-270 explicitly list header files
> > > under lib/libc/include/aarch64-linux-gnu/bits/. So first thought is to
> > > just list them all as a glob lib/libc/include/aarch64-linux-gnu/bits/*
> > > However on closer inspection I see that there is a file in that
> > > directory that is not listed. Specifically
> > > lib/libc/include/aarch64-linux-gnu/bits/fcntl/endianness.h
> > > Inspecting this file and the others in the directory I see that
> > > explicitly listed files contain the LGPL-2.1+ text, but that
> > > endianness.h contains no license text. Thus endianness.h is actually
> > > Expat license and is covered in the block starting on line 10 "Files:
> > > lib/*".
> > > 
> > > So if I change the explicit list of files under
> > > lib/libc/include/aarch64-linux-gnu/bits/ to a glob, I'll need to and
> > > anther block later to explicitly list endianness.h as Expat.
> > 
> > Yes, you would use a glob for the LGPL files and add another block
> > specifically for the Expat-licensed file after the LGPL block.
> 
> Understood. However I do not feel confident that I can correctly make
> these changes by hand. The above is just one example where I found that
> using a glob would require an additional section/exception. There are
> likely many more.
> 
> This debian/copyright file was originally produced by decopy and I
> adjusted it wherever I found problems. I hesitate to change things that
> I do not know to be wrong, at the risk of introducing errors simply to
> reduce the number of lines in the file.


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

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

Bug#749193: apt-listbugs: Reemergence of ruby encoding troubles

[Jochen Sprickerhof]

Package: ruby-soap4r
Version: 2.0.5-5
Followup-For: Bug #749193

Hi,

seems like I was just bitten by this when installing apt-cacher-ng:

# aptitude -u
Performing actions...
Laden der Fehlerberichte … Erledigt
»Found/Fixed«-Informationen werden ausgewertet … Erledigt
serious Fehler von apt-cacher-ng (→ 3.7.4-1+b2) 
/usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:828:in `+': incompatible 
character encodings: ASCII-8BIT and UTF-8 (Encoding::CompatibilityError)
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:828:in `block (4 
levels) in display_bugs'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/bug.rb:69:in `block 
in each_by_category'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/bug.rb:68:in `each'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/bug.rb:68:in 
`each_by_category'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:807:in `block (3 
levels) in display_bugs'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:803:in `each'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:803:in `block (2 
levels) in display_bugs'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:802:in `each'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:802:in `block in 
display_bugs'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:801:in `each'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:801:in 
`display_bugs'
from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:451:in `view'
from /usr/bin/apt-listbugs:626:in `'
E: Unterprozess /usr/bin/apt-listbugs apt hat Fehlercode zurückgegeben (1)
E: Failure running script /usr/bin/apt-listbugs apt
Press Return to continue, 'q' followed by Return to quit.
q
root@fenchel:~# LANG=C.UTF-8 aptitude -u
Performing actions...
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
serious bugs of apt-cacher-ng (→ 3.7.4-1+b2) 
 b1 - #980923 - acngtools eats all the CPU and doesn’t finish daily cron with 
merged pdiffs (Fixed: apt-cacher-ng/3.6.2-1)
   Merged with: 977611
Summary:
 apt-cacher-ng(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...]



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

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

-- no debconf information

Bug#1028435: apr-util: please include changes from 1.6.1-5.1 NMU

[Holger Levsen]

control: retitle -1 apr-util: please include changes from 1.6.1-5.2 NMU
thanks

On Tue, Jan 10, 2023 at 10:53:26PM +, Holger Levsen wrote:
> please include the attached changes from my 1.6.1-5.1 NMU.

I had to fixup that NMU, so I'm attaching the new diff against 1.6.1-5.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Dat gifft in Plattdüütschen keen Woort för „Flüchtlinge”. Dat sünd allens Lüüd, 
Mischen, Kinners, Olle, Froons, Mannslüüd, so as Du un Ick.
diff -Nru apr-util-1.6.1/debian/changelog apr-util-1.6.1/debian/changelog
--- apr-util-1.6.1/debian/changelog 2020-08-29 11:51:07.0 +0200
+++ apr-util-1.6.1/debian/changelog 2023-01-12 20:28:37.0 +0100
@@ -1,3 +1,19 @@
+apr-util (1.6.1-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload by the Reproducible Builds team.
+  * debian/rules: Remove the build path from apt-1-config, using exactly the
+patch from Vagrant Cascadian in #1006865.
+
+ -- Holger Levsen   Thu, 12 Jan 2023 20:28:37 +0100
+
+apr-util (1.6.1-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload by the Reproducible Builds team.
+  * debian/rules: Remove the build path from apt-1-config, based on a patch by
+Vagrant Cascadian. Closes: #1006865.
+
+ -- Holger Levsen   Thu, 29 Dec 2022 19:37:54 +0100
+
 apr-util (1.6.1-5) unstable; urgency=medium
 
   [ Jelmer Vernooij ]
diff -Nru apr-util-1.6.1/debian/rules apr-util-1.6.1/debian/rules
--- apr-util-1.6.1/debian/rules 2020-08-29 11:24:55.0 +0200
+++ apr-util-1.6.1/debian/rules 2023-01-12 20:24:11.0 +0100
@@ -105,6 +105,8 @@
 override_dh_auto_install:
dh_auto_install --destdir=debian/tmp
perl -p -i -e "s,^dependency_libs=.*,dependency_libs=''," 
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libaprutil-1.la
+   # Remove the buildpath: https://reproducible-builds.org/docs/build-path/
+   perl -p -i -e "s,$(CURDIR),BUILDPATH," debian/tmp/usr/bin/apu-1-config
 
 override_dh_strip:
dh_strip --dbgsym-migration='libaprutil1-dbg (<= 1.6.1-3)'


signature.asc
Description: PGP signature

Bug#1028609: deepin-terminal: FTBFS -- Build dependency uninstallable

[Arun Kumar Pariyar]

Hi Nilesh,

On 13/01/2023 21:17, Nilesh Patra wrote:

Dear Maintainer,

deepin-terminal FTBFS because of not being able to install its
B-Ds. Some B-D (transitively?) depends on qtbase-abi-5-15-7 which
is not installable due to being a virtual package. But I leave that
onto you to check further.

| Install main build dependencies (apt-based resolver)
| 
|
| Installing build dependencies
| Reading package lists...
| Building dependency tree...
| Reading state information...
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
|
| The following packages have unmet dependencies:
| libdtkgui5 : Depends: qtbase-abi-5-15-7 but it is not installable
| libdtkwidget5 : Depends: qtbase-abi-5-15-7 but it is not installable
| libqt5designer5 : Depends: qtbase-abi-5-15-7 but it is not installable
| qttools5-dev-tools : Depends: qt5-assistant (= 5.15.7-2) but it is not going 
to be installed
|  Depends: libqt5quick5 (>= 5.15.7+dfsg~) but it is not 
going to be installed or
|   libqt5quick5-gles (>= 5.15.7+dfsg~) but it is 
not going to be installed
|  Depends: libqt5quickwidgets5 (>= 5.15.7+dfsg~) but it is 
not going to be installed
|  Depends: libqt5webkit5 (>= 5.212.0~alpha4-8~) but it is 
not going to be installed
|  Depends: qtbase-abi-5-15-7 but it is not installable
|  Depends: qtdeclarative-abi-5-15-7
| E: Unable to correct problems, you have held broken packages.


Thanks for your bug report, the reason for uninstallable B-D is because 
qtbase-abi-5-15-8 is under transition [1]. It should take around 1-2 
days for the transition to complete with a binNMU of deepin-terminal 
with the new dependency, which should fix the issue.


[1] https://release.debian.org/transitions/html/qtbase-abi-5-15-8.html

Regards,
~ Arun Kumar Pariyar


OpenPGP_0x4B542AF704F74516.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028614: php8.1-common is not installable on Debian Bookworm

[Matthew Brewer]

Package: php8.1-common
Version: 8.1.12-1+b1
Severity: important

php8.1-common depends on php-common, but is incompatable and both may not be 
installed at the same time. This renders php8.1-common uninstallable. I've 
marked this only "important" because if you already have it installed when you 
upgrade the package remains usable. As php8.1-common is a dependency, this 
renders all php8.1 packages uninstallable.

Here's what an attempt to install php8.1-common on Bookworm looks like

root@smalladventures:/home/mbrewer# apt install php8.1-common
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 php-common : Breaks: php8.1-common but 8.1.12-1+b1 is to be installed
 E: Unable to correct problems, you have held broken packages.


I ran into this after accidentally upgrading to php8.2 which is incompatible 
with current release of NextCloud. I then attempted to downgrade and ran into 
this issue.

I tried "apt purge php*" but that does not help. I also tried "aptitude install 
php8.1-common" but aptitude finds no solutions that involve installing 
php8.1-common.

Thanks!

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

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

Versions of packages php8.1-common depends on:
ii  libc6   2.36-8
ii  libffi8 3.4.4-1
ii  libssl3 3.0.7-1
ii  php-common  2:93
ii  ucf 3.0043

php8.1-common recommends no packages.

php8.1-common suggests no packages.

Bug#1024820: Test suite error with pandas 1.5 (Issue #810)

[Yoshiki Vázquez Baeza]

Yes, I’ll take a stab at this in the coming days. Thanks for reporting.

On Jan 12, 2023, at 11:16 PM, Andreas Tille ***@***.***> wrote:



Is there any chance to tackle this issue?

—
Reply to this email directly, view it on 
GitHub, 
or 
unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: 
***@***.***>



-- 
Reply to this email directly or view it on GitHub:
https://github.com/biocore/emperor/issues/810#issuecomment-1382031195
You are receiving this because you authored the thread.

Message ID: 

Bug#1028613: libpam-zfs: zfs_umount failed on closing ssh session

[Andreas Mahling]

Package: libpam-zfs
Version: 2.1.7-1~bpo11+1
Severity: normal
X-Debbugs-Cc: andreas.mahl...@googlemail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***
I have configured a user 'test1' with a zfs encrypted homedir 'tank/home/test1'

The only thing I'd changed on stock pam configuration was adding option 
homes=tank/home

When I start a session for test1 via terminal login, su - test1, ssh 
test1@localhost or graphical login, the homedir is sucessfully mounted and 
decrypted with the password of test1

When I terminate the terminal or su - session, test1 homedir is umnounted and 
encryption key is unloaded as expected.

But when I terminate the ssh session an error is thrown:
Jan 13 16:31:01 rpi-400 sshd[2207]: pam_zfs_key(sshd:session): zfs_unmount 
failed with: -1

test1 homedir is still mounted and readable. 
Same problem occurs when terminating a graphical desktop session.

Excpected behaviour: encrypted zfs homedir should be unmounted if there is no 
sesssion active for test1

-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.15.84-v8+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpam-zfs depends on:
ii  libc62.31-13+rpt2+rpi1+deb11u5
ii  libnvpair3linux  2.1.7-1~bpo11+1
ii  libpam-runtime   1.4.0-9+deb11u1+rpt2
ii  libpam0g 1.4.0-9+deb11u1+rpt2
ii  libssl1.11.1.1n-0+deb11u3+rpt1
ii  libzfs4linux 2.1.7-1~bpo11+1

libpam-zfs recommends no packages.

libpam-zfs suggests no packages.

-- no debconf information

Bug#1028612: unblock: pam/1.5.2-6

[Sam Hartman]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: p...@packages.debian.org
Control: affects -1 + src:pam

Please unblock package pam
If I am reading https://qa.debian.org/excuses.php?package=pam
right, it looks like pam is blocked by a supposed regression on squid on s390x.
I assume the mmdebstrap regression should not block because the version in 
unstable has the regression but the version in testing does not.

As far as I can tell both the squid regression and the mmdebstrap regression 
are flaky tests.
The squid regression particularly: on one arch, the ftp test fails.

I used the ci.debian.net self service to request a rerun of squid from testing 
with pam from unstable on s390x
and my run
https://ci.debian.net/data/autopkgtest/testing/s390x/s/squid/30263099/log.gz

appears to have succeed.
So I think the test is flaky.

Unless I've missed something else, I think that the test failures should be 
ignored and pam accepted into testing.

Bug#1028611: deepin-terminal: lack of icons, customizations

[Nilesh Patra]

Package: deepin-terminal
Version: 5.2.11-1+b4
Severity: important
X-Debbugs-Cc: a...@debian.org, by...@debian.org

Dear Maintainer,

In the current release of deepin-terminal, I am seeing missing
icons for some of the buttons. I also do not see an option to change
themes+color in the terminal.

This is on a fresh debian install. I also checked this on another system
to ensure this is not just $something-wrong-locally thing for me.

I do remember seeing this option in previous releases of
deepin-terminal, and this is sort of un-usable for me at the moment.
Please consider to check.

I'm also attaching a screenshot for your ref.

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_IN, LC_CTYPE=en_IN (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 deepin-terminal depends on:
ii  expect5.45.4-2+b1
ii  libatspi2.0-0 2.46.0-4
ii  libc6 2.36-7
ii  libdframeworkdbus25.5.22-1
ii  libdtkcore5   5.5.33-1+b2
ii  libdtkgui55.5.25-1+b2
ii  libdtkwidget5 5.5.48-1+b2
ii  libgcc-s1 12.2.0-13
ii  libglib2.0-0  2.74.4-1
ii  libqt5core5a [qtbase-abi-5-15-7]  5.15.7+dfsg-2
ii  libqt5dbus5   5.15.7+dfsg-2
ii  libqt5gui55.15.7+dfsg-2
ii  libqt5widgets55.15.7+dfsg-2
ii  libstdc++612.2.0-13
ii  zssh  1.5c.debian.1-8

deepin-terminal recommends no packages.

deepin-terminal suggests no packages.

-- no debconf information

Bug#1028610: tracker.debian.org: shows the short description of the binary package, which is meaningless for the source package

[Vincent Lefevre]

Package: tracker.debian.org
Severity: normal

https://tracker.debian.org/pkg/emacs (which is about the source package)
contains at the top

emacs
   GNU Emacs editor (metapackage)

This is the description of the "emacs" binary package, which
is indeed a metapackage. But this makes no sense for the
source package.

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

Bug#1028609: deepin-terminal: FTBFS -- Build dependency uninstallable

[Nilesh Patra]

Package: deepin-terminal
Version: 5.2.11-1+b4
Severity: serious
X-Debbugs-Cc: a...@debian.org, by...@debian.org

Dear Maintainer,

deepin-terminal FTBFS because of not being able to install its
B-Ds. Some B-D (transitively?) depends on qtbase-abi-5-15-7 which
is not installable due to being a virtual package. But I leave that
onto you to check further.

| Install main build dependencies (apt-based resolver)
| 
|
| Installing build dependencies
| Reading package lists...
| Building dependency tree...
| Reading state information...
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
|
| The following packages have unmet dependencies:
| libdtkgui5 : Depends: qtbase-abi-5-15-7 but it is not installable
| libdtkwidget5 : Depends: qtbase-abi-5-15-7 but it is not installable
| libqt5designer5 : Depends: qtbase-abi-5-15-7 but it is not installable
| qttools5-dev-tools : Depends: qt5-assistant (= 5.15.7-2) but it is not going 
to be installed
|  Depends: libqt5quick5 (>= 5.15.7+dfsg~) but it is not 
going to be installed or
|   libqt5quick5-gles (>= 5.15.7+dfsg~) but it is 
not going to be installed
|  Depends: libqt5quickwidgets5 (>= 5.15.7+dfsg~) but it is 
not going to be installed
|  Depends: libqt5webkit5 (>= 5.212.0~alpha4-8~) but it is 
not going to be installed
|  Depends: qtbase-abi-5-15-7 but it is not installable
|  Depends: qtdeclarative-abi-5-15-7
| E: Unable to correct problems, you have held broken packages.

Thanks.

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_IN, LC_CTYPE=en_IN (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 deepin-terminal depends on:
ii  expect5.45.4-2+b1
ii  libatspi2.0-0 2.46.0-4
ii  libc6 2.36-7
ii  libdframeworkdbus25.5.22-1
ii  libdtkcore5   5.5.33-1+b2
ii  libdtkgui55.5.25-1+b2
ii  libdtkwidget5 5.5.48-1+b2
ii  libgcc-s1 12.2.0-13
ii  libglib2.0-0  2.74.4-1
ii  libqt5core5a [qtbase-abi-5-15-7]  5.15.7+dfsg-2
ii  libqt5dbus5   5.15.7+dfsg-2
ii  libqt5gui55.15.7+dfsg-2
ii  libqt5widgets55.15.7+dfsg-2
ii  libstdc++612.2.0-13
ii  zssh  1.5c.debian.1-8

deepin-terminal recommends no packages.

deepin-terminal suggests no packages.

-- no debconf information

Bug#1028608: evdi-dkms: EVDI module does not build with linux-headers-6.0.0-6-amd64

[Miroslav Maiksnar]

Package: evdi-dkms
Version: 1.12.0+dfsg-0.1
Severity: important
X-Debbugs-Cc: bugs.debian@m.mixi.cz

Dear Maintainer,

Upon updating Debian testing I received build error from evdi-dkms:

Setting up linux-headers-6.0.0-6-amd64 (6.0.12-1) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 6.0.0-6-amd64:Sign command: 
/usr/lib/linux-kbuild-6.0/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j8 KERNELRELEASE=6.0.0-6-amd64 all 
INCLUDEDIR=/lib/modules/6.0.0-6-amd64/build/include KVERSION=6.0.0-6-amd64 
DKMS_BUILD=1...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.0.0-6-amd64 (x86_64)
Consult /var/lib/dkms/evdi/1.12.0/build/make.log for more information.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
 failed!
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 11
Failed to process /etc/kernel/header_postinst.d at 
/var/lib/dpkg/info/linux-headers-6.0.0-6-amd64.postinst line 11.
dpkg: error processing package linux-headers-6.0.0-6-amd64 (--configure):
 installed linux-headers-6.0.0-6-amd64 package post-installation script 
subprocess returned error exit status 1


Contents of /var/lib/dkms/evdi/1.12.0/build/make.log:
---
DKMS make.log for evdi-1.12.0 for kernel 6.0.0-6-amd64 (x86_64)
Fri Jan 13 16:01:26 CET 2023
make KBUILD_VERBOSE=1 M=/var/lib/dkms/evdi/1.12.0/build 
SUBDIRS=/var/lib/dkms/evdi/1.12.0/build SRCROOT=/var/lib/dkms/evdi/1.12.0/build 
CONFIG_MODULE_SIG= -C /lib/modules/6.0.0-6-amd64/build modules
make[1]: Entering directory '/usr/src/linux-headers-6.0.0-6-amd64'
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
\
echo >&2;   \
echo >&2 "  ERROR: Kernel configuration is invalid.";   \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are 
missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix 
it.";  \
echo >&2 ;  \
/bin/false)
make -f /usr/src/linux-headers-6.0.0-6-common/scripts/Makefile.build 
obj=/var/lib/dkms/evdi/1.12.0/build \
single-build= \
need-builtin=1 need-modorder=1
  printf '%s
'   evdi_platform_drv.o evdi_platform_dev.o evdi_sysfs.o evdi_modeset.o 
evdi_connector.o evdi_encoder.o evdi_drm_drv.o evdi_fb.o evdi_gem.o 
evdi_painter.o evdi_params.o evdi_cursor.o evdi_debug.o evdi_i2c.o evdi_ioc32.o 
| awk '!x[$0]++ { print("/var/lib/dkms/evdi/1.12.0/build/"$0) }' > 
/var/lib/dkms/evdi/1.12.0/build/evdi.mod
   gcc-12 -Wp,-MMD,/var/lib/dkms/evdi/1.12.0/build/.evdi_platform_drv.o.d 
-nostdinc -I/usr/src/linux-headers-6.0.0-6-common/arch/x86/include 
-I./arch/x86/include/generated -I/usr/src/linux-headers-6.0.0-6-common/include 
-I./include -I/usr/src/linux-headers-6.0.0-6-common/arch/x86/include/uapi 
-I./arch/x86/include/generated/uapi 
-I/usr/src/linux-headers-6.0.0-6-common/include/uapi -I./include/generated/uapi 
-include /usr/src/linux-headers-6.0.0-6-common/include/linux/compiler-version.h 
-include /usr/src/linux-headers-6.0.0-6-common/include/linux/kconfig.h -include 
/usr/src/linux-headers-6.0.0-6-common/include/linux/compiler_types.h 
-D__KERNEL__ -fmacro-prefix-map=/usr/src/linux-headers-6.0.0-6-common/= -Wall 
-Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing 
-fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration 
-Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 
-mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 
-falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 
-mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone 
-mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables 
-mindirect-branch=thunk-extern -mindirect-branch-register 
-mindirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables 
-mharden-sls=all -fno-delete-null-pointer-checks -Wno-frame-address 
-Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 
-fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong 
-Wno-array-bounds -Wimplicit-fallthrough=5 -Wno-main 
-Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-dangling-pointer 
-ftrivial-auto-var-init=zero -fno-stack-clash-protection -pg -mrecord-mcount 
-mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla 
-Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation 
-Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized 
-Wno-alloc-size-larger-than -fno-strict-overflow -fno-stack-check 
-fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types 
-Werror=designated-init -Wno-packed-not-aligned -g -Iinclude/drm  -DMODULE  
-DKBUILD_BASENAME='"evdi

Bug#1028607: FTBFS: FAILED test-correct-notice and test-end-chop in copyright-tests.log due to new year 2023

[Vincent Lefevre]

Control: tags -1 upstream fixed-upstream patch

On 2023-01-13 16:07:09 +0100, Vincent Lefevre wrote:
> The cause may be that we are now in 2023 and the above tests
> are expecting 2022. Instead of expecting 2022, shouldn't they
> expect the current year?

This is what upstream did in

commit da77d70deeb2798693ec4f28a291befeb8e43989
Author: Mattias Engdegård 
Date:   2023-01-01 13:18:50 +0100

; * test/lisp/emacs-lisp/copyright-tests.el: Fix and future-safe.

I'm attaching this commit.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
commit da77d70deeb2798693ec4f28a291befeb8e43989
Author: Mattias Engdegård 
Date:   2023-01-01 13:18:50 +0100

; * test/lisp/emacs-lisp/copyright-tests.el: Fix and future-safe.

diff --git a/test/lisp/emacs-lisp/copyright-tests.el b/test/lisp/emacs-lisp/copyright-tests.el
index ef531174617..5f8b5c67896 100644
--- a/test/lisp/emacs-lisp/copyright-tests.el
+++ b/test/lisp/emacs-lisp/copyright-tests.el
@@ -59,7 +59,8 @@ test-end-chop
 "\nCopyright 2006, 2007, 2008 Foo Bar\n\n")
 (copyright-update)
 (buffer-substring (- (point-max) 42) (point-max
-"Copyright 2006, 2007, 2008, 2022 Foo Bar\n\n")))
+(format "Copyright 2006, 2007, 2008, %s Foo Bar\n\n"
+(format-time-string "%Y")
 
 (ert-deftest test-correct-notice ()
   (should (equal
@@ -70,7 +71,8 @@ test-correct-notice
(copyright-query nil))
(copyright-update))
  (buffer-string))
-   "Copyright 2021 FSF\nCopyright 2021, 2022 FSF\n")))
+   (format "Copyright 2021 FSF\nCopyright 2021, %s FSF\n"
+   (format-time-string "%Y")
 
 (defmacro with-copyright-fix-years-test (orig result)
   `(let ((copyright-year-ranges t))

Bug#1028607: FTBFS: FAILED test-correct-notice and test-end-chop in copyright-tests.log due to new year 2023

[Vincent Lefevre]

Source: emacs
Version: 28.2+1-9
Severity: serious
Tags: ftbfs
Justification: ftbfs

When trying to rebuild emacs:

SUMMARY OF TEST RESULTS
---
Files examined: 375
Ran 5623 tests, 5545 results as expected, 2 unexpected, 76 skipped
1 files contained unexpected results:
  lisp/emacs-lisp/copyright-tests.log

and in this log file:

[...]
Test test-correct-notice condition:
(ert-test-failed
 ((should
   (equal
(with-temp-buffer ... ... ...)
"Copyright 2021 FSF\nCopyright 2021, 2022 FSF\n"))
  :form
  (equal "Copyright 2021 FSF\nCopyright 2021, 2023 FSF\n" "Copyright 2021 
FSF\nCopyright 2021, 2022 FSF\n")
  :value nil :explanation
  (array-elt 38
 (different-atoms
  (51 "#x33" "?3")
  (50 "#x32" "?2")
   FAILED  2/3  test-correct-notice (0.000103 sec)
[...]
Test test-end-chop condition:
(ert-test-failed
 ((should
   (equal
(with-temp-buffer ...)
"Copyright 2006, 2007, 2008, 2022 Foo Bar\n\n"))
  :form
  (equal "Copyright 2006, 2007, 2008, 2023 Foo Bar\n\n" "Copyright 2006, 
2007, 2008, 2022 Foo Bar\n\n")
  :value nil :explanation
  (array-elt 31
 (different-atoms
  (51 "#x33" "?3")
  (50 "#x32" "?2")
   FAILED  3/3  test-end-chop (0.000154 sec)
[...]
2 unexpected results:
   FAILED  test-correct-notice
   FAILED  test-end-chop

This comes from test/lisp/emacs-lisp/copyright-tests.el, which has

(ert-deftest test-end-chop ()
  (should
   (equal
(with-temp-buffer
  (let ((copyright-query nil))
(insert (make-string (- copyright-limit 14) ?x) "\n"
"\nCopyright 2006, 2007, 2008 Foo Bar\n\n")
(copyright-update)
(buffer-substring (- (point-max) 42) (point-max
"Copyright 2006, 2007, 2008, 2022 Foo Bar\n\n")))

(ert-deftest test-correct-notice ()
  (should (equal
   (with-temp-buffer
 (dotimes (_ 2)
   (insert "Copyright 2021 FSF\n"))
 (let ((copyright-at-end-flag t)
   (copyright-query nil))
   (copyright-update))
 (buffer-string))
   "Copyright 2021 FSF\nCopyright 2021, 2022 FSF\n")))

The cause may be that we are now in 2023 and the above tests
are expecting 2022. Instead of expecting 2022, shouldn't they
expect the current year?

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Running 3 tests (2023-01-13 15:46:41+0100, selector ‘(not (or (tag 
:expensive-test) (tag :unstable)))’)
   passed  1/3  test-copyright-update (0.372676 sec)
Test test-correct-notice backtrace:
  signal(ert-test-failed (((should (equal (with-temp-buffer (dotimes (
  ert-fail(((should (equal (with-temp-buffer (dotimes (_ 2) (insert "C
  #f(compiled-function () #)()
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name test-correct-notice :documentation ni
  ert-run-or-rerun-test(#s(ert--stats :selector (not (or (tag :expensi
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable)))
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  command-line-1(("-L" ":/home/vinc17/tmp/emacs-28.2+1/debian/build-sr
  command-line()
  normal-top-level()
Test test-correct-notice condition:
(ert-test-failed
 ((should
   (equal
(with-temp-buffer ... ... ...)
"Copyright 2021 FSF\nCopyright 2021, 2022 FSF\n"))
  :form
  (equal "Copyright 2021 FSF\nCopyright 2021, 2023 FSF\n" "Copyright 2021 
FSF\nCopyright 2021, 2022 FSF\n")
  :value nil :explanation
  (array-elt 38
 (different-atoms
  (51 "#x33" "?3")
  (50 "#x32" "?2")
   FAILED  2/3  test-correct-notice (0.000103 sec)
Test test-end-chop backtrace:
  signal(ert-test-failed (((should (equal (with-temp-buffer (let (...)
  ert-fail(((should (equal (with-temp-buffer (let ((copyright-query ni
  #f(compiled-function () #)()
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name test-end-chop :documentation nil :bod
  ert-run-or-rer

Bug#1027529: gnote: FTBFS: ../src/test/unit/datetimeutests.cpp:97:1: error: Failure in pretty_print_date: Expected Yesterday but was Dec 31 2022

[Santiago Vila]

El 13/1/23 a las 15:36, Jeremy Bicha escribió:

Control: severity -1 minor
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnote/-/issues/145

I'm downgrading the severity since the package builds fine today;
might build fine every day except January 1.


Why don't you disable the test instead? It's clearly wrong.

If we start allowing packages to FTBFS one day a year,
building the 34231 source packages in bookworm
might result in 93 completely gratuitous failures.

I don't think that's the standard of quality we want for bookworm.

Please reconsider.

Thanks.

Bug#1028606: python-zeroconf: Explicitly depend on python3-async-timeout.

[Corey Bryant]

Package: python-zeroconf
Version: d/control: Add explicit dependency on python3-async-timeout.
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Dear Maintainer,

A package build of ironic in Ubuntu antelope was installing python3-zeroconf
but python3-async-timeout wasn't getting installed. I think it *may* be due
to the pipe logic in python3-zeroconf 0.47.1 (see package build):
Depends: python3-async-timeout (>= 4.0.1) | python3 (>> 3.11)

In a package build for ubuntu antelope, at least currently, py3.10 and py3.11 
exist.
I'm assuming that python3.11 is installed at the time and therefore the 
dependency
is assumed to be satisifed by it.

In Ubuntu, the attached patch was applied to achieve the following:

  * d/control: Add explicit dependency on python3-async-timeout.


Thanks for considering the patch.


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

Kernel: Linux 5.19.0-23-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-zeroconf-0.47.1/debian/control 
python-zeroconf-0.47.1/debian/control
--- python-zeroconf-0.47.1/debian/control   2022-12-22 05:28:48.0 
-0500
+++ python-zeroconf-0.47.1/debian/control   2023-01-12 19:47:19.0 
-0500
@@ -28,7 +28,10 @@
 
 Package: python3-zeroconf
 Architecture: all
-Depends: ${python3:Depends}, ${misc:Depends}
+Depends:
+ python3-async-timeout (>= 4.0.1),
+ ${misc:Depends},
+ ${python3:Depends},
 Breaks: python3-pychromecast (<< 4.2.0~)
 Description: Pure Python implementation of multicast DNS service discovery 
(Python3)
  This is an implementation of the multicast DNS Service Discover Library

Bug#1027529: gnote: FTBFS: ../src/test/unit/datetimeutests.cpp:97:1: error: Failure in pretty_print_date: Expected Yesterday but was Dec 31 2022

[Jeremy Bicha]

Control: severity -1 minor
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnote/-/issues/145

I'm downgrading the severity since the package builds fine today;
might build fine every day except January 1.

Thank you,
Jeremy Bicha

Bug#1028409: vim: insecure use of /var/tmp when editing .gz files

[Bram Moolenaar]

> On Tue, Jan 10, 2023 at 06:58:15PM +0100, Jakub Wilk wrote:
> > If you edit a foo.gz file from a directory which is not writable by you, Vim
> > tries to use /var/tmp/foo.gz.swp as the swap file,
> 
> Vim prefers to use ~/tmp/foo.gz.swp, but it won't create ~/tmp for you.

This reminds me that the default value for 'directory' is not good for a
multi-user system.  However, it's not so easy to come up with an
alternative that will work everywhere.

> As for why this is happening with .gz files, I think it's because
> gzip#read does end up writing a file.  Refactoring the plugin to use
> the BufReadCmd, BufWriteCmd, etc. might help avoid this.

It will still need to write a file, so that the uncompress command can
read it.

> > even when this file
> > already exist and is owned by somebody else.
> 
> One of the main purposes of swap files is to detect when someone else is
> editing the same file and warn you.  Therefore, Vim has to try reading
> the potential swapfile.

If the file exist then Vim will use ".swo" instead of ".swp".  Anyway,
it would still be in the public "tmp" directory, thus this is just a
detail.

> Vim could try checking for non-regular files first, which would swap the
> naive problem here with one that requires a race to replace the file
> after it's checked.
> 
> Arguably, Vim should use the // form for any directory other than ".":
> 
>   - For Unix and Win32, if a directory ends in two path separators "//",
> the swap file name will be built from the complete path to the file
> with all path separators replaced by percent '%' signs (including
> the colon following the drive letter on Win32). This will ensure
> file name uniqueness in the preserve directory.
> 
> However, this just reduces chance of collisions, not the overall gist
> behind your reproduction.
> 
> > This can be exploited for
> > denial of service, maybe worse.
> > 
> > To reproduce, run:
> > 
> > mkfifo -m 666 /var/tmp/changelog.gz.swp
> > 
> > Then, as another user:
> > 
> > vim /usr/share/doc/vim/changelog.gz
> > 
> > Vim will hang forever (and can't be killed easily).

Also, others can read the swap file, something the user probably isn't
aware of.

-- 
Contrary to popular belief, it's often your clothing that gets promoted, not
you.
(Scott Adams - The Dilbert principle)

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///  \\\
\\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Bug#1028605: pinta: please package pinta 2.1

[Michael Young]

Package: pinta
Severity: wishlist
X-Debbugs-Cc: mctor...@gmail.com

Dear Maintainer,

I'm a long-time Debian user and would love to see Pinta available in the repos 
again.  I note that Pinta 2.1 was released last week 
 and I wonder if this 
might be the time to reconsider packaging it again.

I read the "please package pinta 2.0" thread from several years ago, and it 
sounded like this is far from trivial.  Still, I thought I'd highlight the new 
upstream release and mention that I'd love to use it if it became available 
again, for what that's worth.

Many thanks,
Michael

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

Kernel: Linux 6.0.0-6-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

Bug#1028604: gpxviewer: homepage seems to be wrong

[Laurent Bonnaud]

Package: gpxviewer
Version: 1.1.0-5
Severity: normal


Dear Maintainer,

according to the package metadata the homepage of the project is as follows:

$ dpkg -s gpxviewer
[...]
Version: 1.1.0-5
[...]
Homepage: https://github.com/andrewgee/gpxviewer

However, on this page, I only see tags up to version 0.5.3, whereas the package 
version is more recent.

Cheers,


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

Kernel: Linux 6.1.0-1-amd64 (SMP w/2 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 gpxviewer depends on:
ii  gir1.2-osmgpsmap-1.0  1.2.0-2
ii  librsvg2-common   2.54.5+dfsg-1
ii  python3   3.11.1-1
ii  python3-cairo 1.20.1-5
ii  python3-gi3.42.2-3
ii  python3-gi-cairo  3.42.2-3
ii  python3-gpxpy 1.5.0-1
ii  python3-matplotlib3.6.2-4

gpxviewer recommends no packages.

gpxviewer suggests no packages.

-- no debconf information

--
Laurent.

Bug#1028603: dh-python: Deps guarded by (python3 << 3.X) break python-3.(X-1) use

[Simon Chopin]

Package: dh-python
Version: 5.20221001
Severity: normal
X-Debbugs-Cc: scho...@ubuntu.com

For instance, pylint has "tomli>=1.1.0;python_version<'3.11'" in its
pyproject.toml, which is translated as "python3-tomli (>= 1.1.0) |
python3 (>= 3.11)".

This means that if we have python == 3.11 but still have python3.10 in
the archive, any code that iterates over all supported archive risks
failing simply due to the tomli module missing.

This is currently happening in the distro-info autopkgtests for the
python3-defaults migration from unstable to testing (and also in
Ubuntu). I'll probably be adding tomli as a test dependency in Ubuntu as
a stopgap, but I figured someone might think of a better long-term
solution to the issue.

-- System Information:
Debian Release: bookworm/sid
  APT prefers kinetic-updates
  APT policy: (500, 'kinetic-updates'), (500, 'kinetic-security'), (500, 
'kinetic'), (400, 'kinetic-proposed'), (100, 'kinetic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dh-python depends on:
ii  python33.10.6-1
ii  python3-distutils  3.10.7-1

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  dpkg-dev   1.21.9ubuntu1
pn  flit   
ii  libdpkg-perl   1.21.9ubuntu1
pn  python3-build  
pn  python3-installer  
ii  python3-tomli  2.0.1-1

-- no debconf information

Bug#1028602: transition: gnustep-base, gnustep-gui

[Yavor Doganov]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org
Control: affects -1 + src:gnustep-base src:gnustep-gui

Dear Release team,

We would like your permission to carry out a GNUstep transition (two
libraries simultaneously with one round of binNMUs):

  libgnustep-base1.28 -> 1.29
  libgnustep-gui0.29  -> 0.30

I realise we are already late and in all likelihood we've missed the
last bookworm train, which is rather unpleasant for us and GNUstep
users but entirely our fault.  In case it's not possible to do it now
(after tiff/poppler) then please have us in mind for the early stages
of the trixie development cycle.

gnustep-base/1.29.0-1 is available in experimental, not yet built on
mipsen, ppc64el and s390x.  But note that 1.28.1-2 was built in
unstable on all release architectures; 1.29.0 is essentially the same
except the version bump (the damage done was corrected; see #1028189).

gnustep-gui/0.30.0-1 is also available in experimental, not yet built
on ppc64el and s390x but I do not expect any problems there.

While build-testing all rdeps on amd64, the following problems were
observed:

agenda.app   #1028185  gnustep-gui bug, will be fixed with next upload
gnustep-dl2  #1028577  fixed locally; needs a sourceful upload
pantomime#1028578  likewise
sope #1028579  patch sent to the BTS; needs a sourceful upload

In addition, gnustep-back will require a sourceful upload (that is
always the case).

The automatic ben trackers at release.d.o look fine.