date:20240226

Control: tags -1 + moreinfo

Hi Mathias,

On Tue, Feb 27, 2024 at 01:33:08AM +, Mathias Gibbens wrote:
>   iproute2 is Priority: important, which according to Policy §2.5 means
> that it is generally expected to be present on a Debian system. Do you
> have a specific use case where for some reason you don't have iproute2
> installed?

While that means iproute2 is installed by default, it still does not
mean you can rely on its presence. It is "Essential: yes" that allows
you to skip emitting the dependency. Users are entitled to remove
important packages and often do so.

>   I'm initially reluctant to explicitly list iproute2 as a dependency
> for Incus unless there's some very compelling reason.

I think that it is the failure mode that compells me this to be serious.
When iproute2 is missing all the incus commands hang and you spend a
long time digging why this thing doesn't work at all. If incus were
telling me (on the cli) that iproute2 is missing and offering ways of
working without, I'd see things differently.

Conversely, what is the maintenance cost of having this dependency?

Helmut

Bug#973393: truncate less of the backtrace during failing ert tests

Sean Whitton  writes:

> Hello,
>
> On Mon 26 Feb 2024 at 06:16pm -08, Xiyue Deng wrote:
>
>> Recently when debugging an ERT failure I found that enabling larger
>> backtrace margin by default would be very help.
>
> Hmm, interesting.  Can you show an example where it helps, so I can get
> an idea of what you have in mind?
>

Sure!  As an example, by default ERT output will truncate at 70, which
gives something like:
,
| Select project: Test test-markdown-ext/wiki-link-rules backtrace:
|   completing-read-default("Select project: " #f(compiled-function (str
|   completing-read("Select project: " #f(compiled-function (string pred
|   project-prompt-project-dir()
|   project-current(t)
|   ...
`

With the suggested wider margin, this becomes:
,
| Select project: Test test-markdown-ext/wiki-link-rules backtrace:
|   completing-read-default("Select project: " #f(compiled-function (string 
pred action) #) nil t nil nil nil nil)
|   completing-read("Select project: " #f(compiled-function (string pred 
action) #) nil t)
|   project-prompt-project-dir()
|   project-current(t)
|   ...
`

So that you can see the actual arguments to the calls.

(In my patch I took the liberty to set the new margin as 512 (2**9)
instead of 500 as suggested in the wiki, for pure personal hygiene.)

>> I have tested [1] in my fork to be working.  As dh-elpa doesn't enable
>> merge requests, I'd like to gather some reviews/comments here before
>> merging.  TIA!
>
> I'd be grateful if you'd attach patches to BTS mail in the future, for
> inline review.

Ah indeed.  Attached the patch at EOM as an extra reference.

>
> Thanks for looking into this.

:)

-- 
Xiyue Deng

From f9b87fc4857348b327e09513a2286f25b5389f72 Mon Sep 17 00:00:00 2001
From: Xiyue Deng 
Date: Mon, 26 Feb 2024 17:23:05 -0800
Subject: [PATCH] Use larger margin in backtrace when ERT tests fail (Closes:
 #973393.)

---
 debian/changelog | 8 
 dh_elpa_test | 1 +
 2 files changed, 9 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 9f30538..ae45ff6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+dh-elpa (2.1.2) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Set ert-batch-backtrace-right-margin to 512 to allow meaningful
+backtrace info when ERT tests fail (Closes: #973393.)
+
+ -- Xiyue Deng   Mon, 26 Feb 2024 17:15:53 -0800
+
 dh-elpa (2.1.1) experimental; urgency=medium
 
   * Remove /usr/share/$flavor/site-lisp/elpa (from emacsen-remove)
diff --git a/dh_elpa_test b/dh_elpa_test
index c2504bf..847cf80 100755
--- a/dh_elpa_test
+++ b/dh_elpa_test
@@ -367,6 +367,7 @@ if (@ert_files) {
 my @args = qw{ emacs -batch -Q -l package };
 push @args, ("--eval", "(add-to-list 'package-directory-list \"$dhelpadir\")");
 push @args, ("--eval", "(add-to-list 'package-directory-list \"$elpadir\")");
+push @args, ("--eval", "(setq ert-batch-backtrace-right-margin 512)");
 push @args, ("-f", "package-initialize");
 
 # add the user's load-path entries
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1064344: RFS: vzlogger/0.8.3 ITP #864255

2024-02-26 Thread Joachim Zobel

Hi.

Thanks for taking the time to review my package.

Am Donnerstag, dem 22.02.2024 um 22:58 +0100 schrieb Tobias Frost:
> d/postinst / postrm
>  - When you create a user, it should start with "_" - see policy
> 9.2.1
This has been implemented and is on its way, see 
https://github.com/volkszaehler/vzlogger/pull/628

It was a bit complicated because I need to rename an existing user.
There are installations of the existing native package. I am therefore
unsure if it is good to do this. Going by the letter which is
"When maintainers choose a new hardcoded or dynamically generated
username" the username has already been choosen when the
debian/vzlogger.init script was created.

Since it is a now or never situation and since the number of existing
installations is still low I tend to rename the user. Any opinions are
appreciated.

Sincerely,
Joachim

Bug#1062841: [debian-mysql] Bug#1062841: mariadb: NMU diff for 64-bit time_t transition

2024-02-26 Thread Steve Langasek

On Mon, Feb 26, 2024 at 09:29:53PM -0800, Otto Kekäläinen wrote:
> About this suggested change (penging at
> https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68):

> From the announcement message
> https://lists.debian.org/debian-devel-announce/2024/02/msg0.html
> lists we can find in
> https://people.canonical.com/~vorlon/armhf-time_t/source-packages
> lists:
> ```
> mariadb: libmariadbd19
> ```

> However nothing about MariaDB is elsewhere. This finding about
> libmariadbd19 seems like a false positive as nothing depends on it.

Lack of reverse-dependencies in the Debian archive doesn't make it a
false-positive.  It exists as a runtime library package; third party
packages including local packages on end-user systems could link against it.

> The library is used for building embedded servers and typically
> statically linked. I am not inclined to merge this change unless
> somebody points out some additional motivations why it is needed.

> If the libmariadb3 package was affected, it would be another story,
> but this libmariadbd19 is not worth renaming.

If it's inconsequential then I don't know why you care what its name is?

If it's "typically statically linked" you could stop shipping the .so
altogether, which I think is a better outcome overall for system quality if
you don't want to support it as a shared library.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1062841: [debian-mysql] Bug#1062841: mariadb: NMU diff for 64-bit time_t transition

2024-02-26 Thread Otto Kekäläinen

About this suggested change (penging at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68):

>From the announcement message
https://lists.debian.org/debian-devel-announce/2024/02/msg0.html
lists we can find in
https://people.canonical.com/~vorlon/armhf-time_t/source-packages
lists:
```
mariadb: libmariadbd19
```

However nothing about MariaDB is elsewhere. This finding about
libmariadbd19 seems like a false positive as nothing depends on it.
The library is used for building embedded servers and typically
statically linked. I am not inclined to merge this change unless
somebody points out some additional motivations why it is needed.

If the libmariadb3 package was affected, it would be another story,
but this libmariadbd19 is not worth renaming.

Bug#1064765: prometheus: FTBFS: dh_auto_test error

2024-02-26 Thread Daniel Swarbrick

It appears that bumping prometheus/common to 0.47.0 in the prometheus 
go.mod will reproduce the test failure.


prometheus/common 0.46.0 and earlier does not provoke the test failure.



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064877: fwupd: conffiles not removed: /etc/fwupd/remotes.d/vendor.conf

2024-02-26 Thread Paul Wise

Package: fwupd
Version: 1.9.13-1
Severity: normal
Control: found -1 1.9.14-1
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

   $ p=fwupd ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | grep 
obsolete
   fwupd: obsolete-conffile /etc/fwupd/remotes.d/vendor.conf
    /etc/fwupd/remotes.d/vendor.conf f151586eb5757246ab97aa61ac4773be obsolete
   
-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages fwupd depends on:
ii  adduser    3.137
ii  libarchive13   3.7.2-1
ii  libc6  2.37-15
ii  libcbor0.10    0.10.2-1.1
ii  libcurl3-gnutls    8.5.0-2
ii  libflashrom1   1.3.0-2.1+b1
ii  libfwupd2  1.9.13-1
ii  libglib2.0-0   2.78.3-2
ii  libgnutls30    3.8.3-1
ii  libgudev-1.0-0 238-3
ii  libgusb2   0.4.8-1
ii  libjcat1   0.2.0-2
ii  libjson-glib-1.0-0 1.8.0-2
ii  liblzma5   5.4.5-0.3
ii  libmbim-glib4  1.30.0-1
ii  libmbim-proxy  1.30.0-1
ii  libmm-glib0    1.22.0-3
ii  libpolkit-gobject-1-0  124-1
ii  libprotobuf-c1 1.4.1-1+b1
ii  libqmi-glib5   1.34.0-2
ii  libqmi-proxy   1.34.0-2
ii  libsqlite3-0   3.45.1-1
hi  libsystemd0    254.5-1
ii  libtss2-esys-3.0.2-0   4.0.1-7
ii  libxmlb2   0.3.14-2
ii  shared-mime-info   2.4-1
ii  zlib1g 1:1.3.dfsg-3+b1

Versions of packages fwupd recommends:
ii  bolt   0.9.6-2
ii  dbus   1.14.10-4
ii  fwupd-amd64-signed [fwupd-signed]  1:1.4+1
ii  jq 1.7.1-2
ii  python3    3.11.6-1
pn  secureboot-db  
ii  udisks2    2.10.1-5

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#973393: truncate less of the backtrace during failing ert tests

2024-02-26 Thread Sean Whitton

Hello,

On Mon 26 Feb 2024 at 06:16pm -08, Xiyue Deng wrote:

> Recently when debugging an ERT failure I found that enabling larger
> backtrace margin by default would be very help.

Hmm, interesting.  Can you show an example where it helps, so I can get
an idea of what you have in mind?

> I have tested [1] in my fork to be working.  As dh-elpa doesn't enable
> merge requests, I'd like to gather some reviews/comments here before
> merging.  TIA!

I'd be grateful if you'd attach patches to BTS mail in the future, for
inline review.

Thanks for looking into this.

-- 
Sean Whitton

signature.asc
Description: PGP signature

Bug#1064866: python-geopandas: please remove dependencies on obsolete libraries python3-six & python3-mock

2024-02-26 Thread Sebastiaan Couwenberg


Control: tags -1 pending

Fixed in git.

Kind Regards,

Bas

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

Bug#1064876: RFS: openjph/0.10.3-1 [Team] -- HTJ2K image compression/decompression library (documentation files)

2024-02-26 Thread 肖盛文


Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : openjph
Version : 0.10.3-1
Upstream contact : Aous Naman 
* URL : https://github.com/aous72/OpenJPH
* License : BSD-2
* Vcs : https://salsa.debian.org/debian-phototools-team/openjph
Section : libs

The source builds the following binary packages:

libopenjph0.10 - HTJ2K image compression/decompression library (runtime 
files)
libopenjph-dev - HTJ2K image compression/decompression library 
(developer files)
openjph-tools - HTJ2K image compression/decompression library (command 
line tools)
openjph-doc - HTJ2K image compression/decompression library 
(documentation files)


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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/o/openjph/openjph_0.10.3-1.dsc


Changes since the last upload:

openjph (0.10.3-1) unstable; urgency=medium
.
* Team upload.
* New upstream version
* Add salsa-ci file (routine-update)
* d/control:
- Build-Depends: delete ninja-build
- binary package libopenjph0.9 rename to libopenjph0.10
* rm d/libopenjph0.9.install d/libopenjph0.9.symbols.amd64
* add d/libopenjph0.10.install
* add d/libopenjph0.10.symbols
* add d/clean
* d/rules:
- remove override_dh_clean-arch override_dh_clean-indep target
- use execute_after_dh_auto_build target
- use execute_before_dh_installman target
- use "dh $@" only, remove "--buildsystem=cmake+ninja"
* d/copyright:
- update year info to 2024
- delete Files-Excluded field, useless
- add Upstream-Contact: Aous Naman 

Regards,

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064380: RFS: jpeginfo/1.7.1-1 [Team] -- Prints information and tests integrity of JPEG/JFIF files

2024-02-26 Thread 肖盛文


Hi Bastian:

    I'd tag the latest commit including your commit.

But I'm not very agree your last commit:

https://salsa.debian.org/debian-phototools-team/jpeginfo/-/commit/7d5f3daf819494824b81676255c54e42cde4b77d

debian/source$ cat options
extend-diff-ignore = "jpeginfo.h"

This commit there is a shortcoming, that is any change in jpeginfo.h 
will not find by dpkg-source.


The string " $Id: hash $" in "jpeginfo.h" file is almost not change in 
upstream.

Even this string changed in upstream, it will not affect do deb package.

IMHO, this commit is not necessarily.

在 2024/2/27 06:03, Bastian Germann 写道:
Uploaded. I have removed your debian/1.7.1+dfsg-1 tag. Please tag the 
latest commit including my commit.

Regards,

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#973393: truncate less of the backtrace during failing ert tests

Control: tags -1 patch

Hi,

Recently when debugging an ERT failure I found that enabling larger
backtrace margin by default would be very help.  I have tested [1] in my
fork to be working.  As dh-elpa doesn't enable merge requests, I'd like
to gather some reviews/comments here before merging.  TIA!

[1] 
https://salsa.debian.org/manphiz/dh-elpa/-/compare/master...master?from_project_id=18920
-- 
Xiyue Deng

Bug#1064874: wrong behaviour when unsetting/setting some variables

2024-02-26 Thread Christoph Anton Mitterer

Package: dash
Version: 0.5.12-6
Severity: normal
Tags: upstream


Hey.

POSIX describes[0] unset to:
> unset values and attributes of variables and functions

While the exact detials are perhaps a bit unclear (see the discussion at [1], I
think it is rather clear that unset, on a variable that has no readonly 
attribute,
shall case the variable/value binding AND any attributes to be unset.


This works as expected in dash for most variables, but not some, e.g.:
$ env -i dash
$ export
export PWD='/home/calestyo'
$ export MAIL
$ export
export MAIL
export PWD='/home/calestyo'
$ unset -v MAIL
$ export
export MAIL
export PWD='/home/calestyo'
$ 

Same for MAILPATH and PATH, which made me believe it's perhaps an issue
in `changemail` and `changepath` as given in the struct `varinit` in src/var.c.
But it also happens with IFS, PS1, PS2 and PS4, which have no function listed 
there.
OTOH, it doesn’t happen with ATTY, TERM, LINENO and HISTSIZE.

The consequence of that is at least, that one has no chance to fully unset these
variables, and even if they loose their value, they’ll be exported to executed
commands, possibly altering their behaviour.


I think a similar problem exists when using local variables, but there it's even
worse as it seems to affect any variable names:
```
f()
{
export
echo

local FOO=v
export FOO
export
echo

unset -v FOO
export
}

f
```
gives:
```
export PWD='/home/calestyo'

export FOO='v'
export PWD='/home/calestyo'

export FOO
export PWD='/home/calestyo'

```
and presumaby that `FOO` would then be exported to executed commands.


Cheers,
Chris.


[0] 
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#unset
[1] https://austingroupbugs.net/view.php?id=1806

Bug#1060459: scalpel: Scalpel not working on Apple Silicon

2024-02-26 Thread Arnaud Rebillout

Hello, and thanks for reaching out!

On Thu, 11 Jan 2024 13:44:03 -0600 "Golden G. Richard III" 
 wrote:

> I have placed updated source distros for Scalpel 1.60 as well as the
> newer (and more powerful) Scalpel 2.02 on GitHub via
> https://github.com/nolaforensix/scalpel-1.60 and
> https://github.com/nolaforensix/scalpel-2.02. My recommendation is to
> rebuild the 1.60 package from the updated source and also consdering
> adding 2.02.

I have updated the package to latest commit on 
https://github.com/nolaforensix/scalpel-1.60.

I will consider packaging the 2.02 when I have a bit of time, this week 
or next week hopefully.

Best,

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1064097: heimdal: NMU diff for 64-bit time_t transition

2024-02-26 Thread Brian May

Steve Langasek  writes:

> Please find the patch for this NMU attached.

I added these patches to the github repo at
https://salsa.debian.org/debian/heimdal/ in the debian/experimental
branch.

Wondering if it still makes sense to have the -heimdal prefix in the
library package names. Sort of have conflicting opinions here. But if we
wanted to get rid of them, now would probably be a really good time.
-- 
Brian May @ Debian

Bug#1064852: incus: missing depends on iproute2

2024-02-26 Thread Mathias Gibbens

Control: tags -1 + moreinfo

Hi Helmut,

  iproute2 is Priority: important, which according to Policy §2.5 means
that it is generally expected to be present on a Debian system. Do you
have a specific use case where for some reason you don't have iproute2
installed?

  I'm initially reluctant to explicitly list iproute2 as a dependency
for Incus unless there's some very compelling reason.

Mathias


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

Bug#1064851: 4 packages from emacs have an undeclared file conflict on /usr/bin/emacsclient.emacs

2024-02-26 Thread Sean Whitton

control: tag -1 - moreinfo + pending

Hello,

On Tue 27 Feb 2024 at 09:17am +08, Sean Whitton wrote:

> Hmm, I added Breaks/Replaces, and piuparts is happy.  Requesting manual
> review.  Thank you.

Ah, my relations were missing the 1: epoch.  Uploading shortly.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1064851: 4 packages from emacs have an undeclared file conflict on /usr/bin/emacsclient.emacs

2024-02-26 Thread Sean Whitton

control: tag -1 + moreinfo

Hello,

On Mon 26 Feb 2024 at 06:26pm +01, Helmut Grohne wrote:

> 4 packages from emacs have an undeclared file conflict. This may result
> in an unpack error from dpkg.
>
> The file /usr/bin/emacsclient.emacs is contained in the packages
>  * emacs-bin-common
>* 1:27.1+1-3.1+deb11u1 as present in bullseye
>* 1:27.1+1-3.1+deb11u2 as present in bullseye-security
>* 1:28.2+1-15 as present in bookworm
>* 1:29.1+1-5 as present in trixie
>* 1:29.1+1-5~bpo12+1 as present in bookworm-backports
>  * emacs-gtk/1:29.2+1-1 as present in unstable
>  * emacs-lucid/1:29.2+1-1 as present in unstable
>  * emacs-nox/1:29.2+1-1 as present in unstable
>  * emacs-pgtk/1:29.2+1-1 as present in unstable
>
> These packages can be unpacked concurrently, because there is no
> relevant Replaces or Conflicts relation. Attempting to unpack these
> packages concurrently results in an unpack error from dpkg, because none
> of the packages installs a diversion for the affected file.

Hmm, I added Breaks/Replaces, and piuparts is happy.  Requesting manual
review.  Thank you.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1062065:

Here is a patch with the sections that get confused by in-tree symlinks
hacked out. I assume the package still ftbfs though.


nmu_ceph.debdiff
Description: Binary data

Bug#1063653: Acknowledgement (anope: Please ship new upstream version)

2024-02-26 Thread Victor Coss

Now the latest version is 2.0.15 which includes even more bug fixes 
including a more concerning race condition. 
https://www.anope.org/news/2024/anope-2015-release.html


Would greatly appreciate it if you can package the updated version.

Kind Regards,
Victor Coss

On 2/10/2024 10:27 AM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

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

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Dominic Hargreaves 

If you wish to submit further information on this problem, please
send it to 1063...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Bug#1062246:

Here's an updated diff that strips the abi tag rather than appending to it.


nmu_libcdk5.debdiff
Description: Binary data

Bug#1064873: O: osdlyrics -- Show synchronized lyrics with various media players

2024-02-26 Thread Boyuan Yang

Package: wnpp
Control: affects -1 + src:osdlyrics
X-Debbugs-Cc: osdlyr...@packages.debian.org
Severity: normal

I intend to orphan the osdlyrics package due to the lack of interest
of this package.

The package description is:
 OSD Lyrics is a standalone desktop application to view lyrics. It is
 compatible with various media players. It shows lyrics on your desktop
 in the style similar to KaraOK. It also provides the feature to download
 lyrics from the Internet automatically.

Thanks,
Boyuan Yang


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

Bug#1064872: O: libuser -- user and group account administration library - utilities

2024-02-26 Thread Boyuan Yang

Package: wnpp
Control: affects -1 + src:libuser
X-Debbugs-Cc: libu...@packages.debian.org
Severity: normal

I intend to orphan the libuser package. It will need some further work,
including the RFH bug as documented at https://bugs.debian.org/1023564
for LDAP support.

The package description is:
 The libuser library implements a standardized interface for manipulating
 and administering user and group accounts.  The library uses pluggable
 back-ends to interface to its data sources.
 .
 Sample applications modeled after those included with the shadow password
 suite are included: lchsh, lchfn, lid, lnewusers, lgroupadd, luseradd,
 lgroupdel, luserdel, lusermod, lgroupmod, lchage and lpasswd.

Thanks,
Boyuan Yang


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

Bug#1064871: O: lightyears -- single player real-time strategy game with steampunk sci-fi

2024-02-26 Thread Boyuan Yang

Package: wnpp
Control: affects -1 + src:lightyears
X-Debbugs-Cc: lightye...@packages.debian.org
Severity: normal

I intend to orphan the lightyears package due to the lack of interest
to this packge. The upstream development is not very active, but upstream
is accessible via GitHub.

The package description is:
 You have to build and maintain a steam distribution network on an alien
 planet, while under attack from aliens and other hazards. The game has
 three difficulty levels, an interactive tutorial, and a scoring system.
 .
 "20.000 Light Years Into Space" is written in Python using pygame.
 It was rewarded with the second place in the Pyweek March 2006 Individual
 Entries category.

Thanks,
Boyuan Yang


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

Bug#1061863:

Additional testing showed that the previous patch was incomplete, here is
an updated one.


nmu_ace.debdiff
Description: Binary data

Bug#1064854: Breaks tex-common's configuration

2024-02-26 Thread Preuße


Control: affects -1 texlive-binaries
Control: merge -1 1064402
Control: affects -1 context



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064854: Breaks tex-common's configuration

2024-02-26 Thread Preuße


Control: reassign -1 luametatex
Control: severity -1 grave
Control: merge -1 1064402
Control: affects -1 context

On 26.02.2024 18:50, julien.pu...@gmail.com wrote:

Hi,


since a few days, I saw a configuration issue with the tex-common
package. (What I don't get is why it actually needs configuration since
I don't see uploads since months.)



No, it is in the upgraded luametatex, which is for the upcoming TL 2024 
and should have been uploaded to experimental. Downgrade it and put it 
on hold. apt-listbugs is helpful here. Sorry, for the inconvenience!


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064783: apt-listbugs: installs same filename to both bin and sbin

2024-02-26 Thread Francesco Poli

Control: tags -1 - moreinfo
Control: severity -1 wishlist

On Mon, 26 Feb 2024 11:08:29 + ca...@allfreemail.net wrote:

> Source: apt-listbugs
> Followup-For: Bug #1064783
> 
> > The command 'apt-listbugs' is installed to /usr/bin and a symbolic link
> > to it is installed to /usr/sbin .
> 
> You are correct, and on a filesystem where those locations are the same
> it causes unpacking errors.

Yes, that's clear.

> 
> > This layout is not currently supported by Debian, as far as I can tell.
> 
> It is not yet supported on debian, but using debootstrap instead of
> debian-installer makes it possible to create such a filesystem layout.
> This is currently useful for testing how adding /usr/sbin to default
> user $PATH would break, and how merging /usr/sbin and /usr/bin would
> break.
> 
> > Which distributions?
> 
> Archlinux has had merged bin and sbin for a number of years. Fedora is
> going in that direction soon and made a nice writeup on 
> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin

An interesting read, although some of the considerations do not seem to
apply to Debian.

For instance, as far as I can see, in Debian the superuser (root) gets
a different default $PATH (which includes sbin directories), with
respect to regular users (who, by default, do not have sbin directories
in their $PATH). Hence, I would say that the distinction between /bin
and /sbin is not meaningless in Debian...

> 
> > I am not aware of any plans in Debian to move in that direction.
> 
> So far it has been briefly discussed in the -devel channel on IRC and
> the idea has been received mostly well. There are bigger problems with
> it, such as different packages having undeclared file conflicts if the
> sbinmerge happenen, however it is a nice low-hanging fruit to first fix
> the few packages where the one package unpacks the same file (or
> symlink) to both bin and sbin.

I see, but I am a bit worried of breaking scripts with hardcoded paths.

> 
> > See the [usrmerge FAQ], which includes, in part:
> 
> You are correct, this is not about the current usrmerge. It could be called
> usrmerge2.0 or sbinmerge or some other term.

OK, let's call it sbinmerge, then.

> 
> > Could you please elaborate a bit more on why you think this feature of
> > the apt-listbugs Debian package could be an issue?
> 
> On a filesystem where bin and sbin are merged, it causes an unpacking
> error during installation of the package, due to the symlink trying to
> overwrite the real file, or the real file overwriting the symlink. It is
> in a way a file conflict - it can be silenced by passing the right flags
> to the commands, but it is better to fix it properly.

Sorry, I wasn't clear: I understand why unpacking conflicting files
across /sbin and /bin causes issues on a system where /sbin and /bin
are the same directory.

I was asking you to elaborate on why this could be an issue in Debian,
which does not currently support a layout where /sbin and /bin are the
same directory.
And the answer (judging from the rest of your reply) is basically
"because some people in Debian are considering the possibility to
merge /sbin and /bin in some unspecified future, and it would be nice,
if as few packages as possible hampered this possible transition".

> 
> > Which other distributions (Debian-derivatives or otherwise) include
> > apt-listbugs?
> 
> I don't know of any.
> 
> > I am a bit hesitant to do so (risking to break random custom scripts),
> > unless there's a good reason.
> 
> The idea of merging bin and sbin is exactly to help with random custom
> scripts, because if bin and sbin are the same directory, then it doesn't
> matter if only bin or only sbin is in $PATH, or if the executable is
> called directly using hardcoded /usr/bin/apt-listbugs or /usr/sbin/listbugs,
> because both ways will then work instead of giving "command not found"
> errors.
> 
> However I agree that in the meantime some random script somewhere could
> break, and so such a change might warrant a NEWS entry.

Exactly, I am a bit worried about the meantime.

However, you replied to my questions (that's why I am dropping the
'moreinfo' tag).
It's now clear to me, that you are not asking me to modify apt-listbugs
for other distributions, but to simplify a possible future sbinmerge in
Debian.
That sounds like a legitimate feature request (hence severity
'wishlist').

I will think about it.
Bye!

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

pgpGJRNrIwPsh.pgp
Description: PGP signature

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

2024-02-26 Thread Miguel Landaeta

On Thu, Feb 22, 2024 at 09:46:00PM +, Amin Bandali wrote:
> On Thu, Feb 22, 2024 at 09:23:20PM +, Miguel Landaeta wrote:
> > On Thu, Feb 22, 2024 at 02:19:21AM +, Amin Bandali wrote:
> > > Hi Miguel,
> > > 
> > > I'm interested in helping with this.  Do you have the current state 
> > > of your work available on Salsa or elsewhere that I could pull in
> > > and work on?  Otherwise I'll just start with a repo under my own
> > > account and we could later transfer it to the 'debian' group or
> > > elsewhere.
> > 
> > Hi Amin, thanks for reaching out.
> > 
> > I'll push my repo tomorrow or during the weekend to salsa and
> > update this thread with the link.

Hi again Amin,

I just pushed my repo to Salsa:

https://salsa.debian.org/debian/qbe

The package builds fine on my machine but I didn't test this
qbe release yet with hare. I'll try to do that tomorrow when I push
my hare repo as well.

I think qbe is almost ready for an upload but it's missing a man page
and probably just need a review from another DD to be sure I didn't
miss anything important.

Cheers,
Miguel.


-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche

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

2024-02-26 Thread Matthias Geiger

On Mon, 26 Feb 2024 16:08:57 +0330 Danial Behzadi 
 wrote:

> Thanks for clarifying. I added the comment, but the Files-Excluded part
> will trigger a source-ships-excluded-file error, as I replaced the old

> non-free file with a new free one in DFSG source branch.

Ah, I see. The best solution is here to add the train sound under a 
slightly different name then and patch the source accordingly. This way 
you can still import the dfsg'd tarballs. Let me know if you need help 
with this.

--

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

OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064656: mini-httpd violates RFC3875 for NPH-CGIs

2024-02-26 Thread Alexandru Mihail

Hello again,> Dear Maintainer,
> 
> mini-httpd as currently found in 
> https://salsa.debian.org/debian/mini-httpd/-
> /blob/master/mini_httpd.c?ref_type=heads 
> violates the CGI RFC (RFC-3875). The RFC specifies in "5.2 NPH
> Response" 
> that an "NPH  script MUST return a complete HTTP response message",
> and 
> more "The server MUST ensure that the script output is sent to the 
> client unmodified." But mini-http actually DOES modify the HTTP
> response 
> from NPH CGIs. It prefixes the script output with a fixed "HTTP/1.0
> 200 
> OK" header, even if the NPH CGI wants to report a different status.
> This 
> happens only if SSL is active.
Acknowledged, thanks for the test case and proposed solution. This will
be incorporated into mini-httpd-1.30.9. 

Thanks for your contribution to Debian,

Alexandru Mihail,
mini-httpd maintainer

Bug#1064858: python-astroplan-doc: please make the package build reproducible.

2024-02-26 Thread James Addison

Followup-For: Bug #1064858
Control: forwarded -1 
https://salsa.debian.org/debian-astro-team/astroplan/-/merge_requests/2

Merge request opened; it appears that there is one more reproducibiliy issue
remaining in the SVG output from matplotlib: the ID generation scheme for
some clipPath elements varies between builds.  Some further investigation of
this is required.

Bug#1064870: thunar: Thunar 100% CPU usage sshfs

2024-02-26 Thread David Christensen

Package: thunar
Version: 4.16.8-1
Severity: important
X-Debbugs-Cc: dpchr...@holgerdanske.com

Dear Maintainer,

When using Thunar to browse a file system mounted via sshfs, Thunar
sometimes triggers 100% usage of all CPU's.  This persists until Thunar
is killed:

2024-02-26 13:26:03 dpchrist@laalaa ~
$ ps -A | grep -i thunar
   1565 ?00:00:00 panel-27-thunar
   1624 ?00:29:18 Thunar

2024-02-26 13:26:08 dpchrist@laalaa ~
$ kill 1624


David



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

Kernel: Linux 5.10.0-28-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, 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

Versions of packages thunar depends on:
ii  desktop-file-utils   0.26-1
ii  exo-utils4.16.0-1+deb11u1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u8
ii  libcairo21.16.0-5
ii  libexo-2-0   4.16.0-1+deb11u1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1+deb11u1
ii  libgtk-3-0   3.24.24-4+deb11u3
ii  libgudev-1.0-0   234-1
ii  libice6  2:1.0.10-1
ii  libnotify4   0.7.9-3
ii  libpango-1.0-0   1.46.2-3
ii  libsm6   2:1.2.3-1
ii  libthunarx-3-0   4.16.8-1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  libxfconf-0-34.16.0-2
ii  shared-mime-info 2.0-1
ii  thunar-data  4.16.8-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.28-0+deb11u1
ii  gvfs  1.46.2-1
ii  libxfce4panel-2.0-4   4.16.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7
ii  thunar-volman 4.16.0-1
ii  tumbler   4.16.0-1
ii  udisks2   2.9.2-2+deb11u1
ii  xdg-user-dirs 0.17-2

Versions of packages thunar suggests:
pn  gvfs-backends 
ii  thunar-archive-plugin 0.4.0-2
ii  thunar-media-tags-plugin  0.3.0-2

-- no debconf information

Bug#1064598: yagv: crashes with "module 'pyglet.graphics' has no attribute 'vertex_list'"

2024-02-26 Thread Gregor Riepl


Hi,


AttributeError: module 'pyglet.graphics' has no attribute 'vertex_list'


I suspect this may not be trivial to fix.

yagv depends on pyglet 1.x, which relies on the OpenGL fixed function 
pipeline. Debian has switched to 2.x and no longer supports this. [1]


Unfortunately, it appears that upstream project is dead.
The last commit was in 2017, and any requests by @pere on their bug 
tracker fell on deaf ears: [2]


It's regrettable, but I don't think yagv can be kept with the current 
situation.


As you might right recall, I offered to help with a similar situation in 
printrun, but this got stuck due to the significant effort required and 
a lack of time on my side. It's unlikely that I would be able to help 
with yagv either at the moment.


Sorry...


[1] https://pyglet.readthedocs.io/en/latest/programming_guide/migration.html
[2] https://github.com/jonathanwin/yagv/issues/20

Bug#1063267:

The previous patch missed a required change to debian/rules, new version
attached.


nmu_vtk9.debdiff
Description: Binary data

Bug#1064869: nmu: cowsql, golang-github-cowsql-go-cowsql

2024-02-26 Thread Mathias Gibbens

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Tags: bookworm-backports
Control: affects -1 + src:cowsql
Control: affects -1 + src:golang-github-cowsql-go-cowsql

nmu cowsql_1.15.4-1~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd"
nmu golang-github-cowsql-go-cowsql_1.22.0-2~bpo12+1 . amd64 . 
bookworm-backports . -m "Build on buildd"

  I would like for the amd64 builds to happen on official buildds,
rather than relying on my amd64 upload as part of processing through
BACKPORTS-NEW. I'm not sure when the next update in unstable to either
package will be, so I'd like to schedule a binNMU.

Thanks,
Mathias


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

Bug#1064868: trollsift: please remove last reference to python3-six

2024-02-26 Thread Alexandre Detiste

Source: trollsift
Version: 0.5.1-1
Severity: normal

Hi,

Thanks for the cleanup in this commit:

#e55b3245c9c0354223d27079dda5cf01317f362f

Unfortunately it's not enough:
python3-six was referenced twice in debian/control
and there's still yet another reference to remove.

Greetings

Alexandre

Bug#1064867: xsettingsd: Please ship .service file

2024-02-26 Thread Tollef Fog Heen

Package: xsettingsd
Version: 1.0.2-1
Severity: wishlist

xsettingsd upstream ships with a .service file which makes this start
automatically when installed.  Could this please be shipped with
xsettingsd?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#1038058: brandy: Depends on SDL 1.2

2024-02-26 Thread Stewart Russell

I can confirm that after (limited) testing on aarch64, the following
scenarios work for brandy:

2. Install libsdl1.2-compat-shim and run the program in a Wayland
environment

3. Install libsdl1.2-compat-shim ... but this time with environment
variable SDL_VIDEODRIVER=wayland

4. Install libsdl1.2-compat-dev and recompile the package.

I no longer have a current X11 Debian system, so I can't test scenario 1)

 Stewart

Bug#1064806:

And that patch had a lot of cruft in it.

On Tue, 27 Feb 2024 at 09:27, Michael Hudson-Doyle <
michael.hud...@canonical.com> wrote:

> Apologies, I missed some things in the first version of this patch. Here's
> an update.
>


nmu_python3.11.debdiff
Description: Binary data

Bug#1064866: python-geopandas: please remove dependencies on obsolete libraries python3-six & python3-mock

2024-02-26 Thread Alexandre Detiste

Source: python-geopandas
Version: 0.14.3-2
Severity: normal


Hi,

GeoPandas does not needs "six" anymore and will prefer "unittest.mock"
from the standard library over "mock".

Please remove the stale dependencies from debian/control

Greetings

diff --git a/debian/control b/debian/control
index e2b117d..29e9f85 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,6 @@ Build-Depends: debhelper-compat (= 13),
python3-fiona,
python3-geopy,
python3-matplotlib,
-   python3-mock,
python3-numpy,
python3-numpydoc,
python3-pandas,
@@ -26,7 +25,6 @@ Build-Depends: debhelper-compat (= 13),
python3-pytest,
python3-rtree,
python3-setuptools,
-   python3-six,
python3-shapely,
python3-sqlalchemy
 Standards-Version: 4.6.2
@@ -42,7 +40,6 @@ Depends: python3-fiona,
  python3-pandas,
  python3-pyproj,
  python3-shapely,
- python3-six,
  ${python3:Depends},
  ${misc:Depends}
 Recommends: python3-geopy,

Bug#1064865: RFS: streamlink/6.6.2-1~bpo12+1 -- CLI for extracting video streams from various websites to a video player

2024-02-26 Thread Alexis Murzeau


Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "streamlink" into Debian
bookworm-backports repository.

  * Package name: streamlink
Version : 6.6.2-1~bpo12+1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs : https://salsa.debian.org/amurzeau/streamlink/
Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from
various websites
  streamlink - CLI for extracting video streams from various websites
to a video player


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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.6.2-1~bpo12+1.dsc



Differences from testing package (6.5.1-1~bpo12+1):
  * d/control,rules: remove doc package because of missing dependencies
on bookworm.


Changes since the previous backported version in bookworm:
streamlink (6.6.2-1~bpo12+1) bookworm-backports; urgency=medium

  * Rebuild for bookworm-backports.

 -- Alexis Murzeau   Mon, 26 Feb 2024 21:33:02 +0100

streamlink (6.6.2-1) unstable; urgency=medium

  * New upstream version 6.6.2

 -- Alexis Murzeau   Wed, 21 Feb 2024 21:05:19 +0100

streamlink (6.6.1-1) unstable; urgency=medium

  * New upstream version 6.6.1

 -- Alexis Murzeau   Mon, 19 Feb 2024 20:41:54 +0100

Regards,

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|


OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059880: RFS: chr/0.1.77-1 [ITP] -- terminal-based text editor

2024-02-26 Thread Christoph Hueffelmann


Dear mentors,

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

 * Package name : chr
   Version  : 0.1.77-1
   Upstream contact : Christoph Hueffelmann 
 * URL  : https://github.com/istoph/editor
 * License  : Expat, BSL-1.0
 * Vcs  : https://salsa.debian.org/chr/chr
   Section  : editors

The source builds the following binary packages:

  chr - terminal-based text editor
  chr-tiny - terminal-based text editor - without syntax highlighting

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/chr/chr_0.1.77-1.dsc


Changes for the initial release:

 chr (0.1.77-1) unstable; urgency=medium
 .
   * Initial release.
 (Closes: #1059361)


Changes since last version:
* Handled review comments by Phil Wyett:
   Removed unneeded changelog entry
* Updated to current upstream version

Regards,
--
  Christoph Hueffelmann

Bug#1064619: Please package v2.6

Control: tags -1 pending

Hi Nicholas,

Nicholas D Steeves  writes:

> Package: markdown-mode
> Version: 2.5-1
> Severity: normal
> X-Debbugs-Cc: s...@debian.org
>
> Please package markdown-mode v2.6.  Upstream changelog is available
> here:
>
> https://github.com/jrblevin/markdown-mode/releases/tag/v2.6
>
> Regards,
> Nicholas
>

I have prepared the changes on salsa[1] (sans "dch -r") and uploaded to
mentors[2].  PTAL.  TIA!

[1] https://salsa.debian.org/emacsen-team/markdown-mode
[2] https://mentors.debian.net/package/markdown-mode/

-- 
Xiyue Deng

Bug#1064864: rust-drt-tools: Invalid package section

2024-02-26 Thread Jeremy Bícha

Source: rust-drt-tools
Version: 0.2.20-1
Severity: important
X-Debbugs-CC: sramac...@debian.org

There is a problem with the package's debcargo.toml and it generates
an invalid debian/control:

Unknown section 'FIXME-IN-THE-SOURCE-SECTION'

Thank you,
Jeremy Bícha

Bug#1064681: retroarch: FTBFS: make[1]: *** [debian/rules:48: override_dh_auto_configure] Error 1

2024-02-26 Thread Jonathan McDowell

Control: tags -1 - trixie
Control: severity -1 important

On Sun, Feb 25, 2024 at 08:48:32PM +0100, Lucas Nussbaum via Pkg-games-devel 
wrote:
> Source: retroarch
> Version: 1.16.0.3+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240224 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This looks like a glslang issue; #1062799 and the associated autopkgtest
failures for glslang's migration to trixie (e.g.
https://ci.debian.net/packages/g/glslang/testing/amd64/43341664/).

I'm dropping this to important until glslang is fixed.

> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > sed 's/@DEB_HOST_MULTIARCH@/x86_64-linux-gnu/g' \
> > retroarch.cfg > debian/retroarch.cfg
> > # See ./configure --help for valid flags
> > # disable flags (i.e. --disable-ffmpeg for example) if there is no package 
> > relative to the feature in Build-Depends
> > ./configure --prefix=/usr \
> > --disable-builtinmbedtls \
> > --disable-builtinbearssl \
> > --disable-builtinflac \
> > --disable-builtinglslang \
> > --disable-builtinzlib \
> > --disable-update_assets \
> > --disable-oss \
> > --disable-vg \
> > --enable-dbus \
> > --enable-spirv_cross \
> > --enable-vulkan \
> > --enable-sse
> > Checking operating system ... Linux 
> > Checking for suitable working C compiler ... /usr/bin/gcc works
> > Checking for suitable working C++ compiler ... /usr/bin/g++ works
> > Checking for pkg-config ... /usr/bin/pkgconf
> > Checking for availability of switch -std=gnu99 in /usr/bin/gcc ... yes
> > Checking for availability of switch -std=c++17 in /usr/bin/g++ ... yes
> > Checking for availability of switch -Wno-unused-result in /usr/bin/gcc ... 
> > yes
> > Checking for availability of switch -Wno-unused-variable in /usr/bin/gcc 
> > ... yes
> > Checking function sd_get_machine_names in -lsystemd ... no
> > Checking presence of package bcm_host ... no
> > Checking function bcm_host_init in -lbcm_host ... no
> > Checking presence of header file EGL/eglext.h ... yes
> > Checking presence of package egl ... 1.5
> > Checking function ass_library_init in -lfribidi -lass ... no
> > Checking existence of -msse -msse2 ... yes
> > Checking function pthread_create in -lpthread ... yes
> > Checking function pthread_key_create in -lpthread ... yes
> > Checking presence of package check >= 0.15 ... no
> > Checking presence of header file scsi/sg.h ... yes
> > Checking function dlopen in -ldl ... yes
> > Checking function socket in -lc ... yes
> > Checking function getaddrinfo in -lc ... yes
> > Checking function fcntl in -lc ... yes
> > Checking function getopt_long in -lc ... yes
> > Checking presence of package alsa ... 1.2.10
> > Checking presence of package libsixel >= 1.6.0 ... no
> > Checking presence of predefined macro AUDIO_SETINFO in sys/audioio.h ... no
> > Checking presence of package rsound >= 1.1 ... no
> > Checking presence of package libroar >= 1.0.12 ... no
> > Checking presence of package jack >= 0.120.1 ... 1.9.21
> > Checking presence of package libpulse ... 16.1
> > Checking presence of package sdl >= 1.2.10 ... no
> > Checking presence of package sdl2 >= 2.0.0 ... 2.30.0
> > Checking presence of package Qt5Core >= 5.2 ... 5.15.10
> > Checking presence of package Qt5Gui >= 5.2 ... 5.15.10
> > Checking presence of package Qt5Widgets >= 5.2 ... 5.15.10
> > Checking presence of package Qt5Concurrent >= 5.2 ... 5.15.10
> > Checking presence of package Qt5Network >= 5.2 ... 5.15.10
> > Checking presence of package openssl >= 1.0.0 ... no
> > Checking presence of package flac ... 1.4.3
> > Checking existence of -lmbedtls -lmbedx509 -lmbedcrypto ... no
> > Notice: HID is disabled, libusb support will also be disabled.
> > Checking existence of -ldinput8 ... no
> > Checking existence of -ld3d9 ... no
> > Checking existence of -ldsound ... no
> > Checking existence of -ld3dx8 ... no
> > Checking existence of -ld3dx9 ... no
> > Checking presence of header file GL/gl.h ... yes
> > Checking existence of -lGL ... yes
> > Checking function cgCreateContext in -lCg -lCgGL ... no
> > Checking presence of package zlib ... 1.3
> > Checking presence of package libavcodec >= 57 ... 60.31.102
> > Checking presence of package libavformat >= 57 ... 60.16.100
> > Checking presence of package libavdevice >= 57 ... 60.3.100
> > Checking presence of package libswresample >= 2 ... 4.12.100
> > Checking presence of package libavutil >= 55 ... 58.29.100
> > Checking presence of package libswscale >= 4 ... 7.5.100
> > Checking presence of header file libavutil/channel_layout.h ... yes
> > Checking function dlopen in -ldl ... yes
> > Checking presence of package gbm >= 9.0 ... 24.0.1-1
> > Checking presence of package libdrm ... 2.4.120
> > Checking presence of package dbus-1 ... 1.14.10
> > Checking presence of package libudev ... 255
> > Checking presence of

Bug#1064863: u-boot for riscv64 as included does not work in qemu

2024-02-26 Thread Martin Cracauer

Package: u-boot-qemu
Version: 2021.01+dfsg-5
Severity: important
Tags: patch
X-Debbugs-Cc: craca...@cons.org




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

Kernel: Linux 5.15.90-cracauerdlwavehh (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, 
TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

-- no debconf information


/usr/lib/u-boot/qemu-riscv64/u-boot.bin as included in this debian
release does not work for booting in qemu for RISCV64, when combined
with /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf (also from
this debian version).  See below for qemu command line.

If instead you use the version of u-boot.bin included in the FreeBSD
port it works with the same fw_jump.elf.

sha256 of faulty version of u-boot.bin (Debian):
1b5505b90c933a61c2edbf579dd190ea18582e151290d547f68a1eb465f52fe6 

sha256 of working version of u-boot.bin:
70f2d929cc60fb9449290a650f62a5ec7d9fdb43db4251a85b294b08d0d7c3d2

To get the working version (source code):
https://ftp.denx.de/pub/u-boot/u-boot-2024.01.tar.bz2

To get the working version (FreeBSD package):
https://pkg0.tuk.freebsd.org/FreeBSD:14:aarch64/latest/All/u-boot-qemu-riscv64-2024.01.pkg

I extracted the actual u-boot.bin from FreeBSD for you to try out:
https://www.cons.org/riscv/u-boot.bin


Example qemu line showing the problem and solution.  Just exchange the
two u-boot.bin's.  Note that the FreeBSD image is irrelevant here, the
booting never reaches it.  I run this on Debian/amd64.

qemu-system-riscv64 \
  -M virt \
  -smp 8 \
  -m 32G \
  -nographic \
  -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf \
  -kernel u-boot.bin \
  -drive file=FreeBSD-14.0-RELEASE-riscv-riscv64.raw,format=raw,id=hd0 \
  -device virtio-blk-device,drive=hd0 \
  -nographic \
  -netdev user,id=net0,ipv6=off,hostfwd=tcp::3234-:22 \
  -device virtio-net-device,netdev=net0 \
  -device virtio-rng-pci


Log of a faulty boot:
https://www.cons.org/riscv/log

Bug#1064856: dpkg: New xz-utils print warnings on stderr

On 2024-02-26 20:46:43 [+0100], Guillem Jover wrote:
> > > Ignoring stderr could be a workaround, but I'd need to do something as
> > > well for the libdpkg code and the perl code calling xz, which will get
> > > very annoying.
> > > 
> > > This is also going to get in the way of migrating both xz and dpkg
> > > (which seems like would need to be uploaded today for the time64
> > > transition).
> > > 
> > > Or perhaps that warning could be disabled for now in Debian until things
> > > are sorted out with upstream?
> > 
> > Falling back to -T1 in order to keep the previous is not an option?
> 
> I'm not sure I understand what you are saying. Do you mean dpkg would
> fallback to pass -T1 (maybe you mean -T+1, otherwise we might get
> unreproducible output due to switching to single-threaded)? And
> fallback on what condition?

Yes. I *think* that error came from the decompress part but I'm not sure.

> Ah, I think you mean to pass -T+1 to the xz invocations for the test
> suite, right, that could workaround the issue there indeed. Thanks, I
> think I'll do that for now.

Thank you.

> > Let me try to sell this "we move this warning to verbose" to upstream in
> > the meantime…
> 
> That would actually be great!
> 
> > > (Had not seen this test suite failure yet, as I've got xz on hold due
> > > to the breaks on pristine-tar, but would probably stumble over it
> > > during the release process anyway I guess, so thanks for the heads up!)
> > 
> > This poped up on xz debci only armel and armhf.
> 
> Perhaps I'll not see it in my local tree then, but I think the dpkg
> failure will at least block xz migration, but thinking about it now,
> probably not dpkg's migration. So this might not be blocking for dpkg.
> (Sorry if this sounded alarming, but didn't want to add new roadblocks
> to the time64 transition from the dpkg side! :D)

Understood ;)

> Thanks,
> Guillem

Sebastian

Bug#1059892: qa.debian.org: uscan version too old and not using recent @ANY_VERSION@ expansion

Friendly ping.  Any updates on progress?

-- 
Xiyue Deng

Bug#1064856: dpkg: New xz-utils print warnings on stderr

2024-02-26 Thread Guillem Jover

On Mon, 2024-02-26 at 20:10:20 +0100, Sebastian Andrzej Siewior wrote:
> On 2024-02-26 19:23:58 [+0100], Guillem Jover wrote:
> > > | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the 
> > > memory usage limit of 1400 MiB
> > > | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the 
> > > memory usage limit of 1400 MiB
> > > | 89s 4. deb-format.at:511:  FAILED (deb-format.at:518)
> > > 
> > > Allowing output on stderr would be a possible tix.
> > 
> > Hmm, that's warning is unfortunate, and a quick check at the xz code
> > didn't reveal a way to only suppress it. :/
> > 
> > For dpkg, I'd like to either not get the warning or being able to tell xz
> > that even if the threads are reduced, that's ok and it should not warn
> > about that (but that would then require depending on a new enough
> > version supporting that, perhaps that could be suppresses instead via
> > an envvar) so that?
> 
> Could poke upstream.

Thanks!

> > Ignoring stderr could be a workaround, but I'd need to do something as
> > well for the libdpkg code and the perl code calling xz, which will get
> > very annoying.
> > 
> > This is also going to get in the way of migrating both xz and dpkg
> > (which seems like would need to be uploaded today for the time64
> > transition).
> > 
> > Or perhaps that warning could be disabled for now in Debian until things
> > are sorted out with upstream?
> 
> Falling back to -T1 in order to keep the previous is not an option?

I'm not sure I understand what you are saying. Do you mean dpkg would
fallback to pass -T1 (maybe you mean -T+1, otherwise we might get
unreproducible output due to switching to single-threaded)? And
fallback on what condition?

Ah, I think you mean to pass -T+1 to the xz invocations for the test
suite, right, that could workaround the issue there indeed. Thanks, I
think I'll do that for now.

> Let me try to sell this "we move this warning to verbose" to upstream in
> the meantime…

That would actually be great!

> > (Had not seen this test suite failure yet, as I've got xz on hold due
> > to the breaks on pristine-tar, but would probably stumble over it
> > during the release process anyway I guess, so thanks for the heads up!)
> 
> This poped up on xz debci only armel and armhf.

Perhaps I'll not see it in my local tree then, but I think the dpkg
failure will at least block xz migration, but thinking about it now,
probably not dpkg's migration. So this might not be blocking for dpkg.
(Sorry if this sounded alarming, but didn't want to add new roadblocks
to the time64 transition from the dpkg side! :D)

Thanks,
Guillem

Bug#1064861: kubectx: destination of symlinks to zsh completions wrong

2024-02-26 Thread Heiko Schabert

Package: kubectx
Version: 0.9.5-1
Severity: normal

Dear Maintainer,

the package creates symlinks Zsh auto completion under the folder
*/usr/share/zsh/vendor-completions*. The symlink are pointing to an not
known file

```
$ ls /usr/share/zsh/vendor-completions
_kubectx.zsh -> ../../kubectx/completion/kubectx.zsh
_kubens.zsh -> ../../kubectx/completion/kubens.zsh
```

The following destination files seems to be the correct ones:
```
$ ls -al ../../kubectx/completion/ |grep -i zsh
_kubectx.zsh
_kubens.zsh
```


BR,
Heiko

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

Kernel: Linux 6.6.15-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) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kubectx depends on:
ii  libc6  2.37-15

kubectx recommends no packages.

Versions of packages kubectx suggests:
ii  bash-completion  1:2.11-8

-- no debconf information

Bug#1064862: ruby-rack-cors: CVE-2024-27456

2024-02-26 Thread Salvatore Bonaccorso

Source: ruby-rack-cors
Version: 2.0.1-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/cyu/rack-cors/issues/274
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ruby-rack-cors.

CVE-2024-27456[0]:
| rack-cors (aka Rack CORS Middleware) 2.0.1 has 0666 permissions for
| the .rb files.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-27456
https://www.cve.org/CVERecord?id=CVE-2024-27456
[1] https://github.com/cyu/rack-cors/issues/274

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1064860: brandy: tbrandy and sbrandy command-line interpreters are missing

2024-02-26 Thread Stewart Russell

Package: brandy
Version: 1.22.14-1
Severity: normal
X-Debbugs-Cc: scr...@gmail.com

Dear Maintainer,

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

Tried the `tbrandy` and `sbrandy` commands

   * What was the outcome of this action?

bash: tbrandy: command not found
bash: sbrandy: command not found

   * What outcome did you expect instead?

For tbrandy, normal command-line interpreter interaction, something like:

Matrix Brandy BASIC VI version 1.XX.Y ...

Development snapshot at git ...

Starting with 67108864 bytes free

>

`tbrandy` and `sbrandy` are the non-graphical versions of the interpreter. As
well as providing text I/O, they include drivers for several terminal types
including ANSI and Tektronix graphics. They are easily built. In the Brandy
source folder, immediately after running `make` to generate the brandy
executable:

make clean
make -f makefile.text

This will cause the tbrandy and sbrandy executables to be created in the
current folder.

Best Wishes,
 Stewart Russell

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


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

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

Versions of packages brandy depends on:
ii  libc62.36-9+deb12u4
ii  libsdl1.2debian  1.2.15+dfsg2-8
ii  libx11-6 2:1.8.4-2+deb12u2

brandy recommends no packages.

brandy suggests no packages.

-- no debconf information

Bug#1064376: reverse dependency

2024-02-26 Thread Thorsten Alteholz


Control: tags -1 + moreinfo

Hi Marcos,

there is a reverse dependency that needs to be taken care of:


Checking reverse dependencies...
# Broken Depends:
ganglia-modules-linux: ganglia-modules-linux

# Broken Build-Depends:
ganglia-modules-linux: libganglia1-dev


In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1061996: cyclonedds: NMU diff for 64-bit time_t transition

2024-02-26 Thread Steve Langasek

The previous NMU inadvertently failed to handle transitioning of
libddsc0debian.  Please find an updated patch attached.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru cyclonedds-0.10.4/debian/changelog cyclonedds-0.10.4/debian/changelog
--- cyclonedds-0.10.4/debian/changelog  2023-08-29 11:16:42.0 +
+++ cyclonedds-0.10.4/debian/changelog  2024-02-26 18:39:08.0 +
@@ -1,3 +1,10 @@
+cyclonedds (0.10.4-1.1~exp2) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Mon, 26 Feb 2024 18:39:08 +
+
 cyclonedds (0.10.4-1) unstable; urgency=medium
 
   * New upstream version 0.10.4
diff -Nru cyclonedds-0.10.4/debian/control cyclonedds-0.10.4/debian/control
--- cyclonedds-0.10.4/debian/control2023-08-29 11:11:49.0 +
+++ cyclonedds-0.10.4/debian/control2024-02-26 18:39:08.0 +
@@ -28,14 +28,21 @@
  Eclipse IoT project with a growing list of adopters, and has become a
  tier-1 middleware for the Robot Operating System (ROS 2).
 
-Package: libddsc0debian
+Package: libddsc0t64
+X-Time64-Compat: libddsc0debian
+Provides: ${t64:Provides}
+Replaces: libddsc0debian
+Breaks: libddsc0debian (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: ${source:Synopsis} library
  ${source:Extended-Description}
 
-Package: libcycloneddsidl0
+Package: libcycloneddsidl0t64
+Provides: ${t64:Provides}
+Replaces: libcycloneddsidl0
+Breaks: libcycloneddsidl0 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -52,8 +59,8 @@
 Multi-Arch: same
 Recommends: cyclonedds-tools
 Depends: ${misc:Depends},
- libddsc0debian (= ${binary:Version}),
- libcycloneddsidl0 (= ${binary:Version}),
+ libddsc0t64 (= ${binary:Version}),
+ libcycloneddsidl0t64 (= ${binary:Version}),
  libiceoryx-binding-c-dev [amd64 arm64 mips64el ppc64el s390x alpha 
ia64 ppc64 riscv64 sparc64],
 Breaks: libddsc-dev (<< 0.8.1-1)
 Replaces: libddsc-dev (<< 0.8.1-1)
diff -Nru cyclonedds-0.10.4/debian/libcycloneddsidl0.install 
cyclonedds-0.10.4/debian/libcycloneddsidl0.install
--- cyclonedds-0.10.4/debian/libcycloneddsidl0.install  2022-02-22 
08:29:59.0 +
+++ cyclonedds-0.10.4/debian/libcycloneddsidl0.install  1970-01-01 
00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/*/libcycloneddsidl.so.*
diff -Nru cyclonedds-0.10.4/debian/libcycloneddsidl0.symbols 
cyclonedds-0.10.4/debian/libcycloneddsidl0.symbols
--- cyclonedds-0.10.4/debian/libcycloneddsidl0.symbols  2023-05-25 
07:39:04.0 +
+++ cyclonedds-0.10.4/debian/libcycloneddsidl0.symbols  1970-01-01 
00:00:00.0 +
@@ -1,132 +0,0 @@
-libcycloneddsidl.so.0 libcycloneddsidl0 #MINVER#
-* Build-Depends-Package: cyclonedds-dev
- idl_allowable_data_representations@Base 0.9.0
- idl_ancestor@Base 0.8.0
- idl_array_size@Base 0.8.0
- idl_asprintf@Base 0.8.0
- idl_bound@Base 0.8.0
- idl_case_label_intvalue@Base 0.9.0
- idl_compare@Base 0.8.0
- idl_construct@Base 0.8.0
- idl_create_pstate@Base 0.8.0
- idl_current_path@Base 0.8.0
- idl_declaration@Base 0.8.0
- idl_default_value@Base 0.9.0
- idl_degree@Base 0.8.0
- idl_delete_directive@Base 0.8.0
- idl_delete_pstate@Base 0.8.0
- idl_enum_max_value@Base 0.9.0
- idl_error@Base 0.8.0
- idl_evaluate@Base 0.8.0
- idl_find@Base 0.8.0
- idl_find_field_name@Base 0.8.0
- idl_find_scoped_name@Base 0.8.0
- idl_fopen@Base 0.8.0
- idl_fprintf@Base 0.8.0
- idl_generate_out_file@Base 0.10.2
- idl_has_unset_extensibility_r@Base 0.9.0
- idl_hashid@Base 0.8.0
- idl_identifier@Base 0.8.0
- idl_identifier_is@Base 0.9.0
- idl_is_alias@Base 0.8.0
- idl_is_annotation_appl@Base 0.8.0
- idl_is_annotation_member@Base 0.8.0
- idl_is_array@Base 0.8.0
- idl_is_base_type@Base 0.8.0
- idl_is_bit_value@Base 0.9.0
- idl_is_bitmask@Base 0.9.0
- idl_is_bounded@Base 0.8.0
- idl_is_bounded_string@Base 0.9.0
- idl_is_case@Base 0.8.0
- idl_is_case_label@Base 0.8.0
- idl_is_const@Base 0.8.0
- idl_is_constr_type@Base 0.8.0
- idl_is_declaration@Base 0.8.0
- idl_is_declarator@Base 0.8.0
- idl_is_default_case@Base 0.8.0
- idl_is_empty@Base 0.9.0
- idl_is_enum@Base 0.8.0
- idl_is_enumerator@Base 0.8.0
- idl_is_extensible@Base 0.9.0
- idl_is_external@Base 0.9.0
- idl_is_floating_pt_type@Base 0.8.0
- idl_is_forward@Base 0.9.0
- idl_is_implicit_default_case@Base 0.8.0
- idl_is_inherit_spec@Base 0.8.0
- idl_is_integer_type@Base 0.8.0
- idl_is_keyless@Base 0.8.0
- idl_is_literal@Base 0.8.0
- idl_is_member@Base 0.8.0
- idl_is_module@Base 0.8.0
- idl_is_must_understand@Base 0.9.0
- idl_is_optional@Base 0.9.0
- idl_is_sequence@Base 0.8.0
-

Bug#1064859: rust-futures-rustls: Fails to build from source

2024-02-26 Thread Jeremy Bícha

Source: rust-futures-rustls
Version: 0.24.0-1
Severity: serious
Tags: ftbfs

rust-futures-rustls fails to build from source because of build test failures.

https://buildd.debian.org/status/package.php?p=rust-futures-rustls

Thank you,
Jeremy Bícha

Bug#1064858: python-astroplan-doc: please make the package build reproducible.

2024-02-26 Thread James Addison

Package: python-astroplan-doc
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps randomness

Dear Maintainer,

I'm an occasional volunteer contributor to the Reproducible Builds[1] project,
and noticed recently that the python-astroplan-doc package failed[2] an
automated Debian package reproducibility test.

There appear to be two causes of non-reproducibility:

  * Unless instructed otherwise, the Sphinx autodoc extension evaluates the
default values of Python method signature arguments.  In the case of
astroplan, that produces timing information that is relative to the
build-time of the project (such as the value of '_current_year_time_range'
in the arguments to 'months_observable'[3]).

  * The astroplan docs include build-time-generated matplotlib diagrams in SVG
format.  By default, matplotlib uses[4] a randomly-generated UUID4 scheme
to add a salt when creating the path IDs in those SVG files, meaning that
the resulting documentation varies on each build.

I can suggest two corresponding resolutions to make the documentation build
reproducibly:

  * We can use the 'autodoc_preserve_defaults' configuration option[5] in the
autodoc extension to include the source code text of each argument default,
instead of the build-time values they evaluate to.

  * We can configure the matplotlib 'svg.hashsalt' option[6].  This can be
configured on a per-diagram basis, or globally using a matplotlibrc file.
In this case, I recommend the latter because this should mean that we do
not have to modify the source package, only the Debian packaging.

I'll provide a merge request on Salsa with these suggestions and will link that
to the bugreport here.

Regards,
James

[1] - https://reproducible-builds.org

[2] - 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/astroplan.html

[3] - 
https://salsa.debian.org/debian-astro-team/astroplan/-/blob/ffea5b68f3f4e682b0226a11b24df9c7ef56ff2c/astroplan/constraints.py#L1094-1096

[4] - 
https://sources.debian.org/src/matplotlib/3.6.3-1/lib/matplotlib/backends/backend_svg.py/#L497-L498

[5] - 
https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_preserve_defaults

[6] - 
https://matplotlib.org/stable/users/explain/customizing.html?highlight=svg.hashsalt#matplotlibrc-sample

Bug#1061769: Unexpected VLAN behavior with KEA DHCP

2024-02-26 Thread Paride Legovini

Control: tags -1 + wontfix

On 2024-01-29 15:27, kristofer.hans...@icomera.com wrote:
> Package: kea-dhcp4-server
> Version: 2.2.0-6
> 
> Hi, this version (and from what I believe all versions) of kea-dhcp4-server
> (and probably kea-dhcp6-server) handles vlan tagged traffic in a quite
> unintuitive way. When the server is set up in raw socket mode it will accept 
> all
> broadcasted DHCP requests regardless of VLAN tagging. It will then send a
> response untagged, again regardless of initial VLAN tag. See below for a 
> packet
> trace where this happens.
> 
> This has been reported to the ISC team quite some time ago here:
> https://gitlab.isc.org/isc-projects/kea/-/issues/1117.
> A patch has been provided to the ISC team which they have not applied (I can't
> say why): https://github.com/isc-projects/kea/pull/119.
> The file that is patched has been more or less unchanged since the patch was
> created and should still apply (it did for me on 2.2.0-6).
> 
> This behavior was not present in isc-dhcp-server as they filtered out VLAN
> tagged broadcasts from what I can tell, so the behavior is changed between the
> two DHCP server services.
> 
> As I see it there are two things that shouldn't happen here:
> 1. A DHCP server not explicitly configured to listen to VLAN traffic should 
> not
>    respond to that traffic.
> 2. If a DHCP server answers DHCP broadcasts on a VLAN tagged network it should
>    respond on the same VLAN network.
> 
> My suggestion would be to include the patch 
> (https://github.com/isc-projects/kea/pull/119)
> to filter out any tagged traffic, as this is inline with how dhcpd from
> isc-dhcp-server worked.

Hello Kristofer and thanks for this bug report.

After looking at the state of the upstream bug and and the patches you
pointed to, and discussing the issue with the other Debian Kea maintainers,
our opinion is that we should not patch the Debian package to include the
requested functionality. There are many reasons for this, in I think the
two most important ones are:

* The issue is not trivial, and there's the risk to introduce incomplete
or buggy code we can't commit to fix or maintain.

* If what ISC will ship at some point will be different from what Debian
shipped, maybe in a stable release, we'll end up in a difficult to handle
situation, with no clear or easy upgrade path for uses that ended up
relying on the Debian specific implementation.

I think the way forward here is asking upstream what the plans are, and
whether there are ways users interested in the feature can help landing
it.

Cheers,

Paride

Bug#981017: Upstream PR

2024-02-26 Thread Martin Dosch


Hi,

thank you very much.

Best regards,
Martin

On 25.02.2024 18:32, Philippe SWARTVAGHER wrote:

Hello,

On Fri, 16 Feb 2024 16:20:40 +0100 Martin Dosch  wrote:


I just locally rebuilt cd-paranoia with the patch from this PR:

https://github.com/rocky/libcdio-paranoia/pull/38

This fixed the issue and whipper was able to determine the correct
offset and to rip an album.


I included the patch in the Debian package. However, libcdio-paranoia is
impacted by the 64-bit time_t transition (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063125), so I will
upload the package only after it is finished.

Philippe.



signature.asc
Description: PGP signature

Bug#1022043: apt-cacher-ng sometimes fails with several concurrent

2024-02-26 Thread Tim Woodall


On Fri, 23 Feb 2024, Andreas B. Mundt wrote:


Hi Tim,

thanks for the provided patch!  We see the same issue here, so I
included it in a locally built package to give it a try on our
infrastructure.

So far it looks quite promising, no errors up to now .



That's great! I've been running it for a few weeks now and also seen no
errors since I started using it.

I believe it's possibly fixed a second "buggette" too although I never
confirmed that this really existed and I haven't confirmed that it's
definitely gone away either.

If you simultaneously install a big package on multiple machines at the
same time (e.g. a kernel upgrade) then I believe that apt-cacher-ng used
to download it from upstream multiple times. Only once it had a copy did
it serve that up.

This was noticable to me in the past because I was on a relatively slow
download (c 2MB/s) so kernels would take a noticable amount of time to
download and 10 in parallel could take a lot longer than a single
download should have taken.

I used to work around this by triggering the download on a single
machine and then only triggering the rest once that one had completed
downloading.

Since applying this fix I've done another mass kernel upgrade. I'm on a
much faster connection now so I didn't really think about triggering the
download in advance but it only downloaded the kernel once.

zgrep linux-image-5.10.0-28 *
access.log.2.gz:1708183270.671  17321  TCP_MISS/200 
55667185 GET 
http://ftp.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-5.10.0-28-amd64_5.10.209-2_amd64.deb
 - HIER_DIRECT/2a04:4e42:4b::644 application/vnd.debian.binary-package

Next time I'll try and take more care to watch what really happens here
(although with my much faster connection a kernel downloads in a few
seconds anyway)

Tim.

Bug#1064856: dpkg: New xz-utils print warnings on stderr

On 2024-02-26 19:23:58 [+0100], Guillem Jover wrote:
> Hi!
Hi Guillem,

> > | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the 
> > memory usage limit of 1400 MiB
> > | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the 
> > memory usage limit of 1400 MiB
> > | 89s 4. deb-format.at:511:  FAILED (deb-format.at:518)
> > 
> > Allowing output on stderr would be a possible tix.
> 
> Hmm, that's warning is unfortunate, and a quick check at the xz code
> didn't reveal a way to only suppress it. :/
> 
> For dpkg, I'd like to either not get the warning or being able to tell xz
> that even if the threads are reduced, that's ok and it should not warn
> about that (but that would then require depending on a new enough
> version supporting that, perhaps that could be suppresses instead via
> an envvar) so that?

Could poke upstream.

> Ignoring stderr could be a workaround, but I'd need to do something as
> well for the libdpkg code and the perl code calling xz, which will get
> very annoying.
> 
> This is also going to get in the way of migrating both xz and dpkg
> (which seems like would need to be uploaded today for the time64
> transition).
> 
> Or perhaps that warning could be disabled for now in Debian until things
> are sorted out with upstream?

Falling back to -T1 in order to keep the previous is not an option?

Let me try to sell this "we move this warning to verbose" to upstream in
the meantime…

> (Had not seen this test suite failure yet, as I've got xz on hold due
> to the breaks on pristine-tar, but would probably stumble over it
> during the release process anyway I guess, so thanks for the heads up!)

This poped up on xz debci only armel and armhf.

> Thanks,
> Guillem

Sebastian

Bug#1064436: lintian-brush: Missing git commit + changelog entry for added upstream/metadata

2024-02-26 Thread Jelmer Vernooĳ

On Mon, Feb 26, 2024 at 06:38:24PM +0100, Andreas Tille wrote:
> Control: tags -1 - moreinfo
> thanks
> 
> Hi Jelmer,
> 
> Am Mon, Feb 26, 2024 at 03:14:20PM + schrieb Jelmer Vernooĳ:
> > On Thu, Feb 22, 2024 at 08:30:46AM +0100, Andreas Tille wrote:
> > > if upstream/metadata are added this is not added+commited to
> > > the packaging repository.  There is also no changelog created
> > > which should be something like
> > > 
> > >   * Add upstream metadata
> > 
> > Are you specifying --update-changelog ?
> 
> Not explicitly yet.  I'm pretty sure when I started calling
> lintian-brush from routine-update changelog was updated.

It would have dependend on the package. If lintian-brush determines that
the changelog is updated using "gbp dch" then it would not update the
changelog; it has had this behaviour since the beginning. You can
override the detection with the --update-changelog / --no-update-changelog
flags.

(But as mentioned earlier, I'm curious to hear about packages for
which the detection doesn't work, like the one you've presumably just
encountered)

> And as you can see in my other bug report
> 
>#1060338 lintian-brush: Changelog entries are lacking asterisk
> 
> there actually *are* changelog entries ... but they are more ugly
> than before.

Yep, thanks for the bug report - hoping to get to that later this week.

> > By default lintian-brush
> > autodetects whether it needs to update the changelog.
> 
> Well, this actual bug is about "if upstream/metadata are added this is
> not added+commited to the packaging repository".  It simply happens that
> upstream/metadata is added and after lintian-brush git consideres the
> local repository not clean any more since there are files that are not
> yet added.  You should be able to verify this by simply removing
> upstream/metadata and run lintian-brush (or whatever tool finally is
> adding this file.)  I would not mind about a missing changelog entry but
> at least the freshly created file should be added.  I'm pretty sure this
> is a regression since that worked before.

Thanks, I'll give that a try.

> > You can see whether it thinks it needs to update the changelog by running
> > ``detect-changelog-behaviour``.
> 
> I simply want to have a changelog entry once something was changed.

Right, --update-changelog should do that independently of whether lintian-brush
things gbp dch is in use.

Cheers,

Jelmer

Bug#1064838: New package names break APT safety features, ability to co-install different ABIs

2024-02-26 Thread Bastian Blank

On Mon, Feb 26, 2024 at 02:20:41PM +0100, Julian Andres Klode wrote:
> After we had discussed the new proposal a couple months ago and were
> left with severe open questions and concerns it seems that these have
> been ignored and the packages uploaded anyway, breaking APT's algorithm
> that ensures the currently booted kernel is not offered for removal, as
> well as possibly others.

The change for that is not even in.  Where do you see it?

| $ dpkg -l linux-image-$(uname -r)
| Desired=Unknown/Install/Remove/Purge/Hold
| | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
| |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
| ||/ NameVersion  Architecture Description
| 
+++-===---===
| ii  linux-image-6.7-cloud-amd64 6.7.4-1~exp1 amd64Linux 6.7 for 
x86-64 cloud (signed)

Also #1060109 is still unanswered.

> In addition, this means that the ABI changes within the same package
> names, causing different ABIs to no longer be co-installable, which can
> have drastic effect on thef function of systems:

I asked you several times now: please show a problem.  And I also told
you this does not work within the confines of Debian.  And neither did
the kernel team provide this guarantee in the past.

So I only see a way forward by preserving modules outside of the normal
package lifecycle.  Something that is ephemeral and so cleaned up
automatically on shutdown.

Bastian

-- 
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.

Bug#1059223: src:meson: fails to migrate to testing for too long: fails autopkgtest on arm64 and i386

2024-02-26 Thread Fabio Pedretti

Ubuntu fixed it with this patch:
https://launchpadlibrarian.net/715235929/meson_1.3.2-1_1.3.2-1ubuntu1.diff.gz

Bug#1063855: reverse dependencies

2024-02-26 Thread Thorsten Alteholz


Control: tags -1 + moreinfo

Hi Georges,

there are reverse dependencies that need to be taken care of:


Checking reverse dependencies...
# Broken Build-Depends:
dygraphs: jsdoc-toolkit
emperor: jsdoc-toolkit

Dependency problem found.


In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1061208: Please upgrade to llvm-toolchain-17

2024-02-26 Thread Étienne Mollier

Hi Christian,

Christian Kastner, on 2024-02-26:
> Hi Sebastian,
> 
> writing to you as you bumped the severity to 'serious': could the rT
> please give us an extension on the autoremoval for this particular bug.

If that helps, the autoremoval timer is reset each time the RC
critical bug triggering the autoremoval is updated, e.g. when
reporting an evolution of the situation in a new comment.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Bug#1064856: dpkg: New xz-utils print warnings on stderr

2024-02-26 Thread Guillem Jover

Hi!

On Mon, 2024-02-26 at 18:57:32 +0100, Sebastian Andrzej Siewior wrote:
> Package: dpkg
> Version: 1.22.4
> Severity: important

> xz-utils 5.6.0 has been uploaded to unstable. A changed behaviour of
> `xz' is now that mutlti threaded compress/ decompression is now enabled
> by default. This in turn leads to warnings if the requested amount of
> memory exceeds the available amount. A snippet from
> 
> https://ci.debian.net/data/autopkgtest/testing/armel/d/dpkg/43341232/log.gz
> 
> | 88s 
> /tmp/autopkgtest-lxc.dumkcbm0/downtmp/build.4CO/src/src/at/deb-format.at:518:
> | 88s # Extract the base members
> | 88s xz -c control.tar >control.tar.xz
> | 88s xz -c data.tar >data.tar.xz
> | 88s
> | 89s --- /dev/null   2024-02-26 09:29:33.669234548 +
> | 89s +++ 
> /tmp/autopkgtest-lxc.dumkcbm0/downtmp/autopkgtest_tmp/src/at/testsuite.dir/at-groups/4/stderr
>2024-02-26 09:30:58.601386838 +
> | 89s @@ -0,0 +1,2 @@
> | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the 
> memory usage limit of 1400 MiB
> | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the 
> memory usage limit of 1400 MiB
> | 89s 4. deb-format.at:511:  FAILED (deb-format.at:518)
> 
> Allowing output on stderr would be a possible tix.

Hmm, that's warning is unfortunate, and a quick check at the xz code
didn't reveal a way to only suppress it. :/

For dpkg, I'd like to either not get the warning or being able to tell xz
that even if the threads are reduced, that's ok and it should not warn
about that (but that would then require depending on a new enough
version supporting that, perhaps that could be suppresses instead via
an envvar) so that?

Ignoring stderr could be a workaround, but I'd need to do something as
well for the libdpkg code and the perl code calling xz, which will get
very annoying.

This is also going to get in the way of migrating both xz and dpkg
(which seems like would need to be uploaded today for the time64
transition).

Or perhaps that warning could be disabled for now in Debian until things
are sorted out with upstream?

(Had not seen this test suite failure yet, as I've got xz on hold due
to the breaks on pristine-tar, but would probably stumble over it
during the release process anyway I guess, so thanks for the heads up!)

Thanks,
Guillem

Bug#1064648: allegro5-doc: please make the build reproducible.

2024-02-26 Thread Andreas Rönnquist

On Sun, 25 Feb 2024 17:23:55 + James Addison  wrote:
> 
> Dear Maintainer,
> 
> I'm an occasional volunteer contributor to the Reproducible Builds[1] project,
> and noticed recently that your package allegro5-doc failed an automated Debian
> package build reproducibility test[2].
> 
> There appear to be two problems that contribute to the non-reproducibility:
> 
>   * The 'Last updated' message on each page does not use the SOURCE_DATE_EPOCH
> build timestamp (you can find documentation and C code to use it here[3]).
> 
>   * When sorting example documents to reference alongside functions, the
> documentation generation code selects the top-three most popular pages to
> cross-reference, but it does not have a tie-breaker in the case of equally
> popular pages.  This means that the ordering of those examples may vary
> between builds, depending on the order in which the files are discovered
> from the filesystem.
> 
> For the latter case, it might be acceptable to use string comparison of the
> filenames as a tiebreaker.
> 

Thanks for the report - I have pushed two commits to a branch of
allegro5 on github, which I would be glad if you could take a look at
and see if they seem reasonable to you, or if you can discover any
problems with them. If they're fine, I'll make a pull request upstream
and try to make a new debian package release soon(ish).

https://github.com/gusnan/allegro5/commit/e4369e13b1edb96b8ae4821c5363ac7b61002d3e
https://github.com/gusnan/allegro5/commit/842af9e5d6cd9c8fd0d0d2f8095f872e7bd77cef

best
/Andreas
gus...@debian.org

Bug#1064811: libhipsparse0-tests: HIPSPARSE_STATUS_INTERNAL_ERROR

2024-02-26 Thread Cordell Bloor

Hi Christian,

On 2024-02-26 00:54, Christian Kastner wrote:

On gfx1031/gfx1032/gfx1034, there are numerous occurrences of
HIPSPARSE_STATUS_INTERNAL_ERROR, see [1] for a full log. Interestingly,
only some of them lead to test failures (some examples below), and
sometimes there is more than one occurrence per test.

These passed on gfx900/gfx1030 so I don't immediately suspect my update
to the optional-test-matrices resp. allow-missing-matrix-data-in-tests
patches to be the cause.

If it works on gfx1030, but fails on gfx1031, gfx1032 and gfx1034, it is
almost certainly caused by run-time dispatching in rocprim [2]. I would
ignore this issue until rocprim passes its tests on those architectures.

We only build for gfx1030, so the problem is that when running on
gfx103{1,2,4}, rocPRIM is dynamically checking the current GPU
architecture and dispatching to something other than the gfx1030
implementation. If you'd like to verify that this is the problem, you
can run the tests with the environment variable
HSA_OVERRIDE_GFX_VERSION=10.3.0 on gfx1031, gfx1032 or gfx1034 hardware.

The solution is tricky, though, because rocPRIM is a header-only
library. We can't use a solution like in rocBLAS [3] where we force
gfx1031 to use gfx1030 code objects, because librocprim-dev users might
be building their code for gfx1031... unless maybe we hide that dispatch
behaviour behind an #ifdef that rocsparse can define.

Sincerely,
Cory Bloor

[2]:
https://salsa.debian.org/rocm-team/rocprim/-/blob/debian/5.7.1-1/rocprim/include/rocprim/device/config_types.hpp?ref_type=tags#L247
[3]:
https://salsa.debian.org/rocm-team/rocblas/-/blob/debian/5.5.1+dfsg-4/debian/patches/0012-expand-isa-compatibility.patch?ref_type=tags

Bug#1064857: unar: New xz-utils print warnings on stderr

Package: unar
Version: 1.10.7+ds1+really1.10.1-2
Severity: important

xz-utils 5.6.0 has been uploaded to unstable. A changed behaviour of
`xz' is now that mutlti threaded compress/ decompression is now enabled
by default. This in turn leads to warnings if the requested amount of
memory exceeds the available amount. A snippet from
https://ci.debian.net/packages/u/unar/testing/armel/43341293/
| 115s foo.tar.xz: Tar in XZ
| 115s   foo/  (dir)... OK.
| 115s   foo/bar  (4 B)... OK.
| 115s   foo/baz  (4 B)... OK.
| 115s Successfully extracted to "foo".
| 116s autopkgtest [10:53:54]: test tar: ---]
| ▾ test tar: test results
| 116s autopkgtest [10:53:54]: test tar:  - - - - - - - - - - results - - - - - 
- - - - -
| 116s tar  FAIL stderr: xz: Reduced the number of threads from 
16 to 8 to not exceed the memory usage limit of 1400 MiB
| 116s autopkgtest [10:53:54]: test tar:  - - - - - - - - - - stderr - - - - - 
- - - - -

Allowing output on stderr would be a possible tix.

Sebastian

Bug#1064856: dpkg: New xz-utils print warnings on stderr

Package: dpkg
Version: 1.22.4
Severity: important

xz-utils 5.6.0 has been uploaded to unstable. A changed behaviour of
`xz' is now that mutlti threaded compress/ decompression is now enabled
by default. This in turn leads to warnings if the requested amount of
memory exceeds the available amount. A snippet from
https://ci.debian.net/data/autopkgtest/testing/armel/d/dpkg/43341232/log.gz

| 88s 
/tmp/autopkgtest-lxc.dumkcbm0/downtmp/build.4CO/src/src/at/deb-format.at:518:
| 88s # Extract the base members
| 88s xz -c control.tar >control.tar.xz
| 88s xz -c data.tar >data.tar.xz
| 88s
| 89s --- /dev/null 2024-02-26 09:29:33.669234548 +
| 89s +++ 
/tmp/autopkgtest-lxc.dumkcbm0/downtmp/autopkgtest_tmp/src/at/testsuite.dir/at-groups/4/stderr
 2024-02-26 09:30:58.601386838 +
| 89s @@ -0,0 +1,2 @@
| 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the memory 
usage limit of 1400 MiB
| 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the memory 
usage limit of 1400 MiB
| 89s 4. deb-format.at:511:  FAILED (deb-format.at:518)

Allowing output on stderr would be a possible tix.

Sebastian

Bug#1064855: xfce4-power-manager: Display is shutdown despite activity

2024-02-26 Thread ael

Package: xfce4-power-manager
Version: 4.18.3-2
Severity: normal

Since the recent update on testing, several things are broken.

1) The display shuts down ignoring activity rendering machine useless.
 I have to inactivate the "Display power management" entirely.

2) "Suspend" is now completely broken, and requires a reboot! Echos of
Windoze : I am not quite sure if this is also the power manager.

Whereas before pressing the "sleep" key reliably just suspended this
machine which then resumed properly on another press,
now:

a) The "sleep" key displays a whole menu of icons. Clicking on the
"Suspend" icon does appear to suspend.

b) However, on pressing the "sleep" key again does at least reactivate
the display. However both the keyboard and mouse are inactive, so the
only option is to cycle power.

I wish I could offer some diagnostics but where is the documentation?

---

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

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

Versions of packages xfce4-power-manager depends on:
ii  libc6 2.37-15
ii  libcairo-gobject2 1.18.0-1+b1
ii  libcairo2 1.18.0-1+b1
ii  libglib2.0-0  2.78.4-1
ii  libgtk-3-03.24.41-1
ii  libnotify40.8.3-1
ii  libpango-1.0-01.51.0+ds-4
ii  libpangocairo-1.0-0   1.51.0+ds-4
ii  libupower-glib3   1.90.2-8
ii  libx11-6  2:1.8.7-1
ii  libxext6  2:1.3.4-1+b1
ii  libxfce4ui-2-04.18.4-1
ii  libxfce4util7 4.18.1-2
ii  libxfconf-0-3 4.18.1-1+b1
ii  libxrandr22:1.5.2-2+b1
ii  upower1.90.2-8
ii  xfce4-power-manager-data  4.18.3-2

Versions of packages xfce4-power-manager recommends:
ii  libpam-systemd [logind]  255.3-2
ii  xfce4-power-manager-plugins  4.18.3-2

xfce4-power-manager suggests no packages.

-- no debconf information

Bug#1064854: Breaks tex-common's configuration

2024-02-26 Thread julien . puydt

Package: context
Version: 2023.05.05.20230730+dfsg-2
Severity: critical

since a few days, I saw a configuration issue with the tex-common
package. (What I don't get is why it actually needs configuration since
I don't see uploads since months.)

I finally found the time to investigate and report. The error message
is:

Setting up tex-common (6.18) ...
Running mktexlsr. This may take some time... done.
Running mtxrun --generate. This may take some time... 
mtxrun --generate failed. Output has been stored in
/tmp/mtxrun.F4nq0y9x
Please include this file if you report a bug.

where /tmp/mtxrun.* contains a single line:

lua error : startup file: /usr/bin/mtxrun.lua:2438: attempt to assign
to const variable 'i'


The executable /usr/bin/mtxrun.lua is provided by the context package
(which also wasn't updated also since months...)

In /usr/bin/mtxrun.lua, around line 2438 looks like:
 for i,v in next,t do 
  if type(i)=="table" then
   if tables[i] then
i=tables[i]   <- 2438 is that one
   else
i=copy(i,tables)
   end
  end

my guess is the correct value should be put in another variable than
the for-loop index, but I'm pretty clueless about lua, and it did work
at some point... perhaps a new lua version is pickier?

Anyway I'm filing the bug report against context, since uninstalling it
unbreaks things, and setting the gravity level to critical since it
breaks other packages.

Cheers,

J.Puydt

Bug#989775: CVE-2021-3575

2024-02-26 Thread Andrew C Aitchison




OpenJPEG 2.5.1 has been released
  https://groups.google.com/g/openjpeg/c/othStX49Yc8
and includes a fix
  https://github.com/uclouvain/openjpeg/pull/1509
for CVE-2021-3575.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk

Bug#1064436: lintian-brush: Missing git commit + changelog entry for added upstream/metadata

2024-02-26 Thread Andreas Tille

Control: tags -1 - moreinfo
thanks

Hi Jelmer,

Am Mon, Feb 26, 2024 at 03:14:20PM + schrieb Jelmer Vernooĳ:
> On Thu, Feb 22, 2024 at 08:30:46AM +0100, Andreas Tille wrote:
> > if upstream/metadata are added this is not added+commited to
> > the packaging repository.  There is also no changelog created
> > which should be something like
> > 
> >   * Add upstream metadata
> 
> Are you specifying --update-changelog ?

Not explicitly yet.  I'm pretty sure when I started calling
lintian-brush from routine-update changelog was updated.  I changed now
to:

diff --git a/debian/changelog b/debian/changelog
index 1a7aca1..4083c5b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ routine-update (0.2.1) UNRELEASED; urgency=medium

   * Deal with other packaging branches than master even if debian/gbp.conf
 is missing
+  * Make sure changelog will be updated

  -- Andreas Tille   Thu, 22 Feb 2024 07:49:24 +0100

diff --git a/routine-update b/routine-update
index f1eaa23..b13748d 100755
--- a/routine-update
+++ b/routine-update
@@ -777,17 +777,17 @@ if grep -q -P '\t' debian/copyright ; then
dch_git_commit "No tab in license text"
 fi

-LIBRUSH=$(lintian-brush 2>&1 | head -n1)
+LIBRUSH=$(lintian-brush --update-changelog 2>&1 | head -n1)
 if [ "$LIBRUSH" != "No changes made." ]; then
 echo "I: lintian-brush was doing some changes"
 fi

-AMHINTS=$(apply-multiarch-hints 2>&1 | head -n1)
+AMHINTS=$(apply-multiarch-hints --update-changelog 2>&1 | head -n1)
 if [ "$AMHINTS" != "Nothing to do." ]; then
 echo "I: apply-multiarch-hints was doing some changes"
 fi

-DSOBSOLETE=$(deb-scrub-obsolete 2>&1 | wc -l)
+DSOBSOLETE=$(deb-scrub-obsolete --update-changelog 2>&1 | wc -l)
 if [ "$DSOBSOLETE" -gt 1 ]; then
 echo "I: deb-scrub-obsolete was doing some changes"
 fi

And as you can see in my other bug report

   #1060338 lintian-brush: Changelog entries are lacking asterisk

there actually *are* changelog entries ... but they are more ugly
than before.

> By default lintian-brush
> autodetects whether it needs to update the changelog.

Well, this actual bug is about "if upstream/metadata are added this is
not added+commited to the packaging repository".  It simply happens that
upstream/metadata is added and after lintian-brush git consideres the
local repository not clean any more since there are files that are not
yet added.  You should be able to verify this by simply removing
upstream/metadata and run lintian-brush (or whatever tool finally is
adding this file.)  I would not mind about a missing changelog entry but
at least the freshly created file should be added.  I'm pretty sure this
is a regression since that worked before.

> You can see whether it thinks it needs to update the changelog by running
> ``detect-changelog-behaviour``.

I simply want to have a changelog entry once something was changed.

> (Also happy to take bug reports on the autodetection behaviour not working 
> well,
> but in that case, please provide extra context).

This was not really the point of my bug report but if I notice something
I will file an according bug report.

Kind regards and thanks a lot for all those Janitor tools which are
really helpful. 

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1064853: RM: r-bioc-rhtslib [armel armhf i386] -- ANAIS; No longer built

Package: ftp.debian.org
Control: affects -1 + src:r-bioc-rhtslib
X-Debbugs-Cc: r-bioc-rhts...@packages.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Severity: normal

Hi,

starting with 2.4.1+dfsg-2 the r-bioc-rhtslib package no longer builds
for 32bit archs. The previously built 32bit packages prevents migration
to testing and debci tests fail for other packages, too.

Sebastian

Bug#1064852: incus: missing depends on iproute2

Package: incus
Version: 0.6-1
Severity: serious
Justification: missing dependency

After installing incus any "incus *" command (even incus info) just
hangs with no indication what's wrong. journalctl -u incus eventually
reveals:


Feb 26 16:47:45 testvm incusd[685]: Error: exec: "ip": executable file not 
found in $PATH

After installing iproute2, incus starts and incus commands start
working.

Helmut

Bug#1064850: unibilium: stop using libtool-bin

Source: unibilium
Version: 2.1.0-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

We want to remove libtool-bin from the Debian archive, because it is
fundamentally incompatible with cross compilation. Using libtool-bin
usually indicates that libtool is being used in an unintended way. This
is also the case for unibilium. Rather than creating a libtool for the
concrete combination of build and host architecture, unibilium tries to
use a pre-configured system one. I'm attaching a patch that makes
unibilium generate a libtool during build. Please consider applying it.

Helmut
diff --minimal -Nru unibilium-2.1.0/debian/changelog 
unibilium-2.1.0/debian/changelog
--- unibilium-2.1.0/debian/changelog2023-06-23 01:26:23.0 +0200
+++ unibilium-2.1.0/debian/changelog2024-02-26 07:25:21.0 +0100
@@ -1,3 +1,10 @@
+unibilium (2.1.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Generate a libtool instead of using libtool-bin. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 26 Feb 2024 07:25:21 +0100
+
 unibilium (2.1.0-3) unstable; urgency=medium
 
   [ Sven Joachim ]
diff --minimal -Nru unibilium-2.1.0/debian/configure.ac 
unibilium-2.1.0/debian/configure.ac
--- unibilium-2.1.0/debian/configure.ac 1970-01-01 01:00:00.0 +0100
+++ unibilium-2.1.0/debian/configure.ac 2024-02-26 07:24:04.0 +0100
@@ -0,0 +1,3 @@
+AC_INIT([dummy],[1.0])
+LT_INIT
+AC_OUTPUT
diff --minimal -Nru unibilium-2.1.0/debian/control 
unibilium-2.1.0/debian/control
--- unibilium-2.1.0/debian/control  2023-06-23 01:26:23.0 +0200
+++ unibilium-2.1.0/debian/control  2024-02-26 07:14:11.0 +0100
@@ -3,7 +3,7 @@
 Maintainer: James McCoy 
 Build-Depends:
  debhelper-compat (= 13),
- libtool-bin,
+ libtool,
  perl,
 Standards-Version: 4.6.2
 Section: libs
diff --minimal -Nru unibilium-2.1.0/debian/rules unibilium-2.1.0/debian/rules
--- unibilium-2.1.0/debian/rules2023-06-23 01:26:23.0 +0200
+++ unibilium-2.1.0/debian/rules2024-02-26 07:24:25.0 +0100
@@ -7,7 +7,7 @@
 export CFLAGS
 export LDFLAGS
 
-LIBTOOL=libtool
+LIBTOOL=$(CURDIR)/debian/libtool/libtool
 ifneq (,$(filter terse,$(DEB_BUILD_OPTIONS)))
LIBTOOL+=--quiet
 endif
@@ -16,5 +16,15 @@
 %:
dh $@ --buildsystem makefile
 
+override_dh_auto_clean:override_dh_auto_configure
+   dh_auto_clean
+   rm -Rf debian/libtool
+
+override_dh_auto_configure:
+   mkdir debian/libtool
+   cp debian/configure.ac debian/libtool/
+   env -C debian/libtool LIBTOOLIZE='libtoolize -i' autoreconf -f -i
+   dh_auto_configure --sourcedirectory=debian/libtool 
--buildsystem=autoconf
+
 override_dh_auto_install:
$(MAKE) DESTDIR="$(CURDIR)/debian/tmp" PREFIX=/usr 
LIBDIR='$${PREFIX}/lib/$(DEB_HOST_MULTIARCH)' install

Bug#1055508: piuparts: helmut's little wishlist

Hi Andreas,

On Mon, Feb 26, 2024 at 05:08:09PM +0100, Andreas Beckmann wrote:
> can you take a look at #1064350 and #1064842, which may be a regression (not
> enough device nodes mounted to /dev) caused by your changes.

I looked, but I'm having difficulties making sense of it. Can you assist
with reproducing this somehow?

The first bug points at
https://salsa.debian.org/nvidia-team/bumblebee/-/jobs/5333059#L218 and
line 218 says "Created resolv.conf.". As far as I can see, this is only
emitted from create_resolv_conf() which is only called from
configure_chroot() and the next thing the function does is to stat
self.name + "/dev/null". Given that apt tries to create it later, the
most plausible hypothesis is that it raises FileNotFoundError. Then we
try to os.mknod it as a character device. If that were to succeed, apt
couldn't create it, so it likely raises an OSError with EPERM. Then we
try to create it as a regular file. If that were to succeed, apt
wouldn't report it as missing. If that were to fail, an exception would
unwind configure_chroot and then create and make piuparts crash. Since
this is not happening, the most plausible hypothesis seems to be that
something deletes /dev/null after this method has concluded. Not much is
running there but tmp/scripts/post_chroot_unpack_allow_unauthenticated.

Do you see any flaws in this reasoning?

Regarding the other bug, I set up incus, launched a debian/sid container
and successfully ran piuparts there. The original reports says VM, not
container though. I also tried a --vm, but incus didn't like my qemu
(probably due to nested virtualization) and refused.

I have no idea how to reproduce these failures.

The assumption behind your message is that
https://salsa.debian.org/debian/piuparts/-/commit/aa916c1eabdc1579fc31e7ff12254df478cc9a14
causes this regression. Before the change, /dev/null is created using
the mknod binary. After the change /dev/null is created (also as a
character device) using os.mknod (Python function). I have no idea why
mknod does not work in these scenarios, but this is not the important
part of my change and more of an drive-by optimization (less forks ->
more speed was the idea). The important part is handling a failure from
mknod and turn it into a bind mount of the original device. From my pov,
the change from /bin/mknod to os.mknod can be reverted, but I'd like to
understand why it breaks stuff and have no luck at understanding nor
reproducing this.

Helmut

Bug#1064851: 4 packages from emacs have an undeclared file conflict on /usr/bin/emacsclient.emacs