Bug#1040901: Upcoming changes to Debian Linux kernel packages

2023-10-26 Thread Julian Andres Klode
OK,

it seems my original email got lost somewhere in tech hickups,
it's possible the kernel crashed before sending the email, AMD
just crashes once or twice a day.

So I'm writing this email a bit in a hurry, so it's not quite
as thought out as the last one weeks ago, but yesterday's email
was pretty concerning.

We should not rush this. we need to be realistic that this will
take a couple of months to sort out a new scheme, don't expect
this to be done before the end of the year, and that seems to
be very optimistic.

On Sat, Oct 07, 2023 at 04:53:33PM +0200, Bastian Blank wrote:
> Moin
> 
> On Sun, Sep 24, 2023 at 03:01:51PM +0200, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
> 
> This is now
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/607.
> 
> > ## Image packages contains more version info
> > 
> > Example: linux-image-6.5.3-cloud-arm64
> 
> > It will not longer be possible to reliably derive the package name from
> > kernel release (see above), as both values are not really related
> > anymore.

This package name seems to be missing the Debian release, which is
mandatory to ensure that you can install 6.5.3-2 and 6.5.3-1 in
parallel, which again is mandatory. That's not something we can
compromise on; it's absolutely vital that

- you can revert to the kernel you last booted succesfully, i.e. 6.5.3-1
  if 6.5.3-2 is broken (think toolchain broke or something on buildds)

- the currently booted kernel is not impacted. This means it must be
  able to load additional modules. Some platforms even require
  additional modules to be loaded to reboot, I've seen this on
  laptops.

  It is fine to say "you must reboot", but it is not fine to just
  break the running system until you do.

> 
> I missed that apt does something similar (maintainers cced).  It wants
> to see if a particular package matches the current kernel to make the
> autoremove prevention work.  That lookup is quite a hard problem.
> 
> What should work:  We define a new control field.  It contains both the
> kernel name and a version prefix. 
> 
> Example:
> - Linux 6.6 (would match 6.6-1, 6.6.1-1)
> - Linux 6.6.3 (would match 6.6.3-1, but not 6.6.3+2-1)
> - Linux 6.6.3+2
> 
> The algorithm would be something like this:
> - Check $(uname -s) against the first word.  Otherwise completely
>   ignore.

Needless to say I do not believe that uname -s is necessarily a
single word.

> - Check if $(uname -r) matches the version prefix in this field.  Mark
>   as keep if it matches.
> - Aggregate packages by version prefix.
> - Sort as version, keep newest two(?).

I don't really care about the ordering, I want to order by package
version.

I need to identify:

* Which kernel image package is currently booted. Hence I need to
  go from the uname -r to exactly one installed kernel image package
  that acts as the key package to determine if a kernel version is
  installed.

* What are other installed kernel image packages

* Given a uname / kernel image package, which other kernel packages
  belong to it

This allows me to keep the currently installed kernels around.

The flip side of the coin is the code in APT that actually autoremoves
kernels: It needs to identify, given a list of kernel images to keep
which other kernel packages can be removed. Optimally it can still
remove headers for 6.6 if you don't even have 6.6 images installed
anymore and _somehow_ pulled them in.

Essentially I want to order kernel image packages by version,
and keep the currently booted and the latest one, and the 2nd
latest if currently booted == latest one, and then remove any
other versioned kernel package not related to them.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en



Bug#1054635: python3-certbot-dns-ovh: fails with Error adding TXT record: Expecting value: line 1 column 1 (char 0)

2023-10-26 Thread Jordi De Groof
Package: python3-certbot-dns-ovh
Version: 2.1.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Certbot renewal fails:
> systemctl status certbot
× certbot.service - Let's Encrypt renewal
 Loaded: loaded (/etc/systemd/system/certbot.service; static)
 Active: failed (Result: exit-code) since Fri 2023-10-27 01:05:12 CEST; 7h 
ago
TriggeredBy: ● certbot.timer
Process: 31415 ExecStart=/usr/bin/certbot renew --quiet --agree-tos 
--post-hook systemctl reload dovecot.service; systemctl reload lighttpd.service 
(code=exited, status=1/FAILURE)
   Main PID: 31415 (code=exited, status=1/FAILURE)
CPU: 24.663s

okt 27 01:01:13 alarm systemd[1]: Starting certbot.service - Let's Encrypt 
renewal...
okt 27 01:05:10 alarm certbot[31415]: Failed to renew certificate *** with 
error: Error adding TXT record: Expecting value: line 1 column 1 (char 0)
okt 27 01:05:11 alarm certbot[31415]: All renewals failed. The following 
certificates could not be renewed:
okt 27 01:05:11 alarm certbot[31415]:   /etc/letsencrypt/live/***/fullchain.pem 
(failure)
okt 27 01:05:11 alarm certbot[31415]: 1 renew failure(s), 0 parse failure(s)


The bug was alreay reported & fixed upstream, can it please be backported?: 
https://github.com/certbot/certbot/issues/9799


-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security-debug'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 6.1.0-13-marvell (UP)
Kernel taint flags: TAINT_WARN
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-certbot-dns-ovh depends on:
ii  certbot  2.1.0-4
ii  python3  3.11.2-1+b1
ii  python3-acme 2.1.0-1
ii  python3-certbot [python3-certbot-abi-2]  2.1.0-4
ii  python3-lexicon  3.11.7-1
ii  python3-pkg-resources66.1.1-1

python3-certbot-dns-ovh recommends no packages.

python3-certbot-dns-ovh suggests no packages.

-- no debconf information


Bug#1054634: RM: smuxi [all] -- RoQA; NBS; useless metapackage

2023-10-26 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

Please remove the arch:all cruft package smuxi, dropped in 1.1-1.3:

smuxi  | 1.1-1.2   | unstable | source, all
smuxi  | 1.1-2 | unstable | source


Andreas



Bug#1040901: Upcoming changes to Debian Linux kernel packages

2023-10-26 Thread Julian Andres Klode
On Thu, Oct 26, 2023 at 01:36:50PM +0200, Bastian Blank wrote:
> On Fri, Oct 20, 2023 at 05:54:23PM +0200, Bastian Blank wrote:
> > Or would it be easier to re-use normal dependency resolving, like:
> > Kernel-Provides: linux (>> 6.6.1~), linux (<< 6.6.1.)
> > This would allow full flexibility and re-uses existing code to check
> > such definitions.
> 
> Okay, noone complained, so it looks like this should work.
> 

No no it doesn't. Did nobody read my email? Did I even send my
email? I don't know what the hell is going on here, but I spend
an hour writing an email discussing the options outlined before
this ridiculousness and the requirements, but I can't find it
in my notmuch.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en



Bug#1054633: kitty: The CTRL-SHIFT-F5 and CTRL-SHIFT-F6 options only operate on config files loaded when kitty started

2023-10-26 Thread Russell Coker
Package: kitty
Version: 0.26.5-5
Severity: normal
Tags: upstream

When a new user first starts with kitty the most obvious thing to do is
CTRl-SHIFT-F2 to create a new config file and then CTRL-SHIFT-F5 to load
it after changes, but it will not load.  Kitty will only reload config (or
debug config via CTRL-SHIFT-F6) on files that it loaded when it started not
on files that would be loaded on the next start.  To make these changes take
effect you have to close kitty and restart it.

This is confusing for new users who don't have experience with kitty.

-- System Information:
Debian Release: 12.2
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages kitty depends on:
ii  kitty-shell-integration  0.26.5-5
ii  kitty-terminfo   0.26.5-5
ii  libc62.36-9+deb12u3
ii  libdbus-1-3  1.14.10-1~deb12u1
ii  libharfbuzz0b6.0.0+dfsg-3
ii  liblcms2-2   2.14-2
ii  libpng16-16  1.6.39-2
ii  libpython3.113.11.2-6
ii  librsync22.3.2-1+b1
ii  libssl3  3.0.11-1~deb12u2
ii  libwayland-client0   1.21.0-1
ii  libx11-6 2:1.8.4-2+deb12u2
ii  libx11-xcb1  2:1.8.4-2+deb12u2
ii  libxkbcommon-x11-0   1.5.0-1
ii  libxkbcommon01.5.0-1
ii  python3  3.11.2-1+b1
ii  python3.11   3.11.2-6
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages kitty recommends:
pn  kitty-doc 
ii  libcanberra0  0.30-10

Versions of packages kitty suggests:
ii  imagemagick  8:6.9.11.60+dfsg-1.6
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.6

-- debconf-show failed



Bug#1054602: mosdepth: Needs "libhts.so" as a dependency, avaialbe in package "libhts-dev"

2023-10-26 Thread Andreas Tille
Hi Frank,

thank you for your bug report which is always welcome.

Am Thu, Oct 26, 2023 at 12:24:20PM -0400 schrieb Frank Bearoff:
> * What led up to the situation?
> sudo apt install "mosdepth"

OK, you installed the package - but what did you after installing it?
Which command did you called that failed and is exposing the problem?

I checked the linked libraries:

$ ldd /usr/bin/mosdepth 
linux-vdso.so.1 (0x7fffa19fc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb43a39d000)
/lib64/ld-linux-x86-64.so.2 (0x7fb43a657000)

The package (also in the new upstream version which I could upload once
this is clarified) passes its CI test on our development platform[1].
Also the CI test in all Debian releases and architectures is passing
nicely[2].
 
> * What exactly did you do (or not do) that was effective (or
>  ineffective)?

Please write the error you get first ...

>  sudo apt install "libhts-dev"

... and than what is happening after this.

It does not sound very convincing that the development package is
needed.  Most probably your system will be solved by installing libhts3.
But first I would like to know what the problem really is.

> * What was the outcome of this action?
> mosdepth works

Please define `works`.  As in the given test CI links it works as
well.
 
> It appears "mosdepth has the undecalred dependency of "libhts-dev"

Dependencies from libraries are usually detected automatically which
works in general with extremely rare exceptions.  Its very uncommon that
a non-development package needs a *-dev package.
 
> -- System Information:
> 
> Versions of packages mosdepth depends on:
> ii  libc6  2.36-9+deb12u3

This is the only library that should be needed.
 
So please give the command line you called and the error message
that made you assume what is missing - ideally with the data you
used to enable us reproducing the problem.

Kind regards
Andreas.

[1] https://salsa.debian.org/med-team/mosdepth/-/jobs/4856753 
[2] https://ci.debian.net/packages/m/mosdepth/

-- 
http://fam-tille.de



Bug#1036399: Similar problem

2023-10-26 Thread Tommi Höynälänmaa
I have s similar problem with package g-golf, see 
https://mentors.debian.net/package/g-golf/.


Piuparts gives the following error:

---

1m37.6s ERROR: FAIL: Package purging left files on system:
  /etc/default/locale -> ../locale.conf     not owned
  /etc/vconsole.conf -> default/keyboard     not owned
  /root/.ssh/     not owned
  /var/cache/private/     not owned
  /var/lib/private/     not owned
  /var/lib/systemd/coredump/     not owned
  /var/lib/systemd/ephemeral-trees/     not owned
  /var/lib/systemd/pstore/     not owned
  /var/log/private/     not owned

---

 - Tommi

--
Kotisivu / Homepage: http://www.iki.fi/tohoyn/
Sähköposti / E-Mail: tommi.hoynalan...@iki.fi
GPG-sormenjälki / GPG fingerprint:
55F4 2477 7155 3528 5CB2 2B7A BB86 1FDE 4046 0F83
FM, Debian-ylläpitäjä / M.Sc., Debian Maintainer



Bug#1054632: Single-line description continues into extended description

2023-10-26 Thread Josh Triplett
Package: filtermail
Version: 1.04.00-1+b1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

Policy 3.4.2, "The extended description":
> Do not try to continue the single line synopsis into the extended
> description. This will not work correctly when the full description is
> displayed, and makes no sense where only the summary (the single line
> synopsis) is available.



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

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

Versions of packages filtermail depends on:
pn  libbobcat6  
ii  libc6   2.37-12
ii  libgcc-s1   13.2.0-5
ii  libstdc++6  13.2.0-5
ii  whois   5.5.19

filtermail recommends no packages.

filtermail suggests no packages.



Bug#1054631: libnvme1: libnvme causes random memory corruption with some NVMe devices

2023-10-26 Thread Steve Atwell
Package: libnvme1
Version: 1.3-1
Severity: important
Tags: patch

Dear Maintainer,

libnvme has a serious bug that, on some NVMe hardware, can trigger DMA
writes that overwrite memory of unrelated processes, resulting in random
crashes and other system stability issues.  This can be caused by simply
running `nvme list`.

This was very recently fixed upstream in
https://github.com/linux-nvme/libnvme/commit/a2b8e52e46cfd888ac5a48d8ce632bd70a5caa93
and
https://github.com/linux-nvme/libnvme/commit/68c6ffb11d40a427fc1fd70ac2ac97fd01952913.

I've been able to reproduce this in multiple systems that have
SKHynix_HFS256GD9TNI-L2B0B SSDs.  From recent commit descriptions in
libnvme and nvme-cli, it sounds like some NVMe devices DMA only in 4k
blocks, but libnvme would sometimes allocate a smaller buffer.  Which
can result in the DMA operation clobbering unrelated memory.

To reproduce:

1. Make sure the kernel isn't using IOMMU (e.g., boot with
intel_iommu=off).
2. Run `while nvme list; do sleep 0.1; done`.

Generally the nvme process will segfault or abort with an error within a
very small number of iterations.  Example dmesg output when this
happens:

[ 2238.591144] show_signal_msg: 6 callbacks suppressed
[ 2238.591150] nvme[1315]: segfault at 8 ip 7fbf286748e9 sp
7ffe4cbccb30 error 4 in libc.so.6[7fbf28603000+155000] likely on CPU
1 (core 1, socket 0)
[ 2238.591178] Code: 24 18 45 85 d2 0f 85 17 05 00 00 48 81 fb ff 03 00
00 76 20 43 8d 44 2d 0c 48 8d 44 c5 00 48 8b 10 48 8d 48 f0 48 39 ca 74
0a <48> 39 5a 08 0f 83 2b 05 00 00 41 8d 4d 01 43 8d 44 2d 0e 89 cf 48

If you keep running this, you'll also find that other processes start
crashing as well, usually with segfaults or weird shared library
failures.  I've seen sshd crash, firefox crash, systemd segfault, etc.
As an example, I recently saw sshd failing with this error:

Oct 26 19:46:27 challenger sshd[1361]: /usr/sbin/sshd: error while
loading shared libraries: /lib/x86_64-linux-gnu/libnsl.so.2: unexpected
PLT reloc type 0x00

I was able to trivially apply the two git commits listed above to
libnvme 1.3 in Bookworm, and this resolved the crash and memory
corruption caused by `nvme list`.  I'd recommend applying these
changes to libnvme in Bookworm, since the impact is pretty severe for
users who happen to own affected devices.

There have also been other recent memory alignment changes in libnvme
and nvme-cli.  It may be worth trying to backport more of these to
the Bookworm packages to avoid memory corruption during other nvme
operations.


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

Kernel: Linux 6.1.0-13-amd64 (SMP w/6 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 libnvme1 depends on:
ii  libc62.36-9+deb12u3
ii  libdbus-1-3  1.14.10-1~deb12u1
ii  libjson-c5   0.16-2
ii  libssl3  3.0.11-1~deb12u2

libnvme1 recommends no packages.

Versions of packages libnvme1 suggests:
ii  nvme-cli  2.4+really2.3-3

-- no debconf information



Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel

2023-10-26 Thread Guillem Jover
Hi!

On Thu, 2023-10-26 at 12:55:32 +0200, Guillem Jover wrote:
> On Thu, 2023-10-26 at 11:40:53 +0200, Emanuele Rocca wrote:
> > Package: dpkg-dev
> > Version: 1.22.0
> > Severity: normal

> > -fstack-clash-protection is supposed to be enabled by default on amd64,
> > arm64, armhf, and armel since dpkg 1.22.0:
> > https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf
> > 
> > However, due to an issue in the following conditional in
> > scripts/Dpkg/Vendor/Debian.pm, the flag is only on for amd64 and arm64:
> > 
> >   if (none { $cpu eq $_ } qw(amd64 arm64 armhf armel)) {
> > 
> > The value of $cpu is "arm" for both armhf and armel. Please change the
> > line above to:
> > 
> >   if (none { $cpu eq $_ } qw(amd64 arm64 arm)) {
> 
> Ah, nice catch, and sorry! I think this happened due to copy pasting
> and modifying one of the surrounding lines. The intention was to use
> $arch here, to avoid enabling this on all arm-based arches which might
> not support this. I've queued the attached patch for my next push.

Checking now again, I realize Wookey mentioned enabling this for the 3
arm arches (those would be arm64, armhf and armel), so the patch I
provided would match that. But I was wondering now what about armeb and
arm64ilp32? I mean, I assume those should be excluded for now as they
did not get any testing, and they might not even be used/lively(?),
but wanted to ask in any case before pushing. If I don't hear anything
before the release, I'll just push what I proposed, and we can always
enabled these later on if needed.

Thanks,
Guillem



Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol

2023-10-26 Thread Xiyue Deng
Xiyue Deng  writes:

> Hi Bo,
>
> Bo YU  writes:
>
>> Hi!
>>
>> On Thu, Oct 26, 2023 at 7:02 AM Xiyue Deng  wrote:
>>
>> ...
>>>
>>> For the unlikely but possible cause that tests with a long name is a
>>> prefix of other tests that may trigger this issue, I have modified the
>>> test name for testing purposes.  Can you help get the latest upload on
>>> mentors and try again?  TIA.
>>>
>> I tried this and it seems the issue was raised with my sbuild build 
>> environment.
>> I still got this:
>> https://paste.debian.net/1296268/
>>
>> My sbuilderrc is here:
>> https://paste.debian.net/1296269/
>>
>> But if use pbuilder[0] to build your package, it is ok.
>> So I think your package which is no problem.
>>
>> BTW, I suspect the network accessing leads to the issue and I am annoy how to
>> disable network access during building for sbuild.
>>
>> BR,
>> Bo
>> [0]: https://wiki.ubuntu.com/PbuilderHowto
>
> Thanks for testing!  The reason I'm interested in reproducing this error
> is that in the report of the RC bug that this upload is trying to solve
> - https://bugs.debian.org/1052939 - the build log from Lucas has exactly
> the same error:
>
> ,
> | ...
> | > Test ‘lsp-text-document-hover-request’ redefined
> | > 
> | > Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
> | ...
> `
>
> But I haven't been able to reproduce this until Arto and you sent your
> reports, and this being reproduced by two people makes this more
> interesting.  There must be something that may trigger this unlikely
> error.  Also I'm not sure whether the network accessing may have been
> the cause as sbuild needs to download the dependencies and without
> something like apt-cacher{,-ng} it does need network access for that to
> happen.
>
> I suspected that the parallel setting in $DEB_BUILD_OPTIONS may have
> affected it so I copied your sbuild settings and tried again but
> unfortunately it still succeeded for me.  For the unlikely event and for
> completeness, can you also try to turn that off in your sbuild config
> and retry just in case?  TIA.
>

Actually scratch my previous mail, as I found how to produce the issue.
In `lsp-clangd-test.el' it does `(require 'lsp-integration-test)', so if
`lsp-clangd-test.el' is loaded before `lsp-integration-test.el', it
seems the test symbols in the latter are loaded twice that triggers the
error regardless of whether there is an actual duplicated test name.  I
can confirm that in your build log that the clangd one was loaded first
which causes this error.  I assume Arto sees it due to the same cause.

I have added another change to override dh_elpa_test to ensure
`lsp-clangd-test' is loaded last and uploaded to mentors.  Please help
test again.

I'll probably also report this issue upstream to see how it should be
handled.

>>> ,
>>> | $ dget -x 
>>> https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>>> | $ sbuild lsp-mode_8.0.0-6.dsc
>>> `
>>>
>>> P.S. If you can provide the failed build log and ~/.sbuildrc it may
>>> still help to eliminate potential sbuild differences in our environment.
>>>
>>> >>
>>> >> BR,
>>> >> Bo
>>> >>>
>>> >>> --
>>> >>> Arto Jantunen
>>> >>>
>>>
>>> --
>>> Xiyue Deng

-- 
Xiyue Deng



Bug#1054630: dgit - cant import llvm-toolchain-15.

2023-10-26 Thread Peter Green

Package: dgit
Version: 11.3

dgit can't import the current version of llvm-toolchain-15



dgit import-dsc ../llvm-toolchain-15_15.0.7-10.dsc ..workingbranch
Dgit metadata in .dsc: NO git hash
using existing llvm-toolchain-15_15.0.7.orig.tar.xz
using existing llvm-toolchain-15_15.0.7-10.debian.tar.xz
dpkg-source: info: extracting llvm-toolchain-15 in llvm-toolchain-15-15.0.7
dpkg-source: info: unpacking llvm-toolchain-15_15.0.7.orig.tar.xz
dpkg-source: info: unpacking llvm-toolchain-15_15.0.7-10.debian.tar.xz
dpkg-source: warning: unexpected end of diff 
'llvm-toolchain-15-15.0.7/debian/patches/gcc-13-build-fix.patch'
dpkg-parsechangelog: warning: debian/changelog(l124): found start of entry 
where expected more change data or trailer
LINE: llvm-toolchain-14 (1:14.0.6-16) unstable; urgency=medium

dgit: error: missing field Maintainer in package changelog, entry no.11



Now on the one hand, the changelog in llvm-toolchain-15 is indeed broken.
I filed a bug about that.

On the other hand, the package was accepted by the Debian archive and
related tooling. Not being able to import it is blocking things up
for raspbian. I'd appreciate a way to downgrade this error to a
warning.



Bug#1054629: conmon: Healthcheck containers write error to system journal

2023-10-26 Thread Matthew Horan
Package: conmon
Version: 2.1.6+ds1-1
Severity: normal
X-Debbugs-Cc: m...@matthoran.com

Dear Maintainer,

When running a Podman container which leverages a healthcheck (e.g.  
docker.io/jacobalberty/unifi) via systemd service, conmon will write an 
error to the system journal when the check completes. See upstream issue 
https://github.com/containers/conmon/issues/438.

I built my own conmon 2.1.8 package which includes the fix here: 
https://github.com/containers/conmon/commit/77ce3127c3956d65f9400621d7e2d89fcde7f2e1
 
and the errors went away.

In the process of creating this package I also noticed that 
https://salsa.debian.org/podman-team/conmon looks to be out of date, in 
that it's missing the last release (2.1.6).

Thanks,
Matt


-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-13-amd64 (SMP w/8 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 conmon depends on:
ii  libc6 2.36-9+deb12u3
ii  libglib2.0-0  2.74.6-2
ii  libsystemd0   252.17-1~deb12u1

conmon recommends no packages.

conmon suggests no packages.

-- no debconf information



Bug#1054627: budgie-control-center: Drop obsolete Suggests: libcanberra-gtk-module

2023-10-26 Thread Jeremy Bícha
Source: budgie-control-center
Version: 1.3.0-1

Please drop Suggests: libcanberra-gtk-module

That's actually the GTK2 support and the binary package is no longer
built by libcanberra in Unstable.

Thank you,
Jeremy Bícha



Bug#1054628: unzip: zipgrep doesn't handle regexp with some special characters correctly

2023-10-26 Thread Vincent Lefevre
Package: unzip
Version: 6.0-28
Severity: normal
Tags: upstream patch

zipgrep doesn't handle regexp with some special characters correctly,
as shown below.

$ echo a.b > file1
$ echo a-b > file2
$ zip files.zip file1 file2
  adding: file1 (stored 0%)
  adding: file2 (stored 0%)

With egrep:

$ egrep a\\.b file1 file2
file1:a.b
$ egrep a\|b file1 file2
file1:a.b
file2:a-b
$

But with zipgrep:

$ zipgrep a\\.b files.zip
$ zipgrep a\|b files.zip
$

This is due to the following code:

# Escape shell-special characters in "pat".
pat=` echo "$pat" | \
 sed -e 's///g' -e 's/|/\\\|/g' -e 's/&/\\\&/g' `

which breaks the regexp. Escaping is useless because once a string
is in a shell variable pat, it is no longer reinterpreted when just
using "$pat". And as a consequence, escaping is incorrect because
the escape characters are not removed when using "$pat". Moreover,
the use of echo was not portable.

I've attached a patch, which removes this useless/incorrect code.

-- System Information:
Debian Release: trixie/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.5.0-3-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

Versions of packages unzip depends on:
ii  libbz2-1.0  1.0.8-5+b1
ii  libc6   2.37-12

unzip recommends no packages.

Versions of packages unzip suggests:
ii  zip  3.0-13

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Index: b/unix/zipgrep
===
--- a/unix/zipgrep
+++ b/unix/zipgrep
@@ -49,10 +49,6 @@ status_grep_global=1
 IFS='
 '
 
-# Escape shell-special characters in "pat".
-pat=` echo "$pat" | \
- sed -e 's///g' -e 's/|/\\\|/g' -e 's/&/\\\&/g' `
-
 # Use "unzip -Z1" to get a listing of the specified members from the
 # specified archive.  Escape any backslashes in a file name.
 for i in `unzip -Z1 "$zipfile" ${1+"$@"} | sed -e 's///g' `; do


Bug#1054626: calamares: Calamares hangs on "Removing ## packages" at 73% -- never gets past that

2023-10-26 Thread Fred McKinney
Package: calamares
Version: 3.2.61
Severity: important
X-Debbugs-Cc: fred...@gmail.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 ***


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

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

Versions of packages calamares depends on:
pn  kpackagetool5
pn  libboost-python1.74.0
pn  libboost-python1.74.0-py311  
ii  libc62.36-9+deb12u3
ii  libcrypt11:4.4.33-2
ii  libgcc-s112.2.0-14
pn  libkf5configcore5
pn  libkf5coreaddons5
pn  libkf5package5   
pn  libkf5parts5 
pn  libkpmcore12 
ii  libparted2   3.5-3
pn  libpwquality1
ii  libpython3.113.11.2-6
ii  libqt5core5a 5.15.8+dfsg-11
ii  libqt5dbus5  5.15.8+dfsg-11
ii  libqt5gui5   5.15.8+dfsg-11
ii  libqt5network5   5.15.8+dfsg-11
ii  libqt5qml5   5.15.8+dfsg-3
ii  libqt5quick5 5.15.8+dfsg-3
pn  libqt5quickwidgets5  
ii  libqt5svg5   5.15.8-3
pn  libqt5webkit5
ii  libqt5widgets5   5.15.8+dfsg-11
ii  libqt5xml5   5.15.8+dfsg-11
ii  libstdc++6   12.2.0-14
pn  libyaml-cpp0.7   
ii  os-prober1.81

Versions of packages calamares recommends:
pn  btrfs-progs 
pn  squashfs-tools  

calamares suggests no packages.



Bug#1054625: boxes: New upstream release

2023-10-26 Thread Jeremy Bícha
Source: boxes
Version: 2.2.0-2
Severity: wishlist

Please package the new upstream release of boxes:
https://boxes.thomasjensen.com/2023/08/boxes-v2.2.1-released.html

Thank you,
Jeremy Bícha



Bug#1054622: im-config: can set GTK_IM_MODULE to xim, which causes GTK 4 to complain

2023-10-26 Thread brian m. carlson
On 2023-10-26 at 22:51:19, Gunnar Hjalmarsson wrote:
> On 2023-10-26 23:51, brian m. carlson wrote:
> > I have a system with Zoom installed, which necessitates installing
> > ibus, which I don't want to use (because it overrides my shortcut
> > keys without consent).  Thus, the advice I've received is to install
> > im-config and use to set the module to "xim".
> 
> That's bad advice. Where did you get it?
> 
> Don't set it to "xim", set it to "none" instead, which means that im-config
> does not touch any environment variables (and does not launch ibus-daemon).

I believe I got it when I filed a bug report on ibus about some bug
where it affected my input in some way.  I don't recall, since it's been
some time.

> > I don't think, given that GTK+ 4 is used for a wide variety of
> > software in Debian, that it's safe to set GTK_IM_MODULE to "xim"
> > anymore, and im-config needs to not do that.
> 
> Your observation is not a sufficient reason to conclude that "xim" is never
> useful and should be removed as an option. im-config does not set that
> option automatically, but only if the user chooses it explicitly. In your
> case due to a bad advice. ;)
> 
> So I'm inclined to close this bug as a "wontfix", but await possible further
> input on the matter.

I'd argue that setting any environment variables that make programs
scream to the terminal is not okay.  I'm fine with im-config setting any
value that doesn't do that.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA


signature.asc
Description: PGP signature


Bug#1054552: glibc: stat fails when access time is bogus

2023-10-26 Thread Guillem Jover
Hi!

On Thu, 2023-10-26 at 19:27:48 +0200, Aurelien Jarno wrote:
> control: reassign -1 dpkg
> control: retitle -1 dpkg: stat fails on 32-bit systems when access time is 
> bogus

> On 2023-10-25 23:29, Simon McVittie wrote:
> > On Wed, 25 Oct 2023 at 20:53:57 +0200, Jarek Czekalski wrote:
> > > I tried to upgrade system (apt-get upgrade), but it failed in dpkg:
> > > 
> > > Unpacking initscripts (3.06-4) over (2.96-7+deb11u1) ...
> > > dpkg: error processing archive
> > > /var/cache/apt/archives/initscripts_3.06-4_all.deb (--unpack):
> > >  unable to stat './var/log' (which was about to be installed): Value too
> > > large for defined data type

> > > stat /var/log
> > > 
> > >   File: /var/log
> > >   Size: 4096    Blocks: 8  IO Block: 4096 directory
> > > Device: 8,1 Inode: 2752691 Links: 12
> > > Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/ root)
> > > Access: 2040-05-10 23:31:40.285032309 +0200
> > > Modify: 2023-10-25 16:03:42.313742411 +0200
> > > Change: 2023-10-25 16:03:42.313742411 +0200
> > >  Birth: 2017-02-27 09:46:56.739719147 +0100
> > > 
> > > This date (2040) causes dpkg to fail. The workaround is correcting it by
> > > touch /var/log.

> > It is not possible for 32-bit stat() to work correctly on 32-bit systems
> > with dates beyond 2038, because the timestamp will not fit in the data
> > type used. The only solution would be for the program in question (in
> > this case, dpkg) to be compiled with support for 64-bit timestamps.
> 
> I agree with the explanation.
> 
> > Your bug report seems to be from an upgrade from Debian 11 to Debian 12,
> > and Debian 11's glibc version did not support APIs that provide 64-bit
> > timestamps on 32-bit systems, so Debian 11's dpkg cannot support that
> > either.
> > 
> > Debian 12's glibc does, but that will only help you after fully upgrading
> > to Debian 12, at which point you will have Debian 12 versions of glibc
> > and dpkg.

> > Unfortunately, I don't think there's necessarily anything that can be done
> > here, beyond the general move towards supporting 64-bit timestamps
> > distribution-wide that is already in progress.
> 
> The other alternative is to add support at the dpkg level, just like it
> is already the case for some packages like coreutils. I am therefore
> reassigning the bug to dpkg, but I fully understand if it get tagged as
> wontfix until 64-bit timestamps are supported at the distribution-wide
> level.

Right, I think this would be ideal, otherwise the entire port becomes
pretty useless if dpkg itself cannot even be used. There are several
things to take into account though:

  - autoconf with the AC_SYS_YEAR2038 macro has not been released yet,
so I'll need to implement a replacement for that, which I guess I
might need to do anyway otherwise that would involve requiring a
too recent autoconf version.
  - This could wait for the time64 transition, but then this will
leave the i386 port broken (as is supposed to be intended by
that transition), which means this report could not be solved,
but that seems less than ideal as I've mentioned before, because
that means the port is dead at that point. So…
  - Building dpkg with time64 support *everywhere* could be a problem
when the shared libraries it uses or it might use in the future are
not also built with time64 support (the default for i386 based on
the proposed time64 plan in Debian). I've done a brief check over
all currently potentially used libraries and their public
interfaces:
+ libmd → ok (no types involving time)
+ libselinux → ok
+ libz → ok
+ libbz2 → ok
+ liblzma → ok
+ libzstd → ok
+ libps → Hurd library, might be a problem, need to check further
+ libsocket → Solaris library (not relevant in Debian)
+ libkvm → BSD library (not relevant in Debian, several BSDs
   force-switched to time64 anyway)
+ libcurses → seems ok on a quick skim
And prospective ones:
+ libaudit → ok
+ libacl → ok
+ libcap → ok
  - If none of these libraries get built with time64 on all 32-bit
arches (including i386), then dpkg might still fail due to
internal failures in those libraries.

So I guess once the first part is done I _could_ build dpkg with time64
on *all* 32-bit arches that support it (including i386), although if
(like it looks like) the ABIs for the listed shared libraries are not
affected by time64, then it might be way better to also build these
libraries everywhere with time64 anyway, because that should not affect
backwards compat for its current users, and if new symbols get added
with time types then those would not affect old binary programs that
people are concerned about, and would still make it safe to use the
libraries.

Thanks,
Guillem



Bug#1054622: im-config: can set GTK_IM_MODULE to xim, which causes GTK 4 to complain

2023-10-26 Thread Gunnar Hjalmarsson

On 2023-10-26 23:51, brian m. carlson wrote:

I have a system with Zoom installed, which necessitates installing
ibus, which I don't want to use (because it overrides my shortcut
keys without consent).  Thus, the advice I've received is to install
im-config and use to set the module to "xim".


That's bad advice. Where did you get it?

Don't set it to "xim", set it to "none" instead, which means that 
im-config does not touch any environment variables (and does not launch 
ibus-daemon).


im-config -n none


I don't think, given that GTK+ 4 is used for a wide variety of
software in Debian, that it's safe to set GTK_IM_MODULE to "xim"
anymore, and im-config needs to not do that.


Your observation is not a sufficient reason to conclude that "xim" is 
never useful and should be removed as an option. im-config does not set 
that option automatically, but only if the user chooses it explicitly. 
In your case due to a bad advice. ;)


So I'm inclined to close this bug as a "wontfix", but await possible 
further input on the matter.


--
Cheers,
Gunnar Hjalmarsson



Bug#1054585: phpmyadmin: no cleanup of tmp dir

2023-10-26 Thread Beowulf
Control: Severity -1 normal

Hi!
Thanks for maintaining phpmyadmin and your fast response!

> Are you really sure this files are php sessions?
Yes, for us there are php session files in there. 

PHP ships a session cleaner that uses the session.save_path from /etc/php/$
{version}/${conf_dir}/php.ini. Normally the save_path does point to /var/lib/
php/sessions.

I think you are right and the default installation of phpmyadmin stores 
session data in /var/lib/php/sessions and everything is fine.
But as we hardened our server, we setup an own php-fpm pool for phpmyadmin and  
changed the save_path to /var/lib/phpmyadmin/tmp. It seems like that it is our 
own created problem and we do need scripting on our end to clean these files ;)

> They are twig cache files for sure, but yes they could be cleaned up before
> each upgrade.
Yes we see those too and these should be cleaned up.

At least this part of the bug report is actually valid  ;)

Best Regards
Florian

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


Bug#1054623: dokuwiki: DokuWiki unable to render some pages with TypeError

2023-10-26 Thread bakerst
Package: dokuwiki
Version: 0.0.20220731.a-2
Severity: normal
X-Debbugs-Cc: bake...@biomail.me

Dear Maintainer,

dokuwiki is unable to render some pages and shows the error message:
"TypeError: implode(): Argument #2 ($array) must be of type ?array, string 
given"

The easiest way to reproduce the bug is to head to the page
"wiki:syntax". On a freshly installed host without any special
configuration, the URL that fails is:
http://127.0.0.1/dokuwiki/doku.php?id=wiki:syntax

In the dokuwiki logfile, this is the stack trace:
2023-10-26 21:51:00 
/usr/share/php/simplepie/library/SimplePie/Parse/Date.php(544)  TypeError: 
implode(): Argument #2 ($array) must be of type ?array, string given
  #0 /usr/share/php/simplepie/library/SimplePie/Parse/Date.php(544): implode()
  #1 /usr/share/php/simplepie/library/SimplePie/Parse/Date.php(577): 
SimplePie_Parse_Date->__construct()
  #2 /usr/share/php/simplepie/library/SimplePie/Registry.php(222): 
SimplePie_Parse_Date::get()
  #3 /usr/share/php/simplepie/library/SimplePie/Item.php(772): 
SimplePie_Registry->call()
  #4 /usr/share/php/simplepie/library/SimplePie.php(2890): 
SimplePie_Item->get_date()
  #5 /usr/share/php/simplepie/library/SimplePie.php(2777): 
SimplePie->get_items()
  #6 /usr/share/dokuwiki/inc/parser/xhtml.php(1339): 
SimplePie->get_item_quantity()
  #7 /usr/share/dokuwiki/inc/parserutils.php(682): Doku_Renderer_xhtml->rss()
  #8 /usr/share/dokuwiki/inc/parserutils.php(149): p_render()
  #9 /usr/share/dokuwiki/inc/parserutils.php(89): p_cached_output()
  #10 /usr/share/dokuwiki/inc/Ui/PageView.php(68): p_wiki_xhtml()
  #11 /usr/share/dokuwiki/inc/Action/Show.php(37): dokuwiki\Ui\PageView->show()
  #12 /usr/share/dokuwiki/inc/template.php(100): 
dokuwiki\Action\Show->tplContent()
  #13 [internal function]: tpl_content_core()
  #14 /usr/share/dokuwiki/inc/Extension/Event.php(133): call_user_func_array()
  #15 /usr/share/dokuwiki/inc/Extension/Event.php(199): 
dokuwiki\Extension\Event->trigger()
  #16 /usr/share/dokuwiki/inc/template.php(85): 
dokuwiki\Extension\Event::createAndTrigger()
  #17 /var/lib/dokuwiki/lib/tpl/dokuwiki/main.php(59): tpl_content()
  #18 /usr/share/dokuwiki/inc/actions.php(27): include('...')
  #19 /usr/share/dokuwiki/doku.php(126): act_dispatch()
  #20 {main}

The upstream bugtracker has some information:
https://github.com/dokuwiki/dokuwiki/issues/74087

It would appear that this is a dependency problem: this version of
dokuwiki is not compatible with the version of libphp-simplepie in
bookworm.

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

Kernel: Linux 6.1.0-13-amd64 (SMP w/6 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 dokuwiki depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  javascript-common  11+nmu1
ii  libjs-jquery   3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-cookie12-4
ii  libjs-jquery-ui1.13.2+dfsg-1
ii  libphp-simplepie   1.3.1+dfsg-5
ii  perl   5.36.0-7
ii  php2:8.2+93
ii  php-geshi  1.0.9.1-1
ii  php-phpseclib  2.0.42-1
ii  php-random-compat  2.0.21-1
ii  php-xml2:8.2+93
ii  php8.2 [php]   8.2.7-1~deb12u1
ii  php8.2-xml [php-xml]   8.2.7-1~deb12u1
ii  ucf3.0043+nmu1

Versions of packages dokuwiki recommends:
ii  imagemagick  8:6.9.11.60+dfsg-1.6
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.6
ii  php-ldap 2:8.2+93
ii  php8.2-cli [php-cli] 8.2.7-1~deb12u1
ii  php8.2-ldap [php-ldap]   8.2.7-1~deb12u1
ii  wget 1.21.3-1+b2

Versions of packages dokuwiki suggests:
pn  libapache2-mod-xsendfile  

-- debconf information:
  dokuwiki/system/configure-webserver: apache2
  dokuwiki/wiki/superuser: admin
  dokuwiki/system/writeconf: false
  dokuwiki/wiki/email: webmaster@localhost
  dokuwiki/system/accessible: localhost only
  dokuwiki/wiki/failpass:
  dokuwiki/wiki/acl: true
  dokuwiki/wiki/license: cc-by-sa
  dokuwiki/system/documentroot: /dokuwiki
  dokuwiki/system/localnet: 10.0.0.0/24
  dokuwiki/wiki/title: Debian DokuWiki
  dokuwiki/system/restart-webserver: true
  dokuwiki/wiki/policy: public
  dokuwiki/system/writeplugins: false
  dokuwiki/wiki/fullname: DokuWiki Administrator
* dokuwiki/system/purgepages: false



Bug#1054622: im-config: can set GTK_IM_MODULE to xim, which causes GTK 4 to complain

2023-10-26 Thread brian m. carlson
Package: im-config
Version: 0.57-2
Severity: normal

I have a system with Zoom installed, which necessitates installing ibus,
which I don't want to use (because it overrides my shortcut keys without
consent).  Thus, the advice I've received is to install im-config and
use to set the module to "xim".  I don't care very much what input
method is used, but it must not touch any shortcut keys and it must
support the Compose key correctly so I can type Spanish, French, and
various punctuation signs (e.g., ellipsis, section, and various dashes).

Now, with that context, I have an editor that uses GTK+ 4 (Neovim-GTK),
which I frequently invoke from the command line.  GTK+ 4 does not
support xim, and thus it screams to the terminal like so:

  (NeovimGtk:2644084): Gtk-WARNING **: 21:29:13.213: No IM module matching 
GTK_IM_MODULE=xim found

Since this is an editor I invoke from the command line, the terminal
noise is unwelcome.  I have had to unset the appropriate environment
variable in my terminal in the meantime.

I don't think, given that GTK+ 4 is used for a wide variety of software
in Debian, that it's safe to set GTK_IM_MODULE to "xim" anymore, and
im-config needs to not do that.  More generally, im-config needs to not
set global environment variables which cause programs to log loudly to
the terminal, and unfortunately GTK+ programs do exactly that.  Because
the GTK+ developers don't see screaming to the terminal as a problem and
won't fix it or provide a way to disable it, the solution has to be in
im-config instead.  (Of course, you are welcome to try to convince the
GTK+ developers nonetheless.)

-- Package-specific info:
=== command path ==
im-config is /usr/bin/im-config

=== im-config API -l: available IM ===
im-config -l =>  ibus xim

=== im-config API -m: selected IM ===
im-config -m => 
   'system' 'user' 'automatic' 'override' 'autobase'
   'default' 'custom' 'ibus' '' 'ibus'

=== /etc/default/im-config ==
# Default im-config mode (see im-config(8))

# This im-config helps to start best available input method (IM)

# Always start highest priority IM
IM_CONFIG_DEFAULT_MODE=auto
# Start or not to start IM dynamically under CJKV/desktop environment
#IM_CONFIG_DEFAULT_MODE=cjkv
# Never start IM by im-config (Leave it to desktop system)
#IM_CONFIG_DEFAULT_MODE=none

# cjkv mode behavior:
#  case 1:
#* desktop is listed in CJKV_DEFAULT_DESKTOP
#* locale is under so-called CJKV environments
#--> auto mode
#  case 2:
#* desktop is listed in CJKV_DEFAULT_DESKTOP
#* locale is *not* under so-called CJKV environments
#--> none mode
#  case 3:
#* desktop is *not* listed in CJKV_DEFAULT_DESKTOP
#* locale is under any environments
#--> auto mode
#
CJKV_DEFAULT_DESKTOP="*"
#CJKV_DEFAULT_DESKTOP="KDE:LXQt:XFCE"

# List of locales for so-called CJKV environments
CJKV_LOCALES="zh_TW:zh_HK:zh_SG:zh_CN:ja_JP:ko_KR:vi_VN"

# Set locale dependent preferred IM over standard auto mode if not GNOME
IM_CONFIG_PREFERRED_RULE="zh_CN,fcitx5:zh_TW,fcitx5:zh_HK,fcitx5:zh_SG,fcitx5"

# User and system wide configuration is normally done via im-config program.
# The above IM_CONFIG_PREFERRED_RULE sets locale dependent preferred IM
# override rule.  If you wish to use uim over ibus just for ja_JP,
# add :ja_JP,uim at the end of the above list. (Marked by "!" in GUI)

# List of desktop systems which starts ibus if available
#   Applicable desktops are excluded for applying IM_CONFIG_PREFERRED_RULE
DESKTOP_SETUP_IBUS="GNOME"

# Trace commands for debug
# (This may cause problem configuration file generated under console mode)
#IM_CONFIG_SETMODE="-x"

# Verbose output for debug (uncomment following)
#IM_CONFIG_VERBOSE="true"


=== localectl status ===
System Locale: LANG=en_CA.UTF-8
   LANGUAGE=en_CA:en
VC Keymap: (unset)
   X11 Layout: us
X11 Model: pc105

=== /etc/X11/default-display-manager ===
/usr/sbin/lightdm

=== setxkbmap -print ===
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include 
"pc+us+inet(evdev)+capslock(escape)+ctrl(swap_rwin_rctl)+compose(lwin)+terminate(ctrl_alt_bksp)"
};
xkb_geometry  { include "pc(pc102)" };
};

=== ~/.Xmodmap ===
clear control
clear mod4
add control = Control_L
add mod4 = Control_R

=== environment vars ==
DISPLAY=:0
XDG_CURRENT_DESKTOP=MATE
XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/bmc
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=lightdm-xsession
XDG_SESSION_ID=2
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SESSION_TYPE=x11
XDG_VTNR=7
CLUTTER_IM_MODULE=xim
QT_IM_MODULE=xim
XMODIFIERS=@im=none


-- System Information:
Debian Release: trixie/sid
  APT prefers oldstable-security
  APT policy: (500, 'oldstable-security'), (500, 'unstable'), (500, 'stable'), 
(1

Bug#1054621: lutris: new dependencies

2023-10-26 Thread Reiner Herrmann
Source: lutris
Version: 0.5.14-1

Dear maintainer,

while upgrading lutris I noticed that it has some new dependencies, like
fluidsynth and xdg-desktop-portal-*. They were added in the "release"
commit [0], without explaining why they were added or documenting the
change in the changelog.
Did you add them accidentally?
And are they real hard dependencies?
The previous version of lutris was running fine without having them
installed. Unless the new upstream version changed something that makes
them mandatory, they should probably be declared as Recommends or even
Suggests.
Can you please consider loosening the dependency?

Kind regards,
  Reiner

[0]: 
https://salsa.debian.org/games-team/lutris/-/commit/013050e8c8def0f571d2e8a57670ef4f1425965d



Bug#1051851: network-manager-openconnect-gnome: Undefined symbol, seems like linked against old GST

2023-10-26 Thread Michael Biebl
On Wed, 13 Sep 2023 18:08:10 +0200 Mateusz Kaduk 
 wrote:

Package: network-manager-openconnect-gnome
Version: 1.2.10-1
Severity: important
X-Debbugs-Cc: mateusz.ka...@gmail.com

Dear Maintainer,

I think on sid openconnect dialog is broken

/usr/lib/NetworkManager/nm-openconnect-auth-dialog: symbol lookup error: 
/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37: undefined symbol: 
gst_transcoder_get_sync_signal_adapter



Please send the output of
ldd /usr/lib/NetworkManager/nm-openconnect-auth-dialog

My guess is, that you have an outdated library in /usr/local.




OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1054620: bcachefs-tools: Issues in packaging and git repo

2023-10-26 Thread Daniel Gröber
Source: bcachefs-tools
Severity: minor
X-Debbugs-Cc: d...@darkboxed.org

Hi Jonathan,

while building the bcachefs-tools package from git I noticed that
there are a couple of problems:

 - gbp.conf doesn't disable pristine-tar but no pristine-tar branch is
   available, making gbp export-orig fail

 - debian/files was committed to the git repo when it shouldn't be.

 - The upstream version 24~really1.2 should likely have been s/~/+/
  24+really1.2. Currently it compares as less than what's in unstable
  "24".

  See 
https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly

  TBH it seems to me +really isn't appropriate here as it's never
  going to go away. You should use an epoch instead, after posting on d-devel 
obv.

Thanks,
--Daniel



Bug#1054619: [INTL:sv] Swedish strings for distcc debconf

2023-10-26 Thread Martin Bagge / brother

package: distcc
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother# Translation of distcc debconf template to Swedish
# Copyright (C) 2010, 2023 Martin Bagge 
# This file is distributed under the same license as the distcc package.
#
# Martin Ågren , 2008.
# Martin Bagge , 2009, 2010, 2023
msgid ""
msgstr ""
"Project-Id-Version: distcc_2.18.3-7.1_sv\n"
"Report-Msgid-Bugs-To: dis...@packages.debian.org\n"
"POT-Creation-Date: 2018-12-22 18:41+0100\n"
"PO-Revision-Date: 2023-10-26 22:01+0200\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Poedit-Language: Swedish\n"
"X-Poedit-Country: Sweden\n"
"X-Generator: KBabel 1.11.4\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../distcc.templates:1001
msgid "Start the distcc daemon on startup?"
msgstr "Starta distcc-demonen vid systemet uppstart?"

#. Type: boolean
#. Description
#: ../distcc.templates:1001
msgid ""
"distcc can be run as a daemon, listening on port 3632 for incoming "
"connections."
msgstr ""
"distcc kan köras som en demon och lyssnar på port 3632 efter inkommande "
"anslutningar."

#. Type: boolean
#. Description
#: ../distcc.templates:1001
msgid ""
"You have the option of starting the distcc daemon automatically on the "
"computer startup. If in doubt, it's advised not to start it automatically on "
"startup. If you later change your mind, you can run: 'dpkg-reconfigure "
"distcc'."
msgstr ""
"Du har möjligheten att starta distcc-demonen automatiskt när datorn startar "
"upp. Om du är osäker föreslås att du inte startar den automatiskt vid "
"uppstart. Om du ändrar dig senare kan du köra: \"dpkg-reconfigure distcc\"."

#. Type: string
#. Description
#: ../distcc.templates:2001
msgid "Allowed client networks:"
msgstr "Tillåtna klientnätverk:"

#. Type: string
#. Description
#: ../distcc.templates:2001
msgid ""
"The distcc daemon implements access control based on the IP address of the "
"client, that is trying to connect. Only the hosts or networks listed here "
"are allowed to connect."
msgstr ""
"distcc-demonen implementerar tillgångskontroll baserat på IP-addressen hos "
"klienten som försöker ansluta. Bara de värdar eller nätverk som listas här "
"tillåts ansluta."

#. Type: string
#. Description
#: ../distcc.templates:2001
msgid ""
"You can list multiple hosts and/or networks, separated by spaces. Hosts are "
"represented by their IP address, networks have to be in CIDR notation, e.g. "
"\"192.168.1.0/24\"."
msgstr ""
"Du kan lista ett flertal värdar och/eller nätverk, separerade med "
"mellanslag. Värdar representeras av deras IP-address, nätverk måste anges i "
"CIDR-notation, till exempel \"192.0.2.0/24\"."

#. Type: string
#. Description
#: ../distcc.templates:2001
msgid ""
"To change the list at a later point, you can run: 'dpkg-reconfigure distcc'."
msgstr ""
"Om du vill ändra listan vid en senare tidpunkt kan du köra: \"dpkg-"
"reconfigure distcc\"."

#. Type: string
#. Description
#: ../distcc.templates:3001
msgid "Listen interfaces:"
msgstr "Gränssnitt att lyssna på:"

#. Type: string
#. Description
#: ../distcc.templates:3001
msgid "The distcc daemon can be bound to a specific network interface."
msgstr "distcc-demonen kan knytas till ett särskilt nätverksgränssnitt."

#. Type: string
#. Description
#: ../distcc.templates:3001
msgid ""
"You probably want to choose the interface of your local network by entering "
"its IP address. If distccd should listen on all interfaces, just enter "
"nothing."
msgstr ""
"Du vill troligen använda ditt lokala nätverks gränssnitt genom att ange dess "
"IP-adress. Om distccd ska lyssna på alla gränssnitt, skriv inte in någonting."

#. Type: string
#. Description
#: ../distcc.templates:3001
msgid ""
"Be sure to protect distccd from unauthorized access, by being careful in "
"your choice of the listen interface and allowed networks. distccd should  "
"never be accessible from untrusted networks. If that is needed, secureshell "
"should be used instead of the daemon."
msgstr ""
"Se till att skydda distccd från obehörig åtkomst genom att vara noggrann i "
"valet av gränssnitt att lyssna på och tillåtna nätverk. distccd ska aldrig "
"kunna nås från opålitliga nätverk. Om det behövs, ska secureshell användas "
"istället för demonen."

#. Type: string
#. Description
#: ../distcc.templates:3001
msgid ""
"To change the address at a later point, you can run: 'dpkg-reconfigure "
"distcc'."
msgstr ""
"Om du vill ändra adressen vid en senare tidpunkt kan du köra: \"dpkg-"
"reconfigure distcc\"."

#. Type: string
#. Description
#: ../distcc.templates:4001
msgid "Nice level:"
msgstr "Prioritetsnivå för \"nice\":"

#. Type: string
#. Description
#: ../distcc.templates:4001
msgid ""
"You can start the distcc daemon with a nice level, to give it a low priority "
"compared to other process

Bug#1054616: [INTL:sv] Swedish strings for tzdata debconf

2023-10-26 Thread Martin Bagge / brother

package: tzdata
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother# Swedish translation of tzdata.
# Copyright: This file is in the public domain.
# This file is distributed under the same license as the tzdata package.
#
# Christer Andersson , 2008.
# Martin Bagge , 2008, 2011, 2013, 2021, 2023
# Luna Jernberg , 2023.
msgid ""
msgstr ""
"Project-Id-Version: sv\n"
"Report-Msgid-Bugs-To: tzd...@packages.debian.org\n"
"POT-Creation-Date: 2023-08-07 14:48+0200\n"
"PO-Revision-Date: 2023-10-26 22:34+0200\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: select
#. Choices
#. Note to translators:
#. - This is a continent or ocean (except for "Etc")
#. - "Etc" will present users with a list of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Africa"
msgstr "Afrika"

#. Type: select
#. Choices
#. Note to translators:
#. - This is a continent or ocean (except for "Etc")
#. - "Etc" will present users with a list of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "America"
msgstr "Amerika"

#. Type: select
#. Choices
#. Note to translators:
#. - This is a continent or ocean (except for "Etc")
#. - "Etc" will present users with a list of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Antarctica"
msgstr "Antarktis"

#. Type: select
#. Choices
#. Note to translators:
#. - This is a continent or ocean (except for "Etc")
#. - "Etc" will present users with a list of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Arctic"
msgstr "Norra Ishavet"

#. Type: select
#. Choices
#. Note to translators:
#. - This is a continent or ocean (except for "Etc")
#. - "Etc" will present users with a list of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Asia"
msgstr "Asien"

#. Type: select
#. Choices
#. Note to translators:
#. - This is a continent or ocean (except for "Etc")
#. - "Etc" will present users with a list of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Atlantic"
msgstr "Atlanten"

#. Type: select
#. Choices
#. Note to translators:
#. - This is a continent or ocean (except for "Etc")
#. - "Etc" will present users with a list of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Australia"
msgstr "Australien"

#. Type: select
#. Choices
#. Note to translators:
#. - This is a continent or ocean (except for "Etc")
#. - "Etc" will present users with a list of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Europe"
msgstr "Europa"

#. Type: select
#. Choices
#. Note to translators:
#. - This is a continent or ocean (except for "Etc")
#. - "Etc" will present users with a list of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Indian"
msgstr "Indiska Oceanen"

#. Type: select
#. Choices
#. Note to translators:
#. - This is a continent or ocean (except for "Etc")
#. - "Etc" will present users with a list of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Pacific"
msgstr "Stilla Havet"

#. Type: select
#. Choices
#. Note to translators:
#. - This is a continent or ocean (except for "Etc")
#. - "Etc" will present users with a list of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Etc"
msgstr "Etc"

#. Type: select
#. Description
#: ../tzdata.templates:1002
msgid "Geographic area:"
msgstr "Geografiskt område:"

#. Type: select
#. Description
#: ../tzdata.templates:1002
msgid ""
"Please select the geographic area in which you live. Subsequent "
"configuration questions will narrow this down by presenting a list of "
"cities, representing the time zones in which they are located."
msgstr ""
"Välj det geografiska område du bor i. Följande konfigurationsfrågor kommer "
"att begränsa detta genom att presentera en lista med städer, som "
"representerar de tidszoner i vilka de är placerade."

#. Type: select
#. Choices
#. Translators: This is a city name.
#. Do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Abidjan"
msgstr "Abidjan"

#. Type: select
#. Choices
#. Translators: This is a city name.
#. Do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Accra"
msgstr "Accra"

#. Type: select
#. Choices
#. Translators: This is a city name.
#. Do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Addis_Ababa"
msgstr "Addis Abeba"

#. Type: select
#. Choices
#. Translators: This is a city name.
#. Do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Algiers"
msgstr "Alger"

#. Type: select
#. Choices
#. Translators: This is a city name.
#. Do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Asmara"
msgstr "Asmara"

#. Type: select
#. Choices
#. Translators:

Bug#1054618: [INTL:sv] Swedish strings for openafs debconf

2023-10-26 Thread Martin Bagge / brother

package: openafs
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother# Translation of OpenAFS debconf template to Swedish
# Copyright (C) 2015, 2023 Martin Bagge 
# This file is distributed under the same license as the OpenAFS package.
#
# Martin Bagge , 2008, 2015, 2023
msgid ""
msgstr ""
"Project-Id-Version: openafs\n"
"Report-Msgid-Bugs-To: open...@packages.debian.org\n"
"POT-Creation-Date: 2017-07-10 15:27-0500\n"
"PO-Revision-Date: 2023-10-26 22:05+0200\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.7.3\n"

#. Type: string
#. Description
#: ../openafs-client.templates:1001
msgid "DB server host names for your home cell:"
msgstr "Värdnamn för DB-server för din hemmacell:"

#. Type: string
#. Description
#: ../openafs-client.templates:1001
msgid ""
"AFS uses the file /etc/openafs/CellServDB to hold the list of servers that "
"should be contacted to find parts of a cell.  The cell you claim this "
"workstation belongs to is not in that file.  Enter the host names of the "
"database servers separated by spaces. IMPORTANT: If you are creating a new "
"cell and this machine is to be a database server in that cell, only enter "
"this machine's name; add the other servers later after they are functioning. "
"Also, do not enable the AFS client to start at boot on this server until the "
"cell is configured.  When you are ready you can edit /etc/openafs/afs.conf."
"client to enable the client."
msgstr ""
"AFS använder filer /etc/openafs/CellServDB för att hålla reda på listan av "
"servrar som ska kontaktas för att hitta delar till en cell. Cellen du påstår "
"att den här arbetsstationen tillhör finns inte i den filen. Ange värdnamnet "
"på databasservrar, skilj med mellanslag. VIKTIGT: Om du håller på att skapa "
"en ny cell och denna maskinen ska agera databas för den cellen anger du bara "
"namnet på denna maskinen här. Lägg till de övriga servrarna när de är redo. "
"Du ska heller inte ange att AFS-klienten ska starta vid systemets uppstart "
"förrän cellen är helt konfigurerad. Redigera /etc/openafs/afs.conf.client "
"för att aktivera klienten."

#. Type: string
#. Description
#: ../openafs-client.templates:2001
msgid "AFS cell this workstation belongs to:"
msgstr "AFS-cell som denna arbetsstation tillhör:"

# altså. det här med "the domain namne of the site" är helt menlöst att översätta /brother 31/7-08
#. Type: string
#. Description
#: ../openafs-client.templates:2001
msgid ""
"AFS filespace is organized into cells or administrative domains. Each "
"workstation belongs to one cell.  Usually the cell is the DNS domain name of "
"the site."
msgstr ""
"Filsystemet i AFS är organiserat i celler eller administrativa domäner. "
"Varje arbetsstation tillhör en cell, cellnamnet är vanligen samma som "
"domännamnet."

#. Type: string
#. Description
#: ../openafs-client.templates:3001
msgid "Size of AFS cache in kB:"
msgstr "Storlek på AFS-cache i kB:"

#. Type: string
#. Description
#: ../openafs-client.templates:3001
msgid ""
"AFS uses an area of the disk to cache remote files for faster access.  This "
"cache will be mounted on /var/cache/openafs.  It is important that the cache "
"not overfill the partition it is located on.  Often, people find it useful "
"to dedicate a partition to their AFS cache."
msgstr ""
"AFS använder en del av disken för att mellanlagrar fjärrfiler för snabbare "
"tillgång. Denna mellanlagring kommer att monteras som /var/cache/openafs. "
"Det är viktigt att mellanlagringen inte tar större plats än partitionen som "
"den huserar på. Det är vanligt att ha en dedikerad partition för AFS "
"mellanlagring."

#. Type: boolean
#. Description
#: ../openafs-client.templates:4001
msgid "Run Openafs client now and at boot?"
msgstr "Starta Openafsklienten nu och vid varje uppstart?"

#. Type: boolean
#. Description
#: ../openafs-client.templates:4001
msgid ""
"Normally, most users who install the openafs-client package expect AFS to be "
"mounted automatically at boot.  However, if you are planning on setting up a "
"new cell or are on a laptop, you may not want it started at boot time.  If "
"you choose not to start AFS at boot, run service openafs-client force-start "
"to start the client when you wish to run it."
msgstr ""
"Vanligen monteras AFS automatiskt vid uppstart men om du håller på att sätta "
"upp en ny cell eller arbetar med en bärbar dator kan det vara en idé att "
"inte starta klienten automatiskt. Om du inte väljer att starta AFS vid "
"uppstart ska du köra service openafs-client force-start för att starta "
"klienten när du vill ha tillgång till den."

#. Type: boolean
#. Description
#: ../openafs-client.templates:5001
msgid "Look up AFS cells in DNS?"
msgstr "Slå upp AFS-celler i DNS?"

#. Type: boolean
#. Description
#: ../openafs-client.templates:5

Bug#1054617: [INTL:sv] Swedish strings for snort debconf

2023-10-26 Thread Martin Bagge / brother

package: snort
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother# Translation of snort debconf template to Swedish
# Copyright (C) 2013, 2023 Martin Bagge 
# This file is distributed under the same license as the snort package.
#
# Martin Bagge , 2008, 2013, 2023
msgid ""
msgstr ""
"Project-Id-Version: snort 2.3.3-1\n"
"Report-Msgid-Bugs-To: sn...@packages.debian.org\n"
"POT-Creation-Date: 2020-04-13 14:24+0200\n"
"PO-Revision-Date: 2023-10-26 22:26+0200\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"Language: Swedish\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.5.4\n"

#. Type: select
#. Choices
#: ../snort.templates:2001
msgid "boot"
msgstr "uppstart"

#. Type: select
#. Choices
#: ../snort.templates:2001
msgid "dialup"
msgstr "uppringt"

#. Type: select
#. Choices
#: ../snort.templates:2001
msgid "manual"
msgstr "manuell"

#. Type: select
#. Description
#: ../snort.templates:2002
msgid "Snort start method:"
msgstr "Hur ska Snort starta:"

#. Type: select
#. Description
#: ../snort.templates:2002
msgid ""
"Please choose how Snort should be started: automatically on boot, "
"automatically when connecting to the net with pppd, or manually with the /"
"usr/sbin/snort command."
msgstr ""
"Snort kan startas vid uppstart, när uppkoppling mot nätverk sker med pppd "
"eller manuellt med kommandot /usr/sbin/snort."

#. Type: string
#. Description
#: ../snort.templates:3001
msgid "Interface(s) which Snort should listen on:"
msgstr "På vilket/vilka gränssnitt ska Snort lyssna?"

#. Type: string
#. Description
#: ../snort.templates:3001
msgid ""
"This value is usually \"eth0\", but this may be inappropriate in some "
"network environments; for a dialup connection \"ppp0\" might be more "
"appropriate (see the output of \"/sbin/ifconfig\")."
msgstr ""
"Detta värde är oftast \"eth0\" men det kan vara fel i en del "
"nätverksmiljöer. För uppringd anslutning bör \"ppp0\" vara mer korrekt (se "
"vidare utdatat från \"/sbin/ifconfig\")."

#. Type: string
#. Description
#: ../snort.templates:3001
msgid ""
"Typically, this is the same interface as the \"default route\" is on. You "
"can determine which interface is used for this by running \"/sbin/route -"
"n\" (look for \"0.0.0.0\")."
msgstr ""
"Vanligen är detta samma gränssnitt som standardrutten är inställd på. Du kan "
"ta fram vilket gränssnitt som används för detta med kommandot \"/sbin/route -"
"n\" (leta efter \"0.0.0.0\")."

#. Type: string
#. Description
#: ../snort.templates:3001
msgid ""
"It is also not uncommon to use an interface with no IP address configured in "
"promiscuous mode. For such cases, select the interface in this system that "
"is physically connected to the network that should be inspected, enable "
"promiscuous mode later on and make sure that the network traffic is sent to "
"this interface (either connected to a \"port mirroring/spanning\" port in a "
"switch, to a hub, or to a tap)."
msgstr ""
"Det är inte helt ovanligt att köra Snort på ett gränssnitt utan IP-adress i "
"läget \"promiscuous\". Om det är det du vill, välj gränssnittet på detta "
"system som är fysiskt kopplad till nätverket du vill inspektera. Aktivera "
"promiscuousläget efter det och kontrollera att nätverkstrafiken skickas till "
"detta gränssnitt (antingen kopplade till en \"port mirror/spanning\"-port i "
"en switch, en hubb eller en nätverkstapp)"

#. Type: string
#. Description
#: ../snort.templates:3001
msgid ""
"You can configure multiple interfaces, just by adding more than one "
"interface name separated by spaces. Each interface can have its own specific "
"configuration."
msgstr ""
"Du kan konfigurera flera gränssnitt här, bara att lägga till fler än ett "
"gränssnittsnamn separerade med blanksteg. Varje gränssnitt kan ha sin egen "
"specifika konfiguration."

#. Type: string
#. Description
#: ../snort.templates:4001
msgid "Address range for the local network:"
msgstr "Ange adressintervallet som Snort ska lyssna på."

#. Type: string
#. Description
#: ../snort.templates:4001
msgid ""
"Please use the CIDR form - for example, 192.168.1.0/24 for a block of 256 "
"addresses or 192.168.1.42/32 for just one. Multiple values should be comma-"
"separated (without spaces)."
msgstr ""
"Du ska använda CIDR-formatet, till exempel 192.168.1.0/24 för ett block av "
"256 IP-adresser eller 192.168.1.42/32 för bara en av dem. Ange flera "
"adresser på samma rad separerade med \",\" (kommatecken), blanksteg är inte "
"tillåtna!"

#. Type: string
#. Description
#: ../snort.templates:4001
msgid ""
"You can leave this value empty and configure HOME_NET in /etc/snort/snort."
"conf instead. This is useful if you are using Snort in a system which "
"frequently changes network and does not have a static IP address assigned."
msgstr ""
"Detta värde kan lämnas tomt och istället kan HOME_NET anges i /etc/snort/"
"snort.

Bug#1054615: [INTL:sv] Swedish strings for tasksel debconf

2023-10-26 Thread Martin Bagge / brother

package: tasksel
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother# Translation of tasksel debconf template to Swedish
# Copyright (C) 2023 Martin Bagge 
# This file is distributed under the same license as the tasksel package.
#
# Daniel Nylander , 2006
# Martin Bagge , 2023
msgid ""
msgstr ""
"Project-Id-Version: tasksel 2.07 debconf\n"
"Report-Msgid-Bugs-To: task...@packages.debian.org\n"
"POT-Creation-Date: 2018-05-23 01:37+0200\n"
"PO-Revision-Date: 2023-10-26 22:30+0200\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../templates:1001 ../templates:2001
msgid "Choose software to install:"
msgstr "Välj programvara att installera:"

#. Type: multiselect
#. Description
#: ../templates:1001
msgid ""
"At the moment, only the core of the system is installed. To tune the system "
"to your needs, you can choose to install one or more of the following "
"predefined collections of software."
msgstr ""
"För närvarande är endast grunden av systemet installerat. För att anpassa "
"systemet efter dina behov kan du välja att installera en eller flera av "
"följande fördefinierade programvarusamlingar."

#. Type: multiselect
#. Description
#: ../templates:2001
msgid ""
"You can choose to install one or more of the following predefined "
"collections of software."
msgstr ""
"Du kan välja att installera en eller flera av följande fördefinierade "
"programvarusamlingar."

#. Type: multiselect
#. Description
#: ../templates:3001
msgid "This can be preseeded to override the default desktop."
msgstr ""
"Detta kan förkonfigureras för att ange annan skrivbordsmiljö som standard."

#. Type: title
#. Description
#: ../templates:4001
msgid "Software selection"
msgstr "Programvaruväljare"

#~ msgid "${ORIGCHOICES}"
#~ msgstr "${CHOICES}"

#~ msgid "${CHOICES}, manual package selection"
#~ msgstr "${CHOICES}, manuellt paketval"


Bug#1054614: [INTL:sv] Swedish strings for watchdog debconf

2023-10-26 Thread Martin Bagge / brother

package: watchdog
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother# translation of watchdog debconf template to Swedish
# Copyright (C) 2008, 2023 Martin Bagge 
# This file is distributed under the same license as the watchdog package.
#
# Martin Bagge , 2008, 2023.
msgid ""
msgstr ""
"Project-Id-Version: watchdog\n"
"Report-Msgid-Bugs-To: watch...@packages.debian.org\n"
"POT-Creation-Date: 2014-11-10 03:23+0100\n"
"PO-Revision-Date: 2023-10-26 22:37+0200\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: swedish \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: KBabel 1.11.4\n"

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Start watchdog at boot time?"
msgstr "Ska watchdog startas vid systemets uppstart?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Please specify whether watchdog should be started as part of the boot "
"process. This can be changed later by editing /etc/default/watchdog."
msgstr ""
"Ange om watchdog ska startas vid systemets uppstart. Detta kan ändras senare "
"genom att redigera /etc/default/watchdog."

#. Type: boolean
#. Description
#: ../templates:3001
msgid "Start wd_keepalive after stopping watchdog?"
msgstr "SKa wd_keepalice startas när watchdog stoppats?"

#. Type: boolean
#. Description
#: ../templates:3001
msgid ""
"Please specify whether stopping watchdog should start wd_keepalive to keep "
"on triggering the watchdog device. This can be changed later by editing /etc/"
"default/watchdog."
msgstr ""
"Ange om åtgärden att stoppa watchdog ska leda till att wd_keepalive startas "
"för att hålla igång watchdog-enheten. Detta kan ändras senare genom att "
"redigera /etc/default/watchdog."

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Restart watchdog on upgrades?"
msgstr "Ska watchdog startas om vid uppgraderingar?"

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"If the kernel is configured with the CONFIG_WATCHDOG_NOWAYOUT option (which "
"is not the default setting), restarting watchdog will cause a spurious "
"reboot (the kernel will assume that the watchdog daemon crashed)."
msgstr ""
"Om kärnan har alternativet CONFIG_WATCHDOG_NOWAYOUT aktiverat (vilket inte "
"är standard) så kan en omstart av watchdog initera en oönskad omstart av "
"systemet (eftersom kärnan i så fall kan anta att watchdog-tjönsten "
"kraschade)."

#. Type: string
#. Description
#: ../templates:5001
msgid "Watchdog module to preload:"
msgstr "Watchdog-moduler som ska förladdas:"

#. Type: string
#. Description
#: ../templates:5001
msgid ""
"Please choose which watchdog module should be preloaded before starting "
"watchdog. The 'softdog' module should be suited for all installations. Enter "
"'none' if you don't want the script to load a module."
msgstr ""
"Ange vilka watchdog-moduler som ska förladdas innan watchdog startas. "
"Modulen 'softdog' passar de flesta installationerna. Ange 'none' om du inte "
"vill att skriptet ska ladda någon modul."


Bug#1054613: bcachefs-tools: Please upload version 1.2

2023-10-26 Thread Daniel Gröber
Package: src:bcachefs-tools
Severity: wishlist

Hi Jonathan,

the bcachefs-tools version currently in unstable (0.)24-1 is almost a year
old. I see that you pushed packaging for (24~really)1.2-1 to git some weeks
ago, but it looks like you never uploaded the package?

I'd appreciate an upload :)

Thanks,
--Daniel

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

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

Versions of packages bcachefs-tools depends on:
ii  libaio1   0.3.113-5
ii  libblkid1 2.39.2-4
ii  libc6 2.37-12
ii  libkeyutils1  1.6.3-2
ii  liblz4-1  1.9.4-1
ii  libsodium23   1.0.18-1
ii  liburcu8  0.14.0-2
ii  libuuid1  2.39.2-4
ii  libzstd1  1.5.5+dfsg2-2
ii  zlib1g1:1.2.13.dfsg-3

Versions of packages bcachefs-tools recommends:
ii  initramfs-tools [linux-initramfs-tool]  0.142

bcachefs-tools suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#1054612: ITP: vim-autopair -- automatically open bracket pairs

2023-10-26 Thread Matthias Geiger
Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, team+...@tracker.debian.org, 
werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: vim-autopair
  Version : 4.0.1
  Upstream Contact: LunarWatcher 
* URL : https://github.com/LunarWatcher/auto-pairs
* License : MIT
  Programming Lang: vimscript
  Description : automatically open bracket pairs

Insert or delete brackets, parens, and quotes in pair: 
a maintained fork of https://github.com/jiangmiao/auto-pairs.
I believe this makes a nice addition to Debian. The package will be
maintained with the Vim team.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmU6x6IVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR18XwQAL/GkBclcTJ0PNViD2t4fzZhtpJy
lLIEaTAEjpM3zc9jlOu3acwXLzN2umObZpuPc11EjQOGSxhtqKe7Wex9wJLlXk+o
NOPMf0T+pTqg1W+8KQ6oiMpmT1AdkbRbSA5W0jRbmyyuxYCy+WLcpH/HmaS7FDXh
zlQ3WwMN0P2yF2WY1BjiovZ39mcurcJzbioUIglfAbr2cLJ8aarsiQSbENWF0cUg
ElukWbC1t7Yg8d8t4sXm50mSss2wqMsmaxk8pntwYAGGiNh4es/gR+gfqVmo/SUG
rOTLq5YxEu/MSuHmF4hTlWmm4Zs1puQ4tOZSt6Ye1cTGGMedEkfoWR9i7fiyU4dd
GQYap+uCiDJjhlcvBqriylL1CRxT2AGWXBlf3TG0x5GNLusLM+oxRMU2COojRnox
kP2zdv8Ur9kvDL5oyCBnvVz+JpgoNvQzvnR/waFYTinjt2dkR8KOgFcvuB6g7s+a
ir48kxuEVjFsjhdWFokvbHKavKJPntC4X/C2dxmA5Eq9qdj7drV/OMS3NtQGsmVX
PUpqi/et3tI4C+Gtq3j3PULJahcoZJvcIo/yYs237pTz9BLPIZY7twvc6PyP3fKL
T77QT3W+pmUvls43lFaNeWFEL63CY48iZSV6skTU8XzIX5jusun8fDPRHPhElD9p
4X/nMKbb6bB7T5cF
=vz26
-END PGP SIGNATURE-



Bug#1054585: phpmyadmin: no cleanup of tmp dir

2023-10-26 Thread William Desportes
Hi,

Are you really sure this files are php sessions?

This request raises doubts for me, I will need to check too.

They are twig cache files for sure, but yes they could be cleaned up before 
each upgrade.

--
William

Le 26 octobre 2023 13:29:43 GMT+02:00, Beowulf  a 
écrit :
>Package: phpmyadmin
>Version: 4:5.0.4+dfsg2-2+deb11u1
>Severity: important
>Tags: patch
>X-Debbugs-Cc: beow...@netzguerilla.net
>
>Dear Maintainer,
>
>/var/lib/phpmyadmin/tmp/ is created by the installer, php session files are 
>created in there and never cleaned up.
>
>It would be best to have a cronjob cleaning up old session files, like it is 
>done in roundcubemail:
>https://salsa.debian.org/roundcube-team/roundcube/-/blob/debian/bullseye/debian/roundcube-core.cron.daily
>
>Best regards
>Florian Müller



Bug#1054610: src:nvme-stas: fails to migrate to testing for too long: autopkgtest regression

2023-10-26 Thread Paul Gevers

Source: nvme-stas
Version: 2.2.2-2
Severity: serious
Control: close -1 2.3-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1054533

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:nvme-stas has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable fails 
its own autopkgtest as reported in bug 1054533.


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1054609: src:python-django: fails to migrate to testing for too long: sort of transition

2023-10-26 Thread Paul Gevers

Source: python-django
Version: 3:3.2.21-1
Severity: serious
Control: close -1 3:4.2.6-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:python-django has been trying to migrate 
for 31 days [2]. Hence, I am filing this bug. The version in unstable 
causes autopkgtest failes in quite some packages as well as making 
several packages non-installable as they have a versioned (build) 
dependency. For some of them, there's no bug report yet notifying the 
maintainers.


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1039082: [jeroen/jsonlite] Please enable usage of system yajl library (Issue #430)

2023-10-26 Thread Andreas Tille
Control: tags -1 wontfix

As upstream explained this bug is not likely to be fixed.  That's why it is set 
to wontfix.

Kind regards
 Andreas.

- Weitergeleitete Nachricht von Jeroen Ooms  -

Date: Thu, 26 Oct 2023 11:35:34 -0700
From: Jeroen Ooms 
To: jeroen/jsonlite 
Cc: Andreas Tille , Author 
Subject: Re: [jeroen/jsonlite] Please enable usage of system yajl library 
(Issue #430)

Hi,

As I'm pretty sure I indicated earlier, upstream libyajl is unmaintained and we 
use a modified fork of the libyajl code. Therefore it is not possible to use 
Debian's libyajl.

The best I can offer is rename our bundled fork to something else, such that it 
is clear that this is a different library now.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/jeroen/jsonlite/issues/430#issuecomment-1781656207
You are receiving this because you authored the thread.

Message ID: 

-- 
http://fam-tille.de



Bug#969177: debmake: cannot create deb for nodejs modeule

2023-10-26 Thread Nilesh Patra
Control: tags -1 patch

On Thu, 26 Oct 2023 23:25:00 +0530 Akshay S Dinesh  wrote:
> On Thu, 14 Jul 2022 16:37:52 +0200 Pirate Praveen 
>  wrote:
> > Control: reopen -1
> > Control: notfixed 4.4.0-1
> > 
> > On Thu, 14 Jul 2022 10:54:14 +0200 Pirate Praveen
> >  wrote:
> > > Control: fixed -1 4.4.0-1
> > > 
> > > Looks like it is fixed in current version, closing this bug. Thanks!
> > 
> > Seems like I was mistaken, tried on a fresh clean chroot and it still
> > fails.
> > 
> > 
> 
> 
> There's this commit referencing 4.4.0-1 on June 25, 2021 
> https://salsa.debian.org/debian/debmake/-/commit/c59f0dbc112c5aaa737e0afdacbcc193e5e17dea
> 
> And this commit which fixes the bug on June 26, 2021 
> https://salsa.debian.org/debian/debmake/-/commit/7f6c310aff8bf13eb64b98aff14e5e0b2bd58301
> 
> And this commit on May 6, 2022 which talks about 4.4.0
> https://salsa.debian.org/debian/debmake/-/commit/07b1e07a9d9d327778d535287fdc70ac05dbe9e4
> 
> I'm unsure what's what.

It sure has been committed, and it is also present in the source package
in the archive too. Seems to me that the uploader uploaded this on May
6, 2022 but did not edit the date as can be confirmed from the
upload entry as well.


https://tracker.debian.org/news/1323132/accepted-debmake-440-1-source-into-unstable/

> https://packages.debian.org/sid/all/debmake/filelist is missing 
> /usr/share/debmake/extra0desc_long/nodejs

Right that's because the changes in the commit are incomplete to fix this bug,
since the nodejs extradesc file is never installed because it has its entry
missing from setup.cfg.

I've attached a (one-line) patch at the end of the mail to fix this up properly.

> In any case, a workaround is to do
> 
> echo " This package contains the nodejs program." | sudo tee 
> /usr/share/debmake/extra0desc_long/nodejs


I was surprised to know that debmake tries to take the "type" field of
the package from the directory name itself. So another workaround (this
one is admittedly stupid) is:

| $ mv node-pretty-ms-8.0.0 pretty-ms-8.0.0
| $ cd pretty-ms-8.0.0
| $ debmake
| $ cd ..
| $ mv pretty-ms-8.0.0 node-pretty-ms-8.0.0

Though after this it'd take some effort to edit source package name.

Best,
Nilesh


diff --git a/setup.cfg b/setup.cfg
index 57235a5..b19b18c 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -54,6 +54,7 @@ console_scripts =
src/extra0desc_long/dev
src/extra0desc_long/doc
src/extra0desc_long/lib
+   src/extra0desc_long/nodejs
src/extra0desc_long/perl
src/extra0desc_long/python
src/extra0desc_long/python3


signature.asc
Description: PGP signature


Bug#1054280: mirror submission for mirror.hoobly.com

2023-10-26 Thread Adam D. Barratt
Control: tags -1 + moreinfo

On Fri, 2023-10-20 at 13:17 +, Peter Grigor wrote:
> Submission-Type: new
> Site: mirror.hoobly.com
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-
> amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x
> Archive-http: /debian/
> Maintainer: Peter Grigor 
> Country: US United States
> Sponsor: Hoobly Classifieds https://www.hoobly.com
> 

Although I can see you've mentioned them above, your trace file at 
http://mirror.hoobly.com/debian/project/trace/mirror.hoobly.com doesn't
contain either the Maintainer or Sponsor fields, which our tooling
exists to find there.

The location of the server is also a little unclear - your submission
says US, but the IP address claims to be GoDaddy Germany.

Regards,

Adam



Bug#1054608: tt-rss: New entries always marked as read even if the unread counter is not null

2023-10-26 Thread Antoine EMERIT
Package: tt-rss
Version: 21~git20210204.b4cbc79+dfsg-1.2
Severity: normal
Tags: patch

Dear Maintainer,

After a dist-upgrade my server from Debien 11 to Debian 12, my Tiny Tiny RSS 
server diplays
all new entries as already ridden. The unread counters are not impacted.

To reproduce : 
- access to new unread entries in any categories (or in "Unread Articles"), 
unread entries
  are well displayed but the title text is greyed.
- the unread filter is well applied and the unread counters count theses 
entries.
- manually mark an entry as unread -> counter doens't change (this is correct)
- manually mark an entry as read -> counter is correctly decreased (this is 
correct)

After a search in the javascript, I see that the entry JSON attribut returned 
by the
backend.php is always "unread: 0".

In the class/feeds.php at line 258, I see a specific code that check the unread 
database
value and retest it in case of mysql :

if (DB_TYPE == "mysql") {
   foreach (["unread", "marked", "published"] as $k) {
  $line[$k] = $line[$k] === "1";
   }
}

I suspect a change in the MariaDB upgrade that cause this problem.

I propose the following simple modification :
diff classes/feeds.php classes/feeds.php.old
258c258
<   $line[$k] = $line[$k]  === 1 || 
$line[$k] === "1";
---
>   $line[$k] = $line[$k] === "1";

Regards


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

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

Versions of packages tt-rss depends on:
ii  dbconfig-common   2.0.24
ii  dbconfig-pgsql2.0.24
ii  debconf [debconf-2.0] 1.5.82
ii  fonts-material-design-icons-iconfont  6.7.0+dfsg-1
ii  init-system-helpers   1.65.2
ii  libapache2-mod-php2:8.2+93
ii  libapache2-mod-php8.2 [php-json]  8.2.7-1~deb12u1
ii  libjs-dojo-core   1.17.2+dfsg1-2.1
ii  libjs-dojo-dijit  1.17.2+dfsg1-2.1
ii  libjs-scriptaculous   1.9.0-3
ii  lsb-base  11.6
ii  php   2:8.2+93
ii  php-cli   2:8.2+93
ii  php-intl  2:8.2+93
ii  php-json  2:8.2+93
ii  php-mbstring  2:8.2+93
ii  php-mysql 2:8.2+93
ii  php-php-gettext   1.0.12-5
ii  php-psr-log   1.1.4-2
ii  php-xml   2:8.2+93
ii  php8.2 [php]  8.2.7-1~deb12u1
ii  php8.2-cli [php-json] 8.2.7-1~deb12u1
ii  php8.2-intl [php-intl]8.2.7-1~deb12u1
ii  php8.2-mbstring [php-mbstring]8.2.7-1~deb12u1
ii  php8.2-phpdbg [php-json]  8.2.7-1~deb12u1
ii  php8.2-xml [php-xml]  8.2.7-1~deb12u1
ii  phpqrcode 1.1.4-3.1
ii  sysvinit-utils [lsb-base] 3.06-4

Versions of packages tt-rss recommends:
ii  apache2 [httpd] 2.4.57-2
ii  ca-certificates 20230311
ii  php-curl2:8.2+93
ii  php-gd  2:8.2+93
pn  php-mcrypt  
ii  php8.2-curl [php-curl]  8.2.7-1~deb12u1
ii  php8.2-gd [php-gd]  8.2.7-1~deb12u1

Versions of packages tt-rss suggests:
pn  php-apc   
pn  sphinxsearch  

-- Configuration Files:
/etc/tt-rss/config.php changed [not included]

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/share/tt-rss/www/classes/feeds.php (from tt-rss 
package)
debsums: changed file /usr/share/tt-rss/www/include/errorhandler.php (from 
tt-rss package)



Bug#1029801: tbox: reproducible builds: timestamp embedded in tbox.config.h

2023-10-26 Thread Vagrant Cascadian
Control: fixed 1029801 1.7.4-1

On 2023-10-26, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:tbox package:
>
> #1029801: tbox: reproducible builds: timestamp embedded in tbox.config.h
>
> It has been closed by Lin Qigang .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Lin Qigang 
>  by
> replying to this email.
>
>
> -- 
> 1029801: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029801
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> From: Lin Qigang 
> Subject: tbox: reproducible builds: timestamp embedded in tbox.config.h
> To: 1029801-d...@bugs.debian.org
> Date: Thu, 26 Oct 2023 19:53:53 +0700
>
> Thank you, this patch was applied upstream [1].
>
> [1] https://github.com/tboox/tbox/pull/219
>
> -- 
> Lance Lin
> GPG Fingerprint: 4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7
> From: Vagrant Cascadian 
> Subject: tbox: reproducible builds: timestamp embedded in tbox.config.h
> To: sub...@bugs.debian.org
> Date: Fri, 27 Jan 2023 14:57:29 -0800
>
> Source: tbox
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> The build time is embedded in /usr/include/tbox/tbox.config.h:
>
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/tbox.html
>
>   /usr/include/tbox/tbox.config.h
>
>   #define·TB_CONFIG_VERSION_BUILD·20240228
>   vs.
>   #define·TB_CONFIG_VERSION_BUILD·20230127
>
> The attached patch to configure fixes this by calling date with
> arguments to ensure a deterministic timestamp, falling back to the
> default behavior.
>
> According to my local tests, with this patch applied, tbox should
> build reproducibly on tests.reproducible-builds.org!
>
> Thanks for maintaining tbox!
>
> live well,
>   vagrant
> From 83994f9a353d7ebb0c61cf426aeaa033a5042a07 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Fri, 27 Jan 2023 22:42:17 +
> Subject: [PATCH] configure: Use determistic timestamp from SOURCE_DATE_EPOCH
>  if available.
>
> This supports multiple date implementations, falling back to the
> current behavior on failure.
> ---
>  configure | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index a0f42ae..9c9163a 100755
> --- a/configure
> +++ b/configure
> @@ -253,8 +253,10 @@ _os_find() {
>  }
>  
>  # get date, "%Y%m%d%H%M" -> 20221207
> +# Use deterministic timestamp from SOURCE_DATE_EPOCH if available
> +# https://reproducible-builds.org/docs/source-date-epoch/
>  _os_date() {
> -_ret=$(date +"${1}")
> +_ret=$(date -u -d "@$SOURCE_DATE_EPOCH" +"${1}" || date -u -r 
> "$SOURCE_DATE_EPOCH" +"${1}" || date +"${1}")
>  }
>  
>  # we avoid use `basename`, because it's slow
> -- 
> 2.39.1



Bug#1051939: ubpm_1.9.0+20230923-1_amd64.changes REJECTED

2023-10-26 Thread Thorsten Alteholz

Hi Steve,

On 26.10.23 05:23, Steven Robbins wrote:

On Monday, October 23, 2023 1:00:09 P.M. CDT Thorsten Alteholz wrote:

Hi,

please ask upstream to add all licenses of embedded stuff like
./sources/plugins/shared/hidapi

Could you expand on this request?  Each file notes "At the discretion of the
user of this library,  this software may be licensed under the terms of the
GNU General Public License v3, a BSD-Style license, ..."


yes, but the sentence goes on: "..., or the original HIDAPI license as 
outlined in the LICENSE.txt,

LICENSE-gpl3.txt, LICENSE-bsd.txt, and LICENSE-orig.txt"

The GPL is ok, but the BSD-Style license is not at all unambiguous and 
what is the contents of LICENSE.txt and LICENSE-orig.txt?
They should be "located at the root of the source distribution.", but 
they are not, hence my request.




   The debian/copyright
specifies GPL-3:

 Files: sources/plugins/shared/hidapi/*
 Copyright: 2022, 2023 libusb/hidapi Team
 License: GPL-3


Yes but this is just a part of the license, at least the "... or BSD-3" 
is missing. According to Debian policy 12.5 a "verbatim copy of its 
distribution license(s)" need to appear in your debian/copyright.




Sorry, that is a clear miss on my part.  I will clarify the license or remove
these before re-uploading.


Ok, great, thanks a lot.

  Thorsten


Bug#969177: debmake: cannot create deb for nodejs modeule

2023-10-26 Thread Akshay S Dinesh
On Thu, 14 Jul 2022 16:37:52 +0200 Pirate Praveen 
 wrote:

Control: reopen -1
Control: notfixed 4.4.0-1

On Thu, 14 Jul 2022 10:54:14 +0200 Pirate Praveen
 wrote:
> Control: fixed -1 4.4.0-1
> 
> Looks like it is fixed in current version, closing this bug. Thanks!


Seems like I was mistaken, tried on a fresh clean chroot and it still
fails.





There's this commit referencing 4.4.0-1 on June 25, 2021 
https://salsa.debian.org/debian/debmake/-/commit/c59f0dbc112c5aaa737e0afdacbcc193e5e17dea


And this commit which fixes the bug on June 26, 2021 
https://salsa.debian.org/debian/debmake/-/commit/7f6c310aff8bf13eb64b98aff14e5e0b2bd58301


And this commit on May 6, 2022 which talks about 4.4.0
https://salsa.debian.org/debian/debmake/-/commit/07b1e07a9d9d327778d535287fdc70ac05dbe9e4



I'm unsure what's what.

https://packages.debian.org/sid/all/debmake/filelist is missing 
/usr/share/debmake/extra0desc_long/nodejs



In any case, a workaround is to do

echo " This package contains the nodejs program." | sudo tee 
/usr/share/debmake/extra0desc_long/nodejs




Bug#1042947: UDD: create a duck importer

2023-10-26 Thread Baptiste Beauplat
Hi Lucas,

On Wed, 2023-10-25 at 20:57 +0200, Lucas Nussbaum wrote:
> On 08/08/23 at 06:42 +0200, Lucas Nussbaum wrote:
> > Hi Baptiste,
> > 
> > On 07/08/23 at 22:07 +0200, Baptiste Beauplat wrote:
> > > Hi Lucas,
> > > 
> > > On 2023-08-03 10:30, Lucas Nussbaum wrote:
> > > > duck-as-a-service (duck.debian.net) has been broken for a long
> > > > time,
> > > > and
> > > > the corresponding UDD importer is broken as well (see #949009,
> > > > #963887).
> > > > In the meantime, duck continued evolving (was rewritten?) and
> > > > is now
> > > > checking a lot more places for URLs.
> > > > 
> > > > It would probably be useful to re-create a way to provide duck
> > > > results
> > > > as a service, based on UDD, similarly to what is done for
> > > > upstream or
> > > > lintian data.
> > > > 
> > > > Ideally, this would be done in cooperation with the duck
> > > > maintainer
> > > > to
> > > > do the following changes:
> > > > - in duck, separate the logic to get URLs from sources, from
> > > > the
> > > > logic
> > > >   to check those URLs (for example, allow dumping a list of
> > > > URLs, and
> > > >   also using a list of URLs as source)
> > > > - in duck, provide machine-readable outputs (JSON?)
> > > 
> > > Currently duck has two features which can help us:
> > > 
> > > - The `-n` switch, which gets all URLs and prints them to stdout
> > > - The `-l filename` switch, which takes a file with one URL per
> > > line
> > > and checks them
> > > 
> > > Theoretically, what's missing in only a `--json` switch, which
> > > would
> > > change the output from console/text to JSON.
> > > 
> > > But, as I see it, the `-l` argument is limited in two aspects:
> > > 
> > > - It provides only the URL, loosing the checker type which is
> > > used to
> > > select what kind of validation will be performed.
> > > 
> > >   For instance, a https://salsa.debian.org/rfrancoise/tmux.git of
> > > type
> > > VCS-Git would be tested as a standard URL in the `-l` context,
> > > instead
> > > of a git repository.
> > > 
> > > - It requires a file
> > > 
> > > I'm thinking of implementing a new JSON specific input format
> > > (`--input-json`?), including the two information, which would
> > > read from
> > > stdout instead of a file.
> > > 
> > > The format would be as simple as:
> > > 
> > > ```json
> > > [
> > >    {"type": "VCS-Git",
> > >     "url": "https://salsa.debian.org/rfrancoise/tmux.git";,
> > >     "filename": "debian/control",  # optional key
> > >     "line_number": 10},    # optional key
> > >    ...
> > > ]
> > > ```
> > > 
> > > Following this logic, the output format for checking URLs would
> > > be the
> > > same, as to have `duck --json -n | duck --input-json` working.
> > > 
> > > The JSON result would hold an additional dictionary for each URL
> > > entries
> > > named "result", described as follows:
> > > 
> > > ```json
> > > [
> > >    {"type": "VCS-Git",
> > >     "url": "https://salsa.debian.org/rfrancoise/tmux.git";,
> > >     "filename": "debian/control",  # optional key
> > >     "line_number": 10, # optional key
> > >     "result": {
> > >    "state": 0,  # 0 for OK, 1 for Error, 2 for Information
> > >    "detail": "Informative message",
> > >    "certainty": "possible" # optional key
> > >    }},
> > >    ...
> > > ]
> > > ```
> > > 
> > > Let me know what you think of it.
> > 
> > That would be perfect!
> > 
> > In the context of UDD, I will probably implement that as two
> > tables:
> > - one to store the mapping between source packages and urls
> >   (source, version, url, type, filename, line_number)
> >   which would be updated when a new source version gets uploaded
> > - one to store the status of urls
> >   (url, type, result, timestamp of last check)
> >   which would be updated with a retry policy to be defined
> > 
> > I would not use (filename, line_number) in the input of the URL
> > testing part.
> > The reason for that design is that it will easily allow to gather
> > the
> > status for several versions of the package (testing + unstable +
> > experimental for example), while not duplicating the checks for
> > URLs.
> 
> Just checking: did you make progress on this?

Sort of.

I could not see a clean way to add this feature without a total rewrite
of duck. So that's what I've started, and I'm making steady progress on
that front.

However, I have not started working on the json interface
implementation just yet.

I'll keep you posted once I have a working version of that.

Best,
-- 
Baptiste Beauplat



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


Bug#1054459: debian-installer: Debian 12.2 amd64 netinst failes to find a kernel image for a Dell 7812

2023-10-26 Thread David Henderson
cc:d...@caltech.edu, st...@einval.com

Hi Steve,

The Supermicro system that created the netinst flash drive image is a xeon
with ecc;   its  root filesystem system is a btrfs raid1 mirror pair.

I did not verify the checksum of the  netinst image after copying to flash.
My bad because recreating the image on the Supermicro resulted in the
install now running to completion on the Dell 7812.

I created about 4 installs to different partition sets to try and reproduce
the bug to generate a log file with the failure. None of them failed.

this bugreport should be closed as 'unable to reproduce'

I regret the erroneous bugreport and will use the experience to check more
carefully in the future.

David
On 10/24/23 05:46, Steve McIntyre wrote:

Hi David,

On Mon, Oct 23, 2023 at 10:02:44PM -0700, David George Henderson III wrote:

Package: debian-installer
Version: debian installer found on amd64 12.2 netinst.iso
Severity: important

Dear Maintainer,

I have several systems and have experienced this difficulty only with the
Dell 7812 with an Xeon E5 CPU.

The debian 12.2.0 amd64 netinst.iso boots normally and seems to start
normally.
When it gets to finding a kernel to install, it complains that it cannot
find a suitable kernel.

I had the same results with debian 12.2 adm64 dvd-1.iso and dlbd-1.iso

That's very odd. I can't reproduce this here in simple testing in a
VM, and there shouldn't be anything system-specific here.

Could you please test again and grab the installer syslog for us?
That'll help us to see what's going wrong here.


 When I booted the debian 12.2 amd64 live.iso system, its installer ran OK.
I am running on the system installed from the live installer right now. This
is what made the lspci.

I also successfully managed to perform a dist-upgrade from an install of
debian 11.6.


Bug#1054607: btrfs-progs: btrfs prop set causing system to reboot

2023-10-26 Thread axet
Package: btrfs-progs
Version: 6.2-1
Severity: normal

Dear Maintainer,

sudo find "/dev/snd" -exec btrfs prop set {} compression zstd \;

Causing stuck on /dev/snd/pcmC1D0p file and insta reboots in 5 mins.

ls -al /dev/snd/pcmC1D0p
crw-rw+ 1 root audio 116, 5 окт 26 19:37 /dev/snd/pcmC1D0p


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

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

Versions of packages btrfs-progs depends on:
ii  libblkid12.38.1-5+b1
ii  libc62.36-9+deb12u2
ii  libcom-err2  1.47.0-2
ii  libext2fs2   1.47.0-2
ii  liblzo2-22.10-2
ii  libudev1 252.17-1~deb12u1
ii  libuuid1 2.38.1-5+b1
ii  libzstd1 1.5.4+dfsg2-5
ii  zlib1g   1:1.2.13.dfsg-1

btrfs-progs recommends no packages.

Versions of packages btrfs-progs suggests:
ii  duperemove  0.11.2-3

-- debconf-show failed


Bug#1054606: libcap2-bin: Move /sbin/getcap to /bin

2023-10-26 Thread Peter Samuelson
Package: libcap2-bin
Version: 1:2.66-4
Severity: wishlist

In my opinion, getcap(8) is useful to run as a non-root user, so it
should be in /bin rather than /sbin.  This seems analogous to ip(8)
from iproute2, which was moved to /bin many years ago.

Thanks,
Peter



Bug#1054552: glibc: stat fails when access time is bogus

2023-10-26 Thread Aurelien Jarno
control: reassign -1 dpkg
control: retitle -1 dpkg: stat fails on 32-bit systems when access time is bogus

Hi,

On 2023-10-25 23:29, Simon McVittie wrote:
> Control: reassign -1 libc6
> 
> On Wed, 25 Oct 2023 at 20:53:57 +0200, Jarek Czekalski wrote:
> > I tried to upgrade system (apt-get upgrade), but it failed in dpkg:
> > 
> > Unpacking initscripts (3.06-4) over (2.96-7+deb11u1) ...
> > dpkg: error processing archive
> > /var/cache/apt/archives/initscripts_3.06-4_all.deb (--unpack):
> >  unable to stat './var/log' (which was about to be installed): Value too
> > large for defined data type
> 
> This is nothing to do with GLib (libglib2.0-0), but I assume you meant
> glibc (libc6)? Quoting the rest of the bug report below for glibc
> maintainers:
> 
> > stat /var/log
> > 
> >   File: /var/log
> >   Size: 4096    Blocks: 8  IO Block: 4096 directory
> > Device: 8,1 Inode: 2752691 Links: 12
> > Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/ root)
> > Access: 2040-05-10 23:31:40.285032309 +0200
> > Modify: 2023-10-25 16:03:42.313742411 +0200
> > Change: 2023-10-25 16:03:42.313742411 +0200
> >  Birth: 2017-02-27 09:46:56.739719147 +0100
> > 
> > This date (2040) causes dpkg to fail. The workaround is correcting it by
> > touch /var/log.
> > 
> > Running system with bogus date (2040).
> >    * What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > touch /var/log
> >    * What was the outcome of this action?
> > dpkg started working
> >    * What outcome did you expect instead?
> > dpkg should work with strange date or give a better message. Maybe just
> > documentation (for stat) should be fixed and suggest problems with dates.
> > 
> > Current outcome is as follows: apt-get suddenly fails with a cryptic message
> > (initially it was "unable to stat '.'" instead of /var/log). It may be
> > extremely difficult to diagnose the issue.
> 
> It is not possible for 32-bit stat() to work correctly on 32-bit systems
> with dates beyond 2038, because the timestamp will not fit in the data
> type used. The only solution would be for the program in question (in
> this case, dpkg) to be compiled with support for 64-bit timestamps.

I agree with the explanation.

> Your bug report seems to be from an upgrade from Debian 11 to Debian 12,
> and Debian 11's glibc version did not support APIs that provide 64-bit
> timestamps on 32-bit systems, so Debian 11's dpkg cannot support that
> either.
> 
> Debian 12's glibc does, but that will only help you after fully upgrading
> to Debian 12, at which point you will have Debian 12 versions of glibc
> and dpkg.

Yes, and that also means there is nothing that can be done on the glibc
side as the API is already provided started with Debian 12.

> Unfortunately, I don't think there's necessarily anything that can be done
> here, beyond the general move towards supporting 64-bit timestamps
> distribution-wide that is already in progress.

The other alternative is to add support at the dpkg level, just like it
is already the case for some packages like coreutils. I am therefore
reassigning the bug to dpkg, but I fully understand if it get tagged as
wontfix until 64-bit timestamps are supported at the distribution-wide
level.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net



Bug#1052863: krb5: FTBFS: dh_auto_test: error: cd build && make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2

2023-10-26 Thread Lucas Nussbaum
On 26/10/23 at 07:45 -0600, Sam Hartman wrote:
> > "Lucas" == Lucas Nussbaum  writes:
> Lucas> Hi,
> 
> Lucas> As an additional data point, I can still reproduce this
> Lucas> failure.
> 
> So, my understanding is that so far for you it always fails, and the
> evidence so far suggests that it generally (or always, but I am not sure
> we have long enough evidence for that) succeeds on the builds.
> 
> What is your environment like?
> Chroot? Container?  If any namespaces are involved, how do you build the
> namespaces, and what  non-default capability settings do you have on top
> of the defaults of containerization software you use.

It's a standard sbuild setup, on an AWS EC2 VM.

Here is a more verbose output:
/tmp/krb5-1.20.1/build/lib/krb5/ccache# PYTHONPATH=/tmp/krb5-1.20.1/src/util 
/usr/bin/python3 ../../../../src/lib/krb5/ccache/t_cccol.py -v
*** [1] Executing: /tmp/krb5-1.20.1/build/clients/klist/klist -c 
KEYRING:process:abcd
klist: Credentials cache keyring 'process:abcd:abcd' not found
*** [1] Completed with return code 1
*** [2] Executing: ./t_cccol 
DIR:/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir/cc
*** [2] Completed with return code 0
*** [3] Executing: keyctl list @s
1 key in keyring:
862920460: --alswrv 0 65534 keyring: _uid.0
*** [3] Completed with return code 0
*** [4] Executing: keyctl list @s
1 key in keyring:
862920460: --alswrv 0 65534 keyring: _uid.0
*** [4] Completed with return code 0
*** [5] Executing: keyctl list @u
keyring is empty
*** [5] Completed with return code 0
*** [6] Executing: ./t_cccol 
KEYRING:/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir
*** [6] Completed with return code 0
*** [7] Executing: keyctl list @s
2 keys in keyring:
862920460: --alswrv 0 65534 keyring: _uid.0
924062711: --alswrv 0 0 keyring: 
_krb_/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir
*** [7] Completed with return code 0
*** [8] Executing: keyctl search @s keyring 
_krb_/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir
924062711
*** [8] Completed with return code 0
*** [9] Executing: keyctl unlink 924062711 @s
*** [9] Completed with return code 0
*** [10] Executing: ./t_cccol 
KEYRING:legacy:/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir
*** [10] Completed with return code 0
*** [11] Executing: keyctl list @s
2 keys in keyring:
862920460: --alswrv 0 65534 keyring: _uid.0
554948115: --alswrv 0 0 keyring: 
_krb_/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir
*** [11] Completed with return code 0
*** [12] Executing: keyctl search @s keyring 
_krb_/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir
554948115
*** [12] Completed with return code 0
*** [13] Executing: keyctl unlink 554948115 @s
*** [13] Completed with return code 0
*** [14] Executing: ./t_cccol 
KEYRING:session:/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir
*** [14] Completed with return code 0
*** [15] Executing: keyctl list @s
2 keys in keyring:
862920460: --alswrv 0 65534 keyring: _uid.0
1042415883: --alswrv 0 0 keyring: 
_krb_/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir
*** [15] Completed with return code 0
*** [16] Executing: keyctl search @s keyring 
_krb_/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir
1042415883
*** [16] Completed with return code 0
*** [17] Executing: keyctl unlink 1042415883 @s
*** [17] Completed with return code 0
*** [18] Executing: ./t_cccol 
KEYRING:user:/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir
*** [18] Completed with return code 0
*** [19] Executing: keyctl list @u
1 key in keyring:
 80739909: --alswrv 0 0 keyring: 
_krb_/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir
*** [19] Completed with return code 0
*** [20] Executing: keyctl search @u keyring 
_krb_/tmp/krb5-1.20.1/build/lib/krb5/ccache/testdir
80739909
*** [20] Completed with return code 0
*** [21] Executing: keyctl unlink 80739909 @u
*** [21] Completed with return code 0
*** [22] Executing: ./t_cccol KEYRING:process:abcd
*** [22] Completed with return code 0
*** [23] Executing: ./t_cccol KEYRING:thread:abcd
*** [23] Completed with return code 0
*** [24] Executing: /tmp/krb5-1.20.1/build/kadmin/dbutil/kdb5_util create -s -P 
master
Initializing database '/var/lib/krb5kdc/principal' for realm 'KRBTEST.COM',
master key name 'K/m...@krbtest.com'
*** [24] Completed with return code 0
*** [25] Executing: /tmp/krb5-1.20.1/build/kadmin/cli/kadmin.local addprinc -pw 
user119606 u...@krbtest.com
*** [25] Completed with return code 0
*** [26] Executing: /tmp/krb5-1.20.1/build/kadmin/cli/kadmin.local addprinc -pw 
admin119606 user/ad...@krbtest.com
*** [26] Completed with return code 0
*** [27] Starting: /tmp/krb5-1.20.1/build/kdc/krb5kdc -n
krb5kdc: starting...
*** [27] Started with pid 119633
*** [28] Executing: /tmp/krb5-1.20.1/build/clients/kinit/kinit u...@krbtest.com
kinit: Cannot contact any KDC for realm 'KRBTEST.COM' while getting initial 
credentials
*** [28] Completed with return code 1
*** Failure: /tmp/krb5-1.20.1/build/clients/kinit/kinit failed with code 1.
*** Last command (#

Bug#1054605: borgmatic: Systemd service ignores /etc/borgmatic.d/ when deciding whether to run

2023-10-26 Thread Martina Ferrari
Package: borgmatic
Version: 1.7.7-1
Severity: normal
X-Debbugs-Cc: t...@debian.org

Hi,

Today I realised that a borgmatic setup was not performing daily backups,
despite not receiving any errors. Upon inspection, I noticed the
borgmatic.service file has the following option:

ConditionFileNotEmpty=/etc/borgmatic/config.yaml

Since I have multiple backup configurations, I created separate files in
/etc/borgmatic.d/, as recommended in the official documentation[1]. This means
the backup is never launched automatically.

This is not documented anywhere, and I am not even sure what would be the
workaround, except removing the service option.

[1]: https://torsion.org/borgmatic/docs/how-to/make-per-application-backups/

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable'), (50, 'unstable'), (49, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 borgmatic depends on:
ii  borgbackup 1.2.4-1
ii  python33.11.2-1+b1
ii  python3-colorama   0.4.6-2
ii  python3-jsonschema 4.10.3-1
ii  python3-pkg-resources  66.1.1-1
ii  python3-requests   2.28.1+dfsg-1
ii  python3-ruamel.yaml0.17.21-1

borgmatic recommends no packages.

borgmatic suggests no packages.

-- no debconf information



Bug#1054494: RFS: lsp-mode/8.0.0-6 [ITA] [RC] -- Emacs client/library for the Language Server Protocol

2023-10-26 Thread Xiyue Deng
Hi Bo,

Bo YU  writes:

> Hi!
>
> On Thu, Oct 26, 2023 at 7:02 AM Xiyue Deng  wrote:
>
> ...
>>
>> For the unlikely but possible cause that tests with a long name is a
>> prefix of other tests that may trigger this issue, I have modified the
>> test name for testing purposes.  Can you help get the latest upload on
>> mentors and try again?  TIA.
>>
> I tried this and it seems the issue was raised with my sbuild build 
> environment.
> I still got this:
> https://paste.debian.net/1296268/
>
> My sbuilderrc is here:
> https://paste.debian.net/1296269/
>
> But if use pbuilder[0] to build your package, it is ok.
> So I think your package which is no problem.
>
> BTW, I suspect the network accessing leads to the issue and I am annoy how to
> disable network access during building for sbuild.
>
> BR,
> Bo
> [0]: https://wiki.ubuntu.com/PbuilderHowto

Thanks for testing!  The reason I'm interested in reproducing this error
is that in the report of the RC bug that this upload is trying to solve
- https://bugs.debian.org/1052939 - the build log from Lucas has exactly
the same error:

,
| ...
| > Test ‘lsp-text-document-hover-request’ redefined
| > 
| > Error: error ("Test ‘lsp-text-document-hover-request’ redefined")
| ...
`

But I haven't been able to reproduce this until Arto and you sent your
reports, and this being reproduced by two people makes this more
interesting.  There must be something that may trigger this unlikely
error.  Also I'm not sure whether the network accessing may have been
the cause as sbuild needs to download the dependencies and without
something like apt-cacher{,-ng} it does need network access for that to
happen.

I suspected that the parallel setting in $DEB_BUILD_OPTIONS may have
affected it so I copied your sbuild settings and tried again but
unfortunately it still succeeded for me.  For the unlikely event and for
completeness, can you also try to turn that off in your sbuild config
and retry just in case?  TIA.

>> ,
>> | $ dget -x 
>> https://mentors.debian.net/debian/pool/main/l/lsp-mode/lsp-mode_8.0.0-6.dsc
>> | $ sbuild lsp-mode_8.0.0-6.dsc
>> `
>>
>> P.S. If you can provide the failed build log and ~/.sbuildrc it may
>> still help to eliminate potential sbuild differences in our environment.
>>
>> >>
>> >> BR,
>> >> Bo
>> >>>
>> >>> --
>> >>> Arto Jantunen
>> >>>
>>
>> --
>> Xiyue Deng

-- 
Xiyue Deng



Bug#409360: GSSAPIAuthentication should be disabled by default

2023-10-26 Thread Jesse Hathaway
I just ran into this issue when sshing to a server with GSSAPIAuthentication
enabled. Even though I am not using GSSAPI auth, Debian's default on the client
side added 15s to the login time. I agree with other folks that GSSAPI auth is
unusual and should be disabled by default since it may cause significant delays.

# With GSSAPIAuthentication on
$ time ssh -v foo hostname

debug1: Next authentication method: gssapi-with-mic
debug1: No credentials were supplied, or the credentials were
unavailable or inaccessible
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)
debug1: No credentials were supplied, or the credentials were
unavailable or inaccessible
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)

real0m15.204s
user0m0.010s
sys 0m0.011s

# With GSSAPIAuthentication off
$ time ssh -v foo hostname
real0m0.195s
user0m0.014s
sys 0m0.007s



Bug#1050618: Invalid bug

2023-10-26 Thread Christian Kastner
Version: 5.5.1-1

Closing this bug, as it is invalid. rocrand never failed, according to
the CI logs (even the linked one).



Bug#967791: usermode: depends on deprecated GTK 2

2023-10-26 Thread Bastian Germann

Control: tags -1 patch

Please find a patch attached that disables the GTK components.From: Bastian Germann 
Date: Thu, 26 Oct 2023 16:22:38 +
Subject: Disable GTK build (Closes: #967791)

---
 debian/control | 13 +++--
 debian/rules   |  8 +---
 2 files changed, 4 insertions(+), 17 deletions(-)

diff --git a/debian/control b/debian/control
index f923bb5..a66880a 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,6 @@ Build-Depends:
  gettext,
  intltool,
  libblkid-dev,
- libgtk2.0-dev,
  libice-dev,
  libpam0g-dev,
  libsm-dev,
@@ -25,12 +24,6 @@ Architecture: any
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
-Description: Graphical tools for certain user account management tasks
- The usermode package contains several graphical tools for users:
- userinfo, usermount and userpasswd.  Userinfo allows users to change
- their finger information.  Usermount lets users mount, unmount, and
- format filesystems.  Userpasswd allows users to change their
- passwords.
- .
- Install the usermode package if you would like to provide users with
- graphical tools for certain account management tasks.
+Description: Tools for certain user account management tasks
+ The usermode package contains tools for PAM authentication:
+ consolehelper and userhelper.
diff --git a/debian/rules b/debian/rules
index 6836f53..944f8c3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,18 +19,12 @@ DEBDIR=debian/usermode
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- \
+	dh_auto_configure -- --without-gtk \
 		MOUNT=/bin/mount \
 		UMOUNT=/bin/umount \
 		MKFS=/sbin/mkfs \
 		FDFORMAT=/usr/bin/fdformat
 
-execute_after_dh_install:
-	# this functionality doesn't appear to be supported in Debian
-	rm $(DEBDIR)/usr/bin/pam-panel-icon $(DEBDIR)/usr/share/pixmaps/badge-small.png
-	# can't figure out what the hell this stuff is for
-	rm $(DEBDIR)/usr/share/pixmaps/keys.xpm $(DEBDIR)/usr/share/pixmaps/status_lock.png $(DEBDIR)/usr/share/pixmaps/status_unlocked.png
-
 execute_after_dh_strip:
 	if [ "$(findstring nostrip,$(DEB_BUILD_OPTIONS))" != "nostrip" ]; then strip --strip-unneeded -R .comment $(DEBDIR)/usr/sbin/* $(DEBDIR)/usr/bin/*; fi
 


Bug#1054604: openstack-debian-images: Failure when setting up RAID on NVMe drives

2023-10-26 Thread Jim Scadden
Package: openstack-debian-images
Version: 1.73
Tags: patch

Due to the different naming convention for NVMe device nodes,
build-openstack-debian-image fails to set up a RAID array because it's
trying to use /dev/nvme0n11 instead of nvme0n1p1.

I've attached a patch which fixes this.

--

Regards
Jim
diff --git a/build-openstack-debian-image b/build-openstack-debian-image
index 9b2e69a..efb6cef 100755
--- a/build-openstack-debian-image
+++ b/build-openstack-debian-image
@@ -857,24 +857,21 @@ if [ -n "${RAID_DEVICES}" ] ; then
 	FIRST_RAID_ESP_DEV=""
 	SECOND_RAID_ESP_DEV=""
 	for i in ${DEVICES_TO_PARTITION} ; do
+		if echo "${i}" | grep -q -E ^/dev/nvme ; then
+			DEV_NODE_PREFIX="${i}p"
+		else
+			DEV_NODE_PREFIX="${i}"
+		fi
 		if [ -n "${RAID_DLIST}" ] ; then
-			RAID_DLIST="${RAID_DLIST} ${i}${RAID_PART_NUM}"
+			RAID_DLIST="${RAID_DLIST} ${DEV_NODE_PREFIX}${RAID_PART_NUM}"
 		else
-			RAID_DLIST="${i}${RAID_PART_NUM}"
+			RAID_DLIST="${DEV_NODE_PREFIX}${RAID_PART_NUM}"
 		fi
 		if [ -z "${FIRST_RAID_ESP_DEV}" ] && [ "${BOOTTYPE}" = "uefi" ] ; then
 			# This is the UEFI partition of the first RAID device
-			if echo "${DEST_HDD}" | grep -q -E ^nvme ; then
-FIRST_RAID_ESP_DEV=${i}p1
-			else
-FIRST_RAID_ESP_DEV=${i}1
-			fi
+			FIRST_RAID_ESP_DEV=${DEV_NODE_PREFIX}1
 		elif [ -n "${FIRST_RAID_ESP_DEV}" ] && [ -z "${SECOND_RAID_ESP_DEV}" ] && [ "${BOOTTYPE}" = "uefi" ] ; then
-			if echo "${DEST_HDD}" | grep -q -E ^nvme ; then
-SECOND_RAID_ESP_DEV=${i}p1
-			else
-SECOND_RAID_ESP_DEV=${i}1
-			fi
+			SECOND_RAID_ESP_DEV=${DEV_NODE_PREFIX}1
 		fi
 		NUM_DEVS=$((${NUM_DEVS} + 1))
 	done


Bug#1054603: openstack-cluster-installer: regex updates for Dell OS10 switches & BroadCom NXE NICs

2023-10-26 Thread Jim Scadden
Package: openstack-cluster-installer
Version: 42.3.0~bpo12+1
Severity: minor
Tags: patch

During auto-racking the switchport name and NIC firmware version are
rejected by OCI due to containing the / character:

# lldpcli show n | grep -E '(SysDescr|PortID)'
SysDescr: Dell EMC Networking OS10 Enterprise.
PortID:   ifname ethernet1/1/7

# ethtool -i eno12399np0 | grep firmware-version
firmware-version: 220.0.57.0/pkg 22.00.07.60

I have attached a patch which updates the regex to permit the /
character.
I've also updated the error messages to contain the rejected
data, as this may aid others in troubleshooting similar problems in the
future?

--

Regards
Jim
diff --git a/src/report.php b/src/report.php
index 1ade880a..e44cea94 100644
--- a/src/report.php
+++ b/src/report.php
@@ -585,33 +585,33 @@ if($n == 0){
 if(isset($iface["name"]) && isset($iface["macaddr"]) && isset($iface["max_speed"])){
 $if_name = $iface["name"];
 $reg = '/^[0-9a-zA-Z-]{1,64}$/';
-if(!preg_match($reg,$if_name)) die("Network interface device name suspicious line ".__LINE__." file ".__FILE__);
+if(!preg_match($reg,$if_name)) die("Network interface device name '$if_name' suspicious line ".__LINE__." file ".__FILE__);
 $safe_if_name = $if_name;
 
 $if_macaddr = $iface["macaddr"];
 $reg = '/^[0-9a-fA-F]{2}:[0-9a-fA-F]{2}:[0-9a-fA-F]{2}:[0-9a-fA-F]{2}:[0-9a-fA-F]{2}:[0-9a-fA-F]{2}$/';
-if(!preg_match($reg,$if_macaddr)) die("Network interface MAC address suspicious line ".__LINE__." file ".__FILE__);
+if(!preg_match($reg,$if_macaddr)) die("Network interface MAC address '$if_macaddr' suspicious line ".__LINE__." file ".__FILE__);
 $safe_if_macaddr = $if_macaddr;
 
 $if_max_speed = $iface["max_speed"];
 $reg = '/^[0-9]{1,10}$/';
-if(!preg_match($reg,$if_max_speed)) die("Network interface max_speed suspicious line ".__LINE__." file ".__FILE__);
+if(!preg_match($reg,$if_max_speed)) die("Network interface max_speed '$if_max_speed' suspicious line ".__LINE__." file ".__FILE__);
 $safe_if_max_speed = $if_max_speed;
 
 $if_switch_hostname = $iface["switch_hostname"];
 $reg = '/^((?!-))(xn--)?[a-z0-9][.a-z0-9-]{0,61}[a-z0-9]{0,1}$/';
-if(!preg_match($reg,$if_switch_hostname)) die("Switch hostname suspicious line ".__LINE__." file ".__FILE__);
+if(!preg_match($reg,$if_switch_hostname)) die("Switch hostname '$if_switch_hostname' suspicious line ".__LINE__." file ".__FILE__);
 $safe_if_switch_hostname = $if_switch_hostname;
 
 $if_switchport_name = $iface["switchport_name"];
-$reg = '/^[.:0-9a-zA-Z-]{1,64}$/';
-if(!preg_match($reg,$if_switchport_name)) die("Switchport name suspicious line ".__LINE__." file ".__FILE__);
+$reg = '/^[\/.:0-9a-zA-Z-]{1,64}$/';
+if(!preg_match($reg,$if_switchport_name)) die("Switchport name '$if_switchport_name' suspicious line ".__LINE__." file ".__FILE__);
 $safe_if_switchport_name = $if_switchport_name;
 
 if(isset($iface["firmware_version"]) && $iface["firmware_version"] != ""){
 $if_firmware_version = $iface["firmware_version"];
-$reg = '/^[.:0-9a-zA-Z-]{1,64}$/';
-if(!preg_match($reg,$if_firmware_version)) die("Iface firmware version suspicious line ".__LINE__." file ".__FILE__);
+$reg = '/^[\/.:0-9a-zA-Z-]{1,64}$/';
+if(!preg_match($reg,$if_firmware_version)) die("Iface firmware version '$if_firmware_version' suspicious line ".__LINE__." file ".__FILE__);
 $safe_if_firmware_version = $if_firmware_version;
 }else{
 $safe_if_firmware_version = "";
@@ -620,7 +620,7 @@ if($n == 0){
 if(isset($iface["driver"]) && $iface["driver"] != ""){
 $if_driver = $iface["driver"];
 $reg = '/^[_.:0-9a-zA-Z-]{1,64}$/';
-if(!preg_match($reg,$if_driver)) die("Iface driver name suspicious line ".__LINE__." file ".__FILE__);
+if(!preg_match($reg,$if_driver)) die("Iface driver name '$if_driver' suspicious line ".__LINE__." file ".__FILE__);
 $safe_if_driver = $if_driver;
 }else{
 $safe_if_driver = "";


Bug#1026848: apt-cacher-ng: Two fixes for erroneous tagging

2023-10-26 Thread Christophe Le Roy
Package: apt-cacher-ng
Version: 3.7.4-1+b2
Followup-For: Bug #1026848
X-Debbugs-Cc: christophe.f...@gmail.com

Dear Maintainer,

This issue affects me as well.

For example, just after installing bookworm using apt-cacher-ng, the
maintenance web page wants to remove currently up-to-date packages.

Hopefully, exStartTradeOff parameter prevents this, but it won't last forever.

Cheers,
Christophe


-- Package-specific info:

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

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

Versions of packages apt-cacher-ng depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.21.22
ii  libbz2-1.0 1.0.8-5+b1
ii  libc-ares2 1.18.1-3
ii  libc6  2.36-9+deb12u3
ii  libevent-2.1-7 2.1.12-stable-8
ii  libevent-pthreads-2.1-72.1.12-stable-8
ii  libfuse2   2.9.9-6+b1
ii  libgcc-s1  12.2.0-14
ii  liblzma5   5.4.1-0.2
ii  libssl33.0.11-1~deb12u2
ii  libstdc++6 12.2.0-14
ii  libsystemd0252.17-1~deb12u1
ii  libwrap0   7.6.q-32
ii  sysvinit-utils [lsb-base]  3.06-4
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20230311

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.8-10
pn  doc-base  

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission non accordée: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
* apt-cacher-ng/tunnelenable: false
  apt-cacher-ng/port: keep
  apt-cacher-ng/bindaddress: keep
  apt-cacher-ng/cachedir: keep
  apt-cacher-ng/gentargetmode: No automated setup
  apt-cacher-ng/proxy: keep


Bug#1054602: mosdepth: Needs "libhts.so" as a dependency, avaialbe in package "libhts-dev"

2023-10-26 Thread Frank Bearoff
Package: mosdepth
Version: 0.3.3+ds-2
Severity: important
X-Debbugs-Cc: fbear...@gmail.com

Dear Maintainer,

* What led up to the situation?
sudo apt install "mosdepth"

* What exactly did you do (or not do) that was effective (or
 ineffective)?
 sudo apt install "libhts-dev"

* What was the outcome of this action?
mosdepth works

It appears "mosdepth has the undecalred dependency of "libhts-dev"

Thanks!

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

Kernel: Linux 6.1.0-13-amd64 (SMP w/64 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 mosdepth depends on:
ii  libc6  2.36-9+deb12u3

mosdepth recommends no packages.

mosdepth suggests no packages.

-- no debconf information



Bug#1054601: checkinstall: Checkinstall unusable on i386 architecture, while works fine on amd64

2023-10-26 Thread Q4OS Team
Package: checkinstall
Version: 1.6.2+git20170426.d24a630-3+b1
Severity: important
X-Debbugs-Cc: q...@q4os.org

I am not able to build any Debian package using checkinstall on i386 
architecture, it allways fails. It's easily reproducible, just run the for 
example:
$ checkinstall --fstrans=yes --install=no --nodoc --pkgname=test cp /bin/ls 
/usr/local/bin/
That should build a simple Debian package, but fails with message "permission 
denied". I tried it on multilple i386 Debian environments, with the same error 
every time.
Important to mention, the same procedure works just fine on amd64 machines.

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 6.1.0-13-686 (SMP w/1 CPU thread; 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 checkinstall depends on:
ii  dpkg-dev1.21.22
ii  file1:5.44-3
ii  libc6   2.36-9+deb12u3
ii  sensible-utils  0.0.17+nmu1

Versions of packages checkinstall recommends:
ii  make  4.3-4.1

Versions of packages checkinstall suggests:
pn  gettext  

-- no debconf information



Bug#1054558: iotop: crashes on non-utf8 characters

2023-10-26 Thread Paul Wise
On Wed, 2023-10-25 at 23:23 +0200, Marc Lehmann wrote:

> independent of locale (or the fatc that locales are per-process), if
> iotop finds a command line argument that is not utf-8 encoded, it simply
> crashes. regardless of how it handles encodings it does not understand,
> it should not simply crash:

Please try iotop-c, since iotop is not maintained upstream and is
incompatible with Python 3.12 so will likely be removed from Debian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#1054310: Please install helper binaries into /usr/libexec

2023-10-26 Thread Harald Dunkel

Hi Michael,

thank you for the patch and your input to various bug reports about
network-manager-strongswan. I have prepared a new version on Salsa

https://salsa.debian.org/debian/network-manager-strongswan

(not verified yet). Would you mind to take a look, esp. at the
maintscript? I haven't used this feature before.

Are there some special actions necessary about the /etc/NetworkManager/VPN
directory? AFAIU the maintscript cannot remove directories.


I highly appreciate your input

Harri



Bug#1054600: openstack-cluster-installer: /etc/network/interfaces NIC names set to Array

2023-10-26 Thread Jim Scadden
Package: openstack-cluster-installer
Version: 42.3.0~bpo12+1
Tags: patch

When provisioning a new node the interface names in
/etc/network/interfaces are set to 'Array' if OCI is unable to find the
correct interface to use. This is due to
get_ethname_from_network_config() returning an array when there is an
error, but the return value is not checked in
slave_install_server_os_command()

I've attached a patch which check for an array and returns it, which
means that the attempt to provision the node will instead fail and
return the error.

--

Regards
Jim
diff --git a/src/inc/slave_actions.php b/src/inc/slave_actions.php
index 910f503f..f1963a53 100644
--- a/src/inc/slave_actions.php
+++ b/src/inc/slave_actions.php
@@ -1105,7 +1105,7 @@ function get_ethname_from_network_config($con, $conf, $machine_id, $iface_in){
 $neth = mysqli_num_rows($reth);
 if($neth != 1){
 $out["status"]  = "error";
-$out["message"] = "Cannot find block device: $q";
+$out["message"] = "Cannot find matching ethernet device for $iface_in";
 return $out;
 }
 $aeth = mysqli_fetch_array($reth);
@@ -1239,6 +1239,7 @@ function slave_install_server_os_command($con, $conf, $machine_id){
 }
 
 $iface1 = get_ethname_from_network_config($con, $conf, $machine_id, $mgmt_net["iface1"]);
+if (is_array($iface1)) { return $iface1; }
 
 $netvlan = $mgmt_net["vlan"];
 
@@ -1246,6 +1247,7 @@ function slave_install_server_os_command($con, $conf, $machine_id){
 
 if($mgmt_net["iface2"] != "none"){
 $iface2 = get_ethname_from_network_config($con, $conf, $machine_id, $mgmt_net["iface2"]);
+if (is_array($iface2)) { return $iface2; }
 if(is_null($netvlan)){
 if($cluster["bgp_to_the_host"] == "yes" && $machine["force_no_bgp2host"] == "no"){
 $mytype = "bgp";
@@ -1304,9 +1306,11 @@ function slave_install_server_os_command($con, $conf, $machine_id){
 }
 
 $iface1 = get_ethname_from_network_config($con, $conf, $machine_id, $onenet["iface1"]);
+if (is_array($iface1)) { return $iface1; }
 
 if($onenet["iface2"] != "none"){
 $iface2 = get_ethname_from_network_config($con, $conf, $machine_id, $onenet["iface2"]);
+if (is_array($iface2)) { return $iface2; }
 if(is_null($netvlan)){
 if($cluster["bgp_to_the_host"] == "yes" && $machine["force_no_bgp2host"] == "no"){
 $mytype = "bgp";


Bug#1054599: ITP: libtest-expectandcheck-perl -- expect/check-style unit testing with object methods

2023-10-26 Thread gregor herrmann
Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest-expectandcheck-perl
  Version : 0.06
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Test-ExpectAndCheck
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : expect/check-style unit testing with object methods

Test::ExpectAndCheck creates objects that assist in writing unit tests with
mocked object instances. Each mock instance will expect to receive a given
list of method calls. Each method call is checked that it received the right
arguments, and will return a prescribed result. At the end of each test, each
object is checked to ensure all the expected methods were called.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature


Bug#1054598: openstack-cluster-installer: reduce PHP warnings in apache log

2023-10-26 Thread Jim Scadden
Package: openstack-cluster-installer
Version: 42.3.0~bpo12+1
Severity: minor
Tags: patch

When adding a new node to the OpenStack cluster there are a number of
PHP warnings which appear in the apache error log, which can potentially
be misleading when diagnosing problems.

I've attached a couple of patches:

* api.php_fix_var_names.patch

Corrects variable names which don't exist with the right ones

* slave_actions.php_mkdir_if_not_exists.patch

Check if a directory already exists before creating it

* slave_actions.php_no_append_to_nil_string.patch

The key $json["data"] does not exist so appending to it generates a
warning

--

Regards
Jim
diff --git a/src/api.php b/src/api.php
index 5d0a921a..5d5938be 100644
--- a/src/api.php
+++ b/src/api.php
@@ -544,7 +544,7 @@ function api_actions($con,$conf){
 // Time server host
 if(isset($_REQUEST["time_server_host"])){
 $safe_time_server_host = safe_fqdn("time_server_host");
-if($safe_swift_part_power === FALSE){
+if($safe_time_server_host === FALSE){
 $json["status"] = "error";
 $json["message"] = "Error: not valid time server host.";
 return $json;
@@ -611,7 +611,7 @@ function api_actions($con,$conf){
 // VIP hostname (ie: api hostname)
 if(isset($_REQUEST["vip_hostname"])){
 $safe_vip_hostname = safe_fqdn("vip_hostname");
-if($safe_swift_part_power === FALSE){
+if($safe_vip_hostname === FALSE){
 $json["status"] = "error";
 $json["message"] = "Error: not valid time server host.";
 return $json;
diff --git a/src/inc/slave_actions.php b/src/inc/slave_actions.php
index 910f503f..415f15a0 100644
--- a/src/inc/slave_actions.php
+++ b/src/inc/slave_actions.php
@@ -1,5 +1,11 @@
 https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer
 
 $ret = get_machine_management_network_ip($con, $conf, $machine_id);
 $ip = $ret["data"];
-mkdir("$template_path/oci-in-target/etc");
-mkdir("$template_path/oci-in-target/etc/oci");
+mkdir_if_not_exists("$template_path/oci-in-target/etc");
+mkdir_if_not_exists("$template_path/oci-in-target/etc/oci");
 file_put_contents("$template_path/oci-in-target/etc/oci/my-ip", $ip);
 file_put_contents("$template_path/oci-in-target/etc/oci/my-role", $machine_role);
 
@@ -2525,7 +2518,7 @@ https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer
 }
 
 if($machine_role == "compute"){
-mkdir("$template_path/oci-in-target/etc/modprobe.d");
+mkdir_if_not_exists("$template_path/oci-in-target/etc/modprobe.d");
 if(($machine["nested_virt"] == "yes") ||  ($machine["nested_virt"] == "cluster_value" && $cluster["nested_virt"] == "yes")){
 file_put_contents("$template_path/oci-in-target/etc/modprobe.d/kvm.conf", "options kvm_intel nested=1");
 file_put_contents("$template_path/oci-in-target/etc/modprobe.d/kvm_amd.conf", "options kvm_amd nested=1");
@@ -2557,8 +2550,8 @@ https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer
 if($machine_role == "controller"){
 $ssh_key_dir = "/var/lib/oci/clusters/$cluster_name/ssh";
 if(file_exists("$ssh_key_dir/id_rsa")){
-mkdir("$template_path/oci-in-target/root");
-mkdir("$template_path/oci-in-target/root/.ssh", 0700);
+mkdir_if_not_exists("$template_path/oci-in-target/root");
+mkdir_if_not_exists("$template_path/oci-in-target/root/.ssh", 0700);
 copy("$ssh_key_dir/id_rsa", "$template_path/oci-in-target/root/.ssh/id_rsa");
 chmod("$template_path/oci-in-target/root/.ssh/id_rsa", 0600);
 if(file_exists("$ssh_key_dir/id_rsa.pub")){
@@ -2573,8 +2566,8 @@ https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer
 # Please note that what's below is also maintained with puppet
 # in puppet/manifests/generic.pp. Make sure to modify both here
 # and there if you're adding stuff.
-mkdir("$template_path/oci-in-target/etc/facter");
-mkdir("$template_path/oci-in-target/etc/facter/facts.d");
+mkdir_if_not_exists("$template_path/oci-in-target/etc/facter");
+mkdir_if_not_exists("$template_path/oci-in-target/etc/facter/facts.d");
 
 $ret = gen_oci_facts($con, $conf, $machine_id);
 if($ret["status"] != "success"){
@@ -2604,8 +2597,8 @@ https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer
 ### Create signed SSH host keys for this machine ###
 ### and copy the CA, so we can auth all servers  ###
 
-mkdir("$template_path/oci-in-target/etc");
-mkdir("$template_path/oci-in-target/etc/ssh");
+mkdir_if_not_exists("$template_path/oci-in-target/etc");
+mkdir_if_not_exists("$template_path/oci-in-target/etc/ssh");
 
 # Copy 

Bug#1054597: r-cran-gfonts: overrides fonts-open-sans with inferior Open Sans variant

2023-10-26 Thread Horst Schirmeier
Package: r-cran-gfonts
Version: 0.2.0-2
Severity: important
X-Debbugs-Cc: debianb...@schirmeier.com

Dear Maintainer,

the r-cran-gfonts package installs a variant of Open Sans (in
/usr/share/fonts/truetype/gfonts/open-sans) that only contains a subset of the
glyphs that come with the fonts-open-sans package.  However, on my system the
inferior Open Sans variant from r-cran-gfonts seems to take precedence over the
one from fonts-open-sans, which leads to missing glyphs in e.g. LibreOffice.

The only obvious solution to get access to all Open Sans glyphs is to remove
r-cran-gfonts completely and only keep fonts-open-sans.

How to reproduce:
 -  Install fonts-open-sans.
 -  Create LibreOffice Impress presentation with an Open Sans textbox
containing e.g. the "approximately equal sign" (≈) character.  Close
LibreOffice.
 -  Install r-cran-gfonts.
 -  Reopen the presentation file.

Outcome:
 -  LibreOffice shows a "missing glyph" box instead of the expected ≈
character.

Expected:
 -  LibreOffice should show the ≈ character.


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

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

Versions of packages r-cran-gfonts depends on:
ii  r-base-core [r-api-4.0]  4.3.1-4
ii  r-cran-crayon1.5.2-1
ii  r-cran-crul  1.4.0+dfsg-1
ii  r-cran-glue  1.6.2-1
ii  r-cran-htmltools 0.5.6-1
ii  r-cran-jsonlite  1.8.7+dfsg-1
ii  r-cran-shiny 1.7.5.1+dfsg-1

Versions of packages r-cran-gfonts recommends:
ii  r-cran-covr   3.6.3+dfsg-1
ii  r-cran-knitr  1.44+dfsg-1
ii  r-cran-rmarkdown  2.25+dfsg-1
ii  r-cran-testthat   3.2.0-1
ii  r-cran-vcr1.2.2+dfsg-1

r-cran-gfonts suggests no packages.

-- no debconf information


open-sans-specialchars.odp
Description: application/vnd.oasis.opendocument.presentation


Bug#967263: aumix: depends on deprecated GTK 2

2023-10-26 Thread Bastian Germann

On Tue, 4 Aug 2020 12:46:59 +0200 Samuel Thibault wrote:

I had mailed tre...@jpj.net about it in april, without any answer so
far. I guess we'll just disable the gtk build.


I have disabled the gtk build in the git repo.



Bug#1054596: Removal notice: obsolete

2023-10-26 Thread Ilias Tsitsimpis
Source: haskell-binary-parsers
Version: 0.2.4.0-4
Severity: serious

I intend to remove this package:

  * It has no rev dependencies
  * The current version FTBFS
  * Seems unmaintained; Last upload more than 4 years ago
  * It's not part of the latest Stackage LTS

If you believe we should keep this package in Debian, please close this
bug report.

-- 
Ilias



Bug#1054594: Downgrade to normal

2023-10-26 Thread Stuart Naylor
Apols misread the severity, please downgrade to normal as only happens so far 
with the Speex plugin.


Bug#1054595: ITP: nom -- command line tool that helps you lose weight

2023-10-26 Thread Holger Levsen
Package: wnpp
Severity: wishlist
Owner: Holger Levsen 
X-Debbugs-Cc: debian-de...@lists.debian.org, m...@blinry.org

* Package name: nom
  Version : 0.1.3
* URL : https://github.com/blinry/nom
* License : GPL2+
  Programming Lang: Ruby
  Description : command line tool that helps you lose weight

 nom is a command line tool that helps you lose weight by tracking your energy
 intake and creating a negative feedback loop. It's inspired by John Walker's
 The Hacker's Diet (https://www.fourmilab.ch/hackdiet/) and tries to automate
 things as much as possible.


I'm using this myself and plan to maintain it in the debian group on salsa.


-- 
cheers,
Holger

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

In a world where you can be anything, be kind.


signature.asc
Description: PGP signature


Bug#1053436: dhcpcd-base: dhcpcd stops listening on port 68 after several days

2023-10-26 Thread Martin-Éric Racine
It might also help to add a line with the "debug" statement in
/etc/dhcpcd.conf and check whether the log files tell anything useful
when it stops listening.

On Wed, Oct 25, 2023 at 3:35 AM Ron Murray  wrote:
>
> OK. Now running version 10.0.3-1. I'll let you know how it goes.
>
> --
> Ron Murray 
> PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761
>
> Ron Murray wrote:
>
>
> I’ll try that later tonight.
> --
> Ron Murray 
> PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761
>
> On 24 Oct 2023, at 15:28, Martin-Éric Racine  
> wrote:
>
> Next, try what's in Testing.
>
> On Tue, Oct 24, 2023 at 10:15 PM Ron Murray  wrote:
>
>
> It’s still happening. Currently running version 1:9.4.1-24~deb12u2.
>
>
> …..Ron
>
>
> --
>
> Ron Murray 
>
> PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761
>
>
> On 9 Oct 2023, at 10:02, Martin-Éric Racine  wrote:
>
>
> 
>
> Noted. If that still doesn't fix it, the next step is to try what's in 
> Testing.
>
>
> Martin-Éric
>
>
> su 8. lokak. 2023 klo 20.57 Ron Murray  kirjoitti:
>
>
> I've only just updated to that version. I'll let you know how it goes in a 
> few days.
>
>
> --
>
> Ron Murray 
>
> PGP Fingerprint: 4D99 70E3 2317 334B 141E  7B63 12F7 E865 B5E2 E761
>
>
> Martin-Éric Racine wrote:
>
>
>
> On Tue, 03 Oct 2023 20:28:25 -0400 Ron Murray  wrote:
>
>
> Package: dhcpcd-base
>
> Version: 9.4.1-22
>
> Severity: normal
>
>
> Dear Maintainer,
>
>
>  dhcpcd stops listening on udp port 68 after several days. Still
>
> listening on raw port 17. I've tried re-installing the package and I
>
>
> still get the same result.
>
>
> Does this still apply to the package that just entered Stable via updates?
>
>
>
> Martin-Éric



Bug#1054594: libasound2-plugins: Segmentation fault when using speexdsp plugin

2023-10-26 Thread stuartnaylor
Package: libasound2-plugins
Version: 1.2.7.1-1
Severity: important
X-Debbugs-Cc: stuartiannay...@outlook.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 ***


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

Kernel: Linux 6.1.0-rpi4-rpi-v8 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libasound2-plugins depends on:
ii  libasound21.2.8-1+rpt1
ii  libavcodec59  8:5.1.3-1+rpt4
ii  libavutil57   8:5.1.3-1+rpt4
ii  libc6 2.36-9+rpt2+deb12u3
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3
ii  libpulse0 16.1+dfsg1-2+rpt1
ii  libsamplerate00.2.2-3
ii  libspeexdsp1  1.2.1-1
ii  libswresample48:5.1.3-1+rpt4

libasound2-plugins recommends no packages.

libasound2-plugins suggests no packages.

Only checked on RaspiOS but this has been a long term fault where the 
Speex/SpeexDSP packages are RC1 whilst the build for libasound2-plugins checks 
for the final release.
In bookworm I have tried to recompile and install speex/speexdsp and then 
recompile libasound2-plugins  1.2.7.1-1 arm64
When I do I then get a bus error which always worked in Bullseye/Buster so 
maybe its not that old version mismatch
The /etc/asound.conf used is
-
pcm.!default {
type asym
playback.pcm "plughw:0"
capture.pcm  "agc"
}

pcm.array {
 type hw
 card 0
}

pcm.cap {
 type plug
 slave {
   pcm "array"
   channels 2
   }
 route_policy sum
}

pcm.agc {
 type speex
 slave.pcm "cap"
 agc 1
 agc_level 8000
 denoise yes
 dereverb no
}
---



Bug#967551: kasumi: depends on deprecated GTK 2

2023-10-26 Thread Bastian Germann

Please consider upgrading to the gtk3 port
https://github.com/Keruspe/kasumi



Bug#1053481: libdpkg-perl: dpkg-source fails to generate (complete) Testsuite-Triggers if test deps have :native qualifier

2023-10-26 Thread James McCoy
On Thu, Oct 26, 2023 at 01:10:46PM +0200, Guillem Jover wrote:
> On Wed, 2023-10-25 at 20:44:26 -0400, James McCoy wrote:
> > diff --git i/scripts/Dpkg/Deps/Simple.pm w/scripts/Dpkg/Deps/Simple.pm
> > index 431c93bb9..da7aedbd8 100644
> > --- i/scripts/Dpkg/Deps/Simple.pm
> > +++ w/scripts/Dpkg/Deps/Simple.pm
> > @@ -194,7 +194,6 @@ sub parse_string {
> >\s*$  # trailing spaces at end
> >  }x;
> >  if (defined $2) {
> > -return if $2 eq 'native' and not $self->{build_dep};
> >  $self->{archqual} = $2;
> >  }
> >  $self->{package} = $1;
> 
> …this would remove the check for run-time dependencies. What I had in
> mind was something like the attached patch, which I'll queue once I've
> updated the test suite to cope or to add unit tests.

Thanks!  I'm looking to add a lot more arch-qualified test depends, so I
appreciate the effort.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB



Bug#1054593: openstack-cluster-installer: ocicli machine-guess-racking returns error when no match found

2023-10-26 Thread Jim Scadden
Package: openstack-cluster-installer
Version: 42.3.0~bpo12+1
Severity: minor
Tags: patch

It looks like something went wrong with the patch which I provided in
#1053506, so the problem still exists. I've attached a rebased patch.

Original code:
if(sizeof($ret["data"]) == 0){
Current code (as at commit c69a4a67):
if(sizeof($ret["data"]) == 0 || sizeof($ret["data"]) == 0){
Suggested fix:
if(!isset($ret["data"]) || sizeof($ret["data"]) == 0){

Original bug report below

---

When testing out auto racking, the machine-guess-racking command returns
and error when there is no match, rather than reporting 'No racking info
could be guessed.' as expected

root@oci-01:~# ocicli machine-guess-racking afaf7bc0-9ef4-4ba0-8bd0-2e2eec827346
Could not query API:

In the apache error log:
[Thu Oct 05 10:19:33.193747 2023] [php:error] [pid 262310] [client 
127.0.0.1:49928] PHP Fatal error:  Uncaught TypeError: sizeof(): Argument #1 
($value) must be of type Countable|array, null given in 
/usr/share/openstack-cluster-installer/api.php:1118\nStack trace:\n#0 
/usr/share/openstack-cluster-installer/api.php(4023): api_actions()\n#1 
{main}\n  thrown in /usr/share/openstack-cluster-installer/api.php on line 1118

Line 59 of /usr/share/openstack-cluster-installer/inc/auto_racking.php
contains to following comment:
# No $json["data"] means nothing found.
however in line 1118 of api.php it is assumed that $ret["data"] is an
array

--

Regards
Jim
diff --git a/src/api.php b/src/api.php
index 5d0a921a..60f2a980 100644
--- a/src/api.php
+++ b/src/api.php
@@ -1118,7 +1118,7 @@ function api_actions($con,$conf){
 return $ret;
 }
 
-if(sizeof($ret["data"]) == 0 || sizeof($ret["data"]) == 0){
+if(!isset($ret["data"]) || sizeof($ret["data"]) == 0){
 $json["data"] = "No racking info could be guessed.";
 }else{
 $json["data"] = "Machine is in datacenter ".$ret["data"]["dc"]." row ".$ret["data"]["row"]." rack ".$ret["data"]["rack"]." ustart ".$ret["data"]["u_start"]." uend ".$ret["data"]["u_end"].".";


Bug#1054592: ITP: snakeyaml-engine

2023-10-26 Thread Jérôme Charaoui

Package: wnpp
Severity: wishlist
Owner: Jérôme Charaoui 
X-Debbugs-Cc: debian-de...@lists.debian.org

   Package name : snakeyaml-engine
   Version  : 2.7
   Upstream author  : Andrey Somov 
   URL  : https://bitbucket.org/snakeyaml/snakeyaml-engine
   License  : Apache-2.0
   Programming Lang : Java
   Description  : Core YAML 1.2 parser and emitter for Java

YAML is a data serialization format designed for human readability and 
interaction with scripting languages.


SnakeYAML Engine is a YAML 1.2 processor for the Java Virtual Machine 
version 8 and higher.


This a new dependency introduced in version 5.1 of the Ruby psych java 
extension.


Thanks,

-- Jerome



Bug#1054591: python3-pyflow: ${VERSION} not expanded in package metadata, causing PEP-440 validation failures

2023-10-26 Thread Stefano Rivera
Package: python3-pyflow
Version: 1.1.20-4
Severity: serious

Filing this as serious severity, because it has the risk of breaking
unrelated software.

The background here is that setuptools since 66 has required PEP-440
valid versions for all packages installed on a system. Pip makes a noise
about this since 23.3 in preparation for completely rejecting them in
pip 24.
https://github.com/pypa/setuptools/issues/3772#issuecomment-1384342813
https://github.com/pypa/pip/issues/12063

It looks like ${VERSION} is never expanded in setup.py. I suspect this
is because you are grabbing source from GitHub, and not using tarballs
from "scratch/make_release_tarball.bash"

Please provide a valid version in the package metadata.

$ python3 -c 'import pkg_resources; pkg_resources.require("pyFlow")'

This affects bookworm too, if a virtualenv has --system-site-packages
(less common) and upgraded setuptools (very common).

Stefano



Bug#1052863: krb5: FTBFS: dh_auto_test: error: cd build && make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2

2023-10-26 Thread Sam Hartman
> "Lucas" == Lucas Nussbaum  writes:
Lucas> Hi,

Lucas> As an additional data point, I can still reproduce this
Lucas> failure.

So, my understanding is that so far for you it always fails, and the
evidence so far suggests that it generally (or always, but I am not sure
we have long enough evidence for that) succeeds on the builds.

What is your environment like?
Chroot? Container?  If any namespaces are involved, how do you build the
namespaces, and what  non-default capability settings do you have on top
of the defaults of containerization software you use.

--Sam



Bug#1054590: lintian: False positive for all Debian Jr. binary packages: synopsis-is-a-sentence "Debian Jr. Art"

2023-10-26 Thread Andreas Tille
Package: lintian
Version: 2.116.3
Severity: normal
X-Debbugs-Cc: Stefan Kropp , Per Andersson 
, Jonathan Carter 

Hi,

as you can see in Salsa CI[1] there are false positives for

I: junior-art: synopsis-is-a-sentence "Debian Jr. Art"
I: junior-config: synopsis-is-a-sentence "Debian Jr. Project common package"
I: junior-desktop: synopsis-is-a-sentence "Debian Jr. Desktop Environment"
I: junior-education: synopsis-is-a-sentence "Debian Jr. education applications"
I: junior-games-adventure: synopsis-is-a-sentence "Debian Jr. Adventure Games"
...

Please make sure lintian will check only for a '.' at the end of the
synopsis or alternatively exclude the string "Debian Jr." from the
check.

Thanks a lot for working on lintian
   Andreas.

PS: All Uploaders of debian-junior in CC.  If you do not feel
like an Uploader of this package any more please remove
yourself from the list of Uploaders

[1] https://salsa.debian.org/blends-team/junior/-/jobs/4854515

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 
'experimental'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils2.41-6
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.22.0
ii  dpkg-dev1.22.0
ii  file1:5.45-2
ii  gettext 0.21-13+b1
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.29-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.0
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.636-1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1
ii  libsereal-encoder-perl  5.004+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.21-1
ii  libwww-mechanize-perl   2.17-1
ii  libwww-perl 6.72-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzip [lzip-decompressor]1.23-6
ii  lzop1.04-2
ii  man-db  2.11.2-3
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-9
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.4-0.1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.61-1

-- no debconf information



Bug#1054589: unblock: libapache2-mod-python/3.5.0+git20211031.e6458ec-1+b1

2023-10-26 Thread Stefano Rivera
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libapache2-mod-pyt...@packages.debian.org
Control: affects -1 + src:libapache2-mod-python

Please unblock package libapache2-mod-python

[ Reason ]
* In 03_debian-version.patch, strip the debian part of the version. BinNMUs
  were resulting in invalid PEP-440 versions. (Closes: #1054587)
* Patch: Fix segfaults when releasing threads. (Closes: #1019299)

[ Impact ]
The segfault issue seems rather serious.

The PEP-440 issue breaks any attempt to enumerate installed packages on
the system with pkg_resources.

[ Tests ]
Manually tested that mod_python runs and serves content.

[ Risks ]
Segfault patch is trivial and taken from upstream.

Version patch is trivial, and Debian-specific.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock libapache2-mod-python/3.5.0+git20211031.e6458ec-1+b1
diff -Nru libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/changelog 
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/changelog
--- libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/changelog
2022-04-18 06:22:40.0 +0200
+++ libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/changelog
2023-10-26 15:07:51.0 +0200
@@ -1,3 +1,12 @@
+libapache2-mod-python (3.5.0+git20211031.e6458ec-1+deb12u1) bookworm; 
urgency=medium
+
+  * Team upload.
+  * In 03_debian-version.patch, strip the debian part of the version. BinNMUs
+were resulting in invalid PEP-440 versions. (Closes: #1054587)
+  * Patch: Fix segfaults when releasing threads. (Closes: #1019299)
+
+ -- Stefano Rivera   Thu, 26 Oct 2023 15:07:51 +0200
+
 libapache2-mod-python (3.5.0+git20211031.e6458ec-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/03_debian-version.patch
 
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/03_debian-version.patch
--- 
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/03_debian-version.patch
  2022-04-18 06:22:40.0 +0200
+++ 
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/03_debian-version.patch
  2023-10-26 15:07:51.0 +0200
@@ -9,7 +9,7 @@
  1 file changed, 2 insertions(+), 19 deletions(-)
 
 diff --git a/dist/version.sh b/dist/version.sh
-index e5d..9ee18ac 100755
+index e5d..f97084a 100755
 --- a/dist/version.sh
 +++ b/dist/version.sh
 @@ -1,21 +1,4 @@
@@ -35,4 +35,4 @@
 -
 -echo $MAJ.$MIN.$PCH$GIT
 +cd $(dirname $0)/..
-+exec dpkg-parsechangelog -S Version
++dpkg-parsechangelog -S Version | cut -d - -f 1
diff -Nru 
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/15_py310_threadstate_clear.patch
 
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/15_py310_threadstate_clear.patch
--- 
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/15_py310_threadstate_clear.patch
 1970-01-01 02:00:00.0 +0200
+++ 
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/15_py310_threadstate_clear.patch
 2023-10-26 15:07:51.0 +0200
@@ -0,0 +1,27 @@
+From: Gregory Trubetskoy 
+Date: Fri, 16 Jun 2023 18:29:50 -0400
+Subject: 3.10 and up do not need a PyThreadState_Clear()
+
+Closes #100
+
+Bug-Upstream: https://github.com/grisha/mod_python/issues/100
+Bug-Debian: https://bugs.debian.org/1019299
+Origin: upstream, 
https://github.com/grisha/mod_python/commit/7e863bb4652ca4edeb158bf42eb26120e0e54040
+---
+ src/mod_python.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/mod_python.c b/src/mod_python.c
+index 6259c1b..11af968 100644
+--- a/src/mod_python.c
 b/src/mod_python.c
+@@ -303,7 +303,9 @@ static void release_interpreter(interpreterdata *idata)
+ {
+ PyThreadState *tstate = PyThreadState_Get();
+ #ifdef WITH_THREAD
++#if PY_MAJOR_VERSION <= 3 && PY_MINOR_VERSION < 10 
+ PyThreadState_Clear(tstate);
++#endif
+ if (idata)
+ APR_ARRAY_PUSH(idata->tstates, PyThreadState *) = tstate;
+ else
diff -Nru libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/series 
libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/series
--- libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/series   
2022-04-18 06:22:40.0 +0200
+++ libapache2-mod-python-3.5.0+git20211031.e6458ec/debian/patches/series   
2023-10-26 15:07:51.0 +0200
@@ -6,3 +6,4 @@
 12_py310_collections_import.patch
 13_py310_minor_version.patch
 14_sphinx_py3.patch
+15_py310_threadstate_clear.patch


Bug#1054588: ITP: ocaml-metadata -- read metadata from various formats

2023-10-26 Thread Kyle Robbertze
Package: wnpp
Severity: wishlist
Owner: Kyle Robbertze 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ocaml-metadata
  Version : 0.2.0
  Upstream Contact: Savonet Team 
* URL : https://github.com/savonet/ocaml-metadata
* License : GPL-3+
  Programming Lang: OCaml
  Description : read metadata from various formats

A pure OCaml library to read metadata frm various formats. For now, the
following are supported:

* Audio formats: ID3v1 and ID3v2 (for MP3), ogg/vorbis, ogg/opus and
  flac
* Image formats: jpeg and png
* Video formats: mp4 and avi

This will be maintained as part of the OCaml team and hosted on Salsa.



Bug#1054587: libapache2-mod-python: PEP-440 incompatible version (breaks pkg_resources & soon pip)

2023-10-26 Thread Stefano Rivera
Package: libapache2-mod-python
Version: 3.5.0+git20211031.e6458ec-1
Severity: normal

My git snapshot included this version as the Python version, which makes
pkg_resources unhappy

More recent setuptools (often installed in virtualenvs) breaks with this 
version:

$ ve/bin/python3 -c 'import pkg_resources; pkg_resources.require("mod_python")'
:1: DeprecationWarning: pkg_resources is deprecated as an API. See 
https://setuptools.pypa.io/en/latest/pkg_resources.html
Traceback (most recent call last):
  File "", line 1, in 
  File "/root/ve/lib/python3.11/site-packages/pkg_resources/__init__.py", line 
968, in require
needed = self.resolve(parse_requirements(requirements))
 ^^
  File "/root/ve/lib/python3.11/site-packages/pkg_resources/__init__.py", line 
829, in resolve
dist = self._resolve_dist(
   ^^^
  File "/root/ve/lib/python3.11/site-packages/pkg_resources/__init__.py", line 
854, in _resolve_dist
if dist is None or (dist not in req and replace_conflicting):
^^^
  File "/root/ve/lib/python3.11/site-packages/pkg_resources/__init__.py", line 
3205, in __contains__
return self.specifier.contains(item, prereleases=True)
   ^^^
  File 
"/root/ve/lib/python3.11/site-packages/pkg_resources/_vendor/packaging/specifiers.py",
 line 905, in contains
item = Version(item)
   ^
  File 
"/root/ve/lib/python3.11/site-packages/pkg_resources/_vendor/packaging/version.py",
 line 198, in __init__
raise InvalidVersion(f"Invalid version: '{version}'")
pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: 
'3.5.0-git20211031.e6458ec-1-b1'

Stefano



Bug#1054586: cream: depends on non-existent package

2023-10-26 Thread Santiago Vila

severity 105458 normal
thanks

El 26/10/23 a las 13:51, jaylaa.maldon...@allfreemail.net escribió:

Package: cream
Version: 0.43-3.1
Severity: serious

Dear Maintainer,

cream depends on non-existent package gvim, which is a policy violation. Please 
fix.


Have you actually tried to install cream on bookworm? It works for me:

# apt-get install cream
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  ca-certificates fontconfig-config fonts-dejavu-core libasound2 
libasound2-data libbrotli1 libbsd0 libcanberra0
  libedit2 libexpat1 libfontconfig1 libfreetype6 libgpm2 libice6 
libjpeg62-turbo libltdl7 liblua5.2-0
  libmotif-common libncurses6 libogg0 libpng16-16 libpython3.11 
libpython3.11-minimal libpython3.11-stdlib
  libreadline8 libruby libruby3.1 libsm6 libsodium23 libsqlite3-0 libtcl8.6 
libtdb1 libvorbis0a libvorbisfile3
  libx11-6 libx11-data libxau6 libxcb1 libxdmcp6 libxext6 libxft2 libxm4 
libxmu6 libxrender1 libxt6 libyaml-0-2
  media-types openssl rake readline-common ruby ruby-net-telnet ruby-rubygems 
ruby-sdbm ruby-webrick ruby-xmlrpc
  ruby3.1 rubygems-integration sound-theme-freedesktop tzdata ucf vim-common 
vim-gui-common vim-motif vim-runtime
  x11-common
Suggested packages:
  libasound2-plugins alsa-utils libcanberra-gtk0 libcanberra-pulse gpm tcl8.6 
readline-doc ri ruby-dev bundler
  cscope vim-doc
Recommended packages:
  alsa-ucm-conf alsa-topology-conf zip fonts-lato libjs-jquery xxd
The following NEW packages will be installed:
  ca-certificates cream fontconfig-config fonts-dejavu-core libasound2 
libasound2-data libbrotli1 libbsd0
  libcanberra0 libedit2 libexpat1 libfontconfig1 libfreetype6 libgpm2 libice6 
libjpeg62-turbo libltdl7 liblua5.2-0
  libmotif-common libncurses6 libogg0 libpng16-16 libpython3.11 
libpython3.11-minimal libpython3.11-stdlib
  libreadline8 libruby libruby3.1 libsm6 libsodium23 libsqlite3-0 libtcl8.6 
libtdb1 libvorbis0a libvorbisfile3
  libx11-6 libx11-data libxau6 libxcb1 libxdmcp6 libxext6 libxft2 libxm4 
libxmu6 libxrender1 libxt6 libyaml-0-2
  media-types openssl rake readline-common ruby ruby-net-telnet ruby-rubygems 
ruby-sdbm ruby-webrick ruby-xmlrpc
  ruby3.1 rubygems-integration sound-theme-freedesktop tzdata ucf vim-common 
vim-gui-common vim-motif vim-runtime
  x11-common
0 upgraded, 67 newly installed, 0 to remove and 0 not upgraded.
Need to get 33.1 MB of archives.
After this operation, 128 MB of additional disk space will be used.
Do you want to continue? [Y/n]


This is also from your own bug report:


Versions of packages cream depends on:
ii  ucf   3.0043+nmu1
ii  vim-motif [gvim]  2:9.0.1378-2


gvim is a "virtual package", which other real packages may "provide".

If you try to install gvim, this is what happens:

# apt-get install gvim
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package gvim is a virtual package provided by:
  vim-motif 2:9.0.1378-2 (= 2:9.0.1378-2)
  vim-gtk3 2:9.0.1378-2 (= 2:9.0.1378-2)
You should explicitly select one to install.

However, in your bug report it seems you already have vim-motif installed,
so what's exactly the problem you had?

(Note: I'm not the cream maintainer, I just noticed this bug and decided
to reply just to help diagnosing the problem)

Thanks.



Bug#1054586: cream: depends on non-existent package

2023-10-26 Thread Jaylaa . Maldonado
Package: cream
Version: 0.43-3.1
Severity: serious

Dear Maintainer,

cream depends on non-existent package gvim, which is a policy violation. Please 
fix.



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

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

Versions of packages cream depends on:
ii  ucf   3.0043+nmu1
ii  vim-motif [gvim]  2:9.0.1378-2

cream recommends no packages.

cream suggests no packages.

-- no debconf information



Bug#1040901: Upcoming changes to Debian Linux kernel packages

2023-10-26 Thread Bastian Blank
On Fri, Oct 20, 2023 at 05:54:23PM +0200, Bastian Blank wrote:
> Or would it be easier to re-use normal dependency resolving, like:
> Kernel-Provides: linux (>> 6.6.1~), linux (<< 6.6.1.)
> This would allow full flexibility and re-uses existing code to check
> such definitions.

Okay, noone complained, so it looks like this should work.

Regards,
Bastian

-- 
Too much of anything, even love, isn't necessarily a good thing.
-- Kirk, "The Trouble with Tribbles", stardate 4525.6



Bug#1054585: phpmyadmin: no cleanup of tmp dir

2023-10-26 Thread Beowulf
Package: phpmyadmin
Version: 4:5.0.4+dfsg2-2+deb11u1
Severity: important
Tags: patch
X-Debbugs-Cc: beow...@netzguerilla.net

Dear Maintainer,

/var/lib/phpmyadmin/tmp/ is created by the installer, php session files are 
created in there and never cleaned up.

It would be best to have a cronjob cleaning up old session files, like it is 
done in roundcubemail:
https://salsa.debian.org/roundcube-team/roundcube/-/blob/debian/bullseye/debian/roundcube-core.cron.daily

Best regards
Florian Müller


Bug#1054323: fixed in r-cran-tmb 1.9.6-2

2023-10-26 Thread Andreas Tille
Hi Paul,

Am Wed, Oct 25, 2023 at 09:58:42PM +0200 schrieb Paul Gevers:
> >   48s > library('TMB')
> >   48s Error: package or namespace load failed for ‘TMB’ in loadNamespace(j 
> > <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = vI[[j]]):
> >   48s  namespace ‘Matrix’ 1.6-1 is being loaded, but >= 1.6.1.1 is required
> > 
> > which is to be expected if I understand things correctly.
> 
> rmatrix is at 1.6-1.1-1, I think you have the version wrong because of the
> double hyphen.
> 
> paul@mulciber ~ $ dpkg --compare-versions 1.6-1-1 ge 1.6-1.1 ; echo $?
> 0

Hopefully fixed now.  If I would ever meet a three-wishes fairy
my wishes would be:

   1. Peace on earth
   2. Solve climate crisis
   3. Let R people stop using different characters sorting equally

Kind regards
   Andreas.

-- 
http://fam-tille.de



Bug#1051298: RFS: kildclient/3.2.1-1 -- powerful MUD client with a built-in Perl interpreter

2023-10-26 Thread Paul Wise
On Wed, 2023-10-25 at 14:24 -0300, Eduardo M KALINOWSKI wrote:

> As I mentioned, the tarball also has automatically generated html files 
> for the manual (and the xml source). Bastian did not raise an issue 
> about these files, but those I think should not be removed from the 
> upstream tarball, because rebuilding them requires a whole other set of 
> tools (docbook and a xlst processor), and this seems like an unnecessary 
> complication for an end user that is building from source.

Personally, I would suggest to remove the HTML, make building the
documentation optional and offer the generated HTML files on the
website and in secondary tarballs next to the source tarballs.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#1053481: libdpkg-perl: dpkg-source fails to generate (complete) Testsuite-Triggers if test deps have :native qualifier

2023-10-26 Thread Guillem Jover
Hi!

On Wed, 2023-10-25 at 20:44:26 -0400, James McCoy wrote:
> On Thu, Oct 05, 2023 at 07:11:32AM +0200, Guillem Jover wrote:
> > Right, nice catch! Given that these fields are based on what might
> > appear on build dependencies, I think it does make sense to consider
> > them an overlay on top of those. So I'll make them allow anything that
> > is allowed for build dependencies.
> 
> Would that just be the below patch?

Sorry, I started on this, but I think I might have misplaced the small
change I had, in any case thanks for the patch! Although…

> diff --git i/scripts/Dpkg/Deps/Simple.pm w/scripts/Dpkg/Deps/Simple.pm
> index 431c93bb9..da7aedbd8 100644
> --- i/scripts/Dpkg/Deps/Simple.pm
> +++ w/scripts/Dpkg/Deps/Simple.pm
> @@ -194,7 +194,6 @@ sub parse_string {
>\s*$  # trailing spaces at end
>  }x;
>  if (defined $2) {
> -return if $2 eq 'native' and not $self->{build_dep};
>  $self->{archqual} = $2;
>  }
>  $self->{package} = $1;

…this would remove the check for run-time dependencies. What I had in
mind was something like the attached patch, which I'll queue once I've
updated the test suite to cope or to add unit tests.

Thanks,
Guillem
From ecb3332d498b247e7ff2487e89dd9819d79adba2 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 26 Oct 2023 13:06:32 +0200
Subject: [PATCH] Dpkg::Deps: Implicitly enable build_deps option on tests_deps

The test dependencies are based on the build dependency syntax, so we
should accept everything they accept in addition to any test specific
syntax that is allowed.

Closes: #1053481
---
 scripts/Dpkg/Deps.pm| 6 ++
 scripts/Dpkg/Deps/Simple.pm | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/scripts/Dpkg/Deps.pm b/scripts/Dpkg/Deps.pm
index 87855cdc5..959318452 100644
--- a/scripts/Dpkg/Deps.pm
+++ b/scripts/Dpkg/Deps.pm
@@ -252,6 +252,9 @@ If set to 1, allow tests-specific package names in dependencies, that is
 "@" and "@builddeps@" (since dpkg 1.18.7). This should be set whenever
 working with dependency fields from F.
 
+This option implicitly (and forcibly) enables C because test
+dependencies are based on build dependencies (since dpkg 1.22.1).
+
 =back
 
 =cut
@@ -286,6 +289,9 @@ sub deps_parse {
 if ($options{reduce_profiles}) {
 $options{build_profiles} //= [ get_build_profiles() ];
 }
+if ($options{tests_dep}) {
+$options{build_dep} = 1;
+}
 
 # Options for Dpkg::Deps::Simple.
 my %deps_options = (
diff --git a/scripts/Dpkg/Deps/Simple.pm b/scripts/Dpkg/Deps/Simple.pm
index 431c93bb9..a2ab2b125 100644
--- a/scripts/Dpkg/Deps/Simple.pm
+++ b/scripts/Dpkg/Deps/Simple.pm
@@ -111,6 +111,9 @@ Defaults to 0.
 Specifies whether the parser should consider it a tests dependency.
 Defaults to 0.
 
+This option implicitly (and forcibly) enables C because test
+dependencies are based on build dependencies (since dpkg 1.22.1).
+
 =back
 
 =cut
@@ -126,6 +129,10 @@ sub new {
 $self->{build_arch} = $opts{build_arch};
 $self->{build_dep} = $opts{build_dep} // 0;
 $self->{tests_dep} = $opts{tests_dep} // 0;
+if ($self->{tests_dep}) {
+$self->{build_dep} = 1;
+}
+
 $self->parse_string($arg) if defined $arg;
 return $self;
 }
-- 
2.42.0



Bug#808940: ITP: terraform -- tool for managing cloud infrastructure

2023-10-26 Thread Laurent Bigonville

retitle 808940 ITP: opentofu -- tool for managing cloud infrastructure
thanks

On Thu, 24 Dec 2015 14:08:40 +0100 Daniel Stender 
 wrote:


Hello,

> * Package name : terraform
> Version : 0.6.8
> Upstream Author : Mitchell Hashimoto 
> * URL : https://terraform.io/
> * License : MPL-2.0
> Programming Lang: Go
> Description : tool for managing cloud infrastructure
>
> Terraform is a tool for launching complex infrastructure like from 
cloud providers
> like AWS or DigitlOcean. Like the other tools from HashiCorp 
(Vagrant, Packer etc.)
> a simple CLI based program which is very easy to use, employing 
configuration files
> for the needed setups. For more info, please see the documentation 
and quick intro

> on the site.
>

Now that hashicorp has changed the licence of their software BSL, I 
guess that this RFP should be changed to package opentofu instead?


https://opentofu.org/



Bug#1054584: RM: hipcub [arm64] -- ROM; Flaky build blocks migration

2023-10-26 Thread Christian Kastner
Package: ftp.debian.org
Severity: normal

Please remove hipcub from testing on arm64, it's blocking migration because
most buildds can't handle it.

The last successful build was on arm-arm-01, builds on other hosts all time
out.

We currently cannot test these packages on arm64 anyway.

Thanks,
Christian



Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel

2023-10-26 Thread Guillem Jover
Hi!

On Thu, 2023-10-26 at 11:40:53 +0200, Emanuele Rocca wrote:
> Package: dpkg-dev
> Version: 1.22.0
> Severity: normal

> -fstack-clash-protection is supposed to be enabled by default on amd64,
> arm64, armhf, and armel since dpkg 1.22.0:
> https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf
> 
> However, due to an issue in the following conditional in
> scripts/Dpkg/Vendor/Debian.pm, the flag is only on for amd64 and arm64:
> 
>   if (none { $cpu eq $_ } qw(amd64 arm64 armhf armel)) {
> 
> The value of $cpu is "arm" for both armhf and armel. Please change the
> line above to:
> 
>   if (none { $cpu eq $_ } qw(amd64 arm64 arm)) {

Ah, nice catch, and sorry! I think this happened due to copy pasting
and modifying one of the surrounding lines. The intention was to use
$arch here, to avoid enabling this on all arm-based arches which might
not support this. I've queued the attached patch for my next push.

I'll try to get a release out during the weekend.

Thanks,
Guillem
From 59234629857aa5910e27d0fadb3dfe29fbb3996d Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 26 Oct 2023 12:48:21 +0200
Subject: [PATCH] Dpkg::Vendor::Debian: Fix stackclash condition to enable the
 feature

We were using the cpu to check where to enable this feature, but this
should have been the arch, as that's what the names we match against
are. We used these specific names to avoid enabling this feature on
all arm based architectures where this feature might not be supported,
and instead only enable it on new ones.

Closes: #1054583
---
 scripts/Dpkg/Vendor/Debian.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
index 000f7e7f5..49935c9d7 100644
--- a/scripts/Dpkg/Vendor/Debian.pm
+++ b/scripts/Dpkg/Vendor/Debian.pm
@@ -337,7 +337,7 @@ sub set_build_features {
 	#   compiler supports it incorrectly (leads to SEGV)
 	$use_feature{hardening}{stackprotector} = 0;
 }
-if (none { $cpu eq $_ } qw(amd64 arm64 armhf armel)) {
+if (none { $arch eq $_ } qw(amd64 arm64 armhf armel)) {
 # Stack clash protector only available on amd64 and arm.
 $use_feature{hardening}{stackclash} = 0;
 }
-- 
2.42.0



Bug#1051293: Acknowledgement (rocfft: soft lockup with gfx1034)

2023-10-26 Thread Christian Kastner
Control: severity -1 important

I'm downgrading this bug, as the suite successfully completed on another
Navi24 device [1]. No longer RC, this should allow migration to testing
again.

Best,
Christian

[1] https://lists.debian.org/debian-ai/2023/10/msg00044.html



Bug#999610: firefox-esr: Protocol handlers from desktop files are not recognized without additional package desktop-file-utils

2023-10-26 Thread Sheik

Package: firefox-esr
Version: 115.3.0esr-1+b1
Followup-For: Bug #999610
X-Debbugs-Cc: sahibz...@gmail.com


Tested the following scenario to confirm that firefox-esr needs 
desktop-file-utils installed as a dependency to handle various protocols.



Test Cases

1. Run firefox-esr and open appstream://org.kde.dolphin.desktop -
   should launch KDE Discover.
2. Run xdg-open appstream://org.kde.dolphin.desktop - should launch KDE
   Discover.


Test Results

1. fire-fox-esr failed to launch KDE Discover - fail
2. xdg-open launched KDE Discover - pass


Test Results with workaround

1. Installed desktop-file-utils
2. fire-fox-esr launched KDE Discover - pass
3. xdg-open launched KDE Discover - pass


Thanks
Sheik


-- Package-specific info:


-- Addons package information

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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii debianutils 5.14
ii fontconfig 2.14.2-6
ii libasound2 1.2.10-1
ii libatk1.0-0 2.50.0-1
ii libc6 2.37-12
ii libcairo-gobject2 1.18.0-1
ii libcairo2 1.18.0-1
ii libdbus-1-3 1.14.10-1
ii libdbus-glib-1-2 0.112-3
ii libevent-2.1-7 2.1.12-stable-8
ii libffi8 3.4.4-1
ii libfontconfig1 2.14.2-6
ii libfreetype6 2.13.2+dfsg-1
ii libgcc-s1 13.2.0-5
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii libglib2.0-0 2.78.0-2
ii libgtk-3-0 3.24.38-5
ii libnspr4 2:4.35-1.1
ii libnss3 2:3.93-1
ii libpango-1.0-0 1.51.0+ds-2
ii libstdc++6 13.2.0-5
ii libvpx8 1.13.1-2
ii libx11-6 2:1.8.7-1
ii libx11-xcb1 2:1.8.7-1
ii libxcb-shm0 1.15-1
ii libxcb1 1.15-1
ii libxcomposite1 1:0.4.5-1
ii libxdamage1 1:1.1.6-1
ii libxext6 2:1.3.4-1+b1
ii libxfixes3 1:6.0.0-2
ii libxrandr2 2:1.5.2-2+b1
ii libxtst6 2:1.2.3-1.1
ii procps 2:4.0.4-2
ii zlib1g 1:1.2.13.dfsg-3

Versions of packages firefox-esr recommends:
ii libavcodec60 7:6.0-7+b1

Versions of packages firefox-esr suggests:
ii fonts-lmodern 2.005-1
pn fonts-stix | otf-stix 
ii libcanberra0 0.30-10
ii libgssapi-krb5-2 1.20.1-4
ii pulseaudio 16.1+dfsg1-2+b1

-- no debconf information


Bug#1024790: ortools: FTBFS everywhere

2023-10-26 Thread Agathe Porte
Hi,

2023-10-12 09:56 CEST, Nilesh Patra:
> ortools have a bunch of bugs filed against it. Do you intend to take
> care of them sometime soon?

Not really. I packaged it because I needed the python package as a
dependency, but I lost interest and did not make it to package the final
software.

The package maintainer is the Debian Science Team so that anyone can
contribute to the packaging, no questions asked. If someone is willing
to take the Uploader role, I can commit that into the repo.

Bests,

Agathe.



Bug#1054569: qtbase-opensource-src: FTBFS: Please add support for loongarch64

2023-10-26 Thread zhangdandan

Hi,

    Thanks for your reply.

在 2023/10/26 下午3:21, Sune Stolborg Vuorela 写道:

Do you have a link to the upstream accept of this? A link to a gerrit review,
to a git hash or something like that ?
The 6.5 branches support the LoongArch architecture, please see at 
https://github.com/qt/qtbase/tree/6.5
The commit for LoongArch architecture, please see at 
https://github.com/qt/qtbase/commit/bdc16f086f1664b56d8add0691c9a80d7997efd9
I pulled the qtbase source code, switched to branch 6.5 or a newer 
branch, the results of the search are as follows.

```
root@localhost:/home/dd/# git clone https://github.com/212dandan/qtbase.git
root@localhost:/home/dd/qtbase# git checkout remotes/origin/6.5
HEAD is now at 66ee534fba SignalDumper: fix UB (data race on ignoreLevel)
root@localhost:/home/dd/qtbase# grep "loongarch" -ri . |awk -F ":" 
'{print$1}' |uniq

./src/corelib/global/archdetect.cpp
./src/corelib/global/qprocessordetection.qdoc
./src/corelib/global/qprocessordetection.h
./src/corelib/plugin/qelfparser_p.cpp
./src/3rdparty/forkfd/forkfd_linux.c
./src/3rdparty/double-conversion/double-conversion/utils.h
```

thanks,
Dandan Zhang



Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel

2023-10-26 Thread Emanuele Rocca
Package: dpkg-dev
Version: 1.22.0
Severity: normal
Tag: patch

Hi,

-fstack-clash-protection is supposed to be enabled by default on amd64,
arm64, armhf, and armel since dpkg 1.22.0:
https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf

However, due to an issue in the following conditional in
scripts/Dpkg/Vendor/Debian.pm, the flag is only on for amd64 and arm64:

  if (none { $cpu eq $_ } qw(amd64 arm64 armhf armel)) {

The value of $cpu is "arm" for both armhf and armel. Please change the
line above to:

  if (none { $cpu eq $_ } qw(amd64 arm64 arm)) {

Thanks!
  Emanuele



Bug#1054582: fuzzel: Please register as alternative for and have packge provide dmenu

2023-10-26 Thread Jonas Smedegaard
Package: fuzzel
Version: 1.9.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Fuzzel is documented to mimick dmenu when executed under that name.

Please ease doing so, by a) registering the executable with the Debian
alternatives system, and have the binary package provide dmenu.

With that in place, other packages like sway that depend on the
executable dmenu can be made to use fuzzel with no intimate changes to
those packages (only adjust them to explicitly depend on or recommend
dmenu instead of indirectly via suckless-tools).

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmU6Mp0ACgkQLHwxRsGg
ASFIzQ/+O97zJ8NVzPBJOo3WMpeYFPHkUAk8WlvRJJ2UwOFEt+jZvnagA2nVq6tb
h7hoIvt9w9ZS36NPxaOKTxr1lpnE5AvlGNZ5/yXX/sO5p2uV1UQ4U1Txvmea3lvQ
3CWB2oqnhm3VRxFxHBIUPw5ewNWNK4FzoGDJXS1iPmONjj8MeN98NildFgKnoe1B
XeVdL2g/6FxNdmiPdjIvXByl3o3JoaLXh673czB9I2It76Qjfom11Ns3Zzl02Lf7
5+EuOzmQV77aLUwu+O6UAUiB/Upo0uCMQr+A38E8jIdHcrjCHkSopco8pIIiP0sg
czIZJk/kIi0SuWtiWLORqit0D8GDbRYpnsmnnMM9U02TovC4qb9JMlY87Q/EgUwy
lyzSd/SJUGq4ZjDeiRCefWEY7f46lH7OO8n8n8D/O610B7/gyGVQFVOobgk++bYW
LigaPBJVmovjsOvUFpo2zh5QwLMAqrPAJy8La7Lwpcyy60geTpQEwyAIvOYNxD37
bNPprBWd04OPnZmk3l394yDAq721rQZodckrrVtnM3mRP2L41Le0yrxvuS4ruLRm
ir28xRmm1BWOoZRrYGKhyiiKNHO/SJ9OacMneE85KxYnwObW/5oWd6GAUfQ8gNdP
74UwrlQ2Zb9gCg2wVEqg70cL2KJJ0xfV6pYb2kPJNCd8lEhamMU=
=eqCH
-END PGP SIGNATURE-



Bug#997299:

2023-10-26 Thread Naveed Ali
أود أن أناقش معك فرصة عمل أساسية وأحتاج أيضًا إلى مشاركتك فيها. أنا متأكد
جدًا من أنها ستكون مفيدة لكلا الطرفين ، وعند الإقرار بردك الذي أنتظره بصبر
، سأقدم لك المزيد من التفاصيل. شكرًا لك

أطيب التحيات
نفيد علي


Bug#1054581: asdf: Missing dependency on asdf-unit-schemas (breaks pkg_resources)

2023-10-26 Thread Stefano Rivera
Package: asdf
Version: 2.14.3-1
Severity: serious

asdf's upstream requirements declare a dependency on asdf-unit-schemas,
but this doesn't exist in Debian, and isn't a dependency.

The relevant upstream change is https://github.com/asdf-format/asdf/pull/1210
It seems this used to be part of asdf-standard, but got moved into its
own module.

I see the relevant schemas still exist in asdf-standard in Debian.
However, missing this dependency this breaks Python pkg_resources, that
attempts to validate Python requirements.

Filing this as serious, because it breaks unrelated software when asdf
is installed.

In bookworm:
$ python3 -c 'import pkg_resources; pkg_resources.require("asdf")'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 956, in 
require
needed = self.resolve(parse_requirements(requirements))
 ^^
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 815, in 
resolve
dist = self._resolve_dist(
   ^^^
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 856, in 
_resolve_dist
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'asdf-unit-schemas>=0.1.0' distribution 
was not found and is required by asdf

The same thing happens in unstable.

If you are certain that you don't need a (non-optional) Python
dependency, the best thing to do is to patch it out of the requirements
in pyproject.toml.

Stefano



  1   2   >