Bug#1051746: RFP: rust-associative-cache -- A generic N-way associative cache with fixed-size capacity and random or least recently used (LRU) replacement

[Agathe Porte]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: gag...@debian.org

* Package name: rust-associative-cache
  Version : 2.0.0
  Upstream Contact: Nick Fitzgerald 
* URL : https://github.com/fitzgen/associative-cache
* License : MIT OR Apache-2.0
  Programming Lang: Rust
  Description : A generic N-way associative cache with fixed-size capacity 
and random or least recently used (LRU) replacement

A generic, fixed-size, associative cache data structure mapping K keys to V 
values.

This is a dependency for packaging python-orjson [1].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002996

Bug#1051745: RM: r-cran-mlmrev [i386] -- ROM; Does not pass its autopkgtest on i386

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: r-cran-mlm...@packages.debian.org, 1043...@bugs.debian.org
Control: affects -1 + src:r-cran-mlmrev

Hi,

this package times out in its package test for i386 architecture (see
bug #1043130).  There is no real point in keeping this package on
architectures where its not used in practice.  So please remove this
package for i386 from the Debian archive.

Thanks a lot for your work as ftpmaster
Andreas.

Bug#1051744: linux-image-6.1.0-12-amd64: DVB unable to load module dvb_usb_mxl111sf

[Steve VanDevender]

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

Dear Maintainer,

As of linux-image-6.1.0-12, I can no longer use my Hauppage WinTV-Aero-M as
one of its necessary kernel modules (lgdt3305) now fails to load.

2023-09-11T19:35:12.938596-07:00 glitch kernel: [39125.513119] usb 1-1.2: new hi
gh-speed USB device number 4 using ehci-pci
2023-09-11T19:35:13.046533-07:00 glitch kernel: [39125.622902] usb 1-1.2: New US
B device found, idVendor=2040, idProduct=c61b, bcdDevice= 0.00
2023-09-11T19:35:13.046551-07:00 glitch kernel: [39125.622915] usb 1-1.2: New US
B device strings: Mfr=1, Product=2, SerialNumber=3
2023-09-11T19:35:13.046554-07:00 glitch kernel: [39125.622919] usb 1-1.2: Produc
t: WinTV Aero-M
2023-09-11T19:35:13.046555-07:00 glitch kernel: [39125.622922] usb 1-1.2: Manufa
cturer: Hauppauge
2023-09-11T19:35:13.046556-07:00 glitch kernel: [39125.622925] usb 1-1.2: Serial
Number: 4034988989
2023-09-11T19:35:14.198544-07:00 glitch kernel: [39126.776720] usb 1-1.2: dvb_us
b_v2: found a 'Hauppauge WinTV-Aero-M' in warm state
2023-09-11T19:35:14.198566-07:00 glitch kernel: [39126.776775] usb 1-1.2: 
dvb_usb_v2: will pass the complete MPEG2 transport stream to the software 
demuxer
2023-09-11T19:35:14.198569-07:00 glitch kernel: [39126.776847] dvbdev: DVB: 
registering new adapter (Hauppauge WinTV-Aero-M)
2023-09-11T19:35:14.198571-07:00 glitch kernel: [39126.776853] usb 1-1.2: media 
controller created
2023-09-11T19:35:14.200945-07:00 glitch kernel: [39126.777182] dvbdev: 
dvb_create_media_entity: media entity 'dvb-demux' registered.
2023-09-11T19:35:14.478543-07:00 glitch kernel: [39127.053919] failing 
symbol_get of non-GPLONLY symbol lgdt3305_attach.
2023-09-11T19:35:14.478563-07:00 glitch kernel: [39127.053925] DVB: Unable to 
find symbol lgdt3305_attach()
2023-09-11T19:35:14.478566-07:00 glitch kernel: [39127.054502] 
dvb_usb_mxl111sf: probe of 1-1.2:1.0 failed with error -5
2023-09-11T19:35:14.478567-07:00 glitch kernel: [39127.054527] usbcore: 
registered new interface driver dvb_usb_mxl111sf

In 6.1.0-11 and earlier, it would successfully load like this:

2023-09-03T20:56:46.678283-07:00 glitch kernel: [698673.786292] usb 1-1.2: new h
igh-speed USB device number 22 using ehci-pci
2023-09-03T20:56:46.786379-07:00 glitch kernel: [698673.896208] usb 1-1.2: New U
SB device found, idVendor=2040, idProduct=c61b, bcdDevice= 0.00
2023-09-03T20:56:46.786406-07:00 glitch kernel: [698673.896215] usb 1-1.2: New U
SB device strings: Mfr=1, Product=2, SerialNumber=3
2023-09-03T20:56:46.786408-07:00 glitch kernel: [698673.896217] usb 1-1.2: Produ
ct: WinTV Aero-M
2023-09-03T20:56:46.786410-07:00 glitch kernel: [698673.896218] usb 1-1.2: 
Manufacturer: Hauppauge
2023-09-03T20:56:46.786411-07:00 glitch kernel: [698673.896219] usb 1-1.2: 
SerialNumber: 4034988989
2023-09-03T20:56:46.786412-07:00 glitch kernel: [698673.896755] usb 1-1.2: 
dvb_usb_v2: found a 'Hauppauge WinTV-Aero-M' in warm state
2023-09-03T20:56:46.786413-07:00 glitch kernel: [698673.896791] usb 1-1.2: 
dvb_usb_v2: will pass the complete MPEG2 transport stream to the software 
demuxer
2023-09-03T20:56:46.786417-07:00 glitch kernel: [698673.896844] dvbdev: DVB: 
registering new adapter (Hauppauge WinTV-Aero-M)
2023-09-03T20:56:46.786418-07:00 glitch kernel: [698673.896847] usb 1-1.2: 
media controller created
2023-09-03T20:56:46.786419-07:00 glitch kernel: [698673.897142] dvbdev: 
dvb_create_media_entity: media entity 'dvb-demux' registered.
2023-09-03T20:56:47.425649-07:00 glitch kernel: [698674.536902] MxL111SF 
detected, v8_200 (0x18)
2023-09-03T20:56:47.425666-07:00 glitch kernel: [698674.536929] usb 1-1.2: DVB: 
registering adapter 0 frontend 0 (LG Electronics LGDT3305 VSB/QAM Frontend)...
2023-09-03T20:56:47.425668-07:00 glitch kernel: [698674.536953] dvbdev: 
dvb_create_media_entity: media entity 'LG Electronics LGDT3305 VSB/QAM 
Frontend' registered.
2023-09-03T20:56:47.425669-07:00 glitch kernel: [698674.537087] usb 1-1.2: DVB: 
registering adapter 0 frontend 1 (MaxLinear MxL111SF DVB-T demodulator)...
2023-09-03T20:56:47.425669-07:00 glitch kernel: [698674.537099] dvbdev: 
dvb_create_media_entity: media entity 'MaxLinear MxL111SF DVB-T demodulator' 
registered.
2023-09-03T20:56:47.425670-07:00 glitch kernel: [698674.537175] usb 1-1.2: DVB: 
registering adapter 0 frontend 2 (LG Electronics LG2161 ATSC/MH Frontend)...
2023-09-03T20:56:47.425671-07:00 glitch kernel: [698674.537184] dvbdev: 
dvb_create_media_entity: media entity 'LG Electronics LG2161 ATSC/MH Frontend' 
registered.
2023-09-03T20:56:47.474216-07:00 glitch kernel: [698674.583615] tveeprom: 
Hauppauge model 126001, rev F2G4, serial# 4034988989
2023-09-03T20:56:47.474231-07:00 glitch kernel: [698674.583622] tveeprom: MAC 
address is 00:0d:fe:81:0b:bd
2023-09-03T20:56:47.474232-07:00 glitch kernel: [698674.583624] tveeprom: tuner 
model is MaxLinear 111 (idx 164, type 4)
2023-09-03T20:56:47.474233-07:00 glitch kernel: [698674.583626] tveeprom: TV 
standards 

Bug#872587: Document the Protected field

[Russ Allbery]

Control: retitle -1 Document the Protected field

Adam Borowski  writes:
> On Fri, Aug 18, 2017 at 02:28:22PM -0700, Sean Whitton wrote:

>> Do you have any idea how long we can expect to wait until dpkg supports
>> the field?  I would suggest that we wait until dpkg has defined
>> behaviour for the field, as it will make documenting it much easier.
>> It will also allow us to be more confident that there is no serious
>> disagreement about the purpose of the field.

> Right, let's have dpkg maintainers tell us what they think.

>> I couldn't find a bug against dpkg, but if there is one, it should
>> probably be set to block this bug.

> 872587 < 872589, I filed the Policy one first.  Block added.

Per the resolution of #872589, this was implemented as the Protected field
instead.  Retitling the bug accordingly.

The documentation from deb-control(5) is:

Protected: yes|no
This field is usually only needed when the answer is yes.  It denotes
a package that is required mostly for proper booting of the system or
used for custom system-local meta-packages.  dpkg(1) or any other
installation tool will not allow a Protected package to be removed (at
least not without using one of the force options).

It's probably also worth noting the parenthetical comment in the
documentation of Essential:

Essential: yes|no
This field is usually only needed when the answer is yes.  It denotes
a package that is required for the packaging system, for proper
operation of the system in general or during boot (although the latter
should be converted to Protected field instead).  dpkg(1) or any other
installation tool will not allow an Essential package to be removed
(at least not without using one of the force options).

(And while we're there, we don't document the Build-Essential field
either.)

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

Bug#1050172: ITS: mah-jong

[肖盛文]

Hi Nicolas,

    Thanks for reply.

The new version  mah-jong had upload to mentors:

https://mentors.debian.net/package/mah-jong/

Cheers,

在 2023/9/11 01:04, Nicolas Boullis 写道:

Hello,

On Mon, Aug 21, 2023 at 06:28:05PM +0800, xiao sheng wen wrote:

The current maintainer of mah-jong is Nicolas Boullis , he 
is not active now.

The mah-jong has new upstream version.

I want ITS mah-jong.

You’re absolutely right, I haven’t given the mah-jong mackage any love
for too many years. If you’re willing to take over maintenance for this
package, please go ahead.


Cheers,



--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Russ Allbery]

Sam Hartman  writes:
>> "Luca" == Luca Boccassi  writes:

> Luca> Thank you, looks good to me, seconded.

> LGTM too, seconded.

Thanks!  This has now been merged for the next Policy release.

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

Bug#1051743: debhelper: dh_installsystemd --name documentation doesn't match actual behavior

[Mark Eichin]

Subject: debhelper: dh_installsystemd --name documentation doesn't match actual 
behavior
Package: debhelper
Version: 13.11.6
Severity: normal

Dear Debhelper Maintainers,

The dh_installsystemd documentation says that

   As an example, B will look for
   F<<< IB<< I >>I<.service> >>> instead of
   F<< I >>).  

after building a handful of packages and having this silently not work
(the silence isn't a problem per-se, it's just supposed to look for a
correctly named file and use it if present) I eventually figured out
that it would instead install the file F<< I >>,
ie. it would drop I entirely and just use the --name
argument.

There is also a lengthy comment in the source where the work happens
that matches the POD documentation, but the code itself at that point
simply does

   my $name = $dh{NAME} // $package;

which doesn't concatenate anything, it just uses --name if defined, and
package if not.

A quick glance through git history shows that it's behaved this way
since at least 2018 and it looks like that was just an accurate
refactoring of the previous code - I haven't dug further, but perhaps
that is enough to suggest that 5 years is long enough that the
documentation should change to match the behaviour rather than changing
the code (possibly across debhelper's famously well-managed
compatibility levels.)

(If you agree with my assessment, I would be happy to contribute a
documentation patch, though it would be US/English only, I haven't
worked with translations before.)

Bug#963524: debian-policy: Binary and Description fields not mandatory in .changes on source-only uploads

[Russ Allbery]

Guillem Jover  writes:

> Seconded.

Thanks!  I think the wording changes subsequent to Sam's second are
informative and within the changes the Policy Editor can make without
seconds, so I'm proceeding with this and Sam's second and have merged this
change for the next Policy release.

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

Bug#1041731: groff-base: "-" mapped as HYPHEN

[Russ Allbery]

Guillem Jover  writes:
> On Mon, 2023-08-14 at 14:18:51 +0200, Samuel Thibault wrote:

>> Yes, we'd ideally want to fix all manpages to have everything set
>> alright. But we have to do that before the release. And if that's not
>> complete, release with the
>> 
>> .char - \-
>> 
>> workaround.

> Whenever I've maintained man pages in roff I tend to be precise in
> the usage of - and \-, but TBH this has seemed like a lost battle,
> more so since at least lintian stopped emitting tags for it. And
> another problem which I think it's going to be very hard to fix is
> with man page generators from other formats, such as pod2man, where
> it currently has heuristics to determine when to use - or \-, but it
> does not currently has a way to accurately do this always.

Yes, I understand why upstream really wants to find a way to make the
distinction between a language hyphen and an ASCII hyphen to work.  They
are different characters in the *roff language, and in a proper
typesetting system such as troff is intended to be, it is important to
distinguish between them for the best output.

That said, I was surprised to see the attempt to go down this path again
given how many problems we had the last time, and I am quite dubious that
we will be successful.  Not only is this a fiddly point of *roff that a
lot of people writing man pages simply don't pay attention to, man pages
are also generated from a host of other formats that simply do not have
this distinction in their language and therefore *cannot* make this
distinction in generated *roff except by guessing.

Just to give you an idea of the sort of thing that I'm trying to maintain
in order to be "correct" about this distinction, here is the current code
from podlators:

s{
( (?:\G|^|\s|$NBSP) [\(\"]* [a-zA-Z] ) ( \\- )?
( (?: [a-zA-Z\']+ \\-)+ )
( [a-zA-Z\']+ ) (?= [\)\".?!,;:]* (?:\s|$NBSP|\Z|\\\ ) )
\b
} {
my ($prefix, $hyphen, $main, $suffix) = ($1, $2, $3, $4);
$hyphen ||= '';
$main =~ s/\\-/-/g;
$prefix . $hyphen . $main . $suffix;
}egx;

This is still obviously buggy, though.  For example, command names
mentioned in the text look like words with hyphens and I don't think
there's any real way to tell the difference.

I have to admit that I am somewhat tempted to at least make this
transformation optional and instead let people configure pod2man to simply
escape every single - character as \- in the output.  This is not
"correct", but I think it's more correct than what is happening now, and
it's at least consistent.  However, I have a note that I have to do this
translation or *roff will produce unacceptable output, and I don't
remember what problem there was that made me write that comment in the
first place.  Maybe the problem with breaking long lines with
lots-of-words-that-are-all-conncted-by-hyphens, although that's somewhat
rare.

My opinion is that the world of documents that are handled by man do not
encode meaningful distinctions between - and \-, and man should therefore
unify those characters.

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

Bug#1041731: groff-base: "-" mapped as HYPHEN

[Guillem Jover]

Hi!

[ CCed Russ for the pod2man side of this. ]

On Mon, 2023-08-14 at 14:18:51 +0200, Samuel Thibault wrote:
> I'm marking this important, and am tempted to raise it to serious...
> 
> The problem at stake is that we have already a hard time making
> newcomers read manpages. If they can't even trust copying/pasting lines
> from them, they will just definitely turn away, and we'll aggravate the
> schism between us olders and newcomers. Trust me from 20-year teaching
> experience...

This is not just copy, searching in formatted man pages from
within a pager or with grep for example does not work any more (well
you can always use «.» but that's rather unintuitive).

> Yes, we'd ideally want to fix all manpages to have everything set
> alright. But we have to do that before the release. And if that's not
> complete, release with the
> 
> .char - \-
> 
> workaround.

Whenever I've maintained man pages in roff I tend to be precise in
the usage of - and \-, but TBH this has seemed like a lost battle,
more so since at least lintian stopped emitting tags for it. And
another problem which I think it's going to be very hard to fix is
with man page generators from other formats, such as pod2man, where
it currently has heuristics to determine when to use - or \-, but it
does not currently has a way to accurately do this always.

> As in: maybe we can leave the symptom open until the freeze period, so
> that developers notice the issue and fix their bugs, and on the freeze
> period, introduce the workaround so that end users of the eventual
> released distribution don't get affected while we are still fixing the
> bugs.

While in an ideal world that might be good, I'm not sure this is worth
the pain, and fixing this (if deemed necessary) out of linting tags
seems like a better plan?

Thanks,
Guillem

Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

[Pablo Neira Ayuso]

Hi Timo,

On Mon, Sep 11, 2023 at 11:37:50PM +0200, Timo Sigurdsson wrote:
> Hi,
> 
> recently, Debian updated their stable kernel from 6.1.38 to 6.1.52
> which broke nftables ruleset loading on one of my machines with lots
> of "Operation not supported" errors. I've reported this to the
> Debian project (see link below) and Salvatore Bonaccorso and I
> identified "netfilter: nf_tables: disallow rule addition to bound
> chain via NFTA_RULE_CHAIN_ID" (0ebc1064e487) as the offending commit
> that introduced the regression. Salvatore also found that this issue
> affects the 5.10 stable tree as well (observed in 5.10.191), but he
> cannot reproduce it on 6.4.13 and 6.5.2.
> 
> The issue only occurs with some rulesets. While I can't trigger it
> with simple/minimal rulesets that I use on some machines, it does
> occur with a more complex ruleset that has been in use for months
> (if not years, for large parts of it). I'm attaching a somewhat
> stripped down version of the ruleset from the machine I originally
> observed this issue on. It's still not a small or simple ruleset,
> but I'll try to reduce it further when I have more time.
> 
> The error messages shown when trying to load the ruleset don't seem
> to be helpful. Just two simple examples: Just to give two simple
> examples from the log when nftables fails to start:
> /etc/nftables.conf:99:4-44: Error: Could not process rule: Operation not 
> supported
> tcp option maxseg size 1-500 counter drop
> ^
> /etc/nftables.conf:308:4-27: Error: Could not process rule: Operation not 
> supported
> tcp dport sip-tls accept
> 

I can reproduce this issue with 5.10.191 and 6.1.52 and nftables v1.0.6,
this is not reproducible with v1.0.7 and v1.0.8.

> Since the issue only affects some stable trees, Salvatore thought it
> might be an incomplete backport that causes this.
> 
> If you need further information, please let me know.

Userspace nftables v1.0.6 generates incorrect bytecode that hits a new
kernel check that rejects adding rules to bound chains. The incorrect
bytecode adds the chain binding, attach it to the rule and it adds the
rules to the chain binding. I have cherry-picked these three patches
for nftables v1.0.6 userspace and your ruleset restores fine.

See patches enclosed to this email.
>From 4e5b0a64227dde250f94bec45b3fb127d78b7fd2 Mon Sep 17 00:00:00 2001
From: Pablo Neira Ayuso 
Date: Mon, 6 Feb 2023 15:28:40 +0100
Subject: [PATCH 1/3,nft] rule: add helper function to expand chain rules intoi
 commands

[ upstream commit 784597a4ed63b9decb10d74fdb49a1b021e22728 ]

This patch adds a helper function to expand chain rules into commands.
This comes in preparation for the follow up patch.

Signed-off-by: Pablo Neira Ayuso 
---
 src/rule.c | 39 ++-
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/src/rule.c b/src/rule.c
index 1402210acd8d..43c6520517ce 100644
--- a/src/rule.c
+++ b/src/rule.c
@@ -1310,13 +1310,31 @@ void cmd_add_loc(struct cmd *cmd, uint16_t offset, const struct location *loc)
 	cmd->num_attrs++;
 }
 
+static void nft_cmd_expand_chain(struct chain *chain, struct list_head *new_cmds)
+{
+	struct rule *rule;
+	struct handle h;
+	struct cmd *new;
+
+	list_for_each_entry(rule, >rules, list) {
+		memset(, 0, sizeof(h));
+		handle_merge(, >handle);
+		if (chain->flags & CHAIN_F_BINDING) {
+			rule->handle.chain_id = chain->handle.chain_id;
+			rule->handle.chain.location = chain->location;
+		}
+		new = cmd_alloc(CMD_ADD, CMD_OBJ_RULE, ,
+>location, rule_get(rule));
+		list_add_tail(>list, new_cmds);
+	}
+}
+
 void nft_cmd_expand(struct cmd *cmd)
 {
 	struct list_head new_cmds;
 	struct flowtable *ft;
 	struct table *table;
 	struct chain *chain;
-	struct rule *rule;
 	struct set *set;
 	struct obj *obj;
 	struct cmd *new;
@@ -1362,22 +1380,9 @@ void nft_cmd_expand(struct cmd *cmd)
 	>location, flowtable_get(ft));
 			list_add_tail(>list, _cmds);
 		}
-		list_for_each_entry(chain, >chains, list) {
-			list_for_each_entry(rule, >rules, list) {
-memset(, 0, sizeof(h));
-handle_merge(, >handle);
-if (chain->flags & CHAIN_F_BINDING) {
-	rule->handle.chain_id =
-		chain->handle.chain_id;
-	rule->handle.chain.location =
-		chain->location;
-}
-new = cmd_alloc(CMD_ADD, CMD_OBJ_RULE, ,
-		>location,
-		rule_get(rule));
-list_add_tail(>list, _cmds);
-			}
-		}
+		list_for_each_entry(chain, >chains, list)
+			nft_cmd_expand_chain(chain, _cmds);
+
 		list_splice(_cmds, >list);
 		break;
 	case CMD_OBJ_SET:
-- 
2.30.2

>From 70c03d81df0e87fb416bd1f38409367e9d08ed7f Mon Sep 17 00:00:00 2001
From: Pablo Neira Ayuso 
Date: Mon, 6 Feb 2023 15:28:41 +0100
Subject: [PATCH 2/3,nft] rule: expand standalone chain that contains rules

[ upstream 27c753e4a8d4744f479345e3f5e34cafef751602 commit ]

Bug#1042994: Bug solved in version libreoffice/4:7.6.1~rc2-2

[Thomas Florek]

LO Draw and LO Impress now start as normal.

Bug#1043273: amd64-microcode: AMD SEV firmware files not loaded on matching systems

[Diederik de Haas]

On Tue, 8 Aug 2023 13:41:56 +0300 Marko Karppinen  wrote:
> It seems nothing will make you understand an issue faster than filing your
> first ever Debian bug about it :)
> 
> I noticed just now that the firmware loading *will* fall back to the correct
> file, it just happens after it has emitted the error lines:
> 
> > [4.069026] ccp :4a:00.1: firmware: failed to load 
> > amd/amd_sev_fam17h_model31h.sbin (-2)
> > [4.069293] firmware_class: See https://wiki.debian.org/Firmware for 
> > information about missing firmware
> > [4.069597] ccp :4a:00.1: firmware: failed to load 
> > amd/amd_sev_fam17h_model31h.sbin (-2)
> > [4.070002] ccp :4a:00.1: firmware: direct-loading firmware 
> > amd/amd_sev_fam17h_model3xh.sbin
> > [4.102461] ccp :4a:00.1: SEV API:0.24 build:16
> 
> This is made somewhat more difficult to notice by the error lines being
> highlighted and the lines indicating success not. So while my proposed
> symlinks do eliminate the error output in red, they wouldn’t affect actual
> functionality.
> 
> I think this issue can be closed.

AFAICT this is actually https://bugs.debian.org/1040738, which makes it a
kernel bug. As the maintainer has reassigned/merged #1051635 into this one
and thus to the amd64-microcode package, I'll leave reassigning it to src:linux
over to (one of) the maintainer(s).

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

Bug#1037559: systemd-networkd-wait-online waits undefinitely if no networkd managed interfaces

[Michael Biebl]

Will be fixed in 252.15 via
https://github.com/systemd/systemd-stable/commit/f4831559171033ab044758e7fd68627e3bfe84a5


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051742: RFS: miniaudio/0.11.18+dfsg-1 [ITP] -- audio playback and capture library

[Matthias Geiger]

Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear mentors,

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

 * Package name : miniaudio
   Version  : 0.11.18+dfsg-1
   Upstream contact : David Reid 
 * URL  : https://github.com/mackron/miniaudio
 * License  : MIT-0 or Unlicense, Expat or Unlicense
 * Vcs  : https://salsa.debian.org/debian/miniaudio
   Section  : libdevel

The source builds the following binary packages:

  libminiaudio-dev - audio playback and capture library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/miniaudio/miniaudio_0.11.18+dfsg-1.dsc

Changes for the initial release:

 miniaudio (0.11.18+dfsg-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #950181)

This is just a single-header library needed to de-vendor another
program.

Regards,
- -- 
  Matthias Geiger




-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmT/kRIVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1TMoQALParifSpljOtDmVCrwb1zPpiQdw
mWOTkv7yJ0tQrGU5dyUPRznutl8j2ZX05+lzS32qPtEPF0a1ewIkz+5n9KLQL46O
HBXric62PR32XxUw63yIqQmE3YluoEnrB19S3bKkq7BEWqz/YPbbeN2RLCdIgePb
LDGhDrlynwiiN1uFjAx1omIUYWMs9/L53920FCJe0fV7P5X0Wcb0zK0xoZ+xOgWs
aqv0RUMUIkbZK40VbU1BdVpgLXO8Pwfl8S/5caC9d2dqXcPbhnZFmSc55/yYWBzP
RKd9c6qEEWBY8F1CHnnSLXU40KVIK5MNZ1O+QnPAXEMvP3VlH6dmNp7wgXxY1YIx
9weZb3rTZ3dcbpA1DVs6e1SCf2w+oiQ01hcrSK8OJCTmjuDoVTaDolcCalg+7Sbv
DSK6pYho8xcCCFaUgJAYf/XMjRG29i0WHznv3iWAyKDODWjr8cO86A8MgeGDsdxP
LaKseqaL/MYTtKpCFfi6rKRXIwyIcvpx+VSTxe4KXa6ql9y4IIO1ANg6vGhqxZKC
+R+3516yYxtoU4WIrb0EDBQbsbFfjYDBOzgf4303rKZa67+P5iN+qd5GmdktvUUG
vDCj6hIZOmtZ3kP9hERYtmUndHHM3W250+fL7Op8l4JfnpOhyq82cbRl/GFm++Gp
HOBW2e68DVL59Mwx
=POv9
-END PGP SIGNATURE-

Bug#1051497: Please upgrade NewTX to 1.726 2023-08-25

[Al Ma]

Alright, got it. Thanks! I simply wanted to make you aware that there's a need 
for an upgrade of specifically NewTX to a specific version (as compared to 
upgrades of other LaTeX packages or to an upgrade of NewTX to prior or 
yet-to-appear versions) because, as fas as I tested so far (around 1000 pages 
through `pdflatex` and `latex`), this version of NewTX is probably relatively 
free of issues (as compared to other versions of NewTX or other LaTeX packages 
you might wish to upgrade). Gratefully, AlMa
09.09.2023, 00:51, Preuße, Hilmar < mailto:hill...@web.de hill...@web.de >
Control: tags -1 + pending On 08.09.2023 19:43, Al Ma wrote: Hi Al, > Please 
upgrade NewTX to 1.726 (dated 2023-08-25).  The following two > problems are 
resolved there /simultenaously/: > There is no need to send package update 
requests. I'm doing package updates on a regulars basis. I tag that issue 
pending and will close it in one of the next uploads. H. -- sigfault

Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

[Timo Sigurdsson]

Hi,

recently, Debian updated their stable kernel from 6.1.38 to 6.1.52 which broke 
nftables ruleset loading on one of my machines with lots of "Operation not 
supported" errors. I've reported this to the Debian project (see link below) 
and Salvatore Bonaccorso and I identified "netfilter: nf_tables: disallow rule 
addition to bound chain via NFTA_RULE_CHAIN_ID" (0ebc1064e487) as the offending 
commit that introduced the regression. Salvatore also found that this issue 
affects the 5.10 stable tree as well (observed in 5.10.191), but he cannot 
reproduce it on 6.4.13 and 6.5.2.

The issue only occurs with some rulesets. While I can't trigger it with 
simple/minimal rulesets that I use on some machines, it does occur with a more 
complex ruleset that has been in use for months (if not years, for large parts 
of it). I'm attaching a somewhat stripped down version of the ruleset from the 
machine I originally observed this issue on. It's still not a small or simple 
ruleset, but I'll try to reduce it further when I have more time.

The error messages shown when trying to load the ruleset don't seem to be 
helpful. Just two simple examples:
Just to give two simple examples from the log when nftables fails to start:
/etc/nftables.conf:99:4-44: Error: Could not process rule: Operation not 
supported
tcp option maxseg size 1-500 counter drop
^
/etc/nftables.conf:308:4-27: Error: Could not process rule: Operation not 
supported
tcp dport sip-tls accept


Since the issue only affects some stable trees, Salvatore thought it might be 
an incomplete backport that causes this.

If you need further information, please let me know.


Thanks and kind regards,

Timo


#regzbot introduced: 0ebc1064e487
#regzbot monitor: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051592#!/usr/sbin/nft -f

flush ruleset

define public_if = eth0
define trusted_if = eth1
define voip_if = eth2.10
define guest_if = eth2.20
define home_if = { $trusted_if, $voip_if, $guest_if }
define home_ipv6_if = { $trusted_if, $voip_if, $guest_if }

define masq_ip = { 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 
192.168.4.0/24 }
define masq_if = $public_if

define host1_ip = 192.168.1.10
define host2_ip = 192.168.2.20
define host3_ip = 192.168.3.30
define host4_ip = 192.168.4.40

define proxy_port = 8443

define private_ip = { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
define private_ip6 = { fe80::/64, fd00::/8 }
define bogons_ip = { 0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 
169.254.0.0/16, 172.16.0.0/12, 192.0.0.0/24, 192.0.2.0/24, 192.168.0.0/16, 
198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/3 }
define bogons_ip6 = { ::/3, 2001:0002::/48, 2001:0003::/32, 2001:10::/28, 
2001:20::/28, 2001::/32, 2001:db8::/32, 2002::/16, 3000::/4, 4000::/2, 8000::/1 
}

define sip_whitelist_ip6 = { 2001:db8::1/128, 2001:db8::2/128 }
define smtps_whitelist_ip = 10.0.0.1
define protocol_whitelist = { tcp, udp, icmp, ipv6-icmp }

table inet filter {
map if_input {
type ifname : verdict;
elements = { $public_if : jump public_input, $trusted_if : jump 
home_input, $voip_if : jump home_input, $guest_if : jump home_input }
}
map if_forward {
type ifname : verdict;
elements = { $public_if : jump public_forward, $trusted_if : 
jump trusted_forward, $voip_if : jump voip_forward, $guest_if : jump 
guest_forward }
}
map if_output {
type ifname : verdict;
elements = { $public_if : jump public_output, $trusted_if : 
jump home_output, $voip_if : jump home_output, $guest_if : jump home_output }
}

set ipv4_blacklist { type ipv4_addr; flags interval; auto-merge; }
set ipv6_blacklist { type ipv6_addr; flags interval; auto-merge; }
set limit_src_ip { type ipv4_addr; flags dynamic, timeout; size 1024; }
set limit_src_ip6 { type ipv6_addr; flags dynamic, timeout; size 1024; }

chain PREROUTING_RAW {
type filter hook prerouting priority raw;

meta l4proto != $protocol_whitelist counter drop
tcp flags syn jump {
tcp option maxseg size 1-500 counter drop
tcp sport 0 counter drop
}
rt type 0 counter drop
}

chain PREROUTING_MANGLE {
type filter hook prerouting priority mangle;

ct state vmap { invalid : jump ct_invalid_pre, untracked : jump 
ct_untracked_pre, new : jump ct_new_pre, related : jump rpfilter }
}
chain ct_invalid_pre {
counter drop
}
chain ct_untracked_pre {
icmpv6 type { nd-router-solicit, nd-router-advert, 
nd-neighbor-solicit, nd-neighbor-advert, mld-listener-query, 

Bug#1051741: RFS: budgie-desktop-environment/0.1-1 [ITP] -- Budgie Desktop environment customization for Debian

[David Mohammed]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "budgie-desktop-environment":

 * Package name : budgie-desktop-environment
   Version  : 0.1-1
   Upstream contact : David Mohammed 
 * URL  : https://github.com/UbuntuBudgie/debian-bde
 * License  : GPL-2+
 * Vcs  : https://github.com/UbuntuBudgie/debian-bde/tree/debian
   Section  : x11

The source builds the following binary packages:

  budgie-desktop-environment - Budgie Desktop environment
customization for Debian

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

  https://mentors.debian.net/package/budgie-desktop-environment/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-desktop-environment/budgie-desktop-environment_0.1-1.dsc

Background
I am the project lead of Ubuntu Budgie - an official flavour of
Ubuntu.  I maintain the budgie related packages in both Debian and
Ubuntu.

As part of Ubuntu Budgie our key customisation package is called
budgie-desktop-environment which is similarly named as other desktop
customisation packages.

This RFS brings to Debian the key-parts of Ubuntu Budgie to provide a
stylish one-shot customisation package; currently Debian budgie users
have to customise the vanilla upstream budgie-desktop package.

In keeping with Debian custom, this provides a minimal package
concentrating on the look and feel of budgie end-users expect
out-of-the-box.

Changes for the initial release:

 budgie-desktop-environment (0.1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1051734)

Regards,
-- 
  David Mohammed

Bug#961884: init script and config

[Rob Fantini]

Hello

I got the following init clamonacc script from 
https://www.chaddevops.com/2020/02/ubuntu-1804-installing-clamav-with.html



# /etc/systemd/system/clamonacc.service
[Unit]
Description=ClamAV On Access Scanner
Requires=clamav-daemon.service
After=clamav-daemon.service syslog.target network.target

[Service]
Type=simple
User=root
ExecStart=/usr/sbin/clamonacc -F --log=/var/log/clamav/clamonacc 
--move=/root/quarantine

Restart=on-failure
RestartSec=120s

[Install]
WantedBy=multi-user.target


added this to /etc/clamav/clamd.conf .

OnAccessMaxFileSize 5M
OnAccessMountPath /home
OnAccessIncludePath /home
OnAccessExcludeUname root
OnAccessPrevention true
OnAccessExtraScanning false
VirusEvent /etc/clamav/detected.sh
OnAccessExcludeRootUID yes
OnAccessRetryAttempts 3

and did these
mkdir /root/quarantine

added /etc/clamav/detected.sh  :
#!/bin/bash
#/etc/clamav/detected.sh
#modify reply and to addresses

PATH=/usr/bin
alert="Signature detected: $CLAM_VIRUSEVENT_VIRUSNAME in 
$CLAM_VIRUSEVENT_FILENAME"


logtail="$(tail -n 50 /var/log/clamav/clamav.log | tac)"

# send email
export HOME=/root
/usr/bin/printf "Host: $HOSTNAME.\n$alert\n\ntail -n 50 
/var/log/clamav/clamav.log\n\n\n$logtail" | /usr/bin/mailx -s "VIRUS 
ALERT - $HOSTNAME" -r

re...@yourdomain.com "ale...@yourdomnain.com"

# Send the alert to systemd logger if exist, othewise to /var/log
if [[ -z $(command -v systemd-cat) ]]; then
   echo "$(date) - $alert" >> /var/log/clamav/detections.log
else
   echo "$alert" | /usr/bin/systemd-cat -t clamav -p emerg
fi



Note  , we still have apparmor issues so I disabled clamonacc for now.

Bug#1026333: Fwd: ITP: rustup -- the rust toolchain installer

[shuyu liu]

-- Forwarded message -

> Control: retitle -1 RFP: rustup -- the rust toolchain installer
>
> Control:  noowner -1
>
> On Mon, 11 Sep 2023 12:39:14 -0600 shuyu liu 
> wrote:
>
>  > Hi all,
>  >
>  > First, thank you for considering packaging rustup!
>  >
>  > I wonder how this ITP is going. Are there any blockers? I could provide
>  > some help if you need testing.
>  >
>  > Thanks,
>
>  > Zixing
>
> Hi Zixing,
>
> unfortunately I am pretty busy with maintaining Debian (rust) packages.
>
> I prepared async-compression, it needs sponsorship through NEW by a
> Debian Developer.
>
> Then reqwest's compression feature needs to be re-enabled and the
> download crate need to be packaged (again, through NEW).
>
> After that rustup can be uploaded. I set the bug report back to a RFP
> because I already maintain a lot and would rather have someone dedicated
> to rustup maintaining it.
>
> Let me know if you are interested :)
>
> best,
>
> --
> Matthias Geiger (werdahias)
> Debian Maintainer
> "Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg
>
>
Hi Matthias,

I am interested in picking this up. However, I am not a Debian Developer or
Debian Maintainer so the package will require a sponsorship should it be
done.
In which case, who should I tag when the package is finished?

Thanks,
Zixing

Bug#1051740: gpac: CVE-2023-3012 CVE-2023-3013 CVE-2023-3291 CVE-2023-39562 CVE-2023-4678 CVE-2023-4681 CVE-2023-4682 CVE-2023-4683 CVE-2023-4720 CVE-2023-4721 CVE-2023-4722 CVE-2023-4754 CVE-2023-475

[Moritz Mühlenhoff]

Source: gpac
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for gpac.

CVE-2023-3012[0]:
| NULL Pointer Dereference in GitHub repository gpac/gpac prior to
| 2.2.2.

https://huntr.dev/bounties/916b787a-c603-409d-afc6-25bb02070e69
https://github.com/gpac/gpac/commit/53387aa86c1af1228d0fa57c67f9c7330716d5a7

CVE-2023-3013[1]:
| Unchecked Return Value in GitHub repository gpac/gpac prior to
| 2.2.2.

https://huntr.dev/bounties/52f95edc-cc03-4a9f-9bf8-74f641260073
https://github.com/gpac/gpac/commit/78e539b43293829a14a32e821f5267e3b7417594

CVE-2023-3291[2]:
| Heap-based Buffer Overflow in GitHub repository gpac/gpac prior to
| 2.2.2.

https://huntr.dev/bounties/526954e6-8683-4697-bfa2-886c3204a1d5/
https://github.com/gpac/gpac/commit/6a748ccc3f76ff10e3ae43014967ea4b0c088aaf

CVE-2023-39562[3]:
| GPAC v2.3-DEV-rev449-g5948e4f70-master was discovered to contain a
| heap-use-after-free via the gf_bs_align function at bitstream.c.
| This vulnerability allows attackers to cause a Denial of Service
| (DoS) via supplying a crafted file.

https://github.com/gpac/gpac/issues/2537
https://github.com/gpac/gpac/commit/9024531ee8e6ae8318a8fe0cbb64710d1acc31f6

CVE-2023-4678[4]:
| Divide By Zero in GitHub repository gpac/gpac prior to 2.3-DEV.

https://github.com/gpac/gpac/commit/4607052c482a51dbdacfe1ade10645c181d07b07
https://huntr.dev/bounties/688a4a01-8c18-469d-8cbe-a2e79e80c877

CVE-2023-4681[5]:
| NULL Pointer Dereference in GitHub repository gpac/gpac prior to
| 2.3-DEV.

https://github.com/gpac/gpac/commit/4bac19ad854159b21ba70d8ab7c4e1cd1db8ea1c
https://huntr.dev/bounties/d67c5619-ab36-41cc-93b7-04828e25f60e

CVE-2023-4682[6]:
| Heap-based Buffer Overflow in GitHub repository gpac/gpac prior to
| 2.3-DEV.

https://github.com/gpac/gpac/commit/b1042c3eefca87c4bc32afb404ed6518d693e5be
https://huntr.dev/bounties/15232a74-e3b8-43f0-ae8a-4e89d56c474c

CVE-2023-4683[7]:
| NULL Pointer Dereference in GitHub repository gpac/gpac prior to
| 2.3-DEV.

https://github.com/gpac/gpac/commit/112767e8b178fc82dec3cf82a1ca14d802cdb8ec
https://huntr.dev/bounties/7852e4d2-af4e-4421-a39e-db23e0549922

CVE-2023-4720[8]:
| Floating Point Comparison with Incorrect Operator in GitHub
| repository gpac/gpac prior to 2.3-DEV.

https://github.com/gpac/gpac/commit/e396648e48c57e2d53988d3fd4465b068b96c89a
https://huntr.dev/bounties/1dc2954c-8497-49fa-b2af-113e1e9381ad

CVE-2023-4721[9]:
| Out-of-bounds Read in GitHub repository gpac/gpac prior to 2.3-DEV.

https://github.com/gpac/gpac/commit/3ec93d73d048ed7b46fe6e9f307cc7a0cc13db63
https://huntr.dev/bounties/f457dc62-3cff-47bd-8fd2-1cb2b4a832fc

CVE-2023-4722[10]:
| Integer Overflow or Wraparound in GitHub repository gpac/gpac prior
| to 2.3-DEV.

https://github.com/gpac/gpac/commit/de7f3a852bef72a52825fd307cf4e8f486401a76
https://huntr.dev/bounties/ddfdb41d-e708-4fec-afe5-68ff1f88f830

CVE-2023-4754[11]:
| Out-of-bounds Write in GitHub repository gpac/gpac prior to 2.3-DEV.

https://github.com/gpac/gpac/commit/7e2e92feb1b30fac1d659f6620d743b5a188ffe0
https://huntr.dev/bounties/b7ed24ad-7d0b-40b7-8f4d-3c18a906620c

CVE-2023-4755[12]:
| Use After Free in GitHub repository gpac/gpac prior to 2.3-DEV.

https://github.com/gpac/gpac/commit/895ac12da168435eb8db3f96978ffa4c69d66c3a
https://huntr.dev/bounties/463474b7-a4e8-42b6-8b30-e648a77ee6b3

CVE-2023-4756[13]:
| Stack-based Buffer Overflow in GitHub repository gpac/gpac prior to
| 2.3-DEV.

https://github.com/gpac/gpac/commit/6914d016e2b540bac2c471c4aea156ddef8e8e01
https://huntr.dev/bounties/2342da0e-f097-4ce7-bfdc-3ec0ba446e05

CVE-2023-4758[14]:
| Buffer Over-read in GitHub repository gpac/gpac prior to 2.3-DEV.

https://github.com/gpac/gpac/commit/193633b1648582444fc99776cd741d7ba0125e86
https://huntr.dev/bounties/2f496261-1090-45ac-bc89-cc93c82090d6

CVE-2023-4778[15]:
| Out-of-bounds Read in GitHub repository gpac/gpac prior to 2.3-DEV.

https://huntr.dev/bounties/abb450fb-4ab2-49b0-90da-3d878eea5397/
https://github.com/gpac/gpac/commit/d553698050af478049e1a09e44a15ac884f223ed


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-3012
https://www.cve.org/CVERecord?id=CVE-2023-3012
[1] https://security-tracker.debian.org/tracker/CVE-2023-3013
https://www.cve.org/CVERecord?id=CVE-2023-3013
[2] https://security-tracker.debian.org/tracker/CVE-2023-3291
https://www.cve.org/CVERecord?id=CVE-2023-3291
[3] https://security-tracker.debian.org/tracker/CVE-2023-39562
https://www.cve.org/CVERecord?id=CVE-2023-39562
[4] https://security-tracker.debian.org/tracker/CVE-2023-4678
https://www.cve.org/CVERecord?id=CVE-2023-4678
[5] https://security-tracker.debian.org/tracker/CVE-2023-4681
https://www.cve.org/CVERecord?id=CVE-2023-4681
[6] 

Bug#1051739: 1.26.0-3 uninstallable due to nonexistent package

[T. Joseph Carter]

Package: caja-dropbox
Version: 1.26.0-3
Severity: normal

-3 of this package cannot be installed because it depends on:

> --- libayatana-appindicator1 | libappindicator1 (UNAVAILABLE)

libayatana-appindicator3-1 is available on bookworm, but not
testing or sid. Adding this was done apparently to fix an Ubuntu bug,
but it completely broke the package installation for Debian.

Actually, it broke the package on Ubuntu too—the only version of Ubuntu
that has libayatana-appindicator1 is 22.10. It's not in 23.04 and won't
be in 23.10 either.

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

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

Versions of packages caja-dropbox (1.26.0-2) depends on:
ii  dbus-x11  1.14.10-1
ii  gir1.2-gdkpixbuf-2.0  2.42.10+dfsg-1+b1
ii  gir1.2-glib-2.0   1.78.0-1
ii  gir1.2-gtk-3.03.24.38-5
ii  gir1.2-pango-1.0  1.51.0+ds-2
ii  libc6 2.37-8
ii  libcaja-extension11.26.1-1
ii  libglib2.0-0  2.78.0-1
ii  libgtk-3-03.24.38-5
ii  policykit-1   123-1
ii  procps2:4.0.3-1
ii  python3   3.11.4-5+b1
ii  python3-gi3.44.1-2
ii  python3-gpg   1.18.0-3+b1

caja-dropbox recommends no packages.

Versions of packages caja-dropbox suggests:
ii  caja  1.26.1-1

-- no debconf information

Bug#1051738: freeimage: CVE-2020-21428

[Moritz Mühlenhoff]

Source: freeimage
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for freeimage.

CVE-2020-21428[0]:
| Buffer Overflow vulnerability in function LoadRGB in PluginDDS.cpp
| in FreeImage 3.18.0 allows remote attackers to run arbitrary code
| and cause other impacts via crafted image file.

https://sourceforge.net/p/freeimage/bugs/299/

This appears to be fixed in r1877 of the upstream Subversion repository

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1051737: freeimage: CVE-2020-21427

[Moritz Mühlenhoff]

Source: freeimage
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for freeimage.

CVE-2020-21427[0]:
| Buffer Overflow vulnerability in function LoadPixelDataRLE8 in
| PluginBMP.cpp in FreeImage 3.18.0 allows remote attackers to run
| arbitrary code and cause other impacts via crafted image file.

https://sourceforge.net/p/freeimage/bugs/298/

The bug mentions "fixed in the SVN version", but it's unclear in
which version and when.

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1051736: freeimage: CVE-2020-21426

[Moritz Mühlenhoff]

Source: freeimage
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for freeimage.

CVE-2020-21426[0]:
| Buffer Overflow vulnerability in function C_IStream::read in
| PluginEXR.cpp in FreeImage 3.18.0 allows remote attackers to run
| arbitrary code and cause other impacts via crafted image file.

https://sourceforge.net/p/freeimage/bugs/300/

The bug mentions "fixed in the SVN" version, but it's unclear with which
commit and when.

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1051592: linux: Regression - upgrade to 6.1.52-1 breaks nftables

[Salvatore Bonaccorso]

Hi,

On Mon, Sep 11, 2023 at 10:52:12PM +0200, Salvatore Bonaccorso wrote:
> Hi Timo,
> 
> On Mon, Sep 11, 2023 at 10:31:56PM +0200, Timo Sigurdsson wrote:
> > Hi Salvatore,
> > 
> > Salvatore Bonaccorso schrieb am 11.09.2023 22:20 (GMT +02:00):
> > 
> > > Bisected the issue:
> > > 
> > > $ git bisect log
> > > git bisect start
> > > # status: waiting for both good and bad commits
> > > # good: [61fd484b2cf6bc8022e8e5ea6f693a9991740ac2] Linux 6.1.38
> > > git bisect good 61fd484b2cf6bc8022e8e5ea6f693a9991740ac2
> > > # status: waiting for bad commit, 1 good commit known
> > > # bad: [1321ab403b38366a4cfb283145bb2c005becb1e5] Linux 6.1.45
> > > git bisect bad 1321ab403b38366a4cfb283145bb2c005becb1e5
> > > # good: [95d49f79e94d4fa8105c880a266789609f3e791a] ext4: only update
> > > i_reserved_data_blocks on successful block allocation
> > > git bisect good 95d49f79e94d4fa8105c880a266789609f3e791a
> > > # good: [f8b61a2c29fc70f64daad698cf09c1f79a0e39f9] drm/amd/display: Set 
> > > minimum
> > > requirement for using PSR-SU on Rembrandt
> > > git bisect good f8b61a2c29fc70f64daad698cf09c1f79a0e39f9
> > > # bad: [bd2decac7345134ea0bd3f4b978478ef53367cd8] mptcp: ensure subflow is
> > > unhashed before cleaning the backlog
> > > git bisect bad bd2decac7345134ea0bd3f4b978478ef53367cd8
> > > # bad: [fe3409cd013cfd10d3e6787b49f33a5dda39cffd] RDMA/irdma: Fix op_type
> > > reporting in CQEs
> > > git bisect bad fe3409cd013cfd10d3e6787b49f33a5dda39cffd
> > > # good: [85c38ac62c1372cc1ab05426315aad61025d33ef] atheros: fix return 
> > > value
> > > check in atl1_tso()
> > > git bisect good 85c38ac62c1372cc1ab05426315aad61025d33ef
> > > # bad: [539cf23cb48835c69cc3d22edff28b92bd82bb18] tipc: stop tipc crypto 
> > > on
> > > failure in tipc_node_create
> > > git bisect bad 539cf23cb48835c69cc3d22edff28b92bd82bb18
> > > # good: [1ecdbf2467ae4bc4df00c5cfab427cb1aaa5e3e1] x86/traps: Fix
> > > load_unaligned_zeropad() handling for shared TDX memory
> > > git bisect good 1ecdbf2467ae4bc4df00c5cfab427cb1aaa5e3e1
> > > # bad: [7218974aba07ff60c646d5a512b02b871402b03e] mm: suppress mm fault 
> > > logging
> > > if fatal signal already pending
> > > git bisect bad 7218974aba07ff60c646d5a512b02b871402b03e
> > > # good: [89a4d1a89751a0fbd520e64091873e19cc0979e8] netfilter: 
> > > nft_set_rbtree:
> > > fix overlap expiration walk
> > > git bisect good 89a4d1a89751a0fbd520e64091873e19cc0979e8
> > > # bad: [268cb07ef3ee17b5454a7c4b23376802c5b00c79] netfilter: nf_tables:
> > > disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID
> > > git bisect bad 268cb07ef3ee17b5454a7c4b23376802c5b00c79
> > > # good: [4237462a073e24f71c700f3e5929f07b6ee1bcaa] netfilter: nf_tables: 
> > > skip
> > > immediate deactivate in _PREPARE_ERROR
> > > git bisect good 4237462a073e24f71c700f3e5929f07b6ee1bcaa
> > > # first bad commit: [268cb07ef3ee17b5454a7c4b23376802c5b00c79] netfilter:
> > > nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID
> > > 
> > > $ git bisect visualize
> > > commit 268cb07ef3ee17b5454a7c4b23376802c5b00c79
> > > Author: Pablo Neira Ayuso 
> > > Date:   Sun Jul 23 16:41:48 2023 +0200
> > > 
> > > netfilter: nf_tables: disallow rule addition to bound chain via
> > > NFTA_RULE_CHAIN_ID
> > > 
> > > [ Upstream commit 0ebc1064e4874d5987722a2ddbc18f94aa53b211 ]
> > > 
> > > Bail out with EOPNOTSUPP when adding rule to bound chain via
> > > NFTA_RULE_CHAIN_ID. The following warning splat is shown when
> > > adding a rule to a deleted bound chain:
> > > 
> > >  WARNING: CPU: 2 PID: 13692 at net/netfilter/nf_tables_api.c:2013
> > >  nf_tables_chain_destroy+0x1f7/0x210 [nf_tables]
> > >  CPU: 2 PID: 13692 Comm: chain-bound-rul Not tainted 6.1.39 #1
> > >  RIP: 0010:nf_tables_chain_destroy+0x1f7/0x210 [nf_tables]
> > > 
> > > Fixes: d0e2c7de92c7 ("netfilter: nf_tables: add NFT_CHAIN_BINDING")
> > > Reported-by: Kevin Rich 
> > > Signed-off-by: Pablo Neira Ayuso 
> > > Signed-off-by: Florian Westphal 
> > > Signed-off-by: Sasha Levin 
> > 
> > Hehe, yes, I was just about to write you the same. My test build
> > with this one reverted lets me load the ruleset again.
> > 
> > Would you like to take this upstream? I was just about to file a
> > report in netfilter's bugzilla, but since you also worked on it as
> > well, I don't mean to interfere...
> > 
> > I'll try to further reduce my test ruleset to see what actually
> > triggers this.
> 
> I'm fine if you report it upstream, as you have the best position for
> making further tests further stripped down rulesets. But instread of
> bugzilla I think it's best to directly mail Pablo Neira Ayuso
> , the people in the Signed-off-by, additionally
> the stable list (sta...@vger.kernel.org) and the regressions
> mailinglist (regressi...@lists.linux.dev, cf.
> https://www.kernel.org/doc/html/latest/process/handling-regressions.html).

get_maintainers.pl additionally gives:

$ ./scripts/get_maintainer.pl 

Bug#1051592: linux: Regression - upgrade to 6.1.52-1 breaks nftables

[Salvatore Bonaccorso]

Hi Timo,

On Mon, Sep 11, 2023 at 10:31:56PM +0200, Timo Sigurdsson wrote:
> Hi Salvatore,
> 
> Salvatore Bonaccorso schrieb am 11.09.2023 22:20 (GMT +02:00):
> 
> > Bisected the issue:
> > 
> > $ git bisect log
> > git bisect start
> > # status: waiting for both good and bad commits
> > # good: [61fd484b2cf6bc8022e8e5ea6f693a9991740ac2] Linux 6.1.38
> > git bisect good 61fd484b2cf6bc8022e8e5ea6f693a9991740ac2
> > # status: waiting for bad commit, 1 good commit known
> > # bad: [1321ab403b38366a4cfb283145bb2c005becb1e5] Linux 6.1.45
> > git bisect bad 1321ab403b38366a4cfb283145bb2c005becb1e5
> > # good: [95d49f79e94d4fa8105c880a266789609f3e791a] ext4: only update
> > i_reserved_data_blocks on successful block allocation
> > git bisect good 95d49f79e94d4fa8105c880a266789609f3e791a
> > # good: [f8b61a2c29fc70f64daad698cf09c1f79a0e39f9] drm/amd/display: Set 
> > minimum
> > requirement for using PSR-SU on Rembrandt
> > git bisect good f8b61a2c29fc70f64daad698cf09c1f79a0e39f9
> > # bad: [bd2decac7345134ea0bd3f4b978478ef53367cd8] mptcp: ensure subflow is
> > unhashed before cleaning the backlog
> > git bisect bad bd2decac7345134ea0bd3f4b978478ef53367cd8
> > # bad: [fe3409cd013cfd10d3e6787b49f33a5dda39cffd] RDMA/irdma: Fix op_type
> > reporting in CQEs
> > git bisect bad fe3409cd013cfd10d3e6787b49f33a5dda39cffd
> > # good: [85c38ac62c1372cc1ab05426315aad61025d33ef] atheros: fix return value
> > check in atl1_tso()
> > git bisect good 85c38ac62c1372cc1ab05426315aad61025d33ef
> > # bad: [539cf23cb48835c69cc3d22edff28b92bd82bb18] tipc: stop tipc crypto on
> > failure in tipc_node_create
> > git bisect bad 539cf23cb48835c69cc3d22edff28b92bd82bb18
> > # good: [1ecdbf2467ae4bc4df00c5cfab427cb1aaa5e3e1] x86/traps: Fix
> > load_unaligned_zeropad() handling for shared TDX memory
> > git bisect good 1ecdbf2467ae4bc4df00c5cfab427cb1aaa5e3e1
> > # bad: [7218974aba07ff60c646d5a512b02b871402b03e] mm: suppress mm fault 
> > logging
> > if fatal signal already pending
> > git bisect bad 7218974aba07ff60c646d5a512b02b871402b03e
> > # good: [89a4d1a89751a0fbd520e64091873e19cc0979e8] netfilter: 
> > nft_set_rbtree:
> > fix overlap expiration walk
> > git bisect good 89a4d1a89751a0fbd520e64091873e19cc0979e8
> > # bad: [268cb07ef3ee17b5454a7c4b23376802c5b00c79] netfilter: nf_tables:
> > disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID
> > git bisect bad 268cb07ef3ee17b5454a7c4b23376802c5b00c79
> > # good: [4237462a073e24f71c700f3e5929f07b6ee1bcaa] netfilter: nf_tables: 
> > skip
> > immediate deactivate in _PREPARE_ERROR
> > git bisect good 4237462a073e24f71c700f3e5929f07b6ee1bcaa
> > # first bad commit: [268cb07ef3ee17b5454a7c4b23376802c5b00c79] netfilter:
> > nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID
> > 
> > $ git bisect visualize
> > commit 268cb07ef3ee17b5454a7c4b23376802c5b00c79
> > Author: Pablo Neira Ayuso 
> > Date:   Sun Jul 23 16:41:48 2023 +0200
> > 
> > netfilter: nf_tables: disallow rule addition to bound chain via
> > NFTA_RULE_CHAIN_ID
> > 
> > [ Upstream commit 0ebc1064e4874d5987722a2ddbc18f94aa53b211 ]
> > 
> > Bail out with EOPNOTSUPP when adding rule to bound chain via
> > NFTA_RULE_CHAIN_ID. The following warning splat is shown when
> > adding a rule to a deleted bound chain:
> > 
> >  WARNING: CPU: 2 PID: 13692 at net/netfilter/nf_tables_api.c:2013
> >  nf_tables_chain_destroy+0x1f7/0x210 [nf_tables]
> >  CPU: 2 PID: 13692 Comm: chain-bound-rul Not tainted 6.1.39 #1
> >  RIP: 0010:nf_tables_chain_destroy+0x1f7/0x210 [nf_tables]
> > 
> > Fixes: d0e2c7de92c7 ("netfilter: nf_tables: add NFT_CHAIN_BINDING")
> > Reported-by: Kevin Rich 
> > Signed-off-by: Pablo Neira Ayuso 
> > Signed-off-by: Florian Westphal 
> > Signed-off-by: Sasha Levin 
> 
> Hehe, yes, I was just about to write you the same. My test build
> with this one reverted lets me load the ruleset again.
> 
> Would you like to take this upstream? I was just about to file a
> report in netfilter's bugzilla, but since you also worked on it as
> well, I don't mean to interfere...
> 
> I'll try to further reduce my test ruleset to see what actually
> triggers this.

I'm fine if you report it upstream, as you have the best position for
making further tests further stripped down rulesets. But instread of
bugzilla I think it's best to directly mail Pablo Neira Ayuso
, the people in the Signed-off-by, additionally
the stable list (sta...@vger.kernel.org) and the regressions
mailinglist (regressi...@lists.linux.dev, cf.
https://www.kernel.org/doc/html/latest/process/handling-regressions.html).

It should be noted:

0ebc1064e487 ("netfilter: nf_tables: disallow rule addition to bound
chain via NFTA_RULE_CHAIN_ID") in 6.5-rc4 was backported to several
stable series, namely in 5.10.190, 5.15.124, 6.1.43, 6.4.8.

While I can reproduce the issue in 5.10.191-1 and 6.1.52-1, I cannot
in 6.4.13-1 or 6.5.2-1 (not yet released in Debian).

Possibly for the 

Bug#1026333: ITP: rustup -- the rust toolchain installer

[Matthias Geiger]

Control: retitle -1 RFP: rustup -- the rust toolchain installer

Control:  noowner -1

On Mon, 11 Sep 2023 12:39:14 -0600 shuyu liu  wrote:

> Hi all,
>
> First, thank you for considering packaging rustup!
>
> I wonder how this ITP is going. Are there any blockers? I could provide
> some help if you need testing.
>
> Thanks,

> Zixing

Hi Zixing,

unfortunately I am pretty busy with maintaining Debian (rust) packages.

I prepared async-compression, it needs sponsorship through NEW by a 
Debian Developer.


Then reqwest's compression feature needs to be re-enabled and the 
download crate need to be packaged (again, through NEW).


After that rustup can be uploaded. I set the bug report back to a RFP 
because I already maintain a lot and would rather have someone dedicated 
to rustup maintaining it.


Let me know if you are interested :)

best,

--
Matthias Geiger (werdahias)
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051630: transition: qtwebengine-abi-5-15-15

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2023-09-10 21:45:24 +0300, Dmitry Shachnev wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: qtwebengine-opensource-...@packages.debian.org
> Control: affects -1 + src:qtwebengine-opensource-src
> 
> Dear Release team,
> 
> Qt WebEngine has a new patch release in 5.15 LTS branch, and as usual
> we change the ABI virtual package name, which requires a binNMU of two
> reverse dependencies: angelfish and qtwebview-opensource-src.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1051735: RFP: pysolfc -- A large collection of solitaire card, MaJong, and other games written in Python

[Arthur Torrey]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: arthur_tor...@comcast.net

* Package name: pysolfc
  Version : PySolFC v2.21.0.
  Upstream Contact: Name  I don't know and can't find it
* URL : https://pysolfc.sourceforge.io
* License : GPLv3
  Programming Lang: Python
  Description : A large collection of solitaire card, MaJong, and other 
games written in Python

(copied from website)
PySol Fan Club Edition (PySolFC) is a collection of more than 1000 solitaire 
card games. It is a fork of PySol Solitaire.

There are games that use the 52 card International Pattern deck, games for the 
78 card Tarock deck, eight and ten suit Ganjifa games, Hanafuda games, Matrix 
games, Mahjongg games, and games for an original hexadecimal-based deck.

Its features include a modern look and feel (uses the TTk widget set), multiple 
card sets and tableau backgrounds, sound, unlimited undo, player statistics, a 
hint system, demo games, a solitaire wizard, support for user written plug-ins, 
an integrated HTML help browser, and lots of documentation.

This game (or Pysol, which it forks) was in Buster and earlier Debian versions, 
and appears to be in Sid, but is NOT in Trixie, or Bookworm.  There are some 
old bugs filed against it that I found, but I'm not sure if they were ever 
solved.  (I am not a dev!)  I have been addicted to playing FreeCell on many 
systems for years, and this version has IMHO the best interface I've ever 
encountered.  I have looked at the available packages that say they offer 
FreeCell, and IMHO they are horrible to play.  I have attempted to follow the 
instructions on making a local package and have gotten errors I don't 
understand.  I don't want to make a FrankenDeb, please make this game available

Bug#1051593: RM: ecere-sdk -- RoQA; unmaintained, FTBFS

[Sebastian Ramacher]

Control: reassign -1 wnpp
Control: retitle -1 RFH: ecere-sdk -- Ecere cross-platform SDK
Control: submitter -1 Jerome St-Louis 

On 2023-09-10 16:24:41 -0400, Jérôme St-Louis wrote:
> The fixes for FTBFS have been in upstream for a long time, but I have not
> found time to do a proper release or update the Debian package for a while.
> 
> Those FTBFS were a result of GCC changes that we fixed in upstream.
> 
> The 'latest' branch on our Git repo (
> https://github.com/ecere/ecere-sdk/commits/latest ) includes the fixes.
> 
> Could someone please help with the maintenance instead of removing it?

Then let's turn this into a request for help.

Cheers
-- 
Sebastian Ramacher

Bug#1051734: ITP: budgie-desktop-environment - budgie desktop customization for Debian

[David Mohammed]

Package: wnpp
Severity: wishlist

Owner: David Mohammed (fossfree...@ubuntu.com)

Package name : budgie-desktop-environment
Version : 0.1
Upstream Author : David Mohammed (fossfree...@ubuntu.com)
URL : https://github.com/ubuntubudgie/debian-bde
License : GPL 2+
Programming Lang: None
Description :
Budgie Desktop environment customization for Debian
Installs packages, both essential dependencies
as well as recommended packages to produce a useful and
integrated desktop.
The principles followed are to adhere to upstream budgie
recommendations coupled with ensuring a minimal but useful set
of Debian defaults.
Installs:
Debian Budgie panel configuration
gsettings overrides
applies the default Gtk+ theme & icon-theme for GTK+
applications

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Russ Allbery]

Bill Allombert  writes:

> But we do: we support debhelper 13.11.4 and debhelper 13.11.6.  Even if
> we support a single implementation, we still need to know what is
> expected of it.

Policy already requires a single implementation of quite a lot of tools,
does not specify a version, and does not specify how they do what they do.
Bugs are handled as bugs against the packages that supply those tools, and
what they do, except at a very high level, is opaque to Policy.  Examples
include update-rc.d, invoke-rc.d, adduser, and ldconfig, as well as the
obvious example of dpkg (which doesn't really count).

Now, I realize that debhelper feels conceptually different than those, and
I think to some extent it *is* conceptually different.  Those are all
tools that do a single thing, whereas debhelper is an infrastructure that
has a lot of implications for how the package is defined and assembled.
It is a big step to go from requiring that all packages use a specific
tool to requiring that packages of a specific type use a particular
packaging framework.  That's why I wanted to have a discussion about that
first.

The alternative is to adopt deb-systemd-invoke and deb-systemd-helper as
tools similar to update-rc.d and invoke-rc.d and specify how packages
should call them.  This is indeed what I had started doing.  But when I
started writing the language for this, it quickly became obvious that
those tools were written for debhelper and debhelper embeds a lot of
information about how to call them.  (deb-systemd-invoke, for an obvious
example, has a very minimal man page.)

The invocation added by dh_installsystemd is also not entirely trivial.
Here is an example from wpasupplicant, reformatted a bit to make it more
readable in a mail message (and also note that my system has several
versions of this, so it's clearly under active development):

# Automatically added by dh_installsystemd/13.11.6
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] \
   || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
  # The following line should be removed in trixie or trixie+1
  deb-systemd-helper unmask 'wpa_supplicant.service' >/dev/null || true

  # was-enabled defaults to true, so new installations run enable.
  if deb-systemd-helper --quiet was-enabled 'wpa_supplicant.service'; then
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable 'wpa_supplicant.service' >/dev/null || true
  else
# Update the statefile to add new symlinks (if any), which need to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state 'wpa_supplicant.service' >/dev/null || true
  fi
fi
# End automatically added section
# Automatically added by dh_installsystemd/13.11.6
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] \
   || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
  if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
if [ -n "$2" ]; then
  _dh_action=restart
else
  _dh_action=start
fi
deb-systemd-invoke $_dh_action 'wpa_supplicant.service' >/dev/null || true
  fi
fi
# End automatically added section

This is postinst, which is the most complex, but prerm and postrm snippets
are also required.

This felt like kind of a lot to put into Policy.  There is a line that
apparently won't be needed in the future, there's an update-state concept
that's internal to the tool, and the logic differs based on whether this
is a package upgrade or a new installation.  We can put this all into
Policy, but I would just be blindly copying and pasting code from
debhelper, and I'm very dubious that it is going to stay accurate and up
to date (as witnessed by the fact that the existing snippets in Policy for
using update-rc.d and invoke-rc.d do not match what debhelper does and are
likely broken for packages that also include systemd units or packages
that need to care about DPKG_ROOT).

Also, honestly, nearly all packagers think of debhelper as an opaque tool
that everyone uses, and I have a larger concern that this makes Policy
much less useful for a large part of its intended audience than it could
be.  Quite a lot of Policy is of the general format "here's a bunch of
complex things you need to do, wait, never mind, just use debhelper, go
see its documentation for the configuration files you should use instead"
and some of the rest of Policy is "here's a bunch of complex things you
need to do but if you follow these instructions instead of using debhelper
your package will be buggy."  This is not ideal!

I think there's a lot of appeal of having a thorough specification for
what debhelper is supposed to be doing.  It would enable future
competition around better packaging helpers (and I do think debhelper will
not be the last word).  But I also want to be realistic about whether
we're really capable of maintaining that 

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Sam Hartman]

> "Bill" == Bill Allombert  writes:
Bill> But we do: we support debhelper 13.11.4 and debhelper 13.11.6.
Bill> Even if we support a single implementation, we still need to
Bill> know what is expected of it.

At that level, I think the answer is roughly that if you call
dh_installsystemd, then any units in the package installation directory,
or any units matching certain file patterns in the debian directory will
be installed and if appropriate enabled.


I understand there's some work to do:

* do we support units in /lib/systemd/system, /usr/lib/systemd/system,
  or both.

* What are those filename patterns for finding service units under
  debian?

* You might implicitly call dh_installsystemd via dh

I think Russ might be arguing that we should actually push all that out
to the Debhelper documentation.  I'd support that, although I understand
that makes the debhelper 13.4 vs 13.6 issue more relevant.  I'd also
support describing a bit of the interface between debian/rules and
debhelper wrt systemd units if it allowed us to move forward.

My argument is that even if we support multiple versions of debhelper,
we do not need to define the interface between debhelper and systemd in
policy: we do not need to specify deb-systemd-helper and
deb-systemd-invoke.

--Sam

Bug#1051592: linux: Regression - upgrade to 6.1.52-1 breaks nftables

[Timo Sigurdsson]

Hi Salvatore,

Salvatore Bonaccorso schrieb am 11.09.2023 22:20 (GMT +02:00):

> Bisected the issue:
> 
> $ git bisect log
> git bisect start
> # status: waiting for both good and bad commits
> # good: [61fd484b2cf6bc8022e8e5ea6f693a9991740ac2] Linux 6.1.38
> git bisect good 61fd484b2cf6bc8022e8e5ea6f693a9991740ac2
> # status: waiting for bad commit, 1 good commit known
> # bad: [1321ab403b38366a4cfb283145bb2c005becb1e5] Linux 6.1.45
> git bisect bad 1321ab403b38366a4cfb283145bb2c005becb1e5
> # good: [95d49f79e94d4fa8105c880a266789609f3e791a] ext4: only update
> i_reserved_data_blocks on successful block allocation
> git bisect good 95d49f79e94d4fa8105c880a266789609f3e791a
> # good: [f8b61a2c29fc70f64daad698cf09c1f79a0e39f9] drm/amd/display: Set 
> minimum
> requirement for using PSR-SU on Rembrandt
> git bisect good f8b61a2c29fc70f64daad698cf09c1f79a0e39f9
> # bad: [bd2decac7345134ea0bd3f4b978478ef53367cd8] mptcp: ensure subflow is
> unhashed before cleaning the backlog
> git bisect bad bd2decac7345134ea0bd3f4b978478ef53367cd8
> # bad: [fe3409cd013cfd10d3e6787b49f33a5dda39cffd] RDMA/irdma: Fix op_type
> reporting in CQEs
> git bisect bad fe3409cd013cfd10d3e6787b49f33a5dda39cffd
> # good: [85c38ac62c1372cc1ab05426315aad61025d33ef] atheros: fix return value
> check in atl1_tso()
> git bisect good 85c38ac62c1372cc1ab05426315aad61025d33ef
> # bad: [539cf23cb48835c69cc3d22edff28b92bd82bb18] tipc: stop tipc crypto on
> failure in tipc_node_create
> git bisect bad 539cf23cb48835c69cc3d22edff28b92bd82bb18
> # good: [1ecdbf2467ae4bc4df00c5cfab427cb1aaa5e3e1] x86/traps: Fix
> load_unaligned_zeropad() handling for shared TDX memory
> git bisect good 1ecdbf2467ae4bc4df00c5cfab427cb1aaa5e3e1
> # bad: [7218974aba07ff60c646d5a512b02b871402b03e] mm: suppress mm fault 
> logging
> if fatal signal already pending
> git bisect bad 7218974aba07ff60c646d5a512b02b871402b03e
> # good: [89a4d1a89751a0fbd520e64091873e19cc0979e8] netfilter: nft_set_rbtree:
> fix overlap expiration walk
> git bisect good 89a4d1a89751a0fbd520e64091873e19cc0979e8
> # bad: [268cb07ef3ee17b5454a7c4b23376802c5b00c79] netfilter: nf_tables:
> disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID
> git bisect bad 268cb07ef3ee17b5454a7c4b23376802c5b00c79
> # good: [4237462a073e24f71c700f3e5929f07b6ee1bcaa] netfilter: nf_tables: skip
> immediate deactivate in _PREPARE_ERROR
> git bisect good 4237462a073e24f71c700f3e5929f07b6ee1bcaa
> # first bad commit: [268cb07ef3ee17b5454a7c4b23376802c5b00c79] netfilter:
> nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID
> 
> $ git bisect visualize
> commit 268cb07ef3ee17b5454a7c4b23376802c5b00c79
> Author: Pablo Neira Ayuso 
> Date:   Sun Jul 23 16:41:48 2023 +0200
> 
> netfilter: nf_tables: disallow rule addition to bound chain via
> NFTA_RULE_CHAIN_ID
> 
> [ Upstream commit 0ebc1064e4874d5987722a2ddbc18f94aa53b211 ]
> 
> Bail out with EOPNOTSUPP when adding rule to bound chain via
> NFTA_RULE_CHAIN_ID. The following warning splat is shown when
> adding a rule to a deleted bound chain:
> 
>  WARNING: CPU: 2 PID: 13692 at net/netfilter/nf_tables_api.c:2013
>  nf_tables_chain_destroy+0x1f7/0x210 [nf_tables]
>  CPU: 2 PID: 13692 Comm: chain-bound-rul Not tainted 6.1.39 #1
>  RIP: 0010:nf_tables_chain_destroy+0x1f7/0x210 [nf_tables]
> 
> Fixes: d0e2c7de92c7 ("netfilter: nf_tables: add NFT_CHAIN_BINDING")
> Reported-by: Kevin Rich 
> Signed-off-by: Pablo Neira Ayuso 
> Signed-off-by: Florian Westphal 
> Signed-off-by: Sasha Levin 

Hehe, yes, I was just about to write you the same. My test build with this one 
reverted lets me load the ruleset again.

Would you like to take this upstream? I was just about to file a report in 
netfilter's bugzilla, but since you also worked on it as well, I don't mean to 
interfere...

I'll try to further reduce my test ruleset to see what actually triggers this.

Thanks and regards,

Timo

Bug#1051150: RFS: blender-doc/3.6-1 [ITP] -- Blender Manual by the Blender Foundation

[Jonathan Rubenstein]

Hey, I am pinging this RFS as I am still interested in a sponsor.

I'm sure someone from debian-multimedia would be the most suitable for 
this purpose as they maintain the blender package, but their wiki page


https://wiki.debian.org/DebianMultimedia/Sponsoring

says

> In general, we don't do sponsoring.

So for the moment I am not bothering them, however, if I should then let 
me know!


Regards,
Jonathan Rubenstein

Bug#1051733: ITP: ayatana-indicator-a11y -- Ayatana Indicator for Accessibility Settings

[Mike Gabriel]

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

* Package name: ayatana-indicator-a11y
  Version : 0.0.1
  Upstream Contact: Robert Tari 
* URL : https://github.com/AyatanaIndicators/ayatana-indicator-a11y
* License : GPL-3
  Programming Lang: C
  Description : Ayatana Indicator for Accessibility Settings

 This Ayatana Indicator provides quick access to accessibility related
 assistance applications such as the screen reader or an on-screen
 keyboard.
 .
 The provided accessibility indicator should show as an icon in the top
 panel of indicator aware destkop environments. It can be used to toggle
 and access various accessibility features.
 .
 Ayatana Indicators are only available on desktop environments that
 provide a renderer for system indicators (such as MATE, Xfce, Lomiri,
 etc.).
 .
 This package will be maintained by the Ayatana Packagers Team in Debian.

Bug#1051592: linux: Regression - upgrade to 6.1.52-1 breaks nftables

[Salvatore Bonaccorso]

Hi,

On Mon, Sep 11, 2023 at 04:28:34PM +0200, Salvatore Bonaccorso wrote:
> Control: found -1 5.10.191-1
> 
> On Mon, Sep 11, 2023 at 04:17:46PM +0200, Salvatore Bonaccorso wrote:
> > Control: tags -1 + confirmed upstream
> > 
> > Hi,
> > 
> > On Mon, Sep 11, 2023 at 04:08:07PM +0200, Salvatore Bonaccorso wrote:
> > > Control: tags -1 - moreinfo unreproducible
> > > 
> > > Hi Timo,
> > > 
> > > On Mon, Sep 11, 2023 at 03:15:18AM +0200, Timo Sigurdsson wrote:
> > > > Hi,
> > > > 
> > > > Salvatore Bonaccorso schrieb am 10.09.2023 12:21 (GMT +02:00):
> > > > 
> > > > > Would it be possible to provide a minimal set of rules triggering the
> > > > > issue? Can you reproduce the issue with the official build?
> > > > 
> > > > So, I did some more testing on a different machine running the official 
> > > > build. My findings so far are:
> > > > 1) Yes, I can reproduce the issue with the official build.
> > > > 2) The issue depends on the ruleset. The minimal ruleset I have on that 
> > > > machine, doesn't trigger the issue, but when I copy over the ruleset 
> > > > from the machine I first observed this on, then I can reproduce it.
> > > > 
> > > > I'm attaching a somewhat stripped down version of my original, rather 
> > > > complex ruleset. It's by no means a "minimal" reproducer, cause I 
> > > > haven't had the time yet to further reduce it in order to see what 
> > > > actually triggers it. But you should be able to observe that this 
> > > > ruleset loads just fine on linux 6.1.38-4, but doesn't anymore on 
> > > > 6.1.52-1.
> > > 
> > > Thanks for providing it, this helps debugging the issue.
> > > 
> > > > I also started looking into what commit could have introduced this. My 
> > > > first guess "netfilter: nft_dynset: disallow object maps" 
> > > > (23185c6aed1f) is wrong. Even with this one reverted, the issue occurs. 
> > > > I'll try another build with "netfilter: nf_tables: disallow rule 
> > > > addition to bound chain via NFTA_RULE_CHAIN_ID" (0ebc1064e487) reverted 
> > > > tomorrow evening...
> > > 
> > > Thanks, as soon we have the introducing commit we can go to the next
> > > step and check upstream. I cannot trigger the problem with 6.4.13-1 or
> > > 6.5.2.
> > 
> > The issue seems to be present already in 6.1.49-rc1, which I had still
> > from local pareparations for the rebases. So the bisection needs to go
> > to the upstream versions between 6.1.38 and 6.1.49 at least.
> 
> Additionally the behaviour change is as well in 5.10.191-1 (and
> 5.10.193 upstream), whereeas not triggering in 5.10.179.
> 
> So to be on the safe side making the following statement: either this
> is a real regression affecting several stable series or there is an
> intentional upstream change uncovering an issue in ruleset. As the
> behaviour is not in 6.5.2 for now considering it the first case.

Bisected the issue:

$ git bisect log
git bisect start
# status: waiting for both good and bad commits
# good: [61fd484b2cf6bc8022e8e5ea6f693a9991740ac2] Linux 6.1.38
git bisect good 61fd484b2cf6bc8022e8e5ea6f693a9991740ac2
# status: waiting for bad commit, 1 good commit known
# bad: [1321ab403b38366a4cfb283145bb2c005becb1e5] Linux 6.1.45
git bisect bad 1321ab403b38366a4cfb283145bb2c005becb1e5
# good: [95d49f79e94d4fa8105c880a266789609f3e791a] ext4: only update 
i_reserved_data_blocks on successful block allocation
git bisect good 95d49f79e94d4fa8105c880a266789609f3e791a
# good: [f8b61a2c29fc70f64daad698cf09c1f79a0e39f9] drm/amd/display: Set minimum 
requirement for using PSR-SU on Rembrandt
git bisect good f8b61a2c29fc70f64daad698cf09c1f79a0e39f9
# bad: [bd2decac7345134ea0bd3f4b978478ef53367cd8] mptcp: ensure subflow is 
unhashed before cleaning the backlog
git bisect bad bd2decac7345134ea0bd3f4b978478ef53367cd8
# bad: [fe3409cd013cfd10d3e6787b49f33a5dda39cffd] RDMA/irdma: Fix op_type 
reporting in CQEs
git bisect bad fe3409cd013cfd10d3e6787b49f33a5dda39cffd
# good: [85c38ac62c1372cc1ab05426315aad61025d33ef] atheros: fix return value 
check in atl1_tso()
git bisect good 85c38ac62c1372cc1ab05426315aad61025d33ef
# bad: [539cf23cb48835c69cc3d22edff28b92bd82bb18] tipc: stop tipc crypto on 
failure in tipc_node_create
git bisect bad 539cf23cb48835c69cc3d22edff28b92bd82bb18
# good: [1ecdbf2467ae4bc4df00c5cfab427cb1aaa5e3e1] x86/traps: Fix 
load_unaligned_zeropad() handling for shared TDX memory
git bisect good 1ecdbf2467ae4bc4df00c5cfab427cb1aaa5e3e1
# bad: [7218974aba07ff60c646d5a512b02b871402b03e] mm: suppress mm fault logging 
if fatal signal already pending
git bisect bad 7218974aba07ff60c646d5a512b02b871402b03e
# good: [89a4d1a89751a0fbd520e64091873e19cc0979e8] netfilter: nft_set_rbtree: 
fix overlap expiration walk
git bisect good 89a4d1a89751a0fbd520e64091873e19cc0979e8
# bad: [268cb07ef3ee17b5454a7c4b23376802c5b00c79] netfilter: nf_tables: 
disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID
git bisect bad 268cb07ef3ee17b5454a7c4b23376802c5b00c79
# good: [4237462a073e24f71c700f3e5929f07b6ee1bcaa] 

Bug#1051732: apt: download content from unauthenticated repository if matching authenticated repository

[Vagrant Cascadian]

Package: apt
Version: 2.6.1
Severity: wishlist
X-Debbugs-Cc: vagr...@reproducible-builds.org

Thanks for maintaining apt! I use it all the time!

No idea how difficult this would be to implement, but...

It would be nice to be able to download content (e.g. .deb or .dsc)
normally downloadable via apt from an unauthenticated repository if the
checksums on the content match another repository that is authenticated.

Something like in sources.list:

  deb [UnsignedContent=true] https://unauthenticated-mirror.net/debian sid main
  deb https://deb.debian.org/debian sid main

And then something like:

  $ apt update
  
  Hit:1 https://unauthenticated-mirror.example.net/debian sid Release
  Note: Unsigned Content repository http://unauthenticated-mirror.example.net
  ...
  Hit:6 https://deb.debian.org/debian sid InRelease
  ...

  apt download bash

  Note: checksums for bash matched http://deb.debian.org/debian...
  Get:1 http://unauthenticated-mirror.example.net/debian sid/main amd64 bash 
amd64 5.2.15-2+b2 [1,491 kB]
  
This would make it much easier to host partial mirrors or snapshots
without needing to mess around with signing keys (both on the mirror
side, and on the client side), by relying on the checksum information
from a trusted signed repository.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Bill Allombert]

On Mon, Sep 11, 2023 at 09:21:56AM -0600, Sam Hartman wrote:
> > "Santiago" == Santiago Vila  writes:
> 
> Santiago> El 10/9/23 a las 4:09, Russ Allbery escribió:
> >> I therefore would like to propose a first: I think Policy should
> >> simply say that any package that provides a system service should
> >> use debhelper and rely on dh_installsystemd to put the
> >> appropriate commands in its maintainer scripts.  (We can then
> >> discuss whether we should do the same for init scripts and
> >> dh_installinit, although its stanzas are simpler.)
> 
> Santiago> Hello. I don't like this approach, and I believe we are
> Santiago> mixing two different things here. One of them is our
> Santiago> ability (or lack thereof) of policy to catch up with real
> Santiago> development done elsewhere. Another one is the fact that
> Santiago> policy does not mandate any given implementation.
> 
> The question in my mind is whether it is valuable to support multiple
> implementations, and I think the answer is no.

But we do: we support debhelper 13.11.4 and debhelper 13.11.6.
Even if we support a single implementation, we still need to know what is
expected of it.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1051537: reprepro: upgrade from 5.3.1 to 5.4.2 leaves the database in an inconsistent state

[Bastian Germann]

Hi Giorgio,

Thanks for all the information that you supplied. There was no attachment 
however.

Cheers,
Bastian

Bug#1051537: reprepro: upgrade from 5.3.1 to 5.4.2 leaves the database in an inconsistent state

[Giorgio Comitini]

Package: reprepro
Version: 5.4.2-1
Followup-For: Bug #1051537
Control: tags -1 patch

For some reason the patch was not attached. Here it is in text form:


*** 000-migrate-references.patch
--- a/database.c
+++ b/database.c
@@ -1949,6 +1949,8 @@
 
 retvalue database_openreferences(void) {
retvalue r;
+   uint32_t flags;
+   int dbret;
 
assert (rdb_references == NULL);
r = database_table("references.db", "references",
@@ -1959,6 +1961,17 @@
return r;
} else
rdb_references->verbose = false;
+   dbret = 
rdb_references->berkeleydb->get_flags(rdb_references->berkeleydb, );
+   if (dbret != 0) {
+   table_printerror(rdb_references, dbret, "get_flags");
+   return RET_DBERR(dbret);
+   }
+   if (ISSET(flags, DB_DUPSORT)) {
+   fprintf(stderr,
+"Error: database uses deprecated format.\n"
+"Please run translatelegacyreferences to update to the new format first.\n");
+   return RET_ERROR;
+   }
return RET_OK;
 }
 
@@ -2707,3 +2720,91 @@
database_free();
return r;
 }
+
+static retvalue table_copy_with_dup(struct table *oldtable, struct table 
*newtable) {
+   retvalue r;
+   struct cursor *cursor;
+   const char *filekey, *data;
+   size_t data_len;
+
+   r = table_newglobalcursor(oldtable, true, );
+   if (!RET_IS_OK(r))
+   return r;
+   while (cursor_nexttempdata(oldtable, cursor, ,
+   , _len)) {
+   r = table_addrecord(newtable, filekey,
+   data, data_len, false);
+   if (RET_WAS_ERROR(r))
+   return r;
+   }
+   return RET_OK;
+}
+
+retvalue database_translate_legacy_references(void) {
+   char *dbname, *tmpdbname;
+   struct table *oldtable, *newtable;
+   int ret;
+   retvalue r, r2;
+
+   dbname = dbfilename("references.db");
+   if (FAILEDTOALLOC(dbname))
+   return RET_ERROR_OOM;
+   tmpdbname = dbfilename("old.references.db");
+   if (FAILEDTOALLOC(tmpdbname)) {
+   free(dbname);
+   return RET_ERROR_OOM;
+   }
+   ret = rename(dbname, tmpdbname);
+   if (ret != 0) {
+   int e = errno;
+   fprintf(stderr, "Could not rename '%s' into '%s': %s(%d)\n",
+   dbname, tmpdbname, strerror(e), e);
+   free(dbname);
+   free(tmpdbname);
+   return RET_ERRNO(e);
+   }
+   newtable = NULL;
+   r = database_table("references.db", "references",
+   dbt_BTREEDUP, DB_CREATE, );
+   assert (r != RET_NOTHING);
+   oldtable = NULL;
+   if (RET_IS_OK(r)) {
+   r = database_table("old.references.db", "references",
+   dbt_BTREEDUP, DB_RDONLY, );
+   if (r == RET_NOTHING) {
+   fprintf(stderr, "Could not find old-style database!\n");
+   r = RET_ERROR;
+   }
+   }
+   if (RET_IS_OK(r)) {
+   r = table_copy_with_dup(oldtable, newtable);
+   r2 = table_close(oldtable);
+   RET_ENDUPDATE(r, r2);
+   if (r == RET_NOTHING) {
+   r = RET_OK;
+   }
+   }
+   r2 = table_close(newtable);
+   RET_ENDUPDATE(r, r2);
+   if (RET_IS_OK(r))
+   (void)unlink(tmpdbname);
+
+   if (RET_WAS_ERROR(r)) {
+   ret = rename(tmpdbname, dbname);
+   if (ret != 0) {
+   int e = errno;
+   fprintf(stderr,
+"Could not rename '%s' back into '%s': %s(%d)\n",
+   dbname, tmpdbname, strerror(e), e);
+   free(tmpdbname);
+   free(dbname);
+   return RET_ERRNO(e);
+   }
+   free(tmpdbname);
+   free(dbname);
+   return r;
+   }
+   free(tmpdbname);
+   free(dbname);
+   return RET_OK;
+}
\ No newline at end of file
--- a/main.c
+++ b/main.c
@@ -538,6 +538,9 @@
verbosedatabase || verbose > 10);
 }
 
+ACTION_T(n, n, translatelegacyreferences) {
+   return database_translate_legacy_references();
+}
 
 ACTION_F(n, n, n, n, addmd5sums) {
char buffer[2000], *c, *m;
@@ -4135,6 +4138,8 @@
0, 0, "translatefilelists"},
{"translatelegacychecksums",A_N(translatelegacychecksums),
0, 0, "translatelegacychecksums"},
+   {"translatelegacyreferences",   A__T(translatelegacyreferences),
+   0, 0, "translatelegacyreferences"},
{"_listconfidentifiers",A_C(listconfidentifiers),
0, -1, "_listconfidentifiers"},
{"_listdbidentifiers",  

Bug#1051730: RFS: viewnior/1.8-2 [QA] -- simple, fast and elegant image viewer

[Hugo Torres]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : viewnior
   Version  : 1.8-2
   Upstream contact : https://github.com/hellosiyan/Viewnior/issues
 * URL  : https://siyanpanayotov.com/project/viewnior/
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/debian/viewnior
   Section  : graphics

The source builds the following binary packages:

  viewnior - simple, fast and elegant image viewer

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/v/viewnior/viewnior_1.8-2.dsc

Changes since the last upload:

 viewnior (1.8-2) unstable; urgency=medium
 .
   * QA upload.
   * Using new DH level format. Consequently:
   - debian/compat: Removed.
   - debian/control: Changed from 'debhelper' to 'debhelper-compat' in
 Build-Depends field and bumped level to 13.
   * debian/changelog: Removed extra blank space.
   * debian/control:
   - Added 'Rules-Requires-Root: no' to source stanza.
   - Bumped Standards-Version to 4.6.2.
   * debian/copyright:
   - Added Upstream-Contact.
   - Organized licenses.
   - Updated Source URL.
   - Updated upstream email address.
   - Using a secure URI in Format field.
   * debian/upstream/metadata: Created.
   * debian/rules:
   - Added hardening.
   - Removed --parallel argument.

Regards,
--
  Hugo Torres de Lima

Bug#1050180: bookworm-pu: package freeradius/3.2.1+dfsg-4+deb12u1

[Bernhard Schmidt]

Hi,

Control: tag -1 confirmed

On Mon, Aug 21, 2023 at 04:16:12PM +0200, Bernhard Schmidt wrote:

[ Reason ]
I would like to fix a regression in the bookworm release of FreeRADIUS where
the TLS-Client-Cert-Common-Name attribute contains the wrong value, breaking
some use-cases (Bug#1043282)

It has been fixed in the new upstream version in sid, the two relevant commits
apply cleanly. The reporter has confirmed that this fixes his problem.


Please go ahead.


Thanks, the package has been uploaded and accepted.

Bernhard

Bug#1051537: reprepro: upgrade from 5.3.1 to 5.4.2 leaves the database in an inconsistent state

[Giorgio Comitini]

Package: reprepro
Version: 5.4.2-1
Followup-For: Bug #1051537
Control: tags -1 patch

I noticed that reprepro doesn't automatically migrate the database if
needed after version upgrades. Instead, it raises an error and asks
the user to call one of the translate* commands. Therefore I would
propose to add one more such commands to fix this bug. I'm not sure
that this should be done without an increase of the major version,
but this is for the upstream developer to decide.


In attachment you will find one implementation of this proposal. It
works as follows:

- When an attempt is made to open the references.db file, reprepro
  checks if the DUPSORT flag is set. If this is so, the database
  needs to be upgraded, so reprepro exits with an error asking the
  user to call the new 'translatelegacyreferences' command.

  Notes:
  The check is done by the database_openreferences function in
  database.c. The function tries to open references.db with the DUP
  flag and then reads the flags back. If DUPSORT is set, it means
  that references.db was initially created with that flag, so we need
  to recreate the file with DUP only to avoid the bug. Since reprepro
  does not migrate databases on its own, we ask the user to do so
  manually. Also, since not migrating the database risks leaving the
  latter in an inconsistent state, we don't allow the user to access
  references.db until they have migrated the database.

- The translatelegacyreferences command creates a new references.db
  file with the DUP flag in place of DUPSORT. It then copies the
  content of the old references.db file into the new one.

  Notes:
  translatelegacyreferences follows the logic of translatefilelists.
  It is implemented by defining a new function
  database_translate_legacy_references in database.c. The latter
  first moves references.db to old.references.db, then copies the
  content of the latter into the former, and finally it deletes
  old.references.db. While database.c already defines a table_copy
  function that copies between tables, that function discards
  duplicates (it calls table_adduniqsizedrecord), so we define a new
  table_copy_with_dup function that keeps them. table_copy_with_dup
  does so by calling table_addrecord instead of
  table_adduniqsizedrecord.

- Once references.db has been migrated, the first check passes and
  the user is allowed to keep working on the database.


Some final notes:

  - The patch does not currently upgrade the version file, but that's
trivially implemented.
  - I tried to document the new command in the man page.
  - The patch passes all tests except for test_database_upgrade in
multiversion.sh. This is to be expected: upgrades are no longer
automatic, but need to be manually performed using
translatelegacyreferences. Calling the latter before export in
test_database_upgrade makes the test pass.

Bug#1043571: Bug#1051721: simple-cdd: Missing package zstd for default image build on bookworm

[Vagrant Cascadian]

Control: merge 1043571 1051721

On 2023-09-11, Sietze van Buuren wrote:
> When building a default bookworm dist image using the command 
> `build-simple-cdd`
> on a bookworm system, simple-cdd is able to successfully build the
> image. However, when using this image to install a new system, the installer
> complains that it can't find the package `zstd` and refuses to continue.
>
> I built the image with simple-cdd in a docker environment
> (debian:bookworm-slim).
>
> Just adding the package `zstd` (and nothing else) results in a working
> installer.
>
> Might it be, that for bookworm the package `zstd` needs to be addeed to the
> downloads file of the default profile
> (i.e. 
> https://salsa.debian.org/debian/simple-cdd/-/blob/master/profiles/default.downloads)?

If that indeed fixes it, that sounds like a simple enough workaround
worth applying, thanks!

Will try and test this and get a fix uploaded. Will have to first upload
to unstable/sid, and then another upload to stable-proposed-updates to
get this fixed in bookworm.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1051729: pmix: CVE-2023-41915

[Salvatore Bonaccorso]

Source: pmix
Version: 5.0.0~rc1-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for pmix.

CVE-2023-41915[0]:
| OpenPMIx PMIx before 4.2.6 and 5.0.x before 5.0.1 allows attackers
| to obtain ownership of arbitrary files via a race condition during
| execution of library code with UID 0.

As mentioned in [2]:
| A filesystem race condition could permit a malicious user
| to obtain ownership of an arbitrary file on the filesystem
| when parts of the PMIx library are called by a process
| running as uid 0. This may happen under the default
| configuration of certain workload managers, including Slurm.

(fs.protected_symlinks not protecting in such a case)

Please downgrade the severity if you do not agree on the assessment,
but at a very start the unstable version should be fixed. We can have
a look what need to be done for bookworm and bullseye in next step.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-41915
https://www.cve.org/CVERecord?id=CVE-2023-41915
[1] 
https://github.com/openpmix/openpmix/commit/0bf9801a3017eb6ca411e158da39570ccb998c17
[2] https://github.com/openpmix/openpmix/releases/tag/v5.0.1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1051355: Processed: your mail

[Leandro Cunha]

On Mon, Sep 11, 2023 at 4:10 PM Andres Salomon  wrote:
>
>
>
> On Mon, Sep 11 2023 at 03:27:30 PM -03:00:00, Leandro Cunha 
>  wrote:
>
> On Mon, Sep 11, 2023 at 4:07 AM Andres Salomon  wrote:
>
> So apparently it's already fixed in sid and trixie: 
> https://tracker.debian.org/news/1454349/accepted-llvm-toolchain-16-11606-11-source-into-unstable/
>  Bug didn't get closed because of the missing "(closes: " in that changelog 
> entry. I'll push the clang-16 stuff to git so you can give it a test build on 
> ppc. On Mon, Sep 11 2023 at 12:37:39 AM -05:00:00, Timothy Pearson 
>  wrote: For 16 to work we'll need the Debian 
> clang team to include this patchset: https://reviews.llvm.org/D158066 Any 
> chance of that happening? - Original Message - From: "Andres Salomon" 
>  To: "Leandro Cunha" , 
> 1051...@bugs.debian.org Cc: "Timothy Pearson" 
>  Sent: Sunday, September 10, 2023 11:43:18 PM 
> Subject: Re: Bug#1051355: Processed: your mail Alright, I built 117 w/ 
> clang-16 on sid and it doesn't segfault. Same exact build but with clang-14 
> segfaults. Timothy, did you ever get the ppc64 issues with clang >= 15 
> squared away? It's looking like I'm going to need to upload a build with 
> clang-16. On Sun, Sep 10 2023 at 03:07:29 PM -03:00:00, Leandro Cunha 
>  wrote: Hi, Em dom., 10 de set. de 2023 15:01, 
> Andres Salomon mailto:dilin...@queued.net>> escreveu: 
> Unfortunately 117 *also* segfaults on sid. I'm tempted to try a newer clang, 
> but probably not 15 since debian's planning to remove it. 16, I guess? Arch 
> is already with Clang 16 and I tested Chromium 117 in a vm that I installed 
> here and it was working normally.
>
> So we already have this version on unstable? I saw it in experimental. 
> https://metadata.ftp-master.debian.org/changelogs//main/l/llvm-defaults/llvm-defaults_0.57~exp4_changelog
>
>
> That's just the defaults package, which we don't really care about. Because 
> we're dealing with different compilers across different distributions, we're 
> hardcoding the specific clang version for each distribution's build.

Ah yes, I see, there is a user on GitHub who compiles Chromium for
Ubuntu, Debian and Windows operating systems with Clang/LLVM. I also
tested the .deb package it offers in version 117 and it worked. But of
course I had to delete the package distributed by Debian. And I also
didn't find any segmentation fault bug reports in version 116 in my
search. In this sense, research was carried out on other distributions
and their bug tracker. But I noticed that this problem sometimes
occurs considering the links inserted here.

https://groups.google.com/a/chromium.org/g/chromium-bugs/search?q=segmentation%20fault
https://bugs.chromium.org/p/chromium/issues/detail?id=48168
https://bbs.archlinux.org/viewtopic.php?id=151904
https://bugs.chromium.org/p/chromium/issues/list?q=segmentation%20fault=2
https://groups.google.com/a/chromium.org/g/chromium-bugs/c/wolJA_Ma4ZE
https://github.com/RobRich999/Chromium_Clang

-- 
Cheers,
Leandro Cunha

Bug#567033: Decide if we should continue recommending /usr/games

[Alexandre Detiste]

Hi,

The bespoken machine of 2015 with 64GB of SSD has been repurposed
as a Buster (the "new" os at work) backporter box, but I'm still here.

I agree that the games in Debian - especially the free ones - don't
evolve that much,
don't grow so much, but on the "contrib engine + non-free assets" side
it goes in easily in the terabytes, all nicely and orderly managed with
gama-data-packager ...; so please keep the /usr/share/games dir;
so it can be split over a slow HDD or NFS.
(it's not really mandatory at boot even)

Next is /var/games , stuff managed by setgid/setuid binaries,
I would prefer to keep it as such.

Simon's argument about /usr/games are better than mine.

And yes, contents of this dir should generally be less trusted;
even proprietary .deb will install there.
( i.e. /usrgames/WorldOfGoo which works after deleting
is vendored libSDL, I guess a lot of others)

I would add about the usability of the shell when doing
autocomplete, I prefer to have /games separated,
it involves less mental context switch.

And things just work, and /usr/games is just an inode;
I don't see the advantage of getting rid of it.

FreeBSD is likely even more stuck in the past
with very few games to manage;
they can decide otherwise if it makes sense to them.

> libexec
(this scared me to propose that)


Greetings

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Luca Boccassi]

On Mon, 11 Sep 2023, 17:58 Russ Allbery,  wrote:

> Luca Boccassi  writes:
>
> > Two more things went missing: Simon's suggestion on the versioned
> > dependencies on the virtual packages,
>
> Ah, yes, I'm sorry, I talked myself out of that and then completely forgot
> the previous discussion so didn't say anything.
>
> My concern is that it felt like we were providing a detailed description
> of an entirely normal dependency management situation (you always have to
> depend on the version of a package you use that provides the interface
> you're using unless it's old enough that it doesn't matter), and I wasn't
> sure what was special about this one that warranted spelling that out
> other than the need to add the version constraint to both stanzas.  So I
> kept that part but omitted the rest.
>
> The phrasing Simon proposed I think would be appropriate if we thought
> most packages would need a version constraint, but I didn't think the
> functionality was changing that quickly.  Am I wrong about that?  It felt
> awkward to include the version constraints and then tell people to remove
> them if they're going to be able to remove them 95% of the time, but I
> don't know if that's the case.
>
> Maybe the right way to do this is just have two examples, one as the
> default and another if you're using tmpfiles.d functionality added in a
> specific version of systemd that's newer than the version shipped with the
> stable version of Debian prior to the one you're targeting.
>

Ok, I have no opinion either way and am fine with the solution you and
Simon agree on

> and the link from the tmpfiles section to the service directory section
> > (given it was moved).
>
> It's there (last sentence):
>
> +If the files or directories are only needed by a system service or
> +otherwise should only be created when that service is running, packages
> +should define those files and directories in the ``systemd`` unit for the
> +service (and, for alternative init systems, in the configuration for that
> +init system) instead of using the ``tmpfiles.d`` mechanism.  See
> +:ref:`s-services-dirs` for more details.
>
> You don't need to spell out the section title; Sphinx defaults to adding
> that for you based on the heading that you're linking to.  (I think we are
> excessively explicit in a bunch of places in Policy currently due to a
> conversion artifact from DebianDoc-XML.)
>

Got it, thanks

>

Bug#1051728: libgusb: Out of date debian/watch and new upstream release

[Jeremy Bícha]

Source: libgusb
Version: 0.4.5-1.1

The latest releases of libgusb are being published at
https://github.com/hughsie/libgusb/releases instead of at the
people.freedesktop.org site.

The latest release is 0.4.6

Thank you,
Jeremy Bícha

Bug#1051727: libgusb: Homepage no longer controlled by upstream

[Jeremy Bícha]

Source: libgusb
Version: 0.4.5-1.1

The homepage field in libgusb's debian/control needs to be removed or
perhaps updated to https://github.com/hughsie/libgusb since a domain
squatter has taken over the old site and their intentions may be
malicious.

Thank you,
Jeremy Bícha

Bug#1051726: viagee: CVE-2020-24904

[Moritz Mühlenhoff]

Source: viagee
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for gnome-gmail, but I'd
expect it also affects viagee?

CVE-2020-24904[0]:
| An issue was discovered in attach parameter in GNOME Gmail version
| 2.5.4, allows remote attackers to gain sensitive information via
| crafted "mailto" link.

https://github.com/davesteele/gnome-gmail/issues/84

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1051725: ansible: CVE-2023-4567

[Moritz Mühlenhoff]

Source: ansible
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for ansible.

CVE-2023-4567[0]: So far the only reference is
https://bugzilla.redhat.com/show_bug.cgi?id=2235369

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1051724: zbar: CVE-2023-40889 CVE-2023-40890

[Moritz Mühlenhoff]

Source: zbar
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for zbar.

CVE-2023-40889[0]:
| A heap-based buffer overflow exists in the qr_reader_match_centers
| function of ZBar 0.23.90. Specially crafted QR codes may lead to
| information disclosure and/or arbitrary code execution. To trigger
| this vulnerability, an attacker can digitally input the malicious QR
| code, or prepare it to be physically scanned by the vulnerable
| scanner.

https://hackmd.io/@cspl/B1ZkFZv23

CVE-2023-40890[1]:
| A stack-based buffer overflow vulnerability exists in the
| lookup_sequence function of ZBar 0.23.90. Specially crafted QR codes
| may lead to information disclosure and/or arbitrary code execution.
| To trigger this vulnerability, an attacker can digitally input the
| malicious QR code, or prepare it to be physically scanned by the
| vulnerable scanner.

https://hackmd.io/@cspl/H1PxPAUnn

It is unclear if these were reported upstream, could you please sync
up with them?


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1051355: Processed: your mail

[Andres Salomon]

On Mon, Sep 11 2023 at 03:27:30 PM -03:00:00, Leandro Cunha 
 wrote:
On Mon, Sep 11, 2023 at 4:07 AM Andres Salomon > wrote:


 So apparently it's already fixed in sid and trixie:

 



 Bug didn't get closed because of the missing "(closes: " in that 
changelog entry. I'll push the clang-16 stuff to git so you can give 
it a test build on ppc.


 On Mon, Sep 11 2023 at 12:37:39 AM -05:00:00, Timothy Pearson 
> wrote:


 For 16 to work we'll need the Debian clang team to include this 
patchset:  Any chance of that 
happening? - Original Message -


 From: "Andres Salomon" > To: "Leandro Cunha" 
mailto:leandrocunha...@gmail.com>>, 
1051...@bugs.debian.org  Cc: 
"Timothy Pearson" > Sent: Sunday, September 10, 
2023 11:43:18 PM Subject: Re: Bug#1051355: Processed: your mail


 Alright, I built 117 w/ clang-16 on sid and it doesn't segfault. 
Same exact build but with clang-14 segfaults. Timothy, did you ever 
get the ppc64 issues with clang >= 15 squared away? It's looking 
like I'm going to need to upload a build with clang-16. On Sun, Sep 
10 2023 at 03:07:29 PM -03:00:00, Leandro Cunha 
mailto:leandrocunha...@gmail.com>> wrote:


 Hi, Em dom., 10 de set. de 2023 15:01, Andres Salomon 
mailto:dilin...@queued.net> 
<>> escreveu:


 Unfortunately 117 *also* segfaults on sid. I'm tempted to try a 
newer clang, but probably not 15 since debian's planning to remove 
it. 16, I guess?


 Arch is already with Clang 16 and I tested Chromium 117 in a vm 
that I installed here and it was working normally.


So we already have this version on unstable? I saw it in experimental.




That's just the defaults package, which we don't really care about. 
Because we're dealing with different compilers across different 
distributions, we're hardcoding the specific clang version for each 
distribution's build.

Bug#1051677: emacs: Provides backport of 29.1

[Manphiz]

Sean Whitton  writes:

> Hello,
>
> On Mon 11 Sep 2023 at 02:10am -07, Xiyue Deng wrote:
>
>> Package: emacs
>> Version: 1:28.2+1-15
>> Severity: wishlist
>> X-Debbugs-Cc: none, Xiyue Deng 
>>
>> It would be great to have 29.1 backported to bookworm (or potentially
>> bullseye if it's not too much of a trouble :)
>>
>> I acknowledge that some of the addons in bookworm don't work with 29.1
>> yet, while use-package users may just upgrade to latest versions on
>> Elpa/Melpa so that they continues to work.  Meanwhile I will also help
>> with backporting the addons gradually.
>
> Backport requests are to be made to the backports mailing list, and not
> generally to the BTS, because typically backports are maintained by
> someone other than the sid packge maintainers.
>

Ah noted.  I guess they'll redirect me to the actual team/person
handling the requested packages.

> In this case however I was already in the middle of preparing a backport
> while I saw your report :)

Great!  Thanks!

-- 
Manphiz

Bug#1051523: Doxygen changes breaks krb5 documentation build

[Sam Hartman]

> "Tianyu" == Tianyu Chen  writes:


Tianyu> During a local rebuild of krb5, your package failed to
Tianyu> build.

So, I'm guessing this is related to the upgrade in Debian from doxygen
1.9.4 to 1.9.8.

The krb5 build process uses doxygen to generate an xml representation of
the documentation from a bunch of C header files.  Then it uses a pile
of python scripts which haven't seen much love since the days of python2
to turn that documentation into rst, and then includes it in a sphinx
document.

It expects all the doxygen to be in a file called krb5_8hin.xml.
Unfortunately the new doxygen is breaking up the sources into a bunch of
different files and including  elements to refer to them rather
than  elements including their definition.  And so the python
doesn't find the definitions of the documented functions and the build
fails because not many rst files are generated.

I am hoping for help at this point.
I'll continue to look into it, but I'm not familiar with the innards of
doxygen, nor the xml parser that the krb5 python is using.


signature.asc
Description: PGP signature

Bug#567033: Decide if we should continue recommending /usr/games

[Russ Allbery]

Antoine Beaupré  writes:
> On 2023-09-11 11:25:34, Russ Allbery wrote:
>> Antoine Beaupré  writes:

>>> I get the argument against bad binaries not being in PATH but we have
>>> some tooling for that, don't we? /usr/libexec, no?

>> /usr/libexec isn't a replacement because it's not on any user's PATH.
>> /usr/games is intended to be added to a regular user's path but not
>> root's, which is a distinct use case.

> That's an odd argument to make: /usr/games isn't on any user's PATH
> either, is it?

It's common to add it, and I'm fairly sure we have documentation that
tells you to add it, whereas adding /usr/libexec to your PATH is a bug and
something that you should not do.  The binaries in /usr/libexec are not
intended to be invoked directly, may conflict with other binaries, may do
bizarre things when run from the command line, etc.

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

Bug#1051714: linux-image-amd64 6.1.38-1 dvb card stop working, failing symbol_get of non-GPLONLY symbol

[Salvatore Bonaccorso]

Control: reassign -1 src:linux
Control: forcemerge 1051613 -1

Hi,

On Mon, Sep 11, 2023 at 04:54:48PM +, groemich wrote:
> Package: linux-image-amd64
> Version: 6.1.38-1
> 
> Since 6.1.38-1 my dvb card stop working.
> 
> kernel: dvbdev: DVB: registering new adapter (SMI_DVB)
> kernel: failing symbol_get of non-GPLONLY symbol m88ds3103_attach.
> kernel: DVB: Unable to find symbol m88ds3103_attach()

Are you sure you mean 6.1.38-1? I believe this is a regression in the
6.1.52-1 upload, and the same root cause as #1051613. It is a known
upstream regression, cf.
https://lore.kernel.org/stable/2023090841-antitrust-reword-d6bc@gregkh/
and should be be going to be fixed in the next upload.

Regards,
Salvatore

Bug#567033: Decide if we should continue recommending /usr/games

[Bill Allombert]

On Mon, Sep 11, 2023 at 02:38:14PM -0400, Antoine Beaupré wrote:
> On 2023-09-11 11:25:34, Russ Allbery wrote:
> > Antoine Beaupré  writes:
> >
> >> I get the argument against bad binaries not being in PATH but we have
> >> some tooling for that, don't we? /usr/libexec, no?
> >
> > /usr/libexec isn't a replacement because it's not on any user's PATH.
> > /usr/games is intended to be added to a regular user's path but not
> > root's, which is a distinct use case.
> 
> That's an odd argument to make: /usr/games isn't on any user's PATH
> either, is it?

% grep games /etc/profile /etc/login.defs
/etc/profile:  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
/etc/login.defs:ENV_PATH
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1051600: emacs: shouldn't native-compilation use the cached eln-files?

[Jörg-Volker Peetz]

Sean Whitton wrote on 11/09/2023 18:59:

control: severity -1 normal
control: tag -1 + moreinfo

Hello,

On Sun 10 Sep 2023 at 01:15pm +02, Jörg-Volker Peetz wrote:


on my system each newly started emacs process does native-compilation of
all used modules, even the ones already compiled by previous processes.
Is this to be expected?
As I see it, the cached native-compiled modules should be re-used.
Do I have to configure something for that?


It's not expected.  But we will need more precise steps to reproduce to
do anything about it.


Hello,
thanks for looking into this.
From a terminal (rxvt-unicode) running my shell (mksh) I start emacs
(emacs-lucid). After about 15 seconds the following warnings appear:

 ■  Warning (comp): debian-el.el:90:26: Warning: reference to free variable ‘di\
red-mode-map’
 ■  Warning (comp): debian-el.el:90:26: Warning: reference to free variable ‘di\
red-mode-map’
 ■  Warning (comp): debian-el.el:95:35: Warning: docstring has wrong usage of u\
nescaped single quotes (use \= or different quoting)
 ■  Warning (comp): mmm-vars.el:869:2: Warning: defvar `mmm-classes-alist' docs\
tring has wrong usage of unescaped single quotes (use \= or different quoting)
 ■  Warning (comp): mmm-auto.el:168:2: Warning: docstring has wrong usage of un\
escaped single quotes (use \= or different quoting)

I stop emacs (C-x C-c) and start the next emacs. And again, after about the same
time the same warnings appear.
As I understand it, the second emacs is re-compiling the modules mentioned in
the warnings (and others, as can be seen in the eln-cache directory).

This happens also when calling `emacs -nw`.

init.el is appended.

Best regards,
Jörg.
;;; Init File for GNU Emacs
;;; Sep 2023

;;; Set eln-cache dir
(when (boundp 'native-comp-eln-load-path)
  (setcar native-comp-eln-load-path
  (expand-file-name "~/.cache/emacs-eln-cache/" user-emacs-directory)))

;;; Don't show emacs startup screen
(setq inhibit-startup-screen t)

;;; Change mail directory path
(setq message-directory (concat user-emacs-directory "mail/"))

;;; Turn off tool bar
(if (> emacs-major-version 20) (tool-bar-mode 0))

;;; Scroll bar on the right side of frames
(cond (window-system (set-scroll-bar-mode 'right)))

;;; Scroll bar colors (see M-x list-colors-display)
(set-face-attribute 'scroll-bar nil :foreground '"navy" :background '"ivory2")

;;; Let `display-buffer' make a separate frame
(setq pop-up-frames "graphic-only")

;;; Display date and time in the mode line
(setq display-time-string-forms
  '(monthname " " day " " 24-hours ":" minutes ))
(setq display-time-interval '3)
(display-time)

;;; As default make indentation from spaces only
(setq-default indent-tabs-mode nil)

;;; Turn on "parenthesis matching" mode
(show-paren-mode t)

;;; Make certain buffers appear in special frames
(setq special-display-regexps
  '("\\*compilation\\*" "\\*[mM]an.*\\*"))
(setq special-display-frame-alist
  '((height . 40) (width . 80) (unsplittable . f)))

;;; Set Fortran line number indent to zero
(add-hook 'fortran-mode-hook
  '(lambda () (setq fortran-line-number-indent 0)))

Bug#1026333: ITP: rustup -- the rust toolchain installer

[shuyu liu]

Hi all,

First, thank you for considering packaging rustup!

I wonder how this ITP is going. Are there any blockers? I could provide
some help if you need testing.

Thanks,
Zixing

Bug#567033: Decide if we should continue recommending /usr/games

[Antoine Beaupré]

On 2023-09-11 11:25:34, Russ Allbery wrote:
> Antoine Beaupré  writes:
>
>> I get the argument against bad binaries not being in PATH but we have
>> some tooling for that, don't we? /usr/libexec, no?
>
> /usr/libexec isn't a replacement because it's not on any user's PATH.
> /usr/games is intended to be added to a regular user's path but not
> root's, which is a distinct use case.

That's an odd argument to make: /usr/games isn't on any user's PATH
either, is it?

-- 
Science knows still practically nothing about the real nature of
matter, energy, dimension, or time; and even less about those
remarkable things called life and thought. But whatever the meaning
and purpose of this universe, you are a legitimate part of it.
- Gene Roddenberry

Bug#567033: Decide if we should continue recommending /usr/games

[Antoine Beaupré]

On 2023-09-11 19:57:16, Bill Allombert wrote:

[...]

> On the other hand, /usr/games allows:
> - priviledged accounts to omit /usr/games in their path (root does not have 
> it e.g)

I said it elsewhere but I'll repeat it here, if we want a separation
there, we already have another mechanism for that, and it's "private
binaries" in (say) /usr/libexec/

> - quickly find which games are installed on a system (ls /usr/games).

That's neat, but I doubt most users look for installed software with
`ls`. They are way more likely to use a GUI and there we have much
better mechanisms to sort things into buckets, other than "games" and
"not games".

In fact, I will argue that this makes games *harder* to find. If, for
some bizarre reason, a normal user ends up on the commandline to start a
game, they will type "gamename" (e.g. "freeorion") and will get an
unhelpful "command not found", because /usr/games typically won't be in
their PATH.

So this makes games easier to find for an extremely narrow class of
users who browse their filesystems looking for programs, I am not sure
it's worth it.

> - have a separate partitions for game data (which are amongst the largest 
> Debian package)

That, as far as I know, is not something /usr/games does at
all. e.g. here freeorion-data is all in /usr/share, not in /usr/games.

> - have a specific policy for /var/games

that also doesn't seem directly related to /usr/games, ie. you could
keep /var/games and not have /usr/games.

a.

-- 
La politique est l'art d'empêcher les gens de se mêler de ce qui les
regarde
- Paul Valéry

Bug#1051355: Processed: your mail

[Leandro Cunha]

On Mon, Sep 11, 2023 at 4:07 AM Andres Salomon  wrote:
>
> So apparently it's already fixed in sid and trixie:
>
> https://tracker.debian.org/news/1454349/accepted-llvm-toolchain-16-11606-11-source-into-unstable/
>
> Bug didn't get closed because of the missing "(closes: " in that changelog 
> entry. I'll push the clang-16 stuff to git so you can give it a test build on 
> ppc.
>
> On Mon, Sep 11 2023 at 12:37:39 AM -05:00:00, Timothy Pearson 
>  wrote:
>
> For 16 to work we'll need the Debian clang team to include this patchset: 
> https://reviews.llvm.org/D158066 Any chance of that happening? - Original 
> Message -
>
> From: "Andres Salomon"  To: "Leandro Cunha" 
> , 1051...@bugs.debian.org Cc: "Timothy Pearson" 
>  Sent: Sunday, September 10, 2023 11:43:18 PM 
> Subject: Re: Bug#1051355: Processed: your mail
>
> Alright, I built 117 w/ clang-16 on sid and it doesn't segfault. Same exact 
> build but with clang-14 segfaults. Timothy, did you ever get the ppc64 issues 
> with clang >= 15 squared away? It's looking like I'm going to need to upload 
> a build with clang-16. On Sun, Sep 10 2023 at 03:07:29 PM -03:00:00, Leandro 
> Cunha  wrote:
>
> Hi, Em dom., 10 de set. de 2023 15:01, Andres Salomon  > escreveu:
>
> Unfortunately 117 *also* segfaults on sid. I'm tempted to try a newer clang, 
> but probably not 15 since debian's planning to remove it. 16, I guess?
>
> Arch is already with Clang 16 and I tested Chromium 117 in a vm that I 
> installed here and it was working normally.

So we already have this version on unstable? I saw it in experimental.
https://metadata.ftp-master.debian.org/changelogs//main/l/llvm-defaults/llvm-defaults_0.57~exp4_changelog

-- 
Cheers,
Leandro Cunha

Bug#567033: Decide if we should continue recommending /usr/games

[Russ Allbery]

Antoine Beaupré  writes:

> I get the argument against bad binaries not being in PATH but we have
> some tooling for that, don't we? /usr/libexec, no?

/usr/libexec isn't a replacement because it's not on any user's PATH.
/usr/games is intended to be added to a regular user's path but not
root's, which is a distinct use case.

Thanks, Simon and Bill.  I had forgotten about that point even though it
has come up before (just not in this bug).  I agree that's a more
compelling argument for keeping /usr/games.

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

Bug#1051722: libnvme fails to build from source on unstable

[Mateus Rodrigues de Morais]

Source: libnvme
Version: 1.3-1
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: mateus.mor...@canonical.com

Hi,

Building libnvme from source currently fails during
execute_after_dh_auto_install when moving python-related files from
debian/tmp/usr/local/lib/python.

It seems these files are already at the correct location, at debian/tmp/usr/lib,
so removing the python correction lines from d/rules fixes the issue.

I'm building using sbuild on an sid schroot. The command I run is:
$ sbuild -d unstable --purge-build=successful 
--debbuildopts='--buildinfo-option=-O' --no-run-lintian

Ultimately, the build fails with:
make[1]: Entering directory '/<>'
# correcting python location
mv debian/tmp/usr/local/lib/python* debian/tmp/usr/lib
mv: cannot stat 'debian/tmp/usr/local/lib/python*': No such file or directory
make[1]: *** [debian/rules:13: execute_after_dh_auto_install] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


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

Kernel: Linux 6.2.0-32-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
>From 7fd68f186f60a0288b088dc2754aafd8451bbc5d Mon Sep 17 00:00:00 2001
From: Mateus Rodrigues de Morais 
Date: Wed, 6 Sep 2023 10:39:11 -0300
Subject: [PATCH] Removed Python location correction

---
 debian/rules | 4 
 1 file changed, 4 deletions(-)

diff --git a/debian/rules b/debian/rules
index 6673d04..4cb8910 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,10 +9,6 @@ override_dh_auto_configure:
dh_auto_configure -- -Ddocs=man -Ddocs-build=true -Dpython=enabled 
-Dopenssl=enabled --default-library=both
 
 execute_after_dh_auto_install:
-   # correcting python location
-   mv debian/tmp/usr/local/lib/python* debian/tmp/usr/lib
-   rm -rf debian/tmp/usr/local
-
# remove empty manpages
find debian/tmp/usr/share/man -type f -empty -exec rm -f {} +
 
-- 
2.39.2

Bug#567033: Decide if we should continue recommending /usr/games

[Antoine Beaupré]

On 2023-09-11 19:11:30, Simon McVittie wrote:

[...]

> Disclosure: I am a co-maintainer with Alexandre of the game-data-packager
> package, which installs proprietary game data into /usr/share/games, some
> of it much larger than the vast majority of games we package in Debian; and
> I think converting game-data-packager and its various supported game engines
> for a transition from /usr/share/foo to /usr/share/games/foo would be quite
> annoying to achieve, without providing any significant benefit.

See oddly, I have no objection against /usr/share/games, because it's
kind of (more?) explicit it's game data and not executables.

I get the argument against bad binaries not being in PATH but we have
some tooling for that, don't we? /usr/libexec, no?

a.

-- 
Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est
pas réfutable relève de la magie ou de la mystique.
- Karl Popper

Bug#567033: Decide if we should continue recommending /usr/games

[Simon McVittie]

On Mon, 11 Sep 2023 at 10:19:13 -0700, Russ Allbery wrote:
> I am inclined to agree [with no longer recommending /usr/games];
> it's just one more thing for people to think about
> while packaging things, and I don't think it serves much of a useful
> purpose.  However, the bug log has a couple of concrete objections.

I have another possible reason to separate /usr/games, which I think is
potentially more compelling than either of the ones in the bug (I'm sorry,
I thought it was already common knowledge):

Games are often written for performance more than correctness, and
frequently do non-ideal things or have unfixed security issues. If we
separate them into /usr/games and avoid putting that directory in root's
PATH, then tab completion mistakes can't result in root accidentally
running a game.

Similarly, I think (although I have no evidence) it's more common to
install non-free games, and non-free game managers like Steam, than
non-free utility/application software. If we put those in /usr/games, the
root can't accidentally run those as a result of a tab-completion mistake.

Entertainment programs that are not strictly games (the ones we might
classify as "toys") have similar considerations.

Is this enough to justify the existence of /usr/games? I don't know; but
I think it's more likely to be enough to justify /usr/games than the other
reasons previously cited here?

In recent versions of Debian's Steam packaging (formerly the steam
package, now the steam-installer package) I've put a safety-catch on it:
if some important files in ~/.steam/root don't exist (indicating a new
installation), the wrapper script doesn't actually install or run any
proprietary code until the user has confirmed in a GUI dialog that they
actually wanted to install it. Similarly, the binary-only games that
game-data-packager can install have a wrapper script with a confirmation
dialog before the first run, similar to a clickthrough license, to avoid
accidents. That mitigates these being in privileged users' PATHs.

Valve's official Steam packaging in their third-party apt repository
(the steam-launcher package, currently maintained by me with a different
hat on) installs to /usr/bin and has no such safety-catch, but it does
require adding an apt source that will result in running Valve-supplied
maintainer scripts as root, so if you add that apt source you're already
completely trusting Valve anyway.

> Axel Beckert objected because games may conflict with other tools
> installed in /usr/bin.  I feel like this is already a bug and merging the
> two namespaces to force us to deal with that bug may be a feature in
> disguise, because having two binaries with entirely different purposes on
> the user's PATH is a recipe for confusion and problems.

I agree. I think it's silly that a PATH search for pacman can result in
running either a 2D maze game or Arch Linux's package manager, especially
if the two packages are co-installable!

I know we have a Policy requirement that packages do not contain both
/bin/foo and /usr/bin/foo, to ensure that merged-/usr is possible.

I thought we also had a requirement for names of executables in the
PATH to be unique between /{usr/,}bin and /{usr/,}sbin, but I can't find
it now. I know some packages like iproute2 install both /{usr/,}sbin/ip
and /{usr/,}bin/ip, which I think is OK if they are functionally equivalent,
but would be a bug if they were functionally different.

> This is similar the old multiuser timeshare use case for separating games
> back when they competed for resources with other uses of the system and
> administrators wanted to be able to stop people from running them until
> after hours.  I feel like this use case is exceptionally rare at this
> point, and I'm not sure it's worth the packaging thought to maintain a
> separation just for that.

Unlike Axel's namespace-splitting use-case, I think this is a positive
thing, but I'm unsure whether its small benefit is really worth its cost.

> Alexandre also requested keeping games data separate so that it could be
> moved out of the /usr partition because it could be quite large.

Again, I think this is a positive, but I'm unsure whether its benefit is
worth its cost. Perhaps it would be proportionate to say that games MAY
install into /usr/share/games, and leave it up to maintainers whether they
do so, with the suggestion that small games shouldn't bother but
maintainers of large games might want to consider it?

Disclosure: I am a co-maintainer with Alexandre of the game-data-packager
package, which installs proprietary game data into /usr/share/games, some
of it much larger than the vast majority of games we package in Debian; and
I think converting game-data-packager and its various supported game engines
for a transition from /usr/share/foo to /usr/share/games/foo would be quite
annoying to achieve, without providing any significant benefit.

smcv

Bug#1051721: simple-cdd: Missing package zstd for default image build on bookworm

[Sietze van Buuren]

Package: simple-cdd
Version: 0.6.9
Severity: normal
X-Debbugs-Cc: s.van.buu...@gmail.com

Dear Maintainer,

When building a default bookworm dist image using the command `build-simple-cdd`
on a bookworm system, simple-cdd is able to successfully build the
image. However, when using this image to install a new system, the installer
complains that it can't find the package `zstd` and refuses to continue.

I built the image with simple-cdd in a docker environment
(debian:bookworm-slim).

Just adding the package `zstd` (and nothing else) results in a working
installer.

Might it be, that for bookworm the package `zstd` needs to be addeed to the
downloads file of the default profile
(i.e. 
https://salsa.debian.org/debian/simple-cdd/-/blob/master/profiles/default.downloads)?

Thanks for looking into this issue.

Regards,

Sietze


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

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

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


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

Kernel: Linux 5.10.0-25-amd64 (SMP w/4 CPU threads)
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 simple-cdd depends on:
ii  dctrl-tools 2.24-3+b1
ii  debian-cd   3.1.35
ii  lsb-release 11.1.0
ii  python3 3.9.2-3
ii  python3-simple-cdd  0.6.9
ii  reprepro5.3.0-1.2
ii  rsync   3.2.3-4+deb11u1
ii  wget1.21-1+deb11u1

Versions of packages simple-cdd recommends:
ii  dose-distcheck  6.0.1-2

Versions of packages simple-cdd suggests:
ii  qemu-system-x86 [qemu-kvm]  1:5.2+dfsg-11+deb11u2

-- no debconf information

Bug#1051720: apt: [INTL:nl] Dutch translation for the apt package

[Frans Spiesschaert]

 
 
Package: apt 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the apt package. 
A draft has been posted to the debian-l10n-dutch mailing list allowing for
review. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#934463: initscripts: consider taking over hwclock policy machinery

[Mark Hindley]

Andreas,

Thanks for your thoughts on this.

On Thu, Aug 24, 2023 at 06:16:08PM +0200, Andreas Henriksson wrote:
> Since initscripts will need (and has) Breaks/Replaces: util-linux-extra
> the circular nature of util-linux-extra having the same makes me think
> this is something which might be useful to think about a second time.
> Additionally, util-linux-extra might not even be installed on users
> system now that it's no longer pseudo-essential If we want to
> prevent (sysvinit) users from partially upgrading util-linux-extra
> and lack the hwclock machinery, then we likely also want to prevent
> them from deinstalling util-linux-extra which would have the same
> result.

I don't think the hwclock machinery is universally required on non-systemd init
systems: all of my systems are non-systemd and none have util-linux-extra
installed but run one of the time-daemon providers.

Bin:initscripts is installed on all non-systemd systems by being a dependency of
sysvinit-core and runit-init and itself depending on sysv-rc | openrc.

I see 2 scenarios we need to enforce with the dependencies:-

 1) Avoid dpkg attempting installation of packages with conflicting files

 2) Ensure users who might use the hwclock machinery (i.e. currently have
 util-linux-extra installed) continue to have it available

I think 1) is covered by the Breaks/Replaces. 2) is addressed by apt's
preference to upgrade rather than remove packages.

Despite the circular nature of both util-linux-extra and initscripts having
reciprocal breaks that you identify, it is the recommendation in the Package
Transition Wiki[1]. I think we are dealing with scenario #9.

With best wishes.

Mark

[1]  https://wiki.debian.org/PackageTransition

Bug#567033: Decide if we should continue recommending /usr/games

[Bill Allombert]

On Mon, Sep 11, 2023 at 12:51:33PM -0400, Antoine Beaupré wrote:
> On 2018-06-14 11:42:22, Simon McVittie wrote:
> > Debian can choose to put games in the /.../games directories, or in the
> > standard directories /usr/bin, /usr/share etc., or any mixture of our
> > choice, orthogonal to whether/when we move to FHS 3.0.
> 
> It's been a while since this was discussed, but I have just learned of
> this issue, so sorry for bumping an old thread but...
> 
> I have recently learned that FreeBSD moved their games out of /usr/games
> and into /usr/bin. Things like rot13(6), fortune(6), primes(6) are all
> in the main PATH now, amazing no? :)
> 
> That happened in 2015:
> 
> https://cgit.freebsd.org/src/commit/ObsoleteFiles.inc?id=11d9aa670723f508821f2bf6980a555360783a80
> 
> I wonder if we should just do the same. I'm not sure I see the point of
> having all that stuff in a separate directory, personnally, but at least
> in this case we shouldn't needlessly diverge from upstream... although
> in terms of upstream for bsd-games, things are kind of hazy, at best,
> from what I understand.

I do not see any advantage over /usr/games.

On the other hand, /usr/games allows:
- priviledged accounts to omit /usr/games in their path (root does not have it 
e.g)
- quickly find which games are installed on a system (ls /usr/games).
- have a separate partitions for game data (which are amongst the largest 
Debian package)
- have a specific policy for /var/games

Cheers,
Bill

Bug#1051719: markdown-mode.el produces excessive warnings

[Daniel Kahn Gillmor]

Package: elpa-markdown-mode
Version: 2.5-1

I get a lot of warnings from markdown-mode when i launch emacs.  the
buffer contains the following:

⛔ Warning (comp): markdown-mode.el:189:2: Warning: custom-declare-variable 
`markdown-indent-on-enter' docstring has wrong usage of unescaped single quotes 
(use \= or different quoting)
⛔ Warning (comp): markdown-mode.el:491:2: Warning: custom-declare-variable 
`markdown-split-window-direction' docstring has wrong usage of unescaped single 
quotes (use \= or different quoting)
⛔ Warning (comp): markdown-mode.el:517:2: Warning: custom-declare-variable 
`markdown-live-preview-delete-export' docstring has wrong usage of unescaped 
single quotes (use \= or different quoting)
⛔ Warning (comp): markdown-mode.el:855:2: Warning: defconst 
`markdown-regex-wiki-link' docstring has wrong usage of unescaped single quotes 
(use \= or different quoting)
⛔ Warning (comp): markdown-mode.el:1303:2: Warning: defconst 
`markdown-fenced-block-pairs' docstring has wrong usage of unescaped single 
quotes (use \= or different quoting)
⛔ Warning (comp): markdown-mode.el:1608:24: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): markdown-mode.el:1608:39: Warning: ‘point-at-eol’ is an 
obsolete function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): markdown-mode.el:1619:45: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): markdown-mode.el:1619:60: Warning: ‘point-at-eol’ is an 
obsolete function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): markdown-mode.el:1630:38: Warning: ‘point-at-eol’ is an 
obsolete function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): markdown-mode.el:1645:17: Warning: ‘point-at-eol’ is an 
obsolete function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): markdown-mode.el:2551:28: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): markdown-mode.el:2633:2: Warning: docstring has wrong usage 
of unescaped single quotes (use \= or different quoting)
⛔ Warning (comp): markdown-mode.el:2752:47: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): markdown-mode.el:2783:28: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): markdown-mode.el:2966:33: Warning: ‘point-at-eol’ is an 
obsolete function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): markdown-mode.el:3014:2: Warning: docstring has wrong usage 
of unescaped single quotes (use \= or different quoting)
⛔ Warning (comp): markdown-mode.el:3020:2: Warning: docstring has wrong usage 
of unescaped single quotes (use \= or different quoting)
⛔ Warning (comp): markdown-mode.el:3042:2: Warning: docstring has wrong usage 
of unescaped single quotes (use \= or different quoting)
⛔ Warning (comp): markdown-mode.el:3096:45: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): markdown-mode.el:3097:49: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): markdown-mode.el:4462:64: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): markdown-mode.el:4468:26: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): markdown-mode.el:4518:2: Warning: docstring has wrong usage 
of unescaped single quotes (use \= or different quoting)
⛔ Warning (comp): markdown-mode.el:4960:2: Warning: docstring has wrong usage 
of unescaped single quotes (use \= or different quoting)
⛔ Warning (comp): markdown-mode.el:5770:58: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): markdown-mode.el:6220:47: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): markdown-mode.el:6220:62: Warning: ‘point-at-eol’ is an 
obsolete function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): markdown-mode.el:6470:15: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ 
instead.
⛔ Warning (comp): markdown-mode.el:6470:30: Warning: ‘point-at-eol’ is an 
obsolete function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead.
⛔ Warning (comp): markdown-mode.el:6499:30: Warning: ‘point-at-bol’ is an 
obsolete function (as of 29.1); use 

Bug#1050071: llvm-defaults: move to 16

[Simon McVittie]

On Mon, 11 Sep 2023 at 19:46:07 +0300, Timo Aaltonen wrote:
> Simon McVittie kirjoitti 11.9.2023 klo 12.36:
> > I've opened a Mesa bug at wishlist severity suggesting a move to version
> > 16, and set it to block the bug for llvm-toolchain-15 removal (#1050070).
> 
> The remaining blocker for this is that using llvm-16 requires a newer
> bindgen, and the latest upstream version split the cli separate, so that
> needs to be packaged (has been done AIUI) and processed through NEW first,
> see:
> 
> https://salsa.debian.org/rust-team/debcargo-conf/-/issues/50

Does this block a general swap of the defaults from 14 to 16, or is it
just a blocker for Mesa moving to 16 as a result of something Mesa-specific?

Is there / does there need to be a transition tracking bug for this?

Perhaps to avoid the trip through NEW it would be pragmatic to make
rust-bindgen be temporarily or permanently a multiple-upstream-tarball
binary package that combines the upstream projects bindgen and
bindgen-cli, avoiding needing to wait for NEW on the critical path?

Thanks,
smcv

Bug#567033: Decide if we should continue recommending /usr/games

[Antoine Beaupré]

On 2023-09-11 10:19:13, Russ Allbery wrote:

[...]

> I am inclined to agree; it's just one more thing for people to think about
> while packaging things, and I don't think it serves much of a useful
> purpose.  However, the bug log has a couple of concrete objections.

For the record, I actually read through those and didn't mean to restart
that thread: I figured people made their points and argued there thing
and there wasn't much to be said there, but now that you've made such a
nice summary, I can expand on the opinion I voiced above, I guess. :)

> Axel Beckert objected because games may conflict with other tools
> installed in /usr/bin.  I feel like this is already a bug and merging the
> two namespaces to force us to deal with that bug may be a feature in
> disguise, because having two binaries with entirely different purposes on
> the user's PATH is a recipe for confusion and problems.  The two bugs
> cited were:
>
> https://bugs.debian.org/845629
> https://bugs.debian.org/752114
>
> which are about a conflict between the game pacman and the package manager
> pacman.  The game pacman now appears to be orphaned but does indeed still
> ship /usr/games/pacman, and /usr/bin/pacman is provided by
> pacman-package-manager.

Yeah, I've always find this confusing, *especially* when you (like me)
have been adding /usr/games to your PATH since basically forever.

The truth is we really have one global binary namespace. Things that
move away from that tend to generate problems, or just live in their own
namespace (e.g. /usr/libexec or something). /usr/games is just a weird
exception that does not, in my opinion, deserve to exist anymore.

> There was also one request (from Alexandre Detiste) to retain this
> separation that, if I understood it correctly, was based on wanting to
> block access to games for children with accounts on the system.
>
> This is similar the old multiuser timeshare use case for separating games
> back when they competed for resources with other uses of the system and
> administrators wanted to be able to stop people from running them until
> after hours.  I feel like this use case is exceptionally rare at this
> point, and I'm not sure it's worth the packaging thought to maintain a
> separation just for that.

I also believe there are other ways to block access to files than move
them to a different directory, even if we *would* want to respond to
that use case. AppArmor comes to mind, for example.

> Alexandre also requested keeping games data separate so that it could be
> moved out of the /usr partition because it could be quite large.  This is
> another concern that I think in the subsequent eight years has become a
> bit less compelling due to the increase in the size of disks (which is
> only sort of keeping up with full commercial games, but is certainly
> keeping up with the games packaged in Debian).

I don't know about you folks, but the last time *I* played a game on
Debian, it was from steam, and all that crap ended up somewhere in my
$HOME, nevermind the :i386 architecture mess I had to slap on as well.

/usr/games certainly didn't help there... ;)

So yeah, maybe we could gamesmerge? I can see the GR coming aaah! ;)

a.

-- 
The difference between a democracy and a dictatorship is that in a
democracy you vote first and take orders later; in a dictatorship you
don't have to waste your time voting.
 - Charles Bukowski

Bug#567033: Decide if we should continue recommending /usr/games

[Russ Allbery]

Antoine Beaupré  writes:

> I wonder if we should just do the same. I'm not sure I see the point of
> having all that stuff in a separate directory, personnally, but at least
> in this case we shouldn't needlessly diverge from upstream... although
> in terms of upstream for bsd-games, things are kind of hazy, at best,
> from what I understand.

I am inclined to agree; it's just one more thing for people to think about
while packaging things, and I don't think it serves much of a useful
purpose.  However, the bug log has a couple of concrete objections.

Axel Beckert objected because games may conflict with other tools
installed in /usr/bin.  I feel like this is already a bug and merging the
two namespaces to force us to deal with that bug may be a feature in
disguise, because having two binaries with entirely different purposes on
the user's PATH is a recipe for confusion and problems.  The two bugs
cited were:

https://bugs.debian.org/845629
https://bugs.debian.org/752114

which are about a conflict between the game pacman and the package manager
pacman.  The game pacman now appears to be orphaned but does indeed still
ship /usr/games/pacman, and /usr/bin/pacman is provided by
pacman-package-manager.

There was also one request (from Alexandre Detiste) to retain this
separation that, if I understood it correctly, was based on wanting to
block access to games for children with accounts on the system.

This is similar the old multiuser timeshare use case for separating games
back when they competed for resources with other uses of the system and
administrators wanted to be able to stop people from running them until
after hours.  I feel like this use case is exceptionally rare at this
point, and I'm not sure it's worth the packaging thought to maintain a
separation just for that.

Alexandre also requested keeping games data separate so that it could be
moved out of the /usr partition because it could be quite large.  This is
another concern that I think in the subsequent eight years has become a
bit less compelling due to the increase in the size of disks (which is
only sort of keeping up with full commercial games, but is certainly
keeping up with the games packaged in Debian).

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

Bug#1051718: RM: debdry -- RoQA; abandoned experiment; orphaned; FTBFS

[Chris Hofstaedtler]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear ftpmasters,

please remove debdry. You'll remember it is an abandoned experiment, and
currently orphaned.
It also FTBFS for a while already (#954560) and has another RC bug open
(#1040322).

It seems unlikely someone will come around to fix bugs here.

I cannot see any r-build-deps, should be safe to remove.

Thanks,
Chris

Bug#1051717: split wtf(6) in a separate package?

[Antoine Beaupre]

Package: bsdgames
Version: 2.17-29+b1
Severity: critical

I wonder if wtf(6) should be split in a separate package. It's a
genuinely useful package (as opposed to a "game") that I have only
discovered recently, even though I have been familiar with BSD games
for more than a few decades at this point (!).

It seems to be effectively maintained in its own fork right now, with
updates on the acronyms files maintained in debian/patches, which
... doesn't seem ideal.

void-linux seem to have their own git repo for this now:

https://github.com/void-linux/netbsd-wtf

... and it seems relatively up to date. It *looks* like the upstream
source is split between:

http://cvsweb.netbsd.org/bsdweb.cgi/src/share/misc/?only_with_tag=MAIN

and:

http://cvsweb.netbsd.org/bsdweb.cgi/src/games/wtf/?only_with_tag=MAIN

... so I'm not sure how we should handle that, but maybe converging
over the above git repo would be best?

Another upstream I found is:

https://sourceforge.net/projects/bsd-games/

... but i'm not sure how valid that actually is either.

Arch seems to be using this as an upstream now:

https://github.com/vattam/BSDGames

See:

https://archlinux.org/packages/extra/x86_64/bsd-games/

... but that doesn't ship the wtf(6) program!

Anyway, just a thought!

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

Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 bsdgames depends on:
ii  libc6  2.36-9+deb12u1
ii  libfl2 2.6.4-8.2
ii  libgcc-s1  12.2.0-14
ii  libncurses66.4-4
ii  libstdc++6 12.2.0-14
ii  libtinfo6  6.4-4
ii  miscfiles [wordlist]   1.5+dfsg-4
ii  wamerican-huge [wordlist]  2020.12.07-2
ii  wfrench [wordlist] 1.2.7-2

bsdgames recommends no packages.

bsdgames suggests no packages.

-- no debconf information

Bug#997042: bino: watch file: wrong address

[Tobias Frost]

Control: tags -1 pending patch

Fixed in the repo already:
https://github.com/schaal/bino/commit/f9975690d61d199abf61ecf464d685d29d38d7df

Bug#1051716: mopac-makpol apparently not yet packaged

[Norwid Behrnd]

Package: mopac
Version: 22.0.6+dfsg-1+b1
Severity: wishlist
X-Debbugs-Cc: nbeh...@yahoo.com

Dear Maintainer,

apparently, the currently available package about MOPAC 22.0.6 does not yet
include the program's utility `mopac-makpol`.  For future releases maintained
by DebiChem, I would like to suggest its addition.

To quote one of the developers, "MAKPOL is performing a structural
transformation - it is unfolding the periodic unit cell of a crystal into a
supercell - which isn't too complicated, but not something that OpenBabel can
do at the moment as far as I'm aware. MAKPOL is much simpler than MOPAC and
PARAM and may eventually be replaced by a Python script."[1]  A dedicated web
page briefly outlines its functionality,[2] and provides a compiled executable
for Microsoft Windows.[3]  Else, the GUI based installer for Linux the project
distributes offers it as a non mandatory extra.[4]

With best regards,

Norwid Behrnd

[1] https://github.com/openmopac/mopac/issues/173#issuecomment-1713917483
[2] http://openmopac.net/manual/makpol.html
[3] http://openmopac.net/manual/makpol.zip
[4] https://github.com/openmopac/mopac/releases


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

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

Versions of packages mopac depends on:
ii  libblas3 [libblas.so.3]3.11.0-2
ii  libc6  2.37-7
ii  libgcc-s1  13.2.0-2
ii  libgfortran5   13.2.0-2
ii  libgomp1   13.2.0-2
ii  liblapack3 [liblapack.so.3]3.11.0-2
ii  libopenblas0-pthread [liblapack.so.3]  0.3.23+ds-3

mopac recommends no packages.

mopac suggests no packages.

-- no debconf information

Bug#1051714: (no subject)

[groemich]

Sorry i'm have problems to understand version numbering in 
linux-image-amd64 package.


i'm using debian bookworm stable and the latest kernel 
(vmlinuz-6.1.0-12-amd64 under /boot) [SECURITY] [DSA 5492-1] linux 
security update  give me the following error while my dvb card loading:


kernel: dvbdev: DVB: registering new adapter (SMI_DVB)
kernel: failing symbol_get of non-GPLONLY symbol m88ds3103_attach.
kernel: DVB: Unable to find symbol m88ds3103_attach()


There is no device under /dev/dvb anymore and i have to load the 
previous kernel vmlinuz-6.1.0-11-amd64.

Bug#1051715: postfix-gld: There is a conflict between default MariaDB charset and the provided file tables.mysql

[Santiago Vila]

Package: postfix-gld
Version: 1.7-9
Severity: important
X-Debbugs-Cc: sa...@gasmi.net,sanv...@debian.org
Tags: patch

Hello.

On a newly installed Debian 12 (bookworm) system, following the
indications in README.Debian leads to the following error message:

[...]
MariaDB [(none)]> USE gld;
Database changed
MariaDB [gld]> source /usr/share/gld/tables.mysql
ERROR 1071 (42000) at line 1 in file: '/usr/share/gld/tables.mysql': Specified 
key was too long; max key length is 1000 bytes
Query OK, 0 rows affected (0.006 sec)

and the greylist table is not created.

This happens because now the default character set is utf8mb4,
which supports up to four bytes per character.

I have been reading this:

https://en.wikipedia.org/wiki/Email_address

To summarize: The IDN standard performs a clever mangling of the domain names
so that it becomes ASCII before it's processed by tools like GLD.

For the local part of the address, wikipedia says that people "avoid
special characters to avoid the risk of rejected emails".

So, using "latin1", as in the attached patch, is probably enough
to fix the issue, but I'd like to hear from you. I plan to fix this
in stable as well, in some point release (Debian 12.x).

(Using X-Debbugs-Cc to reach the author).

Thanks.--- a/postfix-gld-1.7/tables.mysql
+++ b/postfix-gld-1.7/tables.mysql
@@ -6,11 +6,11 @@ CREATE TABLE greylist (
   last int(11) NOT NULL default '0',
   n int(11) NOT NULL default '0',
   PRIMARY KEY  (ip,sender,recipient)
-) ENGINE=MyISAM COMMENT='greylist';
+) ENGINE=MyISAM CHARSET=latin1;
 
 
 CREATE TABLE whitelist (
   mail char(242) NOT NULL default '',
   comment char(242) NOT NULL default '',
   PRIMARY KEY  (mail)
-) ENGINE=MyISAM;
+) ENGINE=MyISAM CHARSET=latin1;

Bug#567033: Decide if we should continue recommending /usr/games

[Antoine Beaupré]

On 2018-06-14 11:42:22, Simon McVittie wrote:
> Debian can choose to put games in the /.../games directories, or in the
> standard directories /usr/bin, /usr/share etc., or any mixture of our
> choice, orthogonal to whether/when we move to FHS 3.0.

It's been a while since this was discussed, but I have just learned of
this issue, so sorry for bumping an old thread but...

I have recently learned that FreeBSD moved their games out of /usr/games
and into /usr/bin. Things like rot13(6), fortune(6), primes(6) are all
in the main PATH now, amazing no? :)

That happened in 2015:

https://cgit.freebsd.org/src/commit/ObsoleteFiles.inc?id=11d9aa670723f508821f2bf6980a555360783a80

I wonder if we should just do the same. I'm not sure I see the point of
having all that stuff in a separate directory, personnally, but at least
in this case we shouldn't needlessly diverge from upstream... although
in terms of upstream for bsd-games, things are kind of hazy, at best,
from what I understand.

(Kind of OT, but for example, wtf(6) is not in FreeBSD at all and comes
from NetBSD. It's maintained through a patch(1) in debian/patches on
bsd-games...)

Not sure what other BSDs are doing with their /usr/games, and I
understand we're not a BSD, but I figured I would at least document
what's going on on their side of that silly historical divide.

a.

-- 
If builders built houses the way programmers built programs,
The first woodpecker to come along would destroy civilization.
- Gerald Weinberg

Bug#1051600: emacs: shouldn't native-compilation use the cached eln-files?

[Sean Whitton]

control: severity -1 normal
control: tag -1 + moreinfo

Hello,

On Sun 10 Sep 2023 at 01:15pm +02, Jörg-Volker Peetz wrote:

> on my system each newly started emacs process does native-compilation of
> all used modules, even the ones already compiled by previous processes.
> Is this to be expected?
> As I see it, the cached native-compiled modules should be re-used.
> Do I have to configure something for that?

It's not expected.  But we will need more precise steps to reproduce to
do anything about it.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1051714: linux-image-amd64 6.1.38-1 dvb card stop working, failing symbol_get of non-GPLONLY symbol

[groemich]

Package: linux-image-amd64
Version: 6.1.38-1

Since 6.1.38-1 my dvb card stop working.

kernel: dvbdev: DVB: registering new adapter (SMI_DVB)
kernel: failing symbol_get of non-GPLONLY symbol m88ds3103_attach.
kernel: DVB: Unable to find symbol m88ds3103_attach()

Bug#1050071: llvm-defaults: move to 16

[Timo Aaltonen]

Simon McVittie kirjoitti 11.9.2023 klo 12.36:

On Sat, 19 Aug 2023 at 10:39:44 +0200, Sylvestre Ledru wrote:

llvm-defaults has been pointing to 16 in experimental for quite sometime.
Opening this transition to make sure it is on your radar! :)

I opened bug #1050070 & #1050069 for future removals.


Mesa is a significant user of LLVM, and hard-codes its own non-default
version of LLVM which often runs ahead of the default (currently 15).
It seems to be relatively common for a LLVM version upgrade to cause
regressions or uninstallability on at least one architecture, and also
relatively common for a LLVM version upgrade to be necessary to unblock
features or bug fixes in Mesa, which I assume is why the Mesa maintainers
have felt the need to control this themselves.

Should Mesa try moving to -16 *before* the default changes? It would
seem unhelpful to move the rest of the distribution to a version that
Mesa can't use for whatever reason.

I've opened a Mesa bug at wishlist severity suggesting a move to version
16, and set it to block the bug for llvm-toolchain-15 removal (#1050070).

 smcv



Hi,

The remaining blocker for this is that using llvm-16 requires a newer 
bindgen, and the latest upstream version split the cli separate, so that 
needs to be packaged (has been done AIUI) and processed through NEW 
first, see:


https://salsa.debian.org/rust-team/debcargo-conf/-/issues/50


--
t

Bug#1043009: lcov-2.0-2 Fails to build

[Michael Welsh Duggan]

This package fails to build in the autobuilder and on my home machine:

>From the autobuilder:

make[2]: Entering directory '/<>/tests'
Creating coverage files (2 tests, 5 source files)
Creating coverage files (2 tests, 5 source files)
  Source tree .   Source tree . Could not create directory 
/<>/tests/src/build/info
done (950 lines, 50 functions, 3428 branches)
  Full coverage ... make[2]: *** [common.mak:75: 
/<>/tests/zero.info] Error 17


>From my home machine:

make[2]: Entering directory '/usr/local/src/lcov-2.0/tests'
/usr/local/src/lcov-2.0/tests//bin/mkinfo: Could not create directory src/: 
File exists
Creating coverage files (2 tests, 5 source files)
  Source tree . Creating coverage files (2 tests, 5 source files)
  Source tree . Creating coverage files (2 tests, 5 source files)
  Source tree . Creating coverage files (2 tests, 5 source files)
  Source tree . Creating coverage files (2 tests, 5 source files)
  Source tree . make[2]: *** [common.mak:75: 
/usr/local/src/lcov-2.0/tests/full.info] Error 17


-- 
Michael Welsh Duggan
(m...@md5i.com)

Bug#1051314: fonts-recommended: recognise noto-core as alternative to dejavu-core

[Jonas Smedegaard]

Quoting Gunnar Hjalmarsson (2023-09-10 21:25:12)
> On 2023-09-10 13:53, Adam Borowski wrote:
> > On Sat, Sep 09, 2023 at 11:24:04PM +0200, Gunnar Hjalmarsson wrote:
> >>> Alas, noto has the downside of making font pickers next to useless,
> >>> as it declares every single of languages it supports as a separate
> >>> font family. So instead off just "Noto Sans" "Noto Mono" "Noto
> >>> Slightly Serifed", you have "Noto Western Klingon" "Noto Eastern
> >>> Klingon" and so on, making the list of available fonts one big noto
> >>> fest.
[...]
> > Besides, Noto can be said to be a metapackage by itself, providing a large
> > set of fonts -- even if it claims to be a single font, it presents hundreds
> > of them to the system and UI interfaces.
> 
> That's entirely a result of the way the Noto fonts are packaged in 
> Debian, and not something that should be attributed to Noto itself. 
> Discussed at https://bugs.debian.org/983291 .

You are potentially talking past each other here:

Noto (the upstream project) is marketed as a font but technically
appears in an installed operating system not as a single font family but
as multiple similarly named but independent font families, each with a
set of weights and each covering a subset of scripts and glyphs.

fonts-noto (the Debian binary package) is a metapackage pulling in all
upstream Noto fonts available in Debian.

So yes, a Debian metapackage exists that is big, but the existence of
that metapackage is not what "mak[es] font pickers next to useless", nor
what "claims to be a single font".


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1051713: exim4-daemon-heavy 4.96-22: misbehavior in string expansion function reduce combined with inlisti function

[DebianMrt]

Package: exim4-daemon-heavy
Version: 4.96-22
Severity: important

Dear Maintainer,

   Installed Packages list:

 * ii  exim4  4.96-22  all
 * ii  exim4-base 4.96-22  amd64
 * ii  exim4-config   4.96-22  all
 * ii  exim4-daemon-heavy 4.96-22  amd64

   example calling command :

   exim -be '${reduce {<\n 1.1.1.1\n2.2.2.2\n3.3.3.3\n4.4.4.4\n4.4.4.4\n}{}{${if 
!inlisti{$item}{<\n $value}{$value$item\n}{$value'

   output is :

 4.4.4.4  ->  last 4.4.4.4 not matched in list and last value is the output

Counter check with exim4 4.94.2 :

   Installed Packages list:

 * ii  exim4  4.94.2-7 all
 * ii  exim4-base 4.94.2-7 amd64
 * ii  exim4-config   4.94.2-7 all
 * ii  exim4-daemon-heavy 4.94.2-7 amd64

   exim -be '${reduce {<\n 1.1.1.1\n2.2.2.2\n3.3.3.3\n4.4.4.4\n4.4.4.4\n}{}{${if 
!inlisti{$item}{<\n $value}{$value$item\n}{$value'

   output is :

   1.1.1.1
   2.2.2.2
   3.3.3.3
   4.4.4.4  -> last 4.4.4.4 matches in list and the reduced list is the output  
(double 4.4.4.4 removed)

BR
Sascha

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

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

Versions of packages exim4-daemon-heavy depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  exim4-base 4.96-22
ii  libc6  2.36-9+deb12u1
ii  libcrypt1  1:4.4.33-2
ii  libdb5.3   5.3.28+dfsg2-1
ii  libgnutls-dane0    3.8.1-4+b1
ii  libgnutls30    3.8.1-4+b1
ii  libidn12   1.41-1
ii  libidn2-0  2.3.3-1+b1
ii  libldap-2.5-0  2.5.13+dfsg-5
ii  libmariadb3    1:10.11.3-1
ii  libnsl2    1.3.0-2
ii  libpam0g   1.5.2-6
ii  libpcre2-8-0   10.42-4
ii  libperl5.36    5.36.0-7
ii  libpq5 15.3-0+deb12u1
ii  libsasl2-2 2.1.28+dfsg1-3
ii  libspf2-2  1.2.10-7.2+b1
ii  libsqlite3-0   3.40.1-2

-- no debconf information

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Luca Boccassi  writes:

> Two more things went missing: Simon's suggestion on the versioned
> dependencies on the virtual packages,

Ah, yes, I'm sorry, I talked myself out of that and then completely forgot
the previous discussion so didn't say anything.

My concern is that it felt like we were providing a detailed description
of an entirely normal dependency management situation (you always have to
depend on the version of a package you use that provides the interface
you're using unless it's old enough that it doesn't matter), and I wasn't
sure what was special about this one that warranted spelling that out
other than the need to add the version constraint to both stanzas.  So I
kept that part but omitted the rest.

The phrasing Simon proposed I think would be appropriate if we thought
most packages would need a version constraint, but I didn't think the
functionality was changing that quickly.  Am I wrong about that?  It felt
awkward to include the version constraints and then tell people to remove
them if they're going to be able to remove them 95% of the time, but I
don't know if that's the case.

Maybe the right way to do this is just have two examples, one as the
default and another if you're using tmpfiles.d functionality added in a
specific version of systemd that's newer than the version shipped with the
stable version of Debian prior to the one you're targeting.

> and the link from the tmpfiles section to the service directory section
> (given it was moved).

It's there (last sentence):

+If the files or directories are only needed by a system service or
+otherwise should only be created when that service is running, packages
+should define those files and directories in the ``systemd`` unit for the
+service (and, for alternative init systems, in the configuration for that
+init system) instead of using the ``tmpfiles.d`` mechanism.  See
+:ref:`s-services-dirs` for more details.

You don't need to spell out the section title; Sphinx defaults to adding
that for you based on the heading that you're linking to.  (I think we are
excessively explicit in a bunch of places in Policy currently due to a
conversion artifact from DebianDoc-XML.)

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

Bug#1050071: llvm-defaults: move to 16

[Sebastian Ramacher]

Control: tags -1 = confirmed

On 2023-09-11 11:05:40 +0100, Simon McVittie wrote:
> On Sat, 09 Sep 2023 at 12:03:10 +0200, Sebastian Ramacher wrote:
> > And one more issue: llvm-toolchain-16 does not build python3-lldb-16 on
> > mips64el, rendering python3-lldb uninstallable there.
> 
> I think this is actually a non-issue? python3-lldb:mips64el is no longer
> built from llvm-defaults/unstable (and it wasn't present in bookworm).
> 
> There is an old python3-lldb:mips64el_1:13.0-53 binary in unstable, but
> it's already uninstallable. I've opened a ftp team bug asking for it to
> be removed to reduce confusion (ideally this should have been done as part
> of dropping the lldb-related packages from mips64el, before bookworm).

Thanks! I missed that this was a cruft binary.

Sylvestre, please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1050803: mate-session-manager: please provide a mate-portals.conf for xdg-desktop-portal

[Simon McVittie]

Control: forwarded -1 https://github.com/mate-desktop/mate-desktop/issues/574
Control: tags -1 + upstream

On Tue, 29 Aug 2023 at 11:52:06 +0100, Simon McVittie wrote:
> Please
> add an mate-portals.conf to tell x-d-p more explicitly what backends
> MATE is meant to be using by default.

I opened an upstream issue with more context: please see above.

If this isn't fixed via an upstream change, it would be appropriate
(and quite easy) to do this as a Debian-specific change.

Thanks,
smcv

Bug#1051712: RFP: libsentry -- Sentry Native SDK

[Eberhard Beilharz]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: e...@sil.org

* Package name: libsentry
  Version : 0.6.5
  Upstream Author : Functional Software, Inc.
* URL : https://github.com/getsentry/sentry-native
* License : MIT
  Programming Lang: C/C++
  Description : Sentry Native SDK

Sentry is a developer-first error tracking and performance monitoring platform.
The Sentry Native SDK is intended for C and C++. However, since it builds as a
dynamic library and exposes C-bindings, it can be used by any language that
supports interoperability with C, such as the Foreign Function Interface (FFI).

Having libsentry available as a package would allow other packages to use it.
This is especially important for software that is also distributed outside of
the Debian universum since it allows to use the same error tracking and
performance code everywhere.

Bug#1050801: cinnamon-common: please provide an x-cinnamon-portals.conf for xdg-desktop-portal

[Simon McVittie]

Control: forwarded -1 https://github.com/linuxmint/cinnamon/issues/11857
Control: tags -1 + upstream

On Tue, 29 Aug 2023 at 11:50:07 +0100, Simon McVittie wrote:
> Please
> add an x-cinnamon-portals.conf to tell x-d-p more explicitly what backends
> Cinnamon is meant to be using by default.

I opened upstream issue https://github.com/linuxmint/cinnamon/issues/11857
with more details and more context, including the user-visible impact
that will occur when we stop patching Debian's xdg-desktop-portal to
work around this.

If this isn't resolved via a new upstream release,
it would also be appropriate (and easy) to do this as a
Debian-specific change, by installing something like this into
/usr/share/xdg-desktop-portal/x-cinnamon-portals.conf:

[preferred]
default=xapp;gtk;

and adding a Depends, Recommends or Suggests on xdg-desktop-portal-xapp
and/or xdg-desktop-portal-gtk.

Thanks,
smcv

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Sam Hartman]

> "Santiago" == Santiago Vila  writes:

Santiago> El 10/9/23 a las 4:09, Russ Allbery escribió:
>> I therefore would like to propose a first: I think Policy should
>> simply say that any package that provides a system service should
>> use debhelper and rely on dh_installsystemd to put the
>> appropriate commands in its maintainer scripts.  (We can then
>> discuss whether we should do the same for init scripts and
>> dh_installinit, although its stanzas are simpler.)

Santiago> Hello. I don't like this approach, and I believe we are
Santiago> mixing two different things here. One of them is our
Santiago> ability (or lack thereof) of policy to catch up with real
Santiago> development done elsewhere. Another one is the fact that
Santiago> policy does not mandate any given implementation.

The question in my mind is whether it is valuable to support multiple
implementations, and I think the answer is no.

In the past, there was not a preference for using debhelper.  So, back
then, we did need to support multiple implementations of debian/rules,
and we needed to specify the things debhelper did.

Having a specified interface like policy is expensive.  I know; I've
spent a good chunk of my life working on various protocols and
standards.
Having specified interfaces brings value when you need multiple
implementations and in a few other cases, like where you need to plan
for certain forms of extensibility or isolation.

There's a part of this where we do need an interface.  We will have
multiple packages wanting their debian/rules to install systemd units.
So, we do need to at least say or imply that if you stick systemd units
in the right place and call dh_installsystemd, then your systemd units
will be properly handled.

But today, we have a policy preference for using debhelper.  We do not
need multiple implementations of debhelper.  There does sort of need to
be an interface between debhelper and systemd if for no other reason
than to allow for systemd to change and to control which details are
hard-coded in maintainer scripts.  But if we agree that we do not need
multiple implementations of debhelper, the policy team does not need to
be part of defining that interface.  We can be more efficient by not
being involved in that process.  Also, we can do a better job of
focusing on the interface that the project does care about (how to tell
debhelper to install your systemd units) and not confuse people with the
details between debhelper and systemd.

Also, by explicitly acknowledging that the deb-systemd-helper and
deb-systemd-invoke interfaces are effectively between debhelper and
systemd, those interfaces can be simpler because they do not need to
allow for multiple implementations of debhelper or systemd.

In effect by making this decision, we are strengthening our preference
for saying packages should use debhelper.  For a significant class of
packages (those with service units) there really will be no easy
alternative.  And if we go down that route, over time, we will probably
prefer debhelper more and more, and it will be less possible to generate
a policy-compliant package that does not use debhelper.

I think that's desirable.
I think we can still find ways to experiment with new more declarative
ways of handling package building.  But I think that having more
uniformity in the cases where we have a single solution that has broad
support will make things easier for everyone.

Put another way, having multiple implementations is often very expensive
in terms of interface complexity, testing complexity, and especially
complexity that developers need to deal with.
In this instance, I do not think that cost is justified.

--Sam


signature.asc
Description: PGP signature

Bug#1051692: Acknowledgement (New version isn't installing a needed header)

[Sebastien Bacher]

s/rhythmbox/transmission/

Le 11/09/2023 à 13:27, Debian Bug Tracking System a écrit :

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1051692: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051692.

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):
  Thomas Goirand 

If you wish to submit further information on this problem, please
send it to 1051...@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.

Bug#1049903: petsc: misbuild with gcc-13

[Drew Parsons]

Source: petsc
Followup-For: Bug #1049903

Thanks for the clarification.  I'll apply the patch.

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Bill Allombert]

On Mon, Sep 11, 2023 at 12:47:15PM +0200, Santiago Vila wrote:
> El 10/9/23 a las 4:09, Russ Allbery escribió:
> > I therefore would like to propose a first: I think Policy should simply
> > say that any package that provides a system service should use debhelper
> > and rely on dh_installsystemd to put the appropriate commands in its
> > maintainer scripts.  (We can then discuss whether we should do the same
> > for init scripts and dh_installinit, although its stanzas are simpler.)
> 
> Hello. I don't like this approach, and I believe we are mixing two different 
> things
> here. One of them is our ability (or lack thereof) of policy to catch up with
> real development done elsewhere. Another one is the fact that policy does
> not mandate any given implementation.

I agree. The issue is that we need to document what dh_installsystemd should do,
otherwise we will not be able to distinguish between bug in dh_installsystemd 
and
intended behaviour, and we will end up freezing dh_installsystemd to avoid 
introducing
problem by breaking incidental interfaces.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.