Bug#1052019: ITP: golang-github-gookit-color -- A command-line color library with 16/256/True color support

[Afeedh Shaji]

Package: wnpp
Severity: wishlist
Owner: Afeedh Shaji 

* Package name: golang-github-gookit-color
  Version : 1.5.4-1
  Upstream Author : Gookit
* URL : https://github.com/gookit/color
* License : Expat
  Programming Lang: Go
  Description : A command-line color library with 16/256/True color support

  This package provides the library for rendering colored outputs in terminal, 
supporting 8/16 colors, 256 colors, RGB color rendering output, and offering 
Print/Sprintf methods.

This package is in the dependency tree of lazygit (#908894)[1].

[1] https://github.com/jesseduffield/lazygit-debian/wiki/Dependency-graph

Bug#1042024: RFS: hintview/1.3.1-1 [ITP] -- Program to view HINT files

[Gianfranco Costamagna]

On Tue, 25 Jul 2023 23:41:04 +0200 =?UTF-8?Q?Hilmar_Preu=c3=9fe?= 
 wrote:

Control: block 1041668 by -1

On 7/25/23 23:12, Hilmar Preuße wrote:

> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
Add blocking statement.




Hello, aren't some licenses MIT?
backend/stb_image.h: The Unlicense MIT License
Linux/main.c: MIT License
Linux/main.h: MIT License
Linux/renderOGL.c: MIT License


G.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1052018: package contains license CC-BY-NC-ND-4.0

[Thorsten Alteholz]

Package: fortran-language-server
Version: 2.13.0-1
Severity: serious
User: alteh...@debian.org
Usertags: license
thanks


Hi Denis,

unfortunately your package contains files with license: CC-BY-NC-ND-4.0

   assets/*

This license is not compatible with DFSG, so please remove the files or
move the package to non-free.

Thanks!
 Thorsten

Bug#1052017: ITP: errands -- Todo application for those who prefer simplicity

[Leandro Cunha]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-gtk-gn...@lists.debian.org
Owner: Leandro Cunha 
X-Debbugs-Cc: leandrocunha...@gmail.com
Severity: wishlist

* Package name: errands
  Version : 44.7.4
  Upstream Contact: Vlad Krupinski 
* URL : https://apps.gnome.org/List/ and
https://github.com/mrvladus/Errands
* License : MIT license
  Programming Lang: Python
  Description : Todo application for those who prefer simplicity.

Features:
- Add, remove, edit tasks and sub-tasks
- Mark task and sub-tasks as completed
- Add accent color for each task
- Drag and Drop support

The package is part of GNOME Circle[1] now and the Debian GNOME Team
will be defined as maintainer following the criteria of trying to
maintain as many packages as possible with teams. And that's if
permission is given.

[1] https://thisweek.gnome.org/posts/2023/09/twig-113

Bug#1052016: ITP: ruby-net-protocol -- abstract interface for net-* client

[Ravish BC]

package: wnpp
Severity: wishlist
Owner: Ravish B C 

*Package Name  : ruby-net-protocol
 Version   : 0.1.3
 Upstream Author   : Yukihiro Matsumoto
*URL   : https://github.com/duosecurity/duo_api_ruby
*License   : BSD-2-CLAUSE
 Programming Lang  : Ruby
*Description   :  abstract interface for net-* client

The abstract interface for net-* client.
.
This gem is required for the gitlab 16.1.0 update.

 - Ravish B C

Bug#1052015: RFS: blktrace/1.3.0-1 -- utilities for block layer IO tracing

[Daichi Fukui]

Package: sponsorship-requests
Severity: normal

Dear mentors,
(CC: Bas, Dmitry)

I am looking for a sponsor for the new version 1.3.0-1 of the package
"blktrace" as shown below.
If you think this is satisfactory and helpful, I would like you to
upload that draft to the archive.

FYI, I forked the blktrace repository in salsa and added my changes as
well as pristine-tar and upstream branches for 1.3.0.
Hopefully it is helpful for you to update the repository in salsa.

 * Package name : blktrace
   Version  : 1.3.0-1
   Upstream contact : [fill in name and email of upstream]
 * URL  :
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/blktrace.git/about/
 * License  : GPL, GPL-2+, public-domain, GPL-2
 * Vcs  : https://salsa.debian.org/debian/blktrace
   Section  : utils

The source builds the following binary packages:

  blktrace - utilities for block layer IO tracing

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/blktrace/blktrace_1.3.0-1.dsc

Changes since the last upload:

 blktrace (1.3.0-1) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Trim trailing whitespace.
   * Remove 1 obsolete maintscript entry.
   * Bump debhelper from old 11 to 13.
   * Set debhelper-compat version in Build-Depends.
   * Fix day-of-week for changelog entry 0~git-20061221162513-1.
   * Update standards version to 4.6.0, no changes needed.
   * Avoid explicitly specifying -Wl,--as-needed linker flag.
   [ Fukui Daichi ]
   * New upstream version 1.3.0
   * Remove and fix patches to catch up with 1.3.0
   * Update d/copyright

Regards,
Fukui

Bug#719351: mupdf >= 1.18 supports shared lib builds

[vincent torri]

Just pass shared=yes to make

Vincent Torri

Bug#1052014: udfclient: Please package new upstream release 0.8.20

[Boyuan Yang]

Source: udfclient
Severity: normal
Version: 0.8.11-2
Tags: sid bookworm

Dear Debian udfclient package maintainer,

A new upstream release for udfclient (v0.8.20) is now available.
Please consider packaging it in Debian. Thanks!

Best,
Boyuan Yang


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

Bug#1052013: haskell-misfortune: Undeclared dependency on libpcre3

[Michel Alexandre Salim]

Package: haskell-misfortune
Version: 0.1.2.1-2
Severity: important
X-Debbugs-Cc: mic...@michel-slm.name

Running `misfortune` fails with

misfortune: error while loading shared libraries: libpcre.so.3: cannot open 
shared object file: No such file or directory

unless libpcre3 is manually installed.


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

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

-- no debconf information

Bug#607646: gthumb: weird German localization string

[Boyuan Yang]

Control: tags -1 +wontfix
Control: close -1

Hi,

On Mon, 20 Dec 2010 17:04:41 +0100 Amselmann  wrote:
> Package: gthumb
> Version: 3:2.11.5-4
> Severity: minor
> Tags: l10n
> 
> Currently the string "Delete the imported files from the source" is not very
> well translated into German. Now it is "Aus dieser Quell importierte Bilder
> dort löschen" but it should better be something like "Lösche die
importierten
> Bilder vom Quellmedium".

Please check the current translation at
https://gitlab.gnome.org/GNOME/gthumb/-/blob/master/po/de.po . From current
point of view, the translation has already been updated.

If you have any comments, please contact GThumb upstream at
https://gitlab.gnome.org/GNOME/gthumb/-/issues . Since this bug report is no
longer applicable, I am closing this bug report.

Thanks,
Boyuan Yang


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

Bug#532755: gthumb: import dialog box should not close after importing photos

[Boyuan Yang]

Control: close -1

On Thu, 11 Jun 2009 11:44:53 +0100 Julian Gilbey  wrote:
> Package: gthumb
> Version: 3:2.10.11-1
> Severity: wishlist
> 
> I imported 2 photos from a camera, and wanted to import further ones
> from the same camera.  Unfortunately, after clicking "Import" and
> importing the first two, the dialog box then closed and I had to
> reopen it - including reading all the photographs off the camera from
> scratch - in order to import the next photos.  It would be much better
> if there was a "Done" button or the like offered after importing
> photos, allowing for the possibility of importing more than one batch.

According to upstream comment at
http://bugzilla.gnome.org/show_bug.cgi?id=585450 , upstream is clear that
this feature will not be implemented. Debian alone is unable to accommodate
the feature request. Closing this bug report accordingly.

If you have further feature requests, please contact gthumb upstream directly
at https://gitlab.gnome.org/GNOME/gthumb/-/issues .

Thanks,
Boyuan Yang


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

Bug#1043241: options

[Ying-Chun Liu (PaulLiu)]

Hi Dann, 

Yeah. If that's the only option to make it work. But it seems to me that the 
package will be very ugly. Maybe we can wait until Debian Trixie has a more 
clear release date (release plan) and then decide it. 

Currently I still think that it is possible to upstream the patch. Another 
option is to apply the patch locally in Debian. But it is scary either because 
we have to rebase it everytime.

Yours,
Paul

於 2023年9月15日 下午7:10:38 [GMT+05:30]，dann frazier  寫到：
>We've been discussing this with upstream at
>https://github.com/OP-TEE/optee_client/pull/355 , which is an attempt
>to make emulation a runtime option. An argument is being made that
>it should remain a build time switch, to avoid having to ship the
>emulation code in production environments. We'll see how that shakes
>out.
>
>If this remains a build-time switch, one option would be for Debian to
>consider building 2 different binary packages. Would the maintainer be
>open to that?

Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3

[Christopher Obbard]

Hi Michael,

On Fri, 2023-09-15 at 11:42 +0200, Michael Biebl wrote:
> Am 15.09.23 um 11:06 schrieb Christopher Obbard:
> > Package: src:systemd
> > Version: 254.1-3
> > Severity: important
> > X-Debbugs-Cc: chris.obb...@collabora.com
> > 
> > Dear Maintainer,
> > 
> > Installing a new kernel on a system which uses systemd-boot as the
> > bootloader fails if python3 is not installed. Here's the snippet from apt
> > upgrade:
> > 
> >  /etc/kernel/postinst.d/zz-systemd-boot:
> >  Installing kernel version 6.4.0-4-amd64 in systemd-boot...
> >  /usr/bin/env: ‘python3’: No such file or directory
> >  /usr/lib/kernel/install.d/60-ukify.install failed with exit status 127.
> > 
> > This renders the new kernel unusable as it never actually gets installed
> > in the right place for systemd-boot.
> > 
> > /etc/kernel/postinst.d/zz-systemd-boot calls kernel-install, which in turn
> > calls /usr/lib/kernel/install.d/60-ukify.install which calls 
> > /lib/systemd/ukify
> > to attempt to create a unified kernel image. These are both python3 scripts.
> > 
> > To workaround this, I have deleted 
> > /usr/lib/kernel/install.d/60-ukify.install
> > as we don't (yet!) create uki images with the ukify utility anyway. When
> > the ukify postinst script _does_ run, it currently just detects the
> > environment variable KERNEL_INSTALL_LAYOUT != "uki" (set from some config
> > files) and exits early, not even creating the uki. So this is opt-in.
> > 
> > /lib/systemd/ukify is shipped in the systemd package along with
> > /usr/lib/kernel/install.d/60-ukify.install, which I think is wrong as
> > systemd package does not have the right dependencies for this script.
> > 
> > 
> > Perhaps we should split the ukify bits into its own package (systemd-ukify)
> > which depends on python3 and should be manually installed? Also this package
> > can then depend on e.g. sbsigntool and other packages to actually manage
> > the signing (but that can be a separate bug!).
> > 
> 
> Having a separate package feels a bit like overkill for 68K
> 
> 52K   /lib/systemd/ukify
> 8,0K  /usr/lib/kernel/install.d/60-ukify.install
> 8,0K  /usr/share/man/man1/ukify.1.gz
> 
> 
> While systemd has a suggests python3, we certainly don't want a hard 
> python3 dependency though.

> A possible middle way could be to implement 
> /usr/lib/kernel/install.d/60-ukify.install in shell, the script seems 
> simple enough.

Thank you for your reply & suggestion. I don't think that overriding this 
script manually in the Debian package is a good idea
as I think that just diverges from upstream's scripts. Also, just because the 
script is small I don't think that should 
mean it should be shipped as part of systemd and not its own package. Maybe I 
am missing some reasoning here?

Since the ukify script is designed to build a unified kernel image and also 
sign the unified kernel image using e.g.
sbsign, I think it should go into its own package so it can depend on python3 
and the required signing tools
and users can manually install it if they want to build ukis. By default users 
will probably not need to build ukis yet.
Also, Fedora and Arch seem to also package this script separately as 
systemd-ukify.

I can write a patch to do this, of course, I just would like some clarification 
on the way forward first.


Thanks!

Chris.

Bug#1051355: No more crash, this is fixed

[William Desportes]

Thank you for the upload, I can confirm this is fixed.
The CIs PASS now:
- 
- 
--
William Desportes

Bug#1051704: capnproto: Large File Support not enabled on 32 bits systems

[tony mancill]

On Mon, Sep 11, 2023 at 03:19:34PM +0200, Antonin Décimo wrote:
> Package: capnproto
> Version: 0.9.2
> Severity: important
> 
> Dear Maintainer,
> 
> capnproto doesn't define the _FILE_OFFSET_BITS=64 [1] feature test macro for
> Large File Support on 32 bits systems. As a reminder, this macro switches
> types such as off_t (size of a file) and ino_t (inode number) from 32 to 64
> bits. If capnproto encounters a file where these values exceed 32 bits, it'll
>  exit with an error.
> 
> # kj/filesystem-disk-unix.c++:305: failed: ::fstat(fd, ):
> Value too large for defined data type
> 
> The issue has been fixed upstream since v1.0.0, in commit 7c8802f [2].
> I suggest capnproto be updated to the latest version, or the macro
> _FILE_OFFSET_BITS=64 be defined globally at compile-time for this package, or
> apply the commit as a patch.
> 
> [1]: 
> https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fFILE_005fOFFSET_005fBITS
> [2]: 
> https://github.com/capnproto/capnproto/commit/7c8802fb9bec8818f289a44b0ec22419a845b249

Hi Antonin,

Thank you for the bug report.  For the short-term, I'll apply the patch
since it's so simple.  Longer-term, I'll coordinate with Tom (the
maintainer) on getting 1.0 into trixie.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1051900: ohcount: aborts with segfaul or bus error 90% of the time on arm64

[Michael Cree]

Tags: patch

Further to my prior report it is not the use of variable length array
but the overwriting the end of the array that is the problem. This bug
is repeated multiple times throughout the source file src/detector.c.
It appears that there have been attempts to fix a couple of
occurrences of the bug but even that has been cocked up. There does
not seem to be any understanding by the authors of the code that
strlen() returns the length of a string less the terminating zero.

It is astonishing that this code successfully runs on any architecture
whatsoever given the multiple array overruns!

I attach a patch that fixes many occurrences of the bug.  This is
sufficient to get ohcount running on itself on arm64 without crashing.

There are also occurrences of array underruns in the code. For example,
about line 615 of src/detector.c there is the following:

p = line;
while (p < eol) {
  if (islower(*p) && p != bof && !isalnum(*(p - 1)) && *(p - 1) != '_') {

On the first iteration of the while loop in the if statement one byte
before the start of array line can be read.  That is undefined
behaviour.  I have not fixed this in the attached patch, but it should
be reported upstream.  Frankly, the code needs a full audit for issues
such as these.

Regards,
Michael.
--- a/src/detector.c
+++ b/src/detector.c
@@ -46,7 +46,7 @@
   while (isalnum(*pe)) pe++;
   length = pe - p;
   strncpy(buf, p, length);
-  buf[length] = '\0';
+  buf[79] = '\0';
   struct LanguageMap *rl = ohcount_hash_language_from_name(buf, length);
   if (rl) return(rl->name);
 }
@@ -63,7 +63,7 @@
 } while (*p == '-'); // Skip over any switches.
 length = pe - p;
 strncpy(buf, p, length);
-buf[length] = '\0';
+buf[79] = '\0';
 struct LanguageMap *rl = ohcount_hash_language_from_name(buf, length);
 if (rl) return(rl->name);
   } else if (strstr(line, "xml")) return(LANG_XML);
@@ -146,7 +146,7 @@
 while (pe < eof) {
   // Get the contents of the first line.
   while (pe < eof && *pe != '\r' && *pe != '\n') pe++;
-  length = (pe - p <= sizeof(line)) ? pe - p : sizeof(line);
+  length = (pe - p <= sizeof(line)-1) ? pe - p : sizeof(line)-1;
   strncpy(line, p, length);
   line[length] = '\0';
   if (*line == '#' && *(line + 1) == '!') {
@@ -166,7 +166,7 @@
   }
   pe = p;
   while (!isspace(*pe) && *pe != ';' && pe != strstr(pe, "-*-")) pe++;
-  length = (pe - p <= sizeof(buf)) ? pe - p : sizeof(buf);
+  length = (pe - p <= sizeof(buf)-1) ? pe - p : sizeof(buf)-1;
   strncpy(buf, p, length);
   buf[length] = '\0';
 
@@ -236,7 +236,7 @@
 if (p && pe) {
   p += 3;
   const int length = pe - p;
-  char buf[length];
+  char buf[length+1];
   strncpy(buf, p, length);
   buf[length] = '\0';
   char *eol = buf + strlen(buf);
@@ -550,7 +550,7 @@
   // If the directory contains a matching *.m file, likely Objective C.
   length = strlen(sourcefile->filename);
   if (strcmp(sourcefile->ext, "h") == 0) {
-char path[length];
+char path[length+1];
 strncpy(path, sourcefile->filename, length);
 path[length] = '\0';
 *(path + length - 1) = 'm';
@@ -572,7 +572,7 @@
   while (pe < eof) {
 // Get a line at a time.
 while (pe < eof && *pe != '\r' && *pe != '\n') pe++;
-length = (pe - p <= sizeof(line)) ? pe - p : sizeof(line);
+length = (pe - p <= sizeof(line)-1) ? pe - p : sizeof(line)-1;
 strncpy(line, p, length);
 line[length] = '\0';
 char *eol = line + strlen(line);
@@ -594,7 +594,7 @@
   while (pe < eol && *pe != '>' && *pe != '"') pe++;
   length = pe - p;
   strncpy(buf, p, length);
-  buf[length] = '\0';
+  buf[80] = '\0';
   if (ohcount_hash_is_cppheader(buf, length))
 return LANG_CPP;
   // Is the extension for the header file a C++ file?
@@ -602,7 +602,7 @@
   while (p > line && *(p - 1) != '.') p--;
   length = pe - p;
   strncpy(buf, p, length);
-  buf[length] = '\0';
+  buf[80] = '\0';
   struct ExtensionMap *re = ohcount_hash_language_from_ext(buf, length);
   if (re && strcmp(re->value, LANG_CPP) == 0)
 return LANG_CPP;
@@ -619,7 +619,7 @@
 if (!isalnum(*pe) && *pe != '_') {
   length = pe - p;
   strncpy(buf, p, length);
-  buf[length] = '\0';
+  buf[80] = '\0';
   if (strcmp(buf, "class") == 0 ||
   strcmp(buf, "namespace") == 0 ||
   strcmp(buf, "template") == 0 ||
@@ -650,7 +650,7 @@
   if (strstr(p, ".") <= pe) {
 // Only if the filename has an extension prior to the .in
 length = pe - p;
-char buf[length];
+char buf[length+1];
 strncpy(buf, p, length);
 buf[length] = '\0';
 p = ohcount_sourcefile_get_contents(sourcefile);
@@ -741,7 +741,7 @@
   while (pe < eof) {
 // Get a line at a time.
 while 

Bug#1052012: plasma-workspace: sddm presents a white screen with no background nor buttons

[Miguel Angel Rojas]

Hi there,

Downgrading the following packages:

   - sddm-themes-breeze
   - sddm-theme-debian-breeze

to version 4:5.27.7-2 makes sddm fully usable again with no issues.

It seems some changes have been made on version 4:5.27.8-1 that have broken
sddm.

I hope this helps.

Regards

Bug#1052012: plasma-workspace: sddm presents a white screen with no background nor buttons

[Miguel Angel]

Package: plasma-workspace
Version: 4:5.27.8-1
Severity: important
X-Debbugs-Cc: mianro...@gmail.com

After upgrading from 4:5.27-7-1, sddm because unusuable. Background is
ignored (white), there are no button on the screen and the only thing you can
see on the screen is the icon showing the user and password field below
it (with very tiny asterisks) in a horrible format.


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

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

Versions of packages plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus] 1.14.10-1
ii  drkonqi  5.27.8-1
ii  frameworkintegration 5.107.0-1
ii  gdb-minimal [gdb]13.2-1
ii  init-system-helpers  1.65.2
ii  iso-codes4.15.0-1
ii  kactivitymanagerd5.27.8-1
ii  kded55.107.0-1
ii  kinit5.107.0-1
ii  kio  5.107.0-1
ii  kpackagetool55.107.0-1
ii  kwin-common  4:5.27.8-1
ii  libappstreamqt2  0.16.3-1
ii  libc62.37-9
ii  libcolorcorrect5 4:5.27.8-1
ii  libcrypt11:4.4.36-2
ii  libfontconfig1   2.14.2-6
ii  libfreetype6 2.13.2+dfsg-1
ii  libgcc-s113.2.0-4
ii  libgps30 3.25-2
ii  libice6  2:1.0.10-1
ii  libicu72 72.1-3
ii  libkf5activities55.107.0-1
ii  libkf5activitiesstats1   5.107.0-1
ii  libkf5archive5   5.107.0-1
ii  libkf5authcore5  5.107.0-1
ii  libkf5baloo5 5.107.0-1
ii  libkf5bookmarks5 5.107.0-1
ii  libkf5calendarevents55.107.0-1
ii  libkf5completion55.107.0-1
ii  libkf5config-bin 5.107.0-1
ii  libkf5configcore55.107.0-1
ii  libkf5configgui5 5.107.0-1
ii  libkf5configwidgets5 5.107.0-2
ii  libkf5coreaddons55.107.0-1
ii  libkf5crash5 5.107.0-1
ii  libkf5dbusaddons55.107.0-1
ii  libkf5declarative5   5.107.0-1
ii  libkf5globalaccel-bin5.107.0-2
ii  libkf5globalaccel5   5.107.0-2
ii  libkf5guiaddons5 5.107.0-1
ii  libkf5holidays5  1:5.107.0-1
ii  libkf5i18n5  5.107.0-1+b1
ii  libkf5iconthemes55.107.0-1+b1
ii  libkf5idletime5  5.107.0-1
ii  libkf5jobwidgets55.107.0-1
ii  libkf5kcmutils5  5.107.0-2
ii  libkf5kexiv2-15.0.0  23.04.2-2
ii  libkf5kiocore5   5.107.0-1
ii  libkf5kiofilewidgets55.107.0-1
ii  libkf5kiogui55.107.0-1
ii  libkf5kiowidgets55.107.0-1
ii  libkf5networkmanagerqt6  5.107.0-1
ii  libkf5newstuff5  5.107.0-1
ii  libkf5newstuffcore5  5.107.0-1
ii  libkf5newstuffwidgets5   5.107.0-1
ii  libkf5notifications5 5.107.0-1
ii  libkf5notifyconfig5  5.107.0-1
ii  libkf5package5   5.107.0-1
ii  libkf5parts5 5.107.0-1
ii  libkf5people55.107.0-1
ii  

Bug#1052011: iscsitarget-dkms: Module fails to compile

[TimW]

Package: iscsitarget-dkms
Version: 1.4.20.3+svn502-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: t...@tee-jay.org.uk

Dear Maintainer,

Trying to install this package dkms fails to compile the module


make.log is as follows:
DKMS make.log for iscsitarget-1.4.20.3+svn502 for kernel 6.1.21+ (armv7l)
Fri 15 Sep 23:04:56 BST 2023
make: Entering directory '/usr/src/linux-headers-6.1.21+'
  CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/tio.o
  CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/iscsi.o
  CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/nthread.o
  CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/wthread.o
In file included from 
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/nthread.c:16:
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/iscsi.h:274:19: error: 
field ‘rx_hash’ has incomplete type
  274 |  struct hash_desc rx_hash;
  |   ^~~
In file included from 
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/tio.c:7:
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/iscsi.h:274:19: error: 
field ‘rx_hash’ has incomplete type
  274 |  struct hash_desc rx_hash;
  |   ^~~
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/iscsi.h:275:19: error: 
field ‘tx_hash’ has incomplete type
  275 |  struct hash_desc tx_hash;
  |   ^~~
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/iscsi.h:275:19: error: 
field ‘tx_hash’ has incomplete type
  275 |  struct hash_desc tx_hash;
  |   ^~~
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/nthread.c: In function 
‘iscsi_conn_init_read’:
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/nthread.c:45:17: error: 
‘struct msghdr’ has no member named ‘msg_iov’; did you mean ‘msg_inq’?
   45 |  conn->read_msg.msg_iov = conn->read_iov;
  | ^~~
  | msg_inq
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/nthread.c:46:16: error: 
‘struct msghdr’ has no member named ‘msg_iovlen’
   46 |  conn->read_msg.msg_iovlen = 1;
  |^
In file included from ./include/linux/kernel.h:26,
 from ./include/linux/cpumask.h:10,
 from ./include/linux/smp.h:13,
 from ./include/linux/lockdep.h:14,
 from ./include/linux/spinlock.h:63,
 from ./include/linux/wait.h:9,
 from ./include/linux/wait_bit.h:8,
 from ./include/linux/fs.h:6,
 from ./include/linux/highmem.h:5,
 from ./include/linux/bvec.h:10,
 from ./include/linux/blk_types.h:10,
 from ./include/linux/blkdev.h:9,
 from 
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/iscsi.h:11,
 from 
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/tio.c:7:
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/tio.c: In function 
‘tio_add_data’:
./include/linux/minmax.h:20:28: warning: comparison of distinct pointer types 
lacks a cast
   20 |  (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
  |^~
./include/linux/minmax.h:26:4: note: in expansion of macro ‘__typecheck’
   26 |   (__typecheck(x, y) && __no_side_effects(x, y))
  |^~~
./include/linux/minmax.h:36:24: note: in expansion of macro ‘__safe_cmp’
   36 |  __builtin_choose_expr(__safe_cmp(x, y), \
  |^~
./include/linux/minmax.h:45:19: note: in expansion of macro ‘__careful_cmp’
   45 | #define min(x, y) __careful_cmp(x, y, <)
  |   ^
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/tio.c:75:25: note: in 
expansion of macro ‘min’
   75 |  const size_t to_copy = min(tio->pg_cnt * PAGE_SIZE - iter->size, len);
  | ^~~
./include/linux/minmax.h:20:28: warning: comparison of distinct pointer types 
lacks a cast
   20 |  (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
  |^~
./include/linux/minmax.h:26:4: note: in expansion of macro ‘__typecheck’
   26 |   (__typecheck(x, y) && __no_side_effects(x, y))
  |^~~
./include/linux/minmax.h:36:24: note: in expansion of macro ‘__safe_cmp’
   36 |  __builtin_choose_expr(__safe_cmp(x, y), \
  |^~
./include/linux/minmax.h:45:19: note: in expansion of macro ‘__careful_cmp’
   45 | #define min(x, y) __careful_cmp(x, y, <)
  |   ^
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/tio.c:82:18: note: in 
expansion of macro ‘min’
   82 |   size_t chunk = min(PAGE_SIZE - iter->pg_off, residual);
  |  ^~~
In file included from 
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/wthread.c:9:

Bug#1052010: package contains license CC-BY-NC-ND-3.0

[Thorsten Alteholz]

Package: lemonldap-ng
Version: 2.0.2+ds-7+deb10u7
Severity: serious
User: alteh...@debian.org
Usertags: license
thanks


Hi,

unfortunately your package contains files with license: CC-BY-NC-ND-3.0

This license is not compatible with DFSG, so please remove the files or
move the package to non-free.

Thanks!
 Thorsten

Bug#1052008: gm2-13 Cannot Find Its Libraries At Link Time

[Ron Lovell]

Package: gm2-13
Version: 13.2.0-4
Severity: important
X-Debbugs-Cc: ron163...@startmail.com

Dear Maintainer,

Since the upgrade from gm2-12 to gm2-13, the link step fails:

/usr/bin/gm2 -fpim -flibs=m2pim,m2cor,m2iso -o topsort_m2 ../topsort.mod
FAILED: topsort_m2
/usr/bin/gm2 -fpim -flibs=m2pim,m2cor,m2ios -o topsort_m2 ../topsort.mod
/usr/bin/ld: cannot find -lm2pim: No such file or directory
/usr/bin/ld: cannot find -lm2cor: No such file or directory
/usr/bin/ld: cannot find -lm2iso: No such file or directory
collect2: error: ld returned 1 exit status

As a temporary workaround, I modified my build flags to include the
subdirectories containing links to the shared libraries:

/usr/bin/gm2 -L/usr/lib/gcc/x86_64-linux-gnu/13/m2/m2pim/
-L/usr/lib/gcc/x86_64-linux-gnu/13/m2/m2cor/ -L/usr/lib/gcc/x86_64-linux-
gnu/13/m2/m2iso/ -fpim -flibs=m2pim,m2cor,m2iso -o topsort_m2 ../topsort.mod

The GNU Modula-2 packages installed are:

gm2_4:13.2.0-1_amd64
gm2-13_13.2.004_amd64
libgm2-13-dev_13.2.0-4_amd64
libgm2-18_13.2.0-4_amd64


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

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

Versions of packages gm2-13 depends on:
ii  g++-13 13.2.0-4
ii  gcc-13-base13.2.0-4
ii  libc6  2.37-9
ii  libgcc-s1  13.2.0-4
ii  libgm2-13-dev  13.2.0-4
ii  libgmp10   2:6.3.0+dfsg-2
ii  libisl23   0.26-3
ii  libmpc31.3.1-1
ii  libmpfr6   4.2.1-1
ii  libstdc++6 13.2.0-4
ii  libzstd1   1.5.5+dfsg2-1
ii  zlib1g 1:1.2.13.dfsg-3

gm2-13 recommends no packages.

gm2-13 suggests no packages.

-- no debconf information

Bug#1036818: lxcfs: /proc/cpuinfo is empty inside lxc on armel and armhf

[Mathias Gibbens]

  FYI, I've submitted bug #1052007 to cherry-pick this fix back to
bookworm as well. When it's accepted, I'll update the fixed versions
for this bug.

Mathias


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

Bug#1052007: bookworm-pu: package lxcfs/5.0.3-1+deb12u1

[Mathias Gibbens]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-lxc-de...@lists.alioth.debian.org, gib...@debian.org
Control: affects -1 + src:lxcfs

[ Reason ]
lxcfs 5.0.3-1 has a bug where /proc/cpuinfo is not properly reported
within a 32bit arm container when the 64bit host has more than ~13
CPUs. This was initially reported in #1036818 and impacts some
autopkgtests run on the ci.debian.net arm hosts.

I have uploaded lxcfs 5.0.4-1 to unstable with a fix cherry-picked from
the upstream main branch, and would like to include it in bookworm's
version of lxcfs so that the CI arm servers can operate properly.

[ Impact ]
autopkgtests run on the CI infrastructure have been erroneously failing
for some packages, requiring workarounds. Fixing this will allow
autopkgtests for armel/armhf runs to be useful once again.

[ Tests ]
I have tested the patch locally in a QEMU VM, both when initially
debugging the issue as well as installing the proposed update. The
changes have been reviewed and accepted by the upstream developers.

[ Risks ]
The risk of regression is limited -- the changes have been reviewed and
accepted by the upstream developers. The fix is small and targeted.

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

[ Changes ]
Backport upstream commit fc8f593bda9eb4692daa07512ef6ba60dc39aded,
which was merged upstream earlier today and will be included in the
next release of lxcfs. There's also a small change to adjust the
default branch used by gbp to reflect the new branch for bookworm
fixes.

[ Other info ]
The source debdiff is attached.
diff -Nru lxcfs-5.0.3/debian/changelog lxcfs-5.0.3/debian/changelog
--- lxcfs-5.0.3/debian/changelog	2023-01-17 01:21:28.0 +
+++ lxcfs-5.0.3/debian/changelog	2023-09-15 21:32:11.0 +
@@ -1,3 +1,11 @@
+lxcfs (5.0.3-1+deb12u1) bookworm; urgency=medium
+
+  * Cherry-pick upstream fix for /proc/cpuinfo being empty within an arm32
+container with large numbers of CPUs (See: #1036818)
+  * Adjust branch in d/gbp.conf
+
+ -- Mathias Gibbens   Fri, 15 Sep 2023 21:32:11 +
+
 lxcfs (5.0.3-1) unstable; urgency=medium
 
   [ Mathias Gibbens ]
diff -Nru lxcfs-5.0.3/debian/gbp.conf lxcfs-5.0.3/debian/gbp.conf
--- lxcfs-5.0.3/debian/gbp.conf	2023-01-17 01:21:28.0 +
+++ lxcfs-5.0.3/debian/gbp.conf	2023-09-15 21:32:07.0 +
@@ -1,3 +1,3 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = master
+debian-branch = debian/bookworm
diff -Nru lxcfs-5.0.3/debian/patches/000-fix-arm32-personality.patch lxcfs-5.0.3/debian/patches/000-fix-arm32-personality.patch
--- lxcfs-5.0.3/debian/patches/000-fix-arm32-personality.patch	1970-01-01 00:00:00.0 +
+++ lxcfs-5.0.3/debian/patches/000-fix-arm32-personality.patch	2023-09-15 21:32:07.0 +
@@ -0,0 +1,88 @@
+From fc8f593bda9eb4692daa07512ef6ba60dc39aded Mon Sep 17 00:00:00 2001
+From: Mathias Gibbens 
+Date: Mon, 4 Sep 2023 00:13:57 +
+Subject: [PATCH] proc: Fix /proc/cpuinfo not respecting personality
+
+It was found that the personality within the container was not being
+properly respected, which for large numbers of CPUs would break
+reporting of /proc/cpuinfo in arm32 containers running on an arm64 host.
+
+Signed-off-by: Mathias Gibbens 
+---
+ src/proc_fuse.c | 49 +++--
+ 1 file changed, 47 insertions(+), 2 deletions(-)
+
+diff --git a/src/proc_fuse.c b/src/proc_fuse.c
+index 25af10a1..40eb2680 100644
+--- a/src/proc_fuse.c
 b/src/proc_fuse.c
+@@ -82,6 +82,45 @@ static off_t get_procfile_size(const char *path)
+ 	return answer;
+ }
+ 
++static off_t get_procfile_size_with_personality(const char *path)
++{
++	struct fuse_context *fc = fuse_get_context();
++	__u32 host_personality = liblxcfs_personality(), caller_personality;
++	bool change_personality;
++	int ret;
++	off_t procfile_size_ret;
++
++	if (get_task_personality(fc->pid, _personality) < 0)
++		return log_error(0, "Failed to get caller process (pid: %d) personality", fc->pid);
++
++	/* do we need to change thread personality? */
++	change_personality = host_personality != caller_personality;
++
++	if (change_personality) {
++		ret = personality(caller_personality);
++		if (ret == -1)
++			return log_error(0, "Call to personality(%d) failed: %s\n",
++	caller_personality, strerror(errno));
++
++		lxcfs_debug("task (tid: %d) personality was changed %d -> %d\n",
++(int)syscall(SYS_gettid), ret, caller_personality);
++	}
++
++	procfile_size_ret = get_procfile_size(path);
++
++	if (change_personality) {
++		ret = personality(host_personality);
++		if (ret == -1)
++			return log_error(0, "Call to personality(%d) failed: %s\n",
++	host_personality, strerror(errno));
++
++		lxcfs_debug("task (tid: %d) personality 

Bug#1052006: linux-image-6.5.0-1-amd64 breaks X on amd GPU

[Klaus Ethgen]

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

Booting with the new kernel makes the display (1920x1200) heavily
flckering, diplaying two times the same one above the other and only
displaying about 1/4 of the screen smashed together on the left border
of the screen.

That way it is not usable at all and I have to boot the older kernel
(linux-image-6.4.0-4-amd64) to get it working again.

To compare the resolution section in Xorg.log. The old and working
kernel has the following:
  [14.606] (II) AMDGPU(0): Modeline "1920x1200"x60.0  596.20  1920 3888 
3920 4000  1200 2403 2408 2484 -hsync -vsync (149.1 kHz UeP)
  [14.606] (II) AMDGPU(0): Modeline "3840x2400"x60.0  596.20  3840 3888 
3920 4000  2400 2403 2408 2484 -hsync -vsync (149.1 kHz eP)
  [14.606] (II) AMDGPU(0): Modeline "1920x1080"x60.0  596.20  1920 3888 
3920 4000  1080 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [14.606] (II) AMDGPU(0): Modeline "1600x1200"x60.0  596.20  1600 3888 
3920 4000  1200 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [14.606] (II) AMDGPU(0): Modeline "1680x1050"x60.0  596.20  1680 3888 
3920 4000  1050 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [14.607] (II) AMDGPU(0): Modeline "1280x1024"x60.0  596.20  1280 3888 
3920 4000  1024 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [14.607] (II) AMDGPU(0): Modeline "1440x900"x60.0  596.20  1440 3888 3920 
4000  900 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [14.607] (II) AMDGPU(0): Modeline "1280x800"x60.0  596.20  1280 3888 3920 
4000  800 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [14.607] (II) AMDGPU(0): Modeline "1280x720"x60.0  596.20  1280 3888 3920 
4000  720 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [14.607] (II) AMDGPU(0): Modeline "1024x768"x60.0  596.20  1024 3888 3920 
4000  768 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [14.607] (II) AMDGPU(0): Modeline "800x600"x60.0  596.20  800 3888 3920 
4000  600 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [14.607] (II) AMDGPU(0): Modeline "640x480"x60.0  596.20  640 3888 3920 
4000  480 2403 2408 2484 -hsync -vsync (149.1 kHz e)

while the new and broken one has the following:
  [24.377] (II) AMDGPU(0): Modeline "1920x1200"x60.0  596.20  1920 3888 
3920 4000  1200 2403 2408 2484 -hsync -vsync (149.1 kHz UeP)
  [24.377] (II) AMDGPU(0): Modeline "3840x2400"x60.0  596.20  3840 3888 
3920 4000  2400 2403 2408 2484 -hsync -vsync (149.1 kHz eP)
  [24.377] (II) AMDGPU(0): Modeline "3840x2400"x50.0  596.20  3840 3888 
3920 4000  2400 2900 2905 2981 -hsync -vsync (149.1 kHz e)
  [24.377] (II) AMDGPU(0): Modeline "3840x2400"x48.0  596.20  3840 3888 
3920 4000  2400 3024 3029 3105 -hsync -vsync (149.1 kHz e)
  [24.377] (II) AMDGPU(0): Modeline "1920x1080"x60.0  596.20  1920 3888 
3920 4000  1080 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [24.377] (II) AMDGPU(0): Modeline "1600x1200"x60.0  596.20  1600 3888 
3920 4000  1200 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [24.377] (II) AMDGPU(0): Modeline "1680x1050"x60.0  596.20  1680 3888 
3920 4000  1050 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [24.377] (II) AMDGPU(0): Modeline "1280x1024"x60.0  596.20  1280 3888 
3920 4000  1024 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [24.377] (II) AMDGPU(0): Modeline "1440x900"x60.0  596.20  1440 3888 3920 
4000  900 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [24.377] (II) AMDGPU(0): Modeline "1280x800"x60.0  596.20  1280 3888 3920 
4000  800 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [24.377] (II) AMDGPU(0): Modeline "1280x720"x60.0  596.20  1280 3888 3920 
4000  720 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [24.377] (II) AMDGPU(0): Modeline "1024x768"x60.0  596.20  1024 3888 3920 
4000  768 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [24.377] (II) AMDGPU(0): Modeline "800x600"x60.0  596.20  800 3888 3920 
4000  600 2403 2408 2484 -hsync -vsync (149.1 kHz e)
  [24.377] (II) AMDGPU(0): Modeline "640x480"x60.0  596.20  640 3888 3920 
4000  480 2403 2408 2484 -hsync -vsync (149.1 kHz e)

Note that the broken setup has 3 lines of 3840x2400, althogh I use
1920x1200 as resolution.

Going a bit down to search for more differences, I see the following
lines in the broken kernel:
  [29.577] (II) AMDGPU(0): EDID vendor "AUO", prod id 58272
  [29.577] (II) AMDGPU(0): Using EDID range info for horizontal sync
  [29.577] (II) AMDGPU(0): Using EDID range info for vertical refresh
  [29.577] (II) AMDGPU(0): Printing DDC gathered Modelines:
  [29.577] (II) AMDGPU(0): Modeline "3840x2400"x0.0  596.20  3840 3888 3920 
4000  2400 2403 2408 2484 -hsync -vsync (149.1 kHz eP)

while on the good one, I see:
  [23.420] (II) AMDGPU(0): EDID vendor "AUO", prod id 58272
  [23.420] (II) AMDGPU(0): Using EDID range info for horizontal sync
  [23.420] (II) AMDGPU(0): Using EDID range info for vertical refresh
  [23.420] (II) AMDGPU(0): Printing DDC gathered Modelines:
  [23.420] (II) AMDGPU(0): 

Bug#1052005: KDE Plasma with IBus: im-config changes needed

[Gunnar Hjalmarsson]

Package: im-config
Version: 0.57-2
Severity: important

If you use IBus in a Plasma (Wayland) session, the intention seems to be 
that you apply an "IBus Wayland" virtual keyboard and let Wayland handle 
everything internally. Otherwise the suggestion window does not show up, 
for instance. OTOH, with the virtual keyboard enabled im-config should 
better be disabled.


In a Plasma (X11) session im-config keeps dealing with IBus as intended.

Probably we should change im-config so it doesn't do anything in case of 
a Plasma (Wayland) session. However, during my tests things get 
extremely slow with that "IBus Wayland" virtual keyboard enabled, which 
may be a bug or a "user error" from my side.


In any case it's highly desirable that any changes are made in 
consultation with somebody who actually uses IBus together with Plasma.


--
Gunnar Hjalmarsson

Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.

[Sebastian Andrzej Siewior]

On 2023-09-15 15:51:51 [+0200], Felix Zielcke wrote:
> Hi Sebastian,

Hi Felix,

> there's now a patch from Jon DeVree upstream, which might fix this for
> you. Is it possible for you to test his patch?
> 
> https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html

Yes it sovles the issue, the box boots.

Sebastian

Bug#1051371: Post-/usr-merge paths for script interpreters

[Russ Allbery]

Luca Boccassi  writes:
> On Wed, 13 Sept 2023 at 04:48, Russ Allbery  wrote:

>> Simon pointed out that this bug is not yet ready to act on, which was
>> very helpful.  Thank you.  However, presumably the buildds will be
>> /usr-merged at some point in the not-too-distant future, and we do need
>> to decide what to do after that point.

> While that could be said for the original revision, in my view that's
> not really the case for the latest that I posted?

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051371#120

> So I would prefer if this was a clone rather than a retitle/repurpose.
> Unless I'm missing something, the changes linked above should be
> uncontroversial and simply remove excessively normative language in what
> are essentially examples that should have been taken as such - and that
> currently are not. So, could that be taken forward independently of the
> problem you define below?

I believe it would be an error to move Policy away from explicitly saying
/bin/sh as long as we have unmerged systems.  For as long as we have to
support unmerged systems, which includes the buildds because quite a
surprising range of packages end up needing to be installed on buildds
during package builds, packages must use /bin/sh and may not use
/usr/bin/sh.

This is not currently explicit in Policy because previously it wasn't
necessary.  Packages using /usr/bin/sh would simply not work, thus forcing
the issue.  But right now, if we were writing Policy from scratch, we
would need to explicitly say that using /bin/sh is a must in order to
avoid breaking the buildds, since /usr/bin/sh would appear to work locally
and then potentially cause weird problems during package builds.  (Ideally
build failure, but a lot of strange things can happen when paths are
missing during a build.)

Presumably this is getting fixed in short order, so it's not worth the
intermediate Policy change to add that language only to remove it again.
But similarly, I don't think it's correct to relax Policy language about
the /bin/sh path for as long as using /usr/bin/sh is potentially a
release-critical bug.

Obviously this all becomes moot as soon as the buildds are /usr-merged.

> I think b would work out fine, but if we want to start being normative
> then it probably would make more sense to go for the new layout rather
> than the old. It would seem strange to have lived with the old layout
> and no rule, and suddenly add a rule for the old layout just as it has
> been phased out, no?

The reason why this is not strange to me (which is not to say that this is
my personal preference) is that previously we had a rule requiring /bin/sh
enforced by a much harsher mechanism than Policy:  using /usr/bin/sh would
simply break.  So we *did* have a de facto rule, which we implicitly
dropped by doing /usr-merge, and the debate is whether to replace it with
a de jure rule.

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

Bug#950308: linux-signed-amd64: Please set CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER

[Ross Beazley]

> So it needs to be made opt-in through a kernel
> parameter (which we might set by default, later on).

I only stumbled onto this recently whilst attempting to get a flicker free
boot, i think the kernel param you are looking for is

fbcon=nodefer

6. fbcon=nodefer

If the kernel is compiled with deferred fbcon takeover support, normally
the framebuffer contents, left in place by the firmware/bootloader, will
be preserved until there actually is some text is output to the console.
This option causes fbcon to bind immediately to the fbdev device.

so maybe we could set CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y
in conjunction with fbcon=nodefer


?


On Fri, 31 Jan 2020 12:03:03 +0100 Ben Hutchings 
wrote:
> Control: reassign src:linux
> Control: forcemerge 926794 -1
>
> On Fri, 2020-01-31 at 19:22 +1100, Julien Goodwin wrote:
> > Package: linux-signed-amd64
> > Version: 5.4.13+1
> > Severity: wishlist
> >
> > Please consider setting CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y
> > to allow for "flicker free" booting (when combined with appropriate
> > bootloader & plymouth configs).
>
> And there's the problem: this actually looks really bad without those
> config changes.  So it needs to be made opt-in through a kernel
> parameter (which we might set by default, later on).
>
> > The upstream patch introducing the behaviour:
> > https://patchwork.kernel.org/patch/10432641/
> >
> > Fedora (29) & Arch are known to set this on their kernels.
>
> Ben.
>
> --
> Ben Hutchings
> 73.46% of all statistics are made up.
>

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

[Russ Allbery]

Guillem Jover  writes:

> Not shipping these empty directories in the .deb seems like a regression
> or a disservice to me. Even for things that might get deleted because
> things like our policy or the FHS allows for it (say stuff under
> /var/cache), as «dpkg --verify» can be useful. Because of course, these
> in addition, can be defined via tmpfiles.d, so that they can possibly be
> recreated if needed (until dpkg provides its own interfaces to do that).

Luca, are there any drawbacks for your purposes in both shipping the
directories in the deb *and* defining them with tmpfiles.d for those cases
where it is possible to ship them in the deb (no dynamic owner or group,
for instance)?  At first glance, it feels like this should be fine, since
tmpfiles.d will recreate the directories and dpkg will then be happy with
them.

It does potentially create problems if dpkg and tmpfiles.d have different
ideas about what the ownership or permissions of the directories should
be, but at present I don't think such conflicts would create a lot of
practical problems (tmpfiles.d should essentialy always win), so I think
it's a fairly minor point.

It's a bit more complicated to specify in Policy because it's not possible
to include the directory in the deb file in cases where it needs to have
ownership set based on users or groups created dynamically by the
maintainer scripts, but hopefully not overly complicated.

This has the valuable benefit, as Guillem points out, of retaining dpkg
database awareness of the association between that directory and a package
until such time as dpkg is aware of files defined in tmpfiles.d (directly
or indirectly via debhelper magic to register the tmpfiles.d targets with
a new dpkg dynamic file database; the latter is my guess about where we're
headed based on previous discussions).

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

Bug#1052002: firefox: FTBFS: ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix the problem. Or build with --without-wasm-sandboxed-libraries

[Mike Hommey]

reassign 1052002 clang-16
affects 1052002 firefox
affects 1052002 firefox-esr
thanks

On Fri, Sep 15, 2023 at 08:19:17PM +0200, Aurelien Jarno wrote:
> Source: firefox
> Version: 117.0.1-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> Dear maintainer,
> 
> firefox fails to build from source. From my build log on amd64:
> 
> | checking for vpx >= 1.10.0... yes
> | checking MOZ_LIBVPX_CFLAGS... 
> | checking MOZ_LIBVPX_LIBS... -lvpx -lm
> | checking for vpx/vpx_decoder.h... yes
> | checking for vpx_codec_dec_init_ver... yes
> | checking for nasm... /usr/bin/nasm
> | checking nasm version... 2.16.01
> | checking for the wasm C compiler... /usr/bin/clang
> | checking whether the wasm C compiler can be used... yes
> | checking the wasm C compiler version... 16.0.6
> | checking the wasm C compiler works... yes
> | checking the wasm C compiler can find wasi headers... yes
> | checking the wasm C linker can find wasi libraries... yes
> | checking for the wasm C++ compiler... /usr/bin/clang++
> | checking whether the wasm C++ compiler can be used... yes
> | checking the wasm C++ compiler version... 16.0.6
> | checking the wasm C++ compiler works... yes
> | checking the wasm C++ compiler can find wasi headers... 
> | DEBUG: Creating `/tmp/conftest.t4tbmgsv.cpp` with content:
> | DEBUG: | #include 
> | DEBUG: | int
> | DEBUG: | main(void)
> | DEBUG: | {
> | DEBUG: | 
> | DEBUG: |   ;
> | DEBUG: |   return 0;
> | DEBUG: | }
> | DEBUG: Executing: `/usr/bin/clang++ --target=wasm32-wasi 
> /tmp/conftest.t4tbmgsv.cpp -c`
> | DEBUG: The command returned non-zero exit status 1.
> | DEBUG: Its error output was:
> | DEBUG: | /tmp/conftest.t4tbmgsv.cpp:1:10: fatal error: 'cstring' file not 
> found
> | DEBUG: | #include 
> | DEBUG: |  ^
> | DEBUG: | 1 error generated.
> | ERROR: Cannot find wasi headers or problem with the wasm compiler. Please 
> fix the problem. Or build with --without-wasm-sandboxed-libraries.
> | make[1]: *** [debian/rules:228: stamps/configure-browser] Error 1
> | make[1]: Leaving directory '/<>'
> | make: *** [debian/rules:329: build-arch] Error 2
> | dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2

This is a regression from the upgrade to clang 16.

with clang 14:
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/wasm32-wasi/c++/v1
 /usr/lib/llvm-14/lib/clang/14.0.6/include
 /usr/local/include
 /usr/include/wasm32-wasi
 /usr/include
End of search list.

with clang 16:
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/llvm-16/lib/clang/16/include
 /usr/local/include
 /usr/include/wasm32-wasi
 /usr/include
End of search list.

Note how /usr/include/wasm32-wasi/c++/v1 is missing.

Mike

Bug#1042140: trophy: FTBFS: undefined reference to `pthread_mutexattr_setkind_np'

[Markus Koschany]

Control: reassign -1 src:clanlib
Control: tags -1 pending

This is actually a bug in clanlib which surfaced because of the recent uploads
/ rebuilds against glibc > 2.34. The pthread_mutexattr_setkind_np symbol is
obsolete and has been replaced by pthread_mutexattr_settype.




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

Bug#1051368: python3-selenium: Selenium Python still can't find chromedriver

[Jonathan Kamens]

I believe your decision not to include Selenium Manager in the 
python3-selenium package is objectively incorrect, inconsistent with 
what is required for the correct functioning of the package and 
inconsistent with the clearly stated intent of the package vendor.


I do not believe an RFP is the correct answer, because I don't believe 
Selenium Manager should be put in a separate package from the rest of 
the Python Selenium driver. The maintainers of Selenium clearly intend 
it to be packaged with the driver; that's what they've said, and that's 
what they've done, in that the PyPI packages have Selenium Manager 
embedded in them (though only for x86_64).


I did some research and found that it takes only four straightforward 
steps to compile Selenium Manager from source for any platform:


1. Download the Selenium source code from GitHub or somewhere else it
   is published
2. Download a bazel binary from
   https://github.com/bazelbuild/bazelisk/releases and make it
   executable in your search path
3. Unpack the Selenium source code
4. Run "bazel build //rust:selenium-manager" in the top directory of
   the Selenium source code

After these four steps, the Selenium Manager is available for packaging 
in bazel-bin/rust/selenium-manager.


It does not seem like this is too much work for Debian's 
python3-selenium package build scripts to do.


I believe the decision not to include Selenium Manager in the package is 
sufficiently wrong to justify escalating this to the Technical Committee 
 if necessary.

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

[Guillem Jover]

Hi!

On Tue, 2023-09-12 at 22:17:44 -0700, Russ Allbery wrote:
> Russ Allbery  writes:
> > Russ Allbery  writes:
> >> Maybe the right way to do this is just have two examples, one as the
> >> default and another if you're using tmpfiles.d functionality added in a
> >> specific version of systemd that's newer than the version shipped with
> >> the stable version of Debian prior to the one you're targeting.
> 
> > Here's an updated version with that change plus some other minor fixes.
> 
> Er, right, helps to rebase first.  Here's the actual patch.

> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> index b34c183..fa3e5be 100644
> --- a/policy/ch-files.rst
> +++ b/policy/ch-files.rst
> @@ -722,6 +722,70 @@ The name of the files and directories installed by 
> binary packages
>  outside the system PATH must be encoded in UTF-8 and should be
>  restricted to ASCII when it is possible to do so.
>  
> +.. _s-tmpfiles.d:
> +
> +Volatile and temporary files (``tmpfiles.d``)
> +-
> +
> +Some packages require empty directories in ``/var`` or ``/etc``, or

Not shipping these empty directories in the .deb seems like a
regression or a disservice to me. Even for things that might get
deleted because things like our policy or the FHS allows for it (say
stuff under /var/cache), as «dpkg --verify» can be useful. Because of
course, these in addition, can be defined via tmpfiles.d, so that they
can possibly be recreated if needed (until dpkg provides its own
interfaces to do that).

> +symlinks or files with trivial content in ``/var``, to implement their
> +functionality.  Examples include directories under ``/var/cache`` that are
> +writable by the package as cache areas, an initially-empty directory in
> +``/etc`` intended for local overrides added by the local system
> +administrator, or a file in ``/var`` that should default to a symlink
> +elsewhere on the system but may be changed later.
> +
> +Rather than include these symlinks, files, or directories in the binary
> +package or create them in package maintainer scripts, packages should use
> +the ``tmpfiles.d`` mechanism to specify the files and directories that
> +should be created.  This allows associating these files and directories
> +with specific packages (not currently possible when creating them in
> +maintainer scripts),

Well, this association would then only be indirect, instead of being able
to get at them via say «dpkg-query --search» or «dpkg-query --listfiles».

>   and allows local administrators to delete the
> +contents of directories such as ``/var/cache`` with the assurance that
> +``tmpfiles.d`` can recreate the necessary file structure without
> +reinstalling packages or re-running maintainer scripts.

Thanks,
Guillem

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

[Timo Sigurdsson]

Hi,

Salvatore Bonaccorso schrieb am 12.09.2023 21:13 (GMT +02:00):

> Hi Timo,
> 
> On Tue, Sep 12, 2023 at 01:39:59PM +0200, Timo Sigurdsson wrote:
>> Hi Pablo,
>> 
>> Pablo Neira Ayuso schrieb am 12.09.2023 00:57 (GMT +02:00):
>> 
>> > Hi Timo,
>> > 
>> > On Mon, Sep 11, 2023 at 11:37:50PM +0200, Timo Sigurdsson wrote:
>> >> Hi,
>> >> 
>> >> recently, Debian updated their stable kernel from 6.1.38 to 6.1.52
>> >> which broke nftables ruleset loading on one of my machines with lots
>> >> of "Operation not supported" errors. I've reported this to the
>> >> Debian project (see link below) and Salvatore Bonaccorso and I
>> >> identified "netfilter: nf_tables: disallow rule addition to bound
>> >> chain via NFTA_RULE_CHAIN_ID" (0ebc1064e487) as the offending commit
>> >> that introduced the regression. Salvatore also found that this issue
>> >> affects the 5.10 stable tree as well (observed in 5.10.191), but he
>> >> cannot reproduce it on 6.4.13 and 6.5.2.
>> >> 
>> >> The issue only occurs with some rulesets. While I can't trigger it
>> >> with simple/minimal rulesets that I use on some machines, it does
>> >> occur with a more complex ruleset that has been in use for months
>> >> (if not years, for large parts of it). I'm attaching a somewhat
>> >> stripped down version of the ruleset from the machine I originally
>> >> observed this issue on. It's still not a small or simple ruleset,
>> >> but I'll try to reduce it further when I have more time.
>> >> 
>> >> The error messages shown when trying to load the ruleset don't seem
>> >> to be helpful. Just two simple examples: Just to give two simple
>> >> examples from the log when nftables fails to start:
>> >> /etc/nftables.conf:99:4-44: Error: Could not process rule: Operation not
>> >> supported
>> >> tcp option maxseg size 1-500 counter drop
>> >> ^
>> >> /etc/nftables.conf:308:4-27: Error: Could not process rule: Operation not
>> >> supported
>> >> tcp dport sip-tls accept
>> >> 
>> > 
>> > I can reproduce this issue with 5.10.191 and 6.1.52 and nftables v1.0.6,
>> > this is not reproducible with v1.0.7 and v1.0.8.
>> > 
>> >> Since the issue only affects some stable trees, Salvatore thought it
>> >> might be an incomplete backport that causes this.
>> >> 
>> >> If you need further information, please let me know.
>> > 
>> > Userspace nftables v1.0.6 generates incorrect bytecode that hits a new
>> > kernel check that rejects adding rules to bound chains. The incorrect
>> > bytecode adds the chain binding, attach it to the rule and it adds the
>> > rules to the chain binding. I have cherry-picked these three patches
>> > for nftables v1.0.6 userspace and your ruleset restores fine.
>> 
>> hmm, that doesn't explain why Salvatore didn't observe this with
>> more recent kernels.
>> 
>> Salvatore, did you use newer userspace components when you tested
>> your 6.4.13 and 6.5.2 builds?
> 
> It does explain now because understanding the issue better. While one
> while experinting should only change each one constraint for the
> 6.4.13 and 6.5.2 testing I indeed switched to a Debian unstable
> system, which has newer userpace nftables and so not triggering the
> issue. This was missleading for the report.
> 
>> As for the regression and how it be dealt with: Personally, I don't
>> really care whether the regression is solved in the kernel or
>> userspace. If everybody agrees that this is the best or only viable
>> option and Debian decides to push a nftables update to fix this,
>> that works for me. But I do feel the burden to justify this should
>> be high. A kernel change that leaves users without a working packet
>> filter after upgrading their machines is serious, if you ask me. And
>> since it affects several stable/longterm trees, I would assume this
>> will hit other stable (non-rolling) distributions as well, since
>> they will also use older userspace components (unless this is
>> behavior specific to nftables 1.0.6 but not older versions). They
>> probably should get a heads up then.
> 
> So if it is generally believed on kernel side there should not happen
> any further changes to work with older userland, I guess in Debian we
> will need to patch nftables. I'm CC'ing Arturo Borrero Gonzalez
> , maintainer for the package. The update should go
> ideally in the next point releases from October (and maybe released
> earlier as well trough the stable-updates mechanism).

So, I built nftables 1.0.6-2+deb12u1 with the three cherry-picked patches from 
Pablo and can confirm that they resolve the issue for me on bookworm. I can now 
run linux 6.1.52-1 and load my original nftables ruleset again.
 
> FWIW: In Debian bullseye we have 0.9.8 based nftables, in bookworm
> 1.0.6, so both will need those fixes.
> 
> As 0ebc1064e487 is to address CVE-2023-4147 other distros picking the
> fix will likely 

Bug#1051371: Post-/usr-merge paths for script interpreters

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Wed, 13 Sept 2023 at 04:48, Russ Allbery  wrote:
>> 
>> Control: retitle -1 Post-/usr-merge paths for script interpreters
>> 
>> Simon pointed out that this bug is not yet ready to act on, which
>> was very helpful.  Thank you.  However, presumably the buildds
>> will be /usr-merged at some point in the not-too-distant future,
>> and we do need to decide what to do after that point.

Luca> While that could be said for the original revision, in my view
Luca> that's not really the case for the latest that I posted?

Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051371#120

Luca> So I would prefer if this was a clone rather than a
Luca> retitle/repurpose.  Unless I'm missing something, the changes
Luca> linked above should be uncontroversial and simply remove
Luca> excessively normative language in what are essentially
Luca> examples that should have been taken as such - and that
Luca> currently are not. So, could that be taken forward
Luca> independently of the problem you define below?

I agree the above is uncontroversial and would support including it in
policy now.
I don't think it needs seconds because it is non-normative.

(As an aside, reading the summary, I expected to find the patch
something I was not entirely happy with.  I was planning to hold my
nose, and neither support the patch nor object.  However, since you
brought it up again, I read the full patch and find I like the patch a
lot better than your summary of it:-)


signature.asc
Description: PGP signature

Bug#1051371: Post-/usr-merge paths for script interpreters

[Bill Allombert]

On Wed, Sep 13, 2023 at 10:47:48AM +0200, Bill Allombert wrote:
> On Tue, Sep 12, 2023 at 08:48:04PM -0700, Russ Allbery wrote:
> > Control: retitle -1 Post-/usr-merge paths for script interpreters
> > 
> > Simon pointed out that this bug is not yet ready to act on, which was very
> > helpful.  Thank you.  However, presumably the buildds will be /usr-merged
> > at some point in the not-too-distant future, and we do need to decide what
> > to do after that point.
> > 
> > I think the root problem behind this bug is that it is revealing we have
> > not made a decision about /bin and /usr/bin path references in Debian
> > after /usr-merge.  Various people, myself included, made assumptions about
> > what the policy would be, but we never actually decided anything that I am
> > aware of and people's assumptions are not matching.  I think we need to
> > talk about this directly, after which what to do with this bug will
> > probably become obvious.
> 
> Russ, there is a quite related point I do not think the TC addressed 
> directly, 
> but I can easily be mistaken: the default PATH.
> It is currently defined in /etc/login.defs (unless my copy of this file is 
> out of date):
> as
> ENV_SUPATH  
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> ENV_PATHPATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
> 
> so in pratice, tools like 'which' will always favor /usr/bin over /bin
> 
> $ which sh
> /usr/bin/sh
> 
> One of the issue in the past is that reproducible build was broken because 
> different
> build environment lead to different paths. We at least need to address that.

To be specific, I needed to add 
SHELL=/bin/sh GREP=/bin/grep SED=/bin/sed DD=/bin/dd
to configure to get reproducible build. (This was in December 2018).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1052004: libcbor: requires source-only upload to transition

[Sebastian Ramacher]

Source: libcbor
Version: 0.10.2-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://qa.debian.org/excuses.php?package=libcbor

Issues preventing migration:

Not built on buildd: arch amd64 binaries uploaded by bernat
Not built on buildd: arch all binaries uploaded by bernat, a new 
source-only upload is needed to allow migration

Cheers
-- 
Sebastian Ramacher

Bug#1051650: cmake: Problems finding libraries on Alpha

[Timo Röhling]

Hi Adrian,

On Mon, 11 Sep 2023 01:20:53 +0300 Adrian Bunk  wrote:

1. The problem is about not finding a library,
it happens in many packages with many libraries.

2. The problem happens only on alpha.

3. There is no such problem with non-cmake build systems.

4. The problem started after the release of bookworm.
It might be a regression in cmake 3.26 or somewhere else (glibc?).

Do you think the bug is reproducible with a small shell script
such as:

set -e
while sleep 5
do
mkdir /tmp/_build
cmake -B /tmp/_build -S /path/to/project/with/required/find_library
rm -rf /tmp/_build
done

If yes, we could try this with a rebuilt CMake 3.25 and see if
this is truly a CMake regression. I looked at the code and could not
spot anything suspicious yet, so this would certainly be
instructive.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid

[Manphiz]

control: tags -1 patch
thanks

Lev Lamberov  writes:

> Пт 15 сен 2023 @ 14:25 David Bremner :
>
>> Lev Lamberov  writes:
>>
 elpa-hl-todo has a versioned depends which is wrong.
>>>
>>> It is not wrong. It is as it is stated in the code, and as it is
>>> detected by dh-elpa.
>>>
>>> Personally, I don't see any problem here. The hl-todo-el package is just
>>> waiting for the latest upstream version of complat-el. There's no hurry
>>> to make its way into testing right now. From my point of view there is
>>> only a wishlist bug requesting the latest upstream version of compat-el
>>> to be uploaded into unstable.
>>
>> Yeah, I see what you mean, but the versioned depends is unsatisfiable in
>> unstable, so it doesn't make sense to upload the package to unstable,
>> unless there is something weird like a circular dependency. 
>>
>> I don't think it's OK for packages in unstable to be uninstallable in
>> unstable. It certainly meets the textbook definition of a release
>> critical bug, since nobody can actually use the package.
>
> Unstable is... well, unstable. Sometimes things break there. ¯\_(ツ)_/¯
> There's no point in removing either compat-el or hl-todo-el from testing
> because of this.
>
> Regards,
> Lev

Prepared a merge request[1] to update compat-el to 29.1.4.2.  Also added
back "+dfsg" to version as we drop compat.texi to be DFSG-compatible.

[1] https://salsa.debian.org/emacsen-team/compat-el/-/merge_requests/1


signature.asc
Description: PGP signature

Bug#1052003: emscripten: FTBFS with binaryen in experimental

[Markus Koschany]

Package: emscripten
Version: 3.1.6~dfsg-5
Severity: important
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

emscripten fails to build from source with the latest version of
binaryen, currently 116, in experimental.

I'm attaching the complete build log. I intend to upload a new version
of binaryen to unstable next year because I know that emscripten has
no real maintainer and is currently maintained by the QA team. I will
ping this bug report again before I do the upload but I hope someone
else can look into this problem before that.

I wonder if emscripten should embed the exact version of binaryen
required to build the package to avoid a circular dependency (because
then I could use emscripten to build wabt.js for example).

These are the last log lines when emscripten fails:

embuilder:INFO: building struct_info
cache:INFO: generating system asset: 
sysroot/lib/wasm32-emscripten/struct_info.json... (this will be cached in 
"/<>/debian/em_cache/sysroot/lib/wasm32-emscripten/struct_info.json"
 for subsequent builds)
emscripten:ERROR: emscript: failure to parse metadata output from 
wasm-emscripten-finalize. raw output is: 

Traceback (most recent call last):
  File "/<>/emcc.py", line 3947, in 
sys.exit(main(sys.argv))
 ^^
  File "/usr/lib/python3.11/contextlib.py", line 81, in inner
return func(*args, **kwds)
   ^^^
  File "/<>/emcc.py", line 3940, in main
ret = run(args)
  ^
  File "/<>/emcc.py", line 1199, in run
phase_post_link(options, state, wasm_target, wasm_target, target)
  File "/usr/lib/python3.11/contextlib.py", line 81, in inner
return func(*args, **kwds)
   ^^^
  File "/<>/emcc.py", line 2753, in phase_post_link
phase_emscript(options, in_wasm, wasm_target, memfile)
  File "/usr/lib/python3.11/contextlib.py", line 81, in inner
return func(*args, **kwds)
   ^^^
  File "/<>/emcc.py", line 2781, in phase_emscript
emscripten.run(in_wasm, wasm_target, final_js, memfile)
  File "/<>/emscripten.py", line 932, in run
emscript(in_wasm, out_wasm, outfile_js, memfile)
  File "/<>/emscripten.py", line 297, in emscript
metadata = finalize_wasm(in_wasm, out_wasm, memfile)
   ^
  File "/<>/emscripten.py", line 521, in finalize_wasm
metadata = get_metadata_binaryen(infile, outfile, modify_wasm, args)
   ^
  File "/usr/lib/python3.11/contextlib.py", line 81, in inner
return func(*args, **kwds)
   ^^^
  File "/<>/emscripten.py", line 406, in get_metadata_binaryen
metadata = load_metadata_json(stdout)
   ^^
  File "/<>/emscripten.py", line 851, in load_metadata_json
metadata_json = json.loads(metadata_raw)

  File "/usr/lib/python3.11/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
   ^^
  File "/usr/lib/python3.11/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
   ^^
  File "/usr/lib/python3.11/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
FAIL: Compilation failed!: ['emcc', '-D_GNU_SOURCE', '-o', 
'/tmp/tmp3mop6qgt.js', '/tmp/tmpelb1y5rp.c', '-O0', '-Werror', '-Wno-format', 
'-nostdlib', 
'/<>/debian/em_cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a',
 '-sMEMORY64=0', '-sBOOTSTRAPPING_STRUCT_INFO=1', '-sLLD_REPORT_UNDEFINED=1', 
'-sSTRICT', '-sSINGLE_FILE', '-Wno-error=version-check', '-Wno-deprecated']
make[1]: *** [debian/rules:195: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:378: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


emscripten_3.1.6~dfsg-5.gz
Description: application/gzip

Bug#1050979: debian-installer-12-netboot-amd64 Drive Order scrambled

[Pascal Hambourg]

On 15/09/2023 at 17:26, Todd Morgan wrote:

AFAIK /dev/sd* discovery and ordering was never guaranteed to be
deterministic nor persistent across boots nor match any hardware or
firmware ordering. One should not rely on these names, hence the use of
persistent identifiers such as UUID, device path or disk ID.


I agree. That is why I used UUID for the fstab entries. But this drive
ordering issue is specific to the installer. The preseed is expecting
a /dev/sd* type of entry in order for partman to partition the correct
drive...or in my case (using software RAID1) drives.


If I understand correctly, the issue is not drive ordering but the 
preseed capability to handle persistent drive identifiers.

Bug#1052001: RFP: govarnam -- Completion engine to type Indic languages

[Guido Günther]

Hi,
On Fri, Sep 15, 2023 at 07:30:31PM +0200, Guido Günther wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: govarnam
>   Version : 1.9.0
> * URL : https://github.com/varnamproject/govarnam
> * License : AGPL-3
>   Programming Lang: Go
>   Description : Completion engine to type Indic languages
> 
> Easily Type Indian Languages on computer and mobile. GoVarnam is a
> cross-platform transliteration library. Manglish -> Malayalam, Thanglish
> -> Tamil, Hinglish -> Hindi plus another 10 languages. GoVarnam is a
> near-Go port of libvarnam
> 
> govarnam builds a shared library that can be used from C (and other 
> languages).
> 
> This would be used by phosh-osk-stub to supply Indic language input on mobile.

The go dependency golang-github-mattn-go-sqlite3-dev is in Debian
already. The build system needs some minor tweaks:

  https://github.com/varnamproject/govarnam/pull/33
  https://github.com/varnamproject/govarnam/pull/32
  https://github.com/varnamproject/govarnam/pull/31

Cheers,
 -- Guido

Bug#1051649: libportal: FTBFS on riscv64 due to test timeout

[Aurelien Jarno]

Hi,

On 2023-09-15 13:31, Simon McVittie wrote:
> Control: tags 1051649 + pending
> 
> On Mon, 11 Sep 2023 at 00:17:31 +0200, Aurelien Jarno wrote:
> > libportal fails to build from source on riscv64 (and a few other slow
> > architectures) with a timeout in a test
> ...
> > After investigation, it appeared the test actually passes, but needs
> > 85 seconds instead of the 60 seconds it got allocated. The
> > following patch uses the --timeout-multiplier feature of meson to
> > increase the timeout.
> 
> Thanks, I'll upload a similar fix after the current version has migrated
> to testing (it's only 1 day off, so it would seem a shame to reset the
> clock for this). I increased the timeout by a factor of 3 rather than 2,
> to give some margin of error.

Thanks!

> However, I'm concerned that this implies riscv64 might be our new slowest
> release architecture, even slower than mips64el, which is going to put
> it at risk of delaying migrations, security fixes and other release
> stuff (as a result of builds taking a long time, arbitrary timeouts in
> build-time tests becoming insufficient, or race conditions in build-time
> tests being hit when they wouldn't have been seen on faster buildds).

It depends how you count. While the build time for a single package
takes longer than some mips64el buildds, we plan to use more buildds. We
currently have 7 buildds, and 2 more are waiting to be installed. This
should ensure that build queues do not fill up, at least once the whole
set of packages has been rebuilt.

> Do you expect faster riscv64 buildds to become available by the time
> trixie is the stable release, or is what we have now what we are going
> to continue to have?

We do have a set of faster buildds available for a few months already,
using the VisionFive 2 boards. They are around 80% faster than the
current HiFive Unmatched based buildds for building packages, and
libportal's testsuite passes on them without changing the timeout
factor.  Unfortunately they lack kernel support in mainline, so they
can't be used and thus are just stored in a box. With the kernel
6.6-rc1, we are down to 19 missing patches to support these boards, we
expect full support will arrive in linux 6.7 or 6.8.

We also hope that the Milk-V Pioneer board (already released) and HiFive
Pro P550 board (planned) will enable us to get way faster riscv64
buildds, but it is still uncertain until they get mainline support, they
get tested in a configuration similar to the buildds and that we are
sure that we can host them in a datacenter.

Regards
Aurelien

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

Bug#1052002: firefox: FTBFS: ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix the problem. Or build with --without-wasm-sandboxed-libraries

[Aurelien Jarno]

Source: firefox
Version: 117.0.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

firefox fails to build from source. From my build log on amd64:

| checking for vpx >= 1.10.0... yes
| checking MOZ_LIBVPX_CFLAGS... 
| checking MOZ_LIBVPX_LIBS... -lvpx -lm
| checking for vpx/vpx_decoder.h... yes
| checking for vpx_codec_dec_init_ver... yes
| checking for nasm... /usr/bin/nasm
| checking nasm version... 2.16.01
| checking for the wasm C compiler... /usr/bin/clang
| checking whether the wasm C compiler can be used... yes
| checking the wasm C compiler version... 16.0.6
| checking the wasm C compiler works... yes
| checking the wasm C compiler can find wasi headers... yes
| checking the wasm C linker can find wasi libraries... yes
| checking for the wasm C++ compiler... /usr/bin/clang++
| checking whether the wasm C++ compiler can be used... yes
| checking the wasm C++ compiler version... 16.0.6
| checking the wasm C++ compiler works... yes
| checking the wasm C++ compiler can find wasi headers... 
| DEBUG: Creating `/tmp/conftest.t4tbmgsv.cpp` with content:
| DEBUG: | #include 
| DEBUG: | int
| DEBUG: | main(void)
| DEBUG: | {
| DEBUG: | 
| DEBUG: |   ;
| DEBUG: |   return 0;
| DEBUG: | }
| DEBUG: Executing: `/usr/bin/clang++ --target=wasm32-wasi 
/tmp/conftest.t4tbmgsv.cpp -c`
| DEBUG: The command returned non-zero exit status 1.
| DEBUG: Its error output was:
| DEBUG: | /tmp/conftest.t4tbmgsv.cpp:1:10: fatal error: 'cstring' file not 
found
| DEBUG: | #include 
| DEBUG: |  ^
| DEBUG: | 1 error generated.
| ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix 
the problem. Or build with --without-wasm-sandboxed-libraries.
| make[1]: *** [debian/rules:228: stamps/configure-browser] Error 1
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:329: build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=firefox=riscv64=117.0.1-1=1694756702=0

Regards
Aurelien

Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid

[Lev Lamberov]

Пт 15 сен 2023 @ 14:25 David Bremner :

> Lev Lamberov  writes:
>
>>> elpa-hl-todo has a versioned depends which is wrong.
>>
>> It is not wrong. It is as it is stated in the code, and as it is
>> detected by dh-elpa.
>>
>> Personally, I don't see any problem here. The hl-todo-el package is just
>> waiting for the latest upstream version of complat-el. There's no hurry
>> to make its way into testing right now. From my point of view there is
>> only a wishlist bug requesting the latest upstream version of compat-el
>> to be uploaded into unstable.
>
> Yeah, I see what you mean, but the versioned depends is unsatisfiable in
> unstable, so it doesn't make sense to upload the package to unstable,
> unless there is something weird like a circular dependency. 
>
> I don't think it's OK for packages in unstable to be uninstallable in
> unstable. It certainly meets the textbook definition of a release
> critical bug, since nobody can actually use the package.

Unstable is... well, unstable. Sometimes things break there. ¯\_(ツ)_/¯
There's no point in removing either compat-el or hl-todo-el from testing
because of this.

Regards,
Lev

Bug#1051998: chromium: please to add support for riscv64

[Andres Salomon]

Hi,

Have these patches been submitted upstream? If so, what's the status? 
If not, why not?


BTW, quickly looking at those patches - when sending it upstream, I 
suspect that the #ifdef around the stddef.h should either be removed 
(stddef.h is available everywhere and if size_t requires it, size_t 
requires it), or that whole #include removed (there's no usage of 
size_t anywhere in the header).



On Fri, Sep 15 2023 at 10:44:44 PM +08:00:00, Bo YU 
 wrote:

Source: chromium
Version: 116.0.5845.180-1
Severity: wishlist
Tags: ftbfs patch moreinfo
User: debian-ri...@lists.debian.org 


Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org 



Dear Maintainer,

Now the chromium can be built[0] on Debian riscv64 with the attached 
patch.

And it seems it works to visit youtube or bilibili on my Unmatched
board with below arguments:

chromium --no-sandbox --use-gl=egl

But the patch can not be accepted by now because:

The patch will conflict with ppc's patch and it can not be maintained 
by

rebasing code on ppc patch. In fact, the patch of riscv64 looks like
small and maintenance easily independent. I would like to follow your
advice that how to deal with the situation.

My initial thought is that applying the ppc/riscv64 patch based on
$(DEB_HOST_ARCH_CPU). Sure, this may require a tricky scripts to do 
so.

I will try my best not to break workflow for all maintainers of
chromium and I will maintain these patch until Chromium upstream 
support

the riscv64 totally.

Once ready, I will remove the moreinfo tag.

Thanks for all the help porting/backport the chromium riscv64 patch 
from

distro like[1]&[2] and developers.

[0]: 

[1]: 

[2]: 



--
Regards,
--
  Bo YU

Bug#1051371: Post-/usr-merge paths for script interpreters

[Luca Boccassi]

On Wed, 13 Sept 2023 at 04:48, Russ Allbery  wrote:
>
> Control: retitle -1 Post-/usr-merge paths for script interpreters
>
> Simon pointed out that this bug is not yet ready to act on, which was very
> helpful.  Thank you.  However, presumably the buildds will be /usr-merged
> at some point in the not-too-distant future, and we do need to decide what
> to do after that point.

While that could be said for the original revision, in my view that's
not really the case for the latest that I posted?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051371#120

So I would prefer if this was a clone rather than a retitle/repurpose.
Unless I'm missing something, the changes linked above should be
uncontroversial and simply remove excessively normative language in
what are essentially examples that should have been taken as such -
and that currently are not. So, could that be taken forward
independently of the problem you define below?

> I think the root problem behind this bug is that it is revealing we have
> not made a decision about /bin and /usr/bin path references in Debian
> after /usr-merge.  Various people, myself included, made assumptions about
> what the policy would be, but we never actually decided anything that I am
> aware of and people's assumptions are not matching.  I think we need to
> talk about this directly, after which what to do with this bug will
> probably become obvious.
>
> So far as I can tell, there are three main possibilities:
>
> (a) Although /bin and /usr/bin are merged (and likewise for the other
> merged paths), Debian will continue to require (or at least recommend)
> use of /bin paths for things such as /bin/sh that historically used
> those paths.
>
> (b) Since /bin and /usr/bin (and likewise for the other paths) are merged,
> /bin/sh and /usr/bin/sh are equivalent.  Packages can use whichever
> path they want, and Debian will end up with a mix of both references.
>
> (c) Although /bin and /lib technically work due to the aliasing, they are
> deprecated and everything in Debian should stop using those paths.
> All paths should point to /usr/bin and /usr/lib now.
>
> Although Luca made a few arguments in the direction of (c), my
> understanding of his current patch is that it essentially implements (b)
> for script interpreters, although without encoding into Policy an explicit
> decision between these three options (quite understandably because he was
> trying to deal with a narrower issue).  Several other people were, I
> think, arguing for (a), but I'm not sure if they would continue to do so
> when it's put in these terms.
>
> Policy currently says nothing significant about this (hence most of the
> text so-far discussed being informative) because, up until now, (a) was
> the de facto policy.  If you didn't follow (a), you would get not-found
> errors and your package would have an RC bug because it wouldn't work.
>
> If we do nothing, we'll get (b).  I think that's reasonably obvious, since
> there is no technical factor forcing either (a) or (c).  Both paths will
> work without any noticable difference, so some people will use /bin and
> some people will use /usr/bin.
>
> That said, I would rather make an explicit choice rather than decide by
> default, since otherwise this seems like the kind of thing where people
> are going to get conflicting advice, which is frustrating for everyone.
>
> If someone wants to argue for (a) or (c), I think the biggest problem with
> either of them is an enforcement mechanism.  How are we going to check
> whether packages are following the rules?  Lintian and a bunch of grep
> patterns is sort of an unsatisfying 90% solution, and people will ignore
> it or just not use Lintian.  There is also no technical reason why both
> paths will not work, so people are going to get grumpy about being told
> what to do and some people will view this as makework.  I think any
> proposal to pick (a) or (c) needs to wrestle with that.
>
> I will also say that it will be very hard to convince me that Debian
> should give Policy advice like (a) or (c) but not actually enforce it
> anywhere.  We have a long history to look at for how those sorts of
> mandates go.  Conscientious packagers who read Policy carefully follow the
> rules and go to extra effort to do so, but other people will never see
> that advice or not pay attention to it.  That means that the effort is
> mostly wasted, because no one can rely on the invariant that either (a) or
> (c) is attempting to achieve.  I am not a big fan of asking people to do
> extra work without some clear benefit from doing that work, which mostly
> requires uniformity.
>
> One last point about this decision: although there are a few style
> recommendations in it, Policy is not a style guide.  The point of Policy
> is to describe the things we should or must do, or at least that the
> project as a whole wants to encourage, that have a concrete effect on the
> quality of the 

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

[Luca Boccassi]

On Wed, 13 Sept 2023 at 15:37, Sam Hartman  wrote:
>
> > "Russ" == Russ Allbery  writes:
>
> I don't know if this needs seconds, but I reviewed all the text and it
> looks good.
> If seconds are required, I second.

Same, in case ownership passes to Russ, seconded/approved/you have my
sword/etc etc

Bug#1029064: Lintian Bug

[Markus Koschany]

Control: forwarded -1 https://github.com/WebAssembly/binaryen/issues/5947




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

Bug#1052001: RFP: govarnam -- Completion engine to type Indic languages

[Guido Günther]

Package: wnpp
Severity: wishlist

* Package name: govarnam
  Version : 1.9.0
* URL : https://github.com/varnamproject/govarnam
* License : AGPL-3
  Programming Lang: Go
  Description : Completion engine to type Indic languages

Easily Type Indian Languages on computer and mobile. GoVarnam is a
cross-platform transliteration library. Manglish -> Malayalam, Thanglish
-> Tamil, Hinglish -> Hindi plus another 10 languages. GoVarnam is a
near-Go port of libvarnam

govarnam builds a shared library that can be used from C (and other languages).

This would be used by phosh-osk-stub to supply Indic language input on mobile.

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

[Todd J]

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

Dear Maintainer,

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

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

should allow "logrotate hourly" to work as expected.

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

Thanks!

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


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

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

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

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

logrotate suggests no packages.

-- no debconf information

Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid

[David Bremner]

Lev Lamberov  writes:

>> elpa-hl-todo has a versioned depends which is wrong.
>
> It is not wrong. It is as it is stated in the code, and as it is
> detected by dh-elpa.
>
> Personally, I don't see any problem here. The hl-todo-el package is just
> waiting for the latest upstream version of complat-el. There's no hurry
> to make its way into testing right now. From my point of view there is
> only a wishlist bug requesting the latest upstream version of compat-el
> to be uploaded into unstable.

Yeah, I see what you mean, but the versioned depends is unsatisfiable in
unstable, so it doesn't make sense to upload the package to unstable,
unless there is something weird like a circular dependency. 

I don't think it's OK for packages in unstable to be uninstallable in
unstable. It certainly meets the textbook definition of a release
critical bug, since nobody can actually use the package.

What I don't really understand why this bug was not filed on elpa-hl-todo .

Bug#1015358: binaryen: ftbfs with LTO (link time optimization) enabled

[Markus Koschany]

Control: forwarded -1 https://github.com/WebAssembly/binaryen/issues/5946


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

Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid

[Lev Lamberov]

Hi,

Пт 15 сен 2023 @ 11:24 David Bremner :

> Control: severity -1 important
>
> David Bremner  writes:
>
>> Andreas Beckmann  writes:
>>
>>> Package: compat-el
>>> Version: 29.1.4.1-2
>>> Severity: serious
>>>
>>> elpa-hl-todo/sid is currently uninstallable since it depends on
>>> elpa-compat (>= 29.1.4.2).
>>>
>>>
>>> Andreas
>>
>> Maybe it doesn't matter, but I don't think this is a serious bug in
>> compat.el. It's not like a it's a regression. It's a serious bug in the
>> package which is uninstallable.
>
> Addendum: it does matter, there are a bunch of rdepends and unless they
> all don't work with current elpa-compat, then it is needlessly
> disruptive to auto-remove elpa-compat (or even to mark it for
> auto-removal).
>
> elpa-hl-todo has a versioned depends which is wrong.

It is not wrong. It is as it is stated in the code, and as it is
detected by dh-elpa.

Personally, I don't see any problem here. The hl-todo-el package is just
waiting for the latest upstream version of complat-el. There's no hurry
to make its way into testing right now. From my point of view there is
only a wishlist bug requesting the latest upstream version of compat-el
to be uploaded into unstable.

Regards,
Lev

Bug#1049332: alg: self-tests for stdrng using drbg_nopr_hmac_sha512 failed (rc=-22)

[in . cognito35]

Since reporting this issue I never got that error again in the journal.

Feel free to close as "not reproducible".

Bug#1039873: fixed in pam 1.5.2-7

[Guido Berhoerster]

On 15.09.23 17:55, Sam Hartman wrote:

"Guido" == Guido Berhoerster  writes:


 Guido> Are there plans to get this into stable-updates?

No, not currently.
But if you would agree to test in testing/unstable now, and test again
once it gets into stable-proposed, I'd be happy to raise the severity to
important so that it is eligible for bookworm and prepare an update.


Sounds good, I'll test on unstable and provide feedback here.

--
Guido Berhoerster

Bug#1051901: libasound2: 1.2.10 breaks ability to play audio using i386 binaries on amd64 host

[Antoine Le Gonidec]

tags -1 upstream
thanks

Similar symptoms have been reported by Arch Linux users: 
https://bugs.archlinux.org/task/79628
So this bug is most probably not specific to the Debian packaging.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051999: transition: libfm

[Sebastian Ramacher]

Control: tags -1 confirm

On 2023-09-15 23:53:27 +0800, ChangZhuo Chen wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: li...@packages.debian.org, team+l...@tracker.debian.org
> Control: affects -1 + src:libfm
> 
> We want to transition libfm from gtk2 to gtk3. All affected packages are
> ready in experimental.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Harlan Lieberman-Berg]

On Tue, 12 Sep 2023 10:52:16 -0400 Paul Tagliamonte  wrote:
> I upgraded my sid system, and post-upgrade gdm3 isn't showing my face
> when I reboot, and entering my username causes it to loop back to
> username entry again (no password prompt).

Hello all,

I've gotten bitten by this one too, I'm afraid, this time in Debian testing.

Potentially interestingly, though I do have a PKCS#11 token inserted,
it has no certificates on it.  That's still enough to trigger the bug,
however, even though there is no certificate for it to even attempt to
auth against.

For example:

```
❯ pkcs11-tool -L
Available slots:
Slot 0 (0x0): Yubico YubiKey OTP+FIDO+CCID 00 00
  token label: PIV_II
  token manufacturer : piv_II
  token model: PKCS#15 emulated
  token flags: login required, rng, token initialized, PIN
initialized, user PIN locked
  hardware version   : 0.0
  firmware version   : 0.0
  serial num : 
  pin min/max: 4/8
```

However...

```
❯ pkcs11-tool --list-objects --type cert
Using slot 0 with a present token (0x0)
```

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1039873: fixed in pam 1.5.2-7

[Sam Hartman]

> "Guido" == Guido Berhoerster  writes:

Guido> Are there plans to get this into stable-updates?

No, not currently.
But if you would agree to test in testing/unstable now, and test again
once it gets into stable-proposed, I'd be happy to raise the severity to
important so that it is eligible for bookworm and prepare an update.

--Sam

Bug#1051999: transition: libfm

[陳昌倬]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: li...@packages.debian.org, team+l...@tracker.debian.org
Control: affects -1 + src:libfm

We want to transition libfm from gtk2 to gtk3. All affected packages are
ready in experimental.

https://release.debian.org/transitions/html/auto-libfm.html

Ben file:

title = "libfm";
is_affected = .depends ~ "libfm-gtk4" | .depends ~ "libfm-gtk3-4";
is_good = .depends ~ "libfm-gtk3-4";
is_bad = .depends ~ "libfm-gtk4";

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
https://czchen.org/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1051945: README.Debian documentation regarding MAIN_TLS_ENABLE is wrong

[Andreas Metzler]

On 2023-09-14 Marc Haber  wrote:
> Package: exim4-base
> Version: 4.96-22
> Severity: normal

> Hi,

> in README.Debian we are documenting that MAIN_TLS_ENABLE is needed to
> make exim advertise STARTTLS. This is implemented in the configuration
> by bracketing the TLS configuration in an .ifdef MAIN_TLS_ENABLE
> construct, leaving the upstream defaults in the .else case.
[...]

Hello,

the docs should already reflect the current behavior.

README already says that exim supports incoming opportunistic TLS by using
on-connect autogenerated self-signed certificates unless MAIN_TLS_ENABLE
set.

However later on the sentence "After this configuration, Exim will …" is
misleading - I will drop the "After this configuration" at the start
of the sentence.

cu Andreas

Bug#1050979: debian-installer-12-netboot-amd64 Drive Order scrambled

[Todd Morgan]

> AFAIK /dev/sd* discovery and ordering was never guaranteed to be
> deterministic nor persistent across boots nor match any hardware or
> firmware ordering. One should not rely on these names, hence the use of
> persistent identifiers such as UUID, device path or disk ID.

I agree. That is why I used UUID for the fstab entries. But this drive
ordering issue is specific to the installer. The preseed is expecting
a /dev/sd* type of entry in order for partman to partition the correct
drive...or in my case (using software RAID1) drives.

> I advise to not hardcode /dev/sd* anywhere and use persistent
> identifiers instead.

As stated above, I am not using /dev/sd* anywhere other than in the
preseed which requires it.

Bug#1039731: [pkg-php-pear] Bug#1039731: php-laravel-lumen-framework: FTBFS with symfony 6: unsatisfiable build-dependencies

[Robin Gustafsson]

Hi,

On Fri, Sep 15, 2023 at 12:54 PM David Prévot  wrote:
> Hi Robin,
>
> Le Wed, Jun 28, 2023 at 03:41:28PM -0300, Athos Ribeiro a écrit :
> > Source: php-laravel-lumen-framework
> […]
> > We are about to start the symfony 6 transition in unstable.
>
> As for php-laravel-lumen-framework, php-laravel-framework is not yet
> ready for the symfony 6 transition, documenting the issue in this bug
> report. As for the symfony 5 transition during the last cycle, I assume
> we should not block it by Laravel, and be ready to see
> php-laravel-lumen-framework and php-laravel-lumen-framework removed from
> testing if they are not yet ready (there is more than a year in the
> release cycle to get them ready).

Indeed. Sounds good to me. Don't let it block you.

Regards,
Robin

Bug#1051879: RFS: ncdu/1.19-0.1 [NMU] -- ncurses disk usage viewer

[Wookey]

On 2023-09-13 22:35 +0200, Christian Göttsche wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ncdu":

I have to go to a conference right now, but if no-one has sorted this by Tue
next week I can do it for you (I use and enjoy this package).

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1043124: FYI Same error with zfs-2.1.12-2 and kernel 6.5.0-1-amd64

[Michal Wojcik]

checking whether bops->release() is void... configure: error:
*** None of the expected "bops->release()" interfaces were detected.
*** This may be because your kernel version is newer than what is
*** supported, or you are using a patched custom kernel with
*** incompatible modifications.
***
*** ZFS Version: zfs-2.1.12-2
*** Compatible Kernels: 3.10 - 6.3


Building module:
Cleaning build area...(bad exit status: 2)
make -j12 KERNELRELEASE=6.5.0-1-amd64...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.5.0-1-amd64 (x86_64)
Consult /var/lib/dkms/zfs/2.1.12/build/make.log for more information.
dkms autoinstall on 6.5.0-1-amd64/x86_64 failed for zfs(10)

Bug#1051563: Backporting mutt patches to Debian Buster

[Chris Frey]

Attached is a patch that applies to the unpackaged sources of Debian Buster's
version of mutt 1.10.

It includes 3 patches:

upstream/Fix-rfc2047-base64-decoding-to-abort-on-illegal-char.patch
debian-specific/Check-for-NULL-userhdrs.patch
debian-specific/Fix-write_one_header-illegal-header-check.patch

First one applied from Bullseye.  The other two I modified slightly
to match the older sources.

The CVE's make mention of "specially crafted input" but I don't have
any samples to test with.  I only tested that this built on Buster and
opens mail as before.

I have not adjusted any other files but the 3 above and debian/patches/series.
Hopefully this gives a head start on making these fixes available on buster.

- Chris

diff --git a/debian/patches/debian-specific/Check-for-NULL-userhdrs.patch b/debian/patches/debian-specific/Check-for-NULL-userhdrs.patch
new file mode 100644
index 000..33f5cb5
--- /dev/null
+++ b/debian/patches/debian-specific/Check-for-NULL-userhdrs.patch
@@ -0,0 +1,56 @@
+From: Chris Frey 
+Date: Fri, 15 Sep 2023 08:41:00 -0400
+Subject: Check for NULL userhdrs.
+Bug-Debian: https://bugs.debian.org/1051563
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-4875
+
+The original patch from Kevin McCarthy backported to Debian buster's
+mutt version 1.10.1-2.1+deb10u6.
+
+Original summary below:
+
+ From: Kevin McCarthy 
+ Date: Mon, 4 Sep 2023 12:50:07 +0800
+ Subject: Check for NULL userhdrs.
+ Origin: https://gitlab.com/muttmua/mutt/-/commit/4cc3128abdf52c615911589394a03271fddeefc6
+
+ When composing an email, miscellaneous extra headers are stored in a
+ userhdrs list.  Mutt first checks to ensure each header contains at
+ least a colon character, passes the entire userhdr field (name, colon,
+ and body) to the rfc2047 decoder, and safe_strdup()'s the result on
+ the userhdrs list.  An empty result would from the decode would result
+ in a NULL headers being added to list.
+
+ The previous commit removed the possibility of the decoded header
+ field being empty, but it's prudent to add a check to the strchr
+ calls, in case there is another unexpected bug resulting in one.
+
+ Thanks to Chenyuan Mi (@morningbread) for discovering the two strchr
+ crashes, giving a working example draft message, and providing the
+ stack traces for the two NULL derefences.
+ ---
+  sendlib.c | 4 ++--
+  1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/sendlib.c b/sendlib.c
+index f9bf3f9..d75e66a 100644
+--- a/sendlib.c
 b/sendlib.c
+@@ -2070,7 +2070,7 @@ int mutt_write_rfc822_header (FILE *fp, ENVELOPE *env, BODY *attach,
+   /* Add any user defined headers */
+   for (; tmp; tmp = tmp->next)
+   {
+-if ((p = strchr (tmp->data, ':')))
++if ((p = strchr (NONULL (tmp->data), ':')))
+ {
+   q = p;
+ 
+@@ -2116,7 +2116,7 @@ static void encode_headers (LIST *h)
+ 
+   for (; h; h = h->next)
+   {
+-if (!(p = strchr (h->data, ':')))
++if (!(p = strchr (NONULL (h->data), ':')))
+   continue;
+ 
+ i = p - h->data;
diff --git a/debian/patches/debian-specific/Fix-write_one_header-illegal-header-check.patch b/debian/patches/debian-specific/Fix-write_one_header-illegal-header-check.patch
new file mode 100644
index 000..8806525
--- /dev/null
+++ b/debian/patches/debian-specific/Fix-write_one_header-illegal-header-check.patch
@@ -0,0 +1,46 @@
+From: Chris Frey 
+Date: Fri, 15 Sep 2023 10:09:00 -0400
+Subject: Fix write_one_header() illegal header check.
+Bug-Debian: https://bugs.debian.org/1051563
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-4874
+
+Backporting original patch from Kevin McCarthy to Debian Buster's
+mutt version 1.10.1-2.1+deb10u6.
+
+Original commentary included below:
+
+ From: Kevin McCarthy 
+ Date: Sun, 3 Sep 2023 14:11:48 +0800
+ Subject: Fix write_one_header() illegal header check.
+ Origin: https://gitlab.com/muttmua/mutt/-/commit/a4752eb0ae0a521eec02e59e51ae5daedf74fda0
+
+ This is another crash caused by the rfc2047 decoding bug fixed in the
+ second prior commit.
+
+ In this case, an empty header line followed by a header line starting
+ with ":", would result in t==end.
+
+ The mutt_substrdup() further below would go very badly at that point,
+ with t >= end+1.  This could result in either a memcpy onto NULL or a
+ huge malloc call.
+
+ Thanks to Chenyuan Mi (@morningbread) for giving a working example
+ draft message of the rfc2047 decoding flaw.  This allowed me, with
+ further testing, to discover this additional crash bug.
+ ---
+  sendlib.c | 2 +-
+  1 file changed, 1 insertion(+), 1 deletion(-)
+ 
+diff --git a/sendlib.c b/sendlib.c
+index f9bf3f9..d821061 100644
+--- a/sendlib.c
 b/sendlib.c
+@@ -1832,7 +1832,7 @@ static int write_one_header (FILE *fp, int pfxw, int max, int wraplen,
+   else
+   {
+ t = strchr (start, ':');
+-if (!t || t > end)
++if (!t || t >= end)
+ {
+   dprint (1, (debugfile, "mwoh: warning: header not 

Bug#1051998: chromium: please to add support for riscv64

[Bo YU]

Source: chromium
Version: 116.0.5845.180-1
Severity: wishlist
Tags: ftbfs patch moreinfo
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

Now the chromium can be built[0] on Debian riscv64 with the attached patch.
And it seems it works to visit youtube or bilibili on my Unmatched
board with below arguments:

chromium --no-sandbox --use-gl=egl

But the patch can not be accepted by now because:

The patch will conflict with ppc's patch and it can not be maintained by
rebasing code on ppc patch. In fact, the patch of riscv64 looks like
small and maintenance easily independent. I would like to follow your
advice that how to deal with the situation.

My initial thought is that applying the ppc/riscv64 patch based on 
$(DEB_HOST_ARCH_CPU). Sure, this may require a tricky scripts to do so.
I will try my best not to break workflow for all maintainers of
chromium and I will maintain these patch until Chromium upstream support
the riscv64 totally.

Once ready, I will remove the moreinfo tag.

Thanks for all the help porting/backport the chromium riscv64 patch from
distro like[1]&[2] and developers.

[0]: 
https://drive.google.com/drive/folders/1n-XakYgPZiuI5hGQa0CGit-8e-74zfMa?usp=drive_link
[1]: https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/chromium
[2]: https://github.com/felixonmars/archriscv-packages/tree/master/chromium

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1051973: tzdata: no warning about moving US/* to tzdata-legacy

[Mike Kupfer]

Mike Kupfer wrote:

> I'm okay with the change itself, but it really should get more
> visibility.  That is, on upgrade the user should get some sort of
> heads-up that they are getting an incompatible change and may need to
> take corrective action.

To clarify, what I have in mind is a news entry, which apt-listchanges
would display.  (I'm not really familiar with Debian packaging, so I
couldn't describe the mechanism when I filed the bug last night.  I
guess what I'm requesting is a NEWS.Debian entry.)

thanks,
mike

Bug#1051968: libreoffice: Libreoffice on MATE doesn't install libreoffice-gnome

[Charles Boling]

You mean you have chosen "MATE Desktop Environment" in the installer in 
the "task selection" (a.k.a tasksel)?


Yes; thank you for prompting me to clarify that.


The "libreoffice" package suggests libreoffice-gnome | 
libreoffice-plasma but indeed  the MATE task just does

...

Depends: tasksel (= 3.73), task-desktop, mate-desktop-environment, lightdm
Recommends: gimp, synaptic, libreoffice-writer, libreoffice-calc, 
libreoffice-impress, libreoffice-help-en-us, mythes-en-us, 
hunspell-en-us, hyphen-en-us, network-manager-gnome, orca, libreoffice-gtk3

...
But that (understandably, leaving out Base etc) bypasses the 
"libreoffice" metapackage (except that that suggests is not shown when 
being installed by the installer anyway...)


Ah, that explains it!  Thanks for finding that, Rene. I was looking at 
pkgs and didn't even think to go up a level to tasksel.


--
Charles Boling

PGP Public Key: http://www.boling.us/pgp/charles.html

Bug#1051997: PHP errors on overview page

[Guido Berhoerster]

Package: gosa
Version: 2.8~git20230203.10abe45+dfsg-9

Even with a build from the latest master I get the
following errors on the overview page right after logging in.

Sep 15 16:27:35 tjener.intern apache2[241429]: GOsa[server-admin]: (view) error 
: PHP error: Array to string conversion (/usr/share/gosa/include/class_acl.inc, 
line 180)
Sep 15 16:27:35 tjener.intern apache2[241429]: GOsa[server-admin]: (view) error 
: PHP error: Undefined property: acl::$Array 
(/usr/share/gosa/include/class_acl.inc, line 180)

-- 
Guido Berhoerster

Bug#1031047: keepass2: new upstream releases (2.53)

[Libor Klepac]

Hi,
i have downloaded upstream binary and replaced files from this package on disk.
There is bug in packaged  2.47 version: when i have two files opened at once, 
app freezes when switching between tabs/files.
It does not happen with 2.53 

Libor

Bug#1051996: xdg-desktop-portal: Rethink xdg-desktop-portal-backend virtual package now that we have 1.17.x

[Simon McVittie]

Package: xdg-desktop-portal
Version: 1.17.2-1
Severity: wishlist
X-Debbugs-Cc: jeremy.bi...@canonical.com, debian-desk...@lists.debian.org

See https://lists.debian.org/debian-devel/2023/08/msg00311.html for more
context about what x-d-p is, what it's for, and how it is now set up.

At the moment we have this dependency structure:

- Each desktop-specific x-d-p backend Provides x-d-p-backend
  (some are versioned Provides, but it's not clear that it makes much sense
  to do so, because what the versioning means isn't really defined)
- Backends (x-d-p-gtk, -gnome, -kde, etc.) have Depends on a suitable
  version of x-d-p
- x-d-p intentionally does not have a Depends or Recommends on a backend,
  because if it did, that would be a circular dependency (#915117)
- Packages that need working portals (Flatpak, Snap, WebKit, Steam, etc.)
  have Depends or Recommends on x-d-p and x-d-p-gtk | x-d-p-backend
- Well-integrated desktop environments have Depends or Recommends on their
  own preferred portal backends, optionally with x-d-p-backend as secondary,
  e.g. gnome-session Depends: x-d-p-gnome | x-d-p-backend
- Non-integrated or assemble-it-yourself desktop environments have no
  particular dependencies

Now that xdg-desktop-portal 1.17.x has portals.conf(5), we should probably
re-think this.

It's not clear to me whether x-d-p-backend necessarily makes sense as a
virtual package in its current form. Historically, we had a small number
of implementations (basically -gtk and -kde) each of which implemented
"most" of the possible interfaces listed in
https://docs.flatpak.org/en/latest/portal-api-reference.html.

We're starting to see a lot more backend implementations. This is good:
it makes it more likely that the user will get working portals in their
desktop environment. However, increasingly many of the backends only
implement a few interfaces: for example x-d-p-lxqt only implements
FileChooser, and x-d-p-xapp only implements a small number of interfaces
like Lockdown, Screenshot and Wallpaper (but notably, *not* FileChooser).
They both have Provides on x-d-p-backend, but neither is enough on its own
to provide enough portals to make Flatpak apps work as intended.

Perhaps we should do something like this instead?

- Well-integrated desktop environments have a $DESKTOP-portals.conf and a
  Depends/Recommends on the backends that it asks for; if they do, then
  they may also add Provides on x-d-p-config
- New real or virtual package x-d-p-fallback that arranges for a fallback
  portal backend (in practice it will be -gtk) to be used for
  non-integrated or assemble-it-yourself desktop environments
- Packages that need working portals (Flatpak, etc.) should have
  Depends/Recommends on x-d-p and x-d-p-fallback | x-d-p-config
- The x-d-p-backend virtual package eventually disappears as not
  practically useful any more

The result would be that if there is at least one fully-integrated desktop
environment installed, then the user gets its preferred portal backends,
whatever they are; or if there are no fully-integrated desktop environments
(only i3 or fvwm or whatever), then they get a fallback to x-d-p-gtk.

Thoughts?

smcv

Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid

[David Bremner]

Control: severity -1 important

David Bremner  writes:

> Andreas Beckmann  writes:
>
>> Package: compat-el
>> Version: 29.1.4.1-2
>> Severity: serious
>>
>> elpa-hl-todo/sid is currently uninstallable since it depends on
>> elpa-compat (>= 29.1.4.2).
>>
>>
>> Andreas
>
> Maybe it doesn't matter, but I don't think this is a serious bug in
> compat.el. It's not like a it's a regression. It's a serious bug in the
> package which is uninstallable.

Addendum: it does matter, there are a bunch of rdepends and unless they
all don't work with current elpa-compat, then it is needlessly
disruptive to auto-remove elpa-compat (or even to mark it for
auto-removal).

elpa-hl-todo has a versioned depends which is wrong.

Bug#1051995: PHP errors when adding a user

[Guido Berhoerster]

Package: gosa
Version: 2.8~git20230203.10abe45+dfsg-9

Even with a build from the latest master I get the
following PHP errors when adding a new user:

Sep 14 15:53:01 tjener.intern apache2[1645]: GOsa[server-admin]: (view) error : 
PHP error: ldap_read(): Search: Invalid DN syntax 
(/usr/share/gosa/plugins/personal/generic/class_user.inc, line 1456)
Sep 14 15:53:01 tjener.intern slapd[1272]: conn=1497 op=1 do_search: invalid 
dn: "new"
Sep 14 15:53:01 tjener.intern apache2[1645]: GOsa[server-admin]: (view) error : 
PHP error: ldap_read(): Search: Invalid DN syntax 
(/usr/share/gosa/include/class_ldap.inc, line 921)
Sep 14 15:53:27 tjener.intern apache2[1659]: GOsa[server-admin]: (view) error : 
PHP error: A non-numeric value encountered 
(/usr/share/gosa/plugins/personal/posix/class_posixAccount.inc, line 1196)
Sep 14 15:53:27 tjener.intern apache2[1659]: GOsa[server-admin]: (view) error : 
PHP error: Undefined array key "new" 
(/usr/share/gosa/include/class_pathNavigator.inc, line 36)
Sep 14 15:53:27 tjener.intern apache2[1659]: GOsa[server-admin]: (view) error : 
PHP error: Trying to access array offset on value of type null 
(/usr/share/gosa/include/class_pathNavigator.inc, line 36)
Sep 14 15:53:27 tjener.intern apache2[1659]: GOsa[server-admin]: (view) new of 
type users/user
Sep 14 15:54:23 tjener.intern apache2[4027]: GOsa[server-admin]: (view) error : 
PHP error: Undefined array key "new" 
(/usr/share/gosa/include/class_pathNavigator.inc, line 36)
Sep 14 15:54:23 tjener.intern apache2[4027]: GOsa[server-admin]: (view) error : 
PHP error: Trying to access array offset on value of type null 
(/usr/share/gosa/include/class_pathNavigator.inc, line 36)
Sep 14 15:54:23 tjener.intern apache2[4027]: GOsa[server-admin]: (view) new of 
type users/posixAccount


-- 
Guido Berhoerster

Bug#1041742: RFS: keepassxc-proxy-client/0.1.7-1 [ITP] -- Library to access a running KeepassXC instance

[Antonio Russo]

Dear mentors,

I am looking for a sponsor for my package "keepassxc-proxy-client":

  * Package name : keepassxc-proxy-client
Version  : 0.1.7-1
Upstream contact : Henrik Böving 
  * URL  : https://github.com/hargoniX/keepassxc-proxy-client
  * License  : ISC
  * Vcs  : 
https://salsa.debian.org/aerusso-guest/keepassxc-proxy-client
Section  : python
Description  : Library to access a running KeepassXC instance

KeepassXC is a password manager which exposes a interface to allow 
access-conntroled retrieval of
passwords from its secure storage. keepassxc-proxy-client is a Python library 
that can speak this
protocol, allowing programmatic access to passwords in the database.  This 
packages also includes
a simple CLI client build using the library.

I am re-posting this RFS for this very small library in the hopes that I can 
get some feedback
on the packaging.

The source builds the following binary packages:

   keepassxc-proxy-client - Library to access a running KeepassXC instance

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

   https://mentors.debian.net/package/keepassxc-proxy-client/

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

   dget -x 
https://mentors.debian.net/debian/pool/main/k/keepassxc-proxy-client/keepassxc-proxy-client_0.1.6-1.dsc

Changes for the initial release:

 keepassxc-proxy-client (0.1.7-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1041718)


Best,
Antonio Russo

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051994: RFS: inkscape-textext/1.9.0-1 -- Re-editable LaTeX graphics for Inkscape

[Antonio Russo]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: aeru...@aerusso.net

Dear mentors,

I am looking for a sponsor for my package "inkscape-textext"

 * Package name: inkscape-textext
   Version : 1.9.0-1
   Upstream Author : Jan Winkler 
 * URL : https://textext.github.io/textext
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/aerusso-guest/textext
   Section : graphics
   Description : Re-editable LaTeX graphics for Inkscape

TexText is a Python plugin for the vector graphics editor Inkscape
providing the possibility to add and re-edit LaTeX generated SVG
elements to your drawing.

 Key features
 . Windows/Linux/MacOS support
 . LaTeX generated SVG elements can be re-edited later
 . Multi-line editor with syntax highlighting
 . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex
 . Interoperable scaling in TexText and Inkscape
 . Font size match with Inkscape text
 . Customizable TeX preamble (additional packages, parskip, parindent, etc.)
 . Colorization via TeX commands/Inkscape is kept after re-editing
 . Alignment anchor of the produced output
 . Preview images

It builds the binary packages:

  inkscape-textext - Re-editable LaTeX graphics for Inkscape
  inkscape-textext-doc - Re-editable LaTeX graphics for Inkscape (documentation)

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

  https://mentors.debian.net/package/inkscape-textext/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/inkscape-textext/inkscape-textext_1.9.0-1.dsc

Changes since the last upload:

 inkscape-textext (1.9.0-1) experimental; urgency=medium
 .
   * New upstream release
   * Refresh patches
   * Update debian/copyright
   * Bump standards version (no changes required)
   * Drop support for inkscape <1.3, matching upstream
   * Simplify build scripts
   * Validate upstream signatures
   * Relax architecture dependencies

This upload is primarily to track upstream releases.  Most notably, upstream 
has dropped support for
inkscape <1.3, and I am tracking that change here.

Best,
Antonio Russo


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1039873: fixed in pam 1.5.2-7

[Guido Berhoerster]

Are there plans to get this into stable-updates?

This is needed in debian-edu-config in bookworm, we get libpam-ldapd as a 
dependency via nslcd and need to programmatically disable pam_ldap as we use
Kerberos (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051841#20).

-- 
Guido Berhoerster

Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.

[Felix Zielcke]

Am Samstag, dem 09.09.2023 um 15:41 +0200 schrieb Sebastian Andrzej
Siewior:
> Package: grub2
> Version: 2.12~rc1-9
> Severity: Serious
> control: forwarded -1 https://savannah.gnu.org/bugs/?64376
> 
> I have a single XFS partition which contains the root filesystem and
> the
> boot partition. Since the recent upgrade to the 2.12 series I can't
> boot
> anymore because grub complains that it can't find normal.mod and
> remains in
> the rescue shell.
> The ls command kind of works. A ls in /boot/grub/i386-pc/ (where the
> normal.mod should be) shows a few files and then abort with the error
> message: 'error: invalid XFS directory entry'.
> 

Hi Sebastian,

there's now a patch from Jon DeVree upstream, which might fix this for
you. Is it possible for you to test his patch?

https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html

Bug#1051993: gdm3: System suspends after 15(!) minutes at login screen

[Michel Dänzer]

Package: gdm3
Version: 45~beta-1
Severity: normal

Dear Maintainer,


After upgrading to 45~beta-1, the system suspends after 15 minutes at
the login screen. This did not happen with older versions up to and
including 44.1-2. This is a desktop machine which is always connected to
AC.

Setting both sleep-inactive-ac-timeout & sleep-inactive-battery-timeout
(which default to 20 minutes though, not 15) to 0, and both
sleep-inactive-ac-type & sleep-inactive-battery-type to 'nothing' in
/etc/gdm3/greeter.dconf-defaults doesn't help.


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

Kernel: Linux 6.5.3+ (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.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 gdm3 depends on:
ii  accountsservice   23.13.9-4
ii  adduser   3.137
ii  alacritty [x-terminal-emulator]   0.12.2-2
ii  dbus [default-dbus-system-bus]1.14.10-1
ii  dbus-bin  1.14.10-1
ii  dbus-daemon   1.14.10-1
ii  dconf-cli 0.40.0-4
ii  dconf-gsettings-backend   0.40.0-4
ii  debconf [debconf-2.0] 1.5.82
ii  gir1.2-gdm-1.045~beta-1
ii  gnome-console [x-terminal-emulator]   45~beta-2
ii  gnome-session [x-session-manager] 44.0-4
ii  gnome-session-bin 44.0-4
ii  gnome-session-common  44.0-4
ii  gnome-settings-daemon 45~rc-1
ii  gnome-shell   44.4-1
ii  gsettings-desktop-schemas 45~rc-1
ii  kitty [x-terminal-emulator]   0.26.5-5
ii  kwin-x11 [x-window-manager]   4:5.27.8-1
ii  libaccountsservice0   23.13.9-4
ii  libaudit1 1:3.1.1-1
ii  libc6 2.37-9
ii  libcanberra-gtk3-00.30-10
ii  libcanberra0  0.30-10
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libgdm1   45~beta-1
ii  libglib2.0-0  2.78.0-1
ii  libglib2.0-bin2.78.0-1
ii  libgtk-3-03.24.38-5
ii  libgudev-1.0-0238-2
ii  libkeyutils1  1.6.3-2
ii  libpam-modules1.5.2-7
ii  libpam-runtime1.5.2-7
ii  libpam-systemd [logind]   254.1-3
ii  libpam0g  1.5.2-7
ii  librsvg2-common   2.54.7+dfsg-2
ii  libselinux1   3.5-1
ii  libsystemd0   254.1-3
ii  libx11-6  2:1.8.6-1
ii  libxau6   1:1.0.9-1
ii  libxcb1   1.15-1
ii  libxdmcp6 1:1.1.2-3
ii  mutter [x-window-manager] 44.4-3
ii  plasma-workspace [x-session-manager]  4:5.27.8-1
ii  polkitd   123-1
ii  procps2:4.0.3-1
ii  systemd-sysv  254.1-3
ii  ucf   3.0043+nmu1
ii  x11-common1:7.7+23
ii  x11-xserver-utils 7.7+9+b1
ii  xfce4-session [x-session-manager] 4.18.3-1
ii  xfce4-terminal [x-terminal-emulator]  1.1.0-1
ii  xfwm4 [x-window-manager]  4.18.0-1
ii  xterm [x-terminal-emulator]   384-1

Versions of packages gdm3 recommends:
ii  at-spi2-core  2.49.91-2
ii  desktop-base  12.0.6+nmu1
ii  gnome-session [x-session-manager] 44.0-4
ii  plasma-workspace [x-session-manager]  4:5.27.8-1
ii  x11-xkb-utils 7.7+7
ii  xfce4-session [x-session-manager] 4.18.3-1
ii  xserver-xephyr2:21.1.8-1
ii  xserver-xorg  1:7.7+23
ii  zenity3.44.2-1

Versions of packages gdm3 suggests:
pn  libpam-fprintd
ii  libpam-gnome-keyring  42.1-1+b2
pn  libpam-pkcs11 
pn  libpam-sss
pn  orca  

-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid

[David Bremner]

Andreas Beckmann  writes:

> Package: compat-el
> Version: 29.1.4.1-2
> Severity: serious
>
> elpa-hl-todo/sid is currently uninstallable since it depends on
> elpa-compat (>= 29.1.4.2).
>
>
> Andreas

Maybe it doesn't matter, but I don't think this is a serious bug in
compat.el. It's not like a it's a regression. It's a serious bug in the
package which is uninstallable.

d

Bug#1051992: wpasupplicant: unattended-upgrade reports tar errors while upgrading wpasupplicant

[in . cognito35]

Package: wpasupplicant
Version: 2:2.10-15
Severity: minor
X-Debbugs-Cc: in.cognit...@arcor.de

Dear Maintainer,

   * What led up to the situation?

unattended-upgrade upgrading wpasupplicant (2:2.10-15) over (2:2.10-12).

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

Executed "sudo unattended-upgrade" manually to force a major unattended
upgrade.

   * What was the outcome of this action?

Seems that the upgrade came through successfully, BUT:
During the process the following error was reported on the
terminal:

  [~]$ sudo unattended-upgrade  
  [sudo] password for farblos: 
  tar: .remove-on-upgrade /etc/dbus-1/system.d/wpa_supplicant.conf: Not found 
in archive
  tar: Exiting with failure status due to previous errors

I guess that this has to do with the first line of the config
file definition of the package:

  [~]$ cat /var/lib/dpkg/info/wpasupplicant.conffiles
  remove-on-upgrade /etc/dbus-1/system.d/wpa_supplicant.conf
  /etc/wpa_supplicant/action_wpa.sh
  /etc/wpa_supplicant/functions.sh
  /etc/wpa_supplicant/ifupdown.sh

More logs available on request.

   * What outcome did you expect instead?

No funny error messages.


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

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

Versions of packages wpasupplicant depends on:
ii  adduser3.137
ii  libc6  2.37-7
ii  libdbus-1-31.14.10-1
ii  libnl-3-2003.7.0-0.2+b1
ii  libnl-genl-3-200   3.7.0-0.2+b1
ii  libnl-route-3-200  3.7.0-0.2+b1
ii  libpcsclite1   2.0.0-1
ii  libreadline8   8.2-1.3
ii  libssl33.0.10-1

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- Configuration Files:
/etc/dbus-1/system.d/wpa_supplicant.conf [Errno 2] No such file or directory: 
'/etc/dbus-1/system.d/wpa_supplicant.conf'

-- no debconf information

Bug#1051577: iproute2: obsolete conffiles

[Luca Boccassi]

On Wed, 13 Sept 2023 at 10:44, Ian Campbell  wrote:
>
> On Tue, 2023-09-12 at 23:13 +0200, Luca Boccassi wrote:
> > On Mon, 11 Sept 2023 at 15:57, Daniel Gröber 
> > wrote:
> > >
> > > Hi Luca,
> > >
> > > On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote:
> > > > > I want to question whether removing these conffiles is a good idea at
> > > > > all. I'm probably one of the few people that actually muck around in 
> > > > > there
> > > > > but it seems like this is going to break things for any users that do.
> > > >
> > > > As far as I understand dpkg's conffile machinery should recognize if
> > > > you changed anything, and leave it in place. Upstream moved the
> > > > default ones to /usr, so we just follow what they do.
> > >
> > > Right. Think of an admin having to adjust these config files though:
> > > previously they could just `editor /etc/iproute2/rt_tables` and get on 
> > > with
> > > things. Now anyone needing to do that will have to do a doubletake, figure
> > > out why /etc/iproute2 is missing, realize that it's at /usr/lib/iproute2
> > > now, copy that over and finally edit.
> > >
> > > Is that friction really warrented to cater to a specialized niche 
> > > use-case?
> > >
> > > Please consider overriding upstream's decision here.
> >
> > Yes, it is warranted, both because it's exactly the correct behaviour
> > for a package, and also because we are certainly not spending time and
> > resources to go against upstream choices, especially when they are the
> > right choices.
>
> What is the plan for handling updates? AIUI we've lost the dpkg
> conffile handling but it doesn't look like it's been replaced by
> anything (e.g. like using ucf to prompt when an update happened
> perhaps?).

Same as everything else that uses drop-ins and hermetic-usr since
forever. No more pointless noise and wasting time solving conflicts by
hand in whitespace changes, comment typos and so on.

Bug#1041702: git-email: crashes when returning from "edit"

[David Bremner]

David Bremner  writes:

> David Bremner  writes:
>
>> Oh, and I am now seeing it with --compose, neither --annotate nor 'e' is
>> involved (cf. my original report).
>>
>> Bumping the severity as I am completely blocked from my normal
>> git-send-email workflow on this machine.
>
> prompted by Kibi on IRC, I observed that installing
> libterm-readline-perl-perl and removing libterm-readline-gnu-perl
> leads to
>
>   Cannot create second readline interface, falling back to dumb.
>   Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll):
>
> this "dumb" seems to succeed.

And removing libterm-readline-perl-perl causes the warning messages to
go away. So maybe most people don't have these problems because they
don't have libterm-readline-*-perl installed.

Bug#1043241: options

[dann frazier]

We've been discussing this with upstream at
https://github.com/OP-TEE/optee_client/pull/355 , which is an attempt
to make emulation a runtime option. An argument is being made that
it should remain a build time switch, to avoid having to ship the
emulation code in production environments. We'll see how that shakes
out.

If this remains a build-time switch, one option would be for Debian to
consider building 2 different binary packages. Would the maintainer be
open to that?

Bug#1032821: smartmontools: Please remove files in /tmp/ after email is sent

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> Hi.  Do you need help fixing this issue?

One idea from
https://listi.jpberlin.de/pipermail/smartmontools-support/2023-September/001022.html
 >
is to use the -p option in smartd.conf.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1051991: ITP: node-sixel -- Node.js library to manage Sixel images

[Yadd]

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

* Package name: node-sixel
  Version : 0.16.0
  Upstream Contact: Joerg Breitbart 
* URL : https://github.com/jerch/node-sixel/
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js library to manage Sixel images

node-sixel is a image decoding / encoding library for node and the browser.

It is a build dependency of node-xterm 5 which is required for
node-jupyterlab. Will be maintained under JS Team umbrella.

Bug#1041702: git-email: crashes when returning from "edit"

[David Bremner]

David Bremner  writes:

> Oh, and I am now seeing it with --compose, neither --annotate nor 'e' is
> involved (cf. my original report).
>
> Bumping the severity as I am completely blocked from my normal
> git-send-email workflow on this machine.

prompted by Kibi on IRC, I observed that installing
libterm-readline-perl-perl and removing libterm-readline-gnu-perl
leads to

  Cannot create second readline interface, falling back to dumb.
  Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll):

this "dumb" seems to succeed.

Bug#1015809: 1015809: isc-dhcp-client: DHCPv6 doesn't work on ppp interface, got `Unsupported device type` error

[Steven Haigh]

I'd suggest that even if nothing else, the package is updated with the 
same patches that Fedora have done - just to make the functionality the 
same - ie it actually works.


I know IPv6-PD isn't really wide-spread, but its enough that there 
should be at least one functional method to do it within Debian.


At that point, you're right - it'll probably not get much attention 
again afterwards.

--
Steven Haigh

 net...@crc.id.au 
 https://crc.id.au 

On Fri, Sep 15 2023 at 13:02:44 +0530, Santiago Ruano Rincón 
 wrote:
On Sun, 23 Jul 2023 12:45:34 +1000 Steven Haigh > wrote:

 Ok, so after a day of messing around with Debian 12, it looks like
 without these patches applied, there is no way to get a IPv6 PD 
working

 with a PPPoE connection. Given the majority of ISPs in Australia use
 PPPoE as their connection method, this is a much bigger issue in 
this

 country than where the maintainers of this package live.

 wide-dhcpv6-client doesn't seem to interpret the reply from the ISP 
as

 a valid one.

 dibbler-client binds to the wrong LL address and fails to open a 
socket.


 Copying the dhclient binary from a Fedora 38 install and using that
 works perfectly - which is using the Fedora patches for dhclient 
v4.4.3.


 The current, functioning patch from Fedora is here:
 
<>


 How are we able to fix this properly instead of a 'copy the binary 
from

 Fedora' type fix?


Sorry, I really missed this bug report. That said, since the EOL of
isc-dhcp-server, I reduced the priority given to isc-dhcp.

If isc-dhcp is that broken for .au, I could consider a stable update,
after this has been solved in unstable and confirmed doesn't break
anything.

Cheers,

 -- Santiago

Bug#1042911: (Still?) breaks Emacs 29.1 unattended-upgrade

[Farblos]

Not sure whether this is still relevant or just bad luck or whatever ... my
unattended-upgrade failed today because of this issue.  Logs available
on request.  Work-around was to remove version 3.20+dfsg-7, retrigger
the unattended upgrade, install version 3.20+dfsg-8.

Thanks for taking care of this package, BTW!

Bug#1051649: libportal: FTBFS on riscv64 due to test timeout

[Simon McVittie]

Control: tags 1051649 + pending

On Mon, 11 Sep 2023 at 00:17:31 +0200, Aurelien Jarno wrote:
> libportal fails to build from source on riscv64 (and a few other slow
> architectures) with a timeout in a test
...
> After investigation, it appeared the test actually passes, but needs
> 85 seconds instead of the 60 seconds it got allocated. The
> following patch uses the --timeout-multiplier feature of meson to
> increase the timeout.

Thanks, I'll upload a similar fix after the current version has migrated
to testing (it's only 1 day off, so it would seem a shame to reset the
clock for this). I increased the timeout by a factor of 3 rather than 2,
to give some margin of error.

However, I'm concerned that this implies riscv64 might be our new slowest
release architecture, even slower than mips64el, which is going to put
it at risk of delaying migrations, security fixes and other release
stuff (as a result of builds taking a long time, arbitrary timeouts in
build-time tests becoming insufficient, or race conditions in build-time
tests being hit when they wouldn't have been seen on faster buildds).

Do you expect faster riscv64 buildds to become available by the time
trixie is the stable release, or is what we have now what we are going
to continue to have?

This might also resolve #1051702, but obviously I haven't tested on
hppa hardware to find out how long this test actually takes there,
so I'm not marking that one as pending.

smcv

Bug#1042989: Consider switching packaging to Incus

[Free Ekanayaka]

Hello!

as you probably know, the initial fork from:

https://github.com/cyphar/incus/

has now been moved under the LXC project:

https://github.com/lxc/incus,

and has definitely gained traction since the initial announcement,
getting support both from the community and from LXD developers that
have now moved to incus (myself included).

I wanted to wait for the first official incus release before reaching
out to Debian fellows, but since I noticed that you might be working on
updating the LXD package I thought it be good to get in contact.

As Debian developer myself, incus maintainer and original author of
dqlite/libraft (which have now been forked too into the new "cowsql"
project https://github.com/cowsql, used by incus), I'd of course love to
see Debian switching to incus and cowsql, and in that case I'd like to
help out with packaging and maintainership.

Within the incus team we have discussed possible Debian-specific
migration strategies and we'd have ideas about how to handle it, so
users experience the least possible disruption.

I'd like to know what are your feelings around these topics, and of
course I understand if you prefer to just sit on the sidelines for now.

Cheers,

Free

Bug#1050582: kmod update corrupts systemd uefi boot

[Martin Nybo Andersen]

Hi,

The problem is, that kmod has switched to using the kernel decompressor 
when available, which is XZ Embedded. This version doesn't handle CRC64 
and dictionaries larger than 1 MiB.


You can fix it by compressing the modules with `xz --check=crc32 
--lzma2=dict=1MiB module.ko`

This can easily be done by applying the following patch to your kernel git 
repository:


https://lore.kernel.org/all/3d34a965-ab9c-d549-0c63-c717ab5d2...@tweek.dk/

Afterwards `make modules_install` will compress and install the modules 
correctly.



Best regards,
Martin Nybo Andersen

Bug#1051990: neovim: New upstream version 0.9.2, the current version is too old

[Jonatas]

Package: neovim
Version: 0.7.2-7
Severity: important
X-Debbugs-Cc: dkdj3p...@mozmail.com

Dear Maintainer,

There is a new version 0.9.2 of this package, the current version is already 
very old.
The current version fixes several bugs, implements performance improvements and 
is compatible with several plugins.
If necessary, I can try to help with packing.

Thanks,
Jonatas

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

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

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


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

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

Versions of packages neovim depends on:
ii  libc62.37-8
ii  libluajit-5.1-2  2.1.0~beta3+git20220320+dfsg-4.1
ii  libmsgpackc2 4.0.0-3
ii  libtermkey1  0.22-1
ii  libtree-sitter0  0.20.8-2
ii  libunibilium42.1.0-3
ii  libuv1   1.44.2-1
ii  libvterm00.1.4-1
ii  lua-luv  1.44.2-0-1
ii  neovim-runtime   0.7.2-7

Versions of packages neovim recommends:
ii  python3-pynvim  0.4.2-2
ii  wl-clipboard2.2.1-1
ii  xxd 2:9.0.1894-1

Versions of packages neovim suggests:
pn  ctags
pn  vim-scripts  

-- no debconf information

Bug#1050639: bookworm-pu: package clamav/1.0.2+dfsg-1~deb12u1

[Sebastian Andrzej Siewior]

On 2023-09-14 21:52:25 [+0100], Adam D. Barratt wrote:
> 
> That's now out, as SUA-240-1.

Thank you Adam.

> Regards,
> 
> Adam

Sebastian

Bug#787963: wdiff: please don't use the same node name two times

[Santiago Vila]

Hello.

Some time ago I received (via clone & reassign), the following report from the 
Debian bug system:

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

To summarize: The command:

info wdiff

jumps into the Invocation instead of top of wdiff.

Thanks.

Bug#1051989: kanboard: FTBFS with php-psr-log >= 3, needed for the symfony 6 transition

[Athos Ribeiro]

Package: kanboard
Severity: normal
X-Debbugs-Cc: athoscribe...@gmail.com

Control: block 1041982 by -1

Dear Maintainer,

During a test build of kanboard in experimental in preparation for
symfony 6, the package tests failed with

 74s PHP Fatal error:  Declaration of Kanboard\Core\Log\Logger::log($level, 
$message, array $context = []) must be compatible with 
Psr\Log\AbstractLogger::log($level, Stringable|string $message, array $context 
= []): void in /usr/share/kanboard/app/Core/Log/Logger.php on line 72

 More information is available at 
https://qa.debian.org/excuses.php?experimental=1=php-psr-log.

 Thanks for the attention!

Bug#1051988: civicrm-common: Not compatible with symfony 6

[David Prévot]

Package: civicrm-common
Version: 5.53.0+dfsg1-1
Severity: normal
X-Debbugs-Cc: Debian PHP PEAR Maintainers 
User: pkg-php-p...@lists.alioth.debian.org
Usertags: symfony
Control: affects -1 + src:symfony
Control: blocks 1041982 by -1

Hi,

civicrm-common is declared to be compatible with Symfony 4 (only) in
its composer.json upstream file. It also depends on php-psr-container
version 1 while a more recent version of php-psr-container is needed for
Symfony 6 that should be released with trixie.

Regards

taffit


signature.asc
Description: PGP signature

Bug#1041702: git-email: crashes when returning from "edit"

[David Bremner]

Sven Joachim  writes:

>
> For me this seems to happen whenever I do not give an email address via
> the "--to" option.  In this case, "git send-email" prompts
>
> "To whom should the emails be sent (if anyone)?"
>
> but no matter what I type, I get the exact same error as you.
>

Hmm. I am seeing it when prompted for an 8bit encoding. I guess the
common theme is prompting.

Bug#1051987: too old for ghc

[Joey Hess]

Package: cabal-install
Version: 3.4.1.0-3
Severity: normal

This version of cabal in unstable is too old to properly support ghc 9.4.6 in 
unstable:

joey@darkstar:~/src/git-annex>cabal configure
'cabal.project.local' already exists, backing it up to 'cabal.project.local~'.
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.1.0 supports
'ghc' version < 9.1): /usr/bin/ghc is version 9.4.6
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: git-annex-10.20230828 (user goal)
[__1] next goal: git-annex:setup.Cabal (dependency of git-annex)
[__1] rejecting: git-annex:setup.Cabal-3.8.1.0/installed-3.8.1.0,
git-annex:setup.Cabal-3.10.1.0, git-annex:setup.Cabal-3.8.1.0,
git-annex:setup.Cabal-3.6.3.0, git-annex:setup.Cabal-3.6.2.0,
git-annex:setup.Cabal-3.6.1.0, git-annex:setup.Cabal-3.6.0.0 (constraint from
maximum version of Cabal used by Setup.hs requires <3.6)
[__1] trying: git-annex:setup.Cabal-3.4.1.0
[__2] next goal: git-annex:setup.base (dependency of git-annex)
[__2] rejecting: git-annex:setup.base-4.17.2.0/installed-4.17.2.0 (conflict:
git-annex:setup.Cabal => git-annex:setup.base>=4.6 && <4.16)
[__2] skipping: git-annex:setup.base-4.18.0.0, git-annex:setup.base-4.17.2.0,
git-annex:setup.base-4.17.1.0, git-annex:setup.base-4.17.0.0,
git-annex:setup.base-4.16.4.0, git-annex:setup.base-4.16.3.0,
git-annex:setup.base-4.16.2.0, git-annex:setup.base-4.16.1.0,
git-annex:setup.base-4.16.0.0 (has the same characteristics that caused the
previous version to fail: excluded by constraint '>=4.6 && <4.16' from
'git-annex:setup.Cabal')
[__2] rejecting: git-annex:setup.base-4.15.1.0, git-annex:setup.base-4.15.0.0,
git-annex:setup.base-4.14.3.0, git-annex:setup.base-4.14.2.0,
git-annex:setup.base-4.14.1.0, git-annex:setup.base-4.14.0.0,
git-annex:setup.base-4.13.0.0, git-annex:setup.base-4.12.0.0,
git-annex:setup.base-4.11.1.0, git-annex:setup.base-4.11.0.0,
git-annex:setup.base-4.10.1.0, git-annex:setup.base-4.10.0.0,
git-annex:setup.base-4.9.1.0, git-annex:setup.base-4.9.0.0,
git-annex:setup.base-4.8.2.0, git-annex:setup.base-4.8.1.0,
git-annex:setup.base-4.8.0.0, git-annex:setup.base-4.7.0.2,
git-annex:setup.base-4.7.0.1, git-annex:setup.base-4.7.0.0,
git-annex:setup.base-4.6.0.1, git-annex:setup.base-4.6.0.0,
git-annex:setup.base-4.5.1.0, git-annex:setup.base-4.5.0.0,
git-annex:setup.base-4.4.1.0, git-annex:setup.base-4.4.0.0,
git-annex:setup.base-4.3.1.0, git-annex:setup.base-4.3.0.0,
git-annex:setup.base-4.2.0.2, git-annex:setup.base-4.2.0.1,
git-annex:setup.base-4.2.0.0, git-annex:setup.base-4.1.0.0,
git-annex:setup.base-4.0.0.0, git-annex:setup.base-3.0.3.2,
git-annex:setup.base-3.0.3.1 (constraint from non-upgradeable package requires
installed instance)
[__2] fail (backjumping, conflict set: git-annex, git-annex:setup.Cabal,
git-annex:setup.base)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: git-annex, git-annex:setup.Cabal,
git-annex:setup.base


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

Kernel: Linux 6.4.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 cabal-install depends on:
ii  ghc9.4.6-1
ii  libc6  2.37-8
ii  libffi83.4.4-1
ii  libgmp10   2:6.3.0+dfsg-2
ii  sgml-base  1.31
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages cabal-install recommends:
ii  curl  8.3.0-1
ii  wget  1.21.4-1+b1

cabal-install suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature