Bug#1031713: ITP: python-klein -- micro-framework for developing web services with Python

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block -1 by 995352

* Package name: python-klein
  Version : 21.8.0
  Upstream Author : Aaron Gallagher et al.
* URL : https://github.com/twisted/klein
* License : Expat
  Programming Lang: Python
  Description : micro-framework for developing web services with Python

Klein is a micro-framework for developing production-ready web services 
with Python. It is 'micro' in that it has an incredibly small API 
similar to Bottle and Flask. It is not 'micro' in that it depends on 
things outside the standard library. This is primarily because it is 
built on widely used and well tested components like Werkzeug and Twisted.


klein is needed by tahoe-lafs.

Remark: This package is to be maintained with Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-klein

Bug#952583: mps-youtube: Mps-youtube failes to find anything because google disabled its api key... and a 2 more minor issues

[jim_p]

Package: mps-youtube
Followup-For: Bug #952583
X-Debbugs-Cc: pitsior...@outlook.com

Speaking of progress from upstream, and only 2 days after my comment here, a
new version was released from upstream!
https://github.com/mps-youtube/yewtube/releases/tag/v2.9.4

The project was renamed to yewtube and its versioning scheme is continued from
the forked project above. If anyone is willing to package it, please do, else
remove it from the repo.


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

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

Versions of packages mps-youtube depends on:
ii  ffmpeg 10:5.1.2-dmo3
ii  mpv1:0.35.1-dmo1
ii  python33.11.1-3
pn  python3-pafy   
ii  python3-pkg-resources  66.1.1-1

Versions of packages mps-youtube recommends:
ii  libnotify40.8.1-1
pn  python3-dbus  
ii  python3-gi3.42.2-3+b1
ii  xclip 0.13-2

mps-youtube suggests no packages.

Bug#1031712: libnet-server-perl: Use of uninitialized value in numeric eq (==) at /usr/share/perl5/Net/Server/Fork.pm line 168.

[Dominique Fournier]

Package: libnet-server-perl
Version: 2.013-1
Severity: normal

Dear Maintainer,

Each time there is a connection in Munin (using the lib-netserver-perl package 
as tcp server),
a log is generated :
munin-node: Use of uninitialized value in numeric eq (==) at 
/usr/share/perl5/Net/Server/Fork.pm line 168.

This appears in version 2.013-1 and don't exists in version 2.009-2 of the 
package.

Could you patch the library to remove this not needed log ?

Thanks a lot

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

Kernel: Linux 5.15.74-1-pve (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, 
TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libnet-server-perl depends on:
ii  libcgi-pm-perl  4.55-1
ii  libio-multiplex-perl1.16-3
ii  libio-socket-inet6-perl 2.73-1
pn  libio-socket-ip-perl
ii  libio-socket-ssl-perl   2.078-1
ii  libnet-cidr-perl0.21-2
ii  libnet-ssleay-perl  1.92-2+b1
ii  libsocket6-perl 0.29-3
ii  perl5.36.0-7
ii  perl-base [libsocket-perl]  5.36.0-7

libnet-server-perl recommends no packages.

Versions of packages libnet-server-perl suggests:
pn  liblog-log4perl-perl  

-- no debconf information

Bug#1030047: ruby-sanitize: diff for NMU version 6.0.0-1.1

[Salvatore Bonaccorso]

Control: tags 1030047 + patch
Control: tags 1030047 + pending


Dear maintainer,

I've prepared an NMU for ruby-sanitize (versioned as 6.0.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru ruby-sanitize-6.0.0/debian/changelog ruby-sanitize-6.0.0/debian/changelog
--- ruby-sanitize-6.0.0/debian/changelog	2022-01-27 20:56:32.0 +0100
+++ ruby-sanitize-6.0.0/debian/changelog	2023-02-20 20:28:45.0 +0100
@@ -1,3 +1,13 @@
+ruby-sanitize (6.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update tests to remove deprecated minitest 'must_be'
+  * Forcibly escape content in "unescaped text" elements inside math or svg
+namespaces
+  * Always remove `` elements (CVE-2023-23627) (Closes: #1030047)
+
+ -- Salvatore Bonaccorso   Mon, 20 Feb 2023 20:28:45 +0100
+
 ruby-sanitize (6.0.0-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru ruby-sanitize-6.0.0/debian/patches/Always-remove-noscript-elements.patch ruby-sanitize-6.0.0/debian/patches/Always-remove-noscript-elements.patch
--- ruby-sanitize-6.0.0/debian/patches/Always-remove-noscript-elements.patch	1970-01-01 01:00:00.0 +0100
+++ ruby-sanitize-6.0.0/debian/patches/Always-remove-noscript-elements.patch	2023-02-20 20:28:23.0 +0100
@@ -0,0 +1,143 @@
+From: Ryan Grove 
+Date: Thu, 26 Jan 2023 13:42:39 -0800
+Subject: Always remove `` elements
+Origin: https://github.com/rgrove/sanitize/commit/ec14265e530dc3fe31ce2ef773594d3a97778d22
+Bug-Debian: https://bugs.debian.org/1030047
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-23627
+
+...even if `noscript` is in the allowlist.
+
+A `` element's content is parsed differently in browsers
+depending on whether or not scripting is enabled. Since Nokogiri doesn't
+support scripting, it always parses `` elements as if
+scripting is disabled. This results in edge cases where it's not
+possible to reliably sanitize the contents of a `` element
+because Nokogiri can't fully replicate the parsing behavior of a
+scripting-enabled browser. The safest thing to do is to simply remove
+all `` elements.
+
+Fixes GHSA-fw3g-2h3j-qmm7
+---
+ HISTORY.md | 27 ++
+ README.md  | 14 +++
+ lib/sanitize/transformers/clean_element.rb | 10 
+ test/test_clean_element.rb |  7 ++
+ test/test_malicious_html.rb| 20 +++-
+ 5 files changed, 73 insertions(+), 5 deletions(-)
+
+diff --git a/README.md b/README.md
+index 0f6efb56fde0..5f5e73816f68 100644
+--- a/README.md
 b/README.md
+@@ -12,10 +12,10 @@ properties, @ rules, and URL protocols in elements or attributes containing CSS.
+ Any HTML or CSS that you don't explicitly allow will be removed.
+ 
+ Sanitize is based on the [Nokogumbo HTML5 parser][nokogumbo], which parses HTML
+-exactly the same way modern browsers do, and [Crass][crass], which parses CSS
+-exactly the same way modern browsers do. As long as your allowlist config only
+-allows safe markup and CSS, even the most malformed or malicious input will be
+-transformed into safe output.
++the same way modern browsers do, and [Crass][crass], which parses CSS the same
++way modern browsers do. As long as your allowlist config only allows safe markup
++and CSS, even the most malformed or malicious input will be transformed into
++safe output.
+ 
+ [![Gem Version](https://badge.fury.io/rb/sanitize.svg)](http://badge.fury.io/rb/sanitize)
+ [![Tests](https://github.com/rgrove/sanitize/workflows/Tests/badge.svg)](https://github.com/rgrove/sanitize/actions?query=workflow%3ATests)
+@@ -427,6 +427,12 @@ elements not in this array will be removed.
+ >
+ > By default, Sanitize will remove all MathML and SVG elements. If you add MathML or SVG elements to a custom element allowlist, you must assume that any content inside them will be allowed, even if that content would otherwise be removed or escaped by Sanitize. This may create a security vulnerability in your application.
+ 
++> **Note**
++>
++> Sanitize always removes `` elements and their contents, even if `noscript` is in the allowlist.
++>
++> This is because a `` element's content is parsed differently in browsers depending on whether or not scripting is enabled. Since Nokogiri doesn't support scripting, it always parses `` elements as if scripting is disabled. This results in edge cases where it's not possible to reliably sanitize the contents of a `` element because Nokogiri can't fully replicate the parsing behavior of a scripting-enabled browser.
++
+  :parser_options (Hash)
+ 
+ [Parsing options](https://github.com/rubys/nokogumbo/tree/master#parsing-options) to be supplied to `nokogumbo`.
+diff --git a/lib/sanitize/transformers/clean_element.rb b/lib/sanitize/transformers/clean_element.rb
+index a2bacd8198f7..98208a7c15f3 100644
+--- a/lib/sanitize/transformers/clean_element.rb

Bug#1031698: RFS: dhcpdump/1.8-5 [QA] -- Parse DHCP packets from tcpdump

[Boian Bonev]

Hi,

First thing to change (after the missing binary) is the description - the tool
no longer executes and parses tcpdump's output, instead it uses libpcap
directly to get the packets. The man page needs the same correction.

The build completely ignores the default hardening and optimization flags. This
breaks both cross and reproducible builds.

tcpdump should be removed from Depends.

Isn't it better to depend on libpcap-dev? (libpcap0.7-dev isn't in any
supported release)

Current standards are 4.6.2.

d/copyright may benefit from a DEP5 conversion.

Now I see that there are 3 open bugs, maybe at least two or even all can be
fixed by this upload?

I have several patches for this tool hanging around since 2013, I did try to
send them to upstream back then but they either got lost or ignored. All of
them are fixing behavioral bugs.

I think it is a good idea to add these patches while doing the QA upload. I
need to add the proper headers and will post after an ACK.

--
With best regards,
b.


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

Bug#1031711: verilator: reproducible-builds: documentation date depends on timezone

[Larry Doolittle]

Package: src:verilator
Version: 5.006-2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

The Reproducible Builds effort noticed that verilator does not build 
reproducibly.
  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/verilator.html
This is because the verilator.pdf file's cover-page date stamp depends on the 
timezone.

When this situation was brought to the attention of upstream developers,
their preference was to shift to using an internal release date, rather
than fix the SOURCE_DATE_EPOCH override to be timezone-independent.
The attached patch is an upstream git commit (bc6a778, Feb 12 2023)
to their primary development sources.

With this patch applied (note it needs to be listed _after_ the existing
"Add SOURCE_DATE_EPOCH for docs guide conf.py 3918.patch" in patches/series)
verilator should build reproducibly on tests.reproducible-builds.org!

Thanks for maintaining Verilator!

  - Larry
>From bc6a7787ed271a8f52ed5b8f8a9e0e8cbba1ab38 Mon Sep 17 00:00:00 2001
From: Larry Doolittle 
Date: Sun, 12 Feb 2023 20:21:03 -0800
Subject: [PATCH] Fix date on the front page of verilator.pdf (#3956) (#3957)

---
 docs/guide/conf.py | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/docs/guide/conf.py b/docs/guide/conf.py
index 04759c6de..9f69245dd 100644
--- a/docs/guide/conf.py
+++ b/docs/guide/conf.py
@@ -10,7 +10,6 @@
 # --
 # -- Path setup
 
-from datetime import datetime
 import os
 import re
 import sys
@@ -24,10 +23,17 @@ def get_vlt_version():
 filename = "../../Makefile"
 with open(filename, "r", encoding="utf8") as fh:
 for line in fh:
-match = re.search(r"PACKAGE_VERSION_NUMBER *= *([a-z0-9.]+)", line)
+match = re.search(r"PACKAGE_VERSION *= *([a-z0-9.]+) +([-0-9]+)", line)
 if match:
-return match.group(1)
-return "unknown"
+return match.group(1), match.group(2)
+match = re.search(r"PACKAGE_VERSION *= *([a-z0-9.]+) +devel", line)
+if match:
+try:
+data = os.popen('git log -n 1 --pretty=%cs').read()
+except Exception:
+data = ""  # fallback, and Sphinx will fill in today's date
+return "Devel " + match.group(1), data
+return "unknown", "unknown"
 
 
 def setup(app):
@@ -44,8 +50,8 @@ author = 'Wilson Snyder'
 # The master toctree document.
 master_doc = "index"
 
-version = get_vlt_version()
-release = get_vlt_version()
+version, today_fmt = get_vlt_version()
+release = version
 
 rst_prolog = """
 .. role:: vlopt(option)
@@ -89,15 +95,6 @@ source_suffix = [".rst"]
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ['_templates']
 
-try:
-# https://reproducible-builds.org/specs/source-date-epoch/
-doc_now = datetime.fromtimestamp(int(os.environ["SOURCE_DATE_EPOCH"]))
-print("Using SOURCE_DATE_EPOCH")
-except Exception:
-doc_now = datetime.now()
-# Date format to ISO
-today_fmt = doc_now.strftime("%F")
-
 # If true, `todo` and `todoList` produce output, else they produce nothing.
 todo_include_todos = True
 
-- 
2.30.2

Bug#1031113: davegnukem: rules breaks parallel build

[David (Plasma) Paul]

On Fri, 17 Feb 2023 12:59:23 +0100
Matteo Bini  wrote:

> Hi Plasma,
> thanks for the patch!

Happy to help.

> Before applying your fix, I would like to ask you what is the
> difference between calling `$(MAKE)` and `dh_auto_build --`.

dh_auto_build, as a part of debhelper, automatically modifies the build
environment and sets makeflags before running the program's Makefile.
Importantly in this case, it checks the environment variable
DEB_BUILD_OPTIONS to see if it contains a "parallel=n" tag. If it does,
debhelper adds '-j' to the makeflags with the associated value n. If
DEB_BUILD_OPTIONS doesn't exist or doesn't contain a "parallel=n" tag,
debhelper sets the makeflags to build with as many CPU threads are
available. Running make directly using $(MAKE) only handles
DEB_BUILD_OPTIONS properly with additional boilerplate code. See Debian
Policy Section 4.9.1 (link below) for an example. In general it's much
easier to let debhelper do the heavy lifting rather than having to write
a bunch of the same boilerplate for each package.

https://www.debian.org/doc/debian-policy/ch-source.html#debian-rules-and-deb-build-options

> Moreover I was wondering if your patch could make davegnukem build
> reproducibly, because now it does not.

I'm not sure. I don't think so. I skimmed the build logs for
davegnukem, but I wasn't able to tell what was keeping it from building
reproducibly, sorry.

> This is one of my first packages, so please forgive my ignorance. I
> really appreciate your help.

Ignorance is easy to forgive in anyone willing and eager to learn. :-)

-- 
Plasma

Bug#1031710: appstream-generator: Include link to valid categories in warning

[Petter Reinholdtsen]

Package: appstream-generator
Version: 0.8.4-1
Severity: wishlist

It would be nice if web pages like the current
https://appstream.debian.org/sid/main/issues/jami.html >, would
include a link to the list of accepted categories.  At the moment it
list warnings like this:

  asv-category-invalid

- Productivity

The category name is not valid. Refer to the XDG Menu Specification
for a list of valid category names. 

Please adjust the web page output to include a link ti
https://specifications.freedesktop.org/menu-spec/latest/apa.html >
where the controlled vocabulary for categories is listed.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1031709: RFS: libkysdk-applications/1.0.1-1 [ITP] -- kylin SDK based on application level

[xibowen]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libkysdk-applications":

 * Package name : libkysdk-applications
   Version  : 1.0.1-1
   Upstream contact : Zhen Sun 
 * URL  : https://gitee.com/openkylin/libkysdk-applications
 * License  : LGPL-3, GPL-3, BSD-3-clause
 * Vcs  : https://gitee.com/openkylin/libkysdk-applications
   Section  : libs

The source builds the following binary packages:

  libkysdk-applications - kylin SDK based on application level
  libkysdk-applications-dev - development for libkysdk-applications
  libkysdk-qtwidgets-dev - development files for libkysdk-qtwidgets
  libkysdk-qtwidgets - add-on widgets and classes for Qt applications
  libkysdk-widgetutils-dev - development files for libkysdk-widgetutils
  libkysdk-widgetutils - window display control moudule
  libkysdk-kabase - additional interface on application level
  libkysdk-kabase-dev - development files for libkysdk-kabase
  libkysdk-waylandhelper-dev - development files for libkysdk-waylandhelper
  libkysdk-waylandhelper - Window management interface
  libkysdk-alm - Application process management module
  libkysdk-alm-dev - development files for libkysdk-ukenv
  libkysdk-ukenv - Kylin system environment interface
  libkysdk-ukenv-dev - development files for libkysdk-ukenv modal

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

  https://mentors.debian.net/package/libkysdk-applications/

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

  dget -x https://mentors.debian.net/debian/pool/main/libk/libkysdk-
applications/libkysdk-applications_1.0.1-1.dsc

Changes for the initial release:

 libkysdk-applications (1.0.1-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1031661)

Regards,
--
  xibowen

Bug#1014782: The problem remains

[Jamie Zawinski]

> The DEACTIVATE events I found, that are apparently sent by the Xfce
> Power Manager, are not preceeded by xscreensaver-systemd lines,
> although other DEACTIVATE lines are, e.g. "inhibited by "chromium"". So
> apparently the systemd integration is working, but Xfce isn't using it?

Sounds that way! Which is surprising, from reading the code, but not actually a 
problem, I guess.

-- 
Jamie Zawinski • jwz.org • dnalounge.com

Bug#1014782: The problem remains

[Celejar]

On Mon, 20 Feb 2023 16:58:37 -0800 Jamie Zawinski  wrote:
> If blanking is being inhibited by dbus, the verbose log will look like this:
> 
> xscreensaver-systemd: 16:54:30: inhibited by "firefox-esr" (:1.48) with 
> "video-playing" cookie "0C765C49"
> xscreensaver-systemd: 16:54:30: inhibited by "firefox-esr" since Mon Feb 20 
> 16:54:30 2023
> xscreensaver-systemd: 16:54:30: exec: xscreensaver-command --verbose 
> -deactivate
> xscreensaver: 16:54:30: ClientMessage DEACTIVATE: already inactive, resetting 
> activity time
> xscreensaver-command: already inactive, resetting activity time
> xscreensaver-systemd: 16:54:32: uninhibited by "firefox-esr" (:1.48) with 
> "video-playing" cookie "0C765C49"
> 
> If blanking is being inhibited directly, you'll see only the "deactivate" 
> line.

The DEACTIVATE events I found, that are apparently sent by the Xfce
Power Manager, are not preceeded by xscreensaver-systemd lines,
although other DEACTIVATE lines are, e.g. "inhibited by "chromium"". So
apparently the systemd integration is working, but Xfce isn't using it?

-- 
Celejar

Bug#1030987: bullseye-pu: package vagrant/2.2.14+dfsg-2

[Antonio Terceiro]

On Sun, Feb 19, 2023 at 06:54:45PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2023-02-10 at 09:58 +0100, Antonio Terceiro wrote:
> > Since VirtualBox is not in stable, people will install it either from
> > upstream, and from Fasttrack (https://fasttrack.debian.net/). When a
> > new
> > version of VirtualBox comes out, vagrant needs change to work with
> > it.
> > 
> > [ Impact ]
> > stable users can't use vagrant with the latest VirtualBox (7.0).
> > 
> 
> Please go ahead.

Uploaded.


signature.asc
Description: PGP signature

Bug#1015273: coreutils: rm -d doesn't try to remove unreadable directories, lies in error message, with *fails to prompt* with -i

[Jim Meyering]

On Mon, Jul 18, 2022 at 12:21 PM наб  wrote:
> Package: coreutils
> Version: 8.32-4.1
> Severity: normal
>
> Dear Maintainer,
>
> Fun one for ya: the baseline:
> -- >8 --
> $ mkdir -p /tmp/psko
> $ rm -vid /tmp/psko
> rm: remove directory '/tmp/psko'? y
> removed directory '/tmp/psko'
> -- >8 --
>
> Bug a:
> -- >8 --
> $ mkdir -p /tmp/psko
> $ chmod -r /tmp/psko
> $ rm -vid /tmp/psko; echo $?
> rm: cannot remove '/tmp/psko': Directory not empty
> 1
> -- >8 --
>
> Absolutely 0 prompt, despite -i!
> That's very fun (and a POSIX violation)!
>
> Bug b:
> -- >8 --
> $ strace rm -vid /tmp/psko 2>&1 | grep -v locale
> execve("/bin/rm", ["rm", "-vid", "/tmp/psko"], 0xff8fbc48 /* 24 vars */) = 0
> /* ... */
> arch_prctl(ARCH_SET_FS, 0xf7f9e240) = 0
> mprotect(0xf7f8b000, 8192, PROT_READ)   = 0
> mprotect(0x40f000, 4096, PROT_READ) = 0
> mprotect(0xf7fcd000, 8192, PROT_READ)   = 0
> munmap(0xf7f96000, 26859)   = 0
> brk(NULL)   = 0xaa6000
> brk(0xac7000)   = 0xac7000
> brk(0xac8000)   = 0xac8000
> newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=3041504, ...}, 
> AT_EMPTY_PATH) = 0
> mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7a0
> mmap(NULL, 2596864, PROT_READ, MAP_PRIVATE, 3, 0x6d000) = 0xf7786000
> close(3)= 0
> ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
> newfstatat(AT_FDCWD, "/tmp/psko", {st_mode=S_IFDIR|0311, st_size=40, ...}, 
> AT_SYMLINK_NOFOLLOW) = 0
> openat(AT_FDCWD, "/tmp/psko", 
> O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_DIRECTORY) = -1 EACCES (Permission 
> denied)
> newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=2996, ...}, AT_EMPTY_PATH) = > 0
> read(3, "# Locale name alias data base.\n#"..., 4096) = 2996
> read(3, "", 4096)   = 0
> close(3)= 0
> write(2, "rm: ", 4rm: ) = 4
> write(2, "cannot remove '/tmp/psko'", 25cannot remove '/tmp/psko') = 25
> newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=1433, ...}, AT_EMPTY_PATH) = > 0
> mmap(NULL, 1433, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f9c000
> close(3)= 0
> write(2, ": Directory not empty", 21: Directory not empty)   = 21
> write(2, "\n", 1
> )   = 1
> lseek(0, 0, SEEK_CUR)   = -1 ESPIPE (Illegal seek)
> close(0)= 0
> close(1)= 0
> close(2)= 0
> exit_group(1)   = ?
> +++ exited with 1 +++
> -- >8 --
>
> Can you spot a rmdir(2) equivalent? I can't! So why does it lie and say
> that it tried to remove it?
>
> Also, the directory /isn't nonempty/! Bug c:
> -- >8 --
> $ rmdir -v /tmp/psko/; echo $?
> rmdir: removing directory, '/tmp/psko/'
> 0
> -- >8 --
> And it's not there! Because, shockingly, there's nothing stopping you
> from removing it! So why on /earth/ is rm failing to prompt, failing to
> try to remove it, then lying that it had and failed with an obviously
> false errno?
>
> The same applies to just plain rm -d /tmp/psko (no -i)
> (except for bug a).

Thank you for the bug report.
I've attached a patch that fixes those bugs.


rm--dir.diff
Description: Binary data

Bug#1031708: RFS: libkysdk-applications/1.0.1-1 [ITP] -- kylin SDK based on application level

[xibowen]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libkysdk-applications":

 * Package name : libkysdk-applications
   Version  : 1.0.1-1
   Upstream contact : Zhen Sun 
 * URL  : https://gitee.com/openkylin/libkysdk-applications
 * License  : LGPL-3, GPL-3, BSD-3-clause
 * Vcs  : https://gitee.com/openkylin/libkysdk-applications
   Section  : libs

The source builds the following binary packages:

  libkysdk-applications - kylin SDK based on application level
  libkysdk-applications-dev - development for libkysdk-applications
  libkysdk-qtwidgets-dev - development files for libkysdk-qtwidgets
  libkysdk-qtwidgets - add-on widgets and classes for Qt applications
  libkysdk-widgetutils-dev - development files for libkysdk-widgetutils
  libkysdk-widgetutils - window display control moudule
  libkysdk-kabase - additional interface on application level
  libkysdk-kabase-dev - development files for libkysdk-kabase
  libkysdk-waylandhelper-dev - development files for libkysdk-waylandhelper
  libkysdk-waylandhelper - Window management interface
  libkysdk-alm - Application process management module
  libkysdk-alm-dev - development files for libkysdk-ukenv
  libkysdk-ukenv - Kylin system environment interface
  libkysdk-ukenv-dev - development files for libkysdk-ukenv modal

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

  https://mentors.debian.net/package/libkysdk-applications/

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

  dget -x https://mentors.debian.net/debian/pool/main/libk/libkysdk-
applications/libkysdk-applications_1.0.1-1.dsc

Changes for the initial release:

 libkysdk-applications (1.0.1-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1031661)

Bug#1031707: RFS: libkysdk-applications/1.0.1-1 [ITP] -- kylin SDK based on application level

[xibowen]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libkysdk-applications":

 * Package name : libkysdk-applications
   Version  : 1.0.1-1
   Upstream contact : Zhen Sun 
 * URL  : https://gitee.com/openkylin/libkysdk-applications
 * License  : LGPL-3, GPL-3, BSD-3-clause
 * Vcs  : https://gitee.com/openkylin/libkysdk-applications
   Section  : libs

The source builds the following binary packages:

  libkysdk-applications - kylin SDK based on application level
  libkysdk-applications-dev - development for libkysdk-applications
  libkysdk-qtwidgets-dev - development files for libkysdk-qtwidgets
  libkysdk-qtwidgets - add-on widgets and classes for Qt applications
  libkysdk-widgetutils-dev - development files for libkysdk-widgetutils
  libkysdk-widgetutils - window display control moudule
  libkysdk-kabase - additional interface on application level
  libkysdk-kabase-dev - development files for libkysdk-kabase
  libkysdk-waylandhelper-dev - development files for libkysdk-waylandhelper
  libkysdk-waylandhelper - Window management interface
  libkysdk-alm - Application process management module
  libkysdk-alm-dev - development files for libkysdk-ukenv
  libkysdk-ukenv - Kylin system environment interface
  libkysdk-ukenv-dev - development files for libkysdk-ukenv modal

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

  https://mentors.debian.net/package/libkysdk-applications/

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

  dget -x https://mentors.debian.net/debian/pool/main/libk/libkysdk-
applications/libkysdk-applications_1.0.1-1.dsc

Changes for the initial release:

 libkysdk-applications (1.0.1-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1031661)

Bug#1029354: ncat: ICMPv4 Type 3 Code 13 not implemented

[Gordon Fyodor Lyon]

Sorry for the delay, but this sounds like expected behavior.  Ncat is
generally using the socket API rather than raw packets and so the host
receives the ICMP response and translates that into a more generic error
code that Ncat sees.  You can use our Nping tool if you need raw packet
sending and sniffing instead.

-Gordon

On Sat, Jan 21, 2023 at 8:30 AM Marco Moock  wrote:

> Package: ncat
> Version: 7.93+dfsg1-1
> Severity: minor
> Tags: upstream
> X-Debbugs-Cc: m...@posteo.de
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
> ncat   and reply is ICMPv4 Type 3 Code 13, wrong error
> message
> "Ncat: No route to host.".
>* What outcome did you expect instead?
> Correct message, like "Connection to   administratively
> prohibited".
> https://datatracker.ietf.org/doc/html/rfc1812#section-5.2.7.1
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.1.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages ncat depends on:
> ii  libc62.36-8
> ii  liblua5.3-0  5.3.6-2
> ii  libpcap0.8   1.10.3-1
> ii  libssl3  3.0.7-1
>
> ncat recommends no packages.
>
> ncat suggests no packages.
>
> -- no debconf information
>
>

Bug#1031293: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z

[Boyuan Yang]

Hi,

在 2023-02-21星期二的 01:16 +0200，Peter Pentchev写道：
> On Tue, Feb 21, 2023 at 12:39:53AM +0200, Peter Pentchev wrote:
> > On Mon, Feb 20, 2023 at 05:23:28PM -0500, Boyuan Yang wrote:
> > > Hi,
> > > 
> > > 在 2023-02-21星期二的 00:38 +0530，Nilesh Patra写道：
> > > > On Fri, 17 Feb 2023 07:51:48 +0100 Lucas Nussbaum 
> > > > wrote:
> > > > > Source: python-zstandard
> > > > > Version: 0.19.0-3
> > > > > Severity: serious
> > > > > Justification: FTBFS
> > > > > Tags: bookworm sid ftbfs
> > > > > User: lu...@debian.org
> > > > > Usertags: ftbfs-20230216 ftbfs-bookworm
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > During a rebuild of all packages in sid, your package failed to
> > > > > build
> > > > > on amd64.
> > > > 
> > > > At the moment this is creating quite
> > > > the havoc with making a bunch of things FTBFS as well (see merhged
> > > > bugs)
> > > > 
> > > > This is likely due to py-zst trying to link with the zstandard in
> > > > the
> > > > archive
> > > > which does not seem to go very well.
> > > > 
> > > > Is someone working to fix this?
> > > 
> > > Thanks for cc-ing. I did not monitor bugs for this package before.
> > > 
> > > Upstream just released v0.20.0 targeting libzstd 1.5.4. I will try it
> > > out
> > > and have it packaged.
> > > 
> > > On the long run, the mismatch of src:libzstd and src:python-zstandard
> > > will
> > > always occur intermittently due to its nature. I am not sure whether
> > > re-
> > > enabling bundled libzstd would be a good choice, but at least let's
> > > fix the
> > > combination for Debian 12 first.
> > > 
> > > Any suggestions?
> > 
> > Oof. Sorry about that. I guess I didn't consider the python-zstandard
> > package at all until now.
> > 
> > As I am a member of both the pkg-rpm and pkg-python teams, I could try
> > to
> > update the packages in sync from now on, possibly adding something like
> > Breaks: python-zstandard (<< version-I-am-about-to-upload-in-sync) to
> > libzstd itself if it breaks the then-current python-zstandard package.
> 
> (of course, I meant Breaks: python3-zstandard (<< ...))
> 
> ...of course, another - or rather, an additional - option would be to
> relax (or remove) the check that python-zstandard makes regarding
> the libzstd version recorded at compile time. Since both libzstd
> upstream and the Debian package tries to hold true to the usual
> semver-like compatiblity scheme, python-zstandard ought to be able to
> believe that even a more recent version of libzstd would be ABI-compatible
> unless it has reason to think otherwise - and that case could be handled
> by Breaks: python3-zstandard (<< next-version) in libzstd as outlined
> above. So maybe (for future new upstream versions of libzstd):
> - relax (or remove) the python3-zstandard check for the libzstd version
> - each time a new libzstd upload is about to be done, check that
>   python3-zstandard works, too
> - if it works, do nothing else, upload libzstd as usual
> - if python3-zstandard would for some reason break and needs updating,
>   hold off with the libzstd upload until an updated version of
>   python3-zstandard is released upstream, make sure it will work, and
>   only then upload libzstd with a Breaks declaration
> - upload the updated version of python3-zstandard immediately (maybe
>   even simultaneously) and declare a Depends relationship on
>   the just-uploaded version of libzstd (as it does now)
> 
> If this sounds good, I believe I can do it that way for future libzstd
> uploads.


There are surely many possibilities as long as we are aware of such
versioned dependency and coordinate on the uploads. Since you are also in
python packaging team, please feel free to make modifications and do team
uploads to python-zstandard in the future if you find it necessary. Thanks!

Best,
Boyuan Yang


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

Bug#1014782: The problem remains

[Jamie Zawinski]

If blanking is being inhibited by dbus, the verbose log will look like this:

xscreensaver-systemd: 16:54:30: inhibited by "firefox-esr" (:1.48) with 
"video-playing" cookie "0C765C49"
xscreensaver-systemd: 16:54:30: inhibited by "firefox-esr" since Mon Feb 20 
16:54:30 2023
xscreensaver-systemd: 16:54:30: exec: xscreensaver-command --verbose -deactivate
xscreensaver: 16:54:30: ClientMessage DEACTIVATE: already inactive, resetting 
activity time
xscreensaver-command: already inactive, resetting activity time
xscreensaver-systemd: 16:54:32: uninhibited by "firefox-esr" (:1.48) with 
"video-playing" cookie "0C765C49"

If blanking is being inhibited directly, you'll see only the "deactivate" line.

Bug#1014782: The problem remains

[Celejar]

On Mon, 20 Feb 2023 11:13:58 -0800 Jamie Zawinski  wrote:
> On Feb 20, 2023, at 9:44 AM, Celejar  wrote:
> > 
> > It turns out that the DEACTIVATEs were being sent by the Xfce Power
> > Manager's Presentation Mode. I'm not sure I was even aware of that
> > mode's existence, but it apparently has a long history of becoming
> > turned on without the conscious intention or awareness of the user :)
> 
> Good to know! 
> 
> So, it sounds like you were seeing XFCE invoking "xscreensaver-command 
> -deactivate" directly, is that right? That would have been happening here:
> 
> https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/2969f0b1ddb60ccda2989c6da6977ab51c75dfd7/src/xfce-screensaver.c#L122
> 
> However it looks like that's a fallback, and first it would have tried to 
> connect to DBus, meaning you should have seen diagnostics from 
> xscreensaver-systemd instead:
> 
> https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/2969f0b1ddb60ccda2989c6da6977ab51c75dfd7/src/xfce-screensaver.c#L233
> 
> Is xscreensaver-systemd not running for you?

It's running:

~$ ps ax | grep xscree
 145156 pts/6S  0:35 xscreensaver -v -v -v --log /home/username/xsvr-log
 145158 pts/6S  0:00 xscreensaver-systemd --verbose
 242602 pts/6S+ 0:00 grep xscree

I don't know whether I'm seeing "xscreensaver-command
-deactivate" or xscreensaver-systemd diagnostics. Where should I look
for these? The xscreensaver log just contains lines of the form:

xscreensaver: nn:nn:nn: ClientMessage DEACTIVATE: already inactive, resetting 
activity time

I don't see any mentions of "xscreensaver-command -deactivate" or systemd. 
Should I be looking somewhere else?

Thanks for the help, and thanks for your work on xscreensaver!

-- 
Celejar

Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)

[James Addison]

Package: python3-dateutil
Followup-For: Bug #1003044

I'm unable to replicate a matplotlib failure so far when using:

  * python3-dateutil 2.8.2-1

  * python3-matplotlib 3.6.3-1+b1

The repro step attempted was to open a Python interpreter session and to enter:

  from matplotlib.dates import DateFormatter

(that succeeded and did not emit any output)

Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')

[James Addison]

Source: feynmf
Followup-For: Bug #1029439

Hi Thorsten,

I'm not completely sure yet (my TeX-foo isn't that great), but I have narrowed
the cause of the problem down.

It looks like the problem is something to do with the '\textlogo' command that
is used when the 'mflogo.sty' TeX package is available.  It is referenced once
in the 'feynmf.dtx' file, and this appears to be what leads to the build
failure.

If that clue is useful for you or someone else, please feel free to use that
to develop a fix.  I'm continuing to investigate.

Thanks,
James

Bug#1030747: Acknowledgement (fuser(1) tries to use statx() which is not available on older kernels and prints misleading error when it can't)

[Andras Korn]

fwiw, psmisc 23.5-3 still works even if the kernel doesn't support statx().

The changelog for 23.6 says "fuser: Use modern statn where possible", but it's 
regrettably also used where not possible.

András

-- 
Is 6 afraid of 7, 'cause 7 8 9?

Bug#1031293: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z

[Peter Pentchev]

On Tue, Feb 21, 2023 at 12:39:53AM +0200, Peter Pentchev wrote:
> On Mon, Feb 20, 2023 at 05:23:28PM -0500, Boyuan Yang wrote:
> > Hi,
> > 
> > 在 2023-02-21星期二的 00:38 +0530，Nilesh Patra写道：
> > > On Fri, 17 Feb 2023 07:51:48 +0100 Lucas Nussbaum 
> > > wrote:
> > > > Source: python-zstandard
> > > > Version: 0.19.0-3
> > > > Severity: serious
> > > > Justification: FTBFS
> > > > Tags: bookworm sid ftbfs
> > > > User: lu...@debian.org
> > > > Usertags: ftbfs-20230216 ftbfs-bookworm
> > > > 
> > > > Hi,
> > > > 
> > > > During a rebuild of all packages in sid, your package failed to build
> > > > on amd64.
> > > 
> > > At the moment this is creating quite
> > > the havoc with making a bunch of things FTBFS as well (see merhged bugs)
> > > 
> > > This is likely due to py-zst trying to link with the zstandard in the
> > > archive
> > > which does not seem to go very well.
> > > 
> > > Is someone working to fix this?
> > 
> > Thanks for cc-ing. I did not monitor bugs for this package before.
> > 
> > Upstream just released v0.20.0 targeting libzstd 1.5.4. I will try it out
> > and have it packaged.
> > 
> > On the long run, the mismatch of src:libzstd and src:python-zstandard will
> > always occur intermittently due to its nature. I am not sure whether re-
> > enabling bundled libzstd would be a good choice, but at least let's fix the
> > combination for Debian 12 first.
> > 
> > Any suggestions?
> 
> Oof. Sorry about that. I guess I didn't consider the python-zstandard
> package at all until now.
> 
> As I am a member of both the pkg-rpm and pkg-python teams, I could try to
> update the packages in sync from now on, possibly adding something like
> Breaks: python-zstandard (<< version-I-am-about-to-upload-in-sync) to
> libzstd itself if it breaks the then-current python-zstandard package.

(of course, I meant Breaks: python3-zstandard (<< ...))

...of course, another - or rather, an additional - option would be to
relax (or remove) the check that python-zstandard makes regarding
the libzstd version recorded at compile time. Since both libzstd
upstream and the Debian package tries to hold true to the usual
semver-like compatiblity scheme, python-zstandard ought to be able to
believe that even a more recent version of libzstd would be ABI-compatible
unless it has reason to think otherwise - and that case could be handled
by Breaks: python3-zstandard (<< next-version) in libzstd as outlined
above. So maybe (for future new upstream versions of libzstd):
- relax (or remove) the python3-zstandard check for the libzstd version
- each time a new libzstd upload is about to be done, check that
  python3-zstandard works, too
- if it works, do nothing else, upload libzstd as usual
- if python3-zstandard would for some reason break and needs updating,
  hold off with the libzstd upload until an updated version of
  python3-zstandard is released upstream, make sure it will work, and
  only then upload libzstd with a Breaks declaration
- upload the updated version of python3-zstandard immediately (maybe
  even simultaneously) and declare a Depends relationship on
  the just-uploaded version of libzstd (as it does now)

If this sounds good, I believe I can do it that way for future libzstd
uploads.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Gunnar Wolf]

Hello Scarlett,

Scarlett Moore dijo [Sun, Feb 19, 2023 at 09:01:56AM -0700]:
> Package: wnpp
> Severity: wishlist
> Owner: Scarlett Moore 
> X-Debbugs-Cc: debian-de...@lists.debian.org, sgmo...@debian.org
> 
> * Package name: gum
>   Version : 0.9.0
>   Upstream Author : Charmbracelet Inc.
> * URL : https://github.com/charmbracelet/gum
> * License : MIT
>   Programming Lang: Golang
>   Description : A tool for glamourous shell scripts
> 
> A tool for glamorous shell scripts. Leverage the power of Bubbles and 
> Lip Gloss in your scripts and aliases without writing any Go code!

I urge you to use a clearer explanation for the Description field --
The short description is fine,but the long description leaves me
scratching my head. Bubbles and Lip Gloss? Never heard of them. Bash
supports aliases, why the need to pull in Go? etc.

Thanks,

Bug#1031478: nrepl-clojure: FTBFS: Build randomly either hangs or fails with test errors

[Santiago Vila]

severity 1031478 important
retitle 1031478 nrepl-clojure: FTBFS: Build randomly either hangs or fails with 
test errors
reopen 1031478
thanks

Hello.

I can't build this package reliably. At some point I was able to get
the "Build killed with signal TERM" error reported by Lucas.

But now that I tried to reproduce that, the build always fails
with test errors.

(Note: I'm going to assume to simplify that the reason for these build failures
is related to the hang reported by Lucas. If this is not ok please tell me
and I will open another different bug).

I attach a sample build log (it's on arm64 but only because I had
those already running right now, I have also build failures on amd64).

I'm testing this with machines with 1 CPU and machines with 2 CPUs,
and I've noticed that the failure rate when using machines with 1 CPU
is a lot higher.

Therefore, to reproduce, please try GRUB_CMDLINE_LINUX="nr_cpus=1"
in /etc/default/grub. If that does not work, please contact me
privately, as I can offer ssh access to a machine where
this happens all the time.

Thanks.

nrepl-clojure_1.0.0-4_arm64-20230220T222034.889Z.gz
Description: application/gzip

Bug#1031471: guestfs-tools: FTBFS: make[5]: *** [Makefile:1073: test-suite.log] Error 1

[Hilko Bengen]

control: tag -1 confirmed

I have been able to confirm the test failure in an unstable/amd64
schroot environment.

Cheers,
-Hilko

Bug#1031293: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z

[Peter Pentchev]

On Mon, Feb 20, 2023 at 05:23:28PM -0500, Boyuan Yang wrote:
> Hi,
> 
> 在 2023-02-21星期二的 00:38 +0530，Nilesh Patra写道：
> > On Fri, 17 Feb 2023 07:51:48 +0100 Lucas Nussbaum 
> > wrote:
> > > Source: python-zstandard
> > > Version: 0.19.0-3
> > > Severity: serious
> > > Justification: FTBFS
> > > Tags: bookworm sid ftbfs
> > > User: lu...@debian.org
> > > Usertags: ftbfs-20230216 ftbfs-bookworm
> > > 
> > > Hi,
> > > 
> > > During a rebuild of all packages in sid, your package failed to build
> > > on amd64.
> > 
> > At the moment this is creating quite
> > the havoc with making a bunch of things FTBFS as well (see merhged bugs)
> > 
> > This is likely due to py-zst trying to link with the zstandard in the
> > archive
> > which does not seem to go very well.
> > 
> > Is someone working to fix this?
> 
> Thanks for cc-ing. I did not monitor bugs for this package before.
> 
> Upstream just released v0.20.0 targeting libzstd 1.5.4. I will try it out
> and have it packaged.
> 
> On the long run, the mismatch of src:libzstd and src:python-zstandard will
> always occur intermittently due to its nature. I am not sure whether re-
> enabling bundled libzstd would be a good choice, but at least let's fix the
> combination for Debian 12 first.
> 
> Any suggestions?

Oof. Sorry about that. I guess I didn't consider the python-zstandard
package at all until now.

As I am a member of both the pkg-rpm and pkg-python teams, I could try to
update the packages in sync from now on, possibly adding something like
Breaks: python-zstandard (<< version-I-am-about-to-upload-in-sync) to
libzstd itself if it breaks the then-current python-zstandard package.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1031293: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z

[Boyuan Yang]

Hi,

在 2023-02-21星期二的 00:38 +0530，Nilesh Patra写道：
> On Fri, 17 Feb 2023 07:51:48 +0100 Lucas Nussbaum 
> wrote:
> > Source: python-zstandard
> > Version: 0.19.0-3
> > Severity: serious
> > Justification: FTBFS
> > Tags: bookworm sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20230216 ftbfs-bookworm
> > 
> > Hi,
> > 
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> 
> At the moment this is creating quite
> the havoc with making a bunch of things FTBFS as well (see merhged bugs)
> 
> This is likely due to py-zst trying to link with the zstandard in the
> archive
> which does not seem to go very well.
> 
> Is someone working to fix this?

Thanks for cc-ing. I did not monitor bugs for this package before.

Upstream just released v0.20.0 targeting libzstd 1.5.4. I will try it out
and have it packaged.

On the long run, the mismatch of src:libzstd and src:python-zstandard will
always occur intermittently due to its nature. I am not sure whether re-
enabling bundled libzstd would be a good choice, but at least let's fix the
combination for Debian 12 first.

Any suggestions?

Thanks,
Boyuan Yang


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

Bug#1027917: wxwidgets3.2 FTCBFS: deliberately broken by upstream

[Scott Talbert]

On Mon, 20 Feb 2023, Helmut Grohne wrote:


Hi Scott,

On Mon, Feb 13, 2023 at 12:21:19PM -0500, Scott Talbert wrote:

It seems that upstream has fixed this particular problem in the recent 3.2.2
release (and the crossqa checks seem to indicate further progress).


I think "this particular problem" is fairly imprecise when the original
report mentions two problems. The first of these was breaking pkg-config
and this part indeed looks fixed to me.


Although it seems there still might be further problems (on the packaging
side?).


The other problem about changed toolchain names persists and my
understanding is that it is what makes the build fail.


Yes, I sent that email before I had looked into the details and was 
overly optimistic about the upstream fix.


Sorry,
Scott

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Lynn Winebarger]

On Mon, Feb 20, 2023, 4:34 PM Stefan Monnier 
wrote:

> > Just to be clear, this condition should be checked before emacs is
> > willing to use the temporary directory in question.  No unprivileged
> > user should be able to overwrite a directory entry the uid of the
> > emacs process creates at any point in the path to the temporary file.
>
> AFAIK we usually consider it's up to the user/system to make sure this
> is the case.


That seems like a pretty aggressive assumption for this functionality.

Lynn

Bug#964279: [deluge] TypeError: '>' not supported between instances of 'NoneType' and 'NoneType'

[Lyndon Brown]

fixed 964279 2.1.1-1
thanks

Hi,

Thanks for taking this package on and updating it.

I believe I meant journalctl, though you can also see it simply from
running in a terminal.

Having just updated to 2.1.x from experimental and running in a
terminal, a whole ton of errors/warnings, including this one, that
2.0.x was generating, have now disappeared - yay! So yes, this can be
closed.

Thanks again.

On Mon, 2023-02-20 at 09:13 +0100, Daniel Baumann wrote:
> Hi Lyndon,
> 
> thank you for your report.
> 
> I didn't find any of these with deluge 2.1.1-1, in order to confirm
> that
> this is fixed - where exactly would I find these messages?
> 
> Regards,
> Daniel

Bug#1031706: optuna: test_create_new_trial randomly fails on s390x

[Rebecca N. Palmer]

Package: python3-optuna
Severity: serious
Control: affects -1 python3-pandas

test_create_new_trial (both parts) sometimes fails on s390x, failing the 
autopkgtest.


It might make sense to remove this package on s390x, if it isn't 
reasonable to actually fix this.

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Tatsuya Kinoshita]

On 2023-02-20 at 20:22 +, Andrea Corallo wrote:
> I've installed 5d0b45cd67b on emacs-29 in order to use always
> `make-temp-file'.

Please be careful with the difference between make-temp-file-internal
and make-temp-file.

> +++ b/lisp/emacs-lisp/comp.el
>  (expand-file-name
> - (make-temp-file-internal (file-name-sans-extension rel-filename)
> -  0 ".eln" nil)
> + (make-temp-file (file-name-sans-extension rel-filename) 0 ".eln"
> + nil)
>   temporary-file-directory

This second argument of make-temp-file should be nil, and expanding
against temporary-file-directory is already done by make-temp-file.

Thanks,
-- 
Tatsuya Kinoshita

Bug#1031705: pymatgen: 7th item of test_babel randomly hangs autopkgtest

[Rebecca N. Palmer]

Package: python3-pymatgen
Severity: serious
Control: affects -1 python3-pandas

The autopkgtest sometimes times out, and when it does, the last line is 
io/tests/test_babel.py and 6 'pass' dots, implying that the 7th item hung.


All known instances are on amd64.

Bug#1031701: python3-pandas: Pandas requires version '2.0.1' or newer of 'xlrd'

[Rebecca N. Palmer]

Is the file you're trying to open .xlsx or .xls?  Do you have 
python3-openpyxl installed?  If .xlsx and no, try installing it.


(python3-)xlrd 2.0+ can only open .xls files, not .xlsx.  Hence, pandas 
1.5+ read_excel() always uses (python3-)openpyxl for .xlsx files. 
python3-pandas already Recommends python3-openpyxl.  (This intentionally 
isn't a hard Depends because pandas can be used on other data formats 
without it, but the error message probably should point to openpyxl not 
xlrd.)

Bug#1031701: python3-pandas: Pandas requires version '2.0.1' or newer of 'xlrd'

[Christopher Jones]

Hi,

Sadly they really are .xls files rather than the more slightly more sane .xlsx.

Thanks!

—
Chris

> On 20 Feb 2023, at 22:39, Rebecca N. Palmer  wrote:
> 
> Is the file you're trying to open .xlsx or .xls?  Do you have 
> python3-openpyxl installed?  If .xlsx and no, try installing it.
> 
> (python3-)xlrd 2.0+ can only open .xls files, not .xlsx.  Hence, pandas 1.5+ 
> read_excel() always uses (python3-)openpyxl for .xlsx files. python3-pandas 
> already Recommends python3-openpyxl.  (This intentionally isn't a hard 
> Depends because pandas can be used on other data formats without it, but the 
> error message probably should point to openpyxl not xlrd.)

Bug#1027917: wxwidgets3.2 FTCBFS: deliberately broken by upstream

[Helmut Grohne]

Hi Scott,

On Mon, Feb 13, 2023 at 12:21:19PM -0500, Scott Talbert wrote:
> It seems that upstream has fixed this particular problem in the recent 3.2.2
> release (and the crossqa checks seem to indicate further progress).

I think "this particular problem" is fairly imprecise when the original
report mentions two problems. The first of these was breaking pkg-config
and this part indeed looks fixed to me.

> Although it seems there still might be further problems (on the packaging
> side?).

The other problem about changed toolchain names persists and my
understanding is that it is what makes the build fail.

Helmut

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Stefan Monnier]

> Just to be clear, this condition should be checked before emacs is
> willing to use the temporary directory in question.  No unprivileged
> user should be able to overwrite a directory entry the uid of the
> emacs process creates at any point in the path to the temporary file.

AFAIK we usually consider it's up to the user/system to make sure this
is the case.


Stefan

Bug#991408: Netbeans: source code problem

[Leandro Cunha]

Hi,

>From the tracking I did, I saw that several packages that had this lib
as a dependency, the maintainers removed it, with the exception of one
that has been outdated by upstream since 2008.
Have more here:
https://www.cs.brandeis.edu/~hosang/BiVoSite/API/org/netbeans/lib/awtextra/AbsoluteLayout.html

-- 
Cheers,
Leandro Cunha
-BEGIN PGP SIGNATURE-

iQKTBAABCgB9FiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAmPznxFfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD
RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQACgkQ2a0UuVE7
UeTatw/9G9EROjkvzc/8U7qf0mXrocdQCoauNzNtYUmTnjmh2rI403yVO1ToUlOp
PUBCXFaMioou006Vbv0j+vakzTxxKxYePOA177YfzAX2DUcqLX6r7X0b0rcLmBmI
bD6qAoGoJQvwpv0+TvNSxoVIun5wyk8lsXkdup/IRLjN7lOuF3zwz+dlmwcMiEYt
cG9yTrP9pYhv/oEI1hEv8XpjP1rbyWFdDmfs4yW7lLSvZFrj11hfUZvvZIfw4yGD
/iS6GsYi6MrxIC/HzIxGZw4rQ3Kns6uqV4gSuXTEDLtEjSVJV+gDXHh1IZsZ8W8A
Bg9sa5k+tpvOcHGwqk4ID1WwZ85jh3IbAaqnNgfLo1FuQhWWSovH7g1SPFZA1Bbb
AMR/wQgod3lx1g0dmLdXoxaAJO3A8hzPK4ry+7yVi3+xEkTTROBpur2XTJshG4JP
wW9jUdCgsyTcEyv9mIwnhlYTrvHQz1qlIqNTzM/bxUFMt5AIfkjg/i4bj/wMzYVk
a/OcU3mdigTpuVCn4AsQ5fM8o44hI54l4BffxDtnR8wxfuDedMSWzLIjoHOClngx
hPCx9JT85M9TBLOCvE1lZQqVUxv7F/pTHejmR29I3iR1dC9PT6ohdYOdYfKe
rcnHp7rYH4Mc2QqRsOdk5bSDV39hpm35kvWqOtVPLQaJS3LC194=
=zkVy
-END PGP SIGNATURE-

Bug#1031704: Wish: Timeout for presentation mode

[Charles Curley]

Package: xfce4-power-manager
Version: 4.16.0-1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: charlescur...@charlescurley.com

Dear Maintainer,

Presentation mode is very nice for watching movies, etc. However, one can 
forget that one has turned it on. And apparently I'm not the only one. 
https://bugzilla.xfce.org/show_bug.cgi?id=14210 And I conjecture that some 
people go to sleep during a movie, in which case not having a laptop screen on 
all night would be nice.

It would be very nice if presentation mode had a time-out timer: after a user 
supplied number of minutes, it turns itself off. This could be made available 
via a slider, thumbwheel, or text entry box adjacent to the presentation mode 
slider switch. This could be in addition to the slider switch or possibly 
replace it if you are pressed for code space or display real estate.

I am using XFCE 4.16. I see no evidence of this in the change log for 4.18. 
https://xfce.org/download/changelogs/4.18

Thank you.

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

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

Versions of packages xfce4-power-manager depends on:
ii  libc6 2.31-13+deb11u5
ii  libcairo2 1.16.0-5
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4+deb11u2
ii  libnotify40.7.9-3
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libupower-glib3   0.99.11-2
ii  libx11-6  2:1.7.2-1
ii  libxext6  2:1.3.3-1.1
ii  libxfce4ui-2-04.16.0-1
ii  libxfce4util7 4.16.0-1
ii  libxfconf-0-3 4.16.0-2
ii  libxrandr22:1.5.1-1
ii  upower0.99.11-2
ii  xfce4-power-manager-data  4.16.0-1

Versions of packages xfce4-power-manager recommends:
ii  libpam-systemd [logind]  247.3-7+deb11u1
ii  xfce4-power-manager-plugins  4.16.0-1

xfce4-power-manager suggests no packages.

-- no debconf information

Bug#1031703: rich: Missing dh-python in Build-Depends

[Danilo Egea Gondolfo]

Source: rich
Version: 13.3.1-1
Severity: normal

Dear Maintainer,

as this package depends on dh-python helpers to be built, should 
dh-python be added to Build-Depends like other python-based packages?



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

Kernel: Linux 6.1.0-14-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en

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

Bug#1031702: mailutils: (locale-dependent) SEGV reading mail

[Dave Love]

Package: mailutils
Version: 1:3.10-3+b1
Severity: normal
X-Debbugs-Cc: none, Dave Love 

I get a consistent SEGV if I try to read mail with mailutils mail(1),
which is sometimes useful.  It turns out to be a function of the locale,
which will affect all Debian versions.  I sent a patch to bug-mailutils
which would be useful to add:
https://lists.gnu.org/archive/html/bug-mailutils/2023-02/msg0.html

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads)
Kernel taint flags: 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 mailutils depends on:
ii  libc6 2.31-13+deb11u5
ii  libcrypt1 1:4.4.18-4
ii  libfribidi0   1.0.8-2+deb11u1
ii  libgnutls30   3.7.1-5+deb11u3
ii  libgsasl7 1.10.0-4+deb11u1
ii  libldap-2.4-2 2.4.57+dfsg-3+deb11u1
ii  libmailutils7 1:3.10-3+b1
ii  libncurses6   6.2+20201114-2
ii  libpam0g  1.4.0-9+deb11u1
ii  libreadline8  8.1-1
ii  libtinfo6 6.2+20201114-2
ii  libunistring2 0.9.10-4
ii  mailutils-common  1:3.10-3

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

Versions of packages mailutils suggests:
pn  mailutils-doc  
pn  mailutils-mh   

-- no debconf information

Bug#1031698: RFS: dhcpdump/1.8-5 [QA] -- Parse DHCP packets from tcpdump

[Adam Borowski]

On Mon, Feb 20, 2023 at 05:10:34PM -0300, Jpaulo wrote:
>  dhcpdump (1.8-5) experimental; urgency=medium
>  .
>* QA upload.
>* debian/control:
>- Set Rules-Requires-Root:no.
>- Set homepage-field.
>- Bumped Standards-Version to 4.6.1.
>- Set debhelper-compat version in Build-Depends.
>- Added Depends ${shlibs:Depends} in Depends fields.
>* debian/rules:
>- Rewrite to use dh-sequencer.
>* debian/metadata:
>- Added missing upstream metadata.
>- Added upstream's key.
>* debian/watch:
>- Add watch file.

Hi!
I believe it's better if packages carry some non-metadata contents, which
the new version currently lacks...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Q: Is it ok to combine wired, wifi, and/or bluetooth connections
⢿⡄⠘⠷⠚⠋⠀in wearable computing?
⠈⠳⣄ A: No, that would be mixed fabric, which Lev19:19 forbids.

Bug#1031701: python3-pandas: Pandas requires version '2.0.1' or newer of 'xlrd'

[Christopher Jones]

Package: python3-pandas
Version: 1.5.3+dfsg-1
Severity: normal

Dear Maintainer,

When attempting to use pandas read_excel function I get the following error 
message:
ImportError: Pandas requires version '2.0.1' or newer of 'xlrd' (version 
'1.2.0' currently installed).

xlrd 1.2 appears to be the latest currently available release packaged for 
Debian.

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

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Lynn Winebarger]

On Mon, Feb 20, 2023 at 11:02 AM Stefan Monnier
 wrote:
> > So I guess one could remove the file after the first creation and make
> > it a link pointing to some other file waiting for libgccjit to do
> > its write.
>
> "One" as in "an attacker"?  In `/tmp` an attacker should not be able to
> do that because it's supposed to be using the sticky bit so that only
> the owner of a file can remove it.

Just to be clear, this condition should be checked before emacs is
willing to use the temporary directory in question.  No unprivileged
user should be able to overwrite a directory entry the uid of the
emacs process creates at any point in the path to the temporary file.

Lynn

Bug#1031700: Audio s/pdif selection in gnome quick settings (bookworm )

[dev . lkq1u]

Package: pipewire-audio
Version: 0.3.65-1

In Debian Bookworm since an update on 2023-02-24 of pipewire-audio and its 
dependencies
In the gnome interface, quick settings no longer show different audio outputs 
if another is selected
The problem occurs if an s/pdif output is selected
In gnome settings, all audio outputs are always available at all times.
A simple logout and login will allow you to recover the audio selections in the 
quick settings.

Bug#1030382: encourage Vcs-Git over other Vcs-* headers

[Bill Allombert]

On Mon, Feb 20, 2023 at 01:59:21PM +, Jelmer Vernooij wrote:
> On Thu, Feb 09, 2023 at 02:15:42PM -0700, Sean Whitton wrote:
> > Hello,
> > 
> > On Fri 03 Feb 2023 at 05:24PM GMT, Jelmer Vernooij wrote:
> > 
> > > Package: debian-policy
> > > Severity: wishlist
> > >
> > > Policy currently describes Vcs-* headers as something optional, but stops 
> > > to
> > > endorse a particular Vcs.
> > >
> > > At this point, it seems uncontroversial to encourage use of Vcs-Git
> > > specifically here. Apart from technical arguments, it's the vcs that the
> > > majority of packages in the archive uses - and thus will have the better
> > > tooling, less of a learning curve for other contributors, etc.
> > >
> > > There are very few holdouts of other vcses in the archive. I count 62
> > > (ignoring those with an alioth URL):
> > >
> > >  * 26 on Svn
> > >  * 3 on Cvs
> > >  * 4 on Hg (2 are hg/hg-buildpackage)
> > >  * 39 on bzr (half of these are actually bzr and related packages, which 
> > > I maintain)
> > 
> > This strikes me as a matter for devref not Policy?
> 
> I've created a PR for devref - 
> https://salsa.debian.org/debian/developers-reference/-/merge_requests/41
> 
> Are you saying that it doesn't belong in policy because it'd be a
> recommendation rather than a must/should (at this point?), or because it's 
> more about the
> workflow inside of Debian than package contents?

Yes this is about the workflow and not the package, and so far we have let 
developpers pick
whatever workflows suit them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1029803: command-not-found breaks dist-upgrade bullseye → bookworm

[Julian Andres Klode]

Sorry on my phone, but thank you and please do go ahead with the change!

Paul Gevers  schrieb am Mo., 20. Feb. 2023, 16:24:

> Control: tags -1 patch
>
> Hi,
>
> On 19-02-2023 21:22, Paul Gevers wrote:
> > On Sat, 28 Jan 2023 00:51:39 +0100 Lee Garrett 
> > wrote:
> >> This is already fixed in unstable, but in it's current form this will
> >> break the
> >> upgrade path from bullseye to bookworm. The fix is trivial, adding
> >> `'non-free-firmware': 60,` to CommandNotFound/db/creator.py is enough.
> >> I propose
> >> doing a p-u to fix it.
> >
> > What do you think of that? Are you OK if I prepare the upload?
>
> I have the attached debdiff ready to handle with the stable release
> managers.
>
> Paul
>

Bug#1031699: python-future: CVE-2022-40899

[Salvatore Bonaccorso]

Source: python-future
Version: 0.18.2-6
Severity: important
Tags: security upstream
Forwarded: https://github.com/PythonCharmers/python-future/pull/610
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-future.

CVE-2022-40899[0]:
| An issue discovered in Python Charmers Future 0.18.2 and earlier
| allows remote attackers to cause a denial of service via crafted Set-
| Cookie header from malicious web server.


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-2022-40899
https://www.cve.org/CVERecord?id=CVE-2022-40899
[1] https://github.com/PythonCharmers/python-future/pull/610
[2] 
https://github.com/PythonCharmers/python-future/commit/c91d70b34ef0402aef3e9d04364ba98509dca76f
 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Andrea Corallo]

Eli Zaretskii  writes:

>> From: Andrea Corallo 
>> Cc: monn...@iro.umontreal.ca,  t...@debian.org,  emacs-de...@gnu.org,
>>   spwhit...@spwhitton.name,  1021...@bugs.debian.org
>> Date: Mon, 20 Feb 2023 15:42:08 +
>> 
>> > You mean, from master to emacs-29, I guess?
>> 
>> Yes
>> 
>> > What was the motivation for that change?  The log message doesn't
>> > explain the problem it meant to solve in enough detail, it just says
>> > something about creating the file twice?  How can that happen? who
>> > creates the file the second time?
>> 
>> Before e6043641d30 the file was created by Fmake_temp_file_internal and
>> afterwards overwritten by libgccjit.  So I guess one could remove the
>> file after the first creation and make it a link pointing to some other
>> file waiting for libgccjit to do its write.
>
> Then it's okay to cherry-pick it to emacs-29.  (I actually am not sure
> why we didn't install it on emacs-29 to begin with, but never mind.)

I didn't install it at the time in emacs-29 as I thought this had
nothing to do with security.  Anyway this turned out not to be the best
solution, so after today's discussion in this thread I've installed
5d0b45cd67b into emacs-29 as should be the optimal fix.

Note there will be conflict in mergin 29 into 30 and we'll have to
accept the change in 29 (sorry never managed to get gitmerge.el working
here).

Best Regards

  Andrea

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Andrea Corallo]

Stefan Monnier  writes:

>> Before e6043641d30 the file was created by Fmake_temp_file_internal and
>> afterwards overwritten by libgccjit.
>
> Yes, that was good.
>
>> So I guess one could remove the file after the first creation and make
>> it a link pointing to some other file waiting for libgccjit to do
>> its write.
>
> "One" as in "an attacker"?  In `/tmp` an attacker should not be able to
> do that because it's supposed to be using the sticky bit so that only
> the owner of a file can remove it.

Finally understood thanks!

I've installed 5d0b45cd67b on emacs-29 in order to use always
`make-temp-file'.

I think at the time I preferred Fmake_temp_file_internal not to call
into Lisp for some reason I can't remember now, anyway seems to work now
for me (just bootstrapped successfully).

  Andrea

Bug#1031698: RFS: dhcpdump/1.8-5 [QA] -- Parse DHCP packets from tcpdump

[Jpaulo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : dhcpdump
   Version  : 1.8-5
 * URL  : http://www.mavetju.org/download/
 * License  : BSD-2-clause
   Section  : admin

The source builds the following binary packages:

  dhcpdump - Parse DHCP packets from tcpdump

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dhcpdump/dhcpdump_1.8-5.dsc

Changes since the last upload:

 dhcpdump (1.8-5) experimental; urgency=medium
 .
   * QA upload.
   * debian/control:
   - Set Rules-Requires-Root:no.
   - Set homepage-field.
   - Bumped Standards-Version to 4.6.1.
   - Set debhelper-compat version in Build-Depends.
   - Added Depends ${shlibs:Depends} in Depends fields.
   * debian/rules:
   - Rewrite to use dh-sequencer.
   * debian/metadata:
   - Added missing upstream metadata.
   - Added upstream's key.
   * debian/watch:
   - Add watch file.

Regards,
-- 
  Joao Paulo

Bug#722719: initscript for deluge-web

[Daniel Baumann]

close 722719
thanks

Hi,

given that the current package has a systemd unit for deluge-web (which
needs fixing though, #996975), it doesn't make sense to add a
initscript, so closing the bug.

Regards,
Daniel

Bug#691649: deluged: Move umask setting to /etc/default/deluged

[Daniel Baumann]

retitle 691649 make default umask configurable
tag 691649 - patch
severity 691649 wishlist
thanks

Hi,

thank you for reporting this and thanks for the patch (this needs to be
reworked for the systemd integration). I'll make it configurable and add
a debconf question for this in one of the next uploads in the next few days.

Regards,
Daniel

Bug#997948: FPC should provide a way to trigger automatic rebuild of

[Paul Gevers]

Hi Abou,

On 18-02-2023 12:17, Abou Al Montacir wrote:

On Thu, 2021-12-30 at 22:30 +0100, Abou Al Montacir wrote:

Maybe we should move
the fp-units-$bar packages to the library section too and embed the ABI
version into the package name.


I like that idea. Let's go that way.

...

I don't think fp-unit-* make sense in the lib section.
I think that the best place for /fp-units-*/ is /libdevel/ as they are 
very similar to the /foo-dev/ packages.


Ack.

what do you think? Will this solve the issue with regards to the release 
team script, or it handle only /lib/ section in that particular way?


The Release Team scripts don't care about the section, they look at 
installability. But if we compare the units to C libraries, we normally 
asks library maintainers to *not* version the dev packages, because then 
all reverse build dependencies need an update when the SONAME gets 
bumped, making the transition process very labor-some.


What we want to achieve here is a way to ensure packages are rebuild 
(semi) automatically when the units require it. But we *also* want to 
come up with a way that doesn't require changes in the reverse 
dependencies at the same time. Consider also that adding new binary 
packages require a trip through NEW. Would it make sense that every unit 
provides a virtual abi package, which get embedded in the dependencies 
during build time, such that when a unit bumps the virtual abi, the 
release team tools notice and rebuilds can be triggered? Or is that what 
we already more or less do?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#695752: deluge: Specific port defined but it takes random one in every start. UPnP and NAT-PMP unchecked.

[Daniel Baumann]

close 695752 2.1.1-1
thanks

Hi,

thank you for reporting this, it has been fixed somewhen in the 2.x
uploads as I coudn't reproduce it with the current version, hence
closing this bug.

Regards,
Daniel

Bug#1029342: jexec: can't locate java: No such file or directory

[James Addison]

Package: openjdk-17-jre-headless
Followup-For: Bug #1029342

Looking at codesearch[1] for the word 'jexec', most of the contexts that appear
are from one of a few categories:

  * The code of OpenJDK itself

  * Scripts/code intended to run in FreeBSD environments (where 'jexec' is
used to run a command within a jail)

  * The 'XB-Cnf-Extra-Commands' control file header in java-common (listing
missing commands that will hint the user to install the package)

Perhaps we could safely remove 'jexec' from the Debian-distributed OpenJDK?

[1] - https://codesearch.debian.net/search?q=%5Cbjexec%5Cb=0=1

Bug#939615: rtkit: Flooding syslog

[Dave Love]

Modifying the systemd message level, as suggested in
https://github.com/heftig/rtkit/pull/26#issuecomment-1361251871 seems to
do the trick.  I think that should be shipped in the absence of upstream
movement.

Bug#1031697: libx11-xcb1: Please update to 1.8.4 - Apps crashing under wayland due to bugs caused by patches in 1.8.3

[Safir Secerovic]

Package: libx11-xcb1
Version: 2:1.8.3-3
Severity: important
Tags: upstream
X-Debbugs-Cc: stephanlach...@debian.org, tjaal...@debian.org

Dear Developer,

Could You please update the package to the new upstream version of 1.8.4
The new version 1.8.4 has been months in the making and it fixes significant 
bugs [1] that also affect
gamescope on wayland usage (both the current versions already and Debian and 
the upcoming upstream).

It is a maintenance update with no ABI change, so no transition necessary...

When trying to run app through gamescope on KDE Plasma Wayland and GNOME 
Wayland, the types of crashes occurs:
For example: 

gamescope -H 1080 -f -- env MESA_LOADER_DRIVER_OVERRIDE=zink MANGOHUD=1  
gamemoderun ./heaven

The crash message: 

heaven_x64: ../../src/xcb_in.c:757: xcb_request_check: Assertion `!reply' 
failed.
(EE) failed to read Wayland events: Broken pipe
browser_x64: Fatal IO error: client killed

It would be a shame for the Bookworm not to have this fixed...

I have tested/rebuilt the Debian 1.8.3 source without these two patches: 
0003-Revert-Fix-797755-Allow-X-IfEvent-to-reenter-libX11.patch
0004-Revert-Allow-X-IfEvent-to-reenter-libX11.patch

And the bug is fixed!  It seems that the newly released libx11 1.8.4 version 
fixes this bug.

Kind regards,
Safir 

[1] https://github.com/godotengine/godot/issues/69352

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

Kernel: Linux 6.1.12-3-liquorix-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libx11-xcb1 depends on:
ii  libx11-6  2:1.8.3-3

libx11-xcb1 recommends no packages.

libx11-xcb1 suggests no packages.

-- no debconf information

Bug#1014782: The problem remains

[Jamie Zawinski]

On Feb 20, 2023, at 9:44 AM, Celejar  wrote:
> 
> It turns out that the DEACTIVATEs were being sent by the Xfce Power
> Manager's Presentation Mode. I'm not sure I was even aware of that
> mode's existence, but it apparently has a long history of becoming
> turned on without the conscious intention or awareness of the user :)

Good to know! 

So, it sounds like you were seeing XFCE invoking "xscreensaver-command 
-deactivate" directly, is that right? That would have been happening here:

https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/2969f0b1ddb60ccda2989c6da6977ab51c75dfd7/src/xfce-screensaver.c#L122

However it looks like that's a fallback, and first it would have tried to 
connect to DBus, meaning you should have seen diagnostics from 
xscreensaver-systemd instead:

https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/2969f0b1ddb60ccda2989c6da6977ab51c75dfd7/src/xfce-screensaver.c#L233

Is xscreensaver-systemd not running for you?

-- 
Jamie Zawinski • jwz.org • dnalounge.com

Bug#1031443: python-zstandard: FTBFS: ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10504 returned by the lib, 10504 hardcoded in z

[Nilesh Patra]

On Fri, 17 Feb 2023 07:51:48 +0100 Lucas Nussbaum  wrote:
> Source: python-zstandard
> Version: 0.19.0-3
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230216 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

At the moment this is creating quite
the havoc with making a bunch of things FTBFS as well (see merhged bugs)

This is likely due to py-zst trying to link with the zstandard in the archive
which does not seem to go very well.

Is someone working to fix this?

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1031465: snippy: FTBFS: make[2]: *** [Makefile:32: S1/snps.tab] Error 2

[Nilesh Patra]

Attempting to fix Pjotr's address. Pjotr: if you are reading this, could
you comment on it?

Thanks
Nilesh

On Mon, 20 Feb 2023 17:21:59 +0100 Andreas Tille  wrote:
> Hi Pjotr,
> 
> in contrast to the bug reporter I get in my unstable chroot
> 
> ...
> [15:53:57] Checking version: bcftools --version is >= 1.7 - ok, have 1.16
> [15:53:57] Checking version: freebayes --version is >= 1.1 - ok, have 1.3.6
> [15:53:57] Checking version: snpEff -version is >= 4.3 - ok, have 5.1
> ...
> 
> which looks good regarding the version check of freebayes.  However
> later on the test ends up in:
> 
> 
> Loaded 3 sequences totalling 317336 bp.
> Loading mask bed file: example.bed
> Will mask 8 regions totalling 3101 bp ~ 0.98%
> 0   S1  snp=0   del=0   ins=0   het=0   unaligned=9643
> 1   S2  snp=0   del=0   ins=0   het=81  unaligned=9428
> 2   S3  snp=0   del=0   ins=0   het=0   unaligned=9376
> 3   S4  snp=0   del=0   ins=0   het=0   unaligned=9707
> Opening: core-mask.tab
> Opening: core-mask.vcf
> Processing contig: LBB_contig01
> Processing contig: LBB_contig02
> Processing contig: LBB_contig03
> Masking alignment at 8 regions
> Generating core-mask.full.aln
> Creating TSV file: core-mask.txt
> Running: snp-sites -c -o core-mask.aln core-mask.full.aln
> Warning: No SNPs were detected so there is nothing to output.
> ERROR: Could not run: snp-sites -c -o core-mask.aln core-mask.full.aln
> 
> 
> I'm not sure whether this might be related to some previous freebayes
> call (which is the only package in the list of dependencies that has
> changed) or whether there is some other problem.  I think it is worth
> investigating since snippy might be an interesting test suite for a
> whole bunch of packages.
> 
> Kind regards
>Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 


signature.asc
Description: PGP signature

Bug#1031688: gnome-shell 44~beta crashes immediately unless mutter-common-bin is installed

[Simon McVittie]

On Mon, 20 Feb 2023 at 17:37:48 +0100, Roderich Schupp wrote:
> On Mon, Feb 20, 2023 at 5:27 PM Simon McVittie <[1]s...@debian.org> wrote:
> 
> > Feb 20 15:18:32 nuc8 gnome-shell[7963]: Running GNOME Shell (using 
> mutter
> > 44.beta) as a X11 window and compositing manager
> >        ??? why X11, should be Wayland
> 
> mutter is a Wayland compositor, but it's also an X11 window and 
> compositing
> manager at the same time. Even when running in native-Wayland mode, it
> manages X11 windows (if any) in its Xwayland instance, to provide
> compatibility with older applications.
> 
> Sure, but  the string "Running GNOME Shell (using mutter XXX) as a X11 window
> and compositing manager"
> doesn't appear in my journal at all before installing 44.beta, only the "... 
> as
> a Wayland compositor" variant.

Perhaps there's a separate regression in 44.beta, then - its udev rules
might be forcing mutter-based compositors into X11 mode on systems where
it isn't necessary, or wasn't previously necessary? Please report that
as a separate bug (presumably of lower severity) if you think the wrong
thing is happening.

smcv

Bug#1031478: nrepl-clojure: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[Louis-Philippe Véronneau]

tags 1031478 moreinfo unreproducible
thanks

Hi!

Thanks for the rebuild. I can't reproduce this issue on my machine, but 
I see that neither DebCI (which runs the same exact testsuite, as an 
autopkgtest) nor Reproducible builds [2] (which just rebuilds the 
package) have had issues with this...


The Clojure ecosystem in Debian still isn't the most stable one, and we 
changed a bunch of stuff right before the freeze... Could you give this 
another go and see if you still get a failure?


Cheers,

[1]: https://ci.debian.net/packages/n/nrepl-clojure/

[2]: 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/nrepl-clojure.html


--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000145: followup on debian 11.6

[Ben Dooks]

I've run into the same on Debian 11.6 I think, whilst buidling qemu

/usr/bin/ld: /lib/x86_64-linux-gnu/libtirpc.so.3: warning: common of 
`rpc_createerr@@GLIBC_2.2.5' overridden by definition from 
/lib/x86_64-linux-gnu/libc.so.6


--
Ben Dooks   http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html

Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support

[Pete Batard]

Package: non-free
Version: firmware-11.6.0

Not sure if this is something that should be sent to the official bug 
tracker, since it's an issue with cdimage/unofficial/non-free, but I 
would like to report that the current cd-including-firmware images, such 
as 'firmware-11.6.0-amd64-netinst.iso' have a major issue in that, 
unlike what is the case for the official Debian installation ISOs, such 
as 'debian-11.6.0-amd64-netinst.iso', they do not support UEFI file 
system transposition.


As a reminder, file system transposition means the ability to take the 
content of a UEFI bootable media and copy it, at the file system level, 
to a partition that was independently created and formatted by the user, 
while preserving the ability of the resulting media to still boot in 
UEFI mode (thus leveraging the cornerstone of UEFI, as opposed to BIOS, 
which is the ability to create boot media by copying content at the file 
system level rather than at the block level).


In short, the expectation of many UEFI users -- and I have to commend 
Debian for having done a stellar job over the past few years to ensure 
that this is properly supported with official ISOs through, for 
instance, switching boot media detection to detecting the presence of a 
specific file rather than looking for a specific partition label or UUID 
-- is that they should be able to a USB media to FAT32 and then extract 
the full content from the Debian ISO there, to end up with a media that 
they can use to both boot and install Debian.


This method has the advantage of not relying on a specific utility to be 
able to create the media (noting that even something as basic as 'dd' is 
for instance not available on Windows platforms) to instead rely 
entirely on the native tools provided by their OS, and that have the 
advantage of usually coming with a GUI that users might also be more 
comfortable with.



Now, the problem is that, when using file system transposition, one 
cannot rely on symbolic links (such as the ones used by Rock Ridge on 
top of an ISO9660 file system) to be preserved during ISO file 
extraction, as, for instance, FAT32 has no support for them whereas it 
is the file system most people are likely to use for UEFI file system 
transposition.


Yet, the current '/firmware/' structure of 
'debian-11.6.0-amd64-netinst.iso' is such that a file like:

 '/firmware/amd64-microcode_3.20191218.1_amd64.deb'
is actually a symbolic link to:

'../pool/non-free/f/firmware-nonfree/firmware-amd-graphics_20210315-3_all.deb'

So this means that during file system transposition to FAT32, 
'/firmware/amd64-microcode_3.20191218.1_amd64.deb' will either be lost 
or contain invalid content, and the Debian installer, which is designed 
to look into /firmware/... to look for packages, will be unable to 
locate the firmware files that the people who chose to use 
'firmware-11.6.0-amd64-netinst.iso' want it to be able to locate.


In short, whereas symbolic links are fine for non-critical things like 
documentation, they should not be used for files that need to be located 
by the debian installer, because doing so breaks file system 
transposition support.


As such, we *strongly* recommend, for the sake of making the Debian ISOs 
work for everyone (rather than only those who will copy the image 
through dd, which is a subset of users), that, instead of having 
'/firmware/xyz.deb' symbolic links pointing to 
'../pool/non-free/x/xyz.deb', the reverse should be used, on account 
that '/firmware/' is the directory where Debian-installer will be trying 
to locate the firmware packages and therefore the physical files should 
always reside there.


Or, even better, Debian should look into symbolic links altogether, as 
they can not be relied on and are a source of trouble.


Regards,

/Pete

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Michael Biebl]

Package: debhelper
Version: 13.11.4
Severity: important
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

It appears we currently ship 35 packages in unstable installing 78
service files to /usr/lib/systemd/system which dh_installsystemd doesn't
handle:

$ apt-file search -x ^/usr/lib/systemd/system | wc -l
78

$ apt-file search -x ^/usr/lib/systemd/system | cut -f1 -d':' | sort -u | wc -l
35

This means, those service files are not enabled and (re)started/stopped.

I suspect this is the result of the attempt last year, to move those
files to /usr where lintian warned for a while if files where installed
to /lib, so package maintainers started to update their packaging to
install in /usr instead.

I think dh_installsystemd should pick up files from
/usr/lib/systemd/system in list_installed_units() and then we could just
rebuild those packages.

The alternative is to update all those 35 packages and make sure they
install the files to /lib.


Michael

Bug#991408: Netbeans: problema no código-fonte

[Leandro Cunha]

Hi,

> apt install netbeans will do nothing. The binary package has been removed from
> Debian. The Netbeans source package has always produced libnb-absolutelayout-
> java. There is no inconsistency. You either don't understand the difference
> between a source and a binary package or you are deliberately annoying. In any
> case I won't reply to this bug report anymore.

If I know how to write code in different programming languages for
different industries and I haven't known the difference between binary
and source code for 10 years, I can only dream that I'm writing code.
I don't want to be boring, but this lib, as the description says,
belongs to the netbeans platform and if I install the IDE via flatpak,
for example, I can use it. Of course apt won't do anything as the
package doesn't even exist in the repository as netbeans.
I even read documentation on using this lib which without Netbeans
doesn't seem to make much sense:
https://docs.oracle.com/javase/tutorial/uiswing/layout/none.html
Without further ado I will close this subject.

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#1031694: ITP: libxisf -- Library to load and save XISF images

[Dušan Poizl]

Package: wnpp
Owner: Ole Streicher 
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org
* Package name: libxisf
  Version : 0.1.3
  Upstream Author : Dušan Poizl https://gitea.nouspiro.space/nou/libXISF
* License : GPL3
  Programming Lang: C++
  Description : Library to load and save XISF images

Extensible Image Serialization Format (XISF, pronounced [ɛksˈɪsf]) is 
the native file format of PixInsight. It is a free, open format for 
storage, management and interchange of digital images and associated data.


I wrote this library to load and save images in XISF format as it is 
preferred format for PixInsight. Just recently it got integrated into 
INDI and KStars.

Bug#1014782: The problem remains

[Celejar]

On Sun, 19 Feb 2023 10:21:48 +0100 Tormod Volden
 wrote:
> On Fri, Feb 17, 2023 at 5:48 PM Celejar wrote:
> > Sorry - I just saw this. I'm currently on 6.06 (Sid package). The
> > "Preview" button is currently working, but the screensaver isn't
> > activating on its own. I started it with logging enabled, and I see
> > regular deactivate events like the following logged every 20 seconds:
> >
> > ClientMessage DEACTIVATE: already inactive, resetting activity time
> >
> > I saw this:
> >
> > https://www.jwz.org/xscreensaver/faq.html#no-blank
> >
> > I guess I have to figure out what application is sending these messages?
> > Firefox? I do tend to keep a lot of tabs open.
> 
> Yes, try freezing Firefox and see if those DEACTIVATEs stop. I use

It turns out that the DEACTIVATEs were being sent by the Xfce Power
Manager's Presentation Mode. I'm not sure I was even aware of that
mode's existence, but it apparently has a long history of becoming
turned on without the conscious intention or awareness of the user :)

https://bugzilla.xfce.org/show_bug.cgi?id=14210

> this script when I need to save laptop battery, it might come handy
> here:

...

Thank you!

> BTW, if you keep many tabs open, I can recommend the Auto Tab Discard 
> extension!

Thanks - I think I've tried it in the past, but I don't currently have
it installed. Perhaps I'll give it another try.

Thanks again for the help.

-- 
Celejar

Bug#1031693: import-dsc: dangling pristine-tar treeish with multiple components

[Huw Jones]

Package: git-buildpackage
Version: 0.9.22
Severity: important
X-Debbugs-Cc: h...@pexip.com

Dear Maintainer,

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

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

*** End of the template - remove these template lines ***
import-dsc leaves a dangling treeish when importing a dsc with multiple 
components.

For example, sqlite3

```
$ dget --download-only --quiet --allow-unauthenticated 
http://ftp.debian.org/debian/pool/main/s/sqlite3/sqlite3_3.34.1-3.dsc
$ gbp import-dsc -v --pristine-tar sqlite3_3.34.1-3.dsc
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: Upstream version: 3.34.1
gbp:debug: Debian version: 3
gbp:debug: Upstream tarball: /tmp/sqlite3/sqlite3_3.34.1.orig.tar.xz
gbp:debug: Additional tarballs: /tmp/sqlite3/sqlite3_3.34.1.orig-www.tar.xz
gbp:debug: Debian patch: /tmp/sqlite3/sqlite3_3.34.1-3.debian.tar.xz
gbp:info: No git repository found, creating one.
gbp:debug: ['git', 'init']
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: tar ['-C', '/tmp/sqlite3/tmp4mt7atb8', '-a', '-xf', 
'/tmp/sqlite3/sqlite3_3.34.1.orig.tar.xz'] []
gbp:info: Found component tarball 'sqlite3_3.34.1.orig-www.tar.xz'
gbp:debug: tar ['-C', '/tmp/sqlite3/tmp4mt7atb8/tmpcrfvrq1w', '-a', '-xf', 
'/tmp/sqlite3/sqlite3_3.34.1.orig-www.tar.xz'] []
gbp:debug: rm ['-rf', '/tmp/sqlite3/tmp4mt7atb8/tmpcrfvrq1w'] []
gbp:debug: ['git', 'tag', '-l', 'debian/3.34.1-3']
gbp:debug: ['git', 'tag', '-l', 'debian/3.34.1-3']
gbp:debug: ['git', 'tag', '-l', 'upstream/3.34.1']
gbp:debug: ['git', 'tag', '-l', 'upstream/3.34.1']
gbp:debug: ['git', 'tag', '-l', 'upstream/3.34.1']
gbp:debug: ['git', 'tag', '-l', 'upstream/3.34.1']
gbp:debug: ['git', 'add', '-f', '.']
gbp:debug: ['git', 'write-tree']
gbp:debug: ['git', 'commit-tree', '1d6f0d8b6276d7ee72fa76fcd2e4cd2d35b86b33']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: Import Upstream version 3.34.1', 
'refs/heads/master', 'cefbc7af913751e761e8b9ff7beb83e0d3f59abe']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: ['git', 'branch', 'upstream', 'master']
gbp:debug: ['git', 'tag', '-m', 'Upstream version 3.34.1', 'upstream/3.34.1', 
'cefbc7af913751e761e8b9ff7beb83e0d3f59abe']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/master']
gbp:debug: tar ['-C', '.', '-a', '-xf', 
'/tmp/sqlite3/sqlite3_3.34.1-3.debian.tar.xz'] []
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 
'cefbc7af913751e761e8b9ff7beb83e0d3f59abe^{commit}']
gbp:debug: ['git', 'branch', '--contains', 
'cefbc7af913751e761e8b9ff7beb83e0d3f59abe']
gbp:debug: ['git', 'add', '-f', '.']
gbp:debug: ['git', 'write-tree']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'master']
gbp:debug: ['git', 'commit-tree', 'a39172afdec174692199169ccecf1578cfc4b84e', 
'-p', 'cefbc7af913751e761e8b9ff7beb83e0d3f59abe']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: Import Debian changes 3.34.1-3', 
'refs/heads/master', '9ab03e07211eb7c103ebd31fabc5325f47cd2d8d', 
'cefbc7af913751e761e8b9ff7beb83e0d3f59abe']
gbp:debug: ['git', 'tag', '-m', 'Debian release 3.34.1-3', 'debian/3.34.1-3', 
'9ab03e07211eb7c103ebd31fabc5325f47cd2d8d']
gbp:debug: ['git', 'ls-tree', '-z', 'cefbc7af913751e761e8b9ff7beb83e0d3f59abe', 
'--']
gbp:debug: ['git', 'mktree', '-z']
gbp:debug: ['git', 'ls-tree', '-z', 'cefbc7af913751e761e8b9ff7beb83e0d3f59abe', 
'--']
gbp:debug: Creating pristine tar commit 
'/tmp/sqlite3/sqlite3_3.34.1.orig-www.tar.xz' from 
'caa99a00bc6709686138dd8813a810f6fa9eef90'
gbp:debug: pristine-tar [] ['commit', 
'/tmp/sqlite3/sqlite3_3.34.1.orig-www.tar.xz', 
'caa99a00bc6709686138dd8813a810f6fa9eef90']
gbp:debug: pristine-tar [] ['commit', 
'/tmp/sqlite3/sqlite3_3.34.1.orig.tar.xz', 
'b8d2ba8963a49f910bb8dfe27e0a3926c3f9a72c']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'master']
gbp:debug: ['git', 'reset', '--quiet', '--hard', 
'9ab03e07211eb7c103ebd31fabc5325f47cd2d8d', '--']
gbp:debug: rm ['-rf', '/tmp/sqlite3/tmp4mt7atb8'] []
gbp:info: Version '3.34.1-3' imported under '/tmp/sqlite3/sqlite3'
```

gbp imports ok, but leaves a dangling tree-ish
```
$ git fsck --lost-found
Checking object directories: 100% (256/256), done.
dangling tree b8d2ba8963a49f910bb8dfe27e0a3926c3f9a72c
```

This means that if you push (not mirror), or prune dangling objects, you cannot 
checkout the main tarball.
```
$ git reflog expire --expire=now && git gc --aggressive --prune=now && git fsck 
--lost-found
Enumerating objects: 2909, done.
Counting objects: 100% (2909/2909), done.
Delta compression using up to 16 threads
Compressing objects: 100% (2884/2884), done.

Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6

[Helmut Grohne]

Hi Dmitry and Lisandro,

thanks for working on this.

On Mon, Feb 20, 2023 at 10:49:52AM +0300, Dmitry Shachnev wrote:
> On Sun, Feb 19, 2023 at 08:20:43PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > On Sun, 19 Feb 2023 at 16:59, Dmitry Shachnev  wrote:
> > > What are these paths?
> > >
> > > I think one that Helmut mentioned is the most important and should cover 
> > > most
> > > cases.
> >
> > Paths to uic. moc et all.
> 
> IIRC, uic and moc produce the same output on all architectures, so we do not
> need cross wrappers for them.
> 
> So calling the native /usr/lib/qt6/bin/{uic,moc} should be absolutely fine.

I agree with all of that.

Lisandro also asked:

| sbuild -host arm64 -sAd unstable some_qt6_app.dsc a good way to test this?

I's --host rather than -host.

Do not pass -A. To simplify matters, cross builds are always assumed to
be arch-only.

Other than that, this should work.

Maybe you should check that qemu's binfmt integration is disabled.
Otherwise, you may be a successful build that only happened to work due
to using qemu. You can run "update-binfmts --disable" to disable all
binfmts and reenable them afterwards.

Helmut

Bug#1031691: dsda-doom FTCBFS: needs a native build pass

[Helmut Grohne]

Source: dsda-doom
Version: 0.25.6+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

dsda-doom fails to cross build from source, because the upstream build
system requires a native build pass to build native tools, which are
imported via an import file into the cross build. This native pass has
not been implemented in the Debian package yet. I'm attaching a patch
for your convenience.

Helmut
diff --minimal -Nru dsda-doom-0.25.6+dfsg/debian/changelog 
dsda-doom-0.25.6+dfsg/debian/changelog
--- dsda-doom-0.25.6+dfsg/debian/changelog  2023-01-31 07:51:06.0 
+0100
+++ dsda-doom-0.25.6+dfsg/debian/changelog  2023-02-10 18:06:35.0 
+0100
@@ -1,3 +1,10 @@
+dsda-doom (0.25.6+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add a native build pass. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 10 Feb 2023 18:06:35 +0100
+
 dsda-doom (0.25.6+dfsg-1) unstable; urgency=medium
 
   * New upstream version 0.25.6+dfsg.
diff --minimal -Nru dsda-doom-0.25.6+dfsg/debian/clean 
dsda-doom-0.25.6+dfsg/debian/clean
--- dsda-doom-0.25.6+dfsg/debian/clean  1970-01-01 01:00:00.0 +0100
+++ dsda-doom-0.25.6+dfsg/debian/clean  2023-02-10 18:06:33.0 +0100
@@ -0,0 +1 @@
+build-native
diff --minimal -Nru dsda-doom-0.25.6+dfsg/debian/control 
dsda-doom-0.25.6+dfsg/debian/control
--- dsda-doom-0.25.6+dfsg/debian/control2022-12-31 12:39:03.0 
+0100
+++ dsda-doom-0.25.6+dfsg/debian/control2023-02-10 18:06:35.0 
+0100
@@ -12,12 +12,16 @@
  libdumb1-dev,
  libfluidsynth-dev,
  libgl1-mesa-dev | libgl-dev,
+ libgl1-mesa-dev:native | libgl-dev:native,
  libglu1-mesa-dev | libglu-dev,
+ libglu1-mesa-dev:native | libglu-dev:native,
  libmad0-dev,
  libportmidi-dev [linux-any],
  libsdl2-dev (>= 2.0.7),
+ libsdl2-dev:native (>= 2.0.7),
  libsdl2-image-dev,
  libsdl2-mixer-dev,
+ libsdl2-mixer-dev:native,
  libsdl2-net-dev,
  libvorbis-dev
 Standards-Version: 4.6.1
diff --minimal -Nru dsda-doom-0.25.6+dfsg/debian/rules 
dsda-doom-0.25.6+dfsg/debian/rules
--- dsda-doom-0.25.6+dfsg/debian/rules  2022-12-31 12:49:58.0 +0100
+++ dsda-doom-0.25.6+dfsg/debian/rules  2023-02-10 18:06:35.0 +0100
@@ -10,12 +10,17 @@
--with bash_completion
 
 override_dh_auto_configure:
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_configure 
-Bbuild-native
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_build -Bbuild-native
+endif
dh_auto_configure -- \
-DCMAKE_INSTALL_BINDIR=games \
-   -DDSDAPWADDIR=/usr/share/dsda-doom
+   -DDSDAPWADDIR=/usr/share/dsda-doom \
+   $(if $(filter 
$(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)),,-DIMPORT_EXECUTABLES=../build-native/ImportExecutables.cmake)
 
 override_dh_installchangelogs:
-   dh_installchangelogs -- patch_notes/v$(basename 
$(DEB_VERSION_UPSTREAM_REVISION))*
+   dh_installchangelogs -- patch_notes/v$(basename 
$(DEB_VERSION_UPSTREAM))*
 
 override_dh_gencontrol:
dh_gencontrol -pprboom-plus -- 
-v3:$(DEB_VERSION_UPSTREAM_REVISION)

Bug#1031692: jami: should probably depend on libqt6sql6-sqlite

[Helmut Grohne]

Package: jami
Version: 20230206.0~ds1-5
Severity: important

When upgrading jami from a qt5-based version, the configuration
typically is stored using sqlite. However, jami does not pull
libqt6sql6-sqlite. As a consequence, the existing account is not
recognized. When trying to import the existing account, the dialog gets
stuck and never finishes. This is a less than useful experience. At a
bare minimum, jami should recommend libqt6sql6-sqlite, but given the
size, I think a real dependency would be more useful.

Helmut

Bug#1031684: python-magic: new upstream version available 0.4.27

[Christoph Biedl]

Control: tags 1031684 moreinfo

Hans-Christoph Steiner wrote...

> There is a new bugfix version available from upstream.  It would be
> nice to have that in bookworm, and there is still time before the hard
> freeze if it is uploaded now.  I can contribute there if that is
> needed to make this happen.

The delta between 0.4.26 (in Debian) and 0.4.27 upstream is minimal,
just a version number bump. If there's anything else after the 0.4.27
release that justifies another upload, let me know.

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#1031690: Regression in wayland mixed DPI setups

[Didier 'OdyX' Raboud]

Package: plasma-workspace-wayland
Version: 4:5.27.0-1
Severity: important
Tags: upstream

Hello there,

it looks like there's a regression in mixed DPI setups (one hiDPI screen
at "150%", a lower-DPI screen at "100%"), on Wayland, for some non-KDE
applications. In my case, flatpak firefox has too small tabs depending
on which screen it initially got launched.

This was working much better pre-5.27.

It looks like upstream is on this;
* https://bugs.kde.org/show_bug.cgi?id=443215
* https://bugs.kde.org/show_bug.cgi?id=465733

But I couldn't really identify directly which patch, and on which
software, to test.

Happy to build/test here.

Best,
OdyX

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

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

Versions of packages plasma-workspace-wayland depends on:
ii  kpackagetool5 5.103.0-1
ii  kwayland-integration  5.27.0-1
ii  kwin-wayland  4:5.27.0-1
ii  libc6 2.36-8
ii  libkf5configcore5 5.103.0-1
ii  libkf5configgui5  5.103.0-1
ii  libkf5configwidgets5  5.103.0-1
ii  libkf5coreaddons5 5.103.0-1
ii  libkf5guiaddons5  5.103.0-1
ii  libkf5kcmutils5   5.103.0-1
ii  libkf5kiogui5 5.103.0-1
ii  libkf5notifications5  5.103.0-1
ii  libkf5package55.103.0-1
ii  libkf5service-bin 5.103.0-1
ii  libkf5service55.103.0-1
ii  libkworkspace5-5  4:5.27.0-1
ii  libphonon4qt5-4   4:4.11.1-4
ii  libqt5core5a  5.15.8+dfsg-2
ii  libqt5dbus5   5.15.8+dfsg-2
ii  libqt5gui55.15.8+dfsg-2
ii  libstdc++612.2.0-14
ii  phonon4qt54:4.11.1-4
ii  plasma-workspace  4:5.27.0-1
ii  qtwayland55.15.8-2

plasma-workspace-wayland recommends no packages.

plasma-workspace-wayland suggests no packages.

-- no debconf information

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Eli Zaretskii]

> From: Andrea Corallo 
> Cc: monn...@iro.umontreal.ca,  t...@debian.org,  emacs-de...@gnu.org,
>   spwhit...@spwhitton.name,  1021...@bugs.debian.org
> Date: Mon, 20 Feb 2023 15:42:08 +
> 
> > You mean, from master to emacs-29, I guess?
> 
> Yes
> 
> > What was the motivation for that change?  The log message doesn't
> > explain the problem it meant to solve in enough detail, it just says
> > something about creating the file twice?  How can that happen? who
> > creates the file the second time?
> 
> Before e6043641d30 the file was created by Fmake_temp_file_internal and
> afterwards overwritten by libgccjit.  So I guess one could remove the
> file after the first creation and make it a link pointing to some other
> file waiting for libgccjit to do its write.

Then it's okay to cherry-pick it to emacs-29.  (I actually am not sure
why we didn't install it on emacs-29 to begin with, but never mind.)

Thanks.

Bug#1031689: ITP: obs-scene-tree-view -- plugin for OBS Studio that adds a scene tree folder dock

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, DigitOtter 


* Package name: obs-scene-tree-view
  Version : 0.1.5
  Upstream Contact: DigitOtter 
* URL : 
https://obsproject.com/forum/resources/scene-tree-folder-plugin-for-obs-studio.1500
* License : GPL-2
  Programming Lang: C++
  Description : plugin for OBS Studio that adds a scene tree folder dock

 This plugin allows OBS to group and organize scenes into a folder structure.
 It is possible to switch the standard scene dock provided by OBS to this
 special plugin.

 It is possible to create several folders to group scenes on them.

Bug#1031688: gnome-shell 44~beta crashes immediately unless mutter-common-bin is installed

[Roderich Schupp]

On Mon, Feb 20, 2023 at 5:27 PM Simon McVittie  wrote:

> > Feb 20 15:18:32 nuc8 gnome-shell[7963]: Running GNOME Shell (using mutter
> > 44.beta) as a X11 window and compositing manager
> >??? why X11, should be Wayland
>
> mutter is a Wayland compositor, but it's also an X11 window and compositing
> manager at the same time. Even when running in native-Wayland mode, it
> manages X11 windows (if any) in its Xwayland instance, to provide
> compatibility with older applications.
>

Sure, but  the string "Running GNOME Shell (using mutter XXX) as a X11
window and compositing manager"
doesn't appear in my journal at all before installing 44.beta, only the
"... as a Wayland compositor" variant.

Cheers, Roderich

Bug#1031688: gnome-shell 44~beta crashes immediately unless mutter-common-bin is installed

[Simon McVittie]

Control: reassign -1 libmutter-12-0 44~beta-1
Control: severity -1 grave
Control: tags -1 + experimental
Control: affects -1 + gdm3 gnome-shell

On Mon, 20 Feb 2023 at 16:41:06 +0100, Roderich Schupp wrote:
> gnome-shell (the gdm login screen) crashes immediately if
> you don't have mutter-common-bin installed (which is not
> a dependency of gnome-shell).

This is an implementation detail of libmutter-12-0, so I think it's
libmutter-12-0 that should have that dependency.

> Feb 20 15:18:32 nuc8 gnome-shell[7963]: Running GNOME Shell (using mutter
> 44.beta) as a X11 window and compositing manager
>??? why X11, should be Wayland

mutter is a Wayland compositor, but it's also an X11 window and compositing
manager at the same time. Even when running in native-Wayland mode, it
manages X11 windows (if any) in its Xwayland instance, to provide
compatibility with older applications.

> Feb 20 15:18:33 nuc8 gnome-shell[7963]: Could not launch X11 frames client:
> Failed to execute child process “./src/frames/mutter-x11-frames” (No such file
> or directory)
> Feb 20 15:18:33 nuc8 kernel: gnome-shell[7963]: segfault at 50 [etc.]

This looks like a separate bug in the error handling for the missing
mutter-x11-frames: ideally it should be crashing out with a g_error() or
otherwise exiting with unsuccesful status, rather than segfaulting. But if
the dependency was in place, then this would never happen.

smcv

Bug#991408: Netbeans: source code problem

[Markus Koschany]

Am Montag, dem 20.02.2023 um 12:41 -0300 schrieb Leandro Cunha:
> Hi Markus,
> 
> I have no interest in keeping Netbeans on Debian, but when I mention
> consistency (according to the dictionary: state or quality of what is
> coherent), it would be consistent with the reality that would be
> represented in the tracker and on package.debian.org that the package
> was removed from repository and if I give apt install netbeans it
> would not be found. The same as with other packages follows the Debian
> Developer Reference [1].


apt install netbeans will do nothing. The binary package has been removed from
Debian. The Netbeans source package has always produced libnb-absolutelayout-
java. There is no inconsistency. You either don't understand the difference
between a source and a binary package or you are deliberately annoying. In any
case I won't reply to this bug report anymore.


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

Bug#1031465: snippy: FTBFS: make[2]: *** [Makefile:32: S1/snps.tab] Error 2

[Andreas Tille]

Hi Pjotr,

in contrast to the bug reporter I get in my unstable chroot

...
[15:53:57] Checking version: bcftools --version is >= 1.7 - ok, have 1.16
[15:53:57] Checking version: freebayes --version is >= 1.1 - ok, have 1.3.6
[15:53:57] Checking version: snpEff -version is >= 4.3 - ok, have 5.1
...

which looks good regarding the version check of freebayes.  However
later on the test ends up in:


Loaded 3 sequences totalling 317336 bp.
Loading mask bed file: example.bed
Will mask 8 regions totalling 3101 bp ~ 0.98%
0   S1  snp=0   del=0   ins=0   het=0   unaligned=9643
1   S2  snp=0   del=0   ins=0   het=81  unaligned=9428
2   S3  snp=0   del=0   ins=0   het=0   unaligned=9376
3   S4  snp=0   del=0   ins=0   het=0   unaligned=9707
Opening: core-mask.tab
Opening: core-mask.vcf
Processing contig: LBB_contig01
Processing contig: LBB_contig02
Processing contig: LBB_contig03
Masking alignment at 8 regions
Generating core-mask.full.aln
Creating TSV file: core-mask.txt
Running: snp-sites -c -o core-mask.aln core-mask.full.aln
Warning: No SNPs were detected so there is nothing to output.
ERROR: Could not run: snp-sites -c -o core-mask.aln core-mask.full.aln


I'm not sure whether this might be related to some previous freebayes
call (which is the only package in the list of dependencies that has
changed) or whether there is some other problem.  I think it is worth
investigating since snippy might be an interesting test suite for a
whole bunch of packages.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1031671: gnome-shell: Some applications always lose focus

[Simon McVittie]

Control: found -1 44~beta-1

On Mon, 20 Feb 2023 at 09:54:38 +, Simon McVittie wrote:
> I think this is another way to describe the upstream bug that
> was fixed by mutter 43.3-3.

I think this also needs fixing in 44~beta-1 (I haven't confirmed this
myself, I'm staying on GNOME 43 for now to try to get Debian 12 into
shape). A simple reproducer:

- have an X11 window (I used `git gui`)
- have a Wayland window (I used gnome-terminal)
- focus the X11 window
- go to the Overview with the Windows key
- click the Wayland window
- good result: focus moves to the Wayland window
- bad result: Wayland window stays unfocused (dim titlebar, etc.)

The fix is https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2841
upstream. Jeremy or other people working on GNOME 44 betas: please could
you grab that change next time you update mutter?

Thanks,
smcv

Bug#958311: cloud kernel 5.5.0-2 does not boot under xen

[Aleksi Suhonen]

Hi,

On 16/02/2023 18:18, Samuel Thibault wrote:

Andy Smith, le jeu. 16 févr. 2023 15:44:21 +, a ecrit:

   - The PV part of grub is quite old and from what I understand
 implemented in a strange way


Ah, uh :/


 that no one wants to maintain any
 more, so this part of grub is stuck without ability to
 understand the newer kernel compressions.


I've been using the attached script to get around the problem. It tries 
to decompress the cloud kernel and then recompress it with something 
that grub-xen can handle. If recompression fails, it leaves an 
uncompressed kernel, which also works, in place.


The script needs to be installed in /etc/kernel/postinst.d/.

--
Aleksi Suhonen

() ascii ribbon campaign
/\ support plain text e-mail
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0-only
# --
# kernel-recompress-hook - recompress cloud kernels for grub-xen
#   Place this script in /etc/kernel/postinst.d/
#   Requires: binutils, lz4, xz-utils
# (c) 2021-2023 Aleksi Suhonen 
#
# Distilled from extract-vmlinux by
# (c) 2009,2010 Dick Streefland 
# (c) 2011  Corentin Chary 
#
# --

KERNEL_VERSION="$1"
KERNEL_PATH="$2"

# The KERNEL_PATH must be valid
if [ ! -f "${KERNEL_PATH}" ]; then
echo >&2 "Kernel file '${KERNEL_PATH}' not found. Aborting"
exit 1
fi

# Prepare temp files:
tmp=$(mktemp /boot/vmlinux-X)
trap "rm -f $tmp ${tmp}.xz" 0

# Try to find the LZ4 header and decompress from here
LZ4_HEADER="$(printf '\002!L\030')"
for pos in `fgrep -abo "$LZ4_HEADER" "$KERNEL_PATH"`
do
# grep counts bytes from 0, while tail counts from 1...
pos=$((1+${pos%%:*}))
rm -f $tmp
tail -c+$pos "$KERNEL_PATH" | lz4 -d >$tmp
readelf -h $tmp >/dev/null 2>&1 && break
echo "False LZ4 header at ${pos}, looking for more..."
done

if ! readelf -h $tmp > /dev/null; then
echo >&2 "Decompression of kernel file '${KERNEL_PATH}' failed!, not a 
valid ELF image"
exit 0
fi

echo "Decompression of kernel file '${KERNEL_PATH}' successful"

if xz --check=crc32 --x86 --lzma2=dict=32MiB $tmp; then
echo "Recompression also successful"
mv -fv ${tmp}.xz ${KERNEL_PATH}
echo "Replacement of kernel file successful"
else
echo "Recompression unsuccessful"
mv -fv ${tmp} ${KERNEL_PATH}
echo "Replacement of kernel file successful"
fi

exit 0
#EOF

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Andrea Corallo]

Stefan Monnier  writes:

>>> `make-temp-name` uses `O_EXCL | O_CREAT` so as to close the race
>>> condition: if someone predicated the filename, we detect it atomically
>>> and we try again.
>>>
>>> You might like to check
>>>
>>> 
>>> https://wiki.sei.cmu.edu/confluence/display/c/FIO21-C.+Do+not+create+temporary+files+in+shared+directories
>>
>> Thanks for the pointer.
>>
>> I'm still not really convinced we have a problem here with trampolines.
>> With `make-temp-file' we are really only choosing the filename and
>> suggesting it to libgccjit, this last one will perform the file
>> creation.
>
> The important part is the use of `O_EXCL | O_CREAT` when creating
> the file.
> *BUT* `O_EXCL | O_CREAT` will fail if the file already exists.  Which is
> why `make-temp-file` needs `make-temp-name` to generate new names until
> we find one that really doesn't exist (not just at the time
> `make-temp-name` is called but the fraction of a millisecond later when
> we do try to create it).

We can't use this loop, we tipically pass a filename to be used to
libgccjit and we have no control after (also see my last comment).

>> I'd be surprised if GCC does not handle this correctly, and
>> in case shouldn't this be a GCC bug?
>
> I'd be surprised.

Surprised if it does or does not?

> If you tell it to write to a pre-existing file, does
> it fail with an error?

I believe it does not.

> If not, then I think it can't be used safely unless
> *you* pre-create the file (e.g. with `make-temp-file`).

Are we sure?

Also if I pre-create the file with make-temp-file can't someone just
replace it even more easily with the infamous link before libgccjit
comes in?

Thanks

  Andrea

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Stefan Monnier]

> Before e6043641d30 the file was created by Fmake_temp_file_internal and
> afterwards overwritten by libgccjit.

Yes, that was good.

> So I guess one could remove the file after the first creation and make
> it a link pointing to some other file waiting for libgccjit to do
> its write.

"One" as in "an attacker"?  In `/tmp` an attacker should not be able to
do that because it's supposed to be using the sticky bit so that only
the owner of a file can remove it.


Stefan

Bug#1030382: encourage Vcs-Git over other Vcs-* headers

[Sean Whitton]

Hello,

On Mon 20 Feb 2023 at 01:59PM GMT, Jelmer Vernooij wrote:

> Are you saying that it doesn't belong in policy because it'd be a
> recommendation rather than a must/should (at this point?), or because it's 
> more about the
> workflow inside of Debian than package contents?

Thanks for filing the patch.  As to your question, it's the latter (I'm
not sure whether or not the former is true, but in any case, Policy
contains recommendations in addition to musts and shoulds).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#991408: Netbeans: source code problem

[Leandro Cunha]

Hi Markus,

I have no interest in keeping Netbeans on Debian, but when I mention
consistency (according to the dictionary: state or quality of what is
coherent), it would be consistent with the reality that would be
represented in the tracker and on package.debian.org that the package
was removed from repository and if I give apt install netbeans it
would not be found. The same as with other packages follows the Debian
Developer Reference [1].

[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#removing-packages

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#1031685: redmine doesn't work as thin instance

[Andre Heider]

On 20/02/2023 16:23, Jakob Haufe wrote:

Control: tag -1 + help

On Mon, 20 Feb 2023 15:57:23 +0100
Andre Heider  wrote:


Adding "gem 'thin'" to /usr/share/redmine/Gemfile fixes it for me.

I've no idea about ruby stuff, so that's probably not an appropriate
solution. Does this need to be fixed or can I solve that without
modifying the package's Gemfile?


We discussed the same issue two days ago on IRC.

The correct place for this is /usr/share/redmine/Gemfile.local, so it
will survive updates.


Nice, that worked, thanks!


It is currently undecided whether this needs to be documented somewhere
or whether we can find an automatic way of doing this without a hard
dependency on thin.

Suggestions are welcome.


I tried to find hints in the changelogs of the thin and redmine packages 
and in /usr/share/doc/redmine/examples/thin-redmine.yml first, but 
couldn't find anything.


The latter sounds like a good place?

Cheers,
Andre

Bug#1031688: gnome-shell 44~beta crashes immediately unless mutter-common-bin is installed

[Roderich Schupp]

Package: gnome-shell
Version: 44~beta-1
Severity: important
X-Debbugs-Cc: roderich.sch...@gmail.com

gnome-shell (the gdm login screen) crashes immediately if
you don't have mutter-common-bin installed (which is not
a dependency of gnome-shell).

Annotated excerpt from log:

Feb 20 15:18:32 nuc8 gnome-session-binary[7892]: DEBUG(+): Starting app:
/org/gnome/SessionManager/App1
Feb 20 15:18:32 nuc8 gnome-session-binary[7892]: DEBUG(+): GsmAutostartApp:
starting org.gnome.Shell.desktop: command=/usr/bin/gnome-shell startup-
id=10a4cdb6f1969bf221676902712162170007892
Feb 20 15:18:32 nuc8 gnome-session-binary[7892]: GnomeDesktop-DEBUG(+): Not
systemd managed, will not move PID 7963 into transient scope
Feb 20 15:18:32 nuc8 gnome-session-binary[7892]: DEBUG(+): GsmAutostartApp:
started pid:7963
Feb 20 15:18:32 nuc8 gnome-shell[7963]: Running GNOME Shell (using mutter
44.beta) as a X11 window and compositing manager
   ??? why X11, should be Wayland
Feb 20 15:18:33 nuc8 /usr/libexec/gdm-x-session[7867]: (II) modeset(0): EDID
vendor "SAM", prod id 2106
...
Feb 20 15:18:33 nuc8 gnome-shell[7963]: ATK Bridge is disabled but a11y has
already been enabled.
Feb 20 15:18:33 nuc8 gnome-shell[7963]: Could not launch X11 frames client:
Failed to execute child process “./src/frames/mutter-x11-frames” (No such file
or directory)
Feb 20 15:18:33 nuc8 kernel: gnome-shell[7963]: segfault at 50 ip
7fc14338c867 sp 7ffc642af308 error 6 in
libglib-2.0.so.0.7503.0[7fc1432f7000+96000] likely on CPU 2 (core 2, socket 0)
Feb 20 15:18:33 nuc8 kernel: Code: e9 be 6a fc ff 66 0f 1f 44 00 00 48 8b 7f 30
e8 df af f6 ff eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 31 c0 ba 01 00 00
00  0f b1 17 75 01 c3 e9 9d f6 ff ff 66 66 2e 0f 1f 84 00 00 00 00

The clue is "Failed to execute child process...".
/usr/libexec/mutter-x11-frames is in package mutter-common-bin
(new in 44~beta) which wasn't installed at the time of the crash.
After installing it, gdm login screen is running
and I can login to a Gnome Wayland session.

Cheers, Roderich



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

Kernel: Linux 6.2.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   22.08.8-6
ii  gir1.2-adw-1 1.3~beta-1
ii  gir1.2-atk-1.0   2.46.0-5
ii  gir1.2-atspi-2.0 2.46.0-5
ii  gir1.2-freedesktop   1.75.6-1
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 44~beta-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-gdm-1.0   43.0-3
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.75.6-1
ii  gir1.2-gnomebluetooth-3.042.5-3
ii  gir1.2-gnomedesktop-3.0  44~beta-1
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.22.0-2
ii  gir1.2-gtk-3.0   3.24.36-4
ii  gir1.2-gtk-4.0   4.9.4+ds-1
ii  gir1.2-gweather-4.0  4.2.0-1
ii  gir1.2-ibus-1.0  1.5.27-5
ii  gir1.2-mutter-12 44~beta-1
ii  gir1.2-nm-1.01.42.0-1
ii  gir1.2-nma-1.0   1.10.6-1
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-polkit-1.0122-3
ii  gir1.2-rsvg-2.0  2.54.5+dfsg-1
ii  gir1.2-soup-3.0  3.3.1-1
ii  gir1.2-upowerglib-1.01.90.0-2
ii  gir1.2-webkit2-4.1   2.39.7-1
ii  gnome-backgrounds44~beta-1
ii  gnome-settings-daemon44~beta-1
ii  gnome-shell-common   44~beta-1
ii  gsettings-desktop-schemas44~beta-1
ii  gstreamer1.0-pipewire0.3.66-1
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libecal-2.0-23.46.4-1
ii  libedataserver-1.2-273.46.4-1
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Andrea Corallo]

Eli Zaretskii  writes:

>> From: Andrea Corallo 
>> Cc: Tatsuya Kinoshita ,  emacs-de...@gnu.org,
>>   spwhit...@spwhitton.name,  1021...@bugs.debian.org, Eli Zaretskii
>>  
>> Date: Mon, 20 Feb 2023 09:03:34 +
>> 
>> OTOH on a slightly differnt subject and in light of this, I think we
>> should probably backport e6043641d30 into emacs-30, so that eln files
>> are created onace and only by libgccjit.  Eli WDYT?
>
> You mean, from master to emacs-29, I guess?

Yes

> What was the motivation for that change?  The log message doesn't
> explain the problem it meant to solve in enough detail, it just says
> something about creating the file twice?  How can that happen? who
> creates the file the second time?

Before e6043641d30 the file was created by Fmake_temp_file_internal and
afterwards overwritten by libgccjit.  So I guess one could remove the
file after the first creation and make it a link pointing to some other
file waiting for libgccjit to do its write.

  Andrea

Bug#1031275: [PATCH v3 1/6] man2/: use IEC or ISO multiples to clarify long numeric digit strings

[Alex Colomar]

On 2/20/23 15:29, Stefan Puiu wrote:

Hi Alex,


Hi Stefan,


4 KiB is not that much better than 4096, since 4096 is easy to read.
For higher numbers such as 33554432, it becomes more important to use 32 KiB.
For consistency, using 4 KiB seems reasonable.


How about using KiB / MiB over a certain number of digits? It seems
excessive to use them everywhere.


We might do that.  So far, I prefer having the patches change 
everything, and then we can later discuss about discarding part of them.




Also, for the record, I had no idea what KiB / MiB means and how it's
different from KB/MB until this discussion. I googled it before
writing this reply, and found this among the first hits:
https://ux.stackexchange.com/a/13850.


That answer was written more than a decade ago.  These days, binary 
prefixes are more common.  In fact, I'd say most GNU/Linux commands 
respect them (an important exception being GNU coreutils (for example 
ls(1)).  But many programs use prefixes accurately, such as fdisk(8).


In the Linux man-pages we have units(7), which documents these.  Maybe 
that page should be more known.


BTW, that answer is inaccurate (at least today): drive manufacturers 
have the distinction pretty clear, and use it precisely (with lawsuits 
won thanks to this); they use metric prefixes, because they mean it. 
They can sell you 1 TB instead of 1 TiB, and most people won't even 
know, but those who know, will know that 1 TB is 1'000'000'000'000 B, 
which is what you get.  They have no incentives to sell 1 TiB drives, 
because they are visually almost the same, but there's around 9.95% more 
bytes, so it's more expensive to produce.  It's not worth it for them.




I would say making the docs easy to understand for users is more
important than adhering to some specs users might not be familiar
with.


Well, using MiB prompts readers to use their search engine to learn what 
that is (that's how I learnt it the first time; and that's what one does 
when reading a book and finding a new word).  I think that shouldn't be 
considered an impediment, but an opportunity to learn something new.


Once you know the difference, you appreciate the preciseness.  I hate 
when I see some software that uses the metric prefixes for meaning 
binary multipliers.  I also hate software that operates on bytes, when 
you almost always want binary multipliers but only have metric 
multipliers (hey partman, I mean you!).  I reported a bug to the Debian 
installer recently because it's very painful to partition a drive from it.


Cheers,

Alex

--

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031687: libtorch-dev: ATEN_INCLUDE_DIR in ATenConfig.cmake uses build path

[Andrius Merkys]

Package: libtorch-dev
Version: 1.13.1+dfsg-3

Hello,

I noticed libtorch-dev embeds build path in 
/usr/lib/${DEB_HOST_MULTIARCH}/cmake/ATen/ATenConfig.cmake by building 
with different setups:


│ │ ├── ./usr/lib/x86_64-linux-gnu/cmake/ATen/ATenConfig.cmake
│ │ │ @@ -1,9 +1,9 @@
│ │ │  # Find the TH includes and library
│ │ │  #
│ │ │  # ATEN_INCLUDE_DIR -- where to find the includes
│ │ │  # ATEN_LIBRARIES -- list of libraries to link against
│ │ │  # ATEN_FOUND -- set to 1 if found
│ │ │
│ │ │  set(ATEN_FOUND 1)
│ │ │ -set(ATEN_INCLUDE_DIR 
"/home/merkys/without-opencl/pytorch-1.13.1+dfsg/torch/include")
│ │ │ +set(ATEN_INCLUDE_DIR 
"/home/merkys/with-opencl/pytorch-1.13.1+dfsg/torch/include")

│ │ │  set(ATEN_LIBRARIES "")

Andrius

Bug#1031685: redmine doesn't work as thin instance

[Jakob Haufe]

Control: tag -1 + help

On Mon, 20 Feb 2023 15:57:23 +0100
Andre Heider  wrote:

> Adding "gem 'thin'" to /usr/share/redmine/Gemfile fixes it for me.
> 
> I've no idea about ruby stuff, so that's probably not an appropriate 
> solution. Does this need to be fixed or can I solve that without 
> modifying the package's Gemfile?

We discussed the same issue two days ago on IRC. 

The correct place for this is /usr/share/redmine/Gemfile.local, so it
will survive updates.

It is currently undecided whether this needs to be documented somewhere
or whether we can find an automatic way of doing this without a hard
dependency on thin.

Suggestions are welcome.

Cheers,
sur5r

-- 
ceterum censeo microsoftem esse delendam.


pgpprxMEhHVog.pgp
Description: OpenPGP digital signature

Bug#1031677: Info received (Bug#1031677: Acknowledgement (live-build of a bookworm system fails at build time))

[Chris Ward]

I am also getting a lot of log lines like

+ for p in $(< /tmp/dpkg.inslist)
+ dpkg -p dbus-daemon
dpkg-query: package 'dbus-daemon' is not available

This comes from commands in my script, where I am attempting to
extract dependency information from the packages with a view to
building an SBOM for the ISO. When I am building for bullseye rather
than bookworm, I don;t get these messages. Is live-build responsible
for this behaviour, or should I report it against some other package ?

Chris Ward

Bug#1029803: command-not-found breaks dist-upgrade bullseye → bookworm

[Paul Gevers]

Control: tags -1 patch

Hi,

On 19-02-2023 21:22, Paul Gevers wrote:
On Sat, 28 Jan 2023 00:51:39 +0100 Lee Garrett  
wrote:
This is already fixed in unstable, but in it's current form this will 
break the

upgrade path from bullseye to bookworm. The fix is trivial, adding
`'non-free-firmware': 60,` to CommandNotFound/db/creator.py is enough. 
I propose

doing a p-u to fix it.


What do you think of that? Are you OK if I prepare the upload?


I have the attached debdiff ready to handle with the stable release 
managers.


Paul
diff --git a/CommandNotFound/db/creator.py b/CommandNotFound/db/creator.py
index 75d01f1..8f6ef70 100755
--- a/CommandNotFound/db/creator.py
+++ b/CommandNotFound/db/creator.py
@@ -20,6 +20,7 @@ component_priorities = {
 'universe': 100,
 'contrib': 80,
 'restricted': 60,
+'non-free-firmware': 50,
 'non-free': 40,
 'multiverse': 20,
 }
diff --git a/debian/changelog b/debian/changelog
index da6aa89..e82f273 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+command-not-found (20.10.1-1+deb11u1) bullseye; urgency=medium
+
+  * creator.py: add new non-free-firmware component (Closes: #1029803)
+
+ -- Paul Gevers   Sun, 19 Feb 2023 21:45:33 +0100
+
 command-not-found (20.10.1-1) unstable; urgency=medium
 
   * Trim trailing whitespace.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031686: libtycho-java: Depends on libeclipse-osgi-util-java which is no longer build

[Paul Gevers]

Package: libtycho-java
Version: 1.6.0-3
Severity: serious
Justification: fais to install

Dear maintainer,

You package depends on libeclipse-osgi-util-java but that no longer
exists in unstable.

Paul

Bug#1015796: bullseye backport

[Andre Heider]

This can be closed, a backport is available now.

Thanks!
Andre

Bug#1031685: redmine doesn't work as thin instance

[Andre Heider]

Package: redmine
Version: 5.0.4-2~bpo11+1

I've a ~3 year old redmine+thin+nginx oldstable setup which I couldn't 
use since upgrading to bullseye. Now that there's a backport (many 
thanks for finally having one!), I tried to get that old instance 
working again.


It seems the packages have been updated and the databases migrated just 
fine.


The thin instance is also started:
2023-02-20 15:26:44 +0100 Writing PID to /run/redmine/redmine.0.pid
2023-02-20 15:26:44 +0100 Changing process privilege to www-data:www-data
2023-02-20 15:26:44 +0100 Using rack adapter
2023-02-20 15:27:14 +0100 Thin web server (v1.8.0 codename Possessed Pickle)
2023-02-20 15:27:14 +0100 Maximum connections set to 1024
2023-02-20 15:27:14 +0100 Listening on /run/redmine/redmine.0.sock, 
CTRL+C to stop


But upon the first request it errors out:

2023-02-20 15:27:18 +0100 Exiting!
/usr/lib/ruby/vendor_ruby/zeitwerk/kernel.rb:34:in `require': cannot 
load such file -- thin/request (LoadError)

from /usr/lib/ruby/vendor_ruby/zeitwerk/kernel.rb:34:in `require'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/lib/thin/connection.rb:31:in 
`post_init'

from /usr/lib/ruby/vendor_ruby/em/connection.rb:58:in `block in new'
from /usr/lib/ruby/vendor_ruby/em/connection.rb:49:in `instance_eval'
from /usr/lib/ruby/vendor_ruby/em/connection.rb:49:in `new'
from /usr/lib/ruby/vendor_ruby/eventmachine.rb:1526:in `event_callback'
from /usr/lib/ruby/vendor_ruby/eventmachine.rb:196:in `run_machine'
from /usr/lib/ruby/vendor_ruby/eventmachine.rb:196:in `run'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/lib/thin/backends/base.rb:75:in 
`start'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/lib/thin/server.rb:162:in 
`start'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/lib/thin/controllers/controller.rb:87:in 
`start'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/lib/thin/runner.rb:203:in 
`run_command'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/lib/thin/runner.rb:159:in 
`run!'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/bin/thin:6:in 
`'

from /usr/bin/thin:23:in `load'
from /usr/bin/thin:23:in `'

Adding "gem 'thin'" to /usr/share/redmine/Gemfile fixes it for me.

I've no idea about ruby stuff, so that's probably not an appropriate 
solution. Does this need to be fixed or can I solve that without 
modifying the package's Gemfile?


Thanks and Cheers,
Andre

Bug#1031679: lintian: d/rules: should suggest using `execute_before/_after_dh_command` instead of `override_dh_command`

[Jelmer Vernooij]

On Mon, Feb 20, 2023 at 03:48:00PM +0100, Christoph Berg wrote:
> Re: Gioele Barabucci
> > execute_after_dh_clean:
> > touch this_strange_file
> 
> The downside of this is that it makes backporting to buster-and-older
> harder since it doesn't have the required debhelper version yet.

It might make sense to only give this warning for packages that are
already on >= 13?

Jelmer