Bug#1070795: Processed: your mail

[Darrick J. Wong]

[actually cc the bugreport this time]

On Thu, May 09, 2024 at 07:40:20AM -0700, Darrick J. Wong wrote:
> On Thu, May 09, 2024 at 10:51:03AM +, Debian Bug Tracking System wrote:
> > Processing commands for cont...@bugs.debian.org:
> > 
> > > tags 1070795 + d-i
> > Bug #1070795 [xfsprogs-udeb] xfsprogs-udeb: the udeb is empty (size 904 
> > bytes) so does not contain mkfs.xfs
> 
> Yeah, someone needs to apply the patches in
> 
> https://lore.kernel.org/linux-xfs/171338841094.1852814.10756994414036094487.stgit@frogsfrogsfrogs/
> 
> and
> 
> https://lore.kernel.org/linux-xfs/171338841109.1852814.13493721733893449217.stgit@frogsfrogsfrogs/
> 
> which were not picked up for 6.7.  Unless the upstream maintainer
> (Carlos) goes ahead with a 6.7.1?
> 
> --D
> 
> > Added tag(s) d-i.
> > > thanks
> > Stopping processing here.
> > 
> > Please contact me if you need assistance.
> > -- 
> > 1070795: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070795
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
> > 
> 

Bug#1069280: Offer to co-maintain or adopt less

[P. J. McDermott]

Milan,

I see you're at least catching up on src:less bug reports, so I won't
pursue the salvaging process.  But my offer to help co-maintain still
stands.

Either way, as a reminder in case it helps you, in my Salsa fork[1] I:

  * Updated to the latest upstream release version 643, closing bugs
#1069037, #901071, #1059967, #931216, and #977494
  * Worked around tests broken since version 632
  * Dropped End-OSC8-hyperlink-on-invalid-embedded-escape-sequen.patch,
applied upstream
  * Refreshed debian/patches/02-655926-more_can_go_backwards.patch
  * Added GNU/Hurd PATH_MAX FTBFS patch from #1060420, applied upstream
  * Fixed lintian old-fsf-address-in-copyright-file,
trailing-whitespace, uses-debhelper-compat-file, and
package-uses-old-debhelper-compat-version (all lintian tags
including info and pedantic are fixed)
  * Added patches (one from upstream, one from me applied upstream) to
fix troff warnings introduced in upstream versions 595 and 608
  * Added DEP-3 headers to debian/patches/less-is-more-434417.patch and
debian/patches/02-655926-more_can_go_backwards.patch both of which I
forwarded upstream (and the latter was accepted)
  * Added .gitignore to fix gbp-buildpackage complaining about .pc/
  * Added debian/salsa-ci.yml

I've rebased upon Salvatore's NMU.  Let me know if I should request
commit access on Salsa to debian/less.git (as a non-DD I don't
automatically have access).  It looks like you have merge requests
disabled.

Feel free to take any or all of my changes and exclude any you don't
like, such as the Uploaders change.

[1]: https://salsa.debian.org/pehjota/less
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/


pgpyTs9yKP1Ww.pgp
Description: OpenPGP digital signature

Bug#1065637: pmbootstrap: postmarketOS project broke compatibility with v2.1.0

[Vivek K J]

Hey,

pmbootstrap 2.2.1 is now available in unstable and testing.

Closing this bug report
-- 
Regards,

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

OpenPGP_0xA5FF4BB3EA53C5DF.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063501: building curl from source fails the island test

[P. J. McDermott]

Hi josch,

On 2024-04-21 at 01:26, Johannes Schauer Marin Rodrigues wrote:
> Quoting Milan Kupcevic (2024-04-21 01:03:12)
> > On 4/20/24 15:59, Johannes Schauer Marin Rodrigues wrote:  
> > > How about using the upstream git instead of the release tarball as the 
> > > base for
> > > the packaging?  
> > I would rather stick with the official release tarballs as they get signed
> > with the upstream developer's key.  
> 
> I think we just recently had a long discussion in Debian about using the
> upstream git as source for the packaging instead of the release tarball in the
> light of how the recent xz-utils attack was performed. Maybe you can convince
> upstream to sign their git commits and/or tags.

It's actually more than just commit/tag signing.  Upstream releases[1]
"RECOMMENDED" release and "BETA" versions, doesn't distinguish[2]
between them in Git tags[3], and tells users to get release versions as
tar archives[4] and only use the Git repository for developing less[5].

[1]: https://www.greenwoodsoftware.com/less/download.html
[2]: https://github.com/gwsw/less/issues/441
[3]: https://github.com/gwsw/less/tags
[4]: https://github.com/gwsw/less/issues/245#issuecomment-1012323104
[5]: https://github.com/gwsw/less/blob/5e425e2/README#L20
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/


pgpSQxAXR5WeB.pgp
Description: OpenPGP digital signature

Bug#1068174: Debian FPGA toolchain update and testing (Was: Bug#1068174: yosys: Please package the latest upstream release)

[J . Neuschäfer]

On Sat, Apr 20, 2024 at 04:15:08PM +0200, Daniel Gröber wrote:
[...]
> Are you open to doing some testing for the new package version once I get
> around to putting it together? I can do end-to-end testing on ICE40(HX) and
> (probably) GW1N (if I can figure out how to flash this thing) maybe
> @Jonathan (in CC) can cover ECP5 and you could do ICE40UP and GateMate?

Count me in!

> I've been meaning to look into what we could use for testing beyond simple
> blinkies. Perhaps some CPU? I'd like to have something that can run
> internal consistency checks. If anyone has any ideas let me know.

That's a good question.

If you find a good answer, let me know, and it's probably a good idea to
write it down as a recommendation somewhere, so it doesn't get lost in time.

https://github.com/olofk/corescore might be an interesting option, but I
haven't looked at it in depth.


-jn


signature.asc
Description: PGP signature

Bug#1069573: libdar-dev: Some libraries listed by `pkg-config --libs libdar64` are not installed

[J. T. Elscott]

Package: libdar-dev
Version: 2.7.14-1
Severity: normal
X-Debbugs-Cc: jtelscot...@fastmail.com

Dear Maintainer,

Please forgive me if this is just a misunderstanding. Having installed libdar-
dev:
$ cat test.cpp
#include 
int main() {libdar::get_version();return 0;}
$ g++ -o test test.cpp $(pkg-config --libs --cflags libdar64)
/usr/bin/ld: cannot find -lthreadar: No such file or directory
/usr/bin/ld: cannot find -lgpgme: No such file or directory
/usr/bin/ld: cannot find -lrsync: No such file or directory
/usr/bin/ld: cannot find -lcap: No such file or directory
collect2: error: ld returned 1 exit status

As I understand it these things (for instance libthreadar-dev) should have been
automatically installed.


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

Kernel: Linux 6.7.9-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=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 libdar-dev depends on:
ii  libargon2-dev 0~20190702+dfsg-4+b1
ii  libassuan-dev 2.5.6-1
ii  libbz2-dev1.0.8-5.1
ii  libdar64-6000t64  2.7.14-1
ii  libgcrypt20-dev   1.10.3-2
ii  libgpg-error-dev  1.47-3
ii  liblz4-dev1.9.4-2
ii  liblzma-dev   5.6.1+really5.4.5-1
ii  liblzo2-dev   2.10-2+b1
ii  libzstd-dev   1.5.5+dfsg2-2
ii  zlib1g-dev1:1.3.dfsg-3.1

libdar-dev recommends no packages.

libdar-dev suggests no packages.

-- no debconf information

Bug#1064293: less: CVE-2022-48624

[P. J. McDermott]

On 2024-04-20 at 16:19, Christoph Anton Mitterer wrote:
> On Sat, 2024-04-20 at 07:54 -0400, P. J. McDermott wrote:
> > Then the salvage procedure can play out for the full 28+ days
> > specified
> > by developers-reference (21 days to allow the maintainer to object
> > followed by a DELAYED/7 adoption upload).  I've already soft-proposed
> > to
> > salvage in bug #1069280 yesterday.  And as mentioned there I'm not
> > yet a
> > DD or DM, so I'd need to find a sponsor (and access to
> > debian/less.git).  
> 
> In the light of the recent XZ backdoor, wouldn't it generally be more
> desirable to get more co-maintainers, rather than replacing an existing
> one?

Sure, that's exactly the plan.  I don't intend to remove or prevent
anyone from co-maintaining src:less.  Note that my proposal to adopt,
co-maintain, or salvage (bug #1069280) said that I would keep the
current maintainer in Uploaders or Maintainer unless he requests
otherwise.  My intent is not to force out the existing maintainer,
but to help where he seems to have been too busy to properly maintain
src:less for at least two years.  (No shame in being busy, but it looks
like the package could use some help keeping up with new upstream
releases, security issues like these, etc.)

And the repository is already in the "debian" Salsa group (formerly
"collab-maint" on Alioth), where any DD can commit to it.  Also, if I
adopt or salvage src:less, I plan to allow low-threshold NMU[1].  Other
than that, I don't know of an appropriate team for it.

[1]: https://wiki.debian.org/LowThresholdNmu
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1064293: less: CVE-2022-48624

[P. J. McDermott]

On 2024-04-19 at 15:55, Salvatore Bonaccorso wrote:
> Hi,
> 
> FWIW, I'm actually preparing a security update for the two CVEs and
> for bookworm I was first planning to do a 590-2.1 reaching unstable,
> and so then 590-2.1~deb12u1 for bookworm.
> 
> But if you want to override it with a NMU and proposing to salvage the
> package this is equally fine.

Your DELAYED/2 NMU is probably the fastest and best way to get these
CVEs fixed in unstable and bookworm, so that's fine, thanks.  Any plans
for 551-2 in bullseye?  The two patches in your NMU apply cleanly there.

Then the salvage procedure can play out for the full 28+ days specified
by developers-reference (21 days to allow the maintainer to object
followed by a DELAYED/7 adoption upload).  I've already soft-proposed to
salvage in bug #1069280 yesterday.  And as mentioned there I'm not yet a
DD or DM, so I'd need to find a sponsor (and access to debian/less.git).

If your NMU and my salvaging procedure go through, I'll rebase my work
upon and acknowledge your NMU.  And I'd like to backport a 643-1 to
bookworm and bullseye sloppy (and update bullseye-backports with your
NMU, unless you do that).

You and I both apparently made the exact same changes to backport the
CVE-2024-32487 patch (except your patch still has the original upstream
diffstat instead of the backport, which is fine), so that's a good
confirmation that my patch was (and yours is) correct.

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1064293: less: CVE-2022-48624

[P. J. McDermott]

On 2024-04-12 at 16:10, Christoph Anton Mitterer wrote:
> Hey.
> 
> There seems to be a somewhat similar issue reported by Jakub Wilk on
> oss-security:
> https://www.openwall.com/lists/oss-security/2024/04/12/5
> 
> where quoting causes troubles (though I couldn't replay the demo).

That was since assigned CVE-2024-32487 and Debian bug #1068938.

> Any chance to get both fixed in Debian unstable?

While the maintainer appears to be somewhat active elsewhere in Debian,
this package hasn't seen an upload in over a year and the packaged
version is getting close to three years old.  (Although I found that
updating to the latest upstream release version introduces new test
suite and lintian issues requiring some upstream patches backported and
reverted/fixed.)

In my Salsa fork[1] I have updated the package (fixing CVE-2022-48624)
and backported (with necessary code changes) the CVE-2024-32487 fix.
I would like to adopt, co-maintain, or if necessary salvage src:less
(see bug #1069280).  But the procedure[2] for that requires 28 days of
waiting for the maintainer to respond.  Perhaps in the meantime a new
upstream version NMU is warranted, or should the procedure be sped up
somehow?

[1]: https://salsa.debian.org/pehjota/less
[2]: 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#how-to-salvage-a-package
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1069280: Offer to co-maintain or adopt less

[P. J. McDermott]

Source: less
Severity: important
X-Debbugs-Cc: Milan Kupcevic 

Milan,

Although you're still somewhat active in Debian (e.g. on src:simulide),
you appear to be busy, which is understandable and common.  I'd like to
help maintain src:less by either joining as a co-maintainer in Uploaders
or adopting the package as its primary Maintainer (and keeping you in
Uploaders unless you disagree).

In my Salsa fork[1] I have already updated to the latest upstream
release version 643, noting five fixed Debian bugs including one CVE.
Then I backported four upstream patches: one for the other CVE (patch
required changes to apply), one to fix a Debian FTBFS bug, and two
trivial patches (one authored by me and accepted upstream) to fix
lintian warnings introduced in the new upstream version.  I also
reverted an upstream change that broke tests, but this should
be investigated further to fix upstream.  Finally, I updated
debian/copyright, Rules-Requires-Root, and debhelper-compat, which all
cleared some existing lintian tags.

I plan to also apply some lesspipe etc. patches from the BTS and from
another Salsa fork, as well as forward upstream debian/patches/* (and
maybe at least one patch from the BTS).  Also on the BTS there are some
old fixed bugs that can be closed and some that could maybe be fixed.

I am not a DD or DM however, so I will need you or another DD to
grant[2] me access to debian/less.git and to sponsor uploads.

I may also be interested in helping maintain src:gzip and/or src:avrdude
in the future (I don't use any of your six other packages), but for now
I'm focusing on src:less as the most critical package.

If I don't see a response here or other activity on src:less by you
within the next week or so, I will retitle this bug report to an ITS.
I will consider this first message the start of the 21 days specified
in developers-reference[3] (during which you're welcome to object to
salvaging) before seeking a sponsor for a DELAYED/7 upload with me as
Maintainer and you in Uploaders.

Although the CVE bugs (now marked grave severity) may justify uploading
sooner, perhaps as an NMU initially.

I believe src:less is eligible[4][5] for salvaging given the lack of
maintainer uploads or VCS commits in over a year, three new upstream
release versions not packaged for almost three years, several bug
reports with no maintainer activity[6] in over two years[7], two CVEs
(#1064293 and #1068938), an arguable DFSG violation (#1063501), and
several patches in the BTS (including #1060420 applied upstream).

[1]: https://salsa.debian.org/pehjota/less
[2]: 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
[3]: 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#how-to-salvage-a-package
[4]: 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#when-a-package-is-eligible-for-package-salvaging
[5]: https://wiki.debian.org/PackageSalvaging
[6]: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;correspondent=milan%40debian.org;ordering=raw;src=less
[7]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004383;msg=7
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1034087: afl++: Include afl-clang-lto(++) in package

[J . Neuschäfer]

On Mon, Apr 15, 2024 at 04:15:15PM +0700, Arnaud Rebillout wrote:
> Hello,
> 
> On Sat, 08 Apr 2023 13:47:19 +0200 =?utf-8?q?Jonathan_Neusch=C3=A4fer?=
>  wrote:
> 
> > Package: afl++
> > Version: 4.04c-3
> > Severity: wishlist
> >
> > Hello,
> >
> > the AFL++ documentation recommends using afl-clang-lto(++) if possible[1].
> >
> > Based on local tests, "PREFIX=/usr make" will produce an afl-clang-lto
> > binary, if lld-14 is also installed (which should be the case, according
> > to debian/rules). Not sure what's missing from the Debian package in
> > order to get afl-clang-lto.
> >
> > Best regards,
> > jn
> >
> >
> > [1]: 
> > https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/fuzzing_in_depth.md#1-instrumenting-the-target
> 
> 
> at this point it seems that afl-clang-lto(++) are parts of the package:
> 
>     $ apt show afl++ | grep ^Version:
>     Version: 4.09c-1+b1
> 
>     $ apt-file show afl++ | grep bin/afl-clang-lto
>     afl++: /usr/bin/afl-clang-lto
>     afl++: /usr/bin/afl-clang-lto++
> 
> Can we close this bug report then? Or did I misunderstand the bug report?

Sounds good.

Thanks for looking into this,
-jn


signature.asc
Description: PGP signature

Bug#1068249: linux-image-6.1.0-18-amd64: ax201 iwlwifi driver creates millions of 'Unhandled alg: 0x33f0707' messages

[J. Pfennig]

Package: src:linux
Version: 6.1.76-1
Severity: important
Tags: upstream

Dear Maintainer,

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

The driver fills the eventlog with millions !!! of messages, see below.
It otherwise works. The problem can be reproduced on different NUC systems.
These are used as small servers, run a network bridge and hostapd. There
is no evidence that the problem depends on hostapd.

When the connection is idle the rate of reported errors goes down to a
few 10 per second. A larger stream of data (2GByte or so) produces
seveeral hundered tousand messages.

   * What led up to the situation?

iwlwifi is loaded with parameters as described in the debian wiki for
AX201 / Intel Nuc hardware:

options iwlwifi 11n_disable=8
options iwlmvm power_scheme=1

without power_scheme it frequently drops connections, with
power_scheme=1 it is stable. The effect of 11n_disable is unknown.

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

Needed to increase network message_cost to reduce logging:

echo 128 > /proc/sys/net/core/message_cost

   * What was the outcome of this action?
   * What outcome did you expect instead?

A driver that simply works.

*** End of the template - remove these template lines ***


-- Package-specific info:
** Version:
Linux version 6.1.0-18-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)

** Command line:
root=LABEL=alpha1_vol0 rootflags=subvol=/Volumes/Root-bookworm ro 
resume=alpha1_swap centauriswitch=static:apoint net.ifnames=0 mitigations=off 
security= quiet splash loglevel=3

** Not tainted

** Kernel log:
[30911.569896] BTRFS info (device sda4): disk space caching is enabled
[30974.905443] net_ratelimit: 67420 callbacks suppressed
[30974.905457] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.905728] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.906036] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.906356] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.906681] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.907014] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.907319] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.907576] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.908421] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[30974.908744] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.906916] net_ratelimit: 216171 callbacks suppressed
[31102.906930] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.911063] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.911481] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.911817] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.912118] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.912434] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.912758] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.913054] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.913376] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31102.913728] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.911440] net_ratelimit: 221524 callbacks suppressed
[31230.911453] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.911815] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.912192] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.912511] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.912895] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.913217] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.913562] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.913912] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.914255] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31230.915740] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.912228] net_ratelimit: 213726 callbacks suppressed
[31358.912240] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.912554] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.912873] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.914335] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.914433] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.914948] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.915097] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.915459] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.915749] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31358.916034] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.915992] net_ratelimit: 205539 callbacks suppressed
[31486.916005] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.923781] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.924153] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.924548] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.924860] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
[31486.925252] iwlwifi :00:14.3: Unhandled alg: 0x33f0707

Bug#1065034: The courier packages on debian are ripe for a hostile takeover: An xz project compromise digression

[J Mo]

Hello!

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

This bug was filed with Debian a little over a month ago.

Unfortunately, the courier packages on Debian have long been poorly 
maintained. Nobody seems to be willing to step up and help out. I know 
Markus Wanner is/was doing his best and he deserves praise for helping 
out rather than bitching by a do-nothing pleb like me, but the last two 
package updates have been NMUs. He put out a Request For Help a long 
time ago and nobody ever stepped up.


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

We had an incompetent and disinterested maintainer in the form of Ondřej 
Surý some time back. He really had no idea what he was doing, didn't 
care, and f**ked s**t up real good.


An even larger threat would be if someone malicious were to come along 
and adopt the packages. Courier may not be the most popular MTA, but if 
I were a nation state actor or malware peddler looking for a reasonably 
popular Well-Known sub-1024 socketed daemon, this Debian package would 
be a prime candidate for take-over.


Finally, I realize I am creating a perfect opportunity for a bike shed, 
and there's been a lot of that going around on the xz compromise issue. 
I'm sorry. Also, just don't.


Thanks for reading



On 2/28/24 10:04 PM, ZHAO, fei wrote:

Package: courier
Severity: important

If the maintainer is unable to keep up with courier related packages, he
should orphan it.
Courier version outdated long.
courier-maildrop related questions not resolved for years and years.


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

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

Bug#1066438: backuppc-rsync: FTBFS: lib/compat.c:154:16: error: too few arguments to function ‘gettimeofday’

[J. Fernando LAGRANGE]

Le 13/03/2024 à 13:02, Lucas Nussbaum a écrit :

[…]
Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

[…]


Thanks for such information. Since no action was taken in last 2 weeks, 
I opened a bug upstream [1].


[1] https://github.com/backuppc/rsync-bpc/issues/40

I was able to reproduce this bug, but I am not able to resolv it as I do 
not understand how rsync-bpc is made from rsync. :-/



Thanks for any hint and regards.
--
J. Fernando Lagrange
Absent les mercredis des semaines paires
PROBESYS - Spécialistes OpenSource
9 rue de chamrousse
38100 Grenoble
Standard : 09 74 76 47 86
GLPi: 01 86 95 99 85
site web : https://www.probesys.com

Bug#1051139: fix doas for sxmo

[Philip J Freeman]

I'm working on a fix for this bug here:

https://salsa.debian.org/DebianOnMobile-team/sxmo-utils/-/merge_requests/2

I'm not sure I like installing Sxmo's doas.conf as /etc/doas.conf.
Looking into alternatives, but it seems that Debian's doas doesn't
support a doas.d/ directory, as pointed out by Jochen Sprickerhof.

This patch (as submitted in the MR on salsa) is currently working for me
on my pinephonepro.

Bug#1061290: RFS: rgbds/0.7.0-3 [ITP] -- Game Boy ASM programming tools

[P. J. McDermott]

I'm not a DD so I can't upload this, but I took a look.  I see you've
addressed most of the comments on Mentors in the repository on GitHub,
so I'm reviewing that rather than the older upload on Mentors.

Build-Depends lists pkg-config, which is a transitional package since
bookworm that should be replaced with the newer pkgconf.  lintian warns
about this:

W: rgbds source: build-depends-on-obsolete-package Build-Depends: 
pkg-config => pkgconf

This is just a suggestion/tip and not at all required, but it's popular
to use `wrap-and-sort -ast` to put each dependency on its own line (with
a trailing comma).  This would make the diff clearer in commits like
d1842536 and 22baba8b.

The years in the Copyright field of the "Files: *" stanza of d/copyright
look outdated: "1997-2020" when LICENSE says "1997-2023" since commit
f8af5696.

Not required by all sponsors, but Emmanuel on Mentors and Tobias here
suggested maintaining the packaging Git repository on Salsa (and
updating the Vcs- fields):

https://salsa.debian.org/
https://salsa.debian.org/games-team
https://salsa.debian.org/debian

You may also want to look into git-buildpackage with pristine-tar and a
DEP-14 branch layout:

https://honk.sigxcpu.org/piki/projects/git-buildpackage/
https://www.eyrie.org/~eagle/notes/debian/git.html
https://dep-team.pages.debian.net/deps/dep14/

Looks OK otherwise to me, and the package builds fine under sbuild with
no lintian tags (even informational or pedantic) other than the obsolete
package warning above; nice work!  So, once the pkg-config -> pkgconf
switch and copyright years update are done, I think it's good enough for
someone to upload.

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1063707: liblua5.4-0: C++ library missing all "lua*" function symbols

[P. J. McDermott]

Control: tags -1 - patch

After submitting the aforementioned merge request (and another one with
other improvements including CI pipelines), I see now that the patch
removal was intentional:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032533

On 2023-03-08 at 14:44, Jackson wrote:
> This patchfile undermines that Lua can be built as C++ to manage unwinding
> exceptions; according to the date, it has been in the Debian Lua repository 
> for
> over seven years. For example, future releases of MAME (package: mame) will
> break using USE_SYSTEM_LUA_LIB if this fallacy not resolved, since they link
> their own copy.

I'm not sure what this bug report is trying to say or how `extern "C"`
(simply preventing C++ name mangling) could undermine or break anything
in what is really a C library (C symbol names, just compiled to throw
and catch C++ exceptions).  (Does MAME link against both a system C++
Lua and its own C Lua copy?)  But whatever.

And from https://salsa.debian.org/lua-team/lua5.4/-/merge_requests/4#note_444235
> With this we found that the current c++ library in sid is probably broken 
> (and unused since nobody complained so far)

Yes, it is broken, but I'm trying to use it for the upcoming
wesnoth-1.18 which can now use a system copy of Lua (after over a month
of work toward that goal):
https://github.com/wesnoth/wesnoth/pull/8234

Since lua5.4 was promoted to Ubuntu main in 23.10 and Wesnoth now uses
Lua without modifications, the goal is for wesnoth-1.18 to use the
lua5.4 package supported in Ubuntu main (instead of Wesnoth's embedded
code copy stuck in universe) before the Ubuntu Noble Debian Import
Freeze on 2024-02-29.  So I hope this can somehow be fixed well before
then (wesnoth-1.18 still has to go through NEW before that date).

I found that the reason it is broken with `extern "C"` removed and name
mangling newly enabled is that debian/patches/0001-build-system.patch
links using the export map debian/version-script which doesn't list
the C++ symbols.  Adding the C++ symbols to debian/version-script and
debian/liblua5.4-0.symbols as I attempted in the updated merge requests
would fix this, however C++ symbol names are architecture-specific.
So we'll have to either collect arch-specific names with `(arch=foo)`
tags[1] (by making buildds fail for a while[2]) or switch to using
shlibs[3].  The wiki recommends shlibs: "For C++ libraries it is often
better not to ship symbols files."[1]  Sounds good, especially since
going through multiple uploads and waiting for buildds to fail would
take time.  Except switching to shlibs means losing the version
information noting that the mangled symbols didn't exist before now,
so users who install a package (that uses the C++ library's mangled
symbols) without updating liblua5.4-0 will see run-time linker errors.
To solve that, we need to also bump the C++ library's SONAME version
(which is appropriate anyway, given that the ABI completely changed).
So unless you disagree (or beat me to it), I'll work on switching to
shlibs and bumping the SONAME version.

Restoring `extern "C"` would avoid all this mess and keep the previous
unmangled symbols in case anyone was using the C++ library before now.
But the previous bug report claims that this breaks something (so let's
break everything else instead).

[1]: https://wiki.debian.org/UsingSymbolsFiles#C.2B-.2B-_libraries
[2]: https://www.eyrie.org/~eagle/journal/2012-01/008.html
[3]: https://www.eyrie.org/~eagle/journal/2012-02/001.html
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1063707: liblua5.4-0: C++ library missing all "lua_*" function symbols

[P. J. McDermott]

tags -1 + patch
thanks

https://salsa.debian.org/lua-team/lua5.4/-/merge_requests/5

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1063707: liblua5.4-0: C++ library missing all "lua_*" function symbols

[P. J. McDermott]

Package: liblua5.4-0
Version: 5.4.6-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: p...@pehjota.net

Hi,

Since version 5.4.6-1, liblua5.4-c++.so.0.0.0 defines no "lua_*"
function symbols (only "lua_ident@@LUA_5.4"):

$ readelf -s /usr/lib/x86_64-linux-gnu/liblua5.4-c++.so.0.0.0 | grep -F lua_
   101: 000315e0   129 OBJECT  GLOBAL DEFAULT   15 
lua_ident@@LUA_5.4
$ readelf -s /usr/lib/i386-linux-gnu/liblua5.4-c++.so.0.0.0 | grep -F lua_
   106: 00030600   129 OBJECT  GLOBAL DEFAULT   15 lua_ident@@LUA_5.4

Version 5.4.4-3 is OK:

$ readelf -s /usr/lib/x86_64-linux-gnu/liblua5.4-c++.so.0.0.0 | grep -F 
lua_ | head -n 5
   102: a610   220 FUNCGLOBAL DEFAULT   13 
lua_pus[...]@@LUA_5.4
   103: a940   160 FUNCGLOBAL DEFAULT   13 
lua_getfield@@LUA_5.4
   104: a5e048 FUNCGLOBAL DEFAULT   13 
lua_pus[...]@@LUA_5.4
   105: b330   273 FUNCGLOBAL DEFAULT   13 
lua_set[...]@@LUA_5.4
   107: bbf086 FUNCGLOBAL DEFAULT   13 
lua_toclose@@LUA_5.4
$ readelf -s /usr/lib/i386-linux-gnu/liblua5.4-c++.so.0.0.0 | grep -F lua_ 
| head -n 5
   107: 678064 FUNCGLOBAL DEFAULT   13 lua_pus[...]@@LUA_5.4
   108: 6a10   173 FUNCGLOBAL DEFAULT   13 lua_getfield@@LUA_5.4
   109: 674060 FUNCGLOBAL DEFAULT   13 lua_pus[...]@@LUA_5.4
   110: 74f0   253 FUNCGLOBAL DEFAULT   13 lua_set[...]@@LUA_5.4
   112: 7c3085 FUNCGLOBAL DEFAULT   13 lua_toclose@@LUA_5.4

The problem is that 0003-extern_C.patch was refreshed but mistakenly
removed from debian/patches/series in version 5.4.6-1 (commit d46ea48)
and then removed completely from debian/patches/ in version 5.4.6-2
(commit 02278c6).

Bug#1061541: ITP: ruby-redis-client -- redis-client is a simple, low-level, client for Redis 6+.

[Vivek K J]

Package: wnpp
Severity: wishlist
Owner: Vivek K J 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ruby-redis-client
  Version : 0.19.1
  Upstream Contact: jean.bouss...@gmail.com
* URL : https://github.com/redis-rb/redis-client
* License : Expat
  Programming Lang: Ruby
  Description : redis-client is a simple, low-level, client for Redis 6+.

 Contrary to the redis gem, redis-client doesn't try to map all Redis commands
 to Ruby constructs, it merely is a thin wrapper on top of the RESP3 protocol.

 This package is a dependency of gitlab. This package will be maintained by
 Debian ruby team.

Bug#1061533: cmake: CMake doesn't find googletest

[J . Neuschäfer]

On Fri, Jan 26, 2024 at 01:20:03AM +0100, Jonathan Neuschäfer wrote:
> Package: cmake
> Version: 3.28.1-1
> Severity: normal
> X-Debbugs-Cc: s...@debian.org, hal...@debian.org
>
>
> Hello, I have installed cmake 3.28.1-1 and googletest 1.14.0-1 from
> Debian testing, and I'm trying to use GTest with CMake as follows:

Sorry for the noise, I found the problem:

For this to work, I need to install libgtest-dev.

Perhaps the googletest package could include a hint to that effect in
the description.

Bug#1061482: gnome-initial-setup: User is added to sudo group

[J. Fernando Lagrange]

Package: gnome-initial-setup
Version: 43.2-6
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Installing with preseed and, at first reboot, using gnome-initial-setup for a 
user (not an admin user) and Enterprise login.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Click on "Set Up Enterprise Login"
Fill in the active directory domain with ad user and password
Fill in the hostname, the active directory administrator's name and password

   * What was the outcome of this action?
User account created and added in local sudo group

   * What outcome did you expect instead?
User account created.


A "workaround" is to launch following command after installation:
deluser  sudo

Must gnome-initial-setup with Enterprise login be filled with an admin account, 
only ?

Regards,
Fernando


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

Kernel: Linux 6.1.0-17-amd64 (SMP w/4 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 gnome-initial-setup depends on:
ii  adduser3.134
ii  desktop-base   12.0.6+nmu1~deb12u1
ii  gnome-settings-daemon  43.0-4
ii  libaccountsservice022.08.8-6
ii  libadwaita-1-0 1.2.2-1
ii  libc6  2.36-9+deb12u3
ii  libcairo2  1.16.0-7
ii  libfontconfig1 2.14.1-4
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1
ii  libgdm143.0-3
ii  libgeoclue-2-0 2.6.0-2
ii  libgeocode-glib-2-03.26.3-6
ii  libglib2.0-0   2.74.6-2
ii  libgnome-desktop-4-2   43.2-2
ii  libgoa-1.0-0b  3.46.0-1
ii  libgoa-backend-1.0-1   3.46.0-1
ii  libgtk-3-0 3.24.38-2~deb12u1
ii  libgtk-4-1 4.8.3+ds-2+deb12u1
ii  libgweather-4-04.2.0-2
ii  libibus-1.0-5  1.5.27-5
ii  libjson-glib-1.0-0 1.6.6-1
ii  libkrb5-3  1.20.1-2+deb12u1
ii  libmalcontent-0-0  0.11.0-4
ii  libmalcontent-ui-1-1   0.11.0-4
ii  libnm0 1.42.4-1
ii  libnma-gtk4-0  1.10.6-1
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpangocairo-1.0-01.50.12+ds-1
ii  libpolkit-gobject-1-0  122-3
ii  libpwquality1  1.4.5-1+b1
ii  librest-1.0-0  0.9.1-6
ii  libsecret-1-0  0.20.5-3
ii  libwebkitgtk-6.0-4 2.42.4-1~deb12u1
ii  pkexec 122-3
ii  polkitd122-3

Versions of packages gnome-initial-setup recommends:
ii  accountsservice  22.08.8-6
ii  geoclue-2.0  2.6.0-2
ii  gnome-keyring42.1-1+b2
pn  malcontent   

Versions of packages gnome-initial-setup suggests:
ii  gdm3  43.0-3

-- no debconf information

Bug#1061122: openarena on wayland unplayable, too dark to see

[J Sloan]

Package: openarena
Version: 0.8.8+dfsg-7+b1
Severity: important
Tags: upstream

Dear Maintainer,


   * What led up to the situation? Attempting to launch openarena on Debian sid 
(trixie)
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I tried to increase the brightness using the game controls
   * What was the outcome of this action? no change
   * What outcome did you expect instead? I expected the brightness to increase


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

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

Versions of packages openarena depends on:
ii  ioquake3  1.36+u20231123.972635e+dfsg-1
ii  libc6 2.37-13
ii  openarena-081-maps0.8.5split-14
ii  openarena-081-misc0.8.5split-14
ii  openarena-081-players 0.8.5split-14
ii  openarena-081-players-mature  0.8.5split-14
ii  openarena-081-textures0.8.5split-14
ii  openarena-085-data0.8.5split-15
ii  openarena-088-data0.8.8-13
ii  openarena-data0.8.5split-15

Versions of packages openarena recommends:
ii  openarena-oacmp1  3-8

openarena suggests no packages.

Versions of packages ioquake3 depends on:
ii  ioquake3-server  1.36+u20231123.972635e+dfsg-1
ii  libc62.37-13
ii  libcurl3-gnutls  8.5.0-2
ii  libgl1   1.7.0-1
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libopenal1   1:1.23.1-4
ii  libopus0 1.4-1
ii  libopusfile0 0.12-4
ii  libsdl2-2.0-02.28.5+dfsg-3
ii  libvorbisfile3   1.3.7-1
ii  zlib1g   1:1.3.dfsg-3+b1

Versions of packages ioquake3 recommends:
ii  kdialog4:22.12.3-1
ii  x11-utils  7.7+6

-- no debconf information

Bug#1061096: bullseye-pu: package ruby-aws-sdk-core/3.104.3-3+deb11u1

[Vivek K J]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ruby-aws-sdk-c...@packages.debian.org
Control: affects -1 + src:ruby-aws-sdk-core


[ Reason ]

The oldstable version of ruby-aws-sdk-core isn't shipping the necessary VERSION
file which is required for the functionality of this package. This proposed
update is aiming to fix that bug (See: #1035389)

[ Impact ]

If the update isn't approved, the package will be unusable in bullseye

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

[ Changes ]

--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ruby-aws-sdk-core (3.104.3-3+deb11u2) bullseye; urgency=medium
+
+  * Team upload.
+  * Include VERSION file in package (Closes: #1035389)
+
+ -- Vivek K J   Thu, 18 Jan 2024 12:05:59 +0530
+
 ruby-aws-sdk-core (3.104.3-3+deb11u1) bullseye; urgency=medium
 
   * Team upload.
diff --git a/debian/rules b/debian/rules
index 8650938..3d8535e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,8 @@
 #!/usr/bin/make -f
 
 export GEM2DEB_TEST_RUNNER = --check-dependencies
-export VERSION = $(cat ../VERSION)
+export DH_RUBY = --gem-install
+
 
 %:
dh $@ --buildsystem=ruby --with ruby

Bug#1060388: sponsor for endless-sky

[P. J. McDermott]

On 2024-01-17 at 10:22, Bo YU wrote:
> Hi,
> 
> First sorry without contacting here before NMU.

Welcome!

> I am looking for a sponsor for my package "endless-sky":

I'm not a DD, but I gave this a look and have a couple comments.

>  * Vcs  : https://salsa.debian.org/games-team/endless-sky

Do you have an account on Salsa?  You could fork the repository and
submit an MR so that the changes are ready to merge and upload.  If not,
that's OK; I think the changes are small enough for one of us to just
commit in one shot.

>  endless-sky (0.10.4-0.1) UNRELEASED; urgency=medium
>  .
>* Non-maintainer upload.
>* New upstream version 0.10.4. (Closes: #1059987)
>* rebase debian/patches

I see out/troff.patch and out/spelling.patch were applied upstream and
removed from debian/patches/series, but the patch files are still under
debian/patches/.  They should be removed.

>* Change Build-Depends on 'cmake' to'cmake (>= 3.21)'.
>  (Closes: #1054624).

(Coincidentally, seeing this bug on Friday reminded me to do a similar
cmake B-D version bump in another package.)

Other than the suggestions of Git and removing patch files, this looks
OK to me for an NMU.  But of course it needs a DD's review (ideally
Damyan).

Since the changes are apparently not in Git, here's the diff I
reviewed:

 changelog |   10 ++
 control   |2 +-
 patches/atomics.patch |   29 ++---
 patches/series|2 --
 4 files changed, 29 insertions(+), 14 deletions(-)
---
diff -Naur endless-sky-0.10.2/debian/changelog 
endless-sky-0.10.4/debian/changelog
--- endless-sky-0.10.2/debian/changelog 2023-10-10 10:57:15.0 -0400
+++ endless-sky-0.10.4/debian/changelog 2024-01-07 20:42:17.0 -0500
@@ -1,3 +1,13 @@
+endless-sky (0.10.4-0.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream version 0.10.4. (Closes: #1059987)
+  * rebase debian/patches
+  * Change Build-Depends on 'cmake' to'cmake (>= 3.21)'.
+(Closes: #1054624).
+
+ -- Bo YU   Mon, 08 Jan 2024 09:42:17 +0800
+
 endless-sky (0.10.2-6) unstable; urgency=medium
 
   [ Adrian Bunk ]
diff -Naur endless-sky-0.10.2/debian/control endless-sky-0.10.4/debian/control
--- endless-sky-0.10.2/debian/control   2023-10-06 09:23:26.0 -0400
+++ endless-sky-0.10.4/debian/control   2024-01-07 20:42:17.0 -0500
@@ -8,7 +8,7 @@
 Vcs-Git: https://salsa.debian.org/games-team/endless-sky.git
 Homepage: https://endless-sky.github.io
 Build-Depends:
- cmake,
+ cmake (>= 3.21),
  debhelper-compat (= 13),
  g++ (>=4.6),
  libgl-dev,
diff -Naur endless-sky-0.10.2/debian/patches/atomics.patch 
endless-sky-0.10.4/debian/patches/atomics.patch
--- endless-sky-0.10.2/debian/patches/atomics.patch 2023-10-05 
06:08:09.0 -0400
+++ endless-sky-0.10.4/debian/patches/atomics.patch 2024-01-07 
20:42:17.0 -0500
@@ -1,17 +1,24 @@
-Description: link with libatomic
- On armel and mipsel, there are a bunch of missing __atomic_load_8 symbols
- during linking
- .
- These are provided by libatomic and that is even in the build-dependencies,
- but is missing on the linker command line.
- .
- The right spot to add it is a bit tricky, appending it to SConstrict near
- 'pthread' doesn't seem to have any effect, but adding to CMakeLists.txt works.
-Author: Damyan Ivanov 
+From: Damyan Ivanov 
+Date: Mon, 8 Jan 2024 07:21:47 +0800
+Subject: link with libatomic
 
+On armel and mipsel, there are a bunch of missing __atomic_load_8 symbols
+during linking
+
+These are provided by libatomic and that is even in the build-dependencies,
+but is missing on the linker command line.
+
+The right spot to add it is a bit tricky, appending it to SConstrict near
+'pthread' doesn't seem to have any effect, but adding to CMakeLists.txt works.
+---
+ CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index fa0903a..d7807e9 100644
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
-@@ -123,7 +123,7 @@ target_link_libraries(ExternalLibraries
+@@ -125,7 +125,7 @@ target_link_libraries(ExternalLibraries INTERFACE 
SDL2::SDL2 PNG::PNG JPEG::JPEG
  if(WIN32)
target_link_libraries(ExternalLibraries INTERFACE rpcrt4 Winmm)
  else()
diff -Naur endless-sky-0.10.2/debian/patches/series 
endless-sky-0.10.4/debian/patches/series
--- endless-sky-0.10.2/debian/patches/series2023-10-05 02:53:48.0 
-0400
+++ endless-sky-0.10.4/debian/patches/series2024-01-07 20:42:17.0 
-0500
@@ -1,3 +1 @@
-out/troff.patch
-out/spelling.patch
 atomics.patch
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#725312: Ohai does not detect python3

[Vivek K J]

Hello,

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

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


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



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


-- 
Regards,

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

OpenPGP_0xA5FF4BB3EA53C5DF.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060062: bootcd: can not exclude folders with files bigger than 4GB inside

[Hans-J. Ullrich]

Package: bootcd
Version: 6.6.5
Severity: important

Dear Maintainer,

when trying to ignore a folder with files bigger than 4GB, I get the following 
error message:

--  snip -

bootcdwrite -m -y -c */root/bootcdwrite.conf* 
--- Checking for possible Problems --- 
--- Cleanup --- 
--- WARNING --- 
S_NEED_COMPRESS > S_VAR (113717304 > 72959976)  
To enable compression there must be much space (S_VAR) 
available in /var/spool/bootcd to hold extra space for compression. 
We need double as much space (S_NEED_COMPRESS) as will be copied to CD. 
but the space available is not enough 
i (-y) 
--- Sizes in KByte (du -klsc ) --- 
NOT_TO_CD =  . . . . . . . . . . . . . . . . . . . . . . . . . . . 24176524 
CD_ALL (SRCDISK v NOT_TO_CD) = . . . . . . . . . . . . . . . . . . 81035176 
Needed = CD_ALL - NOT_TO_CD  . . . . . . . . . . . . . . . . . . . 56858652 
DVD+ (4.7 billion bytes) = . . . . . . . . . . . . . . . . . . . . 470 
because of compression perhaps double size = . . . . . . . . . . . 940 
--- WARNING --- 
SRCDISK does not fit on DVD (Needed > DVD) 
You can exclude files/dirs in NOT_TO_CD in bootcdwrite.conf. 
You can try to ignore this problem, if you only want an iso image. 
i (-y) 
VAR =  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72959976 
OK - enough space in /var/spool/bootcd (Needed <= VAR) 
--- Building Modifications --- 
--- do function extra_changes --- 
--- Creating CD-Image --- 
ERROR: ia premature exit of  
unchecked output: <10+0 records in 
10+0 records out 
10485760 bytes (10 MB, 10 MiB) copied, 0.0209077 s, 502 MB/s 
mkfs.fat 4.2 (2021-01-31) 
/usr/bin/bootcdwrite: 477: eval: MKISOFS: parameter not set>

- snap --

I could not find any related information of this, either in th elogfiles, nor 
in the internet.

For me, it looks like a bug. 

Another thing (maybe the same reason): Folders with a space in the name, like 
"VirtualBox VMs", can not be recognized. Even when masking the name, like 
"VirtualBox\ VM" it recognizes two folders: "VirtualBox\" and "VM". The 
trailing slash is beeing ignored.


I am happy for any help.

Best regards

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

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

Versions of packages bootcd depends on:
ii  busybox1:1.35.0-4+b3
ii  cpio   2.13+dfsg-7.1
ii  dosfstools 4.2-1
ii  e2fsprogs  1.47.0-2
ii  fdisk  2.38.1-5+b1
ii  file   1:5.44-3
ii  genisoimage9:1.1.11-3.4
ii  grub-efi-amd64-bin 2.06-13+deb12u1
ii  initramfs-tools0.142
ii  isolinux   3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  lsb-base   11.6
ii  rsync  3.2.7-1
ii  shellia5.7.6
ii  syslinux   3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
ii  syslinux-common3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  sysvinit-utils [lsb-base]  3.06-4
ii  util-linux 2.38.1-5+b1
ii  uuid-runtime   2.38.1-5+b1
ii  xorriso1.5.4-4

Versions of packages bootcd recommends:
ii  wodim  9:1.1.11-3.4

Versions of packages bootcd suggests:
pn  aufs-tools  
ii  discover2.1.2-10
pn  elilo   
ii  ssh 1:9.2p1-2+deb12u2

-- debconf-show failed

Bug#974220: #974220 libreoffice-writer: Double paste in Writer

[Mario J]

I just installed Debian 12 and bug still happens.

Bug#1059939: linux-image-6.1.0-17-rt-amd64: dkms will not build zfs module for rt-amd64

[T. J. Pinkert]

Package: src:linux
Version: 6.1.69-1
Severity: normal
X-Debbugs-Cc: t.j.pink...@alumnus.utwente.nl

Dear Maintainer,

I tried to install linux-image-6.1.0-17-rt-amd64, building zfs modules with
dkms failed.
The output of aptitude while installing the packages is appended to this
report.

The important line seems to be:
Error! The /var/lib/dkms/zfs/2.1.11/6.1.0-17-rt-amd64/x86_64/dkms.conf for
module zfs includes a BUILD_EXCLUSIVE directive which does not match this
kernel/arch/config

Somehow the directory 6.1.0-17-rt-amd64 seems to be missing.
---
$ ls /var/lib/dkms/zfs/2.1.11/
6.1.0-16-amd64  6.1.0-17-amd64  source
---

whether this is a flaw in the installer script or in the zfs package is unclear
to me.

The expected outcome is, logically, that the dkms modules would all compile as
they do on the normal amd64 kernel image.

Best regards,


Tjeerd Pinkert



Output of aptitude install process on the terminal:
-
Performing actions...
Selecting previously unselected package linux-headers-6.1.0-17-rt-amd64.
(Reading database ... 744179 files and directories currently installed.)
Preparing to unpack .../linux-headers-6.1.0-17-rt-amd64_6.1.69-1_amd64.deb ...
Unpacking linux-headers-6.1.0-17-rt-amd64 (6.1.69-1) ...
Selecting previously unselected package linux-image-6.1.0-17-rt-amd64.
Preparing to unpack .../linux-image-6.1.0-17-rt-amd64_6.1.69-1_amd64.deb ...
Unpacking linux-image-6.1.0-17-rt-amd64 (6.1.69-1) ...
Selecting previously unselected package linux-image-rt-amd64.
Preparing to unpack .../linux-image-rt-amd64_6.1.69-1_amd64.deb ...
Unpacking linux-image-rt-amd64 (6.1.69-1) ...
Setting up linux-image-6.1.0-17-rt-amd64 (6.1.69-1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.1.0-17-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-6.1.0-17-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.0-17-rt-amd64
I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-17-rt-amd64
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-17-rt-amd64.
Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub
Error! The /var/lib/dkms/zfs/2.1.11/6.1.0-17-rt-amd64/x86_64/dkms.conf for
module zfs includes a BUILD_EXCLUSIVE directive which does not match this
kernel/arch/config.
This indicates that it should not be built.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.1.0-17-rt-amd64 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
dpkg: error processing package linux-image-6.1.0-17-rt-amd64 (--configure):
 installed linux-image-6.1.0-17-rt-amd64 package post-installation script
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-rt-amd64:
 linux-image-rt-amd64 depends on linux-image-6.1.0-17-rt-amd64 (= 6.1.69-1);
however:
  Package linux-image-6.1.0-17-rt-amd64 is not configured yet.

dpkg: error processing package linux-image-rt-amd64 (--configure):
 dependency problems - leaving unconfigured
Setting up linux-headers-6.1.0-17-rt-amd64 (6.1.69-1) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-17-rt-amd64.
Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub
Error! The /var/lib/dkms/zfs/2.1.11/6.1.0-17-rt-amd64/x86_64/dkms.conf for
module zfs includes a BUILD_EXCLUSIVE directive which does not match this
kernel/arch/config.
This indicates that it should not be built.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.1.0-17-rt-amd64 failed!
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 11
Failed to process /etc/kernel/header_postinst.d at /var/lib/dpkg/info/linux-
headers-6.1.0-17-rt-amd64.postinst line 11.
dpkg: error processing package linux-headers-6.1.0-17-rt-amd64 (--configure):
 installed linux-headers-6.1.0-17-rt-amd64 package post-installation script
subprocess returned error exit status 1
Errors were encountered while processing:
 linux-image-6.1.0-17-rt-amd64
 linux-image-rt-amd64
 linux-headers-6.1.0-17-rt-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up linux-image-6.1.0-17-rt-amd64 (6.1.69-1) ...
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-17-rt-amd64.
/usr/sbin/dkms: line 2497: echo: write error: Broken pipe
Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub
Error! The /var/lib/dkms/zfs/2.1.11/6.1.0-17-rt-amd64/x86_64/dkms.conf for
module zfs includes a BUILD_EXCLUSIVE directive which does not match this
kernel/arch/config.
This indicates that it should not be built.
Error! One or more 

Bug#1059329: cinnamon-desktop-environment: dependency on noto-font installs too many fonts, fontlist exploded.

[dr. ir. Tjeerd J. Pinkert]

Dear Fabio,

thanks for the quick reply. OK, so that is one issue less... then please 
close this bug?


I also made a reply to the fonts-noto main package. Both the exploding 
fontlist and difficult deinstallation are discussed there in threads:

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

Splitting out the Noto font in many language dependent files seems to be 
not so handy somehow... Unicode was invented to circumvent that issue...

However, the noto-core package still has many fonts installed.

Best regards,


Tjeerd Pinkert

On 12/22/23 17:06, Fabio Fantoni wrote:
Hi, this was already reported by other people and fixed in 5.8.0 (that 
is in unstable/testing) moving fonts-noto from deps to recommends.


I was thinking if it might be useful to further reduce the default 
installation (with recommended) by replacing fonts-noto with 
fonts-noto-core, but I don't know how much the fonts of the other 
packages recommended by fonts-noto are used.

Bug#983291: Default font: Transition from DejaVu to Noto

[dr. ir. Tjeerd J. Pinkert]

Dear Fabian, List,

thanks for packaging fonts for Debian.

On Mon, 18 Sep 2023 13:28:36 +0200 Fabian Greffrath  
wrote:

> If I recall it correctly, the primary suggestion in that bug report
> is to split fonts-noto-core into an LCG and an "other" package.

I have created a MR to implement this:

https://salsa.debian.org/fonts-team/fonts-noto/-/merge_requests/1

 - Fabian


I was also struggling with the extensive font list issue. I managed to 
deinstall the font today to get rid of the annoyance. Of course, I am 
now also rid of a set of type faces.


Why are there so many language specific font files in the package? I'm 
not the most knowledgeable person in this field, but, is it not the idea 
of a unicode font to be capable to include all languages in a single 
font file for one font style / typeface? Then the list of Noto fonts 
would slink to only the various styles available (20 or so?).


- Are there technical boundaries that prevent this other than file size?
- Would this be something to discuss with upstream how to tackle this?

I would guess not only Debian faces these problems with Noto?

Another thought would be to split the package out super fine grained, 
and make the font installation depend on the language selection of the 
users? That would be a lot of work though. I guess there is not an easy 
solution, but people are struggling with this font as can be seen by the 
various bug reports mentioned in this thread. Especially the fact that a 
huge list of fonts is generated by the way the files are structured.


The issue will become harder when more software starts to depend on 
Noto, I had both cinnamon and texlive dependencies. Even only the noto 
core was too much for my taste...


Best regards,


Tjeerd Pinkert

Bug#1059329: cinnamon-desktop-environment: dependency on noto-font installs too many fonts, fontlist exploded.

[T. J. Pinkert]

Package: cinnamon-desktop-environment
Version: 5.6.0
Severity: whishlist
X-Debbugs-Cc: t.j.pink...@alumnus.utwente.nl

Dear Maintainer,

to have several desktop environments available on my computer, I installed the
cinnamon desktop environment.
This package has a hard dependency on the noto-font package. Latter package
contains fonts for all unicode languages, and it is thus not a bad idea to have
that installed per-see.
But since there are for every language about 10 to 20 fonts installed, the
fontlist on my computer "exploded".
This is a hussle as font selection should not be cumbersome, but usefull.
Scrolling along a list of hundreds of noto fonts to come to the next usefull
font is clearly not.

When I tried to deinstall the noto-font, the dependency on this package tried
to deinstall also part of the cinnamon desktop.
I could work around it though, by manually selecting all packages that were to
be deinstalled. However must this be?

For me the question is, is the dependency on the noto-font really necessary? Or
is it a nice to have?
Could the noto-font be a recommended package? That would allow easier
deinstallation when wanted.

Another solution could be to separate the noto-font out into a much finer
selection of font packages, such that only those for installed languages are
installed.
I do understand that native speakers of, say, thai, may want the thai part of
the noto-font, but we "westerners" do typically not need that part of this huge
font base.

I hope some thoughts on this will help to make Debian better.

Best regards,


Tjeerd Pinkert


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

Kernel: Linux 6.1.0-16-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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cinnamon-desktop-environment depends on:
ii  atril [pdf-viewer]   1.26.0-2+b1
ii  cinnamon-core5.6.0
ii  eog  43.2-1
ii  evince [pdf-viewer]  43.1-2+b1
ii  fonts-liberation 1:1.07.4-11
pn  fonts-noto   
ii  gnome-calculator 1:43.0.1-2
ii  gnome-screenshot 41.0-2
ii  gnome-text-editor43.2-1
ii  gv [pdf-viewer]  1:3.7.4-2+b1
ii  xdg-user-dirs-gtk0.11-1

Versions of packages cinnamon-desktop-environment recommends:
ii  blueman  2.3.5-2+b1
ii  brasero  3.12.3-2
ii  bsd-mailx [mail-reader]  8.1.2-0.20220412cvs-1
ii  cheese   43.0-1
ii  chromium [www-browser]   120.0.6099.129-1~deb12u1
ii  cups 2.4.2-3+deb12u5
ii  deja-dup 44.0-2
ii  evolution [mail-reader]  3.46.4-2
ii  firefox-esr [www-browser]115.6.0esr-1~deb12u1
ii  gdebi0.9.5.7+nmu6
ii  gnome-characters 43.1-1+deb12u1
ii  gnome-disk-utility   43.0-1
ii  gnome-font-viewer43.0-1
ii  gnome-games  1:43+1
ii  gnome-logs   43.0-1
ii  gnome-software   43.5-1~deb12u1
ii  gnome-sound-recorder 43~beta-1
ii  gnome-system-monitor 42.0-2
ii  gnote43.1-1
ii  gstreamer1.0-libav   1.22.0-2
ii  gstreamer1.0-plugins-ugly1.22.0-2+deb12u1
ii  hexchat  2.16.1-1+b3
ii  libreoffice-calc 4:7.4.7-1+deb12u1
ii  libreoffice-gnome4:7.4.7-1+deb12u1
ii  libreoffice-impress  4:7.4.7-1+deb12u1
ii  libreoffice-writer   4:7.4.7-1+deb12u1
ii  lynx [www-browser]   2.9.0dev.12-1
ii  mate-themes  3.22.23-1
ii  mpv  0.35.1-4
ii  orca 43.1-1
ii  pidgin   2.14.12-1
ii  remmina  1.4.29+dfsg-1
ii  rhythmbox3.4.6-2+b1
ii  rhythmbox-plugin-cdrecorder  3.4.6-2+b1
ii  rhythmbox-plugins3.4.6-2+b1
ii  seahorse 43.0-1
ii  shotwell 0.30.17-1+b1
ii  simple-scan  42.5-2
ii  smplayer 22.7.0~ds0-1
ii  sound-juicer 3.38.0-2.1
ii  sound-theme-freedesktop  0.8-2
ii  synaptic 0.91.3
ii  system-config-printer1.5.18-1
ii  thunderbird [mail-reader]1:115.6.0-1~deb12u1
ii  totem43.0-2
ii  transmission-gtk 3.00-2.1+deb12u1
pn  vino | x2goserver
ii  vlc  3.0.20-0+deb12u1
ii  yelp 42.2-1
ii  zenity   3.44.0-1

Versions of packages cinnamon-desktop-environment suggests:
pn  gedit-plugins   
ii  gimp

Bug#942274: uscan: handling several levels of http links

[P. J. McDermott]

On Sun, 13 Oct 2019 18:36:51 +0200 Samuel Thibault  wrote:
> Package: devscripts
> Version: 2.19.6
> Severity: wishlist
> 
> Hello,
> 
> For the hwloc package, there is on single webpage that references all
> releases.
> 
[...]
> 
> But this doesn't seem supported. Am I missing something or is handling
> several levels of http links not supported?

I've run into this with the 7kaa-music package:
https://salsa.debian.org/games-team/7kaa-music

Upstream lists versions at:
https://www.7kfans.com/download/
That page links to pages such as:
https://www.7kfans.com/download/v2.15.6.html
And those pages link to the tar archive:
https://www.7kfans.com/downloads/7kaa-music-2.15.tar.bz2

So I need uscan to somehow recurse from the main download page to the
latest version's page to find the tar archive link.

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1059274: ITP: 7kaa-music -- Seven Kingdoms: Ancient Adversaries - music soundtrack

[P. J. McDermott]

Package: wnpp
Severity: wishlist
Owner: "P. J. McDermott" 
X-Debbugs-Cc: debian-devel-ga...@lists.debian.org, p...@pehjota.net

* Package name: 7kaa-music
  Version : 2.15
  Upstream Author : Bjorn Lynne, Enlight Software Ltd.,
Jesse Allen 
* URL : https://www.7kfans.com/download/
* License : Custom non-free license
  Description : Seven Kingdoms: Ancient Adversaries - music
soundtrack

Seven Kingdoms, designed by Trevor Chan, brings a unique blend of
real-time strategy with the addition of trade, diplomacy, and espionage.

This package contains the optional original music from the 1997 release
of Seven Kingdoms.

---

This package provides the optional music for the 7kaa package, which is
already in Debian and already "Suggests: 7kaa-music (>= 2.15)".

I will maintain this within the Debian Games Team and will get
sponsorship there.

Packaging exists at <https://salsa.debian.org/games-team/7kaa-music> and
is awaiting review and upload by a sponsor.

Bug#1034649: 7kaa: Unplugging USB headset hangs 7kaa

[P. J. McDermott]

Hi Nils,

On Thu, 20 Apr 2023 22:20:34 +0200 Nils Dagsson Moskopp 
 wrote:
> whenever I unplug the USB headset while 7kaa is running, it hangs.
> 7kaa prints a single line of output to the terminal, quoted below:
> 
> > AL lib: (EE) ALCpulsePlayback_streamStateCallback: Received stream failure!

This looks like one of (many[1][2][3][4]) bugs in OpenAL's PulseAudio
backend (apparently OpenAL's upstream maintainer doesn't use PulseAudio,
which I don't either).  I found reports of it affecting at least one
other game.  If we can't solve it here, I'll reassign.

An apparent solution is to edit "/etc/openal/alsoft.conf" and under
"[pulse]" change "allow-moves" to "true".  Can you try this and report
whether that solves the issue?

It's also possible that there's an infinite loop somewhere in 7kaa's
src/openal/openal_audio.cpp triggered by this OpenAL error.  Could you
please install 7kaa-dbgsym, run 7kaa under gdb, reproduce the hang, and
get a backtrace?

$ apt install 7kaa-dbgsym gdb
$ gdb 7kaa
(gdb) run
^C
(gdb) backtrace
(gdb) quit

> Versions of packages 7kaa depends on:
[...]
> ii  libopenal1   1:1.19.1-2

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548373
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551018
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562524
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566634
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1057926: 403 Access Denied on some packages on official Debian repo

[Juan J. Fernandez]

Package: linux-image-6.1.0-14-rt-amd64
Version: 6.1.64-1

When I run apt upgrade command it shows Error 403 Access Denied
Here is a transcript:

E: Failed to fetch 
http://ftp.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.1.0-14-rt-amd64_6.1.64-1_amd64.deb
  403  Access denied - broken package [IP: 151.101.126.132 80]

I suggest that the file permissions be corrected

I am using Debian GNU/Linux 12 Bookworm, kernel 6.5.11-7-pve


Thanks for fix it,
Cheers
JJ

E: Failed to fetch 
https://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.1.0-14-cloud-amd64_6.1.64-1_amd64.deb
  403  Access denied - broken package [IP: 151.101.54.132 443]

E: Failed to fetch 
https://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-cloud-amd64_6.1.64-1_amd64.deb
  403  Access denied - broken package [IP: 151.101.54.132 443]

E: Failed to fetch 
http://ftp.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.1.0-14-rt-amd64_6.1.64-1_amd64.deb
  403  Access denied - broken package [IP: 151.101.126.132 80]

E: Failed to fetch 
http://ftp.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-rt-amd64_6.1.64-1_amd64.deb
  403  Access denied - broken package [IP: 151.101.126.132 80]

Sent from Mail for Windows

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Darrick J. Wong]

On Fri, Oct 27, 2023 at 06:19:33PM +0200, Anthony Iliopoulos wrote:
> On Fri, Oct 27, 2023 at 08:45:05AM -0700, Darrick J. Wong wrote:
> > 
> > mkfs.xfs in xfsprogs 6.5 turned on both the large extent counts and
> > reverse mapping btree features by default.  My guess is that grub hasn't
> > caught up with those changes to the ondisk format yet.
> > 
> > Ah, yeah, upstream grub hasn't picked up large extent counts (internally
> > called nrext64) yet.
> > https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/fs/xfs.c#n83
> 
> Yeap it is due to nrext64, I've submitted a patch to grub (should have
> cc'ed linux-xfs..)
> 
> https://lore.kernel.org/grub-devel/20231026095339.31802-1-ail...@suse.com/

FWIW the patch turning on nrext64 by default was intended for xfsprogs
6.6, but the maintainer decided to merge it early.  No complaints here,
but that was a little sooner than I had intended.

--D

> Regards,
> Anthony

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Darrick J. Wong]

On Fri, Oct 27, 2023 at 05:20:42PM +0200, Philip Hands wrote:
> Philip Hands  writes:
> ...
> > Could this be related to #1051543?
> >
> > I'll try testing D-I while using the patch from that bug, to see if that 
> > helps.
> 
> It seems (to me at least) that the patch there does not apply usefully
> to the version we're talking about, so I'll leave it to people that know
> more about grub & XFS to look further.

>From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054644#5:

> > I note that if one runs e.g.:  grub-probe -d /dev/vda1
> > at the moment of failure, the XFS filesystem is not recognised
> > (despite being mounted as XFS at that moment).
> > 
> > Could this be related to #1051543?
> > 
> > I'll try testing D-I while using the patch from that bug, to see if that
> > helps.

I noticed this too while migrating to Debian 12 -- if you mkfs.xfs a
/boot with feature flags that grub doesn't know about, grub-install
unhelpfully refuses to recognize that there's a filesystem there at all.

mkfs.xfs in xfsprogs 6.5 turned on both the large extent counts and
reverse mapping btree features by default.  My guess is that grub hasn't
caught up with those changes to the ondisk format yet.

Ah, yeah, upstream grub hasn't picked up large extent counts (internally
called nrext64) yet.
https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/fs/xfs.c#n83

If you can manually reformat the filesystem from within the installer
with

mkfs.xfs -c /usr/share/xfsprogs/mkfs/lts_6.1.conf

Does grub start to recognize the filesystem again?

> 
> =-=-=
> 
> BTW the jobs where this failure first occured are:
> 
> (BIOS)  https://openqa.debian.net/tests/198911
> (UEFI)  https://openqa.debian.net/tests/198912
> 
> and the immediately previous working jobs are these:
> 
> (BIOS)  https://openqa.debian.net/tests/198840
> (UEFI)  https://openqa.debian.net/tests/198841
> 
> In the jobs you can see a 'Logs & Assets' tab, where you can find e.g.
> the syslog from the D-I run.
> 
> Here's the one from the first BIOS failure:
> 
>   https://openqa.debian.net/tests/198911/logfile?filename=DI_syslog.txt

Curiously, this log says:

Oct 24 05:35:32 in-target: Setting up xfsprogs (6.4.0-1) ...^M

So ... is it running 6.4 and not 6.5?

--D

> 
> One thing I notice when comparing that to the matching successful log:
> 
>   
> https://openqa.debian.net/tests/198840/logfile?filename=complete_install-DI_syslog.txt
> 
> is that they both include a block of lines like:
> 
>grub-installer: Unknown device "/dev/vda1": No such device
> 
> so that's just noise by the looks of it, since it was also saying that
> when it was working.
> 
> I've since slightly reorganised the openQA jobs, to have a job that only
> differs from the normal minimal install by the selection of XFS, so if
> you want to see currently failing jobs, they will be the ones called
> nonGUI_XFS@64bit & nonGUI_XFS (for BIOS & UEFI installs, respectively)
> in this overview:
> 
>   https://openqa.debian.net/tests/overview?distri=debian=10
> 
> HTH
> 
> Cheers, Phil.
> -- 
> Philip Hands -- https://hands.com/~phil

Bug#1053459: elasticsearch-curator: curator_cli does not work against system installed python3-click

[J]

Package: elasticsearch-curator
Version: elasticsearch-curator
Severity: normal

Dear Maintainer,

curator_cli, which is provided by the elasticsearch-curator package,
seems to depend on a different version of the python "click" module than
is installed by the python3-click package. This renders curator_cli
unusable without pip installing an appropriate click version.

I expected elasticsearch-curator to provide a curator_cli which matches
the click provided by python3-click.

To reproduce on a fresh bookworm install:

# apt install elasticsearch-curator

and attempt to run curator_cli without any arguments. You should see
this traceback:

$ curator_cli
Traceback (most recent call last):
  File "/usr/bin/curator_cli", line 33, in 
sys.exit(load_entry_point('elasticsearch-curator==5.8.1', 
'console_scripts', 'curator_cli')())
 
^^
  File "/usr/bin/curator_cli", line 25, in importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/curator/curator_cli.py", line 2, in 

from curator.singletons import cli
  File "/usr/lib/python3/dist-packages/curator/singletons.py", line 7, in 

from curator.cli_singletons.alias import alias
  File "/usr/lib/python3/dist-packages/curator/cli_singletons/alias.py", line 
5, in 
@click.command(context_settings=get_width())
^^^
  File "/usr/lib/python3/dist-packages/curator/cli_singletons/utils.py", line 
34, in get_width
return dict(max_content_width=click.get_terminal_size()[0])
  ^^^
AttributeError: module 'click' has no attribute 'get_terminal_size'


Let me know if you need any more information, although I think this is
pretty straightforward to reproduce.

Thanks!

-- System Information:
Debian Release: 12.1
  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-12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elasticsearch-curator depends on:
ii  python33.11.2-1+b1
pn  python3-elasticsearch-curator  
ii  python3-pkg-resources  66.1.1-1

elasticsearch-curator recommends no packages.

elasticsearch-curator suggests no packages.

Bug#1052000: logrotate systemd timer should run hourly rather than daily

[Todd J]

Package: logrotate
Version: 3.18.0-2+deb11u1
Severity: normal

Dear Maintainer,

"hourly" rotation was added to logrotate in 2019(?).
However, the Debian systemd Timer runs "daily" so "hourly" logrotate jobs
are still only run daily.

Updating /etc/systemd/system/timers.target.wants/logrotate.timer:
...
[Timer]
OnCalendar=hourly
...

should allow "logrotate hourly" to work as expected.

See https://github.com/logrotate/logrotate/issues/249#issuecomment-485829363
"The tricky part is that one needs to change the default cron hook
(or systemd timer) to make hourly actually work as expected."

Thanks!

-- Package-specific info:
Contents of /etc/logrotate.d
total 44
-rw-r--r-- 1 root root 120 Aug 20  2022 alternatives
-rw-r--r-- 1 root root 173 Jun 10  2021 apt
-rw-r--r-- 1 root root 130 Oct 14  2019 btmp
-rw-r--r-- 1 root root 112 Aug 20  2022 dpkg
-rw-r--r-- 1 root root 128 May  4  2021 exim4-base
-rw-r--r-- 1 root root 108 May  4  2021 exim4-paniclog
-rw-r--r-- 1 root root 354 Nov 23  2020 fail2ban
-rw-r--r-- 1 root root 173 Nov  4  2020 monitorix
-rw-r--r-- 1 root root 374 May 20  2022 rsyslog.disabled
-rw-r--r-- 1 root root 534 Feb 28  2023 syslog-ng
-rw-r--r-- 1 root root 145 Oct 14  2019 wtmp


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

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

Versions of packages logrotate depends on:
ii  anacron 2.3-30
ii  cron [cron-daemon]  3.0pl1-137
ii  libacl1 2.2.53-10
ii  libc6   2.31-13+deb11u6
ii  libpopt01.18-2
ii  libselinux1 3.1-3
ii  systemd-sysv247.3-7+deb11u4

Versions of packages logrotate recommends:
ii  mailutils [mailx]  1:3.10-3+b1

logrotate suggests no packages.

-- no debconf information

Bug#1050148: Bug fixed

[Z J]

Dear Maintainer,

This bug is fixed in next kernel update: 6.1.0-12.

Thanks,

Jiandong Zheng

Bug#1051326: systemsettings: A lot of icons are just black squares

[j]

On 06/09/2023 19:21, Lisandro Damián Nicanor Pérez Meyer wrote:

The question is: did you manually install any *-gles package yourself? They 
shouldn't be automatically installed, but we had issues like that before. If 
you have any dpkg/apt logs, the better.


It was not installed manually as far as i remember but sadly no logs left over 
from the time libqt5quick5-gles was pulled in, the system has been installed 
for a long time so this could go back years. If I encounter the issue on other 
installations will try to see if I can find any trace.

Bug#1051326: systemsettings: A lot of icons are just black squares

[j]

Tags: fixed

turns out the issue was libqt5quick5-gles everything looks correct after 
installing libqt5quick5
is there any way to avoid libqt5quick5-gles getting installed on desktops?

Bug#1050148: linux-image-6.1.0-11-amd64: When Ryzen2(4800H) system resume from sleep, mouse and keyboard become sluggish and unusable.

[Z J]

Package: src:linux
Version: 6.1.38-4
Severity: important

Dear Maintainer,

This happens every time back from sleep. Keyboard input in remote ssh 
session works OK.

Older version 6.1.0-9/10 is usable but can still see this issue.

Thanks,

Jiandong Zheng

-- Package-specific info:
** Version:
Linux version 6.1.0-11-amd64 (debian-ker...@lists.debian.org) (gcc-12 
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.38-4 (2023-08-08)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-11-amd64 
root=UUID=fceb24e4-1a93-4cbb-baee-ba8f6a7111f4 ro quiet


** Not tainted

** Kernel log:
[ 4326.678606] microcode: CPU9: patch_level=0x08600103
[ 4326.681343] ACPI: \_SB_.PLTF.P009: Found 3 idle states
[ 4326.681351] ACPI: FW issue: working around C-state latencies out of order
[ 4326.682787] CPU9 is up
[ 4326.682821] smpboot: Booting Node 0 Processor 10 APIC 0xa
[ 4326.681170] microcode: CPU10: patch_level=0x08600103
[ 4326.683598] ACPI: \_SB_.PLTF.P00A: Found 3 idle states
[ 4326.683609] ACPI: FW issue: working around C-state latencies out of order
[ 4326.685940] CPU10 is up
[ 4326.685976] smpboot: Booting Node 0 Processor 11 APIC 0xb
[ 4326.683252] microcode: CPU11: patch_level=0x08600103
[ 4326.686423] ACPI: \_SB_.PLTF.P00B: Found 3 idle states
[ 4326.686430] ACPI: FW issue: working around C-state latencies out of order
[ 4326.688184] CPU11 is up
[ 4326.688231] smpboot: Booting Node 0 Processor 12 APIC 0xc
[ 4326.686237] microcode: CPU12: patch_level=0x08600103
[ 4326.689093] ACPI: \_SB_.PLTF.P00C: Found 3 idle states
[ 4326.689102] ACPI: FW issue: working around C-state latencies out of order
[ 4326.690978] CPU12 is up
[ 4326.691015] smpboot: Booting Node 0 Processor 13 APIC 0xd
[ 4326.688690] microcode: CPU13: patch_level=0x08600103
[ 4326.691454] ACPI: \_SB_.PLTF.P00D: Found 3 idle states
[ 4326.691460] ACPI: FW issue: working around C-state latencies out of order
[ 4326.693493] CPU13 is up
[ 4326.693527] smpboot: Booting Node 0 Processor 14 APIC 0xe
[ 4326.691278] microcode: CPU14: patch_level=0x08600103
[ 4326.694211] ACPI: \_SB_.PLTF.P00E: Found 3 idle states
[ 4326.694220] ACPI: FW issue: working around C-state latencies out of order
[ 4326.696372] CPU14 is up
[ 4326.696413] smpboot: Booting Node 0 Processor 15 APIC 0xf
[ 4326.693945] microcode: CPU15: patch_level=0x08600103
[ 4326.696877] ACPI: \_SB_.PLTF.P00F: Found 3 idle states
[ 4326.696884] ACPI: FW issue: working around C-state latencies out of order
[ 4326.699160] CPU15 is up
[ 4326.700676] ACPI: PM: Waking up from system sleep state S3
[ 4326.705395] pci :00:00.2: can't derive routing for PCI INT A
[ 4326.705400] pci :00:00.2: PCI INT A: no GSI
[ 4326.705606] [drm] PCIE GART of 1024M enabled.
[ 4326.705608] [drm] PTB located at 0x00F41FC0
[ 4326.705620] [drm] PSP is resuming...
[ 4326.713348] nvme nvme0: 16/0/0 default/read/poll queues
[ 4326.725459] [drm] reserve 0x40 from 0xf41f80 for PSP TMR
[ 4326.802889] amdgpu :04:00.0: amdgpu: RAS: optional ras ta ucode 
is not available
[ 4326.810528] amdgpu :04:00.0: amdgpu: RAP: optional rap ta ucode 
is not available
[ 4326.814629] [drm] psp gfx command LOAD_TA(0x1) failed and response 
status is (0x7)
[ 4326.814744] [drm] psp gfx command INVOKE_CMD(0x3) failed and response 
status is (0x4)

[ 4326.814746] amdgpu :04:00.0: amdgpu: Secure display: Generic Failure.
[ 4326.814747] amdgpu :04:00.0: amdgpu: SECUREDISPLAY: query 
securedisplay TA failed. ret 0x0

[ 4326.814751] amdgpu :04:00.0: amdgpu: SMU is resuming...
[ 4326.814791] amdgpu :04:00.0: amdgpu: dpm has been disabled
[ 4326.815563] amdgpu :04:00.0: amdgpu: SMU is resumed successfully!
[ 4326.816243] [drm] DMUB hardware initialized: version=0x01010026
[ 4326.847559] [drm] kiq ring mec 2 pipe 1 q 0
[ 4326.850727] [drm] VCN decode and encode initialized 
successfully(under DPG Mode).

[ 4326.850769] [drm] JPEG decode initialized successfully.
[ 4326.850777] amdgpu :04:00.0: amdgpu: ring gfx uses VM inv eng 0 
on hub 0
[ 4326.850779] amdgpu :04:00.0: amdgpu: ring comp_1.0.0 uses VM inv 
eng 1 on hub 0
[ 4326.850781] amdgpu :04:00.0: amdgpu: ring comp_1.1.0 uses VM inv 
eng 4 on hub 0
[ 4326.850782] amdgpu :04:00.0: amdgpu: ring comp_1.2.0 uses VM inv 
eng 5 on hub 0
[ 4326.850784] amdgpu :04:00.0: amdgpu: ring comp_1.3.0 uses VM inv 
eng 6 on hub 0
[ 4326.850786] amdgpu :04:00.0: amdgpu: ring comp_1.0.1 uses VM inv 
eng 7 on hub 0
[ 4326.850787] amdgpu :04:00.0: amdgpu: ring comp_1.1.1 uses VM inv 
eng 8 on hub 0
[ 4326.850789] amdgpu :04:00.0: amdgpu: ring comp_1.2.1 uses VM inv 
eng 9 on hub 0
[ 4326.850790] amdgpu :04:00.0: amdgpu: ring comp_1.3.1 uses VM inv 
eng 10 on hub 0
[ 4326.850792] amdgpu :04:00.0: amdgpu: ring kiq_2.1.0 uses VM inv 
eng 11 on hub 0
[ 4326.850793] amdgpu :04:00.0: amdgpu: ring sdma0 uses VM inv eng 0 
on hub 1
[ 4326.850795] amdgpu :04:00.0: amdgpu: ring vcn_dec uses VM inv 

Bug#1050145: RFS: qpsmtpd/0.94-6 [ITA] -- Flexible SMTP daemon for network-level spam detection

[Peter J. Holzer]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : qpsmtpd
   Version  : 0.94-6
 * URL  : https://github.com/smtpd/qpsmtpd
   Section  : mail

The source builds the following binary packages:

  qpsmtpd - Flexible SMTP daemon for network-level spam detection

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/q/qpsmtpd/qpsmtpd_0.94-6.dsc

Changes since the last upload:

 qpsmtpd (0.94-6) unstable; urgency=medium
 .
   * Fix #933679

The qpsmtpd package has been orphaned for 5+ years now. There have been
3 upstream releases during that time. So I'm interested in adopting the
package to get a current version into Debian again. This upload however
only fixes a small but very annoying bug.

Regards,
hjp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature

Bug#919587: bringing back Imapsync

[J. Fernando LAGRANGE]

Hello,

I have made some changes to salsa repository, now
(as in commit e90472050852568d9a5232f8930701c7a22a19b8 )
package can be built with following commands:

git clone https://salsa.debian.org/fernando-guest/imapsync.git
cd imapsync
uscan --download-current-version
debuild

Regards,
Fernando


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040226: tomcat10: deployment-time Java EE to Jakarta EE migration fails

[J . Tóth Tamás]

Hi,


Please keep the bug report always in CC.


I thought my 8 August mail contains no new information, so it makes no 
sense to spam the BTS with it. But okay, next time (and this time) I’ll 
use Reply All regardless of the message content.



We’d like to gradually upgrade
to Bookworm, but I don’t want to make sysops’ lives more complicated by
giving them one WAR file to install on Bookworm and another one to
install on Bullseye.


[…] You can just manually run the tomcat-jakartaee-migration tool on
your existing war files. All it mainly does is to replace the old
occurrences of javax.* with jakarta.*.


That’s exactly what I meant by “making sysops’ lives more complicated by
giving them one WAR file to install on Bookworm and another one to 
install on Bullseye”, so it’s out of question for me in production.



You could also send a patch with your proposed changes to Debian's tomcat10 > 
package and I take a look at it.


I created https://salsa.debian.org/java-team/tomcat10/-/merge_requests/1 
– it’s quite likely wrong in its current form, but I hope it can be fixed.


Tamás

Bug#894892: libkscreenlocker5: unable to unlock locked screen ("unlocking failed")

[Hans-J. Ullrich]

Package: libkscreenlocker5
Version: 5.27.5-2
Followup-For: Bug #894892

Dear Maintainer,

tried with a fresh user, but no success. Verified and confirm, that "loginctl 
unlock-session XX" as normal user is unlockung the session. So it looks like 
this command might not be sent correctly from KDE.

Tested on two computers, both running debian bookworm, actual packages, same 
package status.

Both computers got this issue. NOT tested on my 32-bit system yet. 

I will tell more, if I got news.

Thanks for any help.

Best regards

Hans

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

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

Versions of packages libkscreenlocker5 depends on:
ii  kio5.103.0-1
ii  kpackagetool5  5.103.0-1
ii  libc6  2.36-9+deb12u1
ii  libkf5configcore5  5.103.0-2
ii  libkf5configgui5   5.103.0-2
ii  libkf5configqml5   5.103.0-2
ii  libkf5coreaddons5  5.103.0-1
ii  libkf5crash5   5.103.0-1
ii  libkf5declarative5 5.103.0-1
ii  libkf5globalaccel-bin  5.103.0-1
ii  libkf5globalaccel5 5.103.0-1
ii  libkf5i18n55.103.0-1
ii  libkf5idletime55.103.0-2
ii  libkf5kiocore5 5.103.0-1
ii  libkf5notifications5   5.103.0-1
ii  libkf5package5 5.103.0-1
ii  libkf5quickaddons5 5.103.0-1
ii  libkf5screendpms8  4:5.27.5-2
ii  libkf5waylandclient5   4:5.103.0-1
ii  libkf5windowsystem55.103.0-1
ii  libkf5xmlgui5  5.103.0-1
ii  liblayershellqtinterface5  5.27.5-2
ii  libpam0g   1.5.2-6
ii  libqt5core5a   5.15.8+dfsg-11
ii  libqt5dbus55.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
ii  libqt5widgets5 5.15.8+dfsg-11
ii  libqt5x11extras5   5.15.8-2
ii  libstdc++6 12.2.0-14
ii  libwayland-client0 1.21.0-1
ii  libwayland-server0 1.21.0-1
ii  libx11-6   2:1.8.4-2+deb12u1
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb11.15-1
ii  libxi6 2:1.8-1+b1
ii  psmisc 23.6-1

Versions of packages libkscreenlocker5 recommends:
ii  kde-config-screenlocker  5.27.5-2

libkscreenlocker5 suggests no packages.

-- debconf-show failed

Bug#919587: bringing back Imapsync

[J. Fernando LAGRANGE]

Hello,

Is there someone getting this beautiful software to Debian ?

If not, I volunteer to contribute.


Some more context on my part:
We use IMAPSync at work and I have built [1] a repo with it last year.

Now that Debian 12 is out, it has been decided that it was not worth 
maintaining a server only for this package, so we will remove such 
server. :'-(


(For now it is available in http://deb.probesys.com ; beware: no SSL !)


[1] With code available in salsa, build was pretty straightforward:

mkdir imapsync-build && cd imapsync-build
gbp clone https://salsa.debian.org/RAPS/imapsync.git
cd imapsync
git branch upstream
gbp import-orig 
https://imapsync.lamiral.info/dist/old_releases/1.945/imapsync-1.945.tgz

[version to indicate: 1.945+dfsg1 ]
gbp pq import
gbp buildpackage


Regards,
--
J. Fernando Lagrange
PROBESYS - Spécialistes OpenSource


OpenPGP_signature
Description: OpenPGP digital signature

Bug#894892: libkscreenlocker5: The file "/usr/lib/x86_64-linux-gnu/libexec/kcheckpass" is NOT existent in the stable package.

[Hans-J. Ullrich]

Package: libkscreenlocker5
Followup-For: Bug #894892

Dear Maintainer,

I discovered, that in the bookworm repo in the package libscreenlocker5, the 
mentioned file "kcheckpass" is not existent. Thus the above workaround does not 
work. 

I also tried to manually copy the file from bullseye with no success and 
suppose, kcheckpass from bullseye is incompatible with bookworm. Please repack 
the lib with the missing file.

Thank you very much.

Best regards

Hans
 

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

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

Versions of packages libkscreenlocker5 depends on:
ii  kio5.103.0-1
ii  kpackagetool5  5.103.0-1
ii  libc6  2.36-9+deb12u1
ii  libkf5configcore5  5.103.0-2
ii  libkf5configgui5   5.103.0-2
ii  libkf5configqml5   5.103.0-2
ii  libkf5coreaddons5  5.103.0-1
ii  libkf5crash5   5.103.0-1
ii  libkf5declarative5 5.103.0-1
ii  libkf5globalaccel-bin  5.103.0-1
ii  libkf5globalaccel5 5.103.0-1
ii  libkf5i18n55.103.0-1
ii  libkf5idletime55.103.0-2
ii  libkf5kiocore5 5.103.0-1
ii  libkf5notifications5   5.103.0-1
ii  libkf5package5 5.103.0-1
ii  libkf5quickaddons5 5.103.0-1
ii  libkf5screendpms8  4:5.27.5-2
ii  libkf5waylandclient5   4:5.103.0-1
ii  libkf5windowsystem55.103.0-1
ii  libkf5xmlgui5  5.103.0-1
ii  liblayershellqtinterface5  5.27.5-2
ii  libpam0g   1.5.2-6
ii  libqt5core5a   5.15.8+dfsg-11
ii  libqt5dbus55.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
ii  libqt5widgets5 5.15.8+dfsg-11
ii  libqt5x11extras5   5.15.8-2
ii  libstdc++6 12.2.0-14
ii  libwayland-client0 1.21.0-1
ii  libwayland-server0 1.21.0-1
ii  libx11-6   2:1.8.4-2+deb12u1
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb11.15-1
ii  libxi6 2:1.8-1+b1
ii  psmisc 23.6-1

Versions of packages libkscreenlocker5 recommends:
ii  kde-config-screenlocker  5.27.5-2

libkscreenlocker5 suggests no packages.

-- debconf-show failed

Bug#1039536: Info received (Bug#1039536 closed by Julien Cristau (Re: Bug#1039536: mirror submission for mirror.nasutek.com))

[Michael J. Manley]

Nevermind, both are fixed now, should now have Maintainer and Upstream-mirror 
in trace file.

Should also be updating like it should.

Bug#1004256: Default Hash: usesHtml2552279=EM_DWP_223146888=44191126_DEFAULT_HASH=1Fh3Sy4iCY3LZcyIAstAHRi66WYn1vGXiMdAGLiO1XSei Pkgs aI nter me diate1: ethereum/eip-review-b

[J Brutcheira]

ethereum/eip-review-bot@3e9905fcb72cf81ae9ed732df429c28b17e155b1

 
usesHtml2552279=EM_DWP_223146888=44191126_DEFAULT_HASH=1Fh3Sy4iCY3LZcyIAstAHRi66WYn1vGXiMdAGLiO1XSei
Pkgs aI nter me diate1:
ethereum/eip-review-bot@3e9905fcb72cf81ae9ed732df429c28b17e155b1
continue-on-error: truewith:  token: ${{ secrets.TOKEN }}
config: config/eip-editors.yml  pr_number: ${{
steps.save-pr-number.outputs.pr }}

Bug#1039536: closed by Julien Cristau (Re: Bug#1039536: mirror submission for mirror.nasutek.com)

[Michael J. Manley]

Hello,

Fixed the issue with the mirror not updating, seems to be odd it wasnt 
executing in cron.

Tho how do I get the trace file to set the Maintainer value?

- Original Message -
From: "Debian Bug Tracking System" 
To: "Michael Manley" 
Sent: Monday, July 31, 2023 8:36:03 AM
Subject: Bug#1039536 closed by Julien Cristau  (Re: 
Bug#1039536: mirror submission for mirror.nasutek.com)

This is an automatic notification regarding your Bug report
which was filed against the mirrors package:

#1039536: mirror submission for mirror.nasutek.com

It has been closed by Julien Cristau .

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 Julien Cristau 
 by
replying to this email.


-- 
1039536: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039536
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1042820: pim-data-exporter: Can not unpack ZIP file

[Hans-J. Ullrich]

Package: pim-data-exporter
Version: 4:22.12.3-1
Severity: important

Dear Maintainer,

I tried to import and export all mails and settings of kmail from one computer 
to another.

Using pimdataexporter I creyated a file called "kmail1.zip". This went well, 
but when I tried to unpack it, I got the error "Can not unpack kmail1.zip". In 
console it told "unexpected end" or so.

Thus, to refer the file itself is ok, I checked with "unzip kmail1.zip" and it 
could all be extracted.

Then repacked the whole files with ARK to a new zip file called "kmail2.zip" 
and tried again: It does not want to unpack the file. 


It would be nice, if you could take a look of it or tell me another solution.


Thanks for reading and have a nice day.

Best regards

Hans


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

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

Versions of packages pim-data-exporter depends on:
ii  kinit5.103.0-1
ii  kio  5.103.0-1
ii  libc62.36-9+deb12u1
ii  libgcc-s112.2.0-14
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-22.12]4:22.12.3-1
ii  libkf5akonadimime5 [libkf5akonadimime5-22.12]4:22.12.3-1
ii  libkf5akonadinotes5 [libkf5akonadinotes5-22.12]  4:22.12.3-1
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22.12]  4:22.12.3-1
ii  libkf5archive5   5.103.0-1
ii  libkf5calendarcore5abi2  5:5.103.0-1
ii  libkf5configcore55.103.0-2
ii  libkf5configgui5 5.103.0-2
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5contacts5  5:5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5crash5 5.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5identitymanagement5 [libkf5identitymanagement5-22.12]  22.12.3-1
ii  libkf5itemviews5 5.103.0-1
ii  libkf5kiocore5   5.103.0-1
ii  libkf5kiofilewidgets55.103.0-1
ii  libkf5kiogui55.103.0-1
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-22.12]  4:22.12.3-1
ii  libkf5mailtransport5 [libkf5mailtransport5-22.12]22.12.3-1
ii  libkf5mime5abi1 [libkf5mime5-22.12]  22.12.3-1
ii  libkf5notifications5 5.103.0-1
ii  libkf5pimcommon5abi2 [libkf5pimcommon5-22.12]4:22.12.3-1
ii  libkf5pimcommonakonadi5abi1 [libkf5pimcommonakonadi5-22.12]  4:22.12.3-1
ii  libkf5pimtextedit5abi2 [libkf5pimtextedit5-22.12]22.12.3-1
ii  libkf5widgetsaddons5 5.103.0-1
ii  libkf5xmlgui55.103.0-1
ii  libkuserfeedbackcore11.2.0-2
ii  libkuserfeedbackwidgets1 1.2.0-2
ii  libqt5core5a 5.15.8+dfsg-11
ii  libqt5gui5   5.15.8+dfsg-11
ii  libqt5widgets5   5.15.8+dfsg-11
ii  libstdc++6   12.2.0-14

pim-data-exporter recommends no packages.

pim-data-exporter suggests no packages.

-- debconf-show failed

Bug#1040647: ITP: ruby-neighbor -- Nearest neighbor search for Rails and Postgres

[Vivek K J]

Package: wnpp
Severity: wishlist
Owner: Vivek K J 
X-Debbugs-Cc: debian-de...@lists.debian.org, vive...@disroot.org

* Package name: ruby-neighbor
  Version : 0.2.3
  Upstream Contact: Andrew Kane 
* URL : https://github.com/ankane/neighbor
* License : Expat
  Programming Lang: Ruby
  Description : Nearest neighbor search for Rails and Postgres

Ruby package used for finding nearest neighbor search for Rails and Postgres.
This package will be maintained by Ruby Packaging team.

Bug#1040645: ITP: ruby-circuitbox -- Robust circuit breaker that manages failing external services

[Vivek K J]

Package: wnpp
Severity: wishlist
Owner: Vivek K J 
X-Debbugs-Cc: debian-de...@lists.debian.org, vive...@disroot.org

* Package name: ruby-circuitbox
  Version : 2.0.0
  Upstream Contact: Fahim Ferdous 
* URL : https://github.com/yammer/circuitbox
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Robust circuit breaker that manages failing external 
services

It protects your application from failures of its service dependencies. 
It wraps calls to external services and monitors for failures in one minute
intervals. Using a circuit's defaults once more than 5 requests have been 
made with a 50% failure rate, Circuitbox stops sending requests to that
failing service for 90 seconds. This helps your application gracefully degrade.

This package will be maintained by Ruby Packaging team.

Bug#1040226: tomcat10: deployment-time Java EE to Jakarta EE migration fails

[Tamás J . Tóth]

Hi,

I’ve installed the tomcat-jakartaee-migration package, but it still
throws the same exception. Are you sure the JAR file it contains is on
the classpath of Tomcat?

Also, thinking about what I would’ve done if this package was suggested
or even recommended – I probably wouldn’t have installed it. It’s
obvious that it’s suggested to use it if one *doesn’t* want to use the
deployment-time migration, so I would’ve thought that the suggestion is
because of that, not because it’s necessary for Tomcat to work properly.
If you decide to make it only a recommendation or suggestion, please
indicate in the package description of tomcat10 that it’s necessary for
the deployment-time migration.

I realized that I missed an important detail in my report: I ran Tomcat
manually as root using tomcat-start.sh (in a Docker container) rather
than as a systemd service. I don’t have Sid with systemd set up, but
testing on Bookworm with systemd throws a different exception: instead
of a NoClassDefFoundError at HostConfig.java:1243, it already throws an
IOException at HostConfig.java:1232 – it tries to write the
webapps-javaee directory, but only the webapps directory is read/write
enabled in the systemd unit file. After editing the unit file to enable
read/write access for the webapps-javaee directory, the systemd service
also throws the NoClassDefFoundError. Testing on Bookworm by manually
running tomcat-start.sh as root also throws the NoClassDefFoundError.

Regards,
Tamás

Bug#1040226: tomcat10: deployment-time Java EE to Jakarta EE migration fails

[Tamás J . Tóth]

Package: tomcat10
Version: 10.1.10-1
Severity: important
X-Debbugs-Cc: debreport...@jnet.hu

Dear Maintainer,

The deployment-time Java EE to Jakarta EE migration, as documented in
the Tomcat 10 migration guide
, fails
with `NoClassDefFoundError: org/apache/tomcat/jakartaee/Migration`. This
affects only those who use the deployment-time Java EE to Jakarta EE
migration, but makes this migration completely unusable.

Steps to reproduce:

1. Install Tomcat 10.
2. Put a web app in the `appBase` directory (/var/lib/tomcat10/webapps).
   It can be very simple, e.g. a directory (say, test/) containing a
   single index.html.
3. Start Tomcat.
4. Try to open the web app. Assuming you named the directory test/, it
   should be at http://localhost:8080/test/.
5. Verify that it loads.
6. Move the web app to the `legacyAppBase` directory
   (/var/lib/tomcat10/webapps-javaee) and restart Tomcat.
7. Try to open the web app again.

Actual result:

The web app doesn't load. The Tomcat log contains the following:

WARNING [main] org.apache.catalina.startup.HostConfig.migrateLegacyApp 
Migration failure
java.lang.NoClassDefFoundError: org/apache/tomcat/jakartaee/Migration
at 
org.apache.catalina.startup.HostConfig.migrateLegacyApp(HostConfig.java:1243)
at 
org.apache.catalina.startup.HostConfig$MigrateApp.run(HostConfig.java:1996)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at 
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at 
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:123)
at 
org.apache.catalina.startup.HostConfig.migrateLegacyApps(HostConfig.java:1208)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:419)
at 
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1656)
at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309)
at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
at 
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
at 
org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
at 
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:893)
at 
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:846)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1328)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1318)
at 
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at 
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
at 
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:866)
at 
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:241)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:428)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:919)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Catalina.start(Catalina.java:795)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at 
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:347)
at 
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:482)
Caused by: java.lang.ClassNotFoundException: 
org.apache.tomcat.jakartaee.Migration
at 
java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:592)
at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
   

Bug#1036993: /lib/x86_64-linux-gnu/security/pam_sss.so: pam_sss passes KRB5CCNAME with sudo -i (see redhat bug/fix 1324486)

[J. Pfennig]

Package: libpam-sss
Version: 2.8.2-4
Severity: normal
File: /lib/x86_64-linux-gnu/security/pam_sss.so

Dear Maintainer,

   * What led up to the situation?

using kerberos, AD/DC, sssd and its pam module

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

kinit ...   # to get a kerberos ticket
echo $KRB5CCNAME# path to creditial cache

sudo -i user2
echo $KRB5CCNAME# ORIGINAL path to creditial cache

   * What was the outcome of this action?

kinit, klist et al fail, wrong credential cache
echo $KRB5CCNAME# path from original user

   * What outcome did you expect instead?

KRB5CCNAME must not be passed

the case is described better than I can do at:

https://bugzilla.redhat.com/show_bug.cgi?id=1324486

Bug fixed there in 2017. Could Debian fix it too?

Thanks, Jürgen


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

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

Versions of packages libpam-sss:amd64 depends on:
ii  libc6 2.36-9
ii  libgssapi-krb5-2  1.20.1-2
ii  libpam-pwquality  1.4.5-1+b1
ii  libpam-runtime1.5.2-6
ii  libpam0g  1.5.2-6

Versions of packages libpam-sss:amd64 recommends:
ii  sssd  2.8.2-4

libpam-sss:amd64 suggests no packages.

-- no debconf information

Bug#1034494: Acknowledgement (unbound: Unbound fails to create pid file even when pidfile specified in /etc/unbound/unbound.conf or /etc/init.d/unbound)

[J]

Thank you so much. Your help was amazing. Keep up the great work. Can close
this report.

On Tue, 18 Apr 2023 at 13:13, Simon Deziel  wrote:

> You can override ExecStart= by first defining it empty like that:
>
> [Service]
> ExecStart=
> ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS
>
> HTH,
> Simon
>
> On 2023-04-17 23:20, J wrote:
> > Thank you so much, thats exactly what I was missing. I commented out the
> -p
> > in
> > ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS
> > in
> > /usr/lib/systemd/system/unbound.service
> >
> > And now I have a pidfile back that I can use.
> > Unless there is any better way? I tried to override the unbound.service
> but
> > I'm not sure ExecStart= can be overrode.
> >
> > On Sun, 16 Apr 2023 at 18:52, J  wrote:
> >
> >> Hi!
> >> I'm having an issue where unbound is not creating the pid file
> >> I've specified in unbound.conf `pidfile: "/run/unbound.pid"`
> >> I also see that this path is hard coded in `/etc/init.d/unbound` as
> >> `PIDFILE="/run/unbound.pid"`
> >>
> >> The only thing that fixes it is commenting out `.
> /lib/lsb/init-functions`
> >> in  `/etc/init.d/unbound` which is obviously not what I want to do
> >>
> >> On Sun, 16 Apr 2023 at 18:48, Debian Bug Tracking System <
> >> ow...@bugs.debian.org> wrote:
> >>
> >>> Thank you for filing a new Bug report with Debian.
> >>>
> >>> You can follow progress on this Bug here: 1034494:
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034494.
> >>>
> >>> This is an automatically generated reply to let you know your message
> >>> has been received.
> >>>
> >>> Your message is being forwarded to the package maintainers and other
> >>> interested parties for their attention; they will reply in due course.
> >>>
> >>> Your message has been sent to the package maintainer(s):
> >>>   unbound packagers 
> >>>
> >>> If you wish to submit further information on this problem, please
> >>> send it to 1034...@bugs.debian.org.
> >>>
> >>> Please do not send mail to ow...@bugs.debian.org unless you wish
> >>> to report a problem with the Bug-tracking system.
> >>>
> >>> --
> >>> 1034494: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034494
> >>> Debian Bug Tracking System
> >>> Contact ow...@bugs.debian.org with problems
> >>>
> >>
> >
>
>

Bug#1034494: Acknowledgement (unbound: Unbound fails to create pid file even when pidfile specified in /etc/unbound/unbound.conf or /etc/init.d/unbound)

[J]

Thank you so much, thats exactly what I was missing. I commented out the -p
in
ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS
in
/usr/lib/systemd/system/unbound.service

And now I have a pidfile back that I can use.
Unless there is any better way? I tried to override the unbound.service but
I'm not sure ExecStart= can be overrode.

On Sun, 16 Apr 2023 at 18:52, J  wrote:

> Hi!
> I'm having an issue where unbound is not creating the pid file
> I've specified in unbound.conf `pidfile: "/run/unbound.pid"`
> I also see that this path is hard coded in `/etc/init.d/unbound` as
> `PIDFILE="/run/unbound.pid"`
>
> The only thing that fixes it is commenting out `. /lib/lsb/init-functions`
> in  `/etc/init.d/unbound` which is obviously not what I want to do
>
> On Sun, 16 Apr 2023 at 18:48, Debian Bug Tracking System <
> ow...@bugs.debian.org> wrote:
>
>> Thank you for filing a new Bug report with Debian.
>>
>> You can follow progress on this Bug here: 1034494:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034494.
>>
>> This is an automatically generated reply to let you know your message
>> has been received.
>>
>> Your message is being forwarded to the package maintainers and other
>> interested parties for their attention; they will reply in due course.
>>
>> Your message has been sent to the package maintainer(s):
>>  unbound packagers 
>>
>> If you wish to submit further information on this problem, please
>> send it to 1034...@bugs.debian.org.
>>
>> Please do not send mail to ow...@bugs.debian.org unless you wish
>> to report a problem with the Bug-tracking system.
>>
>> --
>> 1034494: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034494
>> Debian Bug Tracking System
>> Contact ow...@bugs.debian.org with problems
>>
>

Bug#1034494: Acknowledgement (unbound: Unbound fails to create pid file even when pidfile specified in /etc/unbound/unbound.conf or /etc/init.d/unbound)

[J]

Hi!
I'm having an issue where unbound is not creating the pid file
I've specified in unbound.conf `pidfile: "/run/unbound.pid"`
I also see that this path is hard coded in `/etc/init.d/unbound` as
`PIDFILE="/run/unbound.pid"`

The only thing that fixes it is commenting out `. /lib/lsb/init-functions`
in  `/etc/init.d/unbound` which is obviously not what I want to do

On Sun, 16 Apr 2023 at 18:48, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

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

Bug#1033716: Info received (Bug#1033716: Acknowledgement (watchdog: Watchdog incorrectly thinks iface eth0 not receiving any data))

[J]

I think the problem is that the '/proc/net/dev' command returns 'unsigned
long long' (see here:
https://github.com/raspberrypi/linux/blame/rpi-6.1.y/net/core/net-procfs.c#L82),
but the watchdog 'iface.c' code uses 'unsigned long', which causes the
'bytes' to always be 4294967295 (0x  or ULONG_MAX). There is no
check that the 'strtoul' operation has been successful.

Recompiling the watchdog using 'unsigned long long' for 'bytes' and
changing 'strtoul' to 'stroull' apparently solved the problem for me after
doing a quick test. See changes below.


I would add the additional checks for "strtoull" to at least add a warning
in the logs if this is happening in the future. Maybe even better it would
be to use 'u64' instead of 'unsigned long long', as that's what is stored
anyway in "struct rtnl_hw_stats64" where "rx_bytes" that we read are
stored. However, they are printed as "%llu" so maybe better to keep as is?

diff --git a/iface.c.orig b/iface.c
index 5db4e55..7b5eba6 100644
--- a/iface.c.orig
+++ b/iface.c
@@ -41,11 +41,11 @@ int check_iface(struct list *dev)

for (; line[i] == ' ' || line[i] == '\t'; i++) ;
if (strncmp(line + i, dev->name, strlen(dev->name))
== 0) {
-   unsigned long bytes = strtoul(line + i +
strlen(dev->name) + 1, NULL, 10);
+   unsigned long long bytes = strtoull(line +
i + strlen(dev->name) + 1, NULL, 10);

/* do verbose logging */
if (verbose && logtick && ticker == 1)
-   log_message(LOG_DEBUG, "device %s
received %lu bytes", dev->name, bytes);
+   log_message(LOG_DEBUG, "device %s
received %llu bytes", dev->name, bytes);

if (dev->parameter.iface.bytes == bytes) {
fclose(file);

diff --git a/extern.h b/extern.h.orig
index 2eccf0b..81bc620 100644
--- a/extern.h
+++ b/extern.h.orig
@@ -30,7 +30,7 @@ struct filemode {
 };

 struct ifmode {
-   unsigned long long bytes;
+   unsigned long bytes;
 };

 struct tempmode {


On Sun, 2 Apr 2023 at 16:18, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

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

Bug#1033717: Acknowledgement (watchdog: After doing certain things, Watchdog thinks "device eth0 did not receive anything since last check")

[J]

Sorry, this is a duplicate of #1033716

On Thu, 30 Mar 2023 at 17:45, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

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

Bug#1033716: Acknowledgement (watchdog: Watchdog incorrectly thinks iface eth0 not receiving any data)

[J]

I have found more information on this. Not sure if it is a problem with the
watchdog package or how the system is configured, but the problem is that
there is an overflow of the "bytes" variable in the "iface.c" source file
for the watchdog.

This is the line that is causing the issues:
unsigned long bytes = strtoul(line + i + strlen(dev->name) + 1, NULL, 10);

Reference:
https://github.com/RPi-Distro/repo/issues/237#issuecomment-1493429567

On Thu, 30 Mar 2023 at 22:46, J  wrote:

> Hello,
> After doing certain activities, in my case, restoring an external SD card
> from a backup using a program, watchdog thinks that
> "device eth0 did not receive anything since last check"
> which triggers a reboot as I've configured in Watchdog.
> However, eth0 is working fine, /proc/net/dev is incrementing, the
> interface is working, I'm serving HTTPS/HTTPS/DNS over this interface, I'm
> SShed in on the interface.
> /dev/proc/net is incrementing, I am cat'ing it and watch it increment AS
> watchdog says its not receiving anything
>
> Relevant links:
> https://github.com/RPi-Distro/repo/issues/237#issuecomment-1490751380
>
> On Thu, Mar 30, 2023, 5:45 p.m. Debian Bug Tracking System <
> ow...@bugs.debian.org> wrote:
>
>> Thank you for filing a new Bug report with Debian.
>>
>> You can follow progress on this Bug here: 1033716:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033716.
>>
>> This is an automatically generated reply to let you know your message
>> has been received.
>>
>> Your message is being forwarded to the package maintainers and other
>> interested parties for their attention; they will reply in due course.
>>
>> As you requested using X-Debbugs-CC, your message was also forwarded to
>>   grandmastertrip...@gmail.com
>> (after having been given a Bug report number, if it did not have one).
>>
>> Your message has been sent to the package maintainer(s):
>>  Michael Meskes 
>>
>> If you wish to submit further information on this problem, please
>> send it to 1033...@bugs.debian.org.
>>
>> Please do not send mail to ow...@bugs.debian.org unless you wish
>> to report a problem with the Bug-tracking system.
>>
>> --
>> 1033716: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033716
>> Debian Bug Tracking System
>> Contact ow...@bugs.debian.org with problems
>>
>

Bug#1033716: Acknowledgement (watchdog: Watchdog incorrectly thinks iface eth0 not receiving any data)

[J]

Hello,
After doing certain activities, in my case, restoring an external SD card
from a backup using a program, watchdog thinks that
"device eth0 did not receive anything since last check"
which triggers a reboot as I've configured in Watchdog.
However, eth0 is working fine, /proc/net/dev is incrementing, the interface
is working, I'm serving HTTPS/HTTPS/DNS over this interface, I'm SShed in
on the interface.
/dev/proc/net is incrementing, I am cat'ing it and watch it increment AS
watchdog says its not receiving anything

Relevant links:
https://github.com/RPi-Distro/repo/issues/237#issuecomment-1490751380

On Thu, Mar 30, 2023, 5:45 p.m. Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

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

Bug#1033575: digikam: bookworm build: No 16-bit color in jpeg2000 and heif, missing gmic-qt

[J. Pfennig]

Package: digikam
Version: 4:7.9.0-1+b2
Severity: important

Dear Maintainer,

Thanks for building digikam for bookworm. As you shurely know this build
is quite important as recent appimage upstream builds crash on bookworm
(I believe that's a know problem).

The latest usable appimage for bookworm was 7.7 (7.8 loads too slow, 7.9
and 7.10 crash).

The 7.7 appimage (and earlier) correctly load jpeg2000 images with more
than 8-bits per color-channel (I use 10-bits for my purposes). 

Anyhow, the 7.9 build for bookworm loads jpeg2000 and heif only with
8-bit per color-channel (implied down-conversion). Tiffs with 16-bit per
channel load correctly (unfortunately only 8/16-bit tiffs work with
kde's libtiff). Needless to say that imagemagick 7.1.0 works fine with
8/10/16-bit tiff/jpeg2000/heif.

Also gmic-qt is missing in the debian build (it works fine if the plugin
is copied from the app-immage). gmic-qt for digikam did never support
16-bit color, but that's an upstream-bug.

Yours
Jürgen

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

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

Versions of packages digikam depends on:
ii  digikam-data  4:7.9.0-1
ii  digikam-private-libs  4:7.9.0-1+b2
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libkf5configcore5 5.103.0-1
ii  libkf5coreaddons5 5.103.0-1
ii  libkf5i18n5   5.103.0-1
ii  libmagick++-6.q16-8   8:6.9.11.60+dfsg-1.6
ii  libqt5core5a  5.15.8+dfsg-3
ii  libqt5gui55.15.8+dfsg-3
ii  libqt5sql55.15.8+dfsg-3
ii  libqt5sql5-mysql  5.15.8+dfsg-3
ii  libqt5sql5-sqlite 5.15.8+dfsg-3
ii  libqt5widgets55.15.8+dfsg-3
ii  libstdc++612.2.0-14
ii  perl  5.36.0-7

Versions of packages digikam recommends:
pn  ffmpegthumbs   
ii  firefox-esr [www-browser]  102.9.0esr-2
ii  konqueror [www-browser]4:22.12.3-1

Versions of packages digikam suggests:
ii  breeze-icon-theme  4:5.103.0-1
pn  digikam-doc
ii  systemsettings 4:5.27.2-1

-- no debconf information

Bug#1033463: linux-image-6.1.0-6-amd64: fails to mount/recognize NTFS partitions

[Vivek K J]

On 25/03/23 21:09, Diederik de Haas wrote:

Control: tag -1 moreinfo

On Saturday, 25 March 2023 15:27:52 CET Vivek K J wrote:

I've been using a automount script (in /etc/fstab) to mount my
windows NTFS partition in Debian Testing. But after updating to
6.1.0-6-amd64 the kernel doesn't boot and stucks at recovery mode. On
commenting the line which I used to automount that drive, I was able to
boot into OS, but it fails to recognize my NTFS partitions.

PS: it's working without any problems in 6.1.0-5-amd64.

Unstable has version 6.1.20-1 aka 6.1.0-7-amd64, can you try whether the
problem is still present in that version?

No.  Unstable version is able to mount that drive without any errors

If it does, then sharing the output when you *manually* mount the drive
successfully on 6.1.0-5-amd64 and when you do the exact same thing on 6.1.0-6-
amd64 with the failure, so it shows some error message(s).


It doesn't even recognizes a NTFS Partition (no output on using sudo 
fdisk -l | grep NTFS

)

--
Regards,

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



OpenPGP_0xA5FF4BB3EA53C5DF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033463: linux-image-6.1.0-6-amd64: fails to mount/recognize NTFS partitions

[Vivek K J]

Package: src:linux
Version: 6.1.15-1
Severity: normal

Dear Maintainer,

I've been using a automount script (in /etc/fstab) to mount my windows 
NTFS partition in Debian
Testing. But after updating to 6.1.0-6-amd64 the kernel doesn't boot 
and stucks at recovery mode.
On commenting the line which I used to automount that drive, I was able 
to boot into OS, but it
fails to recognize my NTFS partitions. 

PS: it's working without any problems in 6.1.0-5-amd64.


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Acer
product_name: Nitro AN515-56
product_version: V1.02
chassis_vendor: Acer
chassis_version: V1.02
bios_vendor: Insyde Corp.
bios_version: V1.02
board_vendor: TGL
board_name: Scala_TLM
board_version: V1.02

** PCI devices:
:00:00.0 Host bridge [0600]: Intel Corporation 11th Gen Core Processor Host 
Bridge/DRAM Registers [8086:9a14] (rev 01)
Subsystem: Acer Incorporated [ALI] 11th Gen Core Processor Host 
Bridge/DRAM Registers [1025:152f]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

:00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake-LP 
GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] TigerLake-LP GT2 [Iris Xe Graphics] 
[1025:152f]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

:00:04.0 Signal processing controller [1180]: Intel Corporation 
TigerLake-LP Dynamic Tuning Processor Participant [8086:9a03] (rev 01)
Subsystem: Acer Incorporated [ALI] TigerLake-LP Dynamic Tuning 
Processor Participant [1025:152f]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device_pci_legacy

:00:06.0 PCI bridge [0604]: Intel Corporation 11th Gen Core Processor PCIe 
Controller [8086:9a09] (rev 01) (prog-if 00 [Normal decode])
Subsystem: Acer Incorporated [ALI] 11th Gen Core Processor PCIe 
Controller [1025:152f]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

:00:07.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP Thunderbolt 4 
PCI Express Root Port #0 [8086:9a23] (rev 01) (prog-if 00 [Normal decode])
Subsystem: Intel Corporation Tiger Lake-LP Thunderbolt 4 PCI Express 
Root Port [8086:7270]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

:00:08.0 System peripheral [0880]: Intel Corporation GNA Scoring 
Accelerator module [8086:9a11] (rev 01)
Subsystem: Acer Incorporated [ALI] GNA Scoring Accelerator module 
[1025:152f]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

:00:0d.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP Thunderbolt 
4 USB Controller [8086:9a13] (rev 01) (prog-if 30 [XHCI])
Subsystem: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller 
[8086:7270]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

:00:0d.2 USB controller [0c03]: Intel Corporation Tiger Lake-LP Thunderbolt 
4 NHI #0 [8086:9a1b] (rev 01) (prog-if 40 [USB4 Host Interface])
Subsystem: Device [:]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: thunderbolt
Kernel modules: thunderbolt

:00:0e.0 RAID bus controller [0104]: Intel Corporation Volume Management 
Device NVMe RAID Controller [8086:9a0b]
Subsystem: Acer Incorporated [ALI] Volume Management Device 

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[Peter J. Holzer]

Package: python3-django-hyperkitty
Followup-For: Bug #1031928
Control: severity -1 normal

next attempt ...

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[Peter J. Holzer]

Package: python3-django-hyperkitty
Version: 1.3.4-4
Severity: normal

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[Peter J. Holzer]

On 2023-03-02 20:30:04 +0100, Peter J. Holzer wrote:
> On 2023-03-02 19:53:12 +0100, Peter J. Holzer wrote:
> > So it seems that my suspicion that {% compress js %}...{% endcompress %}
> > wasn't working properly was correct. But of course that raises the
> > question why that would fail on one system and work on another. I'll
> > investigate that and then get back to you.
> 
> Found it (RTFM helps). I had set DEBUG = True in
> /etc/mailman3/mailman-web.py. This implicitly sets COMPRESS_ENABLED =
> False, so it was just passing the wrong HTML from the template through
> to the browser.

Can I change the severity of the bug?

Since it only happens if the admin sets DEBUG = True, it won't affect
most users. So normal or even minor seems to be more appropriate than
grave.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[Peter J. Holzer]

On 2023-03-03 11:57:14 +, James Addison wrote:
> Package: python3-django-hyperkitty
> Followup-For: Bug #1031928
> X-Debbugs-Cc: h...@hjp.at
> 
> Hi Peter - one more thought from me:
> 
> Would you be willing to send your patch to the upstream hyperkitty project[1]
> as well?  (likely as a merge request on their GitLab instance)

Sure, but it seems to be fixed in upstream already, presumably because
they use a significantly newer version of django-compressor (4.3.1
instead of 2.4). The newer version of django-compressor reformats
 to  even if COMPRESS_ENABLED = False.

    hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[Peter J. Holzer]

On 2023-03-02 19:53:12 +0100, Peter J. Holzer wrote:
> So it seems that my suspicion that {% compress js %}...{% endcompress %}
> wasn't working properly was correct. But of course that raises the
> question why that would fail on one system and work on another. I'll
> investigate that and then get back to you.

Found it (RTFM helps). I had set DEBUG = True in
/etc/mailman3/mailman-web.py. This implicitly sets COMPRESS_ENABLED =
False, so it was just passing the wrong HTML from the template through
to the browser.

hp


-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[Peter J. Holzer]

On 2023-03-02 01:32:55 +, James Addison wrote:
> Package: python3-django-hyperkitty
> Followup-For: Bug #1031928
> X-Debbugs-Cc: h...@hjp.at
> Control: tags -1 moreinfo
> 
> Hi Peter,
> 
> I'd like to gain some experience with configuring email infrastructure, and
> this bug seems like a good opportunity to learn.
> 
> I haven't yet been able to reproduce the self-closing HTML script tags; here's
> roughly the series of install steps I used (I may have omitted one or two
> details) to get the interface up-and-running:
> 
>   # apt install mailman3-full
>   # vim /etc/mailman3/mailman-web.py  # configure REST API creds
>   # ln -s /etc/mailman3/apache.conf /etc/apache2/conf-available/mailman3.conf
>   # a2enconf mailman3
>   # a2enmod proxy_uwsgi
>   # systemctl restart mailman3-web
>   # systemctl restart apache2

I just did that on a fresh VM to to have a pristine state again.


> (note that I also had postfix utilities installed on the system)
> 
> That seemed to work: I was able to browse the postorius web interface and see
> that I had no mailing lists configured.

The problem is only on the "Archives" page (/mailman3/hyperkitty), and
it's not immediately noticable without any archived mailinglists,
however ...


> Checking the HTML source of the page, I did see some  tags -- 
> including
> for 'popper.js' -- each of them had a closing  tag, as expected.

At the bottom of the hyperkitty page I see now:





This is ok, but it's not what I saw on the other system. Instead of the
last line with the cached compressed javascript I got the 12 individual
script entries from the template.

So it seems that my suspicion that {% compress js %}...{% endcompress %}
wasn't working properly was correct. But of course that raises the
question why that would fail on one system and work on another. I'll
investigate that and then get back to you.


> Could you provide any more information on configuration steps / settings that
> may be required to reproduce the problem?

My process wasn't as straightforward as yours, there was quite a bit of
trial and error involved (for example, I installed postgresql after
mailman3 and then did a dpkg-reconfigure to get mailman3 to use
posgresql instead of sqlite; and I also needed a few attempts to get the
apache config right), however, browsing through the shell history I see
no differences which look relevant.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[Peter J. Holzer]

Package: python3-django-hyperkitty
Version: 1.3.4-4
Severity: grave
Tags: patch
Justification: renders package unusable

Dear Maintainer,

I set up mailman3 including the web interface and the hyperkitty
archiver with Apache2 and a test mailing list.

Upon accessing the archive at
https:///mailman3/hyperkitty/list/test@/
I immediately noticed that the page was incomplete, showing only
rotating spinners where some of the context should be.

Further investigation showed that the HTML is wrong:



...

In normal HTML (not XHTML) a  element needs to be closed with a
 tag, the XML-style /> ending is not recognized. The result is
that browsers (at least Firefox and Chromium) ignore all scripts except
the first.

replacing "/>" with ">" on the offending lines fixes the
problem

PS: I do notice that those lines are enclosed in
{% compress js %}...{% endcompress %} so it could also be that that
doesn't work properly

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/2 CPU threads)
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 python3-django-hyperkitty depends on:
ii  fonts-glyphicons-halflings   1.009~3.4.1+dfsg-2
ii  libjs-bootstrap4 4.5.2+dfsg1-8~deb11u1
ii  libjs-sphinxdoc  3.4.3-2
ii  python3  3.9.2-3
ii  python3-dateutil 2.8.1-6
ii  python3-django   2:2.2.28-1~deb11u1
ii  python3-django-compressor2.4-2
ii  python3-django-extensions3.0.3-3
ii  python3-django-gravatar2 1.4.4-2
ii  python3-django-haystack  3.0-1
ii  python3-django-mailman3  1.3.5-2
ii  python3-django-q 1.2.1-1
ii  python3-djangorestframework  3.12.1-1
ii  python3-elasticsearch7.1.0-3
ii  python3-flufl.lock   5.0.1-1
ii  python3-mailmanclient3.3.2-1
ii  python3-networkx 2.5+ds-2
ii  python3-robot-detection  0.4.0-2
ii  python3-tz   2021.1-1

Versions of packages python3-django-hyperkitty recommends:
ii  mailman3-web  0+20200530-2

python3-django-hyperkitty suggests no packages.

-- no debconf information
--- orig/base.html  2023-02-25 14:55:29.682952431 +0100
+++ fixed/base.html 2023-02-25 14:55:42.702972701 +0100
@@ -218,18 +218,18 @@
 
 
 {% compress js %}
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
 {% endcompress %}
 {% block additionaljs %} {% endblock %}
 

Bug#1030134: ITP: ruby-google-apis-discovery-v1 -- Simple REST client for Google API Discovery Service V1

[Vivek K J]

Package: wnpp
Severity: wishlist
Owner: Vivek K J 
X-Debbugs-Cc: debian-de...@lists.debian.org, vive...@disroot.org

* Package name: ruby-google-apis-discovery-v1
  Version : 0.13.0
  Upstream Contact: Google LLC 
* URL : https://github.com/google/google-api-ruby-client
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Simple REST client for Google API Discovery Service V1

 This is the simple REST client for API Discovery Service V1. Simple REST
 clients are Ruby client libraries that provide access to Google services via
 their HTTP REST API endpoints. These libraries are generated and updated
 automatically based on the discovery documents published by the service, and
 they handle most concerns such as authentication, pagination, retry, timeouts,
 and logging. You can use this client to access the API Discovery Service, but
 note that some services may provide a separate modern client that is easier to
 use.

 This package will be maintained by Ruby Team.

Bug#1028396: bullseye-pu: package ruby-aws-sdk-core/3.104.3

[Vivek K J]

On 27/01/23 15:23, Adam D. Barratt wrote:

On Fri, 2023-01-27 at 14:55 +0530, Vivek K J wrote:

  It is not an expected change. The change came because, I built the
current stable version (i.e. 3.104.3-3) using an unstable chroot
(Mistakenly). On taking debdiff between this version and the current
stable version (which is built using a bullseye chroot), this diff
won't be there.  (Attaching base binary package built using bullseye
chroot )

OK, I see.

I've flagged the current upload for rejection. Once you get
confirmation of that rejection, please perform a new - source-only -
upload, so we can build the binary package on the buildds.

Uploaded. Thanks,

Regards,

Adam


--
Regards,

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



OpenPGP_0xA5FF4BB3EA53C5DF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028537: ITP: ruby-google-apis-core -- Common utility and base classes for legacy Google REST clients

[Vivek K J]

Package: wnpp
Severity: wishlist
Owner: Vivek K J 
X-Debbugs-Cc: debian-de...@lists.debian.org, vive...@disroot.org

* Package name: ruby-google-apis-core
  Version : 0.9.4
  Upstream Contact: Google LLC 
* URL : https://github.com/google/google-api-ruby-client
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Common utility and base classes for legacy Google REST 
clients
  
 This library includes common base classes and dependencies used by legacy REST
 clients for Google APIs. It is used by client libraries, but you should not
 need to install it by itself.

 This package is a dependency for gitlab and this package will be maintained
 by debian-ruby team

Bug#1028396: bullseye-pu: package ruby-aws-sdk-core/3.104.3

[Vivek K J]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ruby-aws-sdk-c...@packages.debian.org, vive...@disroot.org
Control: affects -1 + src:ruby-aws-sdk-core


[ Reason ]

Stable version of ruby-aws-sdk-core doesn't have version file. (See #1028285)
The solution was to drop fix-versions.patch which is not necessary with 
gem-install
layout.

[ Impact ]

This means that any integration trying to check the version of the core gem 
using a 
debian installation cannot actually determine the version, or worse, will get 
whatever
version is in the ENV['VERSION'] which is likely completely unrelated to AWS.

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

[ Changes ]

--- ruby-aws-sdk-core-3.104.3/debian/changelog  2023-01-09 19:47:37.0 
+0530
+++ ruby-aws-sdk-core-3.104.3/debian/changelog  2020-08-20 17:53:33.0 
+0530
@@ -1,10 +1,3 @@
-ruby-aws-sdk-core (3.104.3-4) bullseye; urgency=medium
-
-  * Team upload.
-  * drop fix-version.patch (Closes: #1028285)
-
- -- Vivek K J   Mon, 09 Jan 2023 19:47:37 +0530
-
 ruby-aws-sdk-core (3.104.3-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru ruby-aws-sdk-core-3.104.3/debian/patches/fix-version.patch 
ruby-aws-sdk-core-3.104.3/debian/patches/fix-version.patch
--- ruby-aws-sdk-core-3.104.3/debian/patches/fix-version.patch  1970-01-01 
05:30:00.0 +0530
+++ ruby-aws-sdk-core-3.104.3/debian/patches/fix-version.patch  2020-08-20 
17:53:33.0 +0530
@@ -0,0 +1,15 @@
+Description: This patch fixes the VERSION for ruby-paperclip.
+Author: Utkarsh Gupta 
+Last-Update: 2019-09-10
+
+--- a/lib/aws-sdk-core.rb
 b/lib/aws-sdk-core.rb
+@@ -85,7 +85,7 @@
+ 
+ module Aws
+ 
+-  CORE_GEM_VERSION = File.read(File.expand_path('../../VERSION', 
__FILE__)).strip
++  CORE_GEM_VERSION = ENV['VERSION']
+ 
+   @config = {}
+ 
diff -Nru ruby-aws-sdk-core-3.104.3/debian/patches/series 
ruby-aws-sdk-core-3.104.3/debian/patches/series
--- ruby-aws-sdk-core-3.104.3/debian/patches/series 2023-01-09 
19:47:26.0 +0530
+++ ruby-aws-sdk-core-3.104.3/debian/patches/series 2020-08-20 
17:53:33.0 +0530
@@ -0,0 +1 @@
+fix-version.patch

Bug#778792: ucspi-tcp-ipv6: tcprules doesn't support ipv6 addresses in rules file

[Michal J.]

Hi Peter,

> > I have found a problem with ucspi-tcp-ipv6 package; namely that
> > tcprules dies when it encounters ipv6 address in rules file.
> > E.g. adding ipv6 address to /etc/tcp.smtp fails:
> 
> Can you still reproduce this bug with a recent version of
> the ucspi-tcp-ipv6 package?

Yeah, `ucspi-tcp-ipv6` on a recent debian works as it should.

(I have since moved on to a different solution, but at least wanted to
confirm)

Cheers,

M.
-- 
Michal J. 
"Truth is the daughter of time, not of authority." -- Francis Bacon

Bug#1027332: ITP: ruby-google-cloud-errors -- Error classes for google-cloud-ruby

[Vivek K J]

Package: wnpp
Severity: wishlist
Owner: Vivek K J 
X-Debbugs-Cc: debian-de...@lists.debian.org, vive...@disroot.org

* Package name: ruby-google-cloud-errors
  Version : 1.3.0
  Upstream Contact: ["m...@blowmage.com", "quart...@gmail.com"]
* URL : 
https://github.com/googleapis/google-cloud-ruby/tree/master/google-cloud-errors
* License : Apache-2.0
  Programming Lang: ruby
  Description : Error classes for google-cloud-ruby
  
 This Ruby library contains error classes raised by Google Cloud API clients.
 google-cloud-errors defines error classes for google-cloud-ruby.


 This package is a dependency for updating ruby-google-cloud-core to latest
 version. This package will be maintained by Debian Ruby Team.

Bug#1027047: ruby-google-api-client: FTBFS with ruby-googleauth 1.3.0

[Vivek K J]

Package: ruby-google-api-client
Version: 0.50.0-2
Severity: important
Tags: ftbfs
X-Debbugs-Cc: vive...@disroot.org

Hi,
On building this package against latest version of ruby-googleauth
(1.3.0) in experimental, your package failed to build

(Relevant log, hopefully)

┌──┐
│ Checking Rubygems dependency resolution on ruby3.1   │
└──┘

GEM_PATH=/<>/debian/ruby-google-api-client/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
 ruby3.1 -e gem\ \"google-api-client\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in block in 
activate_dependencies': Could not find 'googleauth' (~> 0.9) among 114 total 
gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/<>/debian/ruby-google-api-client/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0'
 at: 
/<>/debian/ruby-google-api-client/usr/share/rubygems-integration/all/specifications/google-api-client-0.50.0.gemspec,
 execute `gem env` for more information
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in `block 
in activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`block in gem'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
find 'googleauth' (~> 0.9) - did find: [googleauth-1.3.0] 
(Gem::MissingSpecVersionError)
Checked in 
'GEM_PATH=/<>/debian/ruby-google-api-client/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0'
 , execute `gem env` for more information
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in `block 
in activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`block in gem'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
from -e:1:in `'

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 ruby-google-api-client depends on:
ii  libruby3.0 [ruby-rexml]  3.0.4-8
ii  libruby3.1 [ruby-rexml]  3.1.2-3
ii  ruby 1:3.1
ii  ruby-addressable 2.8.0-3
ii  ruby-googleauth  1.3.0-1
ii  ruby-httpclient  2.8.3+git20211122.4658227-1
ii  ruby-mini-mime   1.1.1-2
ii  ruby-representable   3.0.4-1.1
ii  ruby-retriable   3.1.2-1
ii  ruby-signet  0.17.0-1

ruby-google-api-client recommends no packages.

ruby-google-api-client suggests no packages.

-- no debconf information

Bug#1024427: reproducible segfault in bullseye mutt

[Kevin J. McCarthy]

Note this was fixed in Mutt 2.2.8.  See 
https://gitlab.com/muttmua/mutt/-/issues/428 for the Mutt bug report.


This important fix is at: 
https://gitlab.com/muttmua/mutt/-/commit/48b6ea32e21db8b580cd3ca8c346c3e2c22756f6.patch


There are two related commits, that may be of interest in backporting 
too, but aren't the cause of this segfault:

https://gitlab.com/muttmua/mutt/-/commit/f0eb3586480c301b66657c7326b6546ef086c7f4.patch
https://gitlab.com/muttmua/mutt/-/commit/b254f2fb44f994c48e2491adaf03d97d3c628283.patch

-Kevin


signature.asc
Description: PGP signature

Bug#990828: mutt can not delete mails due to access rights

[Kevin J. McCarthy]

On Mon, Nov 21, 2022 at 02:53:14PM +0100, Juan Pedro Vallejo wrote:

Yes, you were right.

Architecture: i386 (i686)


Thank you Juan.  So you are running the i386 mutt package on an i386 
architecture.  I believe this means something is wrong the package 
building environment.


I've just looked again at the Mutt configure/makefile related to 
mutt_dotlock, and it turns out Mutt always installs as group 'mail' when 
setting sgid:


configure.ac:
=
if test x$mutt_cv_setgid = xyes; then
DOTLOCK_GROUP='mail'
DOTLOCK_PERMISSION=2755
else
DOTLOCK_GROUP=''
DOTLOCK_PERMISSION=755
fi
AC_SUBST(DOTLOCK_GROUP)
AC_SUBST(DOTLOCK_PERMISSION)

Makefile.am:

if test -f $(DESTDIR)$(bindir)/mutt_dotlock && test x$(DOTLOCK_GROUP) 
!= x ; then \
chgrp $(DOTLOCK_GROUP) $(DESTDIR)$(bindir)/mutt_dotlock && \
chmod $(DOTLOCK_PERMISSION) $(DESTDIR)$(bindir)/mutt_dotlock || 
\
{ echo "Can't fix mutt_dotlock's permissions!  This is required to lock 
mailboxes in the mail spool directory." >&2 ; exit 1 ; } \
fi


The content of the various mutt deb files:
==
% for deb in *; do echo $deb; dpkg -c $deb | grep bin/mutt_dotlock; echo; done
mutt_2.2.9-1_amd64.deb
-rwxr-sr-x root/mail 14584 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_arm64.deb
-rwxr-sr-x root/mail 67680 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_armel.deb
-rwxr-sr-x root/root 67108 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_armhf.deb
-rwxr-sr-x root/root 67120 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_i386.deb
-rwxr-sr-x root/root 13804 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_mips64el.deb
-rwxr-sr-x root/mail 68648 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_mipsel.deb
-rwxr-sr-x root/root 67732 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_ppc64el.deb
-rwxr-sr-x root/mail 67760 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_s390x.deb
-rwxr-sr-x root/mail 14432 2022-11-13 09:01 ./usr/bin/mutt_dotlock


I'm not sure what is going wrong, but armel, armhf, i386, and mipsel are 
failing to chgrp to mail during the package building.


Antonio I'll need your help to figure out what is going on in this case. 
Since this renders the program unusable for working with spoolfile mail, 
I think this ought to be bumped to 'serious'.


-Kevin



signature.asc
Description: PGP signature

Bug#990828: mutt can not delete mails due to access rights

[Kevin J. McCarthy]

On Sun, Nov 20, 2022 at 01:50:41PM +0100, Juan Pedro Vallejo wrote:

"mutt_dotlock" is the one to blame:

# ls -l /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root root 13804 Nov 13 18:01 /usr/bin/mutt_dotlock

This works for me:

# chown root:mail /usr/bin/mutt_dotlock
# chmod 2755 /usr/bin/mutt_dotlock

Now:

# ls -l /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root mail 13804 Nov 13 18:01 /usr/bin/mutt_dotlock


Thanks for the information.  What architecture are you running on?  The 
amd64 package installs properly with sgid mail.


However, I did check the various packages for 2.2.9, and it looks like 
the i386 package does not.  Are you running i386 architecture, or did 
you install the i386 package on an amd64 architecture?


I don't know if this is a bug in the i386 packaging environment, or if 
the mail directories on i386 are different.  I'm Cc'ing Antonio to see 
if he has any input.


-Kevin


signature.asc
Description: PGP signature

Bug#1023599: mutt: FTBFS due to lack of gpgme-config since gpgme1.0 1.18.0-2

[Kevin J. McCarthy]

I've just released mutt 2.2.9, which I believe should fix this problem.

-Kevin


signature.asc
Description: PGP signature

Bug#1023599: mutt: FTBFS due to lack of gpgme-config since gpgme1.0 1.18.0-2

[Kevin J. McCarthy]

On Mon, 7 Nov 2022 13:04:04 +0100 Vincent Lefevre  wrote:

The gpgme-config utility was removed in gpgme1.0 1.18.0-2
(because it needs gpg-error-config, which has been removed).

As a consequence the use of --enable-gpgme to build Mutt yields
an error:


Just as a note, with Vincent's help, I've commited two patches to the 
stable branch, updating to the most recent GPGME autoconf files and 
adjusting AM_PATH_GPG_ERROR before AM_PATH_GPGME:


https://gitlab.com/muttmua/mutt/-/commit/012981e8434903e8b5ae5f099b026b9a64426129.patch
https://gitlab.com/muttmua/mutt/-/commit/527537027b0c9134192663c9d3ec01d6cea6c5c2.patch

I will try to get a Mutt release out later this week with these two 
commits, but if you need the fix sooner, please grab the above patches.


-Kevin


signature.asc
Description: PGP signature

Bug#1022164: ruby-build fails to build 2.7.6 ruby version due to Sid libssl version

[J AG]

Package: ruby-build
Version: 20220426-1
Severity: normal

Dear Maintainer,

I need to use a legacy version of ruby (2.7.x).

As an normal user, I did: "rbenv install 2.7.6" (2.7.6 is the last
version for 2.7 branch)

Outcome:
 > BUILD FAILED (Debian n/a using ruby-build 20220426)
 >
 > Inspect or clean up the working tree at
/tmp/ruby-build.20221020173215.18895.FSRk3g
 > Results logged to /tmp/ruby-build.20221020173215.18895.log

For this branch of ruby version, ruby-build expects libssl > 1.1.1 and
< 3.0.0 and the current Sid libssl-dev version is 3.0.5-4

This issue has been handled upstream
(https://github.com/rbenv/ruby-build/releases/tag/v20220710) by
downloading the expected libssl version when needed.

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

Kernel: Linux 6.0.0-1-amd64 (SMP w/4 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 ruby-build depends on:
ii  build-essential 12.9
ii  curl7.85.0-1
ii  libreadline-dev [libreadline6-dev]  8.2-1
ii  zlib1g-dev  1:1.2.11.dfsg-4.1

Versions of packages ruby-build recommends:
ii  libsqlite3-dev  3.39.4-1
ii  libssl-dev  3.0.5-4
ii  libxml2-dev 2.9.14+dfsg-1+b1
ii  libxslt1-dev [libxslt-dev]  1.1.35-1
ii  rbenv   1.1.2-1

Versions of packages ruby-build suggests:
ii  autoconf2.71-2
ii  automake1:1.16.5-1.3
pn  bison   
ii  default-jre 2:1.11-72
ii  git [git-core]  1:2.37.2-1
ii  libtool 2.4.7-4
ii  rake13.0.6-3
pn  ruby-dev

-- no debconf information

Bug#1021581: linux-image-amd64: 5.18 regression: hibernate works but does not power off computer

[Patrick J.]

Thanks for the info.

I also tested with 6.0~rc7 from experimental but the problem persists.

Am 11.10.22 um 17:26 schrieb Diederik de Haas:

On dinsdag 11 oktober 2022 11:41:58 CEST Patrick Jaap wrote:

An internet research found this similar regression
https://lore.kernel.org/lkml/YqE22nS9k2+AldI6@llamedos.localdomain/
but the fix does not apply to my machine.

FTR: that patch is included upstream in 5.19+, but 5.18 does not have it.

Bug#1021557: jellyfish: Performance regression in 2.3.0 (orders of magnitude for some inputs)

[J Nisbet]

Package: jellyfish
Version: 2.3.0-10
Severity: normal
Tags: upstream
X-Debbugs-Cc: ksnp-...@kissake.net

Dear Maintainer,

   * What led up to the situation?

I observed this issue through normal use of jellyfish.  For some values of -m
and -t, and for a variety of input genomes, performance of 2.3.0 is
significantly (orders of magnitude) worse than other available revisions.
Specifically, jellyfish versions 2.2.10 and 1.1.2 were tested for comparison.

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

For -m values of 13 and 15, -t should be set to 1 for best performance.  This
performance is still noticeably worse than performance at the same settings for
previous versions, but not by an order of magnitude.

This issue has also been reported at the upstream GitHub page here:
https://github.com/gmarcais/Jellyfish/issues/192

You can probably find more details in that report.


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

Kernel: Linux 5.10.0-18-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages jellyfish depends on:
ii  libc6   2.31-13+deb11u4
ii  libgcc-s1   10.2.1-6
ii  libhts3 1.11-4
ii  libjellyfish-2.0-2  2.3.0-10
ii  libstdc++6  10.2.1-6

jellyfish recommends no packages.

jellyfish suggests no packages.


jellyfish_performance_regression.pdf
Description: Adobe PDF document

Bug#985257: backintime-qt: no user callback example installed

[J. A.]

THX for this thoughtful feature request!

I have added it to the developer's issue tracker:

https://github.com/bit-team/backintime/issues/1331

Bug#963849: backintime-qt: GUI fails to launch -> see master issue

[J. A.]

There is HIGH master issue for this in the bug tracker of Back in Time,
please track the status there.

https://github.com/bit-team/backintime/issues/921

We (a new team taking over the responsibilities to develop and maintain Back in 
Time)
are working on this issue and other issues to stabilize (fix bugs, don't add 
new features)
the next release that hopefully is ready before the next Debian freeze window.

As a first indicative diagnosis of this issue:

The CLI "backintime" from "backintime/common" does require a D-Bus service end 
point that is only contained
in the "backintime/qt" source folder (file serviceHelper.py which manages Udev 
rules for Back In Time)
so if the CLI and GUI part are packaged into two different packages the CLI 
does still not work without the installed GUI package.

This is a "lack of enough documentation" issue on our side I think but also a 
bug in Back in Time CLI
that should be more fault-tolerant to ignore a missing serviceHelper.

As a first work-around: If you build from source (and all depdendencies are 
installed!)
you always have to "make install " twice

cd common
./configure
make
# "make test" is not yet reliable here due to the missing serviceHelper 
installed later
make install
cd ../qt
./configure
make
make install   # this actually installs the missing serviceHelper.py 
running as root on the system D-Bus
cd ../common
make test  # no the tests should be green

Bug#1021382: lxqt: Always wants root password for SMART Control

[Hans-J. Ullrich]

Package: lxqt
Version: 30
Severity: normal

Dear Maintainer,

I am running LXQT on an EEEPC with debian/stable. There is an issue, I cannot 
exactly specify, which part is responsible, so let me just describe it.

When started LXQT the first time, a window pops up and wants to enter the root 
password, so that it can actualize the smart-data for the harddrive. When done 
so, the window disappears.

However, when I leave LXQT and change to a console by using "CTL + ALT + 2", 
and revert back to X with "CTL + 7" (terminal 7 is where the window manager is 
running), this behaviour appears again and I have to enter the root password 
again.

This happens every time ands can be reliable repeated.

As this might also be a security issue (can be misused by shoulder surfing or 
somehow else, it is a little bit annoying, too).

It would be nice, if you could fix this.

I tested this with other window managers, too, like LXDE, KDE and XFCE, there 
this behaviour did not appear.

Thank you very much for any help!

Best regards

Hans


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

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

Versions of packages lxqt depends on:
ii  ark   4:20.12.2-1
ii  clipit1.4.4+git20190202-2
ii  featherpad0.17.1-1
ii  kwin-x11 [x-window-manager]   4:5.20.5-1
ii  lightdm [x-display-manager]   1.26.0-7
ii  lximage-qt0.16.0-1
ii  lxqt-about0.16.0-1
ii  lxqt-admin0.16.0-1
ii  lxqt-branding-debian [lxqt-branding]  0.14.0.3
ii  lxqt-core 30
ii  lxqt-openssh-askpass  0.16.0-1
ii  lxqt-powermanagement  0.16.0-1
ii  lxqt-sudo 0.16.0-1
ii  openbox [x-window-manager]3.6.1-9+deb11u1
ii  pavucontrol   4.0-2
ii  qlipper   1:5.1.2-1+b1
ii  qps   2.2.0-1
ii  qterminal 0.16.1-1
ii  qttranslations5-l10n  5.15.2-2
ii  sddm [x-display-manager]  0.19.0-3
ii  sddm-theme-elarun [sddm-theme]0.19.0-3
ii  sddm-theme-maldives [sddm-theme]  0.19.0-3
ii  sddm-theme-maui [sddm-theme]  0.19.0-3
ii  xarchiver 1:0.5.4.17-2

Versions of packages lxqt recommends:
ii  audacious4.0.5-1
ii  bsd-mailx [mail-reader]  8.1.2-0.20180807cvs-2
ii  chromium [www-browser]   106.0.5249.91-1~deb11u1
ii  claws-mail [mail-reader] 3.17.8-1+b1
ii  dillo [www-browser]  3.0.5-7
ii  emacs-nox [mail-reader]  1:27.1+1-3.1
ii  evolution [mail-reader]  3.38.3-1
ii  feathernotes 0.8.0-1
ii  firefox-esr [www-browser]102.3.0esr-1~deb11u1
ii  gucharmap1:13.0.5-1
ii  hexchat  2.14.3-6+deb11u1
ii  im [mail-reader] 1:153-4
ii  irssi1.2.3-1
ii  kmail [mail-reader]  4:20.08.3-1
ii  konqueror [www-browser]  4:20.12.0-4
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1
ii  mailutils [mail-reader]  1:3.10-3+b1
ii  meteo-qt 2.1-1
ii  mutt [mail-reader]   2.0.5-4.1+deb11u1
ii  network-manager-gnome1.20.0-3
ii  plasma-nm4:5.20.5-3
ii  preload  0.6.4-5
ii  qpdfview 0.4.18-5
ii  s-nail [mail-reader] 14.9.22-1
ii  screengrab   2.1.0-1
ii  smplayer 20.6.0~ds0-1
ii  smtube   18.3.0-1+b1
ii  thunderbird [mail-reader]1:102.3.0-1~deb11u1
ii  vm [mail-reader] 8.2.0b-7
ii  w3m [www-browser]0.5.3+git20210102-6
ii  weechat  3.0-1+deb11u1
ii  xemacs21-mule [www-browser]  21.4.24-9

Versions of packages lxqt suggests:
ii  calibre 5.12.0+dfsg-1+deb11u1
ii  compton-conf0.16.0-1
pn  juffed  
pn  nomacs  
ii  obconf-qt   0.16.0-1
ii  qt5-style-kvantum   0.18.0+repack-1
ii  qtpass  1.3.2-3
pn  shutter 
ii  vokoscreen-ng [vokoscreen]  3.0.7-1

-- no debconf information

Bug#1020765: Does Debian 11.x 32 bit support NVDIMM?

[Williams, Dan J]

Comments inline below

On Mon, 26 Sep 2022 08:26:56 + Winnie Yue  wrote:
> Package: ndctl
> Version: 71.1-1
> Severity: serious
>
> For Debian 11.5 32 bit, I got below info:
>
> apt-cache search ndctl
>
> libndctl-dev - Development files for libndctl
>
> libndctl6 - Utility library for managing the libnvdimm subsystem
>
> ndctl - Utility for managing the nvdimm subsystem
>
> It is same to what I got from Debian 11.5 64 bit:
>
> apt-cache search ndctl
>
> libndctl-dev - Development files for libndctl
>
> libndctl6 - Utility library for managing the libnvdimm subsystem
>
> ndctl - Utility for managing the nvdimm subsystem
>
>
> From https://lists.debian.org/debian-devel/2016/12/msg00330.html, 
> https://lists.debian.org/debian-devel/2016/12/msg00343.html, NVDIMM will be 
> fully supported once OS has the package ndctl.
>
> But I found that Debian 11.5 32 bit vm couldn’t recognize the NVDIMM device:
>
>
> #cat /etc/debian_version
>
> 11.5
>
>
>
> #uname -m
>
> i686
>
>
>
> # dmesg | grep -i bios-e820 | grep persistent
>
> [ 0.00] BIOS-e820: [mem 0x00024000-0x00043fff] persistent 
> (type 7)

Note that this is not sufficient for advertising NVDIMM resources. A Type-7 
memory range still requires an ACPI NFIT to advertise the memory range.

That said, why are you trying to run a 32-bit environment. If you need a 32-bit 
userspace you can still use a 64-bit kernel. 32-bit x86 is not well looked 
after by the kernel community in general these days.

Bug#1020786: kmail - option "delete double mails" in folder options not working

[Hans-J. Ullrich]

Package: kmail
Version: 4:20.08.3-1
Severity: normal

Dear Maintainer,

there is an issue in kmail, which is present already since several years. 
I discovered, that the folder option "delete double mails" which is called by 
"CTL + *" is not working.

During the last years, in my folders are many mails double, triple or even 
multi,caused by akonadi crashes,
 and I would like, to geht rid of it.

So it would be nice, if you could take a look at this very usefull feature.

Thank you very much for your help. 

Best regards

Hans
  

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

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

Versions of packages kmail depends on:
ii  akonadi-server4:20.08.3-3
ii  kdepim-runtime4:20.08.3-1
ii  kio   5.78.0-5
ii  libc6 2.32-4
ii  libgcc-s1 10.2.1-6
ii  libgpgmepp6   1.16.0-1.1
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-20.08]   4:20.08.3-3
ii  libkf5akonadicontact5 [libkf5akonadicontact5-20.08]   4:20.08.3-1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-20.08] 4:20.08.3-3
ii  libkf5akonadimime5 [libkf5akonadimime5-20.08] 4:20.08.3-1
ii  libkf5akonadisearch-bin   4:20.08.3-1
ii  libkf5akonadisearch-plugins   4:20.08.3-1
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-20.08]   4:20.08.3-1
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-20.08]   4:20.08.3-1
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-20.08]   4:20.08.3-3
ii  libkf5bookmarks5  5.86.0-1
ii  libkf5calendarcore5abi2   5:5.86.0-1
ii  libkf5calendarutils5 [libkf5calendarutils5-20.08] 4:20.08.3-1
ii  libkf5codecs5 5.86.0-1
ii  libkf5completion5 5.86.0-1
ii  libkf5configcore5 5.86.0-1
ii  libkf5configgui5  5.86.0-1
ii  libkf5configwidgets5  5.86.0-1
ii  libkf5contacts5   5:5.86.0-1
ii  libkf5coreaddons5 5.86.0-1
ii  libkf5crash5  5.86.0-1
ii  libkf5dbusaddons5 5.86.0-1
ii  libkf5grantleetheme-plugins   20.08.3-1
ii  libkf5gravatar5abi2 [libkf5gravatar5-20.08]   4:20.08.3-1
ii  libkf5guiaddons5  5.86.0-1
ii  libkf5i18n5   5.86.0-1
ii  libkf5iconthemes5 5.86.0-1
ii  libkf5identitymanagement5 [libkf5identitymanagement5-20.08]   20.08.3-1
ii  libkf5itemmodels5 5.86.0-1
ii  libkf5itemviews5  5.86.0-1
ii  libkf5jobwidgets5 5.86.0-1
ii  libkf5kcmutils5   5.86.0-1
ii  libkf5kiocore55.86.0-1
ii  libkf5kiofilewidgets5 5.86.0-1
ii  libkf5kiogui5 5.86.0-1
ii  libkf5kiowidgets5 5.86.0-1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-20.08]   20.08.3-1
ii  libkf5ksieveui5 [libkf5ksieveui5-20.08]   4:20.08.3-1
ii  libkf5ldap5abi1 [libkf5ldap5-20.08]   20.08.3-1
ii  libkf5libkdepim5 [libkf5libkdepim5-20.08] 4:20.08.3-1
ii  libkf5libkleo5 [libkf5libkleo5-20.08] 4:20.08.3-1
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-20.08]   4:20.08.3-1
ii  libkf5mailtransport5 [libkf5mailtransport5-20.08] 20.08.3-1
ii  libkf5mailtransportakonadi5 [libkf5mailtransportakonadi5-20.  20.08.3-1
ii  libkf5messagecomposer5abi1 [libkf5messagecomposer5-20.08] 4:20.08.3-5
ii  libkf5messagecore5abi1 [libkf5messagecore5-20.08] 4:20.08.3-5
ii  libkf5messagelist5abi1 

Bug#985631:

[J. A.]

As c.buhtz wrote the bug has already been reported to the backintime team and a 
fix is work in progress
via this related issue:

https://github.com/bit-team/backintime/issues/724

Please note that the published patch does only fix the backintime GUI issues
but (most probably) not the unwanted umount when the GUI is quit

Please check to the issue status there for updates/fixes...

Bug#1019939: fwupd: Not well documented, what does it actually do on Debian systems?

[J. Pfennig]

Package: fwupd
Version: 1.8.4-2
Severity: minor

Dear Maintainer,

A few days ago we had press reports about updates from a specific os
vendor that made some linux machines unbootable. Although that the 
vendor was probably well minded, this was problematic.

Today, at login I had a motd message from fwupd reminding me of a very
similar (or the same update) on my linux systems. Some user might have
installed it already accidentially via discover.

At this point I was looking for documentation about fwupd (mostly I knew
about it via phoronix.com telling me how great is is). But there is very
little to find in the internet (an outdated ubuntu page, or some arch
linux doc). Debian neither provides sufficient documentation.

Having in mind, that this february a satelite network provider
distrubuted a malicious firmware update that destroied thousands of
satelite modems, I choose the uninstall fwupdate on all machines.

Please:

The fwupdt package is very invasive and might be used maliciously. At
least it should be documented in an understandable way or should be
disabled by default.

It should not be used for automatic updates that can be triggered
by unexperienced users (like in discover) at all.

Yours Jürgen

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

Kernel: Linux 5.19.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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fwupd depends on:
ii  libc6  2.34-7
ii  libcurl3-gnutls7.85.0-1
ii  libefiboot137-6
ii  libelf10.187-2
pn  libflashrom1   
ii  libfwupd2  1.8.4-2
pn  libfwupdplugin1
pn  libfwupdplugin7
ii  libglib2.0-0   2.73.3-3
ii  libgnutls303.7.7-2
ii  libgudev-1.0-0 237-2
ii  libgusb2   0.3.10-1
ii  libjcat1   0.1.9-1
ii  libjson-glib-1.0-0 1.6.6-1
ii  libmbim-glib4  1.26.4-1
ii  libmbim-proxy  1.26.4-1
ii  libmm-glib01.18.10-2
ii  libpolkit-gobject-1-0  0.105-33
ii  libprotobuf-c1 1.4.1-1
ii  libqmi-glib5   1.30.8-1
ii  libqmi-proxy   1.30.8-1
pn  libsmbios-c2   
ii  libsqlite3-0   3.39.3-1
ii  libsystemd0251.4-3
ii  libtss2-esys-3.0.2-0   3.2.0-1+b1
pn  libxmlb1   
ii  libxmlb2   0.3.8-1
ii  shared-mime-info   2.2-1

Versions of packages fwupd recommends:
pn  bolt   
ii  dbus   1.14.0-2
pn  fwupd-signed   
pn  jq 
ii  python33.10.6-1
pn  secureboot-db  
ii  udisks22.9.4-3

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

Bug#1019656: dwww: cannot set custom title containing spaces with configuration parameter DWWW_TITLE

[J G Miller]

Package: dwww
Version: 1.14
Severity: wishlist

The dwww configuration file "/etc/dwww/dwww.conf" statess

"The file is in Bourne shell script format, thus no spaces may be used in 
variables assignments."

which gives a false impression since the configuration file is in fact read 
using the Perl
configuration file /usr/share/perl5/Debian/Dwww/ConfigFile.pm which parses the 
entries
using the regular expression on line 150

(m/^\s*([^=]+)\s*=\s*['"]?([^'"\s]+)['"]?\s*$/)

This expression deoes not enforce that the type of quote for the end of the 
parameter value matches
the type of quote used for the end of the parameter value ie the starting quote 
can be a single
quote and the cloing quote van be a double quote or vice versa, which seems 
rather strange.

Since the default title contains a space vis 'dwww: your_hostname' it is surely 
not unreasonable
to override this with a custom title containning one or more spaces.  It would 
be simple to
add if condition that if the parameter is DWWW_TITLE then a different regular 
expression is
used without the restriction of not allowing one or more spaces in the string.

Further it could also be permitted that if the opening and closing quotes are 
limitd to double
quotes for the DWWW_TITLE parameter, then one or ore single quotes would be 
permitted in the
string which would allow possessives eg "Debian's" to be used.

Thanking your for your consideration of these suggested improvements to the 
dwww package.

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

Kernel: Linux 5.10.0-18-marvell
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ISO-8859-1) (ignored: 
LC_ALL set to en_US), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dwww depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  debianutils4.11.2
ii  doc-base   0.11.1
ii  file   1:5.39-3
ii  libc6  2.31-13+deb11u4
ii  libfile-ncopy-perl 0.36-2.1
ii  libmime-types-perl 2.18-1
ii  lighttpd [httpd-cgi]   1.4.59-1+deb11u1
ii  man-db 2.9.4-2
ii  mime-support   3.66
ii  perl   5.32.1-4+deb11u2
ii  sensible-utils 0.0.14
ii  ucf3.0043

Versions of packages dwww recommends:
ii  apt   2.2.4
ii  dlocate   1.07+nmu1
ii  info2www  1.2.2.9-24.1
ii  lighttpd [httpd]  1.4.59-1+deb11u1
ii  swish++   6.1.5-5

Versions of packages dwww suggests:
ii  doc-debian   6.5
ii  dpkg-www 2.61
pn  links | www-browser  

-- debconf information excluded

Bug#1019534: at gives error message: Cannot give away file: Operation not permitted

[Klaus-J. Wolf]

Package: at
Version: 3.1.23-1.1
Severity: normal

Dear Maintainer,

$ echo touch atd_is_here |at 12:10
warning: commands will be executed using /bin/sh
Cannot give away file: Operation not permitted

The error message suggests that there is a permission problem, while it is 
unclear
what can be done about that.

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

Kernel: Linux 5.19.0-8.2-liquorix-amd64 (SMP w/6 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)

Versions of packages at depends on:
ii  libc6   2.31-13+deb11u4
ii  libfl2  2.6.4-8
ii  libpam-runtime  1.4.0-9+deb11u1
ii  libpam0g1.4.0-9+deb11u1
ii  libselinux1 3.1-3
ii  lsb-base11.1.0

Versions of packages at recommends:
ii  postfix [mail-transport-agent]  3.5.13-0+deb11u1

at suggests no packages.

-- Configuration Files:
/etc/at.deny [Errno 13] Permission denied: '/etc/at.deny'

-- no debconf information