Bug#1059706: epics-base.pc is broken in epics-dev package

[Andrius Merkys]

Control: tags -1 + confirmed

Hi,

On 2023-12-30 18:06, Matwey V. Kornilov wrote:

Package: epics-dev
Version: 7.0.7+dfsg1-5

Please note, that epics-base.pc file is installed into
/usr/share/pkg-config instead of /usr/share/pkgconfig and cannot be
found.


I have just fixed this in the packaging repository, but the upload will 
have to wait for the fix in pkgconfig content.



Also, content of epics-base.pc points to the nonexistent paths:

# standard variables
prefix=/build/reproducible-path/epics-base-7.0.7+dfsg1
exec_prefix=${prefix}
bindir=${prefix}/bin/linux-x86_64
libdir=${prefix}/lib/linux-x86_64


Right, these are incorrect, prefix should be set to /usr, bindir should 
be free of arch-specific suffix and libdir should include correct arch 
triplet. Not sure how to fix these properly, though. Maybe this could be 
done at initial configuration step, but I know the build system too 
little to say know. Will give a look a couple days later.


Thanks,
Andrius

Bug#1059315: tinyxml: CVE-2023-34194 CVE-2023-40462 CVE-2023-40458

[Salvatore Bonaccorso]

Hi Guilhem, hi Moritz,

On Sat, Dec 30, 2023 at 11:26:02PM +0100, Guilhem Moulin wrote:
> On Sat, 30 Dec 2023 at 21:02:16 +0100, Felix Geyer wrote:
> > There are some minor changes staged in the salsa git repo. It would be good
> > to include them as well. Feel free to push the patch to git and upload.
> > Alternatively a merge request works as well of course.
> 
> Thanks for the fast response!  Tagged and uploaded.
> 
> Security team, if you agree with my assessment that CVE-2023-40462 is a
> duplicate of CVE-2023-34194 (but for a separate project that embeds
> libxml) and that CVE-2023-40458 is a duplicate of CVE-2021-42260 (but
> for a separate project that embeds libxml), I can propose debdiffs for
> bullseye and bookworm.

I think the former is correct but still bit biased. We initially had
exactly CVE-2023-40462 as NFU and CVE-2023-34194 for tinyxml. I have
now commmited
https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/7e507c932b999df48f808969c00f07a638e3357b
hich does match my understanding for this doubled CVE assignment. The
document is actually not very very clear. It still metnions
CVE-2023-40462 but does not consistently say "TinyXML as used in".
Still hope we can agree the above matches our all udnerstanding.
Moritz given you updated back then the entry from NFU and tinyxml, if
you still strongly disagree I will revert the above, but I tried to
explain my reasoning in the commit message.

Now for CVE-2023-40458 I'm  not sure. Looking back at the references
for CVE-2021-42260 and the issue report at
https://sourceforge.net/p/tinyxml/bugs/141/ this sensibly match the
description for CVE-2023-40458, but will want to see if Moritz has an
additional input here.

If this is the case we either have the otpion to mark it really as
duplicate (and request a reject from MITRE) or it is again just a
ALEOS issue "... tinyxml as used in". Again the table here is not very
clear in the report, for the CVE-2023-34194 and CVE-2023-40462 there
were explicitly listed the two CVEs with brackeds including the
product in the the table, but this is not the case for CVE-2023-40458.

Moritz?

Regards,
Salvatore

Bug#1059738: xfce-goodies: Please consider demoting xfburn

[Phil Wyett]

Package: xfce4-goodies
Version: 4.18.2
Severity: wishlist

Dear maintainers,

Please consider demoting xfburn from dep to ideally sug.

So many laptops and systems come without CD/DVD/DVD-RW etc. these days that the 
application is not
required for many in a default install and users requiring it can always 
install it.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




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

Bug#1050256: AppArmor breaks locking non-fs Unix sockets

[Mathias Gibbens]

On Sat, 2023-12-30 at 16:44 +0100, Salvatore Bonaccorso wrote:
> John, did you had a chance to work on this backport for 6.1.y stable
> upstream so we could pick it downstream in Debian in one of the next
> stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix apparmor
> mediating locking non-fs unix sockets") does not work, if not
> havinging the work around e2967ede2297 ("apparmor: compute policydb
> permission on profile load") AFAICS, so that needs a 6.1.y specific
> backport submitted to sta...@vger.kernel.org ?
> 
> I think we could have people from this bug as well providing a
> Tested-by when necessary. I'm not feeling confident enough to be able
> to provide myself such a patch to sent to stable (and you only giving
> an Acked-by/Reviewed-by), so if you can help out here with your
> upstream hat on that would be more than appreciated and welcome :)
> 
> Thanks a lot for your work!

  I played around with this a bit the past week as well, and came to
the same conclusion as Salvatore did that commits e2967ede2297 and
1cf26c3d2c4c need to be cherry-picked back to the 6.1 stable tree.

  I've attached the two commits rebased onto 6.1.y as patches to this
message. Commit e2967ede2297 needed a little bit of touchup to apply
cleanly, and 1cf26c3d2c4c just needed adjustments for line number
changes. I included some comments at the top of each patch.

  With these two commits cherry-picked on top of the 6.1.69 kernel, I
can boot a bookworm system and successfully start a service within a
container that utilizes `PrivateNetwork=yes`. Rebooting back into an
unpatched vanilla 6.1.69 kernel continues to show the problem.

  While I didn't see any immediate issues (ie, `aa-status` and log
files looked OK), I don't understand the changes in the first commit
well enough to be confident in sending these patches for inclusion in
the upstream stable tree on my own.

Mathias
This is a rebase of commit e2967ede2297 ("apparmor: compute policydb permission
on profile load") onto the 6.1.69 kernel release.

The original commit had a line that changed `kvzalloc()` -> `kvcalloc()` in
security/apparmor/policy_unpack.c, but that code doesn't appear in the 6.1 tree,
so I dropped it.

Also included is the one-line declaration of `struct aa_perms default_perms` in
security/apparmor/file.c which was introduced in commit 408d53e923bd ("apparmor:
compute file permissions on profile load").

Tested-by: Mathias Gibbens 

diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c
index 7160e7aa5..aaba936e1 100644
--- a/security/apparmor/apparmorfs.c
+++ b/security/apparmor/apparmorfs.c
@@ -633,7 +633,7 @@ static void profile_query_cb(struct aa_profile *profile, struct aa_perms *perms,
 		state = aa_dfa_match_len(dfa, profile->policy.start[0],
 	 match_str, match_len);
 		if (state)
-			aa_compute_perms(dfa, state, );
+			tmp = *aa_lookup_perms(profile->policy.perms, state);
 	}
 	aa_apply_modes_to_perms(profile, );
 	aa_perms_accum_raw(perms, );
diff --git a/security/apparmor/file.c b/security/apparmor/file.c
index e1b7e9360..8cf610a22 100644
--- a/security/apparmor/file.c
+++ b/security/apparmor/file.c
@@ -212,6 +212,7 @@ static u32 map_old_perms(u32 old)
  *
  * Returns: computed permission set
  */
+struct aa_perms default_perms = {};
 struct aa_perms aa_compute_fperms(struct aa_dfa *dfa, unsigned int state,
   struct path_cond *cond)
 {
diff --git a/security/apparmor/include/perms.h b/security/apparmor/include/perms.h
index 13f20c598..de9631edb 100644
--- a/security/apparmor/include/perms.h
+++ b/security/apparmor/include/perms.h
@@ -133,6 +133,17 @@ extern struct aa_perms allperms;
 	xcheck(fn_for_each((L1), (P), (FN1)), fn_for_each((L2), (P), (FN2)))
 
 
+extern struct aa_perms default_perms;
+
+static inline struct aa_perms *aa_lookup_perms(struct aa_perms *perms,
+	   unsigned int state)
+{
+	if (!(perms))
+		return _perms;
+
+	return &(perms[state]);
+}
+
 void aa_perm_mask_to_str(char *str, size_t str_size, const char *chrs,
 			 u32 mask);
 void aa_audit_perm_names(struct audit_buffer *ab, const char * const *names,
@@ -141,8 +152,6 @@ void aa_audit_perm_mask(struct audit_buffer *ab, u32 mask, const char *chrs,
 			u32 chrsmask, const char * const *names, u32 namesmask);
 void aa_apply_modes_to_perms(struct aa_profile *profile,
 			 struct aa_perms *perms);
-void aa_compute_perms(struct aa_dfa *dfa, unsigned int state,
-		  struct aa_perms *perms);
 void aa_perms_accum(struct aa_perms *accum, struct aa_perms *addend);
 void aa_perms_accum_raw(struct aa_perms *accum, struct aa_perms *addend);
 void aa_profile_match_label(struct aa_profile *profile, struct aa_label *label,
diff --git a/security/apparmor/include/policy.h b/security/apparmor/include/policy.h
index 639b5b248..230ef5007 100644
--- a/security/apparmor/include/policy.h
+++ b/security/apparmor/include/policy.h
@@ -77,6 +77,7 @@ enum profile_mode {
 struct aa_policydb {
 	/* Generic policy DFA specific rule types will 

Bug#1059497: update

[Brian Sturgill]

Tried a 32 bit base install of debian on the raspberry Pi 4. I have the
same results. i have a Fedora install on a laptop with CubicSDR 0.2.7 amd
it works correctly. Both my RaspberryPi and my Debian Workstation have the
modem waterfall issue after installing Bookworm. Same results using a
SDRPlay RSP2 and a HackRF clone.

Thanks,
Brian

Bug#1059737: cpp-httplib: CMake support

[kiwixz]

Package: cpp-httplib
Severity: wishlist
X-Debbugs-Cc: kiw...@outlook.com

Dear Maintainer,

I'd like to use this library from CMake and I believe upstream has direct 
support for it.
Could you please include the CMake config files in the package ?

The typical way to import the library in CMake would be:

find_package(httplib)

But with the current Debian package I need to use the provided pkg-config:

find_package(PkgConfig)
pkg_search_module(httplib IMPORTED_TARGET cpp-httplib)

Thanks!

Regards,

Bug#1059736: ITP: golang-github-theckman-yacspin -- easy to use and customizable terminal spinners

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block 1059406 by -1

* Package name: golang-github-theckman-yacspin
  Version : 0.13.12
  Upstream Contact: https://github.com/theckman/yacspin/issues
* URL : https://github.com/theckman/yacspin
* License : Apache-2.0
  Programming Lang: Go
  Description : easy to use and customizable terminal spinners

 This package provides yet another CLI spinner for Go, taking inspiration
 (and some utility code) from the https://github.com/briandowns/spinner project.
 Specifically `yacspin` borrows the default character sets, and color mappings
 to github.com/fatih/color colors, from that project.
 .
 yacspin features over 90 spinners, can handle dynamic text width of certain
 animations, success and failure results, configurable positioning,
 concurrency, live updates, pausing for updates, support for non-TTY outputs,
 and manually stepping the animation.

Dependency of github.com/darkhz/invidtui.

This package will be maintained within the Go team, and I will need a sponsor.

--
Kind regards,
Maytham Alsudany



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

Bug#1059735: git-buildpackage: baffling instructions w.r.t. creating a new package

[наб]

Package: git-buildpackage
Version: 0.9.30
Severity: normal

Dear Maintainer,

I would like to import the first version of an upstream source into
a fresh gbp-maintained debian package. I have the usual debian
branch files under debian/ prepped, the working tree is ready for
an uscan.

  $ git ls-tree HEAD
  04 tree 4c37e44470bd093f9b15f925366c84757828cbb3debian
  $ git branch -a
  * debian
  $ gbp import-orig --uscan --pristine-tar
  gbp:error:
  Repository does not have branch 'upstream' for upstream sources. If there is 
none see
  
file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT
  on howto create it otherwise use --upstream-branch to specify it.

Of course it doesn't, there is none. Let's see.

The first and most obvious issue is that the #-location doesn't exist.
"GBP" doesn't figure once in the HTML.

But finding a "Starting a Debian™ package from scratch" sexion in the
index, I navigated to
  
file://localhost/usr/share/doc/git-buildpackage/manual-html/gbp.import.fromscratch.html
which says (these are the entire contents of this document, barring 
header/footer):
  Starting a Debian™ package from scratch
  
 So far, we assumed you already have a Debian™ package to start with, but 
what if you want to start a new package? First, create an empty repository:
mkdir package-0.1
cd package-0.1
git init
  
 Then, you import the upstream sources, branch off the upstream-branch 
branch and add the Debian™ files (e.g. via dh_make):
gbp import-orig -u 0.1 ../package-0.1.tar.gz
dh_make
  
 That's it, you're done. If you want to publish your new repository, you 
can use gbp create-remote-repo.

(a) Why on earth does the directory have a version in it?
(b) gbp import-orig doesn't have an -u option:
  $ man gbp-import-orig | grep -- '-u\b'
  $
and even if it did, I don't see how it would materially change the error.
(c) I didn't realise, until evaluating this literally phrase-by-phrase,
what "branch off the upstream-branch branch" was supposed to
mean, and the entire "Then, you import the upstream sources,
branch off the upstream-branch branch and add the Debian™ files"
sequence is incomprehensible:
(c1) this describes a sequence of
 "import -> create upstream branch -> add debian files";
 import where? this is impossible
(c2) what in god's name does "branch off the upstream-branch branch" mean
(c3) what is "the upstream-branch branch". I've never seen a
 branch called "upstream-branch". Why does it spec that
 instead of the documented default of "upstream"?
(c4) no but really. does it try to mean to spec
   git checkout -b upstream
   git import-orig ...
 or what? Because that's what I did finally after I violated
 (c1) and that worked but. well.
(d) I think this whole thing is worse than just saying
  Repository does not have branch 'upstream' for upstream sources.
  Use --upstream-branch or create it with git checkout -b upstream,
  then gbp import-orig again.
(e) This will also fix the "see [url] on howto create it" salad.

Best,
наб

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

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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.23.4+deb12u1
ii  git1:2.39.2-1.1
ii  man-db 2.11.2-2
ii  python33.11.2-1+b1
ii  python3-dateutil   2.8.2-2
ii  python3-pkg-resources  66.1.1-1
ii  python3-yaml   6.0-3+b2
ii  sensible-utils 0.0.17+nmu1

Versions of packages git-buildpackage recommends:
pn  cowbuilder | pbuilder | sbuild  
ii  pristine-tar1.50
ii  python3-requests2.28.1+dfsg-1

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.13p3-1+deb12u1
ii  unzip6.0-28

-- no debconf information


signature.asc
Description: PGP signature

Bug#1059734: /usr/bin/uscan: refuses to download a tarball it says matches, does nothing, exits 0

[наб]

Package: devscripts
Version: 2.23.4+deb12u1
Severity: normal
File: /usr/bin/uscan

Dear Maintainer,

Given:
  $ head debian/*
  ==> debian/changelog <==
  snappy-tools (0-1) unstable; urgency=low
  
  ==> debian/watch <==
  version=4
  opts="pgpsigurlmangle=s:$:.asc:" \
https://git.sr.ht/~nabijaczleweli/snappy-tools/refs 
.*/([0-9][0-9a-zA-Z]*)@ARCHIVE_EXT@
(and an equivalent but fully-populated debian/,
 with a fully-correct d/changelog and populated d/upstream/signing-key.asc)
uscan gives me
  $ uscan --download-current-version --force-download -v
  uscan info: uscan (version 2.23.4+deb12u1) See uscan(1) for help
  uscan info: Scan watch files in .
  uscan info: Check debian/watch and debian/changelog in .
  uscan: warning: debian/changelog(l1): found end of file where expected 
start of change data
  uscan info: package="snappy-tools" version="0-1" (as seen in debian/changelog)
  uscan info: package="snappy-tools" version="0" (no epoch/revision)
  uscan info: ./debian/changelog sets package="snappy-tools" version="0"
  uscan info: Process watch file at: debian/watch
  package = snappy-tools
  version = 0
  pkg_dir = .
  uscan info: opts: pgpsigurlmangle=s:$:.asc:
  uscan info: line: https://git.sr.ht/~nabijaczleweli/snappy-tools/refs 
.*/([0-9][0-9a-zA-Z]*)(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz))
  uscan info: Parsing pgpsigurlmangle=s:$:.asc:
  uscan info: line: https://git.sr.ht/~nabijaczleweli/snappy-tools/refs 
.*/([0-9][0-9a-zA-Z]*)(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz))
  uscan info: Last orig.tar.* tarball version (from debian/changelog): 0
  uscan info: Download the --download-current-version specified version: 0
  uscan info: Requesting URL:
 https://git.sr.ht/~nabijaczleweli/snappy-tools/refs
  uscan info: Matching pattern:
 
(?:(?:https://git.sr.ht)?\/\~nabijaczleweli\/snappy\-tools\/)?.*/([0-9][0-9a-zA-Z]*)(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz))
  uscan info: Found the following matching hrefs on the web page (newest first):
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0.tar.gz (0) 
index=0-1 matched with the download version
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0.tar.gz (0) 
index=0-1 matched with the download version
  uscan info: Scan finished

I use the exact same d/watch for urlview (and other packages),
and it works there.

Actually, having just made a fake version 0a, I see that it /did/
download that.

With --d-c-v I still saw
  uscan info: Found the following matching hrefs on the web page (newest first):
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0a.tar.gz (0a) 
index=0a-1
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0a.tar.gz (0a) 
index=0a-1
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0.tar.gz (0) 
index=0-1 matched with the download version
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0.tar.gz (0) 
index=0-1 matched with the download version
  uscan info: Scan finished
but without I got
  uscan info: Found the following matching hrefs on the web page (newest first):
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0a.tar.gz (0a) 
index=0a-1
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0a.tar.gz (0a) 
index=0a-1
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0.tar.gz (0) 
index=0-1
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0.tar.gz (0) 
index=0-1
  uscan info: Looking at $base = 
https://git.sr.ht/~nabijaczleweli/snappy-tools/refs with
  $filepattern = 
.*/([0-9][0-9a-zA-Z]*)(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz))
 found
  $newfile = 
https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0a.tar.gz
  $newversion  = 0a
  $lastversion = 0
  uscan info: Matching target for downloadurlmangle: 
https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0a.tar.gz
  uscan info: Upstream URL(+tag) to download is identified as
https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0a.tar.gz
  uscan info: Filename (filenamemangled) for downloaded file: 0a.tar.gz
  Newest version of snappy-tools on remote site is 0a, local version is 0
   => Newer package available from:
  => https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0a.tar.gz
  uscan info: Downloading upstream package: 0a.tar.gz
  uscan info: Requesting URL:
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0a.tar.gz
  uscan info: Successfully downloaded upstream package: 0a.tar.gz
  uscan info: Downloading OpenPGP signature from:
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0a.tar.gz.asc 
(pgpsigurlmangled)
 as 0a.tar.gz.asc
  uscan info: Requesting URL:
 https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0a.tar.gz.asc
  uscan warn: In directory ., downloading
https://git.sr.ht/~nabijaczleweli/snappy-tools/archive/0a.tar.gz.asc 
failed: 404 NOT FOUND
  uscan die: FAIL 

Bug#1059560: libwebkit2gtk-4.1-0: Can not add google online account via gnome-controle-center without : export WEBKIT_DISABLE_DMABUF_RENDERER=1

[Alberto Garcia]

On Thu, Dec 28, 2023 at 03:56:17PM +0100, Maurin Sylvain wrote:
> I did libnvidia-egl-gbm1 installation and probed :
> 
> maurin@gimli:~$ unset WEBKIT_DISABLE_DMABUF_RENDERER
> maurin@gimli:~$ gnome-control-center 
[...]
> providerKMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
> Failed to create GBM buffer of size 496x346: Permission denied
> KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
> Failed to create GBM buffer of size 496x346: Permission denied
> KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
> Failed to create GBM buffer of size 496x346: Permission denied
> Failed to create EGL images for DMABufs with file descriptors -1, -1
> and -1

Can you run /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/MiniBrowser and
see if websites work normally?

If not, can you open webkit://gpu with the MiniBrowser and send me the
output?

Thanks,

Berto

Bug#1059733: ITP: golang-k8s-client-go -- Go client for Kubernetes

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Go Packaging Team 


* Package name: golang-k8s-client-go
  Version : 0.29.0
  Upstream Contact: https://github.com/kubernetes/client-go/issues
* URL : https://github.com/kubernetes/client-go
* License : Apache-2.0
  Programming Lang: Golang
  Description : Go client for Kubernetes

 Go clients for talking to a kubernetes cluster.
  * The kubernetes package contains the clientset to access Kubernetes
API.
  * The discovery package is used to discover APIs supported by a
Kubernetes API server.
  * The dynamic package contains a dynamic client that can perform
generic operations on arbitrary Kubernetes API objects.
  * The plugin/pkg/client/auth packages contain optional authentication
plugins for obtaining credentials from external sources.
  * The transport package is used to set up auth and start a connection.
  * The tools/cache package is useful for writing controllers.

This package will be published in go-team.

It is needed by kubernetes, and other projects like receptor, which is a 
controller for awx.

Bug#1057564: python3-dbusmock: inconsistent signature for PairDevice causes gnome-bluetooth3 FTBFS

[Simon McVittie]

Control: block 1058116 by 1057564
Control: tags 1058116 + patch pending
Control: tags 1057564 + patch

On Sat, 30 Dec 2023 at 21:18:37 +, Simon McVittie wrote:
> Because you can't clone a merged bug, I'm unmerging the two equivalent
> FTBFS bug reports, and arbitrarily choosing to use:
> 
> - #1058116 to represent the gnome-bluetooth3 test failure with dbusmock
>   0.30.0-2, which is genuinely a gnome-bluetooth3 bug, for which I've
>   proposed a fix in
>   https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/merge_requests/175.
>   The symptom is that multiple tests time out.

This fix for #1058116 is pending in gnome-team git, but cannot usefully
be uploaded until the other bug is fixed:

> - #1057564 to represent the gnome-bluetooth3 test failure with dbusmock
>   0.30.1-1, even after applying GNOME/gnome-bluetooth!175, which as far
>   as I can see is a dbusmock regression, reported as
>   https://github.com/martinpitt/python-dbusmock/issues/193
>   (I haven't tested a patch for this, I hope it's as simple as removing
>   the obsolete 3rd argument in one call to PairDevice()).

That is indeed sufficient. Please see
https://github.com/martinpitt/python-dbusmock/pull/194 or the
attached patch.

smcv
>From e5679687939375265a0d080148cc129feade02e1 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 30 Dec 2023 23:58:08 +
Subject: [PATCH] bluez5: Fix invalid arguments to PairDevice

The third (device class) argument to PairDevice was removed in 0.30.1,
but this call to it was still passing a third parameter, resulting in
an error from dbus-python whenever Pair() was called. This caused a
unit test regression in gnome-bluetooth.

Fixes: 63264e18 "bluez5: Clean up static default properties, re-drop PairDevice class_ parameter"
Bug: https://github.com/martinpitt/python-dbusmock/issues/193
Bug-Debian: https://bugs.debian.org/1057564
Signed-off-by: Simon McVittie 
---
 dbusmock/templates/bluez5.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dbusmock/templates/bluez5.py b/dbusmock/templates/bluez5.py
index 4c590da..5603bd8 100644
--- a/dbusmock/templates/bluez5.py
+++ b/dbusmock/templates/bluez5.py
@@ -333,7 +333,7 @@ def Pair(device):
 raise dbus.exceptions.DBusException("Device already paired", name="org.bluez.Error.AlreadyExists")
 device_address = device.props[DEVICE_IFACE]["Address"]
 adapter_device_name = Path(device.props[DEVICE_IFACE]["Adapter"]).name
-device.PairDevice(adapter_device_name, device_address, MOCK_PHONE_CLASS)
+device.PairDevice(adapter_device_name, device_address)
 
 
 @dbus.service.method(DEVICE_IFACE, in_signature="", out_signature="")
-- 
2.43.0

Bug#1040070: ITP texlab

[Matthias Geiger]

On Wed, 26 Jul 2023 22:45:19 +0100 Sebastian Crane 
 wrote:

> Dear Matthias,
>
> > This seems like a nice thing to have in debian. Do you need any 
help with
> > rust packaging ? From a first glance it doesn't look like there's 
that much

> > missing. itertools and logos look like a good starting point.
>
> I would receive such help gratefully! I'll join the IRC channel as per
> your suggestion.
>


I got isocountry accepted. this equals only the logos-* stack missing; 
currently it's not packageable because a dependency had an api change.


best,

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



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1040988: fixed in picom 10.2-2

[Vincent Bernat]

On Tue, 26 Dec 2023 16:19:12 + Debian FTP Masters 
 wrote:



   * Fix infinite loop with GNOME (Closes: #1040988)


Upstream also added: 
https://github.com/yshui/picom/commit/7366553be2b825495c5b1e09be09d0fabde4b9b4


Otherwise, picom won't start at the beginning of a session (no windows yet).

Bug#1059731: Mate keyboard indicator won't cycle layout

[paculino]

Package: mate-applets
Version: 1.26.1-1
Tags: l10n

When keyboard layout selection list is set from terminal (I used "setxkbmap 
-layout eu,epo,latam, -option 'grp:shifts_toggle,lv3:alt_switch'" but did not 
test other combinations), the indicator applet's keyboard layout indicator no 
longer works as a button to click to cycle through the layouts, although macros 
set to do so still function. I suspect it is related to systemd only because 
when I migrated my system to Devuan (and switched to sysvinit), this function 
returned. I have however, kept a clone of both my boot and root partitions 
before the migration, and ran apt upgrade right before making these clones.
I have been running the script to set the layout list as a startup script 50 
seconds from boot, but this issue still applied before that. Additionally, the 
older kernels (inclusively) since 6.1.0-12-amd64 did not seem to have any 
effect on this issue. In addition to the typical package information, I have 
included systemd as it appears related, as well as several x11 packages because 
the command is from x11-xkb-utils.


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

Kernel: Linux 6.1.0-16-amd64 (SMP w/8 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 mate-applets depends on:
ii  gsettings-desktop-schemas  43.0-1
ii  gvfs   1.50.3-1
ii  libatk1.0-02.46.0-5
ii  libc6  2.36-9+deb12u3
ii  libcairo2  1.16.0-7
ii  libcpupower1   6.1.67-1
ii  libdbus-glib-1-2   0.112-3
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1+b1
ii  libglib2.0-0   2.74.6-2
ii  libgtk-3-0 3.24.38-2~deb12u1
ii  libgtksourceview-3.0-1 3.24.11-2+b1
ii  libgtop-2.0-11 2.40.0-2
ii  libgucharmap-2-90-71:15.0.2-1
ii  libmate-panel-applet-4-1   1.27.0-1
ii  libmateweather11.26.0-1.1+deb12u1
ii  libnl-3-2003.7.0-0.2+b1
ii  libnl-genl-3-200   3.7.0-0.2+b1
ii  libnotify4 0.8.1-1
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpangocairo-1.0-01.50.12+ds-1
ii  libpolkit-gobject-1-0  122-3
ii  libupower-glib30.99.20-2
ii  libwnck-3-043.0-3
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxml22.9.14+dfsg-1.3~deb12u1
ii  mate-applets-common1.26.1-1
ii  mate-panel 1.27.0-1
ii  sgml-base  1.31

Versions of packages mate-applets recommends:
ii  mate-media   1.26.0-2
ii  mate-polkit  1.26.1-3
ii  mate-system-monitor  1.26.0-1

mate-applets suggests no packages.

-- no debconf information


systemd is version 252.19-1~deb12u1

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libaudit1  1:3.0.9-1
ii  libblkid1  2.38.1-5+b1
ii  libc6  2.36-9+deb12u3
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-4~deb12u1
ii  libfdisk1  2.38.1-5+b1
ii  libgcrypt201.10.1-3
ii  libkmod2   30+20221128-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.1-0.2
ii  libmount1  2.38.1-5+b1
ii  libp11-kit00.24.1-2
ii  libseccomp22.5.4-1+b3
ii  libselinux13.4-1+b6
ii  libssl33.0.11-1~deb12u2
ii  libsystemd-shared  252.19-1~deb12u1
ii  libsystemd0252.19-1~deb12u1
ii  libzstd1   1.5.4+dfsg2-5
ii  mount  2.38.1-5+b1

Versions of packages systemd recommends:
ii  chrony [time-daemon]4.3-2+deb12u1
ii  dbus [default-dbus-system-bus]  1.14.10-1~deb12u1

Versions of packages systemd suggests:
ii  libfido2-11.12.0-2+b1
ii  libqrencode4  4.1.1-1
pn  libtss2-esys-3.0.2-0  
pn  libtss2-mu0   
pn  libtss2-rc0   
ii  policykit-1   122-3
ii  polkitd   122-3
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-1~deb12u1
pn  dracut 
ii  initramfs-tools0.142
pn  libnss-systemd 
ii  libpam-systemd 252.19-1~deb12u1
ii  udev   252.19-1~deb12u1

-- no debconf information


Versions of packages x11-xkb-utils is related to:
ii  x11-xkb-utils   7.7+7
ii  libc6:amd64 2.36-9+deb12u3
ii  libc6-dbg:amd64 2.36-9+deb12u3
ii  libc6-dev:amd64 2.36-9+deb12u3
ii  libcompfaceg1   1:1.5.2-5.1
ii  libx11-6:amd64  2:1.8.4-2+deb12u2
ii  libxaw7:amd64   2:1.0.14-1
ii  libxkbfile1:amd64   1:1.1.0-1
ii  libxrandr2:amd642:1.5.2-2+b1
ii  libxt6:amd641:1.2.1-1.1

All 

Bug#1059732: RFP: oh-my-bash -- framework to extend bash shell functionality

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: oh-my-bash
  Version : git snapshot
  Upstream Contact: Toan Nguyen 
* URL : https://github.com/ohmybash/oh-my-bash
* License : MIT
  Programming Lang: shell
  Description : framework to extend bash shell functionality

oh-my-bash extends the functionality of the bash shell. It provides
plugins and themes for the shell. A funtionality I use for instance is
the git plugin showing the current branch one is on. This helps to keep
track of things.

best,

werdahias


-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmWQpQoVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1YaIP/jvQ09Bepol73NOEWoXUh19CDUrA
CNC5vjSv4VJBX67pb8H1WYs3zxj4dp1uORrnRPdktdxUljRswIiuGolc1tAK7e5w
AhY2O+hEIQQ8/1lB5imQe8bET2vGaXm8+eHsdEqrHYWGYXE58eM8a0DgQdZQWznB
Lvejoa6g7kqkjk1sWhwr3Q9FiqSktRk8XXpJbMKosTYa2Nn6JpwD5b+qaArXCNDn
QMwZ4jCDYQ7tZHlbLrBJFWQGS9tvSDbNuH+ipq4qpW+TwNrCFiZeWPX8X4U+1bta
AswLipoLuh8/1j+xgNTIvfe6ztHUeVaHdT/iiHmkZR97Lni0H8u1xv7sRWkzZ2MF
y8TtLo8Ona+xwZjAPiq8TLN4EalW2+yxitHSWb9/sm1djE4c3X8v1zJUWOHeTt5H
hZuKL1+kz1Ss6AjhaiekPacZqABOdYrX/USP8zGGkfamdqtrG4nGoH2MwHtzkpnT
hrqqLM3niHooCZHXYAF/YF840IpQcJrYDxedLY+rQoORPORJVqFN00Yx3ZYmmro7
hRNA4DX2yhKDPYj7FLJJ3I2liOrJKhr1cYL4ICcIi9ZeKwJEIbi6x+dlShagpsxw
sHB/mHIiMm0Bsweux8tzyhiGsfh2Gc7yhze3t1yqKHJ2R2YCSVTGTf/qxp4Hq6aK
1KTHvd4F8xeSmQSZ
=gSMM
-END PGP SIGNATURE-

Bug#1059503: RFS: blanket/0.6.0-1 [RFP] -- listen to relaxing sounds

[Matthias Geiger]

On Wed, 27 Dec 2023 05:13:39 +0330 Danial Behzadi 
 wrote:

> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "blanket":
>
> * Package name : blanket
> Version : 0.6.0-1
> Upstream contact : Rafael Mardojai CM 
> * URL : 
> * License : GPL-3+
> * Vcs : 
> Section : utils
>
> The source builds the following binary packages:
>
> blanket - listen to relaxing sounds
>
> To access further information about this package, please visit the
> following URL:
>
> 

>

Hi Danial,

blankets sounds are licensed not under the GPL but different CC 
licenses. Furthermore, the train sound in 0.6.0 is still not dfsg (see 
https://github.com/rafaelmardojai/blanket/issues/297).


You can look into patching this maybe. Feel free to reach out if you 
have any questions.


best,


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



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059730: debian-policy: switch to new Debian-conform html theme for Sphinx/reST

[Sean Whitton]

Hello,

On Sat 30 Dec 2023 at 11:11pm +01, Holger Wansing wrote:

> Source: debian-policy
> Tags: patch
>
> Debian Policy has been migrated to restructedText / Sphinx.
> However, the current html theme is not conform with the look of the Debian 
> website.
>
> Bug #1053549 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053549)
> requests to create a new theme for Sphinx-based documents "to match our docs
> appearance with the Debian website colours etc."
>
> I have worked on this and a patch is attached, to fulfill this goal.
>
> An preview how the Debian Policy would look like with this theme can be found 
> at
> https://people.debian.org/~holgerw/sphinx-theme-for-debian/alabaster/debian-policy-manual/
>
> Please consider to apply this proposal.

We're actually in the middle of applying someone else's proposal, here: #915583.

Possibly some of your changes could be applied on top of that?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1059315: tinyxml: CVE-2023-34194 CVE-2023-40462 CVE-2023-40458

[Guilhem Moulin]

On Sat, 30 Dec 2023 at 21:02:16 +0100, Felix Geyer wrote:
> There are some minor changes staged in the salsa git repo. It would be good
> to include them as well. Feel free to push the patch to git and upload.
> Alternatively a merge request works as well of course.

Thanks for the fast response!  Tagged and uploaded.

Security team, if you agree with my assessment that CVE-2023-40462 is a
duplicate of CVE-2023-34194 (but for a separate project that embeds
libxml) and that CVE-2023-40458 is a duplicate of CVE-2021-42260 (but
for a separate project that embeds libxml), I can propose debdiffs for
bullseye and bookworm.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1059562: contributors.debian.org: some contributors are missing

[Pierre Gruet]

Hi,

Le 28/12/2023 à 20:47, Jonathan McDowell a écrit :

On Thu, Dec 28, 2023 at 02:07:25PM +0100, Pierre Gruet wrote:

I feel some contributors are missing from the page [0]. For instance, I (Pierre
Gruet ) have never been on it although I have contributed on a regular
basis since 2020.
I have no idea of the number of missing people.

I feel pointing this out now is relevant as we are currently [1] discussing
figures based on the contents of [0].


If I look at https://contributors.debian.org/contributor/pgt/ there are
no identifiers listed for you, but does know how to map your username to
your real name. Compare this to my page,
https://contributors.debian.org/contributor/noodles/, which lists email
addresses, fingerprints + logins. Have you tried adding some
associations there (and if you can't login, would you like me to?) -
without any listed it won't be able to match up incoming data.


Thanks for having looked at this bug report!

I have been able to follow your suggestions and indeed got added to the 
list of contributors.


I am now wondering whether we could be missing people (DD or not) as it 
seems the manipulations you described are needed in some cases. This is 
the sense of this bug report.




J.



Again, thanks a lot,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059730: debian-policy: switch to new Debian-conform html theme for Sphinx/reST

[Holger Wansing]

Source: debian-policy
Tags: patch

Debian Policy has been migrated to restructedText / Sphinx.
However, the current html theme is not conform with the look of the Debian 
website.

Bug #1053549 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053549)
requests to create a new theme for Sphinx-based documents "to match our docs 
appearance with the Debian website colours etc."

I have worked on this and a patch is attached, to fulfill this goal.

An preview how the Debian Policy would look like with this theme can be found at
https://people.debian.org/~holgerw/sphinx-theme-for-debian/alabaster/debian-policy-manual/

Please consider to apply this proposal.


BTW:
I have also requested to switch the developers-reference to the same
theme (https://salsa.debian.org/debian/developers-reference/-/merge_requests/47)
and the new release-notes for trixie are already using it
(https://www.debian.org/releases/testing/release-notes/index.en.html).


So long
Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
>From 1193ec1df212565fc5344a9a4bf31b65275cfc5b Mon Sep 17 00:00:00 2001
From: Holger Wansing 
Date: Sat, 30 Dec 2023 22:49:20 +0100
Subject: [PATCH] Switch to new theme for sphinx-based documentation

---
 policy/_static/openlogo-policy-manual.png | Bin 0 -> 15237 bytes
 policy/_static/openlogo-policy-manual.xcf | Bin 0 -> 7904 bytes
 policy/conf.py.in |  13 ++---
 3 files changed, 10 insertions(+), 3 deletions(-)
 create mode 100644 policy/_static/openlogo-policy-manual.png
 create mode 100644 policy/_static/openlogo-policy-manual.xcf

diff --git a/policy/_static/openlogo-policy-manual.png b/policy/_static/openlogo-policy-manual.png
new file mode 100644
index ..bd449f163feefe9e3c0b0f473acfe11591e275f5
GIT binary patch
literal 15237
zcmeHtWmKF?)^6kO8nhdCZ`|FT5L_E*oThOIPJrML0t9!L1PBCo3+@sm5G+U_K#+u7
zl5=L}%>Cwm-<`GY{WrZ}T(KYVWFk>59?TRKmfezytsQI4a8Wx(|PCAKs03ERJjMfGGEU1
zZPJbh-^YDh4fOBY$V=%of72y-s(9lM`l7$X`}F>8kc8XDTAPwrzQ7N#zpC`1N#h@eD5N`>;Y{FYZZMZPv}!Eo?l2
zH%vNpeGjgbce6hsk`taT-1E6^A1%69BtzpS?~;4pK5f0bA)@%SY^hUGR{EZp`R8o;
zTAk6s_N39xS)D}+;n<$v5K%CW-Obtc&>rVck?WJl>oT#S%k7C^zfPCcF3r8W(~h>*
zfJu9AdJ`_A#1RC%n)b~VaO
z?9^k~I+`_G+Yj3+@;cY4A?ivk0l)NRf`RM@be4BTpX!E>(kC3A6$*L2UmUV
zdARJ@P|7TR#^iN%Om(pN@oz|a6mpOoY7_8bLo~bm$S@l2%#?0WuJ861rAD0?!fzs5
zd3(0@_6Ye`4P7b{KB~cY;xmV|>Wn^EkOAe_#Q4cYftlRIT_j(@5sr#flsAt|%Of*-
z8Bo$am*V(}$+1SDGT(Oj=hp+|aP!J~I0%z%VqVN$2oD<|E|uqHQGf+t?^*XuVdI?N
z#8o*ec63!a5xaD3G{B3xPA*N0)7EO7Z)ZZ37yT(EF3^Q{
z%&;2Fw9ADoEZgPT=t#2Hw2xL+wazatSqMKsqOfhli1zyUY`AU=NnS<(u=`cdZ)m~g;TYRO$K&*TMh>LZG%Vo`QfnL
zS0%*Rx@FlnxbH(<;`rD_R?~R-G7=$l1ZjF(*e95uO~$ksc(86x{jgzs
z@~!;`$jM}?JrK?<=O~9Vue6dV6hC#1r+Isjyfx0}IzoRW_-$PXK^0%KBIt6HZQ5*g
zXz=*B|Tc
zxGnq%XwO$a^0mJIJS)PL`g!?LT46H!UBT_@_(7bP-XpQPM?X3}uP6qqbI94eBb?54
zp>MPo)2SCZ@n=BFZKYz?W@)P^F0ICyp_49BBith=PP+nfW^?`yti;6XxkNJ!=ylWn
zyo)VEEzeaJ5C`K0GOx2)O_a8HRSXlVlA*Y49)#Bu
z$fRWN%aREkzr7b9guSfhtSln(GWHH^LOH5_20H#$H{_a%KWG$>U#Gj-{%9d2Bz0A$
zBwd4$ZqDvz(0sLqebT)Gdvg<+y^VWu%e8m?FpsaJ3xB;K>QJ18oj$a98UUo`Py
z3;rKU%{e%a!(Sg#1b$itNSjt#Sb%5n(I|L8(M~Q
z0fbHSk-8O)!v2|S`Syb`#F_m*E$QWXIaxL8n2uwYOTr;GoE=40DqeEM*%+j#>}bAH
zaW}g?Inclp1JILG!Xz@|C>-e@@Pi{`xnm?90Y0$d4_0;Yy%>0Xw`yEk`v1#5{
zW3+IL%iwVmbr7^2ZSm(5@-k8UT^Ql7XfRC^ZLDc`nHu7BW-%b6kfvm-l4tan4%xd4aMe5|tvt
zd!#`MUsXz;HW@7Jd4W-PS}E3&8Ha2^R%Hij?-1t(HFY%C9OZp8R<~N@XKQmHV)qIz
z;kILqv?u`?+x`H|mgd%Y)e*}2X0LfPeT3Hp)u^Hk$aR7h?IGV3{K-)iC9T?HypyWM
zzffdJisA>>=n3s$@C=C>a_7_bWioNd^`-GgtJOT)0)17Ms5>8wor^)sZfBUJj;@7&

Bug#1059592: qhelpgenerator-qt5: emits .qch file attribute entries with unpredictable ordering

[James Addison]

Package: qhelpgenerator-qt5
Followup-For: Bug #1059592
Control: tags -1 fixed-upstream

Please note: it appears that a fix[1] that addresses this same problem is
already included in v6.5.0 of qttools.git upstream.

[1] - https://codereview.qt-project.org/c/qt/qttools/+/416699

Bug#1059631: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized

[James Addison]

Package: qhelpgenerator-qt5
Followup-For: Bug #1059631
X-Debbugs-Cc: mity...@debian.org
Control: forwarded -1 https://codereview.qt-project.org/c/qt/qttools/+/527972

Hi Dmitry,

On Sat, 30 Dec 2023 22:50:47, Dmitry wrote:
> Thank you for the patch!
>
> Any chance you can forward it to upstream Qt? See [1] for the details.

Yep, certainly - done.  Thanks!

Bug#1058720: slurm-wlm: CVE-2023-49933 CVE-2023-49935 CVE-2023-49936 CVE-2023-49937 CVE-2023-49938

[Gennaro Oliva]

Dear Salvatore,
I prepared an updated version of the slurm-wlm package for bookworm in
response to CVE-2023-49933/49935/49936/49937/49938

The package can be found here:

https://people.debian.org/~oliva/slurm-wlm-22.05.8-4+deb12u2

debdiff attached.

A new package for sid in under preparation.

Please let me know if I can be of any further help.

I take this opportunity to wish you and to all the security team members
a successful and prosperous new year.

Best regards,
-- 
Gennaro Oliva

On Fri, Dec 15, 2023 at 06:21:05AM +0100, Salvatore Bonaccorso wrote:
> Source: slurm-wlm
> Version: 23.02.6-1
> Severity: grave
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi Gennaro,
> 
> The following vulnerabilities were published for slurm-wlm.
> 
> CVE-2023-49933[0]:
> | An issue was discovered in SchedMD Slurm 22.05.x, 23.02.x, and
> | 23.11.x. There is Improper Enforcement of Message Integrity During
> | Transmission in a Communication Channel. This allows attackers to
> | modify RPC traffic in a way that bypasses message hash checks. The
> | fixed versions are 22.05.11, 23.02.7, and 23.11.1.
> 
> 
> CVE-2023-49935[1]:
> | An issue was discovered in SchedMD Slurm 23.02.x and 23.11.x. There
> | is Incorrect Access Control because of a slurmd Message Integrity
> | Bypass. An attacker can reuse root-level authentication tokens
> | during interaction with the slurmd process. This bypasses the RPC
> | message hashes that protect against undesired MUNGE credential
> | reuse. The fixed versions are 23.02.7 and 23.11.1.
> 
> 
> CVE-2023-49936[2]:
> | An issue was discovered in SchedMD Slurm 22.05.x, 23.02.x, and
> | 23.11.x. A NULL pointer dereference leads to denial of service. The
> | fixed versions are 22.05.11, 23.02.7, and 23.11.1.
> 
> 
> CVE-2023-49937[3]:
> | An issue was discovered in SchedMD Slurm 22.05.x, 23.02.x, and
> | 23.11.x. Because of a double free, attackers can cause a denial of
> | service or possibly execute arbitrary code. The fixed versions are
> | 22.05.11, 23.02.7, and 23.11.1.
> 
> 
> CVE-2023-49938[4]:
> | An issue was discovered in SchedMD Slurm 22.05.x and 23.02.x. There
> | is Incorrect Access Control: an attacker can modified their extended
> | group list that is used with the sbcast subsystem, and open files
> | with an unauthorized set of extended groups. The fixed versions are
> | 22.05.11 and 23.02.7.
> 
> 
> 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-49933
> https://www.cve.org/CVERecord?id=CVE-2023-49933
> [1] https://security-tracker.debian.org/tracker/CVE-2023-49935
> https://www.cve.org/CVERecord?id=CVE-2023-49935
> [2] https://security-tracker.debian.org/tracker/CVE-2023-49936
> https://www.cve.org/CVERecord?id=CVE-2023-49936
> [3] https://security-tracker.debian.org/tracker/CVE-2023-49937
> https://www.cve.org/CVERecord?id=CVE-2023-49937
> [4] https://security-tracker.debian.org/tracker/CVE-2023-49938
> https://www.cve.org/CVERecord?id=CVE-2023-49938
> 
> Regards,
> Salvatore
> 

-- 
Gennaro Oliva
diffstat for slurm-wlm-22.05.8 slurm-wlm-22.05.8

 changelog|7 
 patches/CVE-2023-49933-49936-49937-49938 |  717 +++
 patches/series   |1 
 3 files changed, 725 insertions(+)

diff -Nru slurm-wlm-22.05.8/debian/changelog slurm-wlm-22.05.8/debian/changelog
--- slurm-wlm-22.05.8/debian/changelog  2023-10-12 20:09:40.0 +0200
+++ slurm-wlm-22.05.8/debian/changelog  2023-12-25 09:26:16.0 +0100
@@ -1,3 +1,10 @@
+slurm-wlm (22.05.8-4+deb12u2) bookworm-security; urgency=medium
+
+  * Fix CVE-2023-49933, CVE-2023-49935, CVE-2023-49936, CVE-2023-49937,
+CVE-2023-49938 (Closes: #1058720) 
+
+ -- Gennaro Oliva   Mon, 25 Dec 2023 09:26:16 +0100
+
 slurm-wlm (22.05.8-4+deb12u1) bookworm-security; urgency=medium
 
   * Fix CVE-2023-41914
diff -Nru slurm-wlm-22.05.8/debian/patches/CVE-2023-49933-49936-49937-49938 
slurm-wlm-22.05.8/debian/patches/CVE-2023-49933-49936-49937-49938
--- slurm-wlm-22.05.8/debian/patches/CVE-2023-49933-49936-49937-49938   
1970-01-01 01:00:00.0 +0100
+++ slurm-wlm-22.05.8/debian/patches/CVE-2023-49933-49936-49937-49938   
2023-12-25 09:26:16.0 +0100
@@ -0,0 +1,717 @@
+Description: Fix CVE-2023-49933/49935/49936/49937/49938
+ Fix improper enforcement of message integrity during transmission in a
+ communication channel that allows attackers to modify RPC traffic in a way 
that
+ bypasses message hash checks. Fix a NULL pointer dereference that leads to 
denial of
+ service. Fix a double free that allows attackers to cause a denial of service 
or
+ possibly execute arbitrary code. Fix incorrect access control that can enable
+ an attacker to modify their extended group list that is used 

Bug#1059729: mutter: gnome-shell restart x11 session fails with window

[Alban Browaeys]

Package: mutter
Version: 45.2-2.1
Severity: normal


restarting gnome-shell x11 when a window is opened fails with:
"another compositing window manager is already running on screen"

Regression in restaring an x11 session
https://gitlab.gnome.org/GNOME/mutter/-/issues/2873


The merge request https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3329
fixes this cras (though as I told in 
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3329#note_1948823

Though I believe the initial code change that introduced this bug should be 
fixed too, code change in
https://gitlab.gnome.org/GNOME/mutter/-/commit/761a254e6f8b8643ce6530e85daf041f25edc683
which moved the window redirection in a X11_DISPLAY_OPENED signal handler
(signal that is emitted mulitple times including the one that bug on me, that
is after plugin init).
Though it could be this is already handled by the move of:
meta_x11_display_redirect_windows
from the meta-x11-display.c  on_x11_display_opened to the
on_x11_display_setup, leaving only meta_x11_display_redirect_windows
in the X11_DISPLAY_OPENED handler introduced in commit 761a254e.
Maybe leaving this call late after the plugin init is fine.

I attach the MR I applied to test that this MR indeed fixes the restart
issue.


Cheers,
Alban



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

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

Versions of packages mutter depends on:
ii  adwaita-icon-theme45.0-2
ii  gnome-settings-daemon-common  45.0-1
ii  gsettings-desktop-schemas 45.0-2
ii  libc6 2.37-12
ii  libgles2  1.7.0-1
ii  libglib2.0-0  2.78.3-1
ii  libmutter-13-045.2-2.1
ii  libwayland-client01.22.0-2.1
ii  mutter-common 45.2-2.1
ii  zenity4.0.0-1

mutter recommends no packages.

Versions of packages mutter suggests:
ii  gnome-control-center  1:45.2-1
ii  xdg-user-dirs 0.18-1

-- no debconf information
>From b7a1159a1ecd08b5e6aa1279fea84accf846b411 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jonas=20=C3=85dahl?= 
Date: Fri, 20 Oct 2023 15:44:29 +0800
Subject: [PATCH 1/4] x11-display: Make subwindow redirection call mode
 specific

This means that for X11 sessions we'll do it before any windows are
mapped, and before any plugin implementation is started. Doing it before
a plugin is started is important, because things that the plugin does
during startup can have consequences on how compositing on Xorg works.

For the Xwayland case, we'll do it relatively in the setup phase. It
appears to have been harmless to do it later in the post-opened signal,
but there is no harm in doing it as one of the earlier steps.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3089
---
 src/compositor/meta-compositor-x11.c | 2 ++
 src/wayland/meta-xwayland.c  | 1 +
 src/x11/meta-x11-display.c   | 1 -
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/compositor/meta-compositor-x11.c 
b/src/compositor/meta-compositor-x11.c
index 1ad3327ddf6..ce7bc1945ce 100644
--- a/src/compositor/meta-compositor-x11.c
+++ b/src/compositor/meta-compositor-x11.c
@@ -188,6 +188,8 @@ meta_compositor_x11_manage (MetaCompositor  *compositor,
 
   compositor_x11->have_x11_sync_object = meta_sync_ring_init (xdisplay);
 
+  meta_x11_display_redirect_windows (x11_display, display);
+
   return TRUE;
 }
 
diff --git a/src/wayland/meta-xwayland.c b/src/wayland/meta-xwayland.c
index e95ca564010..83f2fcb25d9 100644
--- a/src/wayland/meta-xwayland.c
+++ b/src/wayland/meta-xwayland.c
@@ -1170,6 +1170,7 @@ on_x11_display_setup (MetaDisplay *display,
 {
   MetaX11Display *x11_display = meta_display_get_x11_display (display);
 
+  meta_x11_display_redirect_windows (x11_display, display);
   meta_xwayland_init_dnd (x11_display);
   meta_xwayland_init_xrandr (manager, x11_display);
 }
diff --git a/src/x11/meta-x11-display.c b/src/x11/meta-x11-display.c
index 4e98203dd25..c634a71fb2a 100644
--- a/src/x11/meta-x11-display.c
+++ b/src/x11/meta-x11-display.c
@@ -301,7 +301,6 @@ on_x11_display_opened (MetaX11Display *x11_display,
MetaDisplay*display)
 {
   meta_display_manage_all_xwindows (display);
-  meta_x11_display_redirect_windows (x11_display, display);
 }
 
 static void
-- 
GitLab


>From 77fc07943c3171a5e7a047ca34af46feeca347c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jonas=20=C3=85dahl?= 
Date: Fri, 20 Oct 2023 17:03:31 +0800
Subject: [PATCH 

Bug#1059363: gbp-import-dsc crashes when changelog contains leap seconds ("Sun, 1 Jan 2006, 00:59:60 +0100")

[Gioele Barabucci]

On 30/12/23 11:27, Guido Günther wrote:

  from gbp.git.modifier import GitModifier   # noqa: F401
@@ -41,7 +42,11 @@ def rfc822_date_to_git(rfc822_date, fuzzy=False):
  >>> rfc822_date_to_git('So, 26 Feb 1998 8:50:00 +0100', fuzzy=True)
  '888479400 +0100'
  """
+rfc822_date_orig = rfc822_date
+rfc822_date = rfc822_date.replace(":60 ", ":59 ")
  d = dateutil.parser.parse(rfc822_date, fuzzy=fuzzy)
+if rfc822_date != rfc822_date_orig: # Handle leap seconds.
+d += datetime.timedelta(seconds=1)


That works. Could you add a line to the doctest in that function too so
we check for and don't break it on accident again. Otherwise I can do it
when applying the patch.


Hi Guido, I'll be happy to leave the doctest to you. :)

Thanks for accepting the patch.

PS: Beware: the indentation may be wrong.

Regards,

--
Gioele Barasbucci.

Bug#1059728: iputils: Fix debian/watch

[Petr Vorel]

Source: iputils
Version: Fix debian/watch
Severity: normal
Tags: patch

Dear Maintainer,

I'm adding a patch which fixes debian/watch file.

Kind regards,
Petr

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

Kernel: Linux 6.6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.utf8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 0526d3a441035152a12463b0d85d3aec4477e03d Mon Sep 17 00:00:00 2001
From: Petr Vorel 
Date: Sat, 30 Dec 2023 22:27:05 +0100
Subject: [PATCH 1/1] Fix debian/watch

Based on cups watch file
https://salsa.debian.org/printing-team/cups/-/blob/debian/main/debian/watch?ref_type=heads

Signed-off-by: Petr Vorel 
---
 debian/watch | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/debian/watch b/debian/watch
index 3742e10..fe916e2 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,6 @@
+# based on 
https://salsa.debian.org/printing-team/cups/-/blob/debian/main/debian/watch?ref_type=heads
 version=4
-opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz-$1.tar.xz"
-  https://github.com/iputils/iputils/tags \
-  (?:.*?/)?v?s(\d[\d.]*)\.tar\.gz debian uupdate
+opts="searchmode=plain,\
+pgpsigurlmangle=s/$/\.asc/" \
+https://api.github.com/repos/iputils/@PACKAGE@/releases \
+https://github.com/iputils/@PACKAGE@/releases/download/?[\d.]+/@PACKAGE@-@ANY_VERSION@@ARCHIVE_EXT@
-- 
2.43.0

Bug#1059438: ITP: ruby-deb-version, A port of "Debian Version" comparison function to Ruby

[Johannes Schauer Marin Rodrigues]

Hi,

On Mon, 25 Dec 2023 13:25:19 +0100 "Ajayi Olatunji O." 
 wrote:
> * Package name: ruby-deb-version
> 
> Version : 1.0.2
> Upstream Author : Nemo
> 
> * URL : https://github.com/captn3m0/ruby-deb-version#readme
> * License : MIT
> Programming Lang:Ruby
> Description : A port of Debian Version comparison to Ruby.
> 
>   This package is a build dependency for ruby-arr-pm, a package required
> in gitlab 16.6.2

since this seems to be a new parser, could you please provide an implementation
that tests ruby-deb-version against existing parsers to assure it is correct?

https://gitlab.mister-muffin.de/josch/debversioncomp

Let me know if you need any assistance. Unfortunately I do not speak Ruby, so I
cannot do this myself.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1057564: gnome-bluetooth3: FTBFS: failing tests

[Simon McVittie]

Control: unmerge 1057564 1058116
Control: reassign 1057564 python3-dbusmock 0.30.1-1
Control: retitle 1057564 python3-dbusmock: inconsistent signature for 
PairDevice causes gnome-bluetooth3 FTBFS
Control: forwarded 1057564 
https://github.com/martinpitt/python-dbusmock/issues/193
Control: affects 1057564 + src:gnome-bluetooth3
Control: reassign 1058116 gnome-bluetooth3 42.7-1
Control: retitle 1058116 gnome-bluetooth3: FTBFS: multiple tests time out with 
dbusmock >= 0.30.0
Control: forwarded 1058116 
https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/issues/142

On Sat, 30 Dec 2023 at 01:53:56 +, Simon McVittie wrote:
> On Tue, 05 Dec 2023 at 23:05:55 +0100, Santiago Vila wrote:
> > During a rebuild of all packages in unstable, your package failed to build:
> 
> This seems to be another casualty of recent updates to python-dbusmock.
> With python-dbusmock downgraded to 0.29.1-2, all tests pass and
> gnome-bluetooth3/42.7-1 builds successfully. With 0.30.0-2 (trixie)
> or 0.30.1-1 (sid), several tests time out.

I found a solution for the failure with dbusmock 0.30.0-2 and sent it
upstream to
https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/merge_requests/175, and
it works with dbusmock 0.30.0-2, but unfortunately one test still
fails with dbusmock 0.30.1-1. As far as I can see, that's genuinely a
dbusmock bug.

Because you can't clone a merged bug, I'm unmerging the two equivalent
FTBFS bug reports, and arbitrarily choosing to use:

- #1058116 to represent the gnome-bluetooth3 test failure with dbusmock
  0.30.0-2, which is genuinely a gnome-bluetooth3 bug, for which I've
  proposed a fix in
  https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/merge_requests/175.
  The symptom is that multiple tests time out.

- #1057564 to represent the gnome-bluetooth3 test failure with dbusmock
  0.30.1-1, even after applying GNOME/gnome-bluetooth!175, which as far
  as I can see is a dbusmock regression, reported as
  https://github.com/martinpitt/python-dbusmock/issues/193
  (I haven't tested a patch for this, I hope it's as simple as removing
  the obsolete 3rd argument in one call to PairDevice()).
  The symptom is that one test fails with
  "org.freedesktop.DBus.Error.InvalidArgs: Invalid arguments: Fewer
  items found in D-Bus signature than in Python arguments".

smcv

Bug#1059621: sphinx-common: dh_sphinxdoc fails to run: "search.html does not load searchindex.js"

[Drew Parsons]

On 2023-12-30 19:55, Dmitry Shachnev wrote:

Hi Drew!


Hi Dmitry :)

...
In lammps case, it looks like the search page is very unusual and 
relies
on Google's Custom Search Engine. So, in fact, it searches not in the 
local
documentation, but on docs.lammps.org website. This is exactly what 
Lintian

warning privacy-breach-google-cse is about.

I would recommend replacing upstream search.html with pristine version 
from

sphinx-rtd-theme [1] (that lammps theme is based on). Sphinx's default
search relies on source RST files (_sources), so you will also need to 
stop

removing them in doc/Makefile.


Thanks for the analysis.  I'll give it a try using the pristine 
serach.html, and see if I can get it to work.


I'll write (or close) this bug once I have results to report.

Drew

Bug#1059727: RFP: fragments -- GNOME BitTorrent client

[Logan Garcia]

Package: wnpp
Severity: wishlist

* Package name: fragments
* Version : 2.1.1
* Upstream Author : Felix Häcker
* URL : https://gitlab.gnome.org/World/Fragments
* License : gplv3
* Programming Lang: Rust
* Description : GNOME BitTorrent client

https://gitlab.gnome.org/World/Fragments

Fragments is an easy to use BitTorrent client. It can be used to 
transfer files via the BitTorrent protocol, such as videos, music or 
installation images for Linux distributions.

Bug#1059383: neomutt: conffiles not removed: /etc/neomuttrc.d/smime.rc /etc/neomuttrc.d/gpg.rc

[Carlos Henrique Lima Melara]

Control: tags -1 + confirmed

Hi, pabs.

On Sun, Dec 24, 2023 at 12:23:30PM +0800, Paul Wise wrote:
> The recent upgrade did not deal with obsolete conffiles properly.
> Please use the dpkg-maintscript-helper support provided by
> dh_installdeb to remove these obsolete conffiles on upgrade.
> 
> https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
> https://manpages.debian.org/man/1/dh_installdeb
> 
> This bug report brought to you by adequate:
> 
> https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
> 
> $ p=neomutt ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | grep 
> obsolete
> neomutt: obsolete-conffile /etc/neomuttrc.d/smime.rc
> neomutt: obsolete-conffile /etc/neomuttrc.d/gpg.rc
>  /etc/neomuttrc.d/smime.rc d25e75a8d59c32061f275fb823da07a1 obsolete
>  /etc/neomuttrc.d/gpg.rc fa01d034c3ba43eb0899bcca8e8b4903 obsolete

Yes, actually it was my bad. I'm following the instructions to fix it in
the next upload.

Thanks for reporting!

Cheers,
Charles


signature.asc
Description: PGP signature

Bug#1057555: Acknowledgement (system-wide neomuttrc causes warning at startup)

[Carlos Henrique Lima Melara]

Control: tags -1 + confirmed

Hi, Ryan.

On Tue, Dec 05, 2023 at 05:10:08PM -0500, Ryan Kavanagh wrote:
> Please see attached for a patch.

Yes, you are correct, the sort=threads is a legacy option now. I'm
fixing it in the patch we apply to change docs/neomuttrc.head.

Thanks for reporting and also sending a patch :-)

Cheers,
Charles


signature.asc
Description: PGP signature

Bug#1059726: jline3: CVE-2023-50572

[Salvatore Bonaccorso]

Source: jline3
Version: 3.3.1-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for jline3.

CVE-2023-50572[0]:
| An issue in the component GroovyEngine.execute of jline-groovy
| v3.24.1 allows attackers to cause an OOM (OutofMemory) error.

Now I'm not completely sure about the assessment. The code in 3.3.1
got some refactoring in laeter version and the upstream commit from
3.25.0 fixing the issue would not apply cleanly, but I'm not 100%
convinced htat the issue is only introduced later. Please double check
that. In case not, where was the issue introduced, can we pin-point
that?

Additionally, in case the above is asserted to be correct, are the
older series 2.x and 1.x as well affected?


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-50572
https://www.cve.org/CVERecord?id=CVE-2023-50572
[1] 
https://github.com/jline/jline3/commit/f3c60a3e6255e8e0c20d5043a4fe248446f292bb
[2] https://github.com/jline/jline3/issues/909

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1059315: tinyxml: CVE-2023-34194 CVE-2023-40462 CVE-2023-40458

[Felix Geyer]

Hi,

On 30.12.23 16:06, Guilhem Moulin wrote:

Control: tag -1 + patch

Hi,

I had a look at these issues for Buster (LTS).  Unfortunately the
upstream project appears to be inactive.

On Fri, 22 Dec 2023 at 14:50:57 +0100, Moritz Mühlenhoff wrote:

CVE-2023-34194[0]:
| StringEqual in TiXmlDeclaration::Parse in tinyxmlparser.cpp in
| TinyXML through 2.6.2 has a reachable assertion (and application
| exit) via a crafted XML document with a '\0' located after
| whitespace.


I attach a patch for this.  Felix, I can upload an NMU for sid if you'd
like.


Thanks for working on this!

There are some minor changes staged in the salsa git repo. It would be good
to include them as well. Feel free to push the patch to git and upload.
Alternatively a merge request works as well of course.

Cheers,
Felix

Bug#1059631: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized

[Dmitry Shachnev]

Hi James!

On Sat, Dec 30, 2023 at 05:12:52PM +, James Addison wrote:
> Package: qhelpgenerator-qt5
> Followup-For: Bug #1059631
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> My apologies: I had indeed misdiagnosed the problem here.
>
> The code that inserts into the SettingsTable, where the problem reported here
> manifests, is unrelated to the patch from bug #875847 - there is a separate
> check for SOURCE_CODE_EPOCH in the src/assistant/qhelpgenerator/main.cpp file.
>
> To test a fix, I used the following commands to replicate the problem:
>
>   $ SOURCE_DATE_EPOCH=1503951538 qhelpgenerator 
> examples/assistant/simpletextviewer/documentation/simpletextviewer.qhcp -o 
> foo.qch
>   $ TZ=GMT+8 SOURCE_DATE_EPOCH=1503951538 qhelpgenerator 
> examples/assistant/simpletextviewer/documentation/simpletextviewer.qhcp -o 
> bar.qch
>
> Please find attached a patch to address the problem.  Note that I decided to
> patch both SOURCE_CODE_EPOCH locations for consistency, despite the fact that
> only the main.cpp code site was confirmed affected.

Thank you for the patch!

Any chance you can forward it to upstream Qt? See [1] for the details.

I could forward it myself, but upstream requires signing the CLA so they will
not always accept a patch which is forwarded not by its author.

[1]: https://wiki.qt.io/Gerrit_Introduction

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1059677: libpod 3.0.1+dfsg1-3+deb11u5 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1059677 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: libpod
Version: 3.0.1+dfsg1-3+deb11u5

Explanation: fix incorrect handling of supplementary groups [CVE-2022-2989]

Bug#1056935: libde265 1.0.11-0+deb11u2 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1056935 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: libde265
Version: 1.0.11-0+deb11u2

Explanation: fix segmentation violation in the function 
decoder_context::process_slice_segment_header [CVE-2023-27102]; fix heap buffer 
overflow in the function derive_collocated_motion_vectors [CVE-2023-27103]; fix 
buffer over-read in pic_parameter_set::dump [CVE-2023-43887]; fix buffer 
overflow in the slice_segment_header function [CVE-2023-47471]

Bug#1059725: autopkgtest: isolation-machine test fails: nearly all tests in podman-init fail

[Paul Gevers]

Source: autopkgtest
Version: 5.31.2
Severity: important
User: debian...@lists.debian.org
Usertags: isolation-machine

Hi,

I recently added support for isolation-machine testing on ci.d.n and 
when I ran the autopkgtest of src:autopkgtest, it failed. It failed the 
podman-init test and out of 44 tests, only 2 passed 
(PodmanInitRunner.test_user and PodmanInitRunner.test_user_needs_root)


That's not very hopeful for the --podman --init flavor of 
autopkgtest-virt-docker.


Nearly all of them fail in the way quoted below, I haven't figured out 
where these log errors come from: """logger: send message failed: 
Operation not permitted""" while running `create-normal-user`.


Currently a full log lives here: 
https://ci.debian.net/data/autopkgtest/testing/amd64/a/autopkgtest/41372619/log.gz


The quote below is from me running the test inside a qemu testbed.

Paul

19:22:05 I: Started ./tests/autopkgtest 
PodmanInitRunner.test_skippable_success
19:22:06 O: test_skippable_success 
(__main__.PodmanInitRunner.test_skippable_success)

19:22:09 O: A skippable test succeeds ... FAIL
19:22:09 O:
19:22:09 O: 
==
19:22:09 O: FAIL: test_skippable_success 
(__main__.PodmanInitRunner.test_skippable_success)

19:22:09 O: A skippable test succeeds
19:22:09 O: 
--

19:22:09 O: Traceback (most recent call last):
19:22:09 O:   File 
"/tmp/autopkgtest.BNQ3Xt/build.9s6/real-tree/./tests/autopkgtest", line 
455, in test_skippable_success

19:22:09 O: self.assertEqual(code, 0, err)
19:22:09 O: AssertionError: 20 != 0 : autopkgtest: DBG: autopkgtest 
options: Namespace(override_control=None, only_tests=[], 
skip_tests=None, built_binaries=False, 
packages=['/tmp/autopkgtest.test.e19zee88/testpkg'], output_dir=None, 
logfile=None, summary=None, verbosity=2, setup_commands=[], 
setup_commands_boot=[], add_apt_sources=[], add_apt_releases=[], 
pin_packages=[], apt_pocket=[], apt_default_release=None, 
enable_apt_fallback=True, copy=[], env=[], ignore_restrictions=[], 
user=None, gainroot=None, shell_fail=False, shell=False, timeout=0, 
timeout_short=None, timeout_copy=None, timeout_install=None, 
timeout_test=None, timeout_build=None, timeout_factor=1.0, 
set_lang=None, auto_control=True, build_parallel=None, 
needs_internet='run', validate=False)
19:22:09 O: autopkgtest: DBG: virt-runner arguments: ['podman', 
'--init', 'autopkgtest/systemd/debian:testing']
19:22:09 O: autopkgtest: DBG: actions: [('unbuilt-tree', 
'/tmp/autopkgtest.test.e19zee88/testpkg', False)]

19:22:09 O: autopkgtest: DBG: build binaries: False
19:22:09 O: autopkgtest: DBG: testbed init
19:22:09 O: autopkgtest [19:22:06]: starting date and time: 2023-12-30 
19:22:06+

19:22:09 O: autopkgtest [19:22:06]: version 5.31.2
19:22:09 O: autopkgtest [19:22:06]: host host; command line: 
/usr/bin/autopkgtest -d --no-built-binaries 
/tmp/autopkgtest.test.e19zee88/testpkg -- podman --init 
autopkgtest/systemd/debian:testing

19:22:09 O: autopkgtest: DBG: got reply from testbed: ok
19:22:09 O: autopkgtest: DBG: testbed open, scratch=None
19:22:09 O: autopkgtest: DBG: sending command to testbed: open
19:22:09 O: autopkgtest: DBG: got reply from testbed: ok 
/tmp/autopkgtest-virt-docker.shared.3sui98zn/downtmp
19:22:09 O: autopkgtest: DBG: sending command to testbed: 
print-execute-command
19:22:09 O: autopkgtest: DBG: got reply from testbed: ok 
podman,exec,-i,2afe2dad7c01b2607f2184eb63ee03dee0172a73a104bee26d971fd1092a81df,env,-i,bash,-c,set%20-a%3B%20%5B%20-r%20/etc/environment%20%5D%20%26%26%20.%20/etc/environment%202%3E/dev/null%20%7C%7C%20true%3B%20%5B%20-r%20/etc/default/locale%20%5D%20%26%26%20.%20/etc/default/locale%202%3E/dev/null%20%7C%7C%20true%3B%20%5B%20-r%20/etc/profile%20%5D%20%26%26%20.%20/etc/profile%202%3E/dev/null%20%7C%7C%20true%3B%20set%20%2Ba%3B%22%24%40%22%3B%20RC%3D%24%3F%3B%20%5B%20%24RC%20%21%3D%20255%20%5D%20%7C%7C%20RC%3D253%3B%20set%20-e%3Bmyout%3D%24%28readlink%20/proc/%24%24/fd/1%29%3Bmyerr%3D%24%28readlink%20/proc/%24%24/fd/2%29%3Bmyout%3D%22%24%7Bmyout/%5B/%5C%5C%5B%7D%22%3B%20myout%3D%22%24%7Bmyout/%5D/%5C%5C%5D%7D%22%3Bmyerr%3D%22%24%7Bmyerr/%5B/%5C%5C%5B%7D%22%3B%20myerr%3D%22%24%7Bmyerr/%5D/%5C%5C%5D%7D%22%3BPS%3D%24%28ls%20-l%20/proc/%5B0-9%5D%2A/fd/%2A%202%3E/dev/null%20%7C%20sed%20-nr%20%27%5C%23%28%27%22%24myout%22%27%7C%27%22%24myerr%22%27%29%23%20%7B%20s%23%5E.%2A/proc/%28%5B0-9%5D%2B%29/.%2A%24%23%5C1%23%3B%20p%7D%27%7Csort%20-u%29%3BKILL%3D%22%22%3Bfor%20pid%20in%20%24PS%3B%20do%20%20%20%20%5B%20%24pid%20-ne%20%24%24%20%5D%20%26%26%20%5B%20%24pid%20-ne%20%24PPID%20%5D%20%7C%7C%20continue%3B%20%20%20%20KILL%3D%22%24KILL%20%24pid%22%3Bdone%3B%5B%20-z%20%22%24KILL%22%20%5D%20%7C%7C%20kill%20-9%20%24KILL%20%3E/dev/null%202%3E%261%20%7C%7C%20true%3Bexit%20%24RC,--

19:22:09 O: autopkgtest: DBG: sending command to testbed: capabilities
19:22:09 O: autopkgtest: DBG: got reply from testbed: ok 

Bug#1059420: linux-image-6.5.0-5-amd64: Sync or umount of USB task reproducibly hangs

[Salvatore Bonaccorso]

Source: linux
Source-Version: 6.6.8-1

On Sat, Dec 30, 2023 at 10:52:14AM -0800, Alison Chaiken wrote:
> On 2023-12-28 01:34, Salvatore Bonaccorso wrote:
> > Control: tags -1 + moreinfo
> > 
> > Hi Alison,
> > 
> > On Sun, Dec 24, 2023 at 09:29:01PM -0800, Alison Chaiken wrote:
> > > 
> > > 
> > > Package: src:linux
> > > Version: 6.5.13-1
> > > Severity: important
> > > 
> > > Dear Maintainer,
> > > 
> > > With two different USB sticks, "umount" and "sync" reproducibly
> > > trigger a
> > > hung
> > > task.  The USB sticks are of different brands, and one is new.   The
> > > first
> > > attempt produced the warning that is pasted just below.   Long story
> > > short,
> > > I
> > > believe that this system cannot burn a USB stick.   I cannot kill the
> > > currently
> > > running sync process and will have to again reboot.
> > 
> > And this is a regression from a previous kernel? I.e. from which one?
> > 6.5.y series won't be updted anymore and we have 6.6.8-1 in unstable.
> > Is the problem reproducible there?
> > 
> > Regards,
> > Salvatore
> 
> The problem is not recurring in linux-image-6.6.8-amd64.

Aright thanks for confirming. Altough it would be nice to find the
isolating fix, given we won't see any further updates on the 6.5.y
branch and 6.6.y will move to testing, let's close the bug with
6.6.8-1.

Regards,
Salvatore

Bug#1059420: linux-image-6.5.0-5-amd64: Sync or umount of USB task reproducibly hangs

[Alison Chaiken]

On 2023-12-28 01:34, Salvatore Bonaccorso wrote:

Control: tags -1 + moreinfo

Hi Alison,

On Sun, Dec 24, 2023 at 09:29:01PM -0800, Alison Chaiken wrote:



Package: src:linux
Version: 6.5.13-1
Severity: important

Dear Maintainer,

With two different USB sticks, "umount" and "sync" reproducibly 
trigger a

hung
task.  The USB sticks are of different brands, and one is new.   The 
first
attempt produced the warning that is pasted just below.   Long story 
short,

I
believe that this system cannot burn a USB stick.   I cannot kill the
currently
running sync process and will have to again reboot.


And this is a regression from a previous kernel? I.e. from which one?
6.5.y series won't be updted anymore and we have 6.6.8-1 in unstable.
Is the problem reproducible there?

Regards,
Salvatore


The problem is not recurring in linux-image-6.6.8-amd64.

Thanks,
Alison Chaiken

---
Alison Chaiken   ali...@she-devel.com
http://she-devel.com
If you don't keep up the running battle, you will cede the battlefield. 
-- Herb Sutter

Bug#1059621: sphinx-common: dh_sphinxdoc fails to run: "search.html does not load searchindex.js"

[Dmitry Shachnev]

Hi Drew!

On Fri, Dec 29, 2023 at 01:59:53PM +0100, Drew Parsons wrote:
> Package: sphinx-common
> Version: 7.2.6-3
> Severity: normal
> 
> I'm trying to run dh_sphinxdoc on new docs generated for lammps.
> But dh_sphinxdoc fails:
> 
> $ dh_sphinxdoc
> dh_sphinxdoc: error: debian/lammps-doc/usr/share/doc/lammps/html/search.html 
> does not load searchindex.js
> 
> with exit code 255.
> 
> Well no kidding, search.html really does not reference searchindex.js.
> Why is this causing dh_sphinxdoc to fail?  dh_sphinxdoc should be
> replacing existing .js references in the html files, not complaining
> about ones which are not there.
> 
> Adding an -Xsearch.html option does not fix the problem.

dh_sphinxdoc not only symlinks .js files, but also performs some sanity
checks. In particular, it checks stuff related to searchindex, search page
and _sources files.

In lammps case, it looks like the search page is very unusual and relies
on Google's Custom Search Engine. So, in fact, it searches not in the local
documentation, but on docs.lammps.org website. This is exactly what Lintian
warning privacy-breach-google-cse is about.

I would recommend replacing upstream search.html with pristine version from
sphinx-rtd-theme [1] (that lammps theme is based on). Sphinx's default
search relies on source RST files (_sources), so you will also need to stop
removing them in doc/Makefile.

If you don't want to do that, then disabling dh_sphinxdoc is probably fine,
because you don't need all of the Sphinx' JS functionality anyway.

[1]: 
https://sources.debian.org/src/sphinx-rtd-theme/2.0.0%2Bdfsg-1/sphinx_rtd_theme/search.html/

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1059722: fiona FTCBFS: unsatisfiable Build-Depends

[Sebastiaan Couwenberg]

Control: tags -1 patch.

Thanks for the patch, it's applied in git.

Kind Regards,

Bas

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

Bug#1059724: RFS: pygresql/1:6.0-1 [ITA] -- pygresql - PostgreSQL module for Python

[Dale Richards]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pygresql".


Currently orphaned, this is a dependency of another package I have in 
testing (python-dbutils) so I'm keen to keep it in good shape. I may 
move it to the Debian Python Team if my recent request to join is 
approved, but I'm happy to keep maintaining it in the meantime.


* Package name : pygresql
Version : 1:6.0-1
Upstream contact : PyGreSQL team
* URL : https://www.pygresql.org/index.html
* License : PostgreSQL, public-domain
* Vcs : https://salsa.debian.org/doge-tech/pygresql
Section : python

The source builds the following binary packages:

python3-pygresql - PostgreSQL module for Python3
python-pygresql-doc - Python Pygresql (common documentation)

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/pygresql/pygresql_6.0-1.dsc

Changes since the last upload:

pygresql (1:6.0-1) unstable; urgency=medium
.
* New upstream version 6.0
* New maintainer. (Closes: #623685)
* d/control: Add pyproject dependency.
* Update d/copyright for new version and maintainer
* Run upstream tests with autopkgtest.
* Bump standards version to 4.6.2, no changes needed.
* Use GitHub source in d/watch (the tarballs on PyPI appear to
be missing key documentation files.)

Many thanks,

Dale Richards (doge-tech)

Bug#1059639: please give possibility for custom ssh-agent parameters

[Marc Haber]

On Sat, Dec 30, 2023 at 06:01:35PM +, Colin Watson wrote:
> I think the simplest approach would be to allow invoking something like
> "/usr/lib/openssh/agent-launch start -- -t 1200", and pass the extra
> arguments on to ssh-agent.  You could then write a drop-in unit like
> this:
> 
>   [Service]
>   ExecStart=
>   ExecStart=/usr/lib/openssh/agent-launch start -- -t 1200
> 
> Would that be acceptable?

Yes, that is absolutely fine. Thank you.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1059691: molly-guard: impossible reboot

[Helmut Grohne]

Control: tags -1 + patch

On Sat, Dec 30, 2023 at 08:34:47AM +0100, molly-guard wrote:
> when trying to reboot the system molly-guard is unable to perform it's task:
> 
> root@server:~# reboot
> W: molly-guard: SSH session detected!
> Please type in hostname of the machine to reboot: server
> E: unsupported command: reboot.no-molly-guard
> root@server:~#

Seems like I didn't test this particular case. Thanks to Chris
Hofstaedler for pointing me at this. The crux is that reboot is a
symlink to halt. Thus when molly-guard forwards to the
reboot.no-molly-guard, the symlink points at halt which also is a
symlink and points at molly-guard. I didn't anticipate this recursion
and it probably is why molly-guard originally moved the tools to a
different directory.

What I can offer now is checking whether the resolved EXEC points back
at molly-guard (using test -ef) and when that happens resolve the
symlink once (not twice) to append the .no-molly-guard again. And then
it actually works. It just feels like we're piling ever more duct tape
onto it.

On the flip side, there really isn't much of an option. We can either
leave the diverted files in the same directory (as I changed it to) and
then we need to do this manual resolution of symlinks as the argv[0]
information is lost by the shell or we could revert back to the original
implementation where we'd leave the basename as is (except for
.usr-is-merged) and then still have to resolve the symlink manually,
because the relocated links may have become dangling.

Really there is one way to get out of this and that's renaming
/usr/lib/molly-guard to /usr/molly-guard. Then, all the symlinks resolve
correctly:

 * sysv: /usr/molly-guard/reboot -> halt = /usr/molly-guard/halt works
 * sysv: /usr/molly-guard/halt works
 * systemd: /usr/molly-guard/poweroff -> ../bin/systemctl =
   /usr/bin/systemctl works

This is a FHS violation though, so I think the best we can do is the
attached patch.

Helmut
diff --minimal -Nru molly-guard-0.8.3/debian/changelog 
molly-guard-0.8.3+nmu1/debian/changelog
--- molly-guard-0.8.3/debian/changelog  2023-12-22 23:23:25.0 +0100
+++ molly-guard-0.8.3+nmu1/debian/changelog 2023-12-30 16:58:24.0 
+0100
@@ -1,3 +1,10 @@
+molly-guard (0.8.3+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix with sysvinit. (Closes: #1059691)
+
+ -- Helmut Grohne   Sat, 30 Dec 2023 16:58:24 +0100
+
 molly-guard (0.8.3) unstable; urgency=medium
 
   * Upload to unstable
diff --minimal -Nru molly-guard-0.8.3/shutdown.in 
molly-guard-0.8.3+nmu1/shutdown.in
--- molly-guard-0.8.3/shutdown.in   2023-12-22 23:23:25.0 +0100
+++ molly-guard-0.8.3+nmu1/shutdown.in  2023-12-30 16:55:06.0 +0100
@@ -22,6 +22,16 @@
 exit 4
   fi
 fi
+if [ "$EXEC" -ef /usr/lib/molly-guard/molly-guard ]; then
+  # Symlink forwards to ourselves. Resolve!
+  LINKTARGET=$(readlink "$EXEC")
+  if ! EXEC=$(command -v "$LINKTARGET.no-molly-guard"); then
+if ! EXEC=$(command -v "$LINKTARGET.no-molly-guard.usr-is-merged"); 
then
+  echo "E: not a regular file $EXEC" >&2
+  exit 4
+fi
+  fi
+fi
 if [ ! -x $EXEC ]; then
   echo "E: not an executable: $EXEC" >&2
   exit 3

Bug#1059723: xsnow FTCBFS: fails running toascii

[Helmut Grohne]

Source: xsnow
Version: 1:3.7.6-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

xsnow fails to cross build from source, because it fails running toascii
with an Exec format error. Actually the failure is swept under the rug
and it only fails later on a negative array size as consequence. Such
continuing is a policy 4.6 violation and I encourage you to fix it.

That said, what really is the problem here is that toascii needs to be
built with the build architecture compiler. This is done with _FOR_BUILD
variants of the compiler. I'm attaching a patch, but you'll need a
dependency on autoconf-archive or update aclocal.m4 to use it.

Even with the patch applied, xsnow will not succeed in cross building as
it runs the build xsnow to generate its manual page. I don't have a good
solution to this. All options are annoying in some way:
 * Move the manual page to an Arch:all package.
 * Generate the manual page when creating a source package.
 * Make the cross build unreproducible and skip installing a manual page
   there.
 * Build-Depend on xsnow:native  and run that.
 * Actually write a manual page rather than generating it from help
   output.

Do you have a preference? In the mean time, please close this bug when
addressing just the toascii matter.

Helmut
--- xsnow-3.7.6.orig/configure.ac
+++ xsnow-3.7.6/configure.ac
@@ -114,6 +114,7 @@
 AC_PROG_CXX([c++ g++])
 AC_PROG_INSTALL
 AC_PROG_RANLIB
+AC_PROG_CC_FOR_BUILD
 
 LIBS="-lm"
 # Checks for header files.
--- xsnow-3.7.6.orig/src/Makefile.am
+++ xsnow-3.7.6/src/Makefile.am
@@ -88,10 +88,10 @@
 tarfile.inc: $(tarfile) $(TOASCII)
 	@echo "Converting tarfile:"
 	ls -l $(tarfile)
-	export CC="$(CC)"; export CFLAGS="$(CFLAGS)"; $(TOASCII) < $(tarfile) > $@ 
+	env CC="$(CC_FOR_BUILD)" CFLAGS="$(CFLAGS_FOR_BUILD)" $(TOASCII) < $(tarfile) > $@ 
 else
 	tarfile.inc: 
-	echo "No selfrep compiled in" | $(TOASCII) > $@
+	echo "No selfrep compiled in" | env "CC=$(CC_FOR_BUILD)" CFLAGS="$(CFLAGS_FOR_BUILD)" $(TOASCII) > $@
 endif
 
 

Bug#1059722: fiona FTCBFS: unsatisfiable Build-Depends

[Helmut Grohne]

Source: fiona
Version: 1.9.5-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

fiona cannot be cross built from source, because it has a number of
unsatisfiable Build-Depends. Fixing this is a longer effort, but there
is some low hanging fruit: Dependencies annotated  are only
used for testing and testing is usually disabled for cross builds, so
any thus annotated dependency becomes irrelevant to cross builds while
still being there for normal builds. Beware that wrong 
annotations are considered rc bugs since trixie. Anyway. I'm attaching a
patch to annotate those explicitly called out as test depends in
pyproject.toml and verified that skipping them does not alter the output
artifacts (via reproducible builds). Please close this bug when adding
 annotations even though that'll not make fiona cross
buildable.

Helmut
diff --minimal -Nru fiona-1.9.5/debian/changelog fiona-1.9.5/debian/changelog
--- fiona-1.9.5/debian/changelog2023-10-12 05:21:02.0 +0200
+++ fiona-1.9.5/debian/changelog2023-12-30 12:54:17.0 +0100
@@ -1,3 +1,11 @@
+fiona (1.9.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Annotate test dependencies .
+(Closes: #-1)
+
+ -- Helmut Grohne   Sat, 30 Dec 2023 12:54:17 +0100
+
 fiona (1.9.5-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru fiona-1.9.5/debian/control fiona-1.9.5/debian/control
--- fiona-1.9.5/debian/control  2023-08-30 17:21:17.0 +0200
+++ fiona-1.9.5/debian/control  2023-12-30 12:54:15.0 +0100
@@ -18,9 +18,9 @@
python3-click-plugins,
python3-cligj,
python3-munch,
-   python3-pytest,
+   python3-pytest ,
python3-setuptools,
-   python3-tz
+   python3-tz ,
 Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/debian-gis-team/fiona
 Vcs-Git: https://salsa.debian.org/debian-gis-team/fiona.git

Bug#1059721: proxychains-ng FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: proxychains-ng
Version: 4.16-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

proxychains-ng fails to cross build from source, because it rather
builds for the build architecture and thus fails dh_strip.
dh_auto_configure does not pass any cross tools to configure as it
expects an autoconf-style configure script, but this script doesn't
understand the --host flag. Rather we need to set the CC environment
variable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru proxychains-ng-4.16/debian/changelog 
proxychains-ng-4.16/debian/changelog
--- proxychains-ng-4.16/debian/changelog2023-08-13 21:36:31.0 
+0200
+++ proxychains-ng-4.16/debian/changelog2023-12-30 19:11:12.0 
+0100
@@ -1,3 +1,10 @@
+proxychains-ng (4.16-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Export CC for non-autoconf configure. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 30 Dec 2023 19:11:12 +0100
+
 proxychains-ng (4.16-3) unstable; urgency=medium
 
   * debian/control: Bump Standards-Version to 4.6.2.
diff --minimal -Nru proxychains-ng-4.16/debian/rules 
proxychains-ng-4.16/debian/rules
--- proxychains-ng-4.16/debian/rules2021-08-15 19:26:07.0 +0200
+++ proxychains-ng-4.16/debian/rules2023-12-30 19:11:10.0 +0100
@@ -5,9 +5,11 @@
 export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
 export DEB_LDFLAGS_MAINT_APPEND =
 
-export DPKG_EXPORT_BUILDFLAGS = 1
+DPKG_EXPORT_BUILDFLAGS = 1
+DPKG_EXPORT_BUILDTOOLS = 1
 include /usr/share/dpkg/buildflags.mk
 include /usr/share/dpkg/default.mk
+include /usr/share/dpkg/buildtools.mk
 
 %:
dh $@

Bug#1059720: xdiskusage FTCBFS: fails configuring during make distclean

[Helmut Grohne]

Source: xdiskusage
Version: 1.60-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

xdiskusage fails to cross build from source, because it fails to
configure. Looking closer, it fails configuring during make distclean
because it passes host compiler flags to a build compiler and that makes
the compiler unhappy. Sure enough, running configure during make
distclean is a bad idea. Consider applying the attached patch to fix
this.

Helmut
diff --minimal -Nru xdiskusage-1.60/debian/changelog 
xdiskusage-1.60/debian/changelog
--- xdiskusage-1.60/debian/changelog2023-08-29 18:15:33.0 +0200
+++ xdiskusage-1.60/debian/changelog2023-12-30 19:17:38.0 +0100
@@ -1,3 +1,10 @@
+xdiskusage (1.60-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Do not run configure during make distclean. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 30 Dec 2023 19:17:38 +0100
+
 xdiskusage (1.60-2) unstable; urgency=medium
 
   * debian/docs: Dropped, we use debian/xdiskusage.docs.
diff --minimal -Nru xdiskusage-1.60/debian/rules xdiskusage-1.60/debian/rules
--- xdiskusage-1.60/debian/rules2023-08-29 18:12:22.0 +0200
+++ xdiskusage-1.60/debian/rules2023-12-30 19:17:20.0 +0100
@@ -21,6 +21,9 @@
 %:
dh $@
 
+execute_before_dh_auto_clean:
+   touch makeinclude
+
 override_dh_auto_build:
# Explicitly pass flags
dh_auto_build -- \

Bug#1059719: cruft-ng FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: cruft-ng
Version: 0.9.60
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

cruft-ng fails to cross build from source, because it does not pass
cross tools to make. The easiest way of doing so - using dh_auto_build -
makes cruft-ng cross buildable. Consider applying the attached patch.

Helmut
diff --minimal -Nru cruft-ng-0.9.60/debian/changelog 
cruft-ng-0.9.60+nmu1/debian/changelog
--- cruft-ng-0.9.60/debian/changelog2023-12-19 00:49:41.0 +0100
+++ cruft-ng-0.9.60+nmu1/debian/changelog   2023-12-30 08:54:47.0 
+0100
@@ -1,3 +1,10 @@
+cruft-ng (0.9.60+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 30 Dec 2023 08:54:47 +0100
+
 cruft-ng (0.9.60) unstable; urgency=medium
 
   * add new rules for ulogd2, oss-compat,
diff --minimal -Nru cruft-ng-0.9.60/debian/rules 
cruft-ng-0.9.60+nmu1/debian/rules
--- cruft-ng-0.9.60/debian/rules2023-01-28 13:11:55.0 +0100
+++ cruft-ng-0.9.60+nmu1/debian/rules   2023-12-30 08:54:45.0 +0100
@@ -25,11 +25,11 @@
 override_dh_auto_build-arch:
./ruleset.sh $(DEB_DISTRIBUTION)
 ifeq ($(DEB_DISTRIBUTION),$(filter $(DEB_DISTRIBUTION),buster xenial focal))
-   make cruftold cpigsold
+   dh_auto_build -- cruftold cpigsold
mv cruftold cruft
mv cpigsold cpigs
 else
-   make cruft cpigs
+   dh_auto_build -- cruft cpigs
 endif
 
 

Bug#1059718: uthash FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: uthash
Version: 2.3.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

uthash fails to cross build from source, because it builds libut for the
build architecture and even adds host compiler flags that are not
understood by t he build compiler. The easiest way of fixing that -
using dh_auto_build - makes uthash cross buildable. Consider applying
the attached patch.

Helmut
diff --minimal -Nru uthash-2.3.0/debian/changelog uthash-2.3.0/debian/changelog
--- uthash-2.3.0/debian/changelog   2021-09-11 16:02:52.0 +0200
+++ uthash-2.3.0/debian/changelog   2023-12-30 13:57:04.0 +0100
@@ -1,3 +1,10 @@
+uthash (2.3.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 30 Dec 2023 13:57:04 +0100
+
 uthash (2.3.0-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru uthash-2.3.0/debian/rules uthash-2.3.0/debian/rules
--- uthash-2.3.0/debian/rules   2021-09-11 16:02:52.0 +0200
+++ uthash-2.3.0/debian/rules   2023-12-30 13:57:02.0 +0100
@@ -21,7 +21,7 @@
ln -s ../ libut/uthash
cp libut/Makefile.standalone libut/Makefile
# Build 'libut.a' static library
-   $(MAKE) -C libut
+   dh_auto_build --sourcedirectory libut
# Build documentation (use a temp build directory)
mkdir -p $(BUILD_DIR)/html
cp --archive doc/* $(BUILD_DIR)/html/

Bug#1058863: libqwt-qt5-dev: invalid conversion from ‘int’ to ‘QwtPlotLayout::Option’

[Gudjon I. Gudjonsson]

Hi Yadd

The changes are added to your patch below.
Please change the control file with dependency on
libqwt-qt6-dev

Regards
Gudjon 
Description: drop QWT
Author: Yadd 
Forwarded: not-needed
Last-Update: 2023-12-19

--- a/src/3rdparty/CMakeLists.txt
+++ b/src/3rdparty/CMakeLists.txt
@@ -21,9 +21,6 @@
 ###
 
 ADD_SUBDIRECTORY(function2)
-IF(OVITO_BUILD_APP AND NOT OVITO_QML_GUI)
-ADD_SUBDIRECTORY(qwt)
-ENDIF()
 IF(OVITO_BUILD_PLUGIN_PARTICLES)
 ADD_SUBDIRECTORY(ptm)
 ADD_SUBDIRECTORY(mwm_csp)
--- a/src/ovito/correlation/gui/CMakeLists.txt
+++ b/src/ovito/correlation/gui/CMakeLists.txt
@@ -24,7 +24,7 @@
 OVITO_STANDARD_PLUGIN(CorrelationFunctionPluginGui
 SOURCES
 SpatialCorrelationFunctionModifierEditor.cpp
-PRIVATE_LIB_DEPENDENCIES Qwt
+PRIVATE_LIB_DEPENDENCIES qwt-qt6
 PLUGIN_DEPENDENCIES CorrelationFunctionPlugin ParticlesGui
 GUI_PLUGIN
 HAS_NO_EXPORTS
--- a/src/ovito/particles/gui/CMakeLists.txt
+++ b/src/ovito/particles/gui/CMakeLists.txt
@@ -83,7 +83,7 @@
 export/vasp/POSCARExporterEditor.cpp
 export/xyz/XYZExporterEditor.cpp
 resources/particles_gui.qrc
-PRIVATE_LIB_DEPENDENCIES Qwt PolyhedralTemplateMatching
+PRIVATE_LIB_DEPENDENCIES qwt-qt6 PolyhedralTemplateMatching
 PLUGIN_DEPENDENCIES Particles StdObjGui
 PRECOMPILED_HEADERS ParticlesGui.h
 GUI_PLUGIN
--- a/src/ovito/stdmod/gui/CMakeLists.txt
+++ b/src/ovito/stdmod/gui/CMakeLists.txt
@@ -42,7 +42,7 @@
 CombineDatasetsModifierEditor.cpp
 ColorByTypeModifierEditor.cpp
 PLUGIN_DEPENDENCIES StdMod StdObjGui
-PRIVATE_LIB_DEPENDENCIES Qwt
+PRIVATE_LIB_DEPENDENCIES qwt-qt6
 PRECOMPILED_HEADERS StdModGui.h
 GUI_PLUGIN
 HAS_NO_EXPORTS
--- a/src/ovito/stdobj/gui/CMakeLists.txt
+++ b/src/ovito/stdobj/gui/CMakeLists.txt
@@ -39,7 +39,7 @@
 widgets/PropertySelectionComboBox.cpp
 widgets/DataTablePlotWidget.cpp
 PLUGIN_DEPENDENCIES StdObj
-LIB_DEPENDENCIES Qwt
+LIB_DEPENDENCIES qwt-qt6
 PRECOMPILED_HEADERS StdObjGui.h
 GUI_PLUGIN
 )
--- a/src/ovito/crystalanalysis/gui/modifier/GrainSegmentationModifierEditor.cpp
+++ b/src/ovito/crystalanalysis/gui/modifier/GrainSegmentationModifierEditor.cpp
@@ -33,7 +33,7 @@
 #include 
 #include "GrainSegmentationModifierEditor.h"

-#include <3rdparty/qwt/qwt_plot_zoneitem.h>
+#include 

 namespace Ovito::CrystalAnalysis {

diff --git a/src/ovito/stdobj/gui/widgets/DataTablePlotWidget.h b/src/ovito/stdobj/gui/widgets/DataTablePlotWidget.h
index 1630924..d2104ae 100755
--- a/src/ovito/stdobj/gui/widgets/DataTablePlotWidget.h
+++ b/src/ovito/stdobj/gui/widgets/DataTablePlotWidget.h
@@ -76,14 +76,14 @@ public:
 }

 void setAxisAutoScale(int axisId, bool on = true) {
-if(axisValid(axisId)) {
+if(isAxisValid(axisId)) {
 _axisAutoscaleEnabled[axisId] = on;
 QwtPlot::setAxisAutoScale(axisId, on);
 }
 }

 void setAxisScale(int axisId, double min, double max, double stepSize = 0) {
-if(axisValid(axisId)) {
+if(isAxisValid(axisId)) {
 _axisAutoscaleEnabled[axisId] = false;
 QwtPlot::setAxisScale(axisId, min, max, stepSize);
 }

Bug#1059393: ABACuS arXiv.2310.09977

[Colin Watson]

On Tue, Dec 26, 2023 at 12:03:36PM +0100, Boud Roukema wrote:
> There's a proposed mitigation for CVE-2023-51767 with ABACuS:
> 
> https://arxiv.org/abs/2310.09977
> 
> https://github.com/CMU-SAFARI/ABACuS

This is a proposal for redesigned memory controllers.  It isn't an
actionable mitigation at the level of OpenSSH.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1059717: phylonium: packaging help likely needed

[Étienne Mollier]

Source: phylonium
Version: 1.7-1
Severity: normal

I had a chat with Fabian Klötzl[1], and it appears they might
not be in position to work on the packaging front anymore
(although on upstream side, their support will still be
provided).  Additional uploaders would probably be needed so the
package does not risk becoming team orphaned.

[1]: https://github.com/EvolBioInf/andi/pull/17

For information,
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/3, please excuse my verbosity
   `-on air: Van der Graaf Generator - Aloft


signature.asc
Description: PGP signature

Bug#1059716: libdivsufsort: packaging help likely needed

[Étienne Mollier]

Source: libdivsufsort
Version: 2.0.1-5
Severity: normal

I had a chat with Fabian Klötzl[1], and it appears they might
not be in position to work on the packaging front anymore
(although on upstream side, their support will still be
provided).  Additional uploaders would probably be needed so the
package does not risk becoming team orphaned.

[1]: https://github.com/EvolBioInf/andi/pull/17

For information,
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/3, please excuse my verbosity
   `-on air: Van der Graaf Generator - Aloft


signature.asc
Description: PGP signature

Bug#1059715: libmurmurhash: packaging help likely needed

[Étienne Mollier]

Source: libmurmurhash
Version: 1.5-3
Severity: normal

I had a chat with Fabian Klötzl[1], and it appears they might
not be in position to work on the packaging front anymore
(although on upstream side, their support will still be
provided).  Additional uploaders would probably be needed so the
package does not risk becoming team orphaned.

[1]: https://github.com/EvolBioInf/andi/pull/17

For information,
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/3, please excuse my verbosity
   `-on air: Van der Graaf Generator - Aloft


signature.asc
Description: PGP signature

Bug#1059714: spaced: packaging help likely needed

[Étienne Mollier]

Source: spaced
Version: 1.2.0-201605+dfsg-3
Severity: normal

I had a chat with Fabian Klötzl[1], and it appears they might
not be in position to work on the packaging front anymore
(although on upstream side, their support will still be
provided).  Additional uploaders would probably be needed so the
package does not risk becoming team orphaned.

[1]: https://github.com/EvolBioInf/andi/pull/17

For information,
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/3, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Bug#1059713: linux-image-6.6.8-amd64-dbg: vmlinux-6.6.8-amd64 is stripped

[Alison Chaiken]

Package: linux-image-6.6.8-amd64-dbg
Version: 6.6.8-1
Severity: normal

Dear Maintainer,

Thanks for being a Debian volunteer.

In linux-image-6.6.8-amd64-dbg, the symbols for vmlinux are stripped, 
which
defeats the purpose of installing the package.   vmlinux was not 
stripped in the

trixie kernel dbg package:

$ file $(find /usr/lib/debug -name "vmlinux*" -type f)
/usr/lib/debug/boot/vmlinux-6.6.8-amd64:   ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), statically linked, 
BuildID[sha1]=144f4fcbb5d506514b6552bbd7c7d03fd7ddadde, stripped
/usr/lib/debug/boot/vmlinux-6.5.0-2-amd64: ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), statically linked, 
BuildID[sha1]=1921e63a5a6fcc611ae79e17f64ec58225ec23eb, with debug_info, 
not stripped


The modules provided with linux-image-6.6.8-amd64-dbg are not stripped:

$ file /usr/lib/debug/lib/modules/6.6.8-amd64/kernel/fs/ext4/ext4.ko
/usr/lib/debug/lib/modules/6.6.8-amd64/kernel/fs/ext4/ext4.ko: ELF 
64-bit LSB relocatable, x86-64, version 1 (SYSV), 
BuildID[sha1]=53e944d5e261d12c3beb55bcdfb85837c34c761b, with debug_info, 
not stripped


Hopefully it is not too much work to fix this minor error.

Thanks,
Alison Chaiken

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (500, 
'testing-debug')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.8-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Bug#1059712: orphan-sysvinit-scripts: dnscrypt-proxy init script not working out of the box

[Matthias Geiger]

On Sat, 30 Dec 2023 18:52:52 +0100 Matthias Geiger 
 wrote:

> Package: orphan-sysvinit-scripts
> Version: 0.15
> Severity: important
>
> Dear Maintainer,
>
> I installed dnscrypt-proxy alongside orphan-sysvinit-scripts. The
> service does not start however. The script included in o-s-s passes
> the -daemonize flag in line 44. This flag does not exist however on the
> sid version of dnscrypt-proxy, thus rendering the script broken.
> The systemd unit just calls this: "/usr/sbin/dnscrypt-proxy -config 
/etc/dnscrypt-proxy/dnscrypt-proxy.toml".

>
> Trying to reproduce that by amending the init script [see attachment]
> tries to start the service but fails because listen_addresses is empty.
> This is as far as I got trying to get the service to run.

attached script seems to work under openRC (copied from alpine and 
modified).


best,


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

#!/sbin/openrc-run
# Copyright 1999-2018 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

supervisor=supervise-daemon
command="/usr/sbin/dnscrypt-proxy"
command_args="-config /etc/dnscrypt-proxy/dnscrypt-proxy.toml"
pidfile="/run/${RC_SVCNAME}.pid"
command_background="yes"

depend() {
use net logger
provide dns
}

start_pre() {
checkpath -q -d -m 0775 -o "${command_user}" \
/var/cache/"${RC_SVCNAME}" \
/var/log/"${RC_SVCNAME}"
setcap cap_net_bind_service=+ep "${command}"
}



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059712: orphan-sysvinit-scripts: dnscrypt-proxy init script not working out of the box

[Matthias Geiger]

Package: orphan-sysvinit-scripts
Version: 0.15
Severity: important

Dear Maintainer,

I installed dnscrypt-proxy alongside orphan-sysvinit-scripts. The
service does not start however. The script included in o-s-s passes
the -daemonize flag in line 44. This flag does not exist however on the
sid version of dnscrypt-proxy, thus rendering the script broken.
The systemd unit just calls this: "/usr/sbin/dnscrypt-proxy -config 
/etc/dnscrypt-proxy/dnscrypt-proxy.toml".

Trying to reproduce that by amending the init script [see attachment]
tries to start the service but fails because listen_addresses is empty.
This is as far as I got trying to get the service to run.

best,

werdahias

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

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

Versions of packages orphan-sysvinit-scripts depends on:
ii  ucf  3.0043+nmu1

orphan-sysvinit-scripts recommends no packages.

orphan-sysvinit-scripts suggests no packages.

-- no debconf information
#!/bin/sh -e

### BEGIN INIT INFO
# Provides:  dnscrypt-proxy
# Required-Start:$remote_fs
# Required-Stop: $remote_fs
# Should-Start:  $network $syslog
# Should-Stop:   $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: Start and stop dnscrypt-proxy
# Description:   dnscrypt-proxy is Domain Name resolver with extra security
#features and enhanced privacy.
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin

. /lib/lsb/init-functions

DNSCRYPT_PROXY_BIN=/usr/sbin/dnscrypt-proxy
DNSCRYPT_PROXY_USER=_dnscrypt-proxy
DNSCRYPT_PROXY_PIDFILE=/run/dnscrypt-proxy.pid
DNSCRYPT_PROXY_CONF=/etc/dnscrypt-proxy/dnscrypt-proxy.toml
DNSCRYPT_PROXY_HOME=/run/dnscrypt-proxy
DNSCRYPT_PROXY_OPTIONS=""
DNSCRYPT_PROXY_LOCAL_ADDRESS="127.0.2.1:53"
DNSCRYPT_PROXY_RESOLVER_NAME=cisco

# Exit if the package is not installed
[ -x "${DNSCRYPT_PROXY_BIN}" ] || exit 0

[ -r "${DNSCRYPT_PROXY_CONF}" ] && . "${DNSCRYPT_PROXY_CONF}"


case "$1" in
start)
log_daemon_msg "Starting dnscrypt proxy service..." "dnscrypt-proxy"

[ -d "${DNSCRYPT_PROXY_HOME}" ] || \
mkdir -m 0555 "${DNSCRYPT_PROXY_HOME}"

if start_daemon -p "${DNSCRYPT_PROXY_PIDFILE}" ${DNSCRYPT_PROXY_BIN} \
--pidfile "${DNSCRYPT_PROXY_PIDFILE}" \
-config "${DNSCRYPT_PROXY_CONF}" \
$DNSCRYPT_PROXY_OPTIONS; then
if [ -x /sbin/resolvconf ]; then
echo "nameserver ${DNSCRYPT_PROXY_LOCAL_ADDRESS}" \
| cut -d ':' -f 1 \
| /sbin/resolvconf -a lo.dnscrypt-proxy
fi
log_success_msg
else
log_failure_msg
fi
;;

stop)
log_daemon_msg "Stopping dnscrypt proxy service..." "dnscrypt-proxy"

if [ -x /sbin/resolvconf ]; then
/sbin/resolvconf -d lo.dnscrypt-proxy
fi

if killproc -p "${DNSCRYPT_PROXY_PID}" ${DNSCRYPT_PROXY_BIN}
then
log_success_msg
else
log_failure_msg
fi
;;

restart|force-reload)
$0 stop
$0 start
;;

status)
ret=0
status_of_proc -p "${DNSCRYPT_PROXY_PIDFILE}" ${DNSCRYPT_PROXY_BIN} \
   dnscrypt-proxy 2>/dev/null || ret=$?
exit $ret
;;

*)
log_action_msg "Usage: /etc/init.d/dnscrypt-proxy 
{start|stop|restart|force-reload|status}"
exit 1
;;
esac

exit 0

Bug#1059639: please give possibility for custom ssh-agent parameters

[Colin Watson]

On Fri, Dec 29, 2023 at 07:38:40PM +0100, Marc Haber wrote:
> /usr/lib/openssh/agent-launch starts ssh-agent with a standard set of
> parameters. I'd like to have -t 1200 added to that.
> 
> Please consider adding a possibility to control the parameters that the
> ssh agent is being invoked, for example by having an override unit, or
> having /usr/lib/openssh/agent-launch read a user-specific configuration
> file.

My main concern is getting quoting right: ssh-agent does take some
options were quoting can be relevant, especially -P.  IMO that rules out
approaches such as environment variables (well, it's not impossible, but
it'd be a likely source of bugs).

I think the simplest approach would be to allow invoking something like
"/usr/lib/openssh/agent-launch start -- -t 1200", and pass the extra
arguments on to ssh-agent.  You could then write a drop-in unit like
this:

  [Service]
  ExecStart=
  ExecStart=/usr/lib/openssh/agent-launch start -- -t 1200

Would that be acceptable?

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1059387: exim4: CVE-2023-51766

[Salvatore Bonaccorso]

Hi Andreas,

On Sat, Dec 30, 2023 at 03:40:42PM +0100, Andreas Metzler wrote:
> On 2023-12-24 Salvatore Bonaccorso  wrote:
> > Source: exim4
> > Version: 4.97-2
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://bugs.exim.org/show_bug.cgi?id=3063
> [...]
> > The following vulnerability was published for exim4.
> 
> > CVE-2023-51766[0]:
> > | Exim through 4.97 allows SMTP smuggling in certain configurations.
> > | Remote attackers can use a published exploitation technique to
> > | inject e-mail messages that appear to originate from the Exim
> > | server, allowing bypass of an SPF protection mechanism. This occurs
> > | because Exim supports . but some other popular e-mail
> > | servers do not.
> 
> Hello Salvatore,
> 
> are you going to release a DSA (I can start preparing one) or should I
> aim for another stable update?

We certainly can do. We have not fully evaluated yet, but it can be
sensible that we do release via a DSA. For postfix there were enough
mitigation options to do, so that it was good enough to schedule the
update via a point release (and fasttrack still trough a SUA, given
the update was a bugfix release rebase).

How is the situation for exim4? Are there similar workarounds which
can be put in place e.g. like the postfix forbid_unauth_pipelining
option?

If there is no such way for exim4 then this lowers the bar for
releasing exim4 trough a DSA.

If so, will you work as well on the bullseye-security update?

Thanks as usual for your diligent work!

Regards,
Salvatore

Bug#1059711: reportbug: slurm-wlm-basic-plugins depends on libpmix-dev

[Jerome Benoit]

Package: slurm-wlm-basic-plugins
Version: 22.05.8-4+deb12u1
Severity: important

Dear Maintainer,

it appears that after a migration to Bookworm, slurmd failed to start
because it could not load libpmix.so which is provided by libpmix-dev .

hth,
Jerome


-- System Information:
Debian Release: 12.0
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-15-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages slurm-wlm-basic-plugins depends on:
ii  adduser  3.134
ii  libc62.36-9+deb12u3
ii  libdbus-1-3  1.14.10-1~deb12u1devuan1
ii  libhwloc15   2.9.0-1
ii  libjson-c5   0.16-2
ii  liblua5.1-0  5.1.5-9
ii  libmunge20.5.15-2
ii  libnuma1 2.0.16-1
ii  libyaml-0-2  0.2.5-1

Versions of packages slurm-wlm-basic-plugins recommends:
pn  slurm-wlm-plugins  

slurm-wlm-basic-plugins suggests no packages.

-- no debconf information

Bug#1059709: Reopen, not done at all.

[Phil Wyett]

reopen 1059709
thanks

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




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

Bug#1057833: sudo: [Hurd i386] upgrade from 1.9.14p2 to 1.9.15p2 dies with malloc error

[Marc Haber]

On Sat, Dec 30, 2023 at 10:09:10AM +0200, Martin-Éric Racine wrote:
> Sorry, I'm not. Just go ahead and upload. I'll let you know whether
> that fixed it or not.

Okay, sure. I'll ask upstream whether they want to do a release first. A
new upload this year is unlikely, I's also like the current unstable
version to migrate to testing first.

Greetings
Marc

Bug#1059631: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized

[James Addison]

Package: qhelpgenerator-qt5
Followup-For: Bug #1059631
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

My apologies: I had indeed misdiagnosed the problem here.

The code that inserts into the SettingsTable, where the problem reported here
manifests, is unrelated to the patch from bug #875847 - there is a separate
check for SOURCE_CODE_EPOCH in the src/assistant/qhelpgenerator/main.cpp file.

To test a fix, I used the following commands to replicate the problem:

  $ SOURCE_DATE_EPOCH=1503951538 qhelpgenerator 
examples/assistant/simpletextviewer/documentation/simpletextviewer.qhcp -o 
foo.qch
  $ TZ=GMT+8 SOURCE_DATE_EPOCH=1503951538 qhelpgenerator 
examples/assistant/simpletextviewer/documentation/simpletextviewer.qhcp -o 
bar.qch


Please find attached a patch to address the problem.  Note that I decided to
patch both SOURCE_CODE_EPOCH locations for consistency, despite the fact that
only the main.cpp code site was confirmed affected.
Description: helpgenerator: clear UTC offset to zero when reading 
SOURCE_DATE_EPOCH value
Author: James Addison 
Bug-Debian: https://bugs.debian.org/1059631

--- 
qttools-opensource-src-5.15.10.orig/src/assistant/help/qhelpcollectionhandler.cpp
+++ qttools-opensource-src-5.15.10/src/assistant/help/qhelpcollectionhandler.cpp
@@ -2202,8 +2202,10 @@ bool QHelpCollectionHandler::registerInd
 const QString sourceDateEpochStr = 
qEnvironmentVariable("SOURCE_DATE_EPOCH");
 bool ok;
 const qlonglong sourceDateEpoch = sourceDateEpochStr.toLongLong();
-if (ok && sourceDateEpoch < lastModified.toSecsSinceEpoch())
+if (ok && sourceDateEpoch < lastModified.toSecsSinceEpoch()) {
+lastModified.setOffsetFromUtc(0);
 lastModified.setSecsSinceEpoch(sourceDateEpoch);
+}
 }
 m_query->addBindValue(lastModified.toString(Qt::ISODate));
 if (!m_query->exec())
--- qttools-opensource-src-5.15.10.orig/src/assistant/qhelpgenerator/main.cpp
+++ qttools-opensource-src-5.15.10/src/assistant/qhelpgenerator/main.cpp
@@ -116,6 +116,7 @@ int generateCollectionFile(const QByteAr
 if (!config.filesToRegister().isEmpty()) {
 if (Q_UNLIKELY(qEnvironmentVariableIsSet("SOURCE_DATE_EPOCH"))) {
 QDateTime dt;
+dt.setOffsetFromUtc(0);
 
dt.setSecsSinceEpoch(qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH"));
 CollectionConfiguration::updateLastRegisterTime(helpEngine, dt);
 } else {

Bug#1059709: Do not retitle this RFS please.

[Phil Wyett]

retitle 1059709 RFS: filezilla/3.63.0-1+deb12u3 -- Full-featured graphical 
FTP/FTPS/SFTP client
owner 1059709 !
thanks

The 'bartm' script should not be retitling this RFS.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




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

Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Simon Josefsson]

Colin Watson  writes:

> On Sat, Dec 30, 2023 at 12:13:28AM +0100, Philipp Kern wrote:
>> On 29.12.23 11:30, Simon Josefsson wrote:
>> > SSH3 is a complete revisit of the SSH protocol, mapping its semantics on
>> > top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for
>> > secure channel establishment and the HTTP Authorization mechanisms for
>> > user authentication. Among others, SSH3 allows the following
>> > improvements:
>> 
>> I feel like SSH3 is an unfortunate name. The program claims "SSH3 stands for
>> the concatenation of SSH and H3." - well sure, but you're also reusing the
>> name of an existing protocol and bump its version. ssh-h3?
>
> I agree - as the Debian OpenSSH maintainer, I'm concerned that this will
> cause a new source of user confusion because people will think "ah,
> ssh3, that must be better than ssh" (which indeed seems to have been a
> deliberate marketing choice by this project) and not realize that it's a
> largely incompatible thing.  Not to mention the way that it parses
> OpenSSH configuration files, which may work today but I doubt OpenSSH
> offers any guarantees that it won't make changes that will break this
> independent parser in future.

I share these concerns, so I'll delay the upload for now.  I'm hoping
upstream will rename the project to something less confusing.

> I also feel that something security-critical like this that's labelled
> by upstream as "still experimental" probably shouldn't be in a Debian
> release.  Maybe it should be kept in Debian experimental for the time
> being?

Sounds good if nothing happens on the naming front in the next
weeks/months.  Let's wait and see a bit.

One alternative that was suggested was to call the package something
else in Debian.  'golang-ssh3'?  'go-ssh3'?  Still somewhat problematic
as long as the 'ssh3' name is in there.

/Simon


signature.asc
Description: PGP signature

Bug#1059710: [ruby-octokit 6 transition] Could not find 'o,ctokit' (~> 4.0, != 4.4.0) - did find: [octokit-6.1.1]

[Pirate Praveen]

Package: ruby-jekyll-github-metadata
Version: 2.15.0-1
Severity: important
User: debian-r...@lists.debian.org
Usertags: octokit6
Control: tags -1 fixed-upstream

ruby-jekyll-gist autopkgtest and rebuild fails with ruby-octokit 6 from 
experimental


 Could not find 'octokit' (~> 4.0, != 4.4.0) - did find: 
[octokit-6.1.1]  (Gem::MissingSpecVersionError)


Please update the package to make way for ruby-octokit 6 reupload to 
unstable.


It is already fixed upstream, so a simple upstream update would be 
enough to fix this


https://github.com/jekyll/github-metadata/blob/a605d047566c5cb22a7f549d9fad590724d1ba98/jekyll-github-metadata.gemspec

Bug#1059709: RFS: filezilla/3.63.0-1+deb12u3 -- Full-featured graphical FTP/FTPS/SFTP client

[Phil Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : filezilla
   Version  : 3.63.0-1+deb12u3
   Upstream contact : Tim Kosse 
 * URL  : https://filezilla-project.org/
 * License  : GPL-2+, permissive, BSD-like, CC0-1.0, MIT
 * Vcs  : https://salsa.debian.org/debian/filezilla
   Section  : net

The source builds the following binary packages:

  filezilla - Full-featured graphical FTP/FTPS/SFTP client
  filezilla-common - Architecture independent files for filezilla

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.63.0-1+deb12u3.dsc

Changes since the last upload:

 filezilla (3.63.0-1+deb12u3) bullseye; urgency=medium
 .
   * [CVE-2023-48795] - Add patch: CVE-2023-48795.patch.
 - Ref: https://security-tracker.debian.org/tracker/CVE-2023-48795

Note:

See approval: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059694

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




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

Bug#1059708: RFS: filezilla/3.52.2-3+deb11u1 -- Full-featured graphical FTP/FTPS/SFTP client

[Phil Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : filezilla
   Version  : 3.52.2-3+deb11u1
   Upstream contact : Tim Kosse 
 * URL  : https://filezilla-project.org/
 * License  : GPL-2+, permissive, BSD-like, CC0-1.0, MIT
 * Vcs  : https://salsa.debian.org/debian/filezilla
   Section  : net

The source builds the following binary packages:

  filezilla - Full-featured graphical FTP/FTPS/SFTP client
  filezilla-common - Architecture independent files for filezilla

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.52.2-3+deb11u1.dsc

Changes since the last upload:

 filezilla (3.52.2-3+deb11u1) bullseye; urgency=medium
 .
   * [CVE-2023-48795] - Add patch: CVE-2023-48795.patch.
 - Ref: https://security-tracker.debian.org/tracker/CVE-2023-48795

Note:

See approval: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059693

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




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

Bug#1059707: [ruby-octokit 6 transition] Could not find 'octokit' (~> 4.2) - did find: [octokit-6.1.1]

[Pirate Praveen]

Package: ruby-jekyll-gist
Version: 1.5.0-2
Severity: important
User: debian-r...@lists.debian.org
Usertags: octokit6
Control: forwarded -1 https://github.com/jekyll/jekyll-gist/issues/99

ruby-jekyll-gist autopkgtest fails with ruby-octokit 6 from experimental

 /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:317:in `to_specs': 
Could not find 'octokit' (~> 4.2) - did find: [octokit-6.1.1] 
(Gem::MissingSpecVersionError)


Please update the package to make way for ruby-octokit 6 reupload to 
unstable.


It is probably fine to just patch it and relax the requirements, as 
breaking changes in 5.0 and 6.0 are probably not affecting this package 
as explained in https://github.com/jekyll/jekyll-gist/issues/99

Bug#1059706: epics-base.pc is broken in epics-dev package

[Matwey V. Kornilov]

Package: epics-dev
Version: 7.0.7+dfsg1-5

Please note, that epics-base.pc file is installed into
/usr/share/pkg-config instead of /usr/share/pkgconfig and cannot be
found.
Also, content of epics-base.pc points to the nonexistent paths:

# standard variables
prefix=/build/reproducible-path/epics-base-7.0.7+dfsg1
exec_prefix=${prefix}
bindir=${prefix}/bin/linux-x86_64
libdir=${prefix}/lib/linux-x86_64

-- 
With best regards,
Matwey V. Kornilov

Bug#1050256: AppArmor breaks locking non-fs Unix sockets

[Salvatore Bonaccorso]

Hi John,

On Wed, Dec 06, 2023 at 10:47:45PM +0100, Salvatore Bonaccorso wrote:
> Hi Paul,
> 
> On Wed, Dec 06, 2023 at 10:21:02PM +0100, Paul Gevers wrote:
> > Hi,
> > 
> > On Mon, 18 Sep 2023 20:54:17 +0200 Paul Gevers  wrote:
> > > On 09-09-2023 13:06, Paul Gevers wrote:
> > > > All ci.d.n workers (except riscv64) now run the kernel from >
> > > bookworm-backports. systemd passes it's autopkgtest again in unstable, >
> > > testing and stable.
> > > 
> > > We're having issues [1] with the (backports and) unstable kernel on our
> > > main amd64 host, so we reverted back to the stable kernel for amd64.
> > > 
> > > Paul
> > > 
> > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052130
> > 
> > We're having issues [2] with the backports kernel on arm64 so our arm64,
> > armhf and armel hosts are back to the previous backports (arm64) kernel.
> > 
> > I'm slightly wondering if the next point release (on Saturday) will bring us
> > a fixed kernel for this issue? Given that this is the second time in 3
> > months we experience an issue with backports kernels, I think we'll have to
> > revert our hosts back to stable kernels for maintainability reasons.
> 
> TTBOMK, a backport of 1cf26c3d2c4c ("apparmor: fix apparmor mediating
> locking non-fs unix sockets") for the 6.1.y stable series has not
> landed yet so it's not included in the 6.1.64-1 update of the upcoming
> point release next weekend.
> 
> John, as it was said you are working on having the fix backpored to
> linux-6.1.y, is this still WIP?

John, did you had a chance to work on this backport for 6.1.y stable
upstream so we could pick it downstream in Debian in one of the next
stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix apparmor
mediating locking non-fs unix sockets") does not work, if not
havinging the work around e2967ede2297 ("apparmor: compute policydb
permission on profile load") AFAICS, so that needs a 6.1.y specific
backport submitted to sta...@vger.kernel.org ?

I think we could have people from this bug as well providing a
Tested-by when necessary. I'm not feeling confident enough to be able
to provide myself such a patch to sent to stable (and you only giving
an Acked-by/Reviewed-by), so if you can help out here with your
upstream hat on that would be more than appreciated and welcome :)

Thanks a lot for your work!

Regards,
Salvatore

Bug#1059700: opensmtpd dies with "pony express: smtpd: bind: Cannot assign requested address"

[Ryan Kavanagh]

Control: merge 976194 -1

Hi Harald,

On Sat, Dec 30, 2023 at 01:31:02PM +0100, Harald Dunkel wrote:
> Dec 30 12:57:38 dex06.hosting2.aixigo.de systemd[1]: Started 
> opensmtpd.service - OpenSMTPD SMTP server.
> Dec 30 12:57:38 dex06.hosting2.aixigo.de smtpd[130]: pony express: smtpd: 
> bind: Cannot assign requested address
> Dec 30 12:57:38 dex06.hosting2.aixigo.de smtpd[126]: smtpd: process pony 
> socket closed
>
> Please tell *which* address it cannot bind.

It used to be that smtpd -v would tell you which address smtpd tried to
bind, but I see that that's no longer the case on 7.4.0p1. It may still
work on your version.

I forwarded this bug upstream three years ago:
https://github.com/OpenSMTPD/OpenSMTPD/issues/1106

Duplicating the /etc/hosts entry no longer causes the bug to appear on
7.4.0p1. If it's not too much hassle, would you be willing to try
7.4.0p1 from Debian backports and let me know if you can still reproduce
this bug? It would at least help us narrow down if it's since been fixed
upstream.

Happy new year,
Ryan

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#1059705: bookworm-pu: package pluma/1.26.0-1+deb12u1

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pl...@packages.debian.org
Control: affects -1 + src:pluma

While prepare upload of pluma 1.26.1-1 a bookworm-pu upload has been
prepared cherry-picking various fixes from upstream (one mem leak issue,
one out-of-bounds write issue, one double extensions activation issue.

[ Reason ]
Backporting upstream fixes to pluma in bookworm.

[ Impact ]
The named issues remain unfixed in bookworm's pluma version.

[ Tests ]
Manually.

[ Risks ]
Regressions may occur for all pluma users.

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

[ Changes ]

+  * debian/patches:
++ Add 0001_pluma-plugins-engine-fix-memory-leak.patch,
+  0002_Fix-double-activation-of-extensions.patch and
+  0003_Fix-out-of-bounds-write.patch (cherry-picked from
+  v1.26.1). Fixing a mem leak issue, double extensions activation
+  and an out-of-bounds write issue.

[ Other info ]
None.
diff -Nru pluma-1.26.0/debian/changelog pluma-1.26.0/debian/changelog
--- pluma-1.26.0/debian/changelog   2021-12-13 10:55:21.0 +0100
+++ pluma-1.26.0/debian/changelog   2023-12-30 16:04:26.0 +0100
@@ -1,3 +1,14 @@
+pluma (1.26.0-1+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
++ Add 0001_pluma-plugins-engine-fix-memory-leak.patch,
+  0002_Fix-double-activation-of-extensions.patch and
+  0003_Fix-out-of-bounds-write.patch (cherry-picked from
+  v1.26.1). Fixing a mem leak issue, double extensions activation
+  and an out-of-bounds write issue.
+
+ -- Mike Gabriel   Sat, 30 Dec 2023 16:04:26 +0100
+
 pluma (1.26.0-1) unstable; urgency=medium
 
   [ Martin Wimpress ]
diff -Nru 
pluma-1.26.0/debian/patches/0001_pluma-plugins-engine-fix-memory-leak.patch 
pluma-1.26.0/debian/patches/0001_pluma-plugins-engine-fix-memory-leak.patch
--- pluma-1.26.0/debian/patches/0001_pluma-plugins-engine-fix-memory-leak.patch 
1970-01-01 01:00:00.0 +0100
+++ pluma-1.26.0/debian/patches/0001_pluma-plugins-engine-fix-memory-leak.patch 
2023-12-30 15:57:19.0 +0100
@@ -0,0 +1,39 @@
+From f46395ba21cc7fd14e1679ee6c4bc1c5cda81355 Mon Sep 17 00:00:00 2001
+From: rbuj 
+Date: Sat, 23 Oct 2021 03:54:46 +0200
+Subject: [PATCH 1/3] pluma-plugins-engine: fix memory leak
+
+Signed-off-by: Mike Gabriel 
+---
+ pluma/pluma-plugins-engine.c | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/pluma/pluma-plugins-engine.c b/pluma/pluma-plugins-engine.c
+index cf76313..cb5e2c4 100644
+--- a/pluma/pluma-plugins-engine.c
 b/pluma/pluma-plugins-engine.c
+@@ -57,6 +57,7 @@ static void
+ pluma_plugins_engine_init (PlumaPluginsEngine *engine)
+ {
+   GError *error = NULL;
++  char *user_plugins_dir;
+ 
+   pluma_debug (DEBUG_PLUGINS);
+ 
+@@ -89,9 +90,11 @@ pluma_plugins_engine_init (PlumaPluginsEngine *engine)
+   g_clear_error ();
+   }
+ 
++  user_plugins_dir = pluma_dirs_get_user_plugins_dir ();
+   peas_engine_add_search_path (PEAS_ENGINE (engine),
+-   pluma_dirs_get_user_plugins_dir (),
+-   pluma_dirs_get_user_plugins_dir ());
++   user_plugins_dir,
++   user_plugins_dir);
++  g_free (user_plugins_dir);
+ 
+   peas_engine_add_search_path (PEAS_ENGINE (engine),
+PLUMA_LIBDIR "/plugins",
+-- 
+2.39.2
+
diff -Nru 
pluma-1.26.0/debian/patches/0002_Fix-double-activation-of-extensions.patch 
pluma-1.26.0/debian/patches/0002_Fix-double-activation-of-extensions.patch
--- pluma-1.26.0/debian/patches/0002_Fix-double-activation-of-extensions.patch  
1970-01-01 01:00:00.0 +0100
+++ pluma-1.26.0/debian/patches/0002_Fix-double-activation-of-extensions.patch  
2023-12-30 15:59:49.0 +0100
@@ -0,0 +1,29 @@
+From e1d9f852ab4f9b1c162385f5aac1b598f563b17a Mon Sep 17 00:00:00 2001
+From: mbkma 
+Date: Tue, 23 Nov 2021 22:40:26 +0100
+Subject: [PATCH 2/3] Fix double activation of extensions
+
+Signed-off-by: Mike Gabriel 
+---
+ pluma/pluma-view.c | 9 ++---
+ 1 file changed, 2 insertions(+), 7 deletions(-)
+
+diff --git a/pluma/pluma-view.c b/pluma/pluma-view.c
+index 4a353e1..672cca8 100644
+--- a/pluma/pluma-view.c
 b/pluma/pluma-view.c
+@@ -413,11 +413,6 @@ on_notify_buffer_cb (PlumaView  *view,
+   "search_highlight_updated",
+   G_CALLBACK (search_highlight_updated_cb),
+   view);
+-
+-/* We only activate the extensions when the right buffer is set,
+- * because most plugins will expect this behaviour, and we won't
+- * change the buffer later anyway. */
+-peas_extension_set_call 

Bug#1059624: linux-image-6.1.0-16-amd64: aacraid abort request / SCSI hang after upgrade from 11.8 -> 12.4

[Samuel Wolf]

Hi Salvatore,

> Greg just queued it:
> https://lore.kernel.org/all/2023123013-dose-skirmish-27c2@gregkh/

queued sounds good, so happy there is a solution in sight.

The good thing about this bug is that we can use our "faulty" server
again, we thought the server had a hardware issue:
https://bugzilla.kernel.org/show_bug.cgi?id=217599#c55

Samuel

Bug#1059315: tinyxml: CVE-2023-34194 CVE-2023-40462 CVE-2023-40458

[Guilhem Moulin]

Control: tag -1 + patch

Hi,

I had a look at these issues for Buster (LTS).  Unfortunately the
upstream project appears to be inactive.

On Fri, 22 Dec 2023 at 14:50:57 +0100, Moritz Mühlenhoff wrote:
> CVE-2023-34194[0]:
> | StringEqual in TiXmlDeclaration::Parse in tinyxmlparser.cpp in
> | TinyXML through 2.6.2 has a reachable assertion (and application
> | exit) via a crafted XML document with a '\0' located after
> | whitespace.

I attach a patch for this.  Felix, I can upload an NMU for sid if you'd
like.

> CVE-2023-40462[1]:
> | The ACEManager component of ALEOS 4.16 and earlier does not
> | perform input sanitization during authentication, which could
> | potentially result in a Denial of Service (DoS) condition for
> | ACEManager without impairing other router functions. ACEManager
> | recovers from the DoS condition by restarting within ten seconds of
> | becoming unavailable.

AFAICT this is identical to CVE-2023-34194, but for ALEOS' ACEManager:

“TinyXML has not been supported for some years, but ALEOS still embeds its
source code directly into one of its libraries (libSWIALEOS.so).
[…]
For ACEmanager, the bug can be triggered similarly to CVE-2023-40458, as
shown below in Figure 20.  Unlike CVE-2023-40458, though, it crashes the
application, and since ACEmanager runs as a service, it will be
automatically restarted in a few seconds.  However, attackers can keep
sending malformed XML documents, prolonging the DoS indefinitely.  All
currently logged-in users are also immediately logged out.  Attackers do
not need to be authenticated to exploit the issue.” [0]

> CVE-2023-40458[2]:
> | Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability
> | in Sierra Wireless, Inc ALEOS could potentially allow a remote
> | attacker to trigger a  Denial of Service (DoS) condition for
> | ACEManager without impairing  other router functions. This condition
> | is cleared by restarting the  device.

AFAICT this issue is a duplicate of CVE-2021-42260.  §9.4 of the
report[0] reads that CVE-2023-40458 is triggered by a malformed XML
document containing 0xef (TIXML_UTF_LEAD_0) followed (p+1 or p+2) by
0x00, which is exactly what CVE-2021-42260 is about.

https://sourceforge.net/p/tinyxml/git/merge-requests/1/ , which is
included in buster-security, bullseye, bookworm and sid, evade the
infinite loop by blindly advancing the pointer.

Cheers,
-- 
Guilhem.

[0] https://www.forescout.com/resources/sierra21-vulnerabilities
From: Guilhem Moulin 
Date: Sat, 30 Dec 2023 14:15:54 +0100
Subject: Avoid reachable assertion via crafted XML document with a '\0'
 located after whitespace

Bug: https://www.forescout.com/resources/sierra21-vulnerabilities
Bug-Debian: https://bugs.debian.org/1059315
Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-34194
Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2023-40462
---
 tinyxmlparser.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/tinyxmlparser.cpp b/tinyxmlparser.cpp
index 8aa0dfa..1601962 100644
--- a/tinyxmlparser.cpp
+++ b/tinyxmlparser.cpp
@@ -1606,6 +1606,10 @@ const char* TiXmlDeclaration::Parse( const char* p, TiXmlParsingData* data, TiXm
 		}
 
 		p = SkipWhiteSpace( p, _encoding );
+		if ( !p || !*p )
+		{
+			break;
+		}
 		if ( StringEqual( p, "version", true, _encoding ) )
 		{
 			TiXmlAttribute attrib;


signature.asc
Description: PGP signature

Bug#1059704: gitlab: "number of sidekiq processes" check in gitlab-rake gitlab:check fails

[Ondrej Zary]

Package: gitlab
Version: 16.4.4+ds2-3~fto12+1
Severity: normal
X-Debbugs-Cc: z...@gsystem.sk

Dear Maintainer,
since upgrading from 16.2.8+ds1-6~fto12+1 to 16.4.4+ds2-3~fto12+1, sidekiq
check of "gitlab-rake gitlab:check" always fails becacuse it finds two cluster
processes instead of just one. It's probably caused by the extra /bin/sh
process started by gitlab-sidekiq.service.

# gitlab-rake gitlab:check
Attention: used pure ruby version of MurmurHash3

  ██ ██  █  ██  ███    ██ ██ ███    ██  ██ 
  ██ ██ ██   ██ ██   ██    ██ ██    ██ ██  
  ██  █  ██ ███ ██  ██ ██  ██ ██ ██ ██  ██ ██   ███ 
  ██ ███ ██ ██   ██ ██   ██ ██  ██ ██ ██ ██  ██ ██ ██    ██ 
   ███ ███  ██   ██ ██   ██ ██    ██ ██     ██  

**
  Your database has a single connection, and single connections were
  deprecated in GitLab 15.9 
https://docs.gitlab.com/ee/update/deprecations.html#single-database-connection-is-deprecated.

  Please add a :ci section to your database, following these instructions:
  
https://docs.gitlab.com/ee/install/installation.html#configure-gitlab-db-settings.
**

Checking GitLab subtasks ...

Checking GitLab Shell ...

GitLab Shell: ... GitLab Shell version >= 14.28.0 ? ... OK (14.28.0)
Running /usr/share/gitlab-shell/bin/gitlab-shell-check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Gitaly ...

Gitaly: ... default ... OK

Checking Gitaly ... Finished

Checking Sidekiq ...

Sidekiq: ... Running? ... yes
Number of Sidekiq processes (cluster/worker) ... 2/1
  Try fixing it:
  sudo systemctl restart gitlab-sidekiq.service
  Please fix the error above and rerun the checks.
...


# ps axu | grep sidekiq-cluster
gitlab   1144337  0.0  0.0   2576   908 ?Ss   15:29   0:00 /bin/sh -c 
GEM_PATH=$(gem env gempath); /usr/bin/bundle exec bin/sidekiq-cluster 
"$SIDEKIQ_QUEUES" -e $RAILS_ENV
gitlab   1144341  0.1  0.8 252800 49764 ?Sl   15:29   0:02 
bin/sidekiq-cluster * -e production
root 1153747  0.0  0.0   9000  2160 pts/2S+   15:56   0:00 grep 
sidekiq-cluster


-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (100, 
'bookworm-fasttrack'), (100, 'bookworm-backports-staging')
Architecture: amd64 (x86_64)

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

Versions of packages gitlab depends on:
ii  apache2 [httpd]2.4.57-2
ii  asciidoctor2.0.18-2
ii  bc 1.07.1-3+b1
ii  bundler2.3.15-2
ii  bzip2  1.0.8-5+b1
ii  dbconfig-pgsql 2.0.24
ii  debconf [debconf-2.0]  1.5.82
ii  fonts-font-awesome [node-font-awesome  5.0.10+really4.7.0~dfsg-4.1
]
ii  gitlab-common  16.4.4+ds1-4~bpo12+1
ii  gitlab-workhorse   16.4.4+ds2-3~fto12+1
ii  katex [node-katex] 0.16.4+~cs6.1.0-1
ii  libjs-bootstrap4 [node-bootstrap]  4.6.1+dfsg1-4
ii  libjs-pdf [node-pdfjs-dist]2.14.305+dfsg-2
ii  libjs-popper.js [node-popper.js]   1.16.1+ds-6
ii  libruby3.1 [ruby-rexml]3.1.2-7
ii  libssl-dev 3.0.11-1~deb12u2
ii  lsb-base   11.6
ii  node-autosize  4.0.4~dfsg1+~4.0.0-2
ii  node-axios 1.2.1+dfsg-1
ii  node-babel-loader  9.1.0-3
ii  node-babel-plugin-lodash   3.3.4+~cs2.0.1-6
ii  node-babel77.20.15+ds1+~cs214.269.168-3+deb12u1
ii  node-brace-expansion   2.0.1-2
ii  node-cache-loader  4.1.0+~cs2.0.0-4
ii  node-clipboard 2.0.11+ds+~cs9.6.11-1
ii  node-compression-webpack-plugin10.0.0-2
ii  node-copy-webpack-plugin   11.0.0-3
ii  node-core-js   3.26.1-3
ii  node-core-js-compat3.26.1-3
ii  node-core-js-pure  3.26.1-3
ii  node-cron-validator1.3.1-3
ii  node-css-loader6.7.2+~cs14.0.11-1
ii  node-d35.16.0-10
ii  node-d3-selection  1.4.0-8
ii  node-dateformat5.0.3-5
ii  node-dompurify 2.4.1+dfsg+~2.4.0-1
ii  

Bug#1059387: exim4: CVE-2023-51766

[Andreas Metzler]

On 2023-12-24 Salvatore Bonaccorso  wrote:
> Source: exim4
> Version: 4.97-2
> Severity: important
> Tags: security upstream
> Forwarded: https://bugs.exim.org/show_bug.cgi?id=3063
[...]
> The following vulnerability was published for exim4.

> CVE-2023-51766[0]:
> | Exim through 4.97 allows SMTP smuggling in certain configurations.
> | Remote attackers can use a published exploitation technique to
> | inject e-mail messages that appear to originate from the Exim
> | server, allowing bypass of an SPF protection mechanism. This occurs
> | because Exim supports . but some other popular e-mail
> | servers do not.

Hello Salvatore,

are you going to release a DSA (I can start preparing one) or should I
aim for another stable update?

TIA, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


signature.asc
Description: PGP signature

Bug#1059703: binutils: Please drop nocheck override for powerpc and sparc64

[John Paul Adrian Glaubitz]

Source: binutils
Version: 2.41.50.20231227-1
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hello!

The debian/rules file for binutils currently overrides the nocheck build
option with the following code snippet:

ifneq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
  # override buildd admins to run the testsuite anyway ...
  ifeq (,$(filter $(DEB_HOST_ARCH), m68k powerpc sh4 sparc64))
with_check := disabled through DEB_BUILD_OPTIONS
  endif
endif

Since both the powerpc and sparc64 buildds don't build with "nocheck" there
is no need to override it. It only annoys porters when they want to build
binutils locally with the testsuite disabled.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1059702: apparmor-profiles: Firefox profile should confine firefox-esr

[Sam Lee]

Package: apparmor-profiles
Version: 3.0.8-3
Severity: wishlist

The Firefox profile 'usr.lib.firefox.firefox' does not confine the
firefox-esr binary (/usr/lib/firefox-esr/firefox-esr). The AppArmor
profile for Firefox should include support for the firefox-esr binary,
since firefox-esr is the default Firefox for Debian stable.


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

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

Versions of packages apparmor-profiles depends on:
ii  apparmor  3.0.8-3

apparmor-profiles recommends no packages.

apparmor-profiles suggests no packages.

-- no debconf information

Bug#833278: firefox-esr: lack of apparmor profile

[Sam Lee]

On Wed, 4 Dec 2019 02:15:16 +0300 dinar qurbanov  wrote:
> it is in apparmor-profiles package:
> https://packages.debian.org/stretch/all/apparmor-profiles/filelist

For Debian bookworm, an AppArmor profile is also available in the
apparmor-profiles package, but that profile is obsolete. It confines
binaries that match /usr/lib/firefox{,-[0-9]*}/firefox{,*[^s][^h]}
[1], which would not match the current location of the firefox-esr
binary which is at /usr/lib/firefox-esr/firefox-esr.

Debian should definitely ship an AppArmor profile with the firefox-esr
package. Web browsers are widely installed and have lots of security
vulnerabilities.

[1]: 
https://salsa.debian.org/apparmor-team/apparmor/-/blob/debian/3.0.8-3/profiles/apparmor/profiles/extras/usr.lib.firefox.firefox#L21

Bug#1059631: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized

[James Addison]

Package: qhelpgenerator-qt5
Followup-For: Bug #1059631
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

On Fri, 29 Dec 2023 15:30:58, I wrote:
> Inspecting the patch from #875847 and the values that appear in the diffoscope
> output from the build logs: the SOURCE_DATE_EPOCH value of the build is used,
> as expected, to improve the reproducibility of the build.  It takes the value
> of the most recent Debian changelog entry.
>
> However: the patch mutates an existing QT QDateTime instance (last_modified) 
> to
> store the seconds-since-epoch value -- without specifying a timezone for the
> value.
...
> My sense is that the LastRegisterTime column value is probably intended to be
> stored in UTC; it may be sufficient to set the timezone of the last_modified
> instance to UTC -- making careful to ensure that it is indeed a _set_ timezone
> operation and not a _translate_ timezone operation.

In hindsight: I think I've misunderstood some of the details here.  If the root
cause is indeed a non-UTC timezone on the last_modified object, then maybe it
does in fact make sense to translate that object's value into UTC -- because
that would mean that we the date-string we bind is always UTC-based, regardless
of whether  SOURCE_DATE_EPOCH is set.

Related, though: I also don't yet understand why the date string that appears
in the INSERT statement does not include a timezone offset (+1200, for
example).  My reading of the QT documentation[1] is that a timezone offset will
be included in the formatted string for non-UTC date+time objects.. I'll do
some more investigation.

[1] - https://doc.qt.io/qt-5/qt.html#DateFormat-enum

Bug#1058522: (no subject)

[Lev Lamberov]

Hi Jeremy,

Сб 30 дек 2023 @ 11:28 Jeremy Sowden :

> On 2023-12-24, at 10:00:26 +0500, Lev Lamberov wrote:
>> Чт 21 дек 2023 @ 15:06 Jeremy Sowden:
>> > On 2023-12-21, at 11:21:48 +, Jeremy Sowden wrote:
>> >> On 2023-12-21, at 11:10:28 +0500, Lev Lamberov wrote:
>> >> > Since I cannot reproduce the bug, I'm downgrading the severity of
>> >> > this bug report.
>> >> 
>> >> I cloned the git repo, ran `gbp buildpackage --git-pbuilder` and
>> >> reproduced it (log attached).  I'll see if I can work out what's going
>> >> on.
>> 
>> Thanks for your input. I double checked this bug report both under
>> git-pbuilder and sbuild. E. g., here is the sbuild environment:
>> 
>> $ sudo sbuild-shell unstable
>> I: /bin/sh
>> # bash
>> (unstable-amd64-sbuild)root@shakva:/# du --version
>> du (GNU coreutils) 9.4
>> Copyright (C) 2023 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later 
>> .
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> 
>> Written by Torbjörn Granlund, David MacKenzie, Paul Eggert,
>> and Jim Meyering.
>> (unstable-amd64-sbuild)root@shakva:/# exit
>> 
>> But I still cannot reproduce the bug. Don't know...
>
> First things first, do you see the following in your chroot?
>
>   (unstable-amd64-sbuild)root@ulthar:~# d=$(mktemp -d)
>   (unstable-amd64-sbuild)root@ulthar:~# du -sb $d
>   0   /tmp/tmp.qay80HZ09w
>
> This is the cause of the problem.  If your du is not reporting zero size
> for an empty directory, that would explain the discrepancy and the rest
> of this e-mail is irrelevant. :)

It is zero for me.

I was able to reproduce the bug in a clean schroot environment. Will
figure out what to do next in the coming days.

Happy New Year!

Cheers!
Lev

Bug#1059701: sccache - upcoming rust-object update

[Peter Michael Green]

Package: sccache
Version: 0.7.4-3

I have been working on an update of rust-backtrace and it's
dependencies, backtrace itself is not semver breaking, but
several of it's dependencies are.

backtrace 0.3.68 -> 0.3.69
addr2line 0.20.0 -> 0.21.0
fallible-iterator 0.2.0 -> 0.3.0
gimli 0.27.3 -> 0.28.1
object 0.31.1 -> 0.32.1

Your package depends on object, I have looked at the
upstream changelog and didn't see anything too scary
and I've built your package with the dependency bumped,
the package has no autopkgtests.

If you want to do further testing the new version of
the packages are available in experimental.

Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Colin Watson]

On Sat, Dec 30, 2023 at 12:13:28AM +0100, Philipp Kern wrote:
> On 29.12.23 11:30, Simon Josefsson wrote:
> > SSH3 is a complete revisit of the SSH protocol, mapping its semantics on
> > top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for
> > secure channel establishment and the HTTP Authorization mechanisms for
> > user authentication. Among others, SSH3 allows the following
> > improvements:
> 
> I feel like SSH3 is an unfortunate name. The program claims "SSH3 stands for
> the concatenation of SSH and H3." - well sure, but you're also reusing the
> name of an existing protocol and bump its version. ssh-h3?

I agree - as the Debian OpenSSH maintainer, I'm concerned that this will
cause a new source of user confusion because people will think "ah,
ssh3, that must be better than ssh" (which indeed seems to have been a
deliberate marketing choice by this project) and not realize that it's a
largely incompatible thing.  Not to mention the way that it parses
OpenSSH configuration files, which may work today but I doubt OpenSSH
offers any guarantees that it won't make changes that will break this
independent parser in future.

I also feel that something security-critical like this that's labelled
by upstream as "still experimental" probably shouldn't be in a Debian
release.  Maybe it should be kept in Debian experimental for the time
being?

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1059618: ITP: ssh3 -- faster and rich secure shell using HTTP/3

[Simon Josefsson]

Packaging of SSH3 is available here:

https://salsa.debian.org/go-team/packages/ssh3
https://salsa.debian.org/jas/ssh3/

Thanks to the Salsa CI/CD pipeline there is an aptly repository
available for easy testing, if anyone would like to experiment or help.

Below you can find a snippet how you can test the SSH3 client and server
via Debian packages, for password and public key authentication, in a
safe container using podman.  I have only tested this on my laptop that
runs Trisquel, but should hopefully be portable.

I am delaying upload to Debian for a while to see if upstream reaches a
conclusion around naming.  I think the name 'ssh3' is unfortunate and
distracts from the effort. See:
.

/Simon

sudo apt install podman
podman run -it --hostname myhost.example --rm debian:unstable
cd
apt update
apt dist-upgrade -y
apt install -y ca-certificates
echo "deb [trusted=yes] 
https://salsa.debian.org/jas/ssh3/-/jobs/5094673/artifacts/raw/aptly unstable 
main" | tee /etc/apt/sources.list.d/ssh3.list
apt update
apt install -y ssh3

apt install -y ssl-cert # creates snakeoil key/cert

passwd # set a test password for 'root' e.g. 'foo'

ssh3-server -cert /etc/ssl/certs/ssl-cert-snakeoil.pem -key 
/etc/ssl/private/ssl-cert-snakeoil.key -enable-password-login -url-path /myurl 
-v &

ssh3 -v -insecure -use-password myhost.example/myurl
# type 'foo' at the prompt, and on successful connection type 'exit' to log out

apt install -y openssh-client # for ssh-keygen
ssh-keygen -t ed25519 -P "" -f /root/.ssh/id_ed25519
cat /root/.ssh/id_ed25519.pub > /root/.ssh3/authorized_identities
ssh3 -v -insecure -privkey /root/.ssh/id_ed25519 myhost.example/myurl
# on successful connection type 'exit' to log out


signature.asc
Description: PGP signature

Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)

[Alastair McKinstry]

On 27/12/2023 21:30, Drew Parsons wrote:
Hi Alistair, given the complexity around hacking openmpi to 
accommodate placing the mod files under /usr/include, I'm starting to 
wonder whether it's the best way of resolving Bug#1058526 in the first 
place.


I did it bit of background reading on the fortran mod files. There's a 
fair bit of dissent about them, and no consensus on a proper 
location.  e.g. https://fortranwiki.org/fortran/show/Library+distribution
The files are binary dependent (and compiler version dependent), and 
not clear that /usr/include is the best place for them anyway.


mpich seems to be fine placing them in 
/usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15/mpich, and openmpi 
seemed to be happy enough doing the same up until Bug#1058526.


Is there a different way of resolving Bug#1058526 without moving the 
mod files to /usr/include?


Drew


I had altered FMODDIR from /usr/lib/ to /usr/include to match what 
appears to be most conventional, but given the problems caused, I'm 
backing out that change and reverting to /usr/lib/${DEB_HOST_MULTIARCH}/.


It will take changes in dh-fortran-mod and openmpi which I'm doing today.

Alastair

--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie

Bug#1059700: opensmtpd dies with "pony express: smtpd: bind: Cannot assign requested address"

[Harald Dunkel]

Package: opensmtpd
Version: 6.8.0p2-4+b4


opensmtpd is not started by systemd at boot time. Error message
is:

dex06:~# journalctl -b -u opensmtpd
Dec 30 12:57:38 dex06.hosting2.aixigo.de systemd[1]: Starting opensmtpd.service 
- OpenSMTPD SMTP server...
Dec 30 12:57:38 dex06.hosting2.aixigo.de opensmtpd[103]: Active Internet 
connections (only servers)
Dec 30 12:57:38 dex06.hosting2.aixigo.de opensmtpd[103]: Proto Recv-Q Send-Q 
Local Address   Foreign Address State   PID/Program name
Dec 30 12:57:38 dex06.hosting2.aixigo.de opensmtpd[103]: tcp6   0  0 
:::3142 :::*LISTEN  -
Dec 30 12:57:38 dex06.hosting2.aixigo.de smtpd[111]: info: OpenSMTPD 6.8.0p2 
starting
Dec 30 12:57:38 dex06.hosting2.aixigo.de systemd[1]: Started opensmtpd.service 
- OpenSMTPD SMTP server.
Dec 30 12:57:38 dex06.hosting2.aixigo.de smtpd[130]: pony express: smtpd: bind: 
Cannot assign requested address
Dec 30 12:57:38 dex06.hosting2.aixigo.de smtpd[126]: smtpd: process pony socket 
closed
Dec 30 12:57:38 dex06.hosting2.aixigo.de systemd[1]: opensmtpd.service: Main 
process exited, code=exited, status=1/FAILURE
Dec 30 12:57:38 dex06.hosting2.aixigo.de systemd[1]: opensmtpd.service: Failed 
with result 'exit-code'.


If I manually restart opensmtpd, there is no such problem. As
you can see in the logfile, another service (apt-cacher-ng)
doesn't have this problem. (I had modified opensmtpd.service
to do a netstat -tnlp in ExecStartPre.)

smtpd.conf is

listen on lo
action "relay" relay host smtp://smarthost
match from local for any action "relay"

Please tell *which* address it cannot bind.


Regards

Harri

Bug#1012720: ITP: golang-k8s-apimachinery -- Handle Kubernetes-like API objects

[Jérémy Lal]

Package: wnpp
Followup-For: Bug #1012720


Hi,

is there any advance on
https://salsa.debian.org/go-team/packages/golang-k8s-apimachinery.git
?

I could help with it.

Bug#1058522: (no subject)

[Jeremy Sowden]

On 2023-12-24, at 10:00:26 +0500, Lev Lamberov wrote:
> Чт 21 дек 2023 @ 15:06 Jeremy Sowden:
> > On 2023-12-21, at 11:21:48 +, Jeremy Sowden wrote:
> >> On 2023-12-21, at 11:10:28 +0500, Lev Lamberov wrote:
> >> > Since I cannot reproduce the bug, I'm downgrading the severity of
> >> > this bug report.
> >> 
> >> I cloned the git repo, ran `gbp buildpackage --git-pbuilder` and
> >> reproduced it (log attached).  I'll see if I can work out what's going
> >> on.
> 
> Thanks for your input. I double checked this bug report both under
> git-pbuilder and sbuild. E. g., here is the sbuild environment:
> 
> $ sudo sbuild-shell unstable
> I: /bin/sh
> # bash
> (unstable-amd64-sbuild)root@shakva:/# du --version
> du (GNU coreutils) 9.4
> Copyright (C) 2023 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> .
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by Torbjörn Granlund, David MacKenzie, Paul Eggert,
> and Jim Meyering.
> (unstable-amd64-sbuild)root@shakva:/# exit
> 
> But I still cannot reproduce the bug. Don't know...

First things first, do you see the following in your chroot?

  (unstable-amd64-sbuild)root@ulthar:~# d=$(mktemp -d)
  (unstable-amd64-sbuild)root@ulthar:~# du -sb $d
  0   /tmp/tmp.qay80HZ09w

This is the cause of the problem.  If your du is not reporting zero size
for an empty directory, that would explain the discrepancy and the rest
of this e-mail is irrelevant. :)

Now I'm going to walk through the test.  The dired directory listings I
quote below were got by running:

  # apt-get source dired-du
  # cd dired-du-0.5.2
  # export TERM=rxvt
  # emacs -nw -l dired-du.el

in an sbuild unstable chroot, entering extracts from the test source
adapted to run in the *scratch* buffer and executing them, and observing
the results in a dired buffer in the same frame.

The test source begins:

  ;; Sort by size only supported in `ls-lisp'.
  (ert-deftest dired-du-sort-by-size ()
"Test ls-lisp sort by size with recursive size dir feature."
(let* ((dir (make-temp-file "dired-du" 'dir))
   (filled-subdir (expand-file-name "filled-subdir" dir))
   (empty-subdir (expand-file-name "empty-subdir" dir))
   (external-file (expand-file-name "external-file" dir))
   (inner-file (expand-file-name "inner-file" filled-subdir))

We're going to create the following directory structure:

  dired-duXX/
   |
   +-> empty-subdir/
   |
   +-> external-file
   |
   +-> filled-subdir/
|
+-> inner-file

The test source continues:

   (ls-lisp-use-insert-directory-program nil)

We force the use of ls-lisp.

   (orig-def-dir default-directory)
   (dired-listing-switches "-lS")

We tell dired to sort by size.

   (buffers '()) mode-on)
  (unwind-protect
  (let (filled-subdir-size empty-subdir-size file-size)
(make-directory filled-subdir)
(make-directory empty-subdir)
(setq default-directory dir)
(add-to-list 'buffers (dired dir))
(dired dir)

At this point we have created the two subdirectories and the dired
buffer contains:

  /tmp/dired-duSKABAl: (557 GiB available)
  drwxr-xr-x 2 root root 4096 Dec 29 16:40 empty-subdir
  drwxr-xr-x 2 root root 4096 Dec 29 16:40 filled-subdir

Note that the directory sizes come from opendir -> readdir -> fstat.  In
what follows, however, the recursive directory sizes are got by calling
du.

(setq empty-subdir-size (dired-du--get-recursive-dir-size 
"empty-subdir"))

The test expects that the recursive size of "empty-subdir" will be some
non-zero value, $x, like the 4kB reported by fstat above.

(setq file-size (* empty-subdir-size 2))
(setq filled-subdir-size (+ empty-subdir-size file-size))
(dolist (file (list external-file inner-file))
  (write-region (make-string file-size ?.) nil file))

2 * $x bytes are written to "external-file" and "inner-file".  At this
point, the expectation is that "empty-subdir" has a recursive size $x,
the two files have size 2 * $x, and "filled-subdir" has a recursive size
$x + 2 * $x.  However, because du now reports directories as having zero
size, $x equals 0, the two files contain 0B, and the two directories
have recursive sizes of 0B.

(dired-revert) ; Revert to show external-file

On running `M-x revert-buffer` in the dired buffer, it includes the
empty "external-file":

  /tmp/dired-duSKABAl: (557 GiB available)
  drwxr-xr-x 2 root root 4096 Dec 29 16:40 empty-subdir
  drwxr-xr-x 2 root root 4096 Dec 29 16:50 filled-subdir
  -rw-r--r-- 1 root root0 Dec 29 16:50 external-file

The test source continues:

(setq filled-subdir-size (dired-du--get-recursive-dir-size 
"filled-subdir"))
(setq mode-on dired-du-mode)
(dired-du-mode 

Bug#1059699: python-propka-doc: mathjax not configured to display TeX equations in docs

[Drew Parsons]

Package: python-propka-doc
Version: 3.5.0-3
Severity: normal
Tags: patch

The propka docs are not fully configured to display maths equations
(TeX).  You can see the problem opening
file:///usr/share/doc/python3-propka/html/index.html in the browser,
it displays "Heuristic \(\text{p}K_\text{a}\)" in the title.

The problem is the mathjax configuration. From the Debian privacy policy we 
strive
to make our documentation independent of internet acces, which you've
done in debian patch no-sphinx-sitemap.patch with

-mathjax_path = 
'https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS-MML_HTMLorMML'
+mathjax_path = 'file:///usr/share/javascript/mathjax/MathJax.js'


However this is not enough for display.  The success of the MathJax.js
is senstive to the mathjax config requested.  You can see upstream
used "?config=TeX-AMS-MML_HTMLorMML".  So the maths in the docs should
render correctly if the patch is updated to

-mathjax_path = 
'https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS-MML_HTMLorMML'
+mathjax_path = 
'file:///usr/share/javascript/mathjax/MathJax.js?config=TeX-AMS-MML_HTMLorMML'

Bug#1059697: This is fixed upstream

[Praveen Arimbrathodiyil]

Latest release has  s.add_dependency("octokit", ">= 4", "< 8") in gemspec

https://github.com/github/pages-health-check/blob/120cc09f776f42e9ac4e9d87e66a042819b8aa32/github-pages-health-check.gemspec


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059698: Please do a maintainer upload to enable riscv64 cross-building

[Jan Kiszka]

Package: libkeyutils1
Version: 1.6.3-2+b1

Currently, libkeyutils1 is the last blocker to automatically set up an
essential cross-build environments for riscv64:

$ docker run --rm -it debian:sid
root@d897052b9483:/# dpkg --add-architecture riscv64
root@d897052b9483:/# apt update
...
root@032073e91e5f:/# apt install build-essential libc6-dev:riscv64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libkrb5-3:riscv64 : Depends: libkeyutils1:riscv64 (>= 1.5.9) but it is not 
installable
E: Unable to correct problems, you have held broken packages.
root@032073e91e5f:/# apt-get install build-essential libc6-dev:riscv64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libkrb5-3:riscv64 : Depends: libkeyutils1:riscv64 (>= 1.5.9) but it is not 
installable
E: Unable to correct problems, you have held broken packages.


It looks like this is caused by libkeyutils1:amd64 and
libkeyutils1:riscv64 having different versions and, thus, refuse to be
installed at the same time. I've resolved it locally by rebuilding
keyutils for riscv64 using the same version as for the other archs.

Would be great to resolve that by performing a maintainer upload for
this package to sid for all architectures (not sure if
libkeyutils1:riscv64 could be "downgraded" from 1.6.3-2+b1 to 1.6.3-2, I
suspect not).

Bug#1059624: linux-image-6.1.0-16-amd64: aacraid abort request / SCSI hang after upgrade from 11.8 -> 12.4

[Salvatore Bonaccorso]

Hi,

On Sat, Dec 30, 2023 at 10:44:27AM +0100, Samuel Wolf wrote:
> Hi Salvatore,
> 
> > Thanks for your testing! Yes this is enough from your side, thanks a
> > lot for taking the time for the explict test rounds!
> 
> no problem, thanks for all you work on the Debian project!

Very welcome as well. Thanks for this kind and very motivating
feedback.

> I hope you get a feedback on your question here:
> https://lore.kernel.org/all/zy8oxge0qkyuk...@eldamar.lan/

Greg just queued it:
https://lore.kernel.org/all/2023123013-dose-skirmish-27c2@gregkh/

> I've been very careful since the last O_DIRECT issue..
> But on the other hand, hanging storage is also not without danger.

Yes fully understandable. Even though the impact was quite targeted,
as Jan Kara explained https://lwn.net/Articles/954841/, this was a
major hassle to handle right in the mittle of of the point release
pushing.

Regards,
Salvatore

Bug#1059697: [ruby-octokit 6 transition] ruby-github-pages-health-check : Depends: ruby-octokit (< 5~) but 6.1.1-1 is to be installed

[Praveen Arimbrathodiyil]

Package: ruby-github-pages-health-check
Severity: important
Version: 1.16.1-3
Control: User debian-r...@lists.debian.org
Control: Usertags octokit6

With ruby-octokit 6.1.1 in experimental, ruby-github-pages-health-check 
is no longer installable.


79s The following packages have unmet dependencies:
 80s  ruby-github-pages-health-check : Depends: ruby-octokit (< 5~) but 
6.1.1-1 is to be installed


Please make sure your package is ready to work with ruby-octokit 6 by 
the time we upload this version to unstable soon.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059291: bookworm-pu: package spip/4.1.9+dfsg-1+deb12u3

[Salvatore Bonaccorso]

Hi,

On Fri, Dec 22, 2023 at 01:28:00PM +0100, David Prévot wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: s...@packages.debian.org, t...@security.debian.org
> Control: affects -1 + src:spip
> 
> Hi,
> 
> This issue is similar to #1059289 for oldstable.
> 
> Another upstream release fixed a security (XSS) issue. The last two
> updates of this kind didn’t warrant a DSA, so I guess this one will not
> warrant one either (security team X-D-CCed in case I’m wrong).

To confirm, from security team perspective, this does not warrant a
DSA and can be fixed in the upcoming point release.

Regards,
Salvatore

Bug#1059696: bookworm-pu: package mate-utils/1.26.0-1+deb12u1

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: mate-ut...@packages.debian.org
Control: affects -1 + src:mate-utils

While preparing a new upstream release upload of mate-utils, a
bookworm-pu has been prepared cherry-picking various memory leak fixes
from upstream.

[ Reason ]
(a) Fixing various memleaks in mate utils.
(b) Fixing package name in upstream changelog.

[ Impact ]
If this pu won't get accepted, memleaks in mate-utils in bookworm remain.

[ Tests ]
Manually.

[ Risks ]
MATE users could be affected by regression. The various tools in mate-utils
supplement MATE desktop's functionality scope with minor tools (diskusage,
screenshot, dictionary, etc.).

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

[ Changes ]

+  * debian/patches:
++ Add _Fix-News.patch. Fix wrong package name in upstream NEWS file
+  (i.e. our upstream ChangeLog).
++ Add patches 0001 - 0006 fixing various memleaks in mate-utils (closes:
+  #1052579), cherry-picked from v1.26.1: 0001_mate-screenshot-fix-memory-
+  leak.patch, 0002_mate-disk-image-mounter-fix-memory-leak.patch, 
0003_mate-
+  dictionary-fix-memory-leak.patch, 0004_gsearchtool-fix-memory-leak.patch,
+  0005_mate-dictionary-fix-memory-leak.patch, 0006_mate-dictionary-fix-
+  memory-leak.patch.

[ Other info ]
None.
diff -Nru mate-utils-1.26.0/debian/changelog mate-utils-1.26.0/debian/changelog
--- mate-utils-1.26.0/debian/changelog  2021-12-13 08:11:24.0 +0100
+++ mate-utils-1.26.0/debian/changelog  2023-12-30 11:48:33.0 +0100
@@ -1,3 +1,17 @@
+mate-utils (1.26.0-1+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
++ Add _Fix-News.patch. Fix wrong package name in upstream NEWS file
+  (i.e. our upstream ChangeLog).
++ Add patches 0001 - 0006 fixing various memleaks in mate-utils (closes:
+  #1052579), cherry-picked from v1.26.1: 0001_mate-screenshot-fix-memory-
+  leak.patch, 0002_mate-disk-image-mounter-fix-memory-leak.patch, 
0003_mate-
+  dictionary-fix-memory-leak.patch, 0004_gsearchtool-fix-memory-leak.patch,
+  0005_mate-dictionary-fix-memory-leak.patch, 0006_mate-dictionary-fix-
+  memory-leak.patch.
+
+ -- Mike Gabriel   Sat, 30 Dec 2023 11:48:33 +0100
+
 mate-utils (1.26.0-1) unstable; urgency=medium
 
   [ Martin Wimpress ]
diff -Nru mate-utils-1.26.0/debian/patches/_Fix-News.patch 
mate-utils-1.26.0/debian/patches/_Fix-News.patch
--- mate-utils-1.26.0/debian/patches/_Fix-News.patch1970-01-01 
01:00:00.0 +0100
+++ mate-utils-1.26.0/debian/patches/_Fix-News.patch2023-12-30 
11:38:14.0 +0100
@@ -0,0 +1,55 @@
+From 3d70c8ec7b5b3847fe906974dc178d03a05bdaf7 Mon Sep 17 00:00:00 2001
+From: raveit65 
+Date: Thu, 5 Aug 2021 22:45:07 +0200
+Subject: [PATCH] Fix News
+
+closes annoying report https://github.com/mate-desktop/mate-utils/issues/318
+
+Signed-off-by: Mike Gabriel 
+---
+ NEWS | 10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/NEWS b/NEWS
+index 3d677c09..da91780c 100644
+--- a/NEWS
 b/NEWS
+@@ -1,9 +1,9 @@
+-### mate-notification-daemon 1.26.0
++### mate-utils 1.26.0
+ 
+   * Translations update
+   * update copyright to 2021
+ 
+-### mate-notification-daemon 1.25.1
++### mate-utils 1.25.1
+ 
+   * Translations update
+   * Remove warnings about missing prototypes
+@@ -33,7 +33,7 @@
+   * Warn about accessing an undefined property of the object
+   * gsearchtool: Fix "open with" behavior
+ 
+-### mate-notification-daemon 1.25.0
++### mate-utils 1.25.0
+ 
+   * Translations update
+   * gdict-pref-dialog: Simplify notebook scroll event
+@@ -67,12 +67,12 @@
+   * baobab: Remove unused variable ‘uri_list’
+   * mate-screenshot: do not use stock icons in mate-screenshot.ui
+ 
+-### mate-notification-daemon 1.24.0
++### mate-utils 1.24.0
+ 
+   * Translations update
+   * Fix build using gcc 10 -fno-common flag
+ 
+-### mate-notification-daemon 1.23.2
++### mate-utils 1.23.2
+ 
+   * Translations update
+   * gettext: Fix locale dir
+-- 
+2.39.2
+
diff -Nru 
mate-utils-1.26.0/debian/patches/0001_mate-screenshot-fix-memory-leak.patch 
mate-utils-1.26.0/debian/patches/0001_mate-screenshot-fix-memory-leak.patch
--- mate-utils-1.26.0/debian/patches/0001_mate-screenshot-fix-memory-leak.patch 
1970-01-01 01:00:00.0 +0100
+++ mate-utils-1.26.0/debian/patches/0001_mate-screenshot-fix-memory-leak.patch 
2023-12-30 11:38:46.0 +0100
@@ -0,0 +1,29 @@
+From 74646513584b8bcbea61b37ddb3e75a5a206605c Mon Sep 17 00:00:00 2001
+From: rbuj 
+Date: Mon, 8 Nov 2021 15:26:58 +0100
+Subject: [PATCH 1/6] mate-screenshot: fix memory leak
+
+Signed-off-by: Mike Gabriel 
+---
+ mate-screenshot/src/mate-screenshot.c | 4 +++-
+ 1 file