Bug#1072105: /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.

2024-06-08 Thread Andreas Metzler
On 2024-05-29 Luca Boccassi  wrote:
> On Wed, 29 May 2024 20:15:36 +0200 Michael Biebl  wrote:
>> On Tue, 28 May 2024 17:15:02 +0100 Luca Boccassi  wrote:
>>> On Tue, 28 May 2024 17:44:54 +0200 Michael Biebl >> wrote:
[...]

 Please do not not ship conflicting configuration for /run/lock

 /usr/lib/tmpfiles.d/debian.conf:d /run/lock    1777 root root -  
> -
 /usr/lib/tmpfiles.d/legacy.conf:d /run/lock 0755 root root -

 triggering unnecessary warnings.

>>> This is needed to apply debian-specific changes, just ignore it,
>>> it's
>>> harmless
[...]
> No. The current approach is just fine. If you don't like seeing the
> harmless notice-level log, just add a local override in /etc/.

>> Btw, please don't close bug reports without CCing the bug submitter. 
>> That's rude.

> Please stop playing ping pong with the BTS, this is staying as it is.

Hello,

Let me upvote this bug-report. I have unnecessarly spent time
investigating the issue, checking whether this is a known bug. Having
read through the bug I still have not read an explanation why the
current state "is just fine". If it really was systemd would not throw
a warning. What is the huge benefit of shipping conflicting configurations
instead of shipping one that is correct for Debian that justifies
wasting our contributors' time?

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



Bug#731668: gnome-boxes: Cannot connect to VM

2024-06-08 Thread Dr Lawrence M Fox
Package: gnome-boxes
Version: 46.1-3
Followup-For: Bug #731668
X-Debbugs-Cc: dr...@chicagovet.net

Dear Maintainer,


Apt update/upgrade to the latest packages for sid today, 8 July 2024.
Tried to run Boxes. Program opened without the VM which I had previously built
and has been running well. It did not show the VM. When I navigated to the VM
location (./local/share/gnome-boxes/images/win11) the file would not open.
Boxes was asking for a .qcow2 file. I reported to the debian forum and a reply
was given about how to change a qcow file to a .qcow2 file. I did the
conversion and tried to open the Win11.qcow2 file and there was a quick flash
and the program terminated.


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

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

Versions of packages gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  genisoimage  9:1.1.11-3.5
ii  libarchive13t64  3.7.2-2.1
ii  libc62.38-12.1
ii  libcairo21.18.0-3+b1
ii  libgdk-pixbuf-2.0-0  2.42.12+dfsg-1
ii  libglib2.0-0t64  2.80.2-2
ii  libgtk-3-0t643.24.42-1
ii  libgudev-1.0-0   238-5
ii  libhandy-1-0 1.8.3-1+b1
ii  libosinfo-1.0-0  1.11.0-2+b1
ii  libosinfo-bin1.11.0-2+b1
ii  libportal-gtk3-1 0.7.1-5+b1
ii  libportal1   0.7.1-5+b1
ii  libsoup-3.0-03.4.4-5+b1
ii  libspice-client-glib-2.0-8   0.42-2.1
ii  libspice-client-gtk-3.0-50.42-2.1
ii  libusb-1.0-0 2:1.0.27-1
ii  libvirt-clients  10.4.0-1
ii  libvirt-daemon   10.4.0-1
ii  libvirt-glib-1.0-0   5.0.0-2+b3
ii  libwebkit2gtk-4.1-0  2.44.2-1+b1
ii  libxml2  2.12.7+dfsg-3
ii  tracker  3.7.3-1
ii  user-session-migration   0.4.2

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:8.2.4+ds-2

Versions of packages gnome-boxes suggests:
pn  gnome-connections  

-- no debconf information



Bug#1064485: RFS: samplebrain/0.18.5-1 [ITP] -- Custom sample smashing app designed by Aphex Twin

2024-06-08 Thread Phil Wyett
Hi,

Not a full review at this time. Package fails to build, error below.

g++ -c -pipe -O3 -Wall -Wno-unused -std=c++11 -g -O2 -ffile-prefix-
map=/build/samplebrain-0.18.5=. -fstack-protector-strong -fstack-clash-
protection -Wformat -Werror=format-security -fcf-protection -Wdate-time
-D_FORTIFY_SOURCE=2 -Wall -Wextra -D_REENTRANT -fPIC -DQT_NO_DEBUG
-DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. -I2 -Ibrain/src
-I/usr/local/include -I/opt/homebrew/include 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-
gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I.
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o allocator.o
brain/src/spiralcore/allocator.cpp
g++ -c -pipe -O3 -Wall -Wno-unused -std=c++11 -g -O2 -ffile-prefix-
map=/build/samplebrain-0.18.5=. -fstack-protector-strong -fstack-clash-
protection -Wformat -Werror=format-security -fcf-protection -Wdate-time
-D_FORTIFY_SOURCE=2 -Wall -Wextra -D_REENTRANT -fPIC -DQT_NO_DEBUG
-DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. -I2 -Ibrain/src
-I/usr/local/include -I/opt/homebrew/include 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-
gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I.
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o stream.o
brain/src/spiralcore/stream.cpp
brain/src/spiralcore/OSC_server.cpp: In constructor
'OSC_server::OSC_server(const std::string&)':
brain/src/spiralcore/OSC_server.cpp:40:32: error: invalid conversion from 'int
(*)(const char*, const char*, lo_arg**, int, void*, void*)' to
'lo_method_handler' {aka 'int (*)(const char*, const char*, lo_arg**, int,
lo_message_*, void*)'} [-fpermissive]
   40 | lo_server_thread_add_method(m_server, NULL, NULL, default_handler,
this);
  | ~~~^

  ||
  |int (*)(const char*, const char*,
lo_arg**, int, void*, void*)
In file included from /usr/include/lo/lo.h:33,
 from brain/src/spiralcore/OSC_server.h:21,
 from brain/src/spiralcore/OSC_server.cpp:23:
/usr/include/lo/lo_serverthread.h:151:72: note:   initializing argument 4 of
'lo_method_* lo_server_thread_add_method(lo_server_thread, const char*, const
char*, lo_method_handler, const void*)'
  151 |const char *typespec, lo_method_handler
h,
  |  ~~^
make[1]: *** [Makefile:800: OSC_server.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/build/samplebrain-0.18.5'
dh_auto_build: error: make -j4 returned exit code 2
make: *** [debian/rules:6: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package

When rectified, please indicate a new upload via this RFS bug.

Regards

Phil

-- 

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg


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


Bug#1072853: transition: gnustep-base, gnustep-gui

2024-06-08 Thread Yavor Doganov
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org
User: release.debian@packages.debian.org
Usertags: transition

Hi release managers,

On behalf of the GNUstep team I'd like to request a transition slot
for a combined gnustep-base/gnustep-gui transition (one-round binNMUs):

libgnustep-base1.29 -> 1.30
libgnustep-gui0.30 -> 0.31

The new libraries are available in experimental, built on all release
architectures.  Build-testing the rdeps revealed only one issue
(lynkeos.app, #1072736) which has been fixed in unstable so no
sourceful uploads (except gnustep-back) will be required.

FYI, the new gnustep-gui version adds support for ImageMagick 7
(release.d.o #1060103).

The automatically generated trackers look fine.



Bug#1072852: man page for python3-unidiff

2024-06-08 Thread Yogeswaran Umasankar

Package: python-unidiff
Tags: patch

Hi,

I've created a man page for the 'python3-unidiff'. Please find the
attached man page 'python3-unidiff.1' for your review.

Cheers!
Yogeswaran.
.TH PYTHON3-UNIDIFF "1" "June 2024" "python3-unidiff 1.0" "User Commands"
.SH NAME
python3-unidiff 
.SH SYNOPSIS
.B python3-unidiff
.RI [ options ]
.SH DESCRIPTION
.B python3-unidiff
is a tool for processing unified diff data. It can read diff data from a file 
or from standard input and optionally output the diff to stdout.
.SH OPTIONS
.TP
.B \-h, \--help
Show this help message and exit.
.TP
.B \--show-diff
Output the diff to stdout.
.TP
.B \-f, \--file \fIDIFF_FILE\fR
Read diff data from the specified file. If not specified, read diff data from 
stdin.
.SH EXAMPLES
.TP
.B
git diff | python3-unidiff
Run the tool with diff data from \fBgit diff\fR.
.TP
.B
hg diff | python3-unidiff --show-diff
Run the tool with diff data from \fBhg diff\fR and output the diff to stdout.
.TP
.B
python3-unidiff -f patch.diff
Run the tool with diff data from the specified file \fBpatch.diff\fR.
.SH AUTHOR
Yogeswaran Umasankar 
.SH REPORTING BUGS
Report bugs to the Debian Bug Tracking System at \fIhttps://bugs.debian.org/\fR.


Bug#1072851: ITP: python-truncnorm -- Moments for truncated multivariate normal distributions for Python

2024-06-08 Thread Boyuan Yang
Package: wnpp
Owner: Boyuan Yang 
Severity: wishlist

* Package name: python-truncnorm
  Version : 0.0.2
  Upstream Contact: Jaakko Luttinen 
* URL : https://github.com/jluttine/truncnorm
* License : Expat
  Programming Lang: Python
  Description : Moments for truncated multivariate normal distributions for 
Python

 Package truncnorm provides support of arbitrary order moments for doubly
 truncated multivariate normal distributions as a Python library.

This package is a dependency to the new version of python-bayespy.

This package will be maintained under Debian Science Team umbrella.


Thanks,
Boyuan Yang



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


Bug#1072828: texlive-binaries upgrade breaks therion build

2024-06-08 Thread Adrian Bunk
On Sun, Jun 09, 2024 at 12:02:02AM +0200, Preuße, Hilmar wrote:
> On 08.06.2024 16:09, Adrian Bunk wrote:
> 
> Hi,

Hi Hilmar,

>...
> Hence I tend to say this is something specific for sbuild environments,
> which could have lower priority than "serious".

all testing I did for the below statement was plain dpkg-buildpackage
in a chroot.

> > Downgrading texlive-binaries to 2023.20230311.66589-9 OR
> > installing texlive-fonts-recommended works around this issue.
> 
> Why not simply adding texlive-fonts-recommended to BD (which carries the
> Type1 fonts of logo10) and then solve the issue?
>...

Because that doesn't fix whatever the bug is, which might also affect 
other packages or users.

a minimal example inside therion-6.2.1/thbook/ after a failed 
build seems to be
  TEXINPUTS="/<>/build/thbook;." /usr/bin/pdftex 
--output-dir=/<>/build/thbook thbook.tex 

Did anything break or change regarding --output-dir ?

In the working case with the old version the generated file is in
debian/.debhelper/generated/_source/home/.texlive2023/texmf-var/fonts/pk/ljfour/public/knuth-lib/logo10.720pk

> H.

cu
Adrian



Bug#1072850: python-mkdocs: Please package new version 1.6.0

2024-06-08 Thread Boyuan Yang
Source: python-mkdocs
Severity: normal
Version: 1.5.3+dfsg-1
X-Debbugs-CC: b...@debian.org c.schoen...@t-online.de

Dear Debian python-mkdocs maintainer,

A new upstream release of mkdocs is available. Please consider reviewing it
(as well as the compatibility of related packages) and have it packaged in 
Debian.

Thanks,
Boyuan Yang


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


Bug#1072786: addch.3ncurses: some remarks and editorial changes for this man page

2024-06-08 Thread Thomas Dickey
On Fri, Jun 07, 2024 at 08:40:59PM +, Bjarni Ingi Gislason wrote:
> Package: ncurses-doc
> Version: 6.5-2
> Severity: minor
> Tags: patch
...
> 
> :189: warning: table row does not fit on page 1

Branden Robinson made a fix for this two weeks ago.

> Split lines longer than 80 characters into two or more lines.
> Appropriate break points are the end of a sentence and a subordinate
> clause; after punctuation marks.
>  
> addch.3ncurses: line 69 length 84

I don't use that check.  Instead, I use a script which warns me if the
rendered line would be too long.  This one ends at column 64.
 
> \fBint mvwaddch(WINDOW *\fIwin\fP, int \fIy\fP, int \fIx\fP, const chtype 
> \fIch\fP);

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature


Bug#1072849: uuid.3: some remarks and editorial changes for this man page

2024-06-08 Thread Bjarni Ingi Gislason
Package: uuid-dev
Version: 2.40.1-8
Severity: minor
Tags: patch

Dear Maintainer,

   * What led up to the situation?

 Checking for defects with

[test-]groff -mandoc -t -K utf8 -ww -b -z 

  [test-groff is a script in the repository for "groff"]

   * What was the outcome of this action?

troff: backtrace: file '':10
troff::10: warning: macro 'Aq' not defined

   * What outcome did you expect instead?

 No output (warnings).

-.-

  Remarks and a patch are in the attachments.

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

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages uuid-dev depends on:
ii  libc6-dev [libc-dev]  2.38-12
ii  libuuid1  2.40.1-8

uuid-dev recommends no packages.

uuid-dev suggests no packages.

-- no debconf information
  Any program (person), that produces man pages, should check its content for
defects by using

groff -mandoc -t -ww -b -z [ -K utf8 | k ] 

  The same goes for man pages that are used as an input.

  For a style guide use

  mandoc -T lint

-.-

  So any generator should check its products with the above mentioned
'groff' and additionally with 'nroff ...'.

  This is just a simple quality control measure.

  The generator may have to be corrected to get a better man page,
the source file may, and any additional file may.

-.-

The difference between the formatted outputs can be seen with:

  nroff -mandoc  > 
  nroff -mandoc  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -mandoc -Z - "

instead of "nroff -mandoc"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint uuid.3": (possibly shortened list)

mandoc: uuid.3:10:61: WARNING: undefined string, using "": Aq
mandoc: uuid.3:21:9: ERROR: skipping insecure request: mso
mandoc: uuid.3:28:4: ERROR: skipping unknown macro:  LINKSTYLE blue R < >
mandoc: uuid.3:33:2: WARNING: skipping paragraph macro: sp after SH
mandoc: uuid.3:36:2: WARNING: skipping paragraph macro: sp after SH
mandoc: uuid.3:37:278: STYLE: input text line longer than 80 bytes: The UUID 
library is ...
mandoc: uuid.3:39:294: STYLE: input text line longer than 80 bytes: The UUIDs 
generated ...
mandoc: uuid.3:41:2: WARNING: skipping paragraph macro: sp after SH
mandoc: uuid.3:42:107: STYLE: input text line longer than 80 bytes: This 
library generat...
mandoc: uuid.3:45:2: WARNING: skipping paragraph macro: sp after SH
mandoc: uuid.3:48:2: WARNING: skipping paragraph macro: sp after SH
mandoc: uuid.3:58:2: WARNING: skipping paragraph macro: sp after SH
mandoc: uuid.3:62:2: WARNING: skipping paragraph macro: sp after SH
mandoc: uuid.3:63:111: STYLE: input text line longer than 80 bytes: The 
\fBlibuuid\fP li...

-.-.

Lines containing '\c':

42:This library generates UUIDs compatible with OSF DCE 1.1, and hash based 
UUIDs V3 and V5 compatible with \c
59:For bug reports, use the issue tracker at \c
63:The \fBlibuuid\fP library is part of the util\-linux package since version 
2.15.1. It can be downloaded from \c



Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

N.B.

  The number of lines affected can be too large to be in the patch.

37:The UUID library is used to generate unique identifiers for objects that may 
be accessible beyond the local system. This library generates UUIDs compatible 
with those created by the Open Software Foundation (OSF) Distributed Computing 
Environment (DCE) utility \fBuuidgen\fP(1).
39:The UUIDs generated by this library can be reasonably expected to be unique 
within a system, and unique across all systems. They could be used, for 
instance, to generate unique HTTP cookies across multiple web servers without 

Bug#1072828: texlive-binaries upgrade breaks therion build

2024-06-08 Thread Preuße

On 08.06.2024 16:09, Adrian Bunk wrote:

Hi,


https://buildd.debian.org/status/fetch.php?pkg=therion=amd64=6.2.1-1%2Bb1=1717847632=0

...
FAILED: thbook/thbook.pdf /<>/build/thbook/thbook.pdf


I can confirm that the failing command works fine on a normal
computer..this is a chroot on arm64.


hille@rasppi2:~$ mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600
logo10
mktexpk: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1+0/600;
nonstopmode; input logo10
This is METAFONT, Version 2.71828182 (TeX Live 2025/dev/Debian)
(preloaded base=mf)

(/usr/share/texlive/texmf-dist/fonts/source/public/knuth-lib/logo10.mf
(/usr/share/texlive/texmf-dist/fonts/source/public/knuth-lib/logo.mf [77]
[69] [84] [65] [70] [80] [83] [79] [78]) )
Font metrics written on logo10.tfm.
Output written on logo10.600gf (9 characters, 1748 bytes).
Transcript written on logo10.log.
mktexpk:
/home/hille/.texlive2024/texmf-var/fonts/pk/ljfour/public/knuth-lib/logo10.600pk:
successfully generated.
/home/hille/.texlive2024/texmf-var/fonts/pk/ljfour/public/knuth-lib/logo10.600pk
hille@rasppi2:~$

Hence I tend to say this is something specific for sbuild environments,
which could have lower priority than "serious".


Downgrading texlive-binaries to 2023.20230311.66589-9 OR
installing texlive-fonts-recommended works around this issue.



Why not simply adding texlive-fonts-recommended to BD (which carries the
Type1 fonts of logo10) and then solve the issue? We may open a new bug
"why does mktexpk does not work in an sbuild?", but this could have a
lower priority, IMHO.

H.
--
sigfault



Bug#1072842: rust-async-lock: please update to version 3.0+

2024-06-08 Thread Jonas Smedegaard
Quoting weepingclown (2024-06-08 23:19:14)
> The issue tagged in #1071902 [0] (as well as the issue tagged in that one 
> [1]) seems to be closed with the latest release, so this does not exactly 
> seems like a blocker. If anything, doesn't this close #1071902 itself?
> 
> As for #1068929, while it brings the event-listener dependency, that alone 
> does not bring async-lock 3.0 comaptibility as I ubderstand it. I'm fine with 
> the merge of the bugs, but am failing to see how they are the same. In either 
> case, there does no seem to be a blocker anymore if I understand the 
> situation correctly.

Please discuss those issues at the corresponding bugreport, rather than here.

 - Jonas

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

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

signature.asc
Description: signature


Bug#1072847: lacme: Post-issuance validation fails in the default configuration

2024-06-08 Thread Guilhem Moulin
Package: lacme
Version: 0.8.2-1
Severity: grave
Justification: renders package unusable

Let's Encrypt has recently rotated its intermediate certificates [0].
The previous intermediate certificates (lets-encrypt-r[34].pem and
lets-encrypt-e[12].pem) are concatenated along side the roots
(isrgrootx1.pem and isrg-root-x2.pem) and used as trust anchors for
validation of the issued X.509 certificate before its deployment.

The new intermediates means the validation step now fails.  A quick fix
is to add R1[0-4].pem and E[5-9].pem to the certificate bundle, however
that will cease to work once Let's Encrypt rotates its intermediates
again.

A proper fix would be to use the intermediate(s) provided during the
issuance step as -untrusted (for chain building).

-- 
Guilhem.

[0] https://letsencrypt.org/2024/03/19/new-intermediate-certificates


signature.asc
Description: PGP signature


Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore

2024-06-08 Thread grunt2
‌My im-config shows:

Current configuration for the input method:
 * Default mode defined in /etc/default/im-config: 'auto'
 * Active configuration: 'missing' (normally missing)
 * Normal automatic choice: 'ibus' (normally ibus or fcitx5)
 * Override rule: 'zh_CN,fcitx5:zh_TW,fcitx5:zh_HK,fcitx5:zh_SG,fcitx5'
 * Current override choice: '' (Locale='fr_FR')
 * Current automatic choice: 'ibus'
 * Number of valid choices: 1 (normally 1)
 * Desktop environment: 'GNOME'
The configuration set by im-config is activated by re-starting the system.
La sélection explicite n'est pas nécessaire pour permettre la configuration 
automatique si la sélection active est default/auto/cjkv/missing.

I'm using an Azerty French Keyboard, where the backtick is the grave accent on 
the 7 key (Alt + 7) 
https://en.wikipedia.org/wiki/AZERTY#/media/File:KB_France.svg‌
(I call it the backtick, because it's also the character I type for markdown 
code formatting like `myObject.Fcn()`. But maybe I give it a bad name?)

Whatever, I'm sure that typing the ` under my 7 key followed by an A should 
return an À, like it once did, and that it doesn't do that anymore.
And I am also sure that it doesn't do that anymore since the bug that happened 
and affected the dead keys, and that its fix isn't complete.

Regards,
Marc Le Bihan‌

De : "Simon McVittie" 
A : "Marc Le Bihan" 
,1072...@bugs.debian.org,t...@security.debian.org
Envoyé: vendredi 7 Juin 2024 14:37
Objet : Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys 
doesn't type an À anymore
 
On Fri, 07 Jun 2024 at 13:12:52 +0100, Simon McVittie wrote:
> On Fri, 07 Jun 2024 at 04:50:47 +0200, Marc Le Bihan wrote:
> > * What exactly did you do (or not do) that was effective (or
> > ineffective)?
> > Typing the backtick followed by a wovel: `A
> >
> > * What was the outcome of this action?
> > `A
> >
> > * What outcome did you expect instead?
> > À
>
> What desktop environment, what keyboard layout and what input method
> are you using? And what application are you typing this into?

It would be helpful to run the "im-config" tool, and copy/paste the text
that it displays into a reply to this bug report. What I get in a test
virtual machine is:

Current configuration for the input method:
* Default mode defined in /etc/default/im-config: 'auto'
* Active configuration: 'missing' (normally missing)
* Normal automatic choice: 'ibus' (normally ibus or fcitx5)
* Override rule: 'zh_CN,fcitx5:zh_TW,fcitx5:zh_HK,fcitx5:zh_SG,fcitx5'
* Current override choice: '' (Locale='en_GB')
* Current automatic choice: 'ibus'
* Number of valid choices: 1 (normally 1)
* Desktop environment: 'GNOME'
The configuration set by im-config is activated by re-starting the system.
Explicit selection is not required to enable the automatic
configuration, if the active one is default/auto/cjkv/missing.

but your result is presumably different.

I attempted to reproduce this problem in a virtual machine with:

* Debian 12
* GNOME
* German keyboard layout (configured in Settings → Keyboard → Input Sources):
https://en.wikipedia.org/wiki/QWERTZ#/media/File:German-Keyboard-Layout-T2-Version1-large.png
* gnome-text-editor or Libreoffice Writer as the application

GNOME uses ibus as its input method for most languages, including English
and German. ibus is the input method that was affected by #1070745.

I was unable to reproduce the bug with this combination of settings:

When I press the key that would be printed with acute [´] and grave [`]
accents on a German keyboard (2 positions to the right of the [0] key),
the application displays the accent with an underline (acute accent
´ U+00B4 if I do not use Shift, or grave accent/backtick ` U+0060 if I use
Shift). When I press Shift+[A], the underlined accent gets replaced by
Á or À, as appropriate.

If I want to type `A with that keyboard layout, I have to press:
Shift+[`], Space, Shift+[A].

I do not regularly use keyboard layouts that include dead keys, but to
the best of my knowledge, what I described is the expected behaviour
for keyboard layouts that include dead keys. If you would have expected
something different, please describe it.

If this is not the result that you see, please describe what is different
about your system or how I can reproduce the problem.

Thanks,
smcv



Bug#1072846: asio breaks the widelands package on hurd-i386

2024-06-08 Thread Martin Quinson
Source: asio
Version: 1:1.28.1-0.2
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: debian-h...@lists.debian.org

Dear maintainers,

the latest version of widelands fails on the hurd-i386 architecture,
because of a syntax error in the /usr/include/asio/signal_set_base.hpp
system file. I don't think that widelands is involved in any way:


   from /<>/src/network/network.h:24,
   from /<>/src/network/nethost_interface.h:24,
   from /<>/src/network/gamehost.h:28,
   from /<>/src/wui/game_client_disconnected.cc:24:
/usr/include/asio/signal_set_base.hpp:65:21: error: ‘SA_NOCLDWAIT’ was not 
declared in this scope; did you mean ‘SA_NOCLDSTOP’?
   65 | no_child_wait = ASIO_OS_DEF(SA_NOCLDWAIT),
  | ^~~
make[3]: *** [src/wui/CMakeFiles/wui.dir/build.make:233: 
src/wui/CMakeFiles/wui.dir/game_client_disconnected.cc.o] Error 1
-

The full logs are here: 
https://buildd.debian.org/status/fetch.php?pkg=widelands=hurd-i386=2%3A1.2-2=1717876058=0

The hurd porters are in CC, because I must confess I have no idea
about how this should be fixed.

Thanks for your help,
Mt


signature.asc
Description: PGP signature


Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys doesn't type an À anymore

2024-06-08 Thread grunt2
‌My im-config shows:

Current configuration for the input method:
 * Default mode defined in /etc/default/im-config: 'auto'
 * Active configuration: 'missing' (normally missing)
 * Normal automatic choice: 'ibus' (normally ibus or fcitx5)
 * Override rule: 'zh_CN,fcitx5:zh_TW,fcitx5:zh_HK,fcitx5:zh_SG,fcitx5'
 * Current override choice: '' (Locale='fr_FR')
 * Current automatic choice: 'ibus'
 * Number of valid choices: 1 (normally 1)
 * Desktop environment: 'GNOME'
The configuration set by im-config is activated by re-starting the system.
La sélection explicite n'est pas nécessaire pour permettre la configuration 
automatique si la sélection active est default/auto/cjkv/missing.

I'm using an Azerty French Keyboard, where the backtick is the grave accent on 
the 7 key (Alt + 7) 
https://en.wikipedia.org/wiki/AZERTY#/media/File:KB_France.svg‌
(I call it the backtick, because it's also the character I type for markdown 
code formatting like `myObject.Fcn()`. But maybe I give it a bad name?)

Whatever, I'm sure that typing the ` under my 7 key followed by an A should 
return an À, like it once did, and that it doesn't do that anymore.
And I am also sure that it doesn't do that anymore since the bug that happened 
and affected the dead keys, and that its fix isn't complete.

Regards,
Marc Le Bihan
 

De : "Simon McVittie" 
A : "Marc Le Bihan" 
,1072...@bugs.debian.org,t...@security.debian.org
Envoyé: vendredi 7 Juin 2024 14:12
Objet : Re: Bug#1072720: libglib2.0-0: Following fix #1070745, typing `A keys 
doesn't type an À anymore
 
Control: tags -1 + moreinfo

On Fri, 07 Jun 2024 at 04:50:47 +0200, Marc Le Bihan wrote:
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> Typing the backtick followed by a wovel: `A
>
> * What was the outcome of this action?
> `A
>
> * What outcome did you expect instead?
> À

What desktop environment, what keyboard layout and what input method
are you using? And what application are you typing this into?

If your backtick key is really a backtick (like the key printed with `
in the British English keyboard layout) then `A is the expected result.

If your backtick key is a "dead key" grave accent (like the key printed
with ` in some other national and international keyboard layouts) then
À is the expected result.

Have you rebooted since upgrading libglib2.0-0 to version
2.74.6-2+deb12u2?

Are any warning messages logged in the systemd Journal, from either the
application you are using, or ibus?

Or if you run an affected application from a terminal (gnome-terminal
or xterm or similar), are any warning messages logged in that terminal?

smcv



Bug#1072842: rust-async-lock: please update to version 3.0+

2024-06-08 Thread weepingclown
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The issue tagged in #1071902 [0] (as well as the issue tagged in that one [1]) 
seems to be closed with the latest release, so this does not exactly seems like 
a blocker. If anything, doesn't this close #1071902 itself?

As for #1068929, while it brings the event-listener dependency, that alone does 
not bring async-lock 3.0 comaptibility as I ubderstand it. I'm fine with the 
merge of the bugs, but am failing to see how they are the same. In either case, 
there does no seem to be a blocker anymore if I understand the situation 
correctly.

Best,
Ananthu

[0] https://github.com/smol-rs/async-lock/issues/81
[1] https://github.com/smol-rs/event-listener/issues/123
-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuJxxBbmFudGh1IEMgViA8d2VlcGluZ2Nsb3duQGRpc3Jvb3Qub3Jn
PgUCZmTK0gAKCRDu7UeebOz3B4GUD/wNbu7V+WIf3Witx49DYiX5MXPncx1b0Le+
OvjA2qiU15DpxZA06MZFqQtgkyCxbL8qInE3K8YTfdwG3TcFOkZS10uuENpqlVDV
kunLZ/tVp0nAb7UpRDGUFBevo0wcXMvrXOUp7X5ruzlFl7sSa8kG5ONWsGmTABVT
rHCxzVsqL51RXzSnDZigO9DtY+rVwAHvHgDKG2VpqxhHLZ9hseq7kwYaT+at1to7
o4IuaAc+J+FP9nhs5y4tui8xYvTede7JvHqQJ35hvDS2EYNwbD1XVQ7nUC0L1Rm8
YJHQ8kx05Gfp76vVyIxOcOwIUKEvMX5YqH+yf0qLRjR0fpnXmVkiQMC1KiV4QOuS
B4RE8PQEW1y97T3/IIfl/sIeU0ME04TBtsTq91x075sUcERSYsrhRVPGm+FZ3USO
H9Y5hyc+J5nCB8jBA602b2rVNqqeKnmkCZyw0V8cJLMRhu6oxCSIdtpdT0T4juHB
aq8gIqe46qJZm38i/BG5BY47+s4LCN/+25wziK/xMYU5sCxWO2nN+qcyGmW+D5cV
jjR6SoHeTetSfTrxV3pDFxU43+O+U28piXpw/mSxuXWu+8PenJoBVal8skz9C5ME
swcSalEUkxA3xadNyWYz6gR5Ipk9syYaiFkK1J9AOL230R8u/ah9umzAmcJMoo3m
/nDYSBFS4A==
=b4br
-END PGP SIGNATURE-



Bug#1072845: Blank pages since upgrade to WebKitGTK 2.44

2024-06-08 Thread Dennis Camera
Package: epiphany-browser
Version: 43.1-1
Severity: important

Dear maintainer,

since upgrading libwebkit2gtk-4.1-0 from version 2.42.5 to 2.44.2 I'm
having difficulty browsing the web using Epiphany 43.1 on
Debian bookworm (12.5).
Most web pages (except for some very trivial ones) don't render and
only a white canvas is shown.

I attached the output of webkit://gpu at the end of this e-mail.

Other applications also using WebKitGTK (namely Evolution) are not
affected (on my system at least) and still display HTML e-mail correctly.

As a workaround setting the WEBKIT_DISABLE_DMABUF_RENDERER=1
environment variable restores the display of web pages in the Epiphany
browser.

Thank you for investigating.

Kind regards,

Dennis


{
"Version Information": {
"WebKit version": "WebKitGTK 2.44.2 (tarball)",
"Operating system": "Linux 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.90-1 (2024-05-03) x86_64",
"Desktop": "MATE",
"Cairo version": "1.16.0 (build) 1.16.0 (runtime)",
"GStreamer version": "1.22.0 (build) GStreamer 1.22.0 (runtime)",
"GTK version": "3.24.38 (build) 3.24.38 (runtime)"
},
"Display Information": {
"Identifier": "1",
"Type": "X11",
"Screen geometry": "0,0 1440x900",
"Screen work area": "0,24 1440x852",
"Depth": "24",
"Bits per color component": "8",
"Font Scaling DPI": "96.0244140625",
"Screen DPI": "110.48275454819004",
"VBlank type": "Timer",
"VBlank refresh rate": "60Hz",
"DRM Device": "/dev/dri/card0",
"DRM Render Node": "/dev/dri/renderD128"
},
"API": "OpenGL (libepoxy)",
"Hardware Acceleration Information": {
"Policy": "on demand",
"WebGL enabled": "Yes",
"Renderer": "DMABuf (Supported buffers: Hardware, Shared Memory)",
"Native interface": "None"
},
"Hardware Acceleration Information (Render process)": {
"Platform": "GBM",
"GL_RENDERER": "NVAC",
"GL_VENDOR": "nouveau",
"GL_VERSION": "OpenGL ES 3.0 Mesa 22.3.6",
"GL_SHADING_LANGUAGE_VERSION": "OpenGL ES GLSL ES 3.00",
"GL_EXTENSIONS": "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_s3tc
GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc
GL_EXT_texture_format_BGRA GL_OES_compressed_ETC1_RGB8_texture
GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap
GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives
GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float
GL_OES_texture_float_linear GL_OES_texture_half_float
GL_OES_texture_half_float_linear GL_OES_texture_npot
GL_OES_vertex_half_float GL_EXT_draw_instanced
GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_OES_depth_texture
GL_AMD_performance_monitor GL_OES_packed_depth_stencil
GL_EXT_texture_type_2_10_10_10_REV GL_NV_conditional_render
GL_OES_get_program_binary GL_APPLE_texture_max_level
GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_NV_pack_subimage
GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external
GL_OES_EGL_sync GL_OES_vertex_array_object
GL_ANGLE_pack_reverse_row_order GL_ANGLE_texture_compression_dxt3
GL_ANGLE_texture_compression_dxt5 GL_EXT_occlusion_query_boolean
GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers
GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil
GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range
GL_KHR_debug GL_KHR_texture_compression_astc_ldr
GL_NV_pixel_buffer_object GL_OES_depth_texture_cube_map
GL_OES_required_internalformat GL_OES_surfaceless_context
GL_EXT_color_buffer_float GL_EXT_debug_label GL_EXT_sRGB_write_control
GL_EXT_separate_shader_objects GL_EXT_shader_integer_mix
GL_EXT_base_instance GL_EXT_compressed_ETC1_RGB8_sub_texture
GL_EXT_copy_image GL_EXT_draw_elements_base_vertex
GL_EXT_polygon_offset_clamp GL_EXT_texture_border_clamp
GL_KHR_context_flush_control GL_NV_shader_noperspective_interpolation
GL_OES_copy_image GL_OES_draw_elements_base_vertex
GL_OES_texture_border_clamp GL_OES_texture_stencil8
GL_EXT_blend_func_extended GL_EXT_float_blend GL_EXT_texture_sRGB_R8
GL_EXT_texture_sRGB_RG8 GL_KHR_no_error
GL_KHR_texture_compression_astc_sliced_3d
GL_OES_EGL_image_external_essl3 GL_EXT_clip_cull_distance
GL_EXT_disjoint_timer_query GL_EXT_texture_compression_s3tc_srgb
GL_EXT_window_rectangles GL_MESA_shader_integer_functions
GL_EXT_clip_control GL_EXT_color_buffer_half_float
GL_EXT_texture_compression_bptc GL_EXT_texture_mirror_clamp_to_edge
GL_KHR_parallel_shader_compile GL_EXT_EGL_image_storage
GL_MESA_framebuffer_flip_y GL_EXT_depth_clamp GL_MESA_bgra ",
"EGL_VERSION": "1.4",
"EGL_VENDOR": "Mesa Project",
"EGL_EXTENSIONS": "EGL_EXT_device_base
EGL_EXT_device_enumeration EGL_EXT_device_query
EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses
EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_device

Bug#1072844: heimdal: Please build heimdal with openssl

2024-06-08 Thread Jarek Kamiński
Source: heimdal
Version: 7.8.git20221117.28daf24+dfsg-5
Severity: wishlist

Hi,

While trying to use PKINIT I've got the following error:
#v+
% kinit -D DIR:/etc/ssl/certs/ -C PKCS11:/usr/lib/x86_64-linux-gnu/libykcs11.so
PIN code for Yubico YubiKey OTP+FIDO+CCID 00 00:
kinit: krb5_get_init_creds: PKINIT: ECDH not supported
#v-

Looking at the source code, the error is printed when
HAVE_HCRYPTO_W_OPENSSL is not defined, which is the case because the
source code is configured --without-openssl. Changelog explains this was
introduced to fix #440443, but disabling OpenSSL is a bit unfortunate
solution to the FTBFS.

Could you consider building with OpenSSL support enabled? For the
record, PKINIT with RSA certificates works all right.


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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) (ignored: LC_ALL set to 
pl_PL), LANGUAGE=pl:en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
greetz(); // Jarek


signature.asc
Description: PGP signature


Bug#1072842: rust-async-lock: please update to version 3.0+

2024-06-08 Thread Jonas Smedegaard
Control: forcemerge -1 1068929

Quoting Ananthu C V (2024-06-08 21:52:38)
> I am trying to package async-dup and it requires version 3.1 of async-lock.
> I tried to build it with the current v2.8 but that seems to be failing. Since
> async-lock in debian is lagging behind the upstream version a bit, perhaps
> updating the package is the right solution for this. Several packages seems to
> depend on async-lock, so this might be a transition needing a bit of work.
> Can you try finding some time to work on this?

Sorry, but upgrading rust-async-lock is affected by bug#1071902 - I have
just now tagged that relationship as such.

Also, this issue has been already reported as bug#1068929 - merging
accordingly.

 - Jonas

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

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

signature.asc
Description: signature


Bug#1072813: release.debian.org: Help doris migrate to testing

2024-06-08 Thread Paul Gevers

Hi,

On 08-06-2024 11:17 a.m., Antonio Valentino wrote:
Could you please clarify if there is something on my side that I should 
do to allow doris to migrate?


You could bootstrap doris on other architectures too, such that it's not 
only available on amd64 and this check of the migration tooling wouldn't 
block the package. It's a hint you might have not thought about doing it.


If bootstrapping doris on non-amd64 isn't trivial, we can add a hint to 
ignore the installability on arm64.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1072843: poppler: stopped to build Qt6 lib on i386 without coordination with reverse dependencies

2024-06-08 Thread Sebastian Ramacher
Source: poppler
Version: 24.02.0-5
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

 poppler (24.02.0-5) unstable; urgency=medium
 .
   * Team upload
   * Stop building Qt6 library on i386


vs


dak rm -Rn -b libpoppler-qt6-3t64 libpoppler-qt6-dev  -a i386
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

libpoppler-qt6-3t64 |  24.02.0-4 | i386
libpoppler-qt6-dev |  24.02.0-4 | i386

Maintainer: Debian freedesktop.org maintainers 


--- Reason ---

--

Checking reverse dependencies...
# Broken Build-Depends:
photoqt: libpoppler-qt6-dev
qpdfview: libpoppler-qt6-dev
texworks: libpoppler-qt6-dev


This needs coordination with reverse dependencies.

The decision is also somewhat inconsistent. Why is support only dropped
on i386 and not the other 32 bit architectures?

Cheers
-- 
Sebastian Ramacher



Bug#1070972: epiphany-browser fails to render webpages - blank pages

2024-06-08 Thread Jeremy Bícha
On Sat, Jun 8, 2024 at 2:42 PM Dennis Camera
 wrote:
> I am seeing the same bug with Epiphany 43.1 on Debian bookworm (12.5)
> since upgrading libwebkit2gtk-4.1-0 from version 2.42.5 to 2.44.2.
>
> I attached the output of webkit://gpu at the end of this e-mail.

Thank you for the details. Please file a new bug for your issue even
though it might appear to be similar to an existing bug.

In your case, you are providing graphics details which can help if
this bug is specific to your graphics drivers. The original reporter
did not provide that information so it would be difficult to know
whether they are affected by a graphics driver bug.

More importantly, your issue is with Debian 12, but the original
report is about Debian Testing which has many differences compared to
Debian 12.

Thank you,
Jeremy Bícha



Bug#1072842: rust-async-lock: please update to version 3.0+

2024-06-08 Thread Ananthu C V
Source: rust-async-lock
Version: 2.6.0-4
Severity: wishlist

Hi,

I am trying to package async-dup and it requires version 3.1 of async-lock.
I tried to build it with the current v2.8 but that seems to be failing. Since
async-lock in debian is lagging behind the upstream version a bit, perhaps
updating the package is the right solution for this. Several packages seems to
depend on async-lock, so this might be a transition needing a bit of work.
Can you try finding some time to work on this?

Best,
Ananthu

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

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



Bug#1072226: RFS: serious-engine/0~git20230724+dfsg-1 [ITP]

2024-06-08 Thread Sébastien Noel
control: tags 1072226 - moreinfo

Le vendredi 31 mai 2024 à 10:11 +0200, Gianfranco Costamagna a écrit :
> control: tags -1 moreinfo
> 
> Hello, some copyright/licenses are missing
> 
> GPL-3+
> Sources/Ecc/Parser.cpp: GNU General Public License v3.0 or later
> Sources/Ecc/Parser.h: GNU General Public License v3.0 or later
> Sources/Ecc/Parser.hpp: GNU General Public License v3.0 or later
> 
> Sources/Engine/Base/Parser.cpp: GNU General Public License v3.0 or
> later
> Sources/Engine/Base/Parser.h: GNU General Public License v3.0 or
> later
> Sources/Engine/Base/Parser.hpp: GNU General Public License v3.0 or
> later
> 
> Sources/Engine/Ska/smcPars.cpp: GNU General Public License v3.0 or
> later
> Sources/Engine/Ska/smcPars.h: GNU General Public License v3.0 or
> later
> Sources/Engine/Ska/smcPars.hpp: GNU General Public License v3.0 or
> later

Hi,

i'm sorry but... all those files aren't present in the orig tarball !
They are generated during the build by Bison.

I will not add artefact generated by the build system to d/copyrigth,
that would be insane...

> GPL-2+
> Sources/Ecc/parser.h: GNU General Public License v2.0 or later
> Sources/Engine/Base/parser.h: GNU General Public License v2.0 or
> later
> 

those 2 were already fixed in the last upload in the 2023-05-28

br,
Sébastien


> And probably more
> 
> Please remove moreinfo tag once you address the above
> 
> Cheers
> 
> Gianfranco
> (a serious serious sam fan!)



Bug#1054393: Informational: stable/bookworm/12, ...: #1072035 Re: Bug#1054393: dns-root-data: New IPs for b.root-servers-net

2024-06-08 Thread Santiago Ruano Rincón
El 08/06/24 a las 01:53, Marco d'Itri escribió:
> On Jun 08, Santiago Ruano Rincón  wrote:
> 
> > > For oldstable bullseye 11 ...
> > > I'm not spotting it yet on:
> > > https://release.debian.org/proposed-updates/oldstable.html
> > > But presumably that will occur via #1072035, etc.
> It has been uploaded a few days ago, it only needs to be approved.

ACK. Thank you. And FTR, I will wait until the point update has been
published to upload to the older releases.

> > I will handle the update dns-root-data for buster LTS and the ELTS
> > releases. Is there any objection to push the changes to the dns-team
> > repository?
> I am not sure.
> Anyway, please do not push to the debian/bullseye and debian/bookworm 
> branches which are waiting to be pulled from my fork.

Ah sorry, I already push'ed to the debian/bookworm branch. I hope that
is not a huge problem.

And if keeping the LTS and ELTS branches in the dns-team repo is an
issue, don't worry, I will create a fork for them. No big deal.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature


Bug#1070972: epiphany-browser fails to render webpages - blank pages

2024-06-08 Thread Dennis Camera
Control: found 1070972 epiphany-browser/43.1-1

Hi,

I am seeing the same bug with Epiphany 43.1 on Debian bookworm (12.5)
since upgrading libwebkit2gtk-4.1-0 from version 2.42.5 to 2.44.2.

I attached the output of webkit://gpu at the end of this e-mail.

Other applications also using WebKitGTK (namely Evolution) are not
affected (on my system at least) and still display HTML e-mail correctly.

As a workaround setting the WEBKIT_DISABLE_DMABUF_RENDERER=1
environment variable restores the display of web pages in the Epiphany
browser.

Kind regards,

Dennis


{
"Version Information": {
"WebKit version": "WebKitGTK 2.44.2 (tarball)",
"Operating system": "Linux 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.90-1 (2024-05-03) x86_64",
"Desktop": "MATE",
"Cairo version": "1.16.0 (build) 1.16.0 (runtime)",
"GStreamer version": "1.22.0 (build) GStreamer 1.22.0 (runtime)",
"GTK version": "3.24.38 (build) 3.24.38 (runtime)"
},
"Display Information": {
"Identifier": "1",
"Type": "X11",
"Screen geometry": "0,0 1440x900",
"Screen work area": "0,24 1440x852",
"Depth": "24",
"Bits per color component": "8",
"Font Scaling DPI": "96.0244140625",
"Screen DPI": "110.48275454819004",
"VBlank type": "Timer",
"VBlank refresh rate": "60Hz",
"DRM Device": "/dev/dri/card0",
"DRM Render Node": "/dev/dri/renderD128"
},
"API": "OpenGL (libepoxy)",
"Hardware Acceleration Information": {
"Policy": "on demand",
"WebGL enabled": "Yes",
"Renderer": "DMABuf (Supported buffers: Hardware, Shared Memory)",
"Native interface": "None"
},
"Hardware Acceleration Information (Render process)": {
"Platform": "GBM",
"GL_RENDERER": "NVAC",
"GL_VENDOR": "nouveau",
"GL_VERSION": "OpenGL ES 3.0 Mesa 22.3.6",
"GL_SHADING_LANGUAGE_VERSION": "OpenGL ES GLSL ES 3.00",
"GL_EXTENSIONS": "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_s3tc
GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc
GL_EXT_texture_format_BGRA GL_OES_compressed_ETC1_RGB8_texture
GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap
GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives
GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float
GL_OES_texture_float_linear GL_OES_texture_half_float
GL_OES_texture_half_float_linear GL_OES_texture_npot
GL_OES_vertex_half_float GL_EXT_draw_instanced
GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_OES_depth_texture
GL_AMD_performance_monitor GL_OES_packed_depth_stencil
GL_EXT_texture_type_2_10_10_10_REV GL_NV_conditional_render
GL_OES_get_program_binary GL_APPLE_texture_max_level
GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_NV_pack_subimage
GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external
GL_OES_EGL_sync GL_OES_vertex_array_object
GL_ANGLE_pack_reverse_row_order GL_ANGLE_texture_compression_dxt3
GL_ANGLE_texture_compression_dxt5 GL_EXT_occlusion_query_boolean
GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers
GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil
GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range
GL_KHR_debug GL_KHR_texture_compression_astc_ldr
GL_NV_pixel_buffer_object GL_OES_depth_texture_cube_map
GL_OES_required_internalformat GL_OES_surfaceless_context
GL_EXT_color_buffer_float GL_EXT_debug_label GL_EXT_sRGB_write_control
GL_EXT_separate_shader_objects GL_EXT_shader_integer_mix
GL_EXT_base_instance GL_EXT_compressed_ETC1_RGB8_sub_texture
GL_EXT_copy_image GL_EXT_draw_elements_base_vertex
GL_EXT_polygon_offset_clamp GL_EXT_texture_border_clamp
GL_KHR_context_flush_control GL_NV_shader_noperspective_interpolation
GL_OES_copy_image GL_OES_draw_elements_base_vertex
GL_OES_texture_border_clamp GL_OES_texture_stencil8
GL_EXT_blend_func_extended GL_EXT_float_blend GL_EXT_texture_sRGB_R8
GL_EXT_texture_sRGB_RG8 GL_KHR_no_error
GL_KHR_texture_compression_astc_sliced_3d
GL_OES_EGL_image_external_essl3 GL_EXT_clip_cull_distance
GL_EXT_disjoint_timer_query GL_EXT_texture_compression_s3tc_srgb
GL_EXT_window_rectangles GL_MESA_shader_integer_functions
GL_EXT_clip_control GL_EXT_color_buffer_half_float
GL_EXT_texture_compression_bptc GL_EXT_texture_mirror_clamp_to_edge
GL_KHR_parallel_shader_compile GL_EXT_EGL_image_storage
GL_MESA_framebuffer_flip_y GL_EXT_depth_clamp GL_MESA_bgra ",
"EGL_VERSION": "1.4",
"EGL_VENDOR": "Mesa Project",
"EGL_EXTENSIONS": "EGL_EXT_device_base
EGL_EXT_device_enumeration EGL_EXT_device_query
EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses
EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_device
EGL_EXT_platform_wayland EGL_KHR_platform_wayland
EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_EXT_platform_xcb
EGL_MESA_platform_gbm EGL_KHR_platform_gbm

Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

2024-06-08 Thread Samuel Henrique
Hello Chris,

> > > Per Debian policy this is not the correct solution for naming conflicts. 
> > > Both
> > > maintainer (teams), please find a policy compliant solution together.
> >
> > The solution for this one seems correct, it's a Conflict + Replaces because
> > both packages provide a "sherlock" library. Am I missing something?
>
> Do both packages provide the same API? IOW: do they provide the same
> "type" of library?
> If so, then Conficts/Replaces may be appropriate.
>
> If they share a name but none of the API / features, then it is not
> a correct solution.

They do not share the same API.

> These descriptions do not sound related at all. In this case,
> Conflicts/Replaces is not appropriate.

I see your point now, it seems like it should be just "Conflicts", do you
agree? None of those 2 packages can/should be renamed.

Cheers,

--
Samuel Henrique 



Bug#1072841: sddm: Please start on VT1

2024-06-08 Thread Helge Kreutzmann
Package: sddm
Version: 0.21.0-1
Severity: wishlist

In Stable, sddm was not blocking VT2 etc. Now it blocks VT2 (VT1 is
blocked for some time by boot messages, unfortuantely). So the first
usable VT is VT3.

When I restart sddm after the crash (see #1072840), VT1 is used, so I 
can use VT 2 again for work.

I could not figure out where this is configured, the files in
/etc/sddm/ do not seem to govern it.

Kindly use VT1 by default.

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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sddm depends on:
ii  adduser 3.137
ii  debconf [debconf-2.0]   1.5.86
ii  libc6   2.38-12
ii  libgcc-s1   14-20240330-1
ii  libpam0g1.5.3-7
ii  libqt5core5t64  5.15.13+dfsg-2
ii  libqt5dbus5t64  5.15.13+dfsg-2
ii  libqt5gui5t64   5.15.13+dfsg-2
ii  libqt5network5t64   5.15.13+dfsg-2
ii  libqt5qml5  5.15.13+dfsg-2
ii  libqt5quick55.15.13+dfsg-2
ii  libstdc++6  14-20240330-1
ii  libsystemd0 256~rc3-7
ii  libxau6 1:1.0.9-1+b1
ii  libxcb-xkb1 1.17.0-2
ii  libxcb1 1.17.0-2
ii  qml-module-qtquick2 5.15.13+dfsg-2
ii  x11-common  1:7.7+23
ii  xauth   1:1.1.2-1
ii  xkb-data2.41-2
ii  xserver-xorg [xserver]  1:7.7+23

Versions of packages sddm recommends:
ii  libpam-systemd 256~rc3-7
ii  sddm-theme-breeze [sddm-theme] 4:5.27.11.1-1
ii  sddm-theme-debian-breeze [sddm-theme]  4:5.27.11.1-1

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.27.11-1
pn  qtvirtualkeyboard-plugin  

-- debconf information:
  sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: sddm

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature


Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

2024-06-08 Thread Chris Hofstaedtler
Hi Samuel,

only replying to your question below, with new questions.

* Samuel Henrique  [240608 14:04]:
> For #1072733:
> 
> Chris
> > Per Debian policy this is not the correct solution for naming conflicts. 
> > Both
> > maintainer (teams), please find a policy compliant solution together.
> 
> The solution for this one seems correct, it's a Conflict + Replaces because
> both packages provide a "sherlock" library. Am I missing something?

Do both packages provide the same API? IOW: do they provide the same
"type" of library?
If so, then Conficts/Replaces may be appropriate.

If they share a name but none of the API / features, then it is not
a correct solution. 

Looking at the package descriptions on tracker.d.o:

python-sherlock:
  distributed inter-process locks with a choice of backend

sherlock:
  Find usernames across social networks

These descriptions do not sound related at all. In this case,
Conflicts/Replaces is not appropriate.

Chris



Bug#1072839: rust-linemux: Upcoming rust-notify transition (5.x -> 6.x)

2024-06-08 Thread James McCoy
Source: rust-linemux
Version: 0.3.0-5
Severity: normal

rust-notify 6.x is in experimental. I plan on uploading it to unstable
soon. Upstream made a no-change bump to 6.x, so it looks like
debian/control just needs to be adjusted to accept a broader version
range.

https://github.com/jmagnuson/linemux/pull/68


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

Kernel: Linux 6.8.12-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



Bug#1072742: On Romanian translations in the iso-codes package

2024-06-08 Thread Dr. Tobias Quathamer

Am 07.06.24 um 13:08 schrieb Alex:

Hello,

I’d like to report an issue in the Romanian translations of the
iso-codes package. I’m not sure whether this is the right place. The
README says to open a Salsa issue but that requires authentication
and my account is yet to be approved. If this isn’t the place, please
instruct me on where to post as linux.debian.bugs.dist on Google
Groups seems to be read-only.

In any case, I want to report that the Romanian translations for the
ISO 3166-2 data have unnecessary prefixes indicating the type of the
subdivision (and sometimes suffixes too.) For example, “Alaska” is
translated as “Statul Alaska” (i.e. “The state of Alaska”); the
Romanian county of “Bacău” is translated as “Județul Bacău, România”
(i.e. “The county of Bacău, România”); “Thüringen” is translated to
"Landul Turingia, Germania” (i.e. “The land of Turingia, Germany")
etc. It goes on and on for virtually all subdivisions. On the one
hand, that’s not how Romanians refer to countries' subdivisions. For
example, I was born in "Onești, Bacău", not “Onești, Bacău County”.
Similarly, “Paris" is just “Paris”, not “Orașul metropolitan Paris
(capitala), Franța” (i.e. “Metropolitan city of Paris (capital),
France”). On the other hand, it looks like it's only the Romanian
translation that does this, making it very odd in comparison. To add
to the weirdness, the Zimbabwean province of "Matabeleland South” is
translated as "Provincia Matabeleland South”, not even “Provincia
Matabeleland Sud”, though "South Australia” is fully translated to
"Statul Australia de sud”.

I can and am willing to invest some time in reviewing and cleaning up
at least some of the translations. Considering there’s many of them,
it would take a while to cover all of them, though. There is of
course the question of whether the Debian team is willing to consider
accepting such changes.

Regards, Alex


Hi Alex,

thanks so much for your bug report! I'm not speaking Romanian, so I 
cannot judge the quality of the Romanian translation. However, what 
you've written seems plausible to me, and I can at least infer from your 
examples that what you're writing is correct.


All those translations have come from Weblate, where the iso-codes 
translation is hosted. The changes (adding those prefixes) have been 
done by a translator named Remus-Gabriel Chelu, I've added them in CC of 
this mail.


Remus-Gabriel, would you be so kind to join this discussion on the 
Debian BTS and share your point of view? You can just reply to this 
mail, keeping all addresses in the loop. Many thanks in advance!


The bug report can be seen here: https://bugs.debian.org/1072742

Regards,
Tobias


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1072801: ITP: lsix -- Show thumbnails in terminal using sixel graphics

2024-06-08 Thread Blair Noctis
On Sat, 08 Jun 2024 12:15:48 +0100
Richard Lewis  wrote:

> Blair Noctis  writes:
> 
> > Package: wnpp
> > Severity: wishlist
> > Owner: Blair Noctis 
> > X-Debbugs-Cc: debian-de...@lists.debian.org, n...@sail.ng
> >
> > * Package name: lsix
> >   Version : 1.8.2
> >   Upstream Contact: b9 
> > * URL : https://github.com/hackerb9/lsix
> > * License : GPL-3
> >   Programming Lang: Shell
> >   Description : Show thumbnails in terminal using sixel graphics
> >
> > Like "ls", but for images.  
> 
> But ls works fine on images do you (and upsteam) mean "like 'cat'
> but for images?"
> 
> Some of the "features" look like implementation details so you might
> want to consider from a users' pov

Yes, ls works "fine" on images, in that it lists *file names* of them. OTOH,
this tool works like a GUI file manager, listing their *thumbnails*. There are
other tools like "cat" for images, e.g. viu, which shows them in "full" size.

-- 
Sdrager,
Blair Noctis


pgpKP8huHlVww.pgp
Description: OpenPGP digital signature


Bug#1072838: Blueman : double icon in systray bar of Gnome

2024-06-08 Thread Mon Compte
Package: blueman
Version: 2.1.4-1+b1
Severity: normal

Dear Maintainer,

This issue occurs randomly. After login as user, sometimes the blueman icon
appears in double in the top bar of Gnome.
Blueman works well trough.
In the plugin menu of Blueman, when I desactivate the Appindicator plugin, one
icon disappear, the other remains. When I activate again the Appindicator
plugin, the second icon appears again.
There seems to be a conflict between the way Gnome manages the systray icons
and the way Blueman manages its own icon : one seems to not listen to the other.
Can you solve this bug?
Thank you in advance

-- System Information:
Debian Release: 11.9
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500,
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-28-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages blueman depends on:
ii adwaita-icon-theme 3.38.0-1
ii bluez 5.55-3.1+deb11u1
ii bluez-obexd 5.55-3.1+deb11u1
ii dbus 1.12.28-0+deb11u1
ii dbus-user-session [default-dbus-session-bus] 1.12.28-0+deb11u1
ii dbus-x11 [dbus-session-bus] 1.12.28-0+deb11u1
ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2
ii gir1.2-ayatanaappindicator3-0.1 0.5.5-2+deb11u2
ii gir1.2-gdkpixbuf-2.0 2.42.2+dfsg-1+deb11u1
ii gir1.2-glib-2.0 1.66.1-1+b1
ii gir1.2-gtk-3.0 3.24.24-4+deb11u3
ii gir1.2-nm-1.0 1.30.6-1+deb11u1
ii gir1.2-pango-1.0 1.46.2-3
ii gnome-shell [notification-daemon] 3.38.6-1~deb11u1
ii libbluetooth3 5.55-3.1+deb11u1
ii libc6 2.31-13+deb11u8
ii libglib2.0-0 2.66.8-1+deb11u1
ii libpulse-mainloop-glib0 14.2-2
ii librsvg2-common 2.50.3+dfsg-1+deb11u1
ii notification-daemon 3.20.0-4
ii policykit-1 0.105-31+deb11u1
ii python3 3.9.2-3
ii python3-cairo 1.16.2-4+b2
ii python3-gi 3.38.0-2
ii python3-gi-cairo 3.38.0-2
Versions of packages blueman recommends:
ii pulseaudio-module-bluetooth 14.2-2
blueman suggests no packages.



Bug#1072837: List::Compare.3pm: some remarks and editorial changes for this man page

2024-06-08 Thread Bjarni Ingi Gislason
Package: liblist-compare-perl
Version: 0.55-2
Severity: minor
Tags: patch

Dear Maintainer,

   * What led up to the situation?

 Checking for defects with

[test-]groff -mandoc -t -K utf8 -ww -b -z 

  [test-groff is a script in the repository for "groff"]

   * What was the outcome of this action?

troff: backtrace: file '':1516
troff::1516: warning: [page 17, 8.5i]: cannot break line

   * What outcome did you expect instead?

 No output (warnings).

-.-

  The concerned man page was autogenerated.

  Remarks and a patch are in the attachments.


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

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages liblist-compare-perl depends on:
ii  perl  5.38.2-5

liblist-compare-perl recommends no packages.

liblist-compare-perl suggests no packages.

-- no debconf information
  Any program (person), that produces man pages, should check its content for
defects by using

groff -mandoc -t -ww -b -z [ -K utf8 | k ] 

  The same goes for man pages that are used as an input.

  For a style guide use

  mandoc -T lint

-.-

  So any generator should check its products with the above mentioned
'groff' and additionally with 'nroff ...'.

  This is just a simple quality control measure.

  The generator may have to be corrected to get a better man page,
the source file may, and any additional file may.

-.-

The difference between the formatted outputs can be seen with:

  nroff -mandoc  > 
  nroff -mandoc  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -mandoc -Z - "

instead of "nroff -mandoc"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint List::Compare.3pm": (possibly shortened list)

mandoc: List::Compare.3pm:1005:99: STYLE: input text line longer than 80 bytes: 
unsorted option (\f(...
mandoc: List::Compare.3pm:1006:99: STYLE: input text line longer than 80 bytes: 
(\f(CW\*(Aq\-a\*(Aq\...
mandoc: List::Compare.3pm:1041:108: STYLE: input text line longer than 80 
bytes: optionally takes suc...
mandoc: List::Compare.3pm:1042:93: STYLE: input text line longer than 80 bytes: 
are skipped, \f(CW@a...
mandoc: List::Compare.3pm:1137:107: STYLE: input text line longer than 80 
bytes: more lists, you can ...
mandoc: List::Compare.3pm:1155:109: STYLE: input text line longer than 80 
bytes: If you do not need s...
mandoc: List::Compare.3pm:1208:87: STYLE: input text line longer than 80 bytes: 
Except for List::Com...
mandoc: List::Compare.3pm:1216:96: STYLE: input text line longer than 80 bytes: 
you use \f(CW\*(C`Li...
mandoc: List::Compare.3pm:1243:82: STYLE: input text line longer than 80 bytes: 
result from a \fIsin...
mandoc: List::Compare.3pm:1249:86: STYLE: input text line longer than 80 bytes: 
The user selects thi...
mandoc: List::Compare.3pm:1280:108: STYLE: input text line longer than 80 
bytes: list (for \f(CW\*(C`...
mandoc: List::Compare.3pm:1284:103: STYLE: input text line longer than 80 
bytes: new methods \f(CW\*(...
mandoc: List::Compare.3pm:1302:82: STYLE: input text line longer than 80 bytes: 
returned are, by def...
mandoc: List::Compare.3pm:1308:101: STYLE: input text line longer than 80 
bytes: option.  This is don...
mandoc: List::Compare.3pm:1315:98: STYLE: input text line longer than 80 bytes: 
(\f(CW\*(Aq\-u\*(Aq\...
mandoc: List::Compare.3pm:1329:88: STYLE: input text line longer than 80 bytes: 
Similarly, the metho...
mandoc: List::Compare.3pm:1340:123: STYLE: input text line longer than 80 
bytes: use of methods such ...
mandoc: List::Compare.3pm:1341:82: STYLE: input text line longer than 80 bytes: 
aliases for \f(CW\*(...
mandoc: List::Compare.3pm:1386:81: STYLE: input text line longer than 80 bytes: 
test suite which tes...
mandoc: List::Compare.3pm:1388:84: STYLE: input text line longer than 80 bytes: 
Should you still nee...
mandoc: List::Compare.3pm:1405:102: STYLE: input text line longer than 80 
bytes: passing \f(CW\*(Aq\-...
mandoc: List::Compare.3pm:1411:85: STYLE: input text line longer than 80 bytes: 
the module's templat...
mandoc: List::Compare.3pm:1477:83: STYLE: input text line longer than 80 bytes: 
discussed the perfor...
mandoc: List::Compare.3pm:1484:83: STYLE: input text line longer than 80 bytes: 
An April 2004 offer ...
mandoc: List::Compare.3pm:1497:84: STYLE: input text line longer than 80 

Bug#1072757: ffmpeg 5.1.4 (Debian/Bookworm) fails on HLS/fMP4 streams

2024-06-08 Thread Sebastian Ramacher
Control: found -1 5.1.4-0+deb12u1
Control: notfound -1 5.1.4-0
Control: tags -1 moreinfo

On 2024-06-07 15:03:56 +, debian-b...@kosowsky.org wrote:
> Package: ffmpeg
> Version: 5.1.4-0
> Release: Bookworm
> 
> ffmpeg terminates (without error) after a couple of frames when trying
> to download, copy or transcode an HLS/fMP4 stream.
> HOWEVER, the same ffmpeg command lines work fine on HLS/TS streams.
> 
> I am generating the streams using the program `go2rtc` on an RPi5
> 
> Note that the problem seems to be *specific* to Debian Bookworm.
> 
> Specifically the same HLS/fMP4 stream and ffmeg command lines:
>   - Fail on:
>  x86/Debian/Bookworm - ffmpeg 5.1.4
>  RPi5/Bookworm - ffmpeg 5.1.4
> 
>   - Succeed on:
>  RPi4/Buster - ffmpeg 4.1.11
>  x86/Debian/Bullseye - ffmpeg 4.3.6
>  x86/Debian/Trixie - ffmpeg 6.1.1
> 
>  x86/Ubuntu 18.04 - ffmpeg 3.4.11
>  x86/Ubuntu 22:04 - ffmpeg 4.4.2
>  x86/Ubuntu 24:04 - ffmpeg 6.1.1
>  Win11/Cygwin - ffmpeg 4.0.2
> 
> i.e., versions (on multiple platforms) before and after 5.1.4 succeed.
> 
> Using even this simple line fails where the stream is HLS/fMP4
> # ffmpeg -re -i "http://mypi:1984/api/stream.m3u8?src=picam_h264; 
> output.m3u8
> But succeeds when the stream is HLS/TS
> # ffmpeg -re -i "http://mypi:1984/api/stream.m3u8?src=picam_h264; output.m3u8
> 
> Any ideas on what is "special" about Bookworm/ffmpeg-5.1.4 that fails
> but just about any other version seems to succeed

Without a test stream to check, no. We'd need someway to reproduce the
issue.

Cheers
-- 
Sebastian Ramacher



Bug#1072836: Switch to an active upstream

2024-06-08 Thread Sean Anderson

Package: libnginx-mod-http-cache-purge
Version: 1:2.3-4

The current upstream for ngx_cache_purge [1] is defunct, with no updates
for 10 years (despite multiple outstanding PRs fixing bugs). Please
switch to the nginx-modules upstream [2] which has fixed bugs and added
features (such as wildcards). This upstream is also used by Arch
Linux [3].

[1] https://github.com/FRiCKLE/ngx_cache_purge
[2] https://github.com/nginx-modules/ngx_cache_purge
[3] https://archlinux.org/packages/extra/x86_64/nginx-mod-cache_purge/



Bug#1072835: jpeg-xl: Failing autopkgtests

2024-06-08 Thread Jeremy Bícha
Source: jpeg-xl
Version: 0.9.2-5
Severity: serious
Tags: experimental

jpeg-xl in experimental has failing autopkgtests.

https://release.debian.org/britney/pseudo-excuses-experimental.html#jpeg-xl

https://ci.debian.net/packages/j/jpeg-xl/unstable/amd64/

autopkgtest log excerpt
==
md5sum: traffic_light-0-ec0.ppm: No such file or directory
traffic_light-0-ec0.ppm: FAILED open or read
traffic_light-0-ec1.pgm: FAILED open or read
md5sum: traffic_light-0-ec1.pgm: No such file or directory
md5sum: traffic_light-1-ec0.ppm: No such file or directory
traffic_light-1-ec0.ppm: FAILED open or read
md5sum: traffic_light-1-ec1.pgm: No such file or directory
traffic_light-1-ec1.pgm: FAILED open or read
md5sum: traffic_light-2-ec0.ppm: No such file or directory
traffic_light-2-ec0.ppm: FAILED open or read
md5sum: traffic_light-2-ec1.pgm: No such file or directory
traffic_light-2-ec1.pgm: FAILED open or read
md5sum: traffic_light-3-ec0.ppm: No such file or directory
traffic_light-3-ec0.ppm: FAILED open or read
md5sum: traffic_light-3-ec1.pgm: No such file or directory
traffic_light-3-ec1.pgm: FAILED open or read
md5sum: animation_patches-0-ec0.ppm: No such file or directory
animation_patches-0-ec0.ppm: FAILED open or read
md5sum: animation_patches-0-ec1.pgm: No such file or directory
animation_patches-0-ec1.pgm: FAILED open or read
md5sum: animation_patches-1-ec0.ppm: No such file or directory
animation_patches-1-ec0.ppm: FAILED open or read
md5sum: animation_patches-1-ec1.pgm: No such file or directory
animation_patches-1-ec1.pgm: FAILED open or read
pq_gradient.pgm: OK
md5sum: WARNING: 12 listed files could not be read

Thank you,
Jeremy Bícha



Bug#1063645: markdown: missing required debian/rules targets build-arch and/or build-indep

2024-06-08 Thread Bastian Germann

If you think about fixing this to keep a reverse dependency in Debian:
Please consider porting the reverse dep to some other markdown implementation 
that is still maintained.



Bug#1069089: ruby-rubygems: Broken platform detection which lead to unability to install sass-embedded

2024-06-08 Thread Ralf Jung

Hi,

I think I am hitting a similar issue -- trying to install a bundle that contains 
the "ffi" gem leads to an error:


Bundler::HTTPError: Could not download gem from https://rubygems.org/ due to 
underlying error (https://rubygems.org/gems/ffi-1.17.0-x86_64-linux.gem)>


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/rubygems_integration.rb:497:in 
`rescue in download_gem'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/rubygems_integration.rb:469:in 
`download_gem'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/source/rubygems.rb:481:in 
`download_gem'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/source/rubygems.rb:443:in 
`fetch_gem'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/source/rubygems.rb:427:in 
`fetch_gem_if_possible'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/source/rubygems.rb:161:in 
`install'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/installer/gem_installer.rb:54:in 
`install'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/installer/gem_installer.rb:16:in 
`install_from_spec'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/installer/parallel_installer.rb:156:in 
`do_install'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/installer/parallel_installer.rb:147:in 
`block in worker_pool'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/worker.rb:62:in 
`apply_func'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/worker.rb:57:in 
`block in process_queue'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/worker.rb:54:in 
`loop'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/worker.rb:54:in 
`process_queue'


/usr/share/rubygems-integration/all/gems/bundler-2.4.20/lib/bundler/worker.rb:90:in 
`block (2 levels) in create_threads'


Indeed the file https://rubygems.org/gems/ffi-1.17.0-x86_64-linux.gem does not 
exist. The correct filename seems to be 
https://rubygems.org/gems/ffi-1.17.0-x86_64-linux-gnu.gem. I don't know anything 
about Ruby, gem, or bundler so I am quite stuck here, and unable to execute 
Jekyll unfortunately.


Kind regards,
Ralf



Bug#1069089: ruby-rubygems: Broken platform detection which lead to unability to install sass-embedded

2024-06-08 Thread Ralf Jung

Hi again,

Turns out I can fix things by manually editing 
/usr/lib/ruby/vendor_ruby/rubygems/platform.rb, and un-doing the patch mentioned 
at .
But that's obviously quite the hack; would be nice if the faulty patch could be 
removed from the Debian package so that one can use bundler again.


Kind regards,
Ralf



Bug#1069052: gertty: FTBFS with SQLAlchemy 2.x

2024-06-08 Thread Santiago Vila

tags 1069052 + ftbfs
retitle 1069052 gertty: FTBFS with SQLAlchemy 2.x
severity 1069052 serious
thanks

Hello. This is what happens currently when trying to build the package in 
unstable:

==
ERROR: gertty.search (unittest.loader._FailedTest.gertty.search)
--
ImportError: Failed to import test module: gertty.search
Traceback (most recent call last):
  File "/usr/lib/python3.11/unittest/loader.py", line 452, in _find_test_path
package = self._get_module_from_name(name)
  
  File "/usr/lib/python3.11/unittest/loader.py", line 362, in 
_get_module_from_name
__import__(name)
  File 
"/<>/.pybuild/cpython3_3.11_gertty/build/gertty/search/__init__.py", 
line 18, in 
from gertty.search import tokenizer, parser
  File 
"/<>/.pybuild/cpython3_3.11_gertty/build/gertty/search/parser.py", line 
21, in 
import gertty.db
  File "/<>/.pybuild/cpython3_3.11_gertty/build/gertty/db.py", line 615, 
in 
mapper(Account, account_table)
  File "/usr/lib/python3/dist-packages/sqlalchemy/orm/_orm_constructors.py", 
line 1982, in _mapper_fn
raise InvalidRequestError(
sqlalchemy.exc.InvalidRequestError: The 'sqlalchemy.orm.mapper()' function is 
removed as of SQLAlchemy 2.0.  Use the '
sqlalchemy.orm.registry.map_imperatively()` method of the 
``sqlalchemy.orm.registry`` class to perform classical mappi
ng.



Bug#1072732: update-shells: duplicates entries when a package includes both aliased and canonical shells

2024-06-08 Thread Johannes Schauer Marin Rodrigues
Hi,

On Sat, 8 Jun 2024 18:10:04 +0200 Helmut Grohne  wrote:
> On Fri, Jun 07, 2024 at 10:09:04AM +0200, Helmut Grohne wrote:
> > My recent bash upload changes it's shells.d snippet to include both
> > aliased and canonical shells, which is right in principle, but it causes
> > update-shells to duplicate /usr/bin/bash in /etc/shells. While that's
> > not breaking anything yet, it's also not nice and kudos to Johannes for
> > spotting it.
> > 
> > It also is easy to fix with the attached patch. Would you kindly apply
> > it?
> 
> I fear this aspect currently breaks mmdebstrap's autopkgtests, so this
> is an rc bug somewhere. While it isn't technically rc for debianutils, I
> hope that the simplest way forward is to just upload debianutils. If you
> disagree with this assessment, we'll have to adapt mmdebstrap's
> autopkgtests until this bug is fixed, which also works, but is kinda
> meh. So I am tentatively raising it to rc severity for debianutils
> hoping that you agree and let you downgrade in case you disagree. Thanks for
> considering.

please CC me on the decision, so that I know how I should upload the next
version of mmdebstrap. :)

Thanks!

cheers, josch

signature.asc
Description: signature


Bug#1072732: update-shells: duplicates entries when a package includes both aliased and canonical shells

2024-06-08 Thread Helmut Grohne
Control: severity -1 serious
Control: affects -1 + mmdebstrap

On Fri, Jun 07, 2024 at 10:09:04AM +0200, Helmut Grohne wrote:
> My recent bash upload changes it's shells.d snippet to include both
> aliased and canonical shells, which is right in principle, but it causes
> update-shells to duplicate /usr/bin/bash in /etc/shells. While that's
> not breaking anything yet, it's also not nice and kudos to Johannes for
> spotting it.
> 
> It also is easy to fix with the attached patch. Would you kindly apply
> it?

I fear this aspect currently breaks mmdebstrap's autopkgtests, so this
is an rc bug somewhere. While it isn't technically rc for debianutils, I
hope that the simplest way forward is to just upload debianutils. If you
disagree with this assessment, we'll have to adapt mmdebstrap's
autopkgtests until this bug is fixed, which also works, but is kinda
meh. So I am tentatively raising it to rc severity for debianutils
hoping that you agree and let you downgrade in case you disagree. Thanks
for considering.

I'm also happy to NMU debianutils if you're short on time and agree with
me doing it.

Helmut



Bug#1072241: src:manpages: fails to migrate to testing for too long: RC bug and B-D not in testing

2024-06-08 Thread Dr. Tobias Quathamer

Am 31.05.24 um 10:32 schrieb Dr. Tobias Quathamer:
I couldn't find any explanation in the commit messages or 
debian/changelog. What's the reason for all those additional 
dependencies? Can't we get rid of them? I don't see how they are needed 
for building the package.


I did not get a response, so I went ahead and uploaded a version without 
all those extra Build-Dependencies.


Regards,
Tobias



OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1072834: between: Game no longer works due to server error

2024-06-08 Thread James Valleroy

Package: between
Version: 6+dfsg1-4
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: jvalle...@mailbox.org

Dear Maintainer,

   * What led up to the situation?

I installed between and tried to run it.

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


Run the "between" program.

   * What was the outcome of this action?

The following is printed in the terminal:

Screen dimensions for fullscreen mode:  640x480
L4 | Sat Jun  8 11:19:18 2024 (506 ms) | general | Checking if requested 
video mode (640x480) is available

L4 | Sat Jun  8 11:19:18 2024 (506 ms) | general | All resolutions available
Max note length in song = 16
Response:  
301 Moved Permanently

301 Moved Permanently
cloudflare



The game window opens and shows the title screen. When I press spacebar, 
it shows "Locating server..." for a second, and then shows the message 
"ERROR: Badly formatted response from server." (see attachment). There 
is no way to continue after this point, except to close the window.


   * What outcome did you expect instead?

The game would be playable. It seems to depend on a server that no 
longer exists.



-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable'), (100, 
'bookworm-fasttrack')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages between depends on:
ii  libc6   2.36-9+deb12u7
ii  libgcc-s1   12.2.0-14
ii  libgl1  1.6.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  libsdl1.2debian 1.2.15+dfsg2-8
ii  libstdc++6  12.2.0-14

between recommends no packages.

between suggests no packages.

-- no debconf information


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1072833: python-cmarkgfm: Please package the new upstream release 2024+

2024-06-08 Thread Boyuan Yang
Source: python-cmarkgfm
Version: 0.8.0-3
Severity: important
X-Debbugs-CC: ol...@debian.org

Dear Debian python-cmarkgfm package maintainer,

A new upstream release of your package 2024.1.14 is available. Besides, the 
current
packaged version is vulnerable to multiple CVEs. Please consider preparing a new
packaged version soon.

Thanks,
Boyuan Yang


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


Bug#1072832: qt5-doc: No manpage available.

2024-06-08 Thread Nathan Teodosio
Package: qt5-doc
Version: 5.15.13-2
Severity: important
X-Debbugs-Cc: nathan.teodo...@canonical.com

Dear Maintainer,

apt show qt5-doc says:

> The documentation is provided in the Qt's help format and manpage format;

However no manpage is installed.

--->
% dpkg -L qt5-doc
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/qt5-doc
/usr/share/doc/qt5-doc/changelog.Debian.gz
/usr/share/doc/qt5-doc/copyright
/usr/share/qt5
/usr/share/qt5/doc
/usr/share/qt5/doc/qtcmake.qch
/usr/share/qt5/doc/qtdoc.qch
<---

Please rectify the package description or include manpages in the package.



Bug#1072831: getting memory info fails when running under lxc

2024-06-08 Thread Paul Slootman
Package: procps
Version: 2:4.0.2-3
Severity: normal

I am running a number of virtual systems under lxc via libvirt.
This means these systems share the host kernel (not like qemu where a
whole virtual machine is emulated).

I upgraded one to bookworm today, and when running 'ps faxu' or 'free'
I get an error: Unable to create meminfo structure

I downgraded procps to 2:3.3.17-5 (including libprocps8 2:3.3.17-5)
and then it worked again.

Working 'free' output:

# free
   totalusedfree  shared  buff/cache   available
Mem: 2097152   64600 19323529028  100200 1932352
Swap:   10338296  795392 9542904


Not working 'free' output:

# free
free: Unable to create meminfo structure


Contents of /proc/meminfo :
MemTotal:2097152 kB
MemFree: 1930792 kB
MemAvailable:1930792 kB
Buffers:   0 kB
Cached:   100672 kB
SwapCached:60812 kB
Active:   119140 kB
Inactive:  38800 kB
Active(anon):  64480 kB
Inactive(anon):   84 kB
Active(file):  54660 kB
Inactive(file):38716 kB
Unevictable: 660 kB
Mlocked:   43200 kB
SwapTotal:  10338296 kB
SwapFree:9542904 kB
Zswap: 0 kB
Zswapped:  0 kB
Dirty:   344 kB
Writeback: 0 kB
AnonPages:   3726656 kB
Mapped:   455856 kB
Shmem:  9028 kB
KReclaimable: 142356 kB
Slab:  0 kB
SReclaimable:  0 kB
SUnreclaim:0 kB
KernelStack:8576 kB
PageTables:19560 kB
SecPageTables:48 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:14295376 kB
Committed_AS:7452164 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   42352 kB
VmallocChunk:  0 kB
Percpu: 3216 kB
HardwareCorrupted: 0 kB
AnonHugePages:   3117056 kB
ShmemHugePages:0 kB
ShmemPmdMapped:0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
Hugetlb:   0 kB
DirectMap4k:  179704 kB
DirectMap2M: 6940672 kB
DirectMap1G: 3145728 kB


I'm willing to help debug on my system if needed.

Thanks,
Paul

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 procps depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u4
ii  libncursesw6 6.4-4
ii  libproc2-0   2:4.0.2-3
ii  libtinfo66.4-4

Versions of packages procps recommends:
ii  psmisc  23.6-1

procps suggests no packages.

-- no debconf information



Bug#1036630: procps: unowned /usr/bin/ps on filesystem after upgrade to bookworm

2024-06-08 Thread Paul Slootman
On Tue, 23 May 2023 09:06:31 -0500 C Seys  wrote:

> After upgrading to bookworm there is an unowned /usr/bin/ps on the filesystem:
> 
> # dpkg -S /usr/bin/ps
> dpkg-query: no path found matching pattern /usr/bin/ps
> 
> There is also /bin/ps owned by procps:
> 
> # dpkg -S /bin/ps
> procps: /bin/ps

I suspect that /bin is now a symlink to /usr/bin .
So the /usr/bin/ps you see was installed as /bin/ps


Regards,
Paul



Bug#1071260: prometheus-postgres-exporter: pg_replication_slots metrics query fails on standbys with replication slots

2024-06-08 Thread Daniel Swarbrick
No sooner than I had posted my previous reply, I discovered that there 
is in fact already an upstream PR for the aforementioned #547 [1]; 
unsurprisingly #548 [2] claims to fix it, but has been awaiting approval 
since 2021 :(


Perhaps you could give that PR a nudge, and perhaps it also makes sense 
if we simply cherry-pick that as the Debian patch.


[1]: https://github.com/prometheus-community/postgres_exporter/issues/547
[2]: https://github.com/prometheus-community/postgres_exporter/pull/548


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false

2024-06-08 Thread Peter De Wachter
Hi Andreas,

Those locations work. But the correct environment variable turns out to be
SYSTEMD_SLEEP_FREEZE_USER_SESSIONS (plural), the NEWS file has it wrong.
(I've no idea why suspend seemed to work for me yesterday with the wrong
variable. Today it definitely didn't.) The overrides probably also need to
be installed for the other service files that run systemd-sleep:
systemd-hybrid-sleep.service, systemd-hibernate.service and
systemd-suspend-then-hibernate.service.

On Fri, Jun 7, 2024 at 10:05 PM Luca Boccassi  wrote:

> On Fri, 7 Jun 2024 at 21:03, Andreas Beckmann  wrote:
> >
> > On 07/06/2024 08.17, Peter De Wachter wrote:
> > > systemd 256-rc3 was recently uploaded to Debian. Its NEWS file
> mentions:
> > >
> > >  * The behavior of systemd-sleep and systemd-homed has been
> updated to
> > >freeze user sessions when entering the various sleep modes
> or when
> > >locking a homed-managed home area. This is known to cause
> issues with
> > >the proprietary NVIDIA drivers. Packagers of the NVIDIA
> proprietary
> > >drivers may want to add drop-in configuration files that set
> > >SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for
> systemd-suspend.service
> > >and related services, and
> SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for
> > >systemd-homed.service.
> >
> > Thanks for catching that. I'll try to include a fix with the upcoming
> > uploads of the recent CVE series.
> >
> > As I'm not that familiar with configuring systemd bits, do you know what
> > would be the correct locations and contents to ship the fix?
> >
> > If I read the documentation correctly, that should be
> >
> > /usr/lib/systemd/system/systemd-suspend.service.d/nvidia.conf
> > = 8< =
> > [Service]
> > Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSION=false"
> > = >8 =
> >
> > and
> >
> > /usr/lib/systemd/system/systemd-homed.service.d/nvidia.conf
> > = 8< =
> > [Service]
> > Environment="SYSTEMD_HOME_LOCK_FREEZE_SESSION=false"
> > = >8 =
> >
> > Could you verify that this works (after unapplying your temporary
> solution)?
>
> Hi Andreas, I can confirm those are the correct locations. You can
> also omit the quotes.
>


Bug#1072830: IO::Compress::FAQ.3perl: some remarks and editorial changes for this man page

2024-06-08 Thread Bjarni Ingi Gislason
Package: perl-doc
Version: 5.38.2-5
Severity: minor
Tags: patch

Dear Maintainer,

   * What led up to the situation?

 Checking for defects with

[test-][g|n]roff -mandoc -t -K utf8 -ww -b -z 

  [test-groff is a script in the repository for "groff"]

   * What was the outcome of this action?

troff: backtrace: file '':375
troff::375: warning: [page 4, 6.0i]: cannot break line


   * What outcome did you expect instead?

 No output (warnings).

-.-

  Remarks and a patch are in the attachments.



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

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages perl-doc depends on:
ii  perl  5.38.2-5

perl-doc recommends no packages.

Versions of packages perl-doc suggests:
ii  groff-base1.23.0-4
ii  man-db [man-browser]  2.12.1-1

-- no debconf information
  Any program (person), that produces man pages, should check its content for
defects by using

groff -mandoc -t -ww -b -z [ -K utf8 | k ] 

  The same goes for man pages that are used as an input.

  For a style guide use

  mandoc -T lint

-.-

  So any generator should check its products with the above mentioned
'groff' and additionally with 'nroff ...'.

  This is just a simple quality control measure.

  The generator may have to be corrected to get a better man page,
the source file may, and any additional file may.

-.-

The difference between the formatted outputs can be seen with:

  nroff -mandoc  > 
  nroff -mandoc  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -mandoc -Z - "

instead of "nroff -mandoc"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint IO::Compress::FAQ.3perl": (possibly shortened list)

mandoc: IO::Compress::FAQ.3perl:108:102: STYLE: input text line longer than 80 
bytes: The \f(CW\*(C`Archiv...
mandoc: IO::Compress::FAQ.3perl:111:84: STYLE: input text line longer than 80 
bytes: utility cannot be re...
mandoc: IO::Compress::FAQ.3perl:114:103: STYLE: input text line longer than 80 
bytes: If the \f(CW\*(C`unc...
mandoc: IO::Compress::FAQ.3perl:115:95: STYLE: input text line longer than 80 
bytes: of these workarounds...
mandoc: IO::Compress::FAQ.3perl:141:86: STYLE: input text line longer than 80 
bytes: Similarly, if the \f...
mandoc: IO::Compress::FAQ.3perl:190:90: STYLE: input text line longer than 80 
bytes: The following compre...
mandoc: IO::Compress::FAQ.3perl:211:102: STYLE: input text line longer than 80 
bytes: Yes, both the \f(CW\...
mandoc: IO::Compress::FAQ.3perl:244:86: STYLE: input text line longer than 80 
bytes: When uncompressing w...
mandoc: IO::Compress::FAQ.3perl:286:89: STYLE: input text line longer than 80 
bytes: By default \f(CW\*(C...
mandoc: IO::Compress::FAQ.3perl:295:90: STYLE: input text line longer than 80 
bytes: To force \f(CW\*(C`I...
mandoc: IO::Compress::FAQ.3perl:305:88: STYLE: input text line longer than 80 
bytes: A \f(CW\*(C`bgzip\*(...
mandoc: IO::Compress::FAQ.3perl:338:91: STYLE: input text line longer than 80 
bytes: By default \f(CW\*(C...
mandoc: IO::Compress::FAQ.3perl:347:92: STYLE: input text line longer than 80 
bytes: To force \f(CW\*(C`I...
mandoc: IO::Compress::FAQ.3perl:361:87: STYLE: input text line longer than 80 
bytes: By default \f(CW\*(C...
mandoc: IO::Compress::FAQ.3perl:373:85: STYLE: input text line longer than 80 
bytes: Below is a mod_perl ...
mandoc: IO::Compress::FAQ.3perl:457:87: STYLE: input text line longer than 80 
bytes: read the contents of...
mandoc: IO::Compress::FAQ.3perl:462:90: STYLE: input text line longer than 80 
bytes: The gzip support in ...
mandoc: IO::Compress::FAQ.3perl:525:100: STYLE: input text line longer than 80 
bytes: The use of one-shot ...
mandoc: IO::Compress::FAQ.3perl:528:87: STYLE: input text line longer than 80 
bytes: Note the use of the ...
mandoc: IO::Compress::FAQ.3perl:534:102: STYLE: input text line longer than 80 
bytes: The \f(CW\*(C`Net::F...
mandoc: IO::Compress::FAQ.3perl:540:86: STYLE: input text line longer than 80 
bytes: Firstly, here is cod...
mandoc: IO::Compress::FAQ.3perl:582:88: STYLE: input text line longer than 80 
bytes: To illustrate how to...
mandoc: IO::Compress::FAQ.3perl:691:94: STYLE: input text line longer than 80 
bytes: The call to \f(CW\*(...
mandoc: IO::Compress::FAQ.3perl:693:86: STYLE: input text line longer than 

Bug#1071260: prometheus-postgres-exporter: pg_replication_slots metrics query fails on standbys with replication slots

2024-06-08 Thread Daniel Swarbrick

Hi Michael,

As this would seem to also affect the latest upstream release (v0.15.0), 
can you please forward this patch upstream and make a DEP-3 reference to 
it in your patch? There is little point in only patching this in Debian 
when it in fact affects the wider community.


Thanks



OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1072743: texlive-extra-utils: pdfxup: --pages option fails if page range omits start or end of range

2024-06-08 Thread Norbert Preining
> Yes, I'll be happy to discuss it with upstream.
> Should I CC you?  Or just update the Debian bug as needed?

Thanks Sanjoy, much appreciated!

Best regards

Norbert

--
PREINING Norbert  https://www.preining.info
arXiv / Cornell University   +   IFMGA Guide   +   TU Wien  +  TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13



Bug#1072829: RFP: texmacs -- WYSIWYG mathematical text editor using TeX fonts

2024-06-08 Thread Jerome BENOIT
Package: wnpp
Severity: wishlist

* Package name: texmacs
  Version : 2.1.4
  Upstream Author : Joris van der Hoeven 
* URL : https://www.texmacs.org
* License : GPL
  Programming Lang: C++
  Description : WYSIWYG mathematical text editor using TeX fonts


Please re-introduce TeXmacs. It might be used as an alternative to
Jupyter as notebook interface for Computer Alagebraic System (CAS)
as sagemath. The former package provides the following description:


GNU TeXmacs is a free scientific text editor, which was both inspired
by TeX and GNU Emacs.

The editor allows you to write structured documents via a WYSIWYG
(what-you-see-is-what-you-get) and a user friendly interface. New
styles may be created by the user. The program implements
high-quality typesetting algorithms and TeX fonts, which help you to
produce professionally looking documents.

The high typesetting quality still goes through for automatically
generated formulas, which makes TeXmacs suitable as an interface for
computer algebra systems. TeXmacs also supports the Guile/Scheme
extension language, so that you may customize the interface and write
your own extensions to the editor.



Bug#1072828: texlive-binaries upgrade breaks therion build

2024-06-08 Thread Adrian Bunk
Package: texlive-binaries
Version: 2024.20240313.70630+ds-2
Severity: serious
Tags: ftbfs
Control: affects -1 src:therion

https://buildd.debian.org/status/fetch.php?pkg=therion=amd64=6.2.1-1%2Bb1=1717847632=0

...
FAILED: thbook/thbook.pdf /<>/build/thbook/thbook.pdf 
cd /<>/thbook && /usr/bin/cmake -E env FORCE_SOURCE_DATE=1 
TEXINPUTS="/<>/build/thbook;." /usr/bin/pdftex 
--output-dir=/<>/build/thbook 
\\def\\outputsize{0}\\def\\reproducible{}\\input\ thbook.tex && /usr/bin/cmake 
-E env FORCE_SOURCE_DATE=1 TEXINPUTS="/<>/build/thbook;." 
/usr/bin/pdftex --output-dir=/<>/build/thbook 
\\def\\outputsize{0}\\def\\reproducible{}\\input\ thbook.tex && /usr/bin/cmake 
-E env FORCE_SOURCE_DATE=1 TEXINPUTS="/<>/build/thbook;." 
/usr/bin/pdftex --output-dir=/<>/build/thbook 
\\def\\outputsize{0}\\def\\reproducible{}\\input\ thbook.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2025/dev/Debian) 
(preloaded format=pdftex)
 restricted \write18 enabled.
entering extended mode
(./thbook.tex No glyph to unicode mapping found! (./etc/supp-mis.tex
loading : Context Support Macros / Miscellaneous (2004.10.26)
) (./etc/supp-pdf.tex
loading : Context Support Macros / PDF
) (./etc/optarg.tex) (./etc/verbatim.tex) (./ch00.tex [1{/var/lib/texmf/fonts/m
ap/pdftex/updmap/pdftex.map} <./pic/thbook.jpg>]
(/<>/build/thbook/version.tex) [2]
Warning: re-run to input a newly generated TOC file [3] [4]) (./ch01.tex
[5 <./pic/ageom.pdf>] [6] [7] [MP to PDF] (./mp/schema.1) [8]) (./ch02.tex
[9] [10 <./pic/agrippa.jpg>]
Overfull \hbox (9.55724pt too wide) in paragraph at lines 96--99
 []\tt [.MM[.DD[@HH[:MM[:SS[.SS]] [- [.MM[.DD[@HH[:MM[:SS[.SS]]
][]
[11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22]
Overfull \hbox (2.61252pt too wide) in paragraph at lines 824--857
 []\tt ice-pillar[]\rm , []\tt ice-stalactite[]\rm , []\tt ice-stalagmite[]\rm 
, []\tt map-connection[]$[]$\rm , []\tt paleo-material[]\rm ,

Overfull \hbox (4.79291pt too wide) in paragraph at lines 824--857
 []\tt photo[]\rm , []\tt root[]\rm , []\tt seed-germination[]\rm , []\tt sink[
]\rm , []\tt spring[]$[]$\rm , []\tt tree-trunk[]\rm , []\tt u[]$[]$\rm , []\tt
 vegetable-debris[]\rm ,
[23] [24] [25]
Overfull \hbox (0.4216pt too wide) in paragraph at lines 1015--1031
 []\it passages: []\tt wall[]\rm , []\tt con-tour[]\rm , []\tt slope[]$[]$\rm ,
 []\tt floor-step[]\rm , []\tt pit[]\rm , []\tt pitch[] \rm (syn-onym of pit), 
[]\tt ceiling-

Overfull \hbox (0.65195pt too wide) in paragraph at lines 1032--1044
 []\it passage fills: []\tt flow-stone[]\rm , []\tt moon-milk[]\rm , []\tt rock
-border[]$[]$\rm , []\tt rock-edge[]$[]$\rm , []\tt water-flow[]\rm , []\tt aby
ss-

Overfull \hbox (1.1684pt too wide) in paragraph at lines 1045--1053
 []\it equipment: []\tt fixed-ladder[]\rm , []\tt handrail[]\rm , []\tt rope[]\
rm , []\tt rope-ladder[]\rm , []\tt steps[]\rm , []\tt via-ferrata[]\rm , []\tt
 walk-
[MP to PDF] (./mp/xsect.1) [26] [27] [28] [29] [30] [31] [32] [33] [34]
[35] [36] [37] [38] [39] [40] [41] [42] [43] [44]) (./ch03.tex [45] [46 <./pic/
herakl.pdf>] [47] [48] [49]
Overfull \hbox (3.98236pt too wide) in paragraph at lines 294--294
[]\tt fonts-setup  
[50] [51] [52] [MP to PDF] (./mp/page.1) [53 <./pic/page.pdf>] [54] [55]
[56] [57] [58]
Overfull \hbox (1.67323pt too wide) in paragraph at lines 718--720
 [][][]\tt wall-source [] $\mit .$ \rm set source d
ata for pas-sage wall mod-
[59] [60] [61] [62]) (./ch04.tex [63] [64] [65 <./pic/database.pdf>] [66])
(./ch05.tex [67] [68 <./pic/thom.jpg>] [69] [70] [71] [72] [73] [74] [75]
[76] [77]) (./ch06.tex [78] [79] [80] [81] [82] [83] [84] [85] [86] [87]
[88] [89] [90] [91] [92] [93]) (./ch07.tex Warning: skipping the case studies)
[94]
kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 logo10
mktexpk: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1+0/600; 
nonstopmode; input logo10
This is METAFONT, Version 2.71828182 (TeX Live 2025/dev/Debian) (preloaded 
base=mf)

(/usr/share/texlive/texmf-dist/fonts/source/public/knuth-lib/logo10.mf
(/usr/share/texlive/texmf-dist/fonts/source/public/knuth-lib/logo.mf [77]
[69] [84] [65] [70] [80] [83] [79] [78]) )
Font metrics written on /<>/build/thbook/log
o10.tfm.
Output written on /<>/build/thbook/logo10.60
0gf (9 characters, 1748 bytes).
Transcript written on /<>/build/thbook/logo1
0.log.
mktexpk: `mf-nowin -progname=mf \mode:=ljfour; mag:=1+0/600; nonstopmode; input 
logo10' failed to make logo10.600pk.
kpathsea: Appending font creation commands to 
/<>/build/thbook/missfont.log.
 )
(\end occurred when \ifeof on line 10 was incomplete)
(see the transcript file for additional information)
!pdfTeX error: /usr/bin/pdftex (file logo10): Font logo10 at 600 not found
 ==> Fatal error occurred, no output PDF file produced!
 ...





Downgrading texlive-binaries to 2023.20230311.66589-9 OR
installing texlive-fonts-recommended works around this issue.



Bug#1072827: RFP: betterbird -- Betterbird is a fine-tuned version of Mozilla Thunderbird with exclusive bugfixes, additional features and fewer regressions.

2024-06-08 Thread bugreporter7
Package: wnpp
Severity: wishlist

* Package name: betterbird
  Version : N/A
  Upstream Contact: Betterbird 
* URL : https://www.betterbird.eu/
* License : Mozilla Public License Version 2.0
  Programming Lang: python, rust, javascript
  Description : Betterbird is a fine-tuned version of Mozilla Thunderbird 
with exclusive bugfixes, additional features and fewer regressions.

 Betterbird is a fine-tuned version of Mozilla Thunderbird, Thunderbird on 
steroids, if you will.

Betterbird is better than Thunderbird in three ways: It contains new features 
exclusive to Betterbird, it contains bug fixes exclusive to Betterbird and it 
contains fixes that Thunderbird may ship at a later stage. Please refer to this 
feature table (https://betterbird.eu/index.html#featuretable) for examples. 
This should give you an impression of where the project is headed.

Easy adoption: You can install Betterbird at the same time as Thunderbird and 
run them on the same profile. That means that you can try out Betterbird with 
zero hassle, and go back to Thunderbird if you don't like it - which is 
unlikely. Please read the fine print on our support page 
(https://www.betterbird.eu/support/index.html).

More information on why we're doing the project can be found at the FAQ 
(https://betterbird.eu/faq/index.html).

What is Betterbird?

Betterbird is a soft fork of Mozilla Thunderbird. Soft fork means that it is 
closely following the Thunderbird Extended Support Releases (ESR) therefore 
avoiding the mistakes of other forks which quickly lost track of upstream 
Thunderbird, thus opening users up to security vulnerabilities.

Why Betterbird?

Betterbird aims at providing a better user experience by fixing annoying bugs 
in Thunderbird and implementing new features. We will submit all changes to 
upstream to eventually benefit Thunderbird.

A big improvement was the implementation of the much-requested multi-line view, 
as you can check here.

A decent system tray ("systray") tooltip showing new messages and their 
folders. Also avaialble on Linux, it helps people who filter mail into many 
folders.

I have to no plan to package/maintain this software myself, this is only a 
suggestion as I think it would be a useful addition to debian.



Bug#1072815: [Debian-on-mobile-maintainers] Bug#1072815: phoc: colors of logout menu are unreadable when in dark mode

2024-06-08 Thread Russell Coker
On Saturday, 8 June 2024 22:45:27 AEST Guido Günther wrote:
> I assume there's some other GTK custom theme in place. Theming is not
> supported though I assume there's nothing we can do here but knowing
> which custom CSS is in place would be good. If you didn't tweak anything
> in `~/.config/gtk-3.0/` then the gsettings of
> 
> org.gnome.desktop.interface color-scheme
> org.gnome.desktop.interface gtk-theme

mobian@pine:~$ gsettings get org.gnome.desktop.interface color-scheme
'prefer-dark'
mobian@pine:~$ gsettings get org.gnome.desktop.interface gtk-theme
'Breeze'

Above are the settings.  As an aside the phone is currently logged in to 
Plasma Mobile but I presume that gsettings won't be affected by that.

I didn't intentionally make any changes to ~/.config/gtk-3.0/, I've attached 
an archive of it just in case it's relevant.  I have played with lots of 
things on that phone so I can't be sure that something didn't mess with that.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


config-gtk-3.0.tgz
Description: application/compressed-tar


Bug#1072826: importlib-resources: Please package new upstream version 6.4.0

2024-06-08 Thread Boyuan Yang
Source: importlib-resources
Version: 6.0.1-1
Severity: normal
X-Debbugs-CC: jo...@freesources.org

Dear Debian importlib-resources package maintainer,

A new upstream release of importlib-resources, v6.4.0, is available. Please
consider packaging it in Debian.

I could also help with package upgrading, and may make a team upload in the
near future. If you prefer to handle the upgrade yourself, please feel free
to let me know by replying this bug report at any time.

Thanks,
Boyuan Yang


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


Bug#1072825: po4a: Support MR macro natively

2024-06-08 Thread Helge Kreutzmann
Package: po4a
Version: 0.72-1
Severity: wishlist

groff 1.23 introduces the macro .MR for references like "groff(1)".
Using --option translate_joined or --option untranslated this macro
can be considered for translation.

However, this is not very good. Consider the following examples 
from groff(1):

Run eqn(1) preprocessor.

.
.TP
.B \-e
Run
.MR \%eqn 1
preprocessor.
.

This is now 3 paragraphs in the po file:
#. type: Plain text
msgid "Run"
msgstr ""

#. type: MR
#, no-wrap
msgid "\\%eqn 1"
msgstr ""

#. type: Plain text
msgid "preprocessor."
msgstr ""

As you can see, po strings may become very short. Some 
paragraphs are now a few po strings in the file, making it clumsy to
translate, especially if the "MR" part is the last in the english
sentence, but should be somewhere else in the translated sentence.

Or:
A
.MR man 1
librarian program \" such as man-db, since 2001
may use this macro file to delegate loading of the correct macro
…

which becomes

#. type: Plain text
msgid "A"
msgstr ""

#. type: MR
#, no-wrap
msgid "man 1"
msgstr ""

#.  such as man-db, since 2001
msgid ""
"librarian program may use this macro file to delegate loading of the correct "
"macro package; it is thus unnecessary for I itself to scan the contents "
"of a document to decide the issue."
msgstr ""

Here, you have the problem that "A" can be translated as "Ein", "Eine" oder 
"Einer" in German, so if this occurs multiple times, you might not be able to 
correctly translate it. Fortunately, current groff(1) uses this one
only once.

Maybe you can implement it like B<> and I<>, e.g. using R<> for
"reference" or simmilar?


groff(1) has some fallback code for older groffs, maybe you can use
this as starting point for implementation?
.\" Define fallback for groff 1.23's MR macro if the system lacks it.
.nr do-fallback 0
.if !\n(.f   .nr do-fallback 1 \" mandoc
.if  \n(.g .if !d MR .nr do-fallback 1 \" older groff
.if !\n(.g   .nr do-fallback 1 \" non-groff *roff
.if \n[do-fallback]  \{\
.  de MR
.ie \\n(.$=1 \
.  I \%\\$1
.el \
.  IR \%\\$1 (\\$2)\\$3
.  .
.\}
.rr do-fallback

Thank you very much for considering.


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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages po4a depends on:
ii  gettext 0.21-14+b1
ii  libpod-parser-perl  1.67-1
ii  libsgmls-perl   1.03ii-38
ii  libsyntax-keyword-try-perl  0.29-2
ii  libyaml-tiny-perl   1.74-1
ii  opensp  1.5.2-15
ii  perl5.38.2-5

Versions of packages po4a recommends:
ii  liblocale-gettext-perl 1.07-7
ii  libterm-readkey-perl   2.38-2+b3
ii  libtext-wrapi18n-perl  0.06-10
ii  libunicode-linebreak-perl  0.0.20190101-1+b7

po4a suggests no packages.

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature


Bug#1072824: odin FTBFS with VTK 9.3.0

2024-06-08 Thread Adrian Bunk
Source: odin
Version: 2.0.5-5
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=odin=amd64=2.0.5-5%2Bb2=1717847424=0

...
checking for main in -lvtkIOLegacy-7.1... no
checking for main in -lvtkIOLegacy-7.0... no
checking for main in -lvtkIOLegacy-6.3... no
checking for main in -lvtkIOLegacy-6.2... no
checking for main in -lvtkIOLegacy-6.1... no
checking for main in -lvtkIOLegacy-6.0... no
checking for main in -lvtkIOLegacy-9.0... no
checking for main in -lvtkIOLegacy-9.1... no
checking for main in -lvtkIO... no
checking for main in -lvtkRendering... no
checking for main in -lvtkGraphics... no
checking for main in -lvtkFiltering... no
checking for main in -lvtkCommon... no
checking for vtkStructuredPoints.h... no
checking for vtkArrowSource.h... no
configure: error: VTK library missing



Bug#1072823: liggghts FTBFS with VTK 9.3.0

2024-06-08 Thread Adrian Bunk
Source: liggghts
Version: 3.8.0+repack1-9.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=liggghts=amd64=3.8.0%2Brepack1-9.1%2Bb2=1717846024=0

...
/<>/src/dump_vtk.cpp: In member function ‘void 
LAMMPS_NS::DumpVTK::write_vtp(vtkSmartPointer, int, const 
char*)’:
/<>/src/dump_vtk.cpp:170:18: error: ‘class vtkXMLPPolyDataWriter’ 
has no member named ‘SetInput’; did you mean ‘GetInput’?
  170 | pwriter->SetInput(data);
  |  ^~~~
  |  GetInput
/<>/src/dump_vtk.cpp:187:17: error: ‘class vtkXMLPolyDataWriter’ 
has no member named ‘SetInput’; did you mean ‘GetInput’?
  187 | writer->SetInput(data);
  | ^~~~
  | GetInput
/<>/src/dump_vtk.cpp: In member function ‘void 
LAMMPS_NS::DumpVTK::write_vtu(vtkSmartPointer, int, const 
char*)’:
/<>/src/dump_vtk.cpp:209:18: error: ‘class 
vtkXMLPUnstructuredGridWriter’ has no member named ‘SetInput’; did you mean 
‘GetInput’?
  209 | pwriter->SetInput(data);
  |  ^~~~
  |  GetInput
/<>/src/dump_vtk.cpp:226:17: error: ‘class 
vtkXMLUnstructuredGridWriter’ has no member named ‘SetInput’; did you mean 
‘GetInput’?
  226 | writer->SetInput(data);
  | ^~~~
  | GetInput
/<>/src/dump_vtk.cpp: In member function ‘void 
LAMMPS_NS::DumpVTK::write_vtr(vtkSmartPointer, int, const 
char*)’:
/<>/src/dump_vtk.cpp:280:43: error: ‘class vtkDataObject’ has no 
member named ‘GetProducerPort’
  280 | pwriter->SetInputConnection(data->GetProducerPort());
  |   ^~~
/<>/src/dump_vtk.cpp:297:42: error: ‘class vtkDataObject’ has no 
member named ‘GetProducerPort’
  297 | writer->SetInputConnection(data->GetProducerPort());
  |  ^~~
/<>/src/dump_vtk.cpp: In member function ‘void 
LAMMPS_NS::DumpVTK::write_vtk_unstructured_grid(vtkSmartPointer, 
int, const char*, char*)’:
/<>/src/dump_vtk.cpp:322:42: error: ‘class vtkDataObject’ has no 
member named ‘GetProducerPort’
  322 | writer->SetInputConnection(data->GetProducerPort());
  |  ^~~
/<>/src/dump_vtk.cpp: In member function ‘void 
LAMMPS_NS::DumpVTK::write_vtk_rectilinear_grid(vtkSmartPointer, 
int, const char*, char*)’:
/<>/src/dump_vtk.cpp:347:42: error: ‘class vtkDataObject’ has no 
member named ‘GetProducerPort’
  347 | writer->SetInputConnection(data->GetProducerPort());
  |  ^~~
/<>/src/dump_vtk.cpp: In member function ‘void 
LAMMPS_NS::DumpVTK::write_vtk_poly(vtkSmartPointer, int, const 
char*, char*)’:
/<>/src/dump_vtk.cpp:372:42: error: ‘class vtkDataObject’ has no 
member named ‘GetProducerPort’
  372 | writer->SetInputConnection(data->GetProducerPort());
  |  ^~~
...


Bug#1071007:

2024-06-08 Thread Nilson Silva
Hi everybody!

Firstly, we have to make it clear that we have two distinct bugs:

They seem to be the same because you are bumping into the only files they have 
in common:
__init__.py


The first bug was due to Sherlock installing his modules in the root of the 
package directories.
 This has so far been resolved by the patch. I sent it upstream, in case he 
wanted to merge until he
 changed to another beckand(poetry), however I left him free to accept it or 
not. And I made clear the reasons why I sent it.
https://github.com/sherlock-project/sherlock/pull/2147

The other problem is because there is the same project with the same name as 
sherlock, although its
name is python-sherlock, upstream in its code calls it "sherlock".

The question is to solve the problem, one of the projects will have to change 
the name
of both pyproject.toml and also change the name of its main module and create 
nicknames
for its "imports". In my opinion, several files will have to be patched

Or as an alternative
We could make Sherlock install its modules in the package root again. 

The question is when Sherlock joins Poetry, we will have the problem again, 
as there would once again be a directory called Sherlock.

Nilson F. Silva



Bug#1072822: gdcm FTBFS with VTK 9.3.0

2024-06-08 Thread Adrian Bunk
Source: gdcm
Version: 3.0.24-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=gdcm=amd64=3.0.24-1%2Bb2=1717845766=0

...
-- Building Utilities/VTK as a VTK 9 Module
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/vtk-9.3/vtkModule.cmake:2121 
(message):
  The `SPDX_DESTINATION` must not be an absolute path.  Use
  `CMAKE_INSTALL_PREFIX` to keep everything in a single installation prefix.
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/vtk-9.3/vtkModule.cmake:2667 
(_vtk_module_check_destinations)
  CMakeLists.txt:696 (vtk_module_build)


-- Configuring incomplete, errors occurred!



Bug#1072815: [Debian-on-mobile-maintainers] Bug#1072815: phoc: colors of logout menu are unreadable when in dark mode

2024-06-08 Thread Guido Günther
control: reassign -1 phosh
control: tags -1 +moreinfo

Hi,
On Sat, Jun 08, 2024 at 10:02:14AM +, Russell Coker via 
Debian-on-mobile-maintainers wrote:
> Package: phoc
> Version: 0.39.0+ds-1
> Severity: normal
> 
> After the bug is submitted I'll attach a photo of the screen to show.
> 
> It's almost unreadable when in dark mode.

Phosh doesn't care about the dark mode toggle (the menu doesn't change
when you switch between dark and default mode in Settings or the dark
mode quick setting toggle).

It cares about HighContrast but that's not what your screenshot shows
either.

I assume there's some other GTK custom theme in place. Theming is not
supported though I assume there's nothing we can do here but knowing
which custom CSS is in place would be good. If you didn't tweak anything
in `~/.config/gtk-3.0/` then the gsettings of

org.gnome.desktop.interface color-scheme
org.gnome.desktop.interface gtk-theme

would be good to know.

Cheers,
 -- Guido

> 
> 
> -- System Information:
> Debian Release: trixie/sid
> Architecture: arm64 (aarch64)
> 
> Kernel: Linux 6.1-rockchip (SMP w/6 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
> 
> Versions of packages phoc depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
> ii  gsettings-desktop-schemas46.0-1
> ii  libc62.38-12.1
> ii  libcairo21.18.0-3+b1
> ii  libglib2.0-0t64  2.80.2-2
> ii  libgmobile0  0.2.0-2
> ii  libgnome-desktop-3-20t64 44.0-5
> ii  libinput10   1.25.0-1+b2
> ii  libpixman-1-00.42.2-1+b1
> ii  libudev1 256~rc4-1
> ii  libwayland-server0   1.22.0-2.1+b1
> ii  libwlroots12t64  0.17.2-2
> ii  libxcb1  1.17.0-2
> ii  libxkbcommon01.6.0-1+b1
> ii  mutter-common44.8-3.1
> 
> Versions of packages phoc recommends:
> ii  phosh 0.39.0-1
> ii  xwayland  2:24.1.0-1
> 
> phoc suggests no packages.
> 
> -- debconf-show failed
> 
> ___
> Debian-on-mobile-maintainers mailing list
> debian-on-mobile-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
> 



Bug#1072821: wireshark: binNMUs revert t64 transition

2024-06-08 Thread Adrian Bunk
Source: wireshark
Version: 4.2.4-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=wireshark=amd64=4.2.5-1%2Bb1=1717834351=0

...
Description:
 libwireshark-dev - network packet dissection library -- development files
 libwireshark17 - network packet dissection library -- shared library
 libwiretap-dev - network packet capture library -- development files
 libwiretap14 - network packet capture library -- shared library
 libwsutil-dev - network packet dissection utilities library -- development 
files
 libwsutil15 - network packet dissection utilities library -- shared library
 tshark - network traffic analyzer - console version
 wireshark  - network traffic analyzer - graphical interface
 wireshark-common - network traffic analyzer - common files
 wireshark-dev - network traffic analyzer - development tools
Changes:
 wireshark (4.2.5-1+b1) sid; urgency=low, binary-only=yes
 .
   * Binary-only non-maintainer upload for amd64; no source changes.
   * Rebuild against Qt 6.6.2.
...



debian/rules:
...
ifneq ($(filter noble unstable testing trixie UNRELEASED,$(DEB_DISTRIBUTION)),)
sed "$(CONTROL_IN_SED_CMD)" debian/control.t64.in > debian/control
else
sed "$(CONTROL_IN_SED_CMD)" debian/control.in > debian/control
...



sid != unstable



Bug#1069353: plantuml: Re: nncp: FTBFS on arm64: make[1]: *** [debian/rules:21: override_dh_auto_build] Error 1

2024-06-08 Thread Max Nikulin



On 07/06/2024 18:24, Andrej Shadura wrote:

That was totally a bug in plantuml. My fault that I forgot to merge it
with another bug report for the same issue.


Thanks, Andrej. I see that the package have returned to testing.

I am sorry that I missed https://bugs.debian.org/1068999 I was surprised 
that a working version suddenly disappeared from trixie.




Bug#1072817: bookworm-pu: package openrc/0.45.2-2+deb12u1

2024-06-08 Thread Mark Hindley
Control: tags -1 - moreinfo

Adam,

On Sat, Jun 08, 2024 at 12:35:21PM +0100, Adam D. Barratt wrote:
> While you have attached a debdiff, it's of the binary packages. Please
> provide a source debdiff, i.e. between the current and proposed DSCs.

Apologies, attached.

Thanks.

Mark
diff -Nru openrc-0.45.2/debian/changelog openrc-0.45.2/debian/changelog
--- openrc-0.45.2/debian/changelog  2022-08-02 11:46:15.0 +0100
+++ openrc-0.45.2/debian/changelog  2024-05-02 10:04:20.0 +0100
@@ -1,3 +1,10 @@
+openrc (0.45.2-2+deb12u1) bookworm; urgency=medium
+
+  * d/openrc.postinst: ignore non-executable scripts in /etc/init.d
+(Closes: #1070167)
+
+ -- Mark Hindley   Thu, 02 May 2024 10:04:20 +0100
+
 openrc (0.45.2-2) unstable; urgency=medium
 
   * Fix FTBFS on Hurd: explicitly set pam option and don't require kvm.
diff -Nru openrc-0.45.2/debian/gbp.conf openrc-0.45.2/debian/gbp.conf
--- openrc-0.45.2/debian/gbp.conf   2022-08-02 11:46:15.0 +0100
+++ openrc-0.45.2/debian/gbp.conf   2024-05-02 10:04:20.0 +0100
@@ -1,6 +1,6 @@
 [DEFAULT]
 upstream-branch = master
-debian-branch = debian
+debian-branch = bookworm
 upstream-tag = %(version)s
 compression = xz
 pristine-tar = False
diff -Nru openrc-0.45.2/debian/openrc.postinst 
openrc-0.45.2/debian/openrc.postinst
--- openrc-0.45.2/debian/openrc.postinst2022-08-02 11:46:15.0 
+0100
+++ openrc-0.45.2/debian/openrc.postinst2024-05-02 10:04:20.0 
+0100
@@ -25,7 +25,7 @@
rclink=/etc/rc${rl}.d/${f}
initsh=$(readlink -f ${rclink})
svc=$(basename ${initsh})
-   if [ -f ${initsh} ]; then
+   if [ -x ${initsh} ]; then
case ${rl} in
1) orl="recovery" ;;
2) orl="default" ;;
@@ -33,8 +33,12 @@
esac
rc-update add ${svc} ${orl}
else
+   if [ -f ${initsh} ]; then
+   echo "*** WARNING: skipping non-executable 
$initsh"
+   else
echo "*** WARNING: dangling link $rclink"
echo $dsvcs|grep -qw ${svc} || dsvcs="$dsvcs 
${svc}"
+   fi
fi
done
done


Bug#1072820: slm: Issues in slm documentation strings

2024-06-08 Thread Christoph Brinkhaus
Package: slm
Version: 0.8.3-3
Severity: minor

Dear Maintainer,

while updating the strings in the slm template the l10
documentation team noticed some issues in the text which I report below.
All are simple typos. Regarding the second and third one I am not sure,
it depends how and if they are finally presented. In doubt leave them
as they are. The lines below are copy from the template. You will
find the FIXME lines in the translation, too.

# FIXME: s/Otherwise, on gets/Otherwise, one gets/
#. Type: boolean
#. Description
#: ../slm.templates:1001
msgid ""
"When the DEBUG feature is enabled, one can get detailed reports each time a "
"request fails. Otherwise, on gets just a \"404 error\". The default setting "
"(no DEBUG) is safe."

# FIXME: s/administrator's/Administrator's/
#. Type: string
#. Description
#: ../slm.templates:3001
msgid "administrator's e-mail address:"

# FIXME: s/administrator's/Administrator's/
#. Type: password
#. Description
#: ../slm.templates:4001
msgid "administrator's password:"

Thank you very much for maintaining this project,
Christoph Brinkhaus



Bug#1072819: slm: [L10N,DE] slm 0.8.3-3: german translation

2024-06-08 Thread Christoph Brinkhaus
Package: slm
Version: 0.8.3-3
Severity: wishlist

Dear Maintainer,

please find attached the po file with the german translation.
Please consider to apply it to the package.

Thank you very much!

Kind regards,
Christoph Brinkhaus
# Translation of the SLM template to German.
# This file is distributed under the same license as the slm package.
# Copyright © of this file:
# Christoph Brinkhaus , 2024.
#
msgid ""
msgstr ""
"Project-Id-Version: slm 0.8.3-3\n"
"Report-Msgid-Bugs-To: s...@packages.debian.org\n"
"POT-Creation-Date: 2024-06-01 16:29+0200\n"
"PO-Revision-Date: 2024-06-07 20:55+0200\n"
"Last-Translator: Christoph Brinkhaus \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../slm.templates:1001
msgid "Should the DEBUG feature be enabled?"
msgstr "Soll die DEBUG-Funktion aktiviert werden?"

# FIXME: s/Otherwise, on gets/Otherwise, one gets/
#. Type: boolean
#. Description
#: ../slm.templates:1001
msgid ""
"When the DEBUG feature is enabled, one can get detailed reports each time a "
"request fails. Otherwise, on gets just a \"404 error\". The default setting "
"(no DEBUG) is safe."
msgstr ""
"Wenn die DEBUG-Funktion aktiviert ist, kann für jede fehlgeschlagene "
"Anfrage ein detaillierter Bericht erhalten werden. Anderenfalls wird nur "
"ein »404 Fehler« zurückgeliefert. Die Voreinstellung (kein DEBUG) ist sicher." 

#. Type: string
#. Description
#: ../slm.templates:2001
msgid "Server's name:"
msgstr "Name des Servers:"

#. Type: string
#. Description
#: ../slm.templates:2001
msgid ""
"You should give a fully qualified domain name (FQDN), usable to access your "
"SLM server. This will be used to configure Apache2 in order to support SLM "
"as a service."
msgstr "Sie sollten einen vollständigen Domain-Namen (FQDN) für den "
"Zugriff auf den SLM-Server angeben. Er wird für die Konfiguration "
"von Apache2 verwendet, um SLM als einen Dienst zu unterstützen."

# FIXME: s/administrator's/Administrator's/
#. Type: string
#. Description
#: ../slm.templates:3001
msgid "administrator's e-mail address:"
msgstr "E-Mail-Adresse des Administrators:"

#. Type: string
#. Description
#: ../slm.templates:3001
msgid ""
"The user \"admin\" is automatically a superuser owning all the rights to "
"manage SLM's database. Please give a sensible e-mail address if you think "
"that it will be used."
msgstr ""
"Der Benutzer »admin« ist automatisch ein Superuser mit allen Rechten, "
"die Daten von SLM zu verwalten. Bitte geben Sie eine sinnvolle "
"E-Mail-Adresse an, falls Sie diese verwenden wollen."

# FIXME: s/administrator's/Administrator's/
#. Type: password
#. Description
#: ../slm.templates:4001
msgid "administrator's password:"
msgstr "Passwort des Administrators:"

#. Type: password
#. Description
#: ../slm.templates:4001
msgid ""
"The user \"admin\" is automatically a superuser owning all the rights to "
"manage SLM's database. Please provide some strong enough password."
msgstr ""
"Der Benutzer »admin« ist automatisch ein Superuser mit allen Rechten, "
"die Daten von SLM zu verwalten. Bitte geben Sie ein ausreichend starkes "
"Passwort an."


Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

2024-06-08 Thread Samuel Henrique
Control: tags 1072733 moreinfo
Control: reopen 1071007 =

Hello all,

I wasn't subscribed to both bugs so I missed some of the replies, I'm
subscribed now.

I'm sending this reply to both #1072733 and #1071007 because they are related
and I'm trying to clarify the situation on both.

Summary:
#1072733 is a bug caused by a tentative fix of #1071007, I believe Francisco
made the right approach there, but maybe I'm missing something, Chris?

#1071007 is still not fully fixed as the approach is problematic.

We should not submit workarounds to upstream when they already pointed out a PR
which should address the issue.

If we need to perform a workaround on our side in the meantime, we need to make
sure it works and we should not submit it upstream (they already have the
proper fix in progress).

Plan:
Let's try to fix this issue using upstream's PR.

If we spot issues with the PR, we can contribute back (but let's make sure it
makes sense to upstream).

If we end up performing a workaround, let's make sure it works and doesn't
cause other issues. It's ok to let the package be removed from testing until
this gets fixed.

If we really want to avoid the package being removed from testing, we can
package a previous release where the issue wasn't present (using the "+really"
versioning mechanism).

The end goal is to get this fixed before the freeze, so we have time.

Now the lengthy replies below:

For #1072733:

Chris
> Per Debian policy this is not the correct solution for naming conflicts. Both
> maintainer (teams), please find a policy compliant solution together.

The solution for this one seems correct, it's a Conflict + Replaces because
both packages provide a "sherlock" library. Am I missing something?

Note that this bug is different from #1071007, they look very similar and
initially I thought they were a dupe.

Nilson
> Your package should not be called in d/rules:
> export PYBUILD_NAME=python-sherlock
> or something similar that wasn't exactly sherlock?

We should keep the same name as changing it will cause issues for users, this
is a real case of a conflicting library name.

For #1071007:

Nilson,
> I just pushed a new version of shelock with a fix for the problem in the
> "master" branch. If that's ok, I'll do a merge.
> https://salsa.debian.org/pkg-security-team/sherlock/-/tree/master?ref_type=heads

We follow the DEP14 for git branching, that means we do namespacing. When
dealing with temp/wip branches, the recommendation is to push to
$username/$branchname. If you push to master, it will lead to confusion as to
which branch is the main one (it's debian/master).

It looks like that branch has been merged into debian/master but master has not
been deleted yet. We have to remove that branch.

> This led to the bug being reopened twice as RC, leading to its removal from
> "testing" even after > pycrc had resolved its conflict issue.

We always try to avoid getting a package removed from testing, but sometimes it
happens and that's ok, once the issue is fixed the package will get back. This
is only worrying when removing the package causes a cascade effect or when we
are close to the freeze for stable.

We don't have to rush for a fix in this case, it's better to be precise.

> I made a pull request to usptream
> https://github.com/sherlock-project/sherlock/pull/2147

We should not be submitting this to upstream when they already pointed us to a
PR that solves the issue. We have to try working with that PR. If  that's not
possible, we can patch it ourselves with a different approach, but we should
not submit our workaround to upstream because they already have a proper
solution in progress.

> In accordance with the other Package Uploaders,
> Debian Developer, Francisco Vilmar.
> I will be closing the bug.
> Since the problem itself, with Sherlock installing its
modules in the root of the packages, has been fixed.

The upload done by Francisco for #1072733 can't be used to close #1071007, he
was fixing an issue caused by one of the uploads that tried to fix #1071007, it
was not fixing #1071007 itself.

> sherlock (0.14.4+git20240531.e5ad3c4-1) unstable; urgency=medium
> .
>   * New upstream version 0.14.4+git20240531.e5ad3c4
>   * debian/patches: Adjusted directory installation package (Closes: #1071007)

This upload is indeed trying to solve #1071007 by patching the source code
instead of pulling the upstream PR.
Looking at the list of files shiped [0], the egginfo files are in the wrong
place.

I also find the following commit confusing:
https://salsa.debian.org/pkg-security-team/sherlock/-/commit/fc6e9929b1018d411df599a68d5898e42bfe6560

The commit description does not mention what/why the changes are being made,
for example, why the change from dh_auto_install to dh_install.

Cheers,

[0] https://packages.debian.org/trixie/all/sherlock/filelist

--
Samuel Henrique 



Bug#880170: aptitude: Read error (-5: DATA_ERROR_MAGIC)

2024-06-08 Thread Julia Longtin
I can reproduce this on command, and have two workarounds, (one dirty, one
ugly).

I'm using FAI on Debian 9.13.

So, the problem is, that when apt writes a translations related file, it is
writing a symlink to the extracted .bz2, rather than writing a .bz2 file.

Problem reproduction:

I am using apt-cacher-ng, and am currently pointing it to archive.debian.org.
I am also using apt against a chroot, as part of using the Fully Automated
Installer. This is happening while I'm trying to set up a mirror of debian,
with only the packages I have selected.

as part of that, my apt options are as follows:
```
-o Aptitude::Log=/dev/null -o
Aptitude::CmdLine::Ignore-Trust-Violations=yes -o
APT::Get::AllowUnauthenticated=true -o DPkg::force-conflicts::=yes -o
Dir::State=/usr/fai/mirror/aptcache//var/lib/apt -o
Dir::Log=/usr/fai/mirror/aptcache//var/log/apt -o
Dir::State::extended_states=/usr/fai/mirror/aptcache//var/lib/apt/lists/extended_states
-o Dir::State::status=/usr/fai/mirror/aptcache//statefile -o
APT::Get::Force-Yes=true -o
Dir::Cache=/usr/fai/mirror/aptcache//var/cache/apt -o
Dir::State=/usr/fai/mirror/aptcache//var/cache/apt -o
Dir::Cache::Archives=/usr/fai/mirror/aptcache//var/cache/apt/archives -o
Dir::Etc=/usr/fai/mirror/aptcache//etc/apt/ -o
Dir::State::Lists=/usr/fai/mirror/aptcache//var/lib/apt/lists/
```

The error in question is easy to produce:
```
faiserver:/home/fai# apt-get $aptoptions update
Ign:1 http://127.0.0.1:3142/archive.debian.org/debian stretch InRelease
Get:2 http://127.0.0.1:3142/archive.debian.org/debian stretch Release [118
kB]
Get:3 http://127.0.0.1:3142/archive.debian.org/debian stretch Release.gpg
[3,177 B]
Ign:3 http://127.0.0.1:3142/archive.debian.org/debian stretch Release.gpg
Hit:5 http://127.0.0.1:3142/archive.debian.org/debian stretch/main
Translation-en
Ign:5 http://127.0.0.1:3142/archive.debian.org/debian stretch/main
Translation-en
Hit:4 http://127.0.0.1:3142/archive.debian.org/debian stretch/main i386
Packages
Ign:4 http://127.0.0.1:3142/archive.debian.org/debian stretch/main i386
Packages
Hit:5 http://127.0.0.1:3142/archive.debian.org/debian stretch/main
Translation-en
Ign:5 http://127.0.0.1:3142/archive.debian.org/debian stretch/main
Translation-en
Hit:4 http://127.0.0.1:3142/archive.debian.org/debian stretch/main i386
Packages
Ign:4 http://127.0.0.1:3142/archive.debian.org/debian stretch/main i386
Packages
Err:5 http://127.0.0.1:3142/archive.debian.org/debian stretch/main
Translation-en
  BZ2_bzread:
/usr/fai/mirror/aptcache/var/lib/apt/lists/partial/127.0.0.1:3142_archive.debian.org_debian_dists_stretch_main_i18n_Translation-en.bz2
Read error (-5: DATA_ERROR_MAGIC)
Get:4 http://127.0.0.1:3142/archive.debian.org/debian stretch/main i386
Packages [9,587 kB]
Fetched 121 kB in 3s (40.2 kB/s)
Reading package lists... Done
W: GPG error: http://127.0.0.1:3142/archive.debian.org/debian stretch
Release: The following signatures couldn't be verified because the public
key is not available: NO_PUBKEY 04EE7237B7D453EC NO_PUBKEY 648ACFD622F3D138
NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY EF0F382A1A7B6500
W: The repository 'http://127.0.0.1:3142/archive.debian.org/debian stretch
Release' is not signed.
N: Data from such a repository can't be authenticated and is therefore
potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration
details.
E: Failed to fetch
http://127.0.0.1:3142/archive.debian.org/debian/dists/stretch/main/i18n/Translation-en
 BZ2_bzread:
/usr/fai/mirror/aptcache/var/lib/apt/lists/partial/127.0.0.1:3142_archive.debian.org_debian_dists_stretch_main_i18n_Translation-en.bz2
Read error (-5: DATA_ERROR_MAGIC)
E: Some index files failed to download. They have been ignored, or old ones
used instead.
faiserver:/home/fai#
```

that's the error in question. A quick inspection of what the file it is
complaining looks like is as follows:
```
faiserver:/home/fai# ls -la
/usr/fai/mirror/aptcache/var/lib/apt/lists/partial/127.0.0.1:3142
_archive.debian.org_debian_dists_stretch_main_i18n_Translation-en.bz2
lrwxrwxrwx 1 root root 122 Jun  8 12:41
/usr/fai/mirror/aptcache/var/lib/apt/lists/partial/127.0.0.1:3142_archive.debian.org_debian_dists_stretch_main_i18n_Translation-en.bz2
-> /usr/fai/mirror/aptcache/var/lib/apt/lists/127.0.0.1:3142
_archive.debian.org_debian_dists_stretch_main_i18n_Translation-en
faiserver:/home/fai# ls -la
/usr/fai/mirror/aptcache/var/lib/apt/lists//127.0.0.1:3142
_archive.debian.org_debian_dists_stretch_main_i18n_Translation-en
-rw-r--r-- 1 root root 26417876 Jul 18  2020
/usr/fai/mirror/aptcache/var/lib/apt/lists//127.0.0.1:3142
_archive.debian.org_debian_dists_stretch_main_i18n_Translation-en
faiserver:/home/fai# file
/usr/fai/mirror/aptcache/var/lib/apt/lists//127.0.0.1:3142
_archive.debian.org_debian_dists_stretch_main_i18n_Translation-en
/usr/fai/mirror/aptcache/var/lib/apt/lists//127.0.0.1:3142_archive.debian.org_debian_dists_stretch_main_i18n_Translation-en:
UTF-8 Unicode text
```

so apt-get has created 

Bug#1072801: ITP: lsix -- Show thumbnails in terminal using sixel graphics

2024-06-08 Thread Richard Lewis
Blair Noctis  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Blair Noctis 
> X-Debbugs-Cc: debian-de...@lists.debian.org, n...@sail.ng
>
> * Package name: lsix
>   Version : 1.8.2
>   Upstream Contact: b9 
> * URL : https://github.com/hackerb9/lsix
> * License : GPL-3
>   Programming Lang: Shell
>   Description : Show thumbnails in terminal using sixel graphics
>
> Like "ls", but for images.

But ls works fine on images do you (and upsteam) mean "like 'cat'
but for images?"

Some of the "features" look like implementation details so you might
want to consider from a users' pov



Bug#1072817: bookworm-pu: package openrc/0.45.2-2+deb12u1

2024-06-08 Thread Adam D. Barratt
Control: tags -1 + moreinfo

Hi,

On Sat, 2024-06-08 at 11:59 +0100, Mark Hindley wrote:

[...]
>   [x] attach debdiff against the package in stable

While you have attached a debdiff, it's of the binary packages. Please
provide a source debdiff, i.e. between the current and proposed DSCs.

Regards,

Adam



Bug#1072818: RFP: hatch -- Modern, extensible Python project management

2024-06-08 Thread Stefano Rivera
Package: wnpp
Severity: wishlist

* Package name: hatch
  Version : 1.12.0
  Upstream Contact: Ofek Lev 
* URL : https://hatch.pypa.io/latest/
* License : MIT
  Programming Lang: Python
  Description : Modern, extensible Python project management

The high level value proposition of Hatch is that if one adopts all
functionality then many other tools become unnecessary since there is
support for everything one might require. Further, if one chooses to use
only specific features then there are still benefits compared to
alternatives.

The community has requested that we package hatch
https://github.com/pyOpenSci/python-package-guide/issues/301
I had a look, and I think all the dependencies are in place.

Stefano



Bug#1072817: bookworm-pu: package openrc/0.45.2-2+deb12u1

2024-06-08 Thread Mark Hindley
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ope...@packages.debian.org
Control: affects -1 + src:openrc

Dear Release Team,

Please unblock openrc in bookworm-pu. Version 0.45.2-2+deb12u1 includes a
backported fix for #1070167 which prevents openrc's postinst choking on
non-executable scripts in /etc/init.d. These now arise routinely: since
debhelper 13.10 the dh_installinit fragments clear the executable bit on package
removal. The relevant debhelper changelog entries are

 * dh_installinit: Remove executable bit of init scripts on
package removal (via preinst).  Related to #1021027.
  * dh_installsystemd: Stop masking system units on package
removal.  This is no longer necessary with the init scripts
getting their exec bit cleared on package removal.
(Closes: #1021027)


The openrc fix has been in unstable and testing for over a month with no
regressions reported.

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

Thanks

Mark
File lists identical (after any substitutions)

Control files of package libeinfo-dev: lines which differ (wdiff format)

Depends: libeinfo1 (= [-0.45.2-2)-] {+0.45.2-2+deb12u1)+}
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}

Control files of package libeinfo1: lines which differ (wdiff format)
-
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}

Control files of package libeinfo1-dbgsym: lines which differ (wdiff format)

Depends: libeinfo1 (= [-0.45.2-2)-] {+0.45.2-2+deb12u1)+}
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}

Control files of package librc-dev: lines which differ (wdiff format)
-
Depends: librc1 (= [-0.45.2-2)-] {+0.45.2-2+deb12u1)+}
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}

Control files of package librc1: lines which differ (wdiff format)
--
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}

Control files of package librc1-dbgsym: lines which differ (wdiff format)
-
Depends: librc1 (= [-0.45.2-2)-] {+0.45.2-2+deb12u1)+}
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}

Control files of package openrc: lines which differ (wdiff format)
--
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}

Control files of package openrc-dbgsym: lines which differ (wdiff format)
-
Depends: openrc (= [-0.45.2-2)-] {+0.45.2-2+deb12u1)+}
Version: [-0.45.2-2-] {+0.45.2-2+deb12u1+}


Bug#1072815: screen pic

2024-06-08 Thread Russell Coker
Here's a photo of what happens.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


Bug#1072816: sploitscan: Configuration files installed in Python modules directory

2024-06-08 Thread Peter Wienemann
Package: sploitscan
Version: 0.9.1-1
Severity: serious

Hi,

sploitscan installs configuration files in the system Python modules
directory:

/usr/lib/python3/dist-packages/sploitscan/templates/report_template.html
/usr/lib/python3/dist-packages/sploitscan/config.json

As per Debian Policy 10.7.2 configuration files must reside in /etc (or
in case of multiple configuration files it is suggested to put them in
a subdirectory named after the package).

Best regards,

Peter



Bug#1072815: phoc: colors of logout menu are unreadable when in dark mode

2024-06-08 Thread Russell Coker
Package: phoc
Version: 0.39.0+ds-1
Severity: normal

After the bug is submitted I'll attach a photo of the screen to show.

It's almost unreadable when in dark mode.


-- System Information:
Debian Release: trixie/sid
Architecture: arm64 (aarch64)

Kernel: Linux 6.1-rockchip (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages phoc depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  gsettings-desktop-schemas46.0-1
ii  libc62.38-12.1
ii  libcairo21.18.0-3+b1
ii  libglib2.0-0t64  2.80.2-2
ii  libgmobile0  0.2.0-2
ii  libgnome-desktop-3-20t64 44.0-5
ii  libinput10   1.25.0-1+b2
ii  libpixman-1-00.42.2-1+b1
ii  libudev1 256~rc4-1
ii  libwayland-server0   1.22.0-2.1+b1
ii  libwlroots12t64  0.17.2-2
ii  libxcb1  1.17.0-2
ii  libxkbcommon01.6.0-1+b1
ii  mutter-common44.8-3.1

Versions of packages phoc recommends:
ii  phosh 0.39.0-1
ii  xwayland  2:24.1.0-1

phoc suggests no packages.

-- debconf-show failed



Bug#1072814: mutt -A '' generates a segmentation fault

2024-06-08 Thread Bruce Momjian
Package: mutt
Version: 2.2.12-0.1~deb12u1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I was useing -A to look up aliases.

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

mutt -A ''

   * What was the outcome of this action?

crash.

   * What outcome did you expect instead?

I expended an empty result.

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


-- Package-specific info:
Mutt 2.2.12 (2023-09-09)
Copyright (C) 1996-2023 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 6.1.0-15-amd64 (x86_64)
ncurses: ncurses 6.4.20221231 (compiled with 6.4)
libidn2: 2.3.3 (compiled with 2.3.3)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14' 
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-12 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin 
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr
 --enable-offload-defaulted --without-cuda-driver --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14) 

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man' 
'--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
'--libdir=${prefix}/lib/x86_64-linux-gnu' --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking 
--with-mailpath=/var/mail --enable-compressed --enable-debug --enable-fcntl 
--enable-hcache --enable-gpgme --enable-imap --enable-smtp --enable-pop 
--enable-sidebar --enable-dotlock --disable-fmemopen --with-curses 
--with-gnutls --with-gss --with-idn2 --with-mixmaster --with-gsasl 
--without-gdbm --without-bdb --without-qdbm --with-tokyocabinet 
build_alias=x86_64-linux-gnu 'CFLAGS=-g -O2 
-ffile-prefix-map=/build/reproducible-path/mutt-2.2.12=. 
-fstack-protector-strong -Wformat -Werror=format-security' 
'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-ffile-prefix-map=/build/reproducible-path/mutt-2.2.12=. 
-fstack-protector-strong -Wformat -Werror=format-security

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  -USE_SASL  +USE_GSASL  +USE_GSS  
+HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  -HAVE_LIBIDN  +HAVE_LIBIDN2  +HAVE_GETSID  
+USE_HCACHE  
+USE_SIDEBAR  +USE_COMPRESSED  +USE_INOTIFY  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"

To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:
https://gitlab.com/muttmua/mutt/issues


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

Kernel: Linux 6.1.0-15-amd64 (SMP w/48 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 

Bug#1072813: release.debian.org: Help doris migrate to testing

2024-06-08 Thread Antonio Valentino

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org

doris (5.0.3~beta+dfsg-17) is not migrating to testing, the excuses 
suggest this is due to unsatisfiable dependency for python3-doris/arm64:


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

the missing dependency apparently is doris itself that is not build for 
arm64.


Apparently this situation was file before the doris removal from testing 
due to one of the dependencies (fastkml [1]).
Now fastkml is back in tasting so I would expect that doris could be 
able to migrate.


Could you please clarify if there is something on my side that I should 
do to allow doris to migrate?



[1] https://tracker.debian.org/news/1530835/doris-removed-from-testing/

Kind regards
--
Antonio Valentino



Bug#1072812: Autofocus not working

2024-06-08 Thread debian-edid

Package: keepassxc
Version: 2.7.7+dfsg.1-3

Autofocus not working after unlocking database. Issue is resolved in 
2.7.8. Update is needed.




Bug#956454: gmsh: Seg fault doing almost anything related to radeonsi_dri.so

2024-06-08 Thread Francesco Ballarin
Package: gmsh
Followup-For: Bug #956454
X-Debbugs-Cc: francesco.balla...@unicatt.it, si...@lma.cnrs-mrs.fr

Hi Fabrice,
can you report the crash upstream, and see what they suggest?

I definitely don't have the expertise to help with that, and maybe not even the
right graphic card to reproduce the crash.

Cheers,
Francesco


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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages gmsh depends on:
ii  libc62.38-12.1
ii  libgmsh4.13  4.13.1+ds1-1

Versions of packages gmsh recommends:
ii  gmsh-doc  4.13.1+ds1-1

gmsh suggests no packages.

-- no debconf information



Bug#956953: cron: add cron jobs to systemd scope cgroups

2024-06-08 Thread Georges Khaznadar
Hello Paul,

I am still missing a feedback about cron 3.0pl1-190

If you are still interested in having the new feature some day in
debian/testing (and later in debian/stable), I would appreciate to get
a ping, even if you are currently too busy to make tests.

Thank you in advance,   Georges.

On Thu, 23 May 2024 14:26:23 +0200 Georges Khaznadar 
 wrote:
> I uploaded a new cron release (3.0pl1-190) to experimental.
> 
> Please can you test this release?
> ... 


signature.asc
Description: PGP signature


Bug#1070702: bookworm-pu: package nano/7.2-1+deb12u1

2024-06-08 Thread Salvatore Bonaccorso
Hi Jordi,

On Tue, May 07, 2024 at 04:00:15PM +0200, Jordi Mallach wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> X-Debbugs-Cc: n...@packages.debian.org
> Control: affects -1 + src:nano
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> As we did in previous Debian releases, this is an update
> for Debian stable's nano package with selected patches from
> the upstream maintainer.
> 
> 3 of the patches minor security issues, and the other one
> fixes a potential data-loss issue.
> 
> Additionally there's a minor update to the default nanorc which
> is a backport from 7.2-2, which was meant to be included in
> Debian 12.0 but freeze came along. It just gets rid of some
> control characters in some commented-out example bindings,
> replacing them with the new style syntax.
> 
> [ Checklist ]
>   [x] *all* changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in (old)stable
>   [x] the issue is verified as fixed in unstable
> 
> This source update was prompted by Salvatore while discussing one of the
> 3 security issues.

FTR,
https://git.savannah.gnu.org/cgit/nano.git/commit/?id=5e7a3c2e7e118c7f12d5dfda9f9140f638976aa2
has now as well a CVE assigned: CVE-2024-5742. But no need to redo an
upload, but would be great to get it accepted for the next point
release.

Regards,
Salvatore



Bug#1072743: texlive-extra-utils: pdfxup: --pages option fails if page range omits start or end of range

2024-06-08 Thread Hilmar Preuße
08.06.2024 10:25:00 Sanjoy Mahajan :

> Yes, I'll be happy to discuss it with upstream.
> Should I CC you?  Or just update the Debian bug as needed?
> 
> -Sanjoy
> 
> On 2024-06-07 15:48, Preuße, Hilmar  wrote:
> 
>> On 07.06.2024 13:09, Sanjoy Mahajan wrote:
>> 
>> Hi,
>> 
>>> The man entry for pdfxup says that --pages can handle an omitted start
>>> or end of range, e.g. "--pages 2-" or "--pages -5".  However, using the
>>> following pdf file as a test (it's one page long) gives an error
>>> if either the start or end of the range is omitted.
>>> 
>> Are you willing to discuss this with the upstream author?
>> 
>> https://www.ctan.org/tex-archive/support/pdfxup
>> 
>> Thanks,
>>    Hilmar
>> -- 
>> sigfault
I'm one of the TL maintainers, so keeping the bug in Cc is sufficient. Thanks.

Hilmar



Bug#1062180: rust-eyre: please update to v0.6.11

2024-06-08 Thread Jonas Smedegaard
Control: severity -1 important

The crate eyre 0.6.8 is several years old by now, and lacks several
features introduced since then. Therefore raising severity.

Updating seems uncomplicated.
Please update, or at least respond with an explanation why it is left
as-is.

 - Jonas

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

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

signature.asc
Description: signature


Bug#1072743: texlive-extra-utils: pdfxup: --pages option fails if page range omits start or end of range

2024-06-08 Thread Sanjoy Mahajan
Yes, I'll be happy to discuss it with upstream.
Should I CC you?  Or just update the Debian bug as needed?

-Sanjoy

On 2024-06-07 15:48, Preuße, Hilmar  wrote:

> On 07.06.2024 13:09, Sanjoy Mahajan wrote:
>
> Hi,
>
>> The man entry for pdfxup says that --pages can handle an omitted start
>> or end of range, e.g. "--pages 2-" or "--pages -5".  However, using the
>> following pdf file as a test (it's one page long) gives an error
>> if either the start or end of the range is omitted.
>> 
> Are you willing to discuss this with the upstream author?
>
> https://www.ctan.org/tex-archive/support/pdfxup
>
> Thanks,
>Hilmar
> -- 
> sigfault



Bug#1072237: libutempter: integrate with wtmpdb

2024-06-08 Thread Sven Joachim
On 2024-05-30 21:03 +0200, Chris Hofstaedtler wrote:

> Source: libutempter
> Severity: important
>
> Hi,
>
> per the discussion on debian-devel [1], we'll get a Y2038-safe
> replacement for wtmp, named wtmpdb / libwtmpdb etc.
> Please see if your package should integrate with it.
>
> It is unclear to me if non-login-equivalent programs should write to
> wtmpdb or not.

Not the maintainer, but doing so would require installing the wtmptb
database writable by group utmp.  There is also the problem that
libutempter does not have a configurable build system, and you would
probably have to write the code to add wtmpdb support yourself.

Personally I would be inclined to say that non-login sessions should not
be recorded in wtmpdb and call it a day.

Cheers,
   Sven



Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1

2024-06-08 Thread John Paul Adrian Glaubitz
Hi,

On Sat, 2024-06-08 at 09:15 +0200, Chris Hofstaedtler wrote:
> > > I will take care of this myself. Please remove the upload.
> 
> Done.

Thanks.

> 
> > I will try to fix the package tomorrow. Apologies for the delay.
> 
> I'll take this opportunity to point out #1060195, a similar bug in
> hfsprogs.

Thanks for the reminder. Appreciate it.

Adrian

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



Bug#1072811: www.debian.org: Bug reporting guides have poor coverage on modifiers and some incomprehendable language

2024-06-08 Thread Manny
Package: www.debian.org
Severity: normal
X-Debbugs-Cc: debbug.www.debian@sideload.33mail.com

I was looking for the meaning of the “quiet” modifier
(e.g. -qu...@bugs.debian.org). Navigation of the BTS
documentation is always painful. I often just have to control-click
links arbitrarily because the links to other pages are vaguely
described. That said, I started here:

  https://www.debian.org/Bugs/server-refcard

The bottom of that page merely mentions the existence of the
“nnn-quiet” modifier. No description and no link to a description.

I would expect some mention of it here:

  https://www.debian.org/Bugs/server-control

but there is no mention of -quiet there. I could only find a blurb
about -quiet here:

  https://www.debian.org/Bugs/Developer

So the -quiet modifier is described inside the paragraph that talks
about an obsolete variation. And the English is rough:

  “It used to be possible to prevent the bug tracking system from
   forwarding anywhere messages it received at debian-bugs, by putting
   an X-Debian-PR: quiet line in the actual mail header.”

What is meant by “forwarding anywhere messages”?  That needs to be
rewritten.

There is also an oversight with the bug closure procedure. The control
command “close” is described¹ as:

  “close bugnumber [ fixed-version ] (deprecated)”

The reason for deprecation neglects a use case. That is, it’s
deprecated to promote a process that ensures the submitter receives
rationale for the closure. And rightfully so, but this neglects the
case where the submitter closes their own bug report, which usually
means the report was opened erroneously. Often this happens early,
before maintainers have interacted. I’ll stop short of prescribing a
BTS process, but in any case the documentation needs to cover the
scenario of a submitter who needs to close an erroneous report. In
principle, the closure of erroneous submissions should be as quiet as
possible, so as to not make further noise in people’s inboxes with
more forwarded messages (possibly via the -quiet modifer and using the
deprecated “close” control command, not sure).

¹ https://www.debian.org/Bugs/server-control



Bug#1061200: transition: vtk9

2024-06-08 Thread Anton Gladky
Uploaded and built on all relevant platforms.
Please, schedule the rebuild.

Thank you.

Anton


Am So., 2. Juni 2024 um 13:10 Uhr schrieb Sebastian Ramacher <
sramac...@debian.org>:

> Control: tags -1 confirmed
>
> On 2024-01-20 18:15:32 +0100, Anton Gladky wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: v...@packages.debian.org
> > Control: affects -1 + src:vtk9
> >
> >
> > Dear release team,
> >
> > please schedule vtk9.3 transition.
> >
> > Ben file:
> >
> > title = "vtk9";
> > is_affected = .depends ~ "libvtk9\.1|libvtk9\.1\-qt" | .depends ~
> "libvtk9\.3|libvtk9\.3\-qt";
> > is_good = .depends ~ "libvtk9\.3|libvtk9\.3\-qt";
> > is_bad = .depends ~ "libvtk9\.1|libvtk9\.1\-qt";
> >
> > I have done a full rebuild and some failures are detected. Bugs (most of
> them with patches) will
> > be filed in the next time.
>
> Please go ahead.
>
> Cheers
> --
> Sebastian Ramacher
>


Bug#1072782: kristall: Enormous gaps between words

2024-06-08 Thread Manny
> Thanks for using kristall and filling bugs!

Thanks for supporting Kristall!

> I'm also on wayland but I'm not sure I'm seeing the problem. PS: I think
> I made it happen with DejaVu Sans, although Cantarell was the default one
> here and I don't remember changing it.

Maybe you originally installed an earlier version than 0.4, which
might have had a different default, which then would have stuck
through upgrades. I just installed 0.4 to use Kristall for the first
time, and the default standard font was simply “Sans Serif”/normal/12.

> I will see if I can select a more sensible default font - although I
> discovered people can be very pick about their fonts :-) Can you
> send the exact style you had in your settings and a website I can
> test it to see if we can improve the user experience?

There are many sans serif fonts on my system, which perhaps has a
different catalog of fonts than other Debian systems would have. And
because of that, I wonder if the default might be selected
arbitrarily. In my case, the font that was plainly named “Sans Serif”
was used as the “Standard Font” as well as H1, H2, H3, and
blockquote. This font is a disaster for all of those purposes. I guess
I should assume I have DejaVu* fonts because I installed djvu pkgs,
and TeX* fonts because I installed texlive. So in looking for a
generic and possibly common font, I tried “Latin Modern Roman” as the
standard font, which looks nice. I’m just guessing that’d be widely
available.

I wouldn’t try to cater for people’s personal tastes because the
software is designed to make it easy for users to tune the font. It’s
really just important to get rid of the intolerable default font. It’s
a disaster on every single site/page it renders. I’ll just name
gemini://techrights.org to give an arbitrary example.

Note as well I have in version 0.4 the known defect of blank icons to
the left of the URL field. They at least have a mouseover hover
msg. But in settings»style, all the icons on the right are also blank
and there is no mouseover for them. That was reported upstream in
2022, IIRC. Though I guess Debian is not a good place to fix that one.



Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1

2024-06-08 Thread Chris Hofstaedtler
Hi,

* John Paul Adrian Glaubitz  [240607 22:47]:
> On Fri, 2024-06-07 at 22:14 +0200, John Paul Adrian Glaubitz wrote:
> > On Fri, 2024-06-07 at 21:42 +0200, Chris Hofstaedtler wrote:
> > > I've prepared an NMU for linux-minidisc (versioned as 0.9.16-2.1) and
> > > uploaded it to DELAYED/14. Please feel free to tell me if I
> > > should delay it longer.
> > 
> > I will take care of this myself. Please remove the upload.

Done.

> Sorry for the brevity in my previous mail.

No problem.

> The reason I didn't fix this bug was because I missed the bug notification
> mail, so I wasn't aware this bug was around.
> 
> I will try to fix the package tomorrow. Apologies for the delay.

I'll take this opportunity to point out #1060195, a similar bug in
hfsprogs.

Best,
Chris



Bug#1072810: pytest 8 regression with flaky test plugins

2024-06-08 Thread Chris Peterson
Package: pytest
Version: 8.2.2-1
Severity: important
Tags: patch
X-Debbugs-Cc: chris.peter...@canonical.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch




Hi,

Pytest 8.2.2 introduced a regression in flaky test plugins (e.g.
pytest-rerunfailures and python-flaky) that causes AssertionErrors when
re-running tests in test classes which inherit from unittest.TestCase.
I applied the following patch in Ubuntu to fix the issue.

  * 0003-pytest8-testcase-assertion.patch: Fixes unittest regression in
flaky test plugins (LP: #2068642).

Thanks for considering the patch.


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

Kernel: Linux 6.8.0-31-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru pytest-8.2.2/debian/patches/0003-pytest8-testcase-assertion.patch 
pytest-8.2.2/debian/patches/0003-pytest8-testcase-assertion.patch
--- pytest-8.2.2/debian/patches/0003-pytest8-testcase-assertion.patch   
1969-12-31 16:00:00.0 -0800
+++ pytest-8.2.2/debian/patches/0003-pytest8-testcase-assertion.patch   
2024-06-07 15:23:04.0 -0700
@@ -0,0 +1,48 @@
+Description: Fix unittest regressions for flaky test plugins
+ A change in the behavior of the unittest teardown function caused a
+ regression in plugins that re-ran tests. Namely python-flaky and
+ pytest-rerunfailures. This patch was cherry-picked from an upstream
+ PR.
+Origin: upstream, https://github.com/pytest-dev/pytest/pull/12436
+Bug: https://github.com/pytest-dev/pytest/issues/12424
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/pytest/+bug/2068642
+Forwarded: not-needed
+Last-Update: 2024-06-07
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/_pytest/unittest.py
 b/src/_pytest/unittest.py
+@@ -216,7 +216,7 @@
+ self._explicit_tearDown()
+ self._explicit_tearDown = None
+ self._obj = None
+-self._instance = None
++del self._instance
+ super().teardown()
+ 
+ def startTest(self, testcase: "unittest.TestCase") -> None:
+--- /dev/null
 b/testing/plugins_integration/pytest_rerunfailures_integration.py
+@@ -0,0 +1,11 @@
++import unittest
++
++
++class MyTestCase(unittest.TestCase):
++first_time = True
++
++def test_fail_the_first_time(self) -> None:
++"""Regression test for issue #12424."""
++if self.first_time:
++type(self).first_time = False
++self.fail()
+--- a/tox.ini
 b/tox.ini
+@@ -143,7 +143,7 @@
+ pytest --cov=. simple_integration.py
+ pytest --ds=django_settings simple_integration.py
+ pytest --html=simple.html simple_integration.py
+-pytest --reruns 5 simple_integration.py
++pytest --reruns 5 simple_integration.py 
pytest_rerunfailures_integration.py
+ pytest pytest_anyio_integration.py
+ pytest pytest_asyncio_integration.py
+ pytest pytest_mock_integration.py
diff -Nru pytest-8.2.2/debian/patches/series pytest-8.2.2/debian/patches/series
--- pytest-8.2.2/debian/patches/series  2024-06-05 06:34:35.0 -0700
+++ pytest-8.2.2/debian/patches/series  2024-06-07 09:09:35.0 -0700
@@ -1,2 +1,3 @@
 0001-Use-local-intersphinx-mappings.patch
 0002-Disable-Sphinx-extensions.patch
+0003-pytest8-testcase-assertion.patch


Bug#1063945: ipython: Ubuntu patch for pytest 8 support

2024-06-08 Thread Chris Peterson
Package: ipython
Version: 8.20.0-1
Followup-For: Bug #1063945
X-Debbugs-Cc: chris.peter...@canonical.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch
Control: tags -1 patch



Hi,

I identified two patches from upstream that solved this issue but
aren't available in the currently packaged version. I applied the
following in Ubuntu to solve the issue:

  * Update pytest and tests for pytest 8 compatibility (LP: #2068674).
- d/p/pytest8-nose-tests.patch: update nose-style tests for pytest 8.2+
- d/p/support-pytest-plugin.patch: update pytest plugin for pytest 8.1+


Thanks for considering the patches.


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

Kernel: Linux 6.8.0-31-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ipython-8.20.0/debian/patches/pytest8-nose-tests.patch 
ipython-8.20.0/debian/patches/pytest8-nose-tests.patch
--- ipython-8.20.0/debian/patches/pytest8-nose-tests.patch  1969-12-31 
16:00:00.0 -0800
+++ ipython-8.20.0/debian/patches/pytest8-nose-tests.patch  2024-06-06 
17:10:18.0 -0700
@@ -0,0 +1,32 @@
+Description: Update nose-style tests for pytest 8 compatbility
+ Pytest dropped support for nose-style tests in pytest 8. This patch cherry-
+ picks the patch from upstream to fix the offending tests. This patch can
+ be dropped in version 8.24.0.
+Author: Chris Peterson 
+Origin: upstream, 
https://github.com/ipython/ipython/commit/cdacafdccaf1f562e59b21b3c9f2c1a28eba54da
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/ipython/+bug/2068674
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063945
+Forwarded: not-needed
+Last-Update: 2024-06-06
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/IPython/core/tests/test_pylabtools.py
 b/IPython/core/tests/test_pylabtools.py
+@@ -165,7 +165,7 @@
+ def enable_gui(self, gui):
+ pass
+ 
+-def setup(self):
++def setup_method(self):
+ import matplotlib
+ def act_mpl(backend):
+ matplotlib.rcParams['backend'] = backend
+@@ -184,7 +184,7 @@
+ self._save_cis = backend_inline.configure_inline_support
+ backend_inline.configure_inline_support = lambda *a, **kw: None
+ 
+-def teardown(self):
++def teardown_method(self):
+ pt.activate_matplotlib = self._save_am
+ pt.import_pylab = self._save_ip
+ backend_inline.configure_inline_support = self._save_cis
diff -Nru ipython-8.20.0/debian/patches/series 
ipython-8.20.0/debian/patches/series
--- ipython-8.20.0/debian/patches/series2024-01-14 16:32:19.0 
-0800
+++ ipython-8.20.0/debian/patches/series2024-06-06 17:10:38.0 
-0700
@@ -1,2 +1,4 @@
 0002-Update-intersphinx-links-for-local-access.patch
 0003-Drop-setuptools-data_files.patch
+pytest8-nose-tests.patch
+support-pytest-plugin.patch
diff -Nru ipython-8.20.0/debian/patches/support-pytest-plugin.patch 
ipython-8.20.0/debian/patches/support-pytest-plugin.patch
--- ipython-8.20.0/debian/patches/support-pytest-plugin.patch   1969-12-31 
16:00:00.0 -0800
+++ ipython-8.20.0/debian/patches/support-pytest-plugin.patch   2024-06-06 
17:22:13.0 -0700
@@ -0,0 +1,120 @@
+Description: Update pytest plugin for pytest 8
+ Pytest 8.1 changed the plugin API. This patch cherry-picks the upstream
+ modifications to the plugin for pytest 8.1+ support. This patch can be
+ dropped with upstream version 8.25.0.
+Author: Chris Peterson 
+Origin: upstream, 
https://github.com/ipython/ipython/commit/7df70a3cd79068be6f98596e427d60a5d0cfe5b3
+Bug: https://github.com/ipython/ipython/issues/14390
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/ipython/+bug/2068674
+Forwarded: not-needed
+Last-Update: 2024-06-06
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/IPython/testing/plugin/pytest_ipdoctest.py
 b/IPython/testing/plugin/pytest_ipdoctest.py
+@@ -38,7 +38,11 @@
+ from _pytest.compat import safe_getattr
+ from _pytest.config import Config
+ from _pytest.config.argparsing import Parser
+-from _pytest.fixtures import FixtureRequest
++
++try:
++from _pytest.fixtures import TopRequest as FixtureRequest
++except ImportError:
++from _pytest.fixtures import FixtureRequest
+ from _pytest.nodes import Collector
+ from _pytest.outcomes import OutcomeException
+ from _pytest.pathlib import fnmatch_ex
+@@ -68,6 +72,8 @@
+ # Lazy definition of output checker class
+ CHECKER_CLASS: Optional[Type["IPDoctestOutputChecker"]] = None
+ 
++pytest_version = tuple([int(part) for part in pytest.__version__.split(".")])
++
+ 
+ def 

Bug#1070112: ipykernel: Ubuntu patch for pytest 8 support

2024-06-08 Thread Chris Peterson
Package: ipykernel
Version: 6.29.3-1
Followup-For: Bug #1070112
X-Debbugs-Cc: chris.peter...@canonical.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch
Control: tags -1 patch



Hi,

I applied the following patch in Ubuntu to fix this issue.

  * pytest8-nose-deprecation.patch: update tests for pytest 8 compatibility
(LP: #2068672).


Thanks for considering the patch.


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

Kernel: Linux 6.8.0-31-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ipykernel-6.29.3/debian/patches/pytest8-nose-deprecation.patch 
ipykernel-6.29.3/debian/patches/pytest8-nose-deprecation.patch
--- ipykernel-6.29.3/debian/patches/pytest8-nose-deprecation.patch  
1969-12-31 16:00:00.0 -0800
+++ ipykernel-6.29.3/debian/patches/pytest8-nose-deprecation.patch  
2024-06-06 16:39:16.0 -0700
@@ -0,0 +1,95 @@
+Description: Update tests for pytest 8 compatibility
+ Pytest 8 deprecated support for nose-style tests. This patch cherrry-picks
+ changes from upstream to modify tests to run with pytest 8.
+Author: Chris Peterson 
+Origin: upstream, 
https://github.com/ipython/ipykernel/commit/a7d66ae2197e0d7471ba160542cf5ff7713084b5
+Bug: https://github.com/ipython/ipykernel/issues/1230
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/ipykernel/+bug/2068672
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070112
+Forwarded: not-needed
+Last-Update: 2024-06-06
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/tests/__init__.py
 b/tests/__init__.py
+@@ -7,6 +7,8 @@
+ import tempfile
+ from unittest.mock import patch
+ 
++import pytest
++
+ from ipykernel.kernelspec import install
+ 
+ pjoin = os.path.join
+@@ -15,7 +17,8 @@
+ patchers: list = []
+ 
+ 
+-def setup():
++@pytest.fixture(autouse=True)
++def _global_setup():
+ """setup temporary env for tests"""
+ global tmp
+ tmp = tempfile.mkdtemp()
+@@ -35,8 +38,8 @@
+ # install IPython in the temp home:
+ install(user=True)
+ 
++yield
+ 
+-def teardown():
+ for p in patchers:
+ p.stop()
+ 
+--- a/tests/test_eventloop.py
 b/tests/test_eventloop.py
+@@ -42,14 +42,15 @@
+ _get_qt_vers()
+ 
+ 
+-def setup():
++@pytest.fixture(autouse=True)
++def _setup_env():
+ """start the global kernel (if it isn't running) and return its client"""
+ global KM, KC
+ KM, KC = start_new_kernel()
+ flush_channels(KC)
+ 
++yield
+ 
+-def teardown():
+ assert KM is not None
+ assert KC is not None
+ KC.stop_channels()
+--- a/tests/test_message_spec.py
 b/tests/test_message_spec.py
+@@ -21,7 +21,8 @@
+ KC: BlockingKernelClient = None  # type:ignore
+ 
+ 
+-def setup():
++@pytest.fixture(autouse=True)
++def _setup_env():
+ global KC
+ KC = start_global_kernel()
+ 
+--- a/tests/test_async.py
 b/tests/test_async.py
+@@ -8,14 +8,15 @@
+ KC = KM = None
+ 
+ 
+-def setup_function():
++@pytest.fixture(autouse=True)
++def _setup_env():
+ """start the global kernel (if it isn't running) and return its client"""
+ global KM, KC
+ KM, KC = start_new_kernel()
+ flush_channels(KC)
+ 
++yield
+ 
+-def teardown_function():
+ assert KC is not None
+ assert KM is not None
+ KC.stop_channels()
diff -Nru ipykernel-6.29.3/debian/patches/series 
ipykernel-6.29.3/debian/patches/series
--- ipykernel-6.29.3/debian/patches/series  2024-01-11 14:25:38.0 
-0800
+++ ipykernel-6.29.3/debian/patches/series  2024-06-06 16:22:48.0 
-0700
@@ -1,2 +1,3 @@
 0002-test_simple_print-may-produce-stderr-content-when-ex.patch
 0003-Made-build-reproducible-patch-by-Daniel-Shahaf.patch
+pytest8-nose-deprecation.patch


Bug#1063967: protontricks: Forward pytest 8 support patch from Ubuntu

2024-06-08 Thread Chris Peterson
Package: protontricks
Version: 1.10.5-1
Followup-For: Bug #1063967
X-Debbugs-Cc: chris.peter...@canonical.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oracular ubuntu-patch
Control: tags -1 patch



Hi,

I applied the following patch in Ubuntu to fix this issue.


  * pytest8-caplog.patch: Update tests for pytest 8 compatibility
(LP: #2068659).


Thanks for considering the patch.


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

Kernel: Linux 6.8.0-31-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru protontricks-1.10.5/debian/patches/pytest8-caplog.patch 
protontricks-1.10.5/debian/patches/pytest8-caplog.patch
--- protontricks-1.10.5/debian/patches/pytest8-caplog.patch 1969-12-31 
16:00:00.0 -0800
+++ protontricks-1.10.5/debian/patches/pytest8-caplog.patch 2024-06-06 
12:27:04.0 -0700
@@ -0,0 +1,37 @@
+Description: Update test for pytest 8 comptability
+ Pytest 8 now includes all log levels in the caplog fixture. Apply upstream
+ changes to test case which ensures warning messages are logged. Can be dropped
+ in upstream version 1.11.1
+Author: Chris Peterson 
+Origin: upstream, 
https://github.com/Matoking/protontricks/commit/bb1da5a0ddcac1cbd577fd54fe947ff6ad1731bc
+Bug: https://github.com/Matoking/protontricks/issues/283
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/pytest/+bug/2068659
+Forwarded: not-needed
+Last-Update: 2024-06-06
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/tests/test_gui.py
 b/tests/test_gui.py
+@@ -207,7 +207,7 @@
+ assert steam_app == steam_apps[1]
+ assert (
+ "Your system locale is incapable of displaying all characters"
+-in caplog.records[0].message
++in caplog.records[-1].message
+ )
+ 
+ @pytest.mark.parametrize("gui_cmd", ["yad", "zenity"])
+--- a/tests/conftest.py
 b/tests/conftest.py
+@@ -44,6 +44,11 @@
+ logging.getLogger("protontricks").handlers.clear()
+ 
+ 
++@pytest.fixture(scope="function", autouse=True)
++def default_caplog(caplog):
++caplog.set_level(logging.INFO)
++
++
+ @pytest.fixture(scope="function")
+ def verbose_logging():
+ """
diff -Nru protontricks-1.10.5/debian/patches/series 
protontricks-1.10.5/debian/patches/series
--- protontricks-1.10.5/debian/patches/series   1969-12-31 16:00:00.0 
-0800
+++ protontricks-1.10.5/debian/patches/series   2024-06-06 12:26:50.0 
-0700
@@ -0,0 +1 @@
+pytest8-caplog.patch


Bug#1072809: mk-build-deps: When --host-arch is specified, build dependencies with the "all" arch don't work

2024-06-08 Thread Allen Ding
Package: devscripts
Version: 2.23.4+deb12u1
Severity: normal
X-Debbugs-Cc: al...@ading.dev

When --host-arch is passed into mk-build-deps, the generated package's
dependencies always use the specified architecture. However, this behavior
causes issues when a build dependency has the "all" architecture, since mk-
build-deps will try to install that package for an architecture which doesn't
exist.

To reproduce:
$ git clone --depth=1 https://salsa.debian.org/xorg-team/lib/mesa-amber.git
$ cd mesa-amber
$ mk-build-deps --host-arch arm64
$ apt-get install -y ./*.deb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'mesa-amber-cross-build-deps:arm64' instead of './mesa-amber-
cross-build-deps_21.3.9-1_arm64.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mesa-amber-cross-build-deps:arm64 : Depends: python3:arm64 but it is not going
to be installed
 Depends: python3-mako:arm64 but it is not
installable

In this example, mk-build-deps tries to install python3-mako:arm64, which
doens't exist. The correct package would be python3-mako:all.


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.22
ii  fakeroot  1.31-1.2
ii  file  1:5.44-3
ii  gnupg 2.2.40-1.1
ii  gnupg22.2.40-1.1
ii  gpgv  2.2.40-1.1
ii  libc6 2.36-9+deb12u7
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.68-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-7+deb12u1
ii  python3   3.11.2-1+b1
ii  sensible-utils0.0.17+nmu1
ii  wdiff 1.2.2-5

Versions of packages devscripts recommends:
ii  apt 2.6.1
ii  curl7.88.1-10+deb12u5
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2022.12.24
ii  dput1.1.3
ii  equivs  2.3.1
ii  libdistro-info-perl 1.5+deb12u1
ii  libdpkg-perl1.21.22
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-2
ii  libgitlab-api-v4-perl   0.26-3
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-3
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.17-1
ii  licensecheck3.3.5-1
ii  lintian 2.116.3
ii  man-db  2.11.2-2
ii  patch   2.7.6-7
ii  pristine-tar1.50
ii  python3-apt 2.6.0
ii  python3-debian  0.1.49
ii  python3-magic   2:0.4.26-3
ii  python3-requests2.28.1+dfsg-1
ii  python3-unidiff 0.7.3-1
ii  python3-xdg 0.28-2
ii  strace  6.1-0.1
ii  unzip   6.0-28
ii  wget1.21.3-1+b2
ii  xz-utils5.4.1-0.2

Versions of packages devscripts suggests:
pn  adequate 
pn  at   
ii  autopkgtest  5.28
pn  bls-standalone   
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.11.4
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  elpa-devscripts  
pn  faketime 
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-3
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-3
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
pn  libyaml-syck-perl
ii  

<    5   6   7   8   9   10   11   12   13   14   >