Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Matthias Klose]

Package: linux-libc-dev
Version: 6.7.7-1
Severity: serious
Tags: sid trixie

linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it 
doesn't do that completely


Provides: linux-libc-dev-amd64-cross (= 6.7.7-1), ...

However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.

Please stop providing the cross-packages, you don't even need a breaks, 
because the current cross packages continue to work.


Once that is done, I'll reduce the cross packages to some symlinks.

Bug#1064950: AW: Bug#1064950: apache2: (Legacy?) "Depends: apache2-data (= ${source:Version})," in debian/control breaks binNMU builds.

[Sebastian Ramacher]

On 2024-03-04 06:19:58 +, Warlich, Christof wrote:
> Sebastian Ramacher wrote:
> > This is wrong. apache2-data is an Architecture: all package,
> > but apache2 is Architecture: any. So using ${source:Version}
> > here is correct. Note that Debian does not currently support
> > binNMUs for Architecture: all packages, so apache2-data will
> > never have a +bX version.
> 
> Thanks for that clarification.
> 
> This is somewhat confusing for someone not doing package builds as a daily 
> profession: If just doing a "dpkg-buildpackage -us -uc" on the apache2 
> sources _with_ the +bX extension, the apache2-data binary package _does_ get 
> the +bX extension as well, at least with my build, causing the issue that I 
> described initially.

For binNMUs you'll need to pass "-B" at least, but see below.

> Thus, as much as I think I've leaned so far, binNMU builds on source packages 
> that also produce Architekture: all binary packages must always be built 
> separately from sources without the +bX extension for the Architecture: all 
> binary packages, whereras the architecture-dependent binary packages may be 
> built from a source package with a +bX extension, right?

Not exactly. The source packages are not changed for binNMUs. This is
handled via sbuild's --binNMU-* options to set the changelog and the
version. Specifically, these options imply that Arch: all binaries are
not built.

> If this assumption is true, then why is the Debian build system (i.e. 
> dpkg-buildpackage) not smart enough to simply ignore an existing +bX 
> extension for Architecture: all binary packages? IMHO, this would simplify 
> matters, as it would have avoided the pitfall that I stumbled into altogether.

binNMUs are handled a layer above. sbuild will pass the correct options
to dpkg-buildpackage to build binNMUs. If you are interested in having
binNMU builds for your own infrastructure, you'll probably need to take
a look at the sbuild source to see how it is implemented.

Cheers
-- 
Sebastian Ramacher

Bug#1065415: grub2: Work around possible failure in cpio_test

[Christoph Biedl]

Source: grub2
Version: 2.12-1
Severity: normal
Tags: patch

Dear Maintainer,

Hello,

while rebuilding grub, I encountered two issues from the test suite.
Perhaps I've already reported them but cannot find any traces of that.


One is, things go downhill in util/grub-shell if an environment
variable "debug" is set, but it seems this was fixed in newer versions
of grub (no longer found with 2.12-1, currently in testing).


Still open however: There is a limitation in cpio, it cannot deal with
an user ID above 2^21-1. If the build is done using a bigger ID, it
will just fail:

FAIL: cpio_test
===
(...)
cpio: ./: value uid 3123456 out of allowed range 0..2097151
cpio: sdir/: value uid 3123456 out of allowed range 0..2097151
cpio: sdir/2.img: value uid 3123456 out of allowed range 0..2097151
(...)

Fix, as attached: Probe for that situation, and exit gracefully.

Another solution might be using fakeroot then.

Kind regards,

Christoph

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

--- a/tests/cpio_test.in
+++ b/tests/cpio_test.in
@@ -7,6 +7,12 @@
exit 99
 fi
 
+uid="$(id -u)"
+if [ "$uid" -gt 2097151 ]; then
+   echo "User ID $uid is too big to run cpio tests"
+   exit 77
+fi
+
 "@builddir@/grub-fs-tester" cpio_bin
 "@builddir@/grub-fs-tester" cpio_odc
 "@builddir@/grub-fs-tester" cpio_newc


signature.asc
Description: PGP signature

Bug#1064593: debian-policy: missing static resources for www.debian.org policy page

[Stéphane Blondon]

Hello,

Le dim. 3 mars 2024 à 11:49, Holger Wansing  a écrit :
> So, no problem with latest Sphinx version, it seems the integration in the
> debian-policy package is the problem (aka debian/rules) ...

Thank you for the search.

I have two wild guesses based on broken symlink assumption:

1. By dh_auto_install

buildd create symbolic links to the files (like theme.css) provided by
python3-sphinx-rtd-theme:
lrwxrwxrwx root/root 0 2024-02-24 12:39
./usr/share/doc/debian-policy/policy.html/_static/css/theme.css ->
../../../../../sphinx_rtd_theme/static/css/theme.css
(found in the log file)

Then the target dh_auto_install in debian/rules from debian_policy
moves files (line 15):
mv debian/tmp/* debian/debian-policy/

The symlink is relative so it could be broken.

2. By the webserver

In such case, the symlink is still correct after the install. However,
the target directory would be outside the static directories served by
the webserver. By default, they are not followed by the webserver to
avoid leaking data outside the static root directory.


Hope it helps,
Stéphane

Bug#1065414: gargoyle-free: Backport fontconfig fix into 2022.1?

[Yi Xing]

Package: gargoyle-free
Version: 2022.1+dfsg-1
Severity: important
X-Debbugs-Cc: blandil...@gmail.com

Dear Maintainer,

There's a bug with fontconfig in gargoyle 2022.1 that has been fixed in commit
524a1b6, and the fix is in 2023.1. This bug crashes the 2022.1 version (see
https://github.com/garglk/garglk/issues/827), so is it possible to backport the
fix into the old version or release the new version in the stable channel?

Best regards,

Yi Xing


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

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

Versions of packages gargoyle-free depends on:
ii  fonts-go 0~20170330-1
ii  fonts-sil-charis 6.101-1
ii  libc62.36-9+deb12u4
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-5
ii  libgcc-s112.2.0-14
ii  libjpeg62-turbo  1:2.1.5-2
ii  libpng16-16  1.6.39-2
ii  libqt5core5a 5.15.8+dfsg-11
ii  libqt5gui5   5.15.8+dfsg-11
ii  libqt5widgets5   5.15.8+dfsg-11
ii  libsdl2-2.0-02.26.5+dfsg-1
ii  libsdl2-mixer-2.0-0  2.6.2+dfsg-2
ii  libspeechd2  0.11.4-2
ii  libstdc++6   12.2.0-14
ii  zlib1g   1:1.2.13.dfsg-1

gargoyle-free recommends no packages.

gargoyle-free suggests no packages.

-- no debconf information

Bug#1063621: bookworm-pu: package clamav/clamav_1.0.5+dfsg-1~deb12u1

[Sebastian Andrzej Siewior]

On 2024-02-09 23:12:18 [+0100], To sub...@bugs.debian.org wrote:
> Package: release.debian.org
> Control: affects -1 + src:clamav
> X-Debbugs-Cc: cla...@packages.debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: bookworm
> Severity: normal
> 
> This is an update to the latest clamav release in the 1.0.x series. This
> update closes two CVEs:
> 
> - CVE-2024-20290: Fixed a possible heap overflow read bug in the OLE2 file
>   parser that could cause a denial-of-service (DoS) condition.
> 
> - CVE-2024-20328: Fixed a possible command injection vulnerability in the
>   "VirusEvent" feature of ClamAV's ClamD service.
> 
>   To fix this issue, we disabled the '%f' format string parameter.  ClamD
>   administrators may continue to use the `CLAM_VIRUSEVENT_FILENAME`  
> environment
>   variable, instead of '%f'. But you should do so only from within  an
>   executable, such as a Python script, and not directly in the clamd.conf
>   "VirusEvent" command.

A friendly ping.

Sebastian

Bug#1065413: bookworm-pu: package openssl/3.0.13-1~deb12u1

[Sebastian Andrzej Siewior]

Package: release.debian.org
Control: affects -1 + src:openssl
X-Debbugs-Cc: open...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
X-Debbugs-Cc: sebast...@breakpoint.cc
Severity: normal

This is an update to the current stable OpenSSL release in the 3.0.x
series. It addresses the following CVE reports which were postponed due
to low severity:

- CVE-2023-5678 (Fix excessive time spent in DH check / generation with
  large Q parameter value)
- CVE-2023-6129 (POLY1305 MAC implementation corrupts vector registers on
  PowerPC)
- CVE-2023-6237 (Excessive time spent checking invalid RSA public keys)
- CVE-2024-0727 (PKCS12 Decoding crashes)

I'm not aware of a problems/ regression at this point. During the upload
of 3.1.x release to upstable at the time m2crypto and nodejs failed to
build. I verified that m2crypto in stable and nodejs in stable-security
build against this version of openssl.

Sebastian

Bug#1065412: src:pytables: fails to migrate to testing for too long: old s390x binary left around

[Paul Gevers]

Source: pytables
Version: 3.7.0-10
Severity: serious
Control: close -1 3.9.2-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1061661

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:pytables has been trying to migrate for 64 
days [2]. Hence, I am filing this bug. As suggested in bug 1061661, the 
s390x binary needs to be removed by ftp-master. Somebody needs to 
request it.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=pytables



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064950: AW: Bug#1064950: apache2: (Legacy?) "Depends: apache2-data (= ${source:Version})," in debian/control breaks binNMU builds.

[Warlich, Christof]

Sebastian Ramacher wrote:
> This is wrong. apache2-data is an Architecture: all package,
> but apache2 is Architecture: any. So using ${source:Version}
> here is correct. Note that Debian does not currently support
> binNMUs for Architecture: all packages, so apache2-data will
> never have a +bX version.

Thanks for that clarification.

This is somewhat confusing for someone not doing package builds as a daily 
profession: If just doing a "dpkg-buildpackage -us -uc" on the apache2 sources 
_with_ the +bX extension, the apache2-data binary package _does_ get the +bX 
extension as well, at least with my build, causing the issue that I described 
initially.

Thus, as much as I think I've leaned so far, binNMU builds on source packages 
that also produce Architekture: all binary packages must always be built 
separately from sources without the +bX extension for the Architecture: all 
binary packages, whereras the architecture-dependent binary packages may be 
built from a source package with a +bX extension, right?

If this assumption is true, then why is the Debian build system (i.e. 
dpkg-buildpackage) not smart enough to simply ignore an existing +bX extension 
for Architecture: all binary packages? IMHO, this would simplify matters, as it 
would have avoided the pitfall that I stumbled into altogether.

Please note that I my main goal is to better understand how to do it right for 
future builds.

Bug#870679: ghostscript: Annotate debian/conrol for DEB_BUILD_PROFILES=stage1

[Steven Robbins]

Control: tags -1 + moreinfo

Hello,

I'm not sure what is being requested.  

On Thu, 3 Aug 2017 18:51:10 -0700 Daniel Schepler  wrote:
> Source: ghostscript
> Version: 9.21~dfsg-1
> Severity: wishlist
> 
> It would be nice if the source package could be updated with build
> profile annotations for libcups2-dev  and libcupsimage2-dev
> .  

Those packages are generated from the "cups" source package.  Was this bug 
intended for cups?

> Of course, then you would probably either need to split
> off the cups driver into a separate package ghostscript-cups (though I
> don't know if it's even supported to build the driver as a plugin, as
> ghostscript-x support is).  Or otherwise, it would need to produce a
> ghostscript-stage1 package since it would have different binary
> contents from the full ghostscript package.
> -- 
> Daniel Schepler
> 
> 


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

Bug#1065352: Copyright in LGPL projects

[Alan M Varghese]

Hello Mentors,

I have been working on packaging Hyprland window manager.
hyprlang (with a 'g') is a new dependency for this project. This project 
(hyprlang) is licensed under LGPL.

But, the project authors haven't included a copyright notice anywhere in the 
project. It turns out that the
authors are not sure if this is required for an LGPL project[1].

From a Debian perspective, what is the recommendation regarding this? Do we 
require projects to include the
copyright information along with LGPL?

If the copyright *has* to be included, is it enough to include it in a 
COPYRIGHT file? I couldn't find an
example of a project that does this. Most projects seem to include a copyright 
line along with a short form
of LGPL in each file. (I think it may be more appealing to upstream authors if 
we don't have to include the
copyright in every file).

For example, libplacebo[2] is a library I found installed on my system that 
uses LGPL. This project does not
have a common copyright file, but there are copyright notices in some source 
files[3]. While some other source
files in this project do not have a copyright notice[4][5][6].

Note: my doubts are specifically regarding the LGPL license. For other licenses 
like BSD, I see both practices
of including a COPYRIGHT file as well as a short copyright notice in each file, 
or a combination of the two.

Thanks,
Alan M Varghese

[1] https://github.com/hyprwm/hyprlang/issues/28
[2] https://code.videolan.org/videolan/libplacebo
[3] 
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/dither.c?ref_type=heads
[4] 
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/dummy.c?ref_type=heads
[5] 
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/cache.c?ref_type=heads
[6] 
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/colorspace.c?ref_type=heads

Bug#1065411: dash: 'jobs' utility does not generate output in a pipe

[Marc Lehmann]

Package: dash
Version: 0.5.12-6
Severity: normal

Dear Maintainer,

I found that 'jobs' in dash is silent when stdout is a pipe:

   # dash -c 'sleep 1 1|wc -l'
   0

afaics, this is not documented behaviour, and other utilities (kill, alias) seem
to work fine.

bash does allow the output of jobs to be parsed:

   # bash -c 'sleep 1 1|wc -l'
   2

I think the bash behaviour is more useful for shell programming, and
probably correct, as the sus does not seem to indicate that jobs should
have no output in this case.

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 6.6.15-amd64 (SMP w/28 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 dash depends on:
ii  debianutils  5.7-0.5~deb12u1
ii  dpkg 1.21.22
ii  libc62.36-9+deb12u4

dash recommends no packages.

dash suggests no packages.

-- debconf information excluded

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Holger Wansing  writes:

> Hi,
>
> Am 2. März 2024 21:07:34 MEZ schrieb Philip Hands :
>>
>>This sentence is the thing that prompted me to change things in the
>>first place, because it is not true. One does not _need_ to set a root
>>password.
>
> It should be understood as 
> "If you want to enable login as root, you have to set a root password now."
>
> And in expert mode it is in fact working this way:
> At first, you are asked if you want to enable login as root. If you answer 
> yes 
> here, you are prompted to set a root password. 
> And at that point it is indeed required to set a root password, since you 
> chose to enable root login in the first question and the installer does not
> allow an empty password for root.
>
> To make it work in default install, we could change the question as
> in above citation.
>
>>I don't actually care very much whether we encourage sudo use. My
>>wording ended up (after many variations) quite strongly encouraging it
>>mostly as an antidote to the implication that comes from having a
>>question dedicated to setting the root password, but I'd be happy with
>>any wording that makes sure that people understand that both options are
>>totally fine.
>
> The sudo possibility is also mentioned:
>
> 'The root user should not have an empty password. If you leave this
> empty, the root account will be disabled and the system's initial user
> account will be given the power to become root using the "sudo"
> command.'
>
> I have rephrased that a bit, see below.
>
>>The other thing that I was trying to ensure is that people are reassured
>>that they'll get to specify a password that will get them root access even if
>>they decide to leave the root password unset.  This is because I've seen
>>people become quite uncertain about what to expect at this point in the
>>install.
>>
>>I've found that it is not easy to come up with things that include much
>>nuance about this, while still fitting in the space available, which is
>>why I decided to try a more opinionated approach.
>>
>>One could soften what I wrote by replacing "generally recommended" with
>>something like "often appropriate" -- how does that seem to people?
>
> Your proposal too much focusses on the sudo way IMO.
> We risk getting complains from people, who miss advise regarding the
> enabled root login.
>
> I have rephrased the dialog a bit, to make the sudo way more visible and
> better understandable.
>
>>One can of course tinker with this stuff indefinitely. I actually spent
>>a fair amount of time wondering how best to describe not setting a root
>>password for instance -- should one say "leave the password unset", "set
>>an empty password", "enter no password", or something like "just hit
>>"? (and does that last one actually apply to all the available
>>UIs?).
>>
>>The same goes for how you say that the password is not going to get
>>shown (unless you ask for it to be shown), which in the GTK UI gets
>>characters replaced with dots, IIRC in the text UI its with asterisks,
>>and I'd guess it just gets completely hidden in the speech install.
>
> I think that's not much of a problem. People are used to the situation,
> that passwords are not shown, but replaced by asterisks or similar.
> And we have the checkbox for showing it in clear text, that should be
> enough.
>
>
> Updated patch attached.
>
>
> Holger
>
>
>
> diff --git a/debian/user-setup-udeb.templates 
> b/debian/user-setup-udeb.templates
> index cdb6d78..7393511 100644
> --- a/debian/user-setup-udeb.templates
> +++ b/debian/user-setup-udeb.templates
> @@ -34,21 +34,19 @@ Template: passwd/root-password
>  Type: password
>  # :sl1:
>  _Description: Root password:
> - You need to set a password for 'root', the system administrative
> - account. A malicious or unqualified user with root access can have
> + If you want to allow login as root, you need to set a password for 'root',
> + the system administrative account now.
> + A malicious or unqualified user with root access can have
>   disastrous results, so you should take care to choose a root password
> - that is not easy to guess. It should not be a word found in dictionaries,
> - or a word that could be easily associated with you.
> + that cannot be guessed. It should not be a word found in dictionaries,
> + or something that could be easily associated with you.
>   .
> - A good password will contain a mixture of letters, numbers and punctuation
> - and should be changed at regular intervals.
> + You can also leave the password for root empty here, to disable the root
> + account; the system's initial user account (which will be set up in the next
> + step) will then be given the power to become root using the "sudo" command.
>   .
> - The root user should not have an empty password. If you leave this
> - empty, the root account will be disabled and the system's initial user
> - account will be given the power to become root using the "sudo"
> - command.
> - .
> - Note that you will not be able to see 

Bug#1065396: ghostscript: Coordinate uploads for German man page transfer

[Steven Robbins]

Hello!

Thanks for the note!

On Sun, 3 Mar 2024 19:59:28 + Helge Kreutzmann  
wrote:
> Package: ghostscript
> Version: 10.0.0~dfsg-11+deb12u3
> Severity: normal
> 
> Hello Steve,
> ghostscript used to contain German man pages, however, they were not
> properly maintained. As detailed in [1] ghostscript removed the 
> German man pages from its git repository on January 4th 2023.
> 
> So the files are gone since Version 10.01.0rc1.
> 
> I imported them into manpages-de and will start shipping them with the
> next release.
> 
> As per transition rules [2] you will need to add 
> Breaks: manpages-l10n (<4.22) 
> in your debian/control.

OK.  Committed to git.  Will be uploaded as version 10.02.1~dfsg-4.

 
> I will then add
> Breaks: ghostscript (< Replaces: ghostscript (< 
> In my debian/control. I'm a bit lost about the correct version,
> though. So which version is best for "?"

I rarely deal with these situations, so I may be wrong, but
I would think the best version is the new one:  10.02.1~dfsg-4.


> I intend to upload around March 23 and I will provide a backport to
> stable (without these translations, of course).

OK.  You titled the bug "coordinate uploads ...".  Do we need to do them 
together - on the same day or something?

Regards,
-Steve


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

Bug#1065015: the control file for the akonadi libraries are palin wrong

[Sune Stolborg Vuorela]

On Sunday, March 3, 2024 6:16:23 PM CET Eric Valette wrote:
> The transition is completed but the package cannot install because of
> Breaks: in the control file

The transition is still on going. This is in absolute number of packages the 
biggest one ever. If it it wasn't for all of the newish languages like node/
js, go and rust it would also in the relative numbers be the biggest one ever.

It is bigger than the c++ abi change with the c2a packages that happened back 
in KDE 3.4 times.
 
> And I second that the abi provided should be without
> t64libkf5akonadisearchpim5-22.12

It should not. I think you need to read up on the purpose of the transition 
and how it is done.

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#1061025: Additional information

[Vladimir Petko]

Dear Maintainers,

httpcomponents-client contains an implicit dependency on slf4j-java.

Last time it was build successfully against libcommons-log-java 1.2[1]

Support for slf4j was added after its release[2][3]

Debian and Ubuntu have slf4j 1.7.32-1 which calls
org.apache.commons.logging.LogFactory.getLog[4].

This causes exception in httpclient-cache tests[5]:

java.lang.IllegalStateException: Recursive update
 at 
java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1763)

Best Regards,
 Vladimir.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=httpcomponents-client=all=4.5.14-1=1670330442=0
[2] https://github.com/apache/commons-logging/pull/177
[3] 
https://github.com/apache/commons-logging/commits/master/src/main/java/org/apache/commons/logging/impl/Slf4jLogFactory.java
[4] 
https://github.com/qos-ch/slf4j/blob/e9ee55cca93c2bf26f14482a9bdf961c750d2a56/slf4j-jcl/src/main/java/org/slf4j/impl/JCLLoggerFactory.java#L77
[5] 
https://launchpad.net/~vpa1977/+archive/ubuntu/october-21/+build/27798162/+files/buildlog_ubuntu-noble-amd64.httpcomponents-client_4.5.14-1_BUILDING.txt.gz

Bug#1065410: libhsa-runtime64-1: assertion in gfx10addrlib.cpp on gfx1035

[Cordell Bloor]

Package: libhsa-runtime64-1
Version: 5.7.1-1
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

Many tests began failing for the gfx1035 ISA on the Debian ROCm CI upon
the update to libhsa-runtime64-1 (5.7.1-1). The failure is an assertion:

./src/image/addrlib/src/gfx10/gfx10addrlib.cpp:1083: virtual 
rocr::Addr::ChipFamily rocr::Addr::V2::Gfx10Lib::HwlConvertChipFamily(unsigned 
int, unsigned int): Assertion `false' failed.

The rocblas test logs suggest that this was introduced with the update
to rocr-runtime 5.7.1-1 [1], as the tests passed before [2]. On Debian
Testing, it even passed with libhsakm1 (5.7.0-1) [3].

The assertion is complaining that it's not a Rembrandt ASIC [4].
However, the test system is a Minisforum UM773 Lite with an AMD Ryzen
7735 HS (/w AMD Radeon 680M integrated graphics). That's Rembrandt.

Sincerely,
Cory Bloor

[1]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1035/r/rocblas/7826/log.gz
[2]: 
https://ci.rocm.debian.net/data/autopkgtest/unstable/amd64+gfx1035/r/rocblas/4334/log.gz
[3]: 
https://ci.rocm.debian.net/data/autopkgtest/testing/amd64+gfx1035/r/rocblas/8115/log.gz
[4]: 
https://salsa.debian.org/rocm-team/rocr-runtime/-/blob/debian/5.7.1-1/src/image/addrlib/src/gfx10/gfx10addrlib.cpp?ref_type=tags#L1083

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

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

Versions of packages libhsa-runtime64-1 depends on:
ii  libc6   2.38-6
ii  libdrm-amdgpu1  2.4.120-2
ii  libdrm2 2.4.120-2
ii  libelf1 0.190-1+b1
ii  libgcc-s1   14-20240221-2.1
ii  libhsakmt1  5.7.0-1
ii  libstdc++6  14-20240221-2.1

libhsa-runtime64-1 recommends no packages.

libhsa-runtime64-1 suggests no packages.

-- no debconf information

Bug#1062696: libverto: NMU diff for 64-bit time_t transition

[Steve Langasek]

An overlooked hard-coded dependency in debian/control has made libverto
uninstallable.  Please find the debdiff for an updated NMU attached.

On Fri, Feb 02, 2024 at 06:18:40PM +, Steve Langasek wrote:
> Source: libverto
> Version: 0.3.1-1
> Severity: serious
> Tags: patch pending sid trixie
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
> 
> NOTICE: these changes must not be uploaded to unstable yet!
> 
> Dear maintainer,
> 
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> libverto as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
> 
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
> 
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for libverto
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
> 
> Please find the patch for this NMU attached.
> 
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.
> 
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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)

> diff -Nru libverto-0.3.1/debian/changelog libverto-0.3.1/debian/changelog
> --- libverto-0.3.1/debian/changelog   2020-06-08 13:37:48.0 +
> +++ libverto-0.3.1/debian/changelog   2024-02-02 18:18:10.0 +
> @@ -1,3 +1,10 @@
> +libverto (0.3.1-1.1) experimental; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename libraries for 64-bit time_t transition.
> +
> + -- Steve Langasek   Fri, 02 Feb 2024 18:18:10 +
> +
>  libverto (0.3.1-1) unstable; urgency=medium
>  
>[ Debian Janitor ]
> diff -Nru libverto-0.3.1/debian/control libverto-0.3.1/debian/control
> --- libverto-0.3.1/debian/control 2020-06-08 13:34:34.0 +
> +++ libverto-0.3.1/debian/control 2024-02-02 18:18:10.0 +
> @@ -12,7 +12,7 @@
>  Package: libverto-dev
>  Section: libdevel
>  Architecture: any
> -Depends: ${misc:Depends}, libverto1 (= ${binary:Version}), libverto-glib1 (= 
> ${binary:Version}), libverto-libev1 (= ${binary:Version})
> +Depends: ${misc:Depends}, libverto1t64 (= ${binary:Version}), 
> libverto-glib1t64 (= ${binary:Version}), libverto-libev1t64 (= 
> ${binary:Version})
>  Description: Event loop abstraction for Libraries - Development
>   Libverto exists to isolate libraries from the particular event loop
>   chosen by an application. Libverto provides an asynchronous
> @@ -22,7 +22,10 @@
>   .
>   This package includes development libraries.
>  
> -Package: libverto1
> +Package: libverto1t64
> +Provides: ${t64:Provides}
> +Replaces: libverto1
> +Breaks: libverto1 (<< ${source:Version})
>  Section: libs
>  Architecture: any
>  PRe-Depends: ${misc:Pre-Depends}
> @@ -37,7 +40,10 @@
>   .
>   This package includes the main runtime library.
>  
> -Package: libverto-libev1
> +Package: libverto-libev1t64
> +Provides: ${t64:Provides}
> +Replaces: libverto-libev1
> +Breaks: libverto-libev1 (<< ${source:Version})
>  Section: libs
>  Architecture: any
>  PRe-Depends: ${misc:Pre-Depends}
> @@ -52,7 +58,10 @@
>   .
>   This package includes support for the libev event loop.
>  
> -Package: libverto-glib1
> +Package: libverto-glib1t64
> +Provides: ${t64:Provides}
> +Replaces: libverto-glib1
> +Breaks: libverto-glib1 (<< ${source:Version})
>  Section: libs
>  Architecture: any
>  PRe-Depends: ${misc:Pre-Depends}
> diff -Nru libverto-0.3.1/debian/libverto-glib1.install 
> libverto-0.3.1/debian/libverto-glib1.install
> --- libverto-0.3.1/debian/libverto-glib1.install  2014-05-29 
> 00:36:01.0 +
> +++ 

Bug#1065394: debootstrap Sid failed to run due to libuuid1t64 and libuuid1 coexist

[Steven Shiau]

Hi,
debootstrap Sid on amd64 failed to run due to libuuid1t64 2.39.3-6.1 and 
libuuid1 2.39.3-9 coexist:

debootstrap --verbose --arch=amd64 sid sid-chroot
...
I: Extracting libunistring5...
I: Extracting libuuid1...
I: Extracting libuuid1t64...
E: Tried to extract package, but tar failed. Exit...

Though libuuid1 2.39.3-9 from util-linux was released, the libuuid1t64 
2.39.3-6.1 still in the repository, therefore causing debootstrap fails.


Steven

--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#996202: EFI Secure Boot for systemd-boot

[Luca Boccassi]

On Fri, 19 Nov 2021 09:33:00 +0100 Bastian Blank 
wrote:
> Hi
> 
> I'm rescinding this request.  I've got a working prototype, but I
don't
> know where this would go.
> 
> Bastian

The upstream Shim reviewers group now accepts systemd-boot as a 2nd
stage bootloader, trusted by Shim builds signed with the UEFI 3rd party
CA. This clears the way for Debian's CA to sign systemd-boot, so I am
reopening this bug.

shim-review questionnaire update that allows systemd-boot:

https://github.com/rhboot/shim-review/pull/357

MR on Salsa to add the usual template package, adapted from Bastian's
MR from a couple of years ago:

https://salsa.debian.org/systemd-team/systemd/-/merge_requests/252

Debian Shim maintainers, who do we need to seek approvals for this to
happen? Shim maintainers first of course, anybody else? Release team?
FTP team?

-- 
Kind regards,
Luca Boccassi


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

Bug#1065389: RFS: python-click/8.1.7-1 [ITA] -- Wrapper around optparse for command line utilities - documentation

[Bo YU]

Hi!

On Mon, Mar 4, 2024 at 1:51 AM Akash Doppalapudi
 wrote:
>
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "python-click":
>
>   * Package name : python-click
> Version  : 8.1.7-1
> Upstream contact : cont...@palletsprojects.com
>   * URL  : https://github.com/pallets/click
>   * License  : BSD-3-clause
>   * Vcs  :
> https://salsa.debian.org/python-team/packages/python-click
> Section  : python
>
> The source builds the following binary packages:
>
>python3-click - Wrapper around optparse for command line utilities -
> Python 3.x
>python-click-doc - Wrapper around optparse for command line utilities
> - documentation
>
> To access further information about this package, please visit the
> following URL:
>
>https://mentors.debian.net/package/python-click/
>
> Alternatively, you can download the package with 'dget' using this command:
>
>dget -x
> https://mentors.debian.net/debian/pool/main/p/python-click/python-click_8.1.7-1.dsc
>
> Changes since the last upload:
>
>   python-click (8.1.7-1) unstable; urgency=medium
>   .
> * New upstream version 8.1.7
> * New Maintainer (Closes: #1065251)

I would like to suggest you contact  Peter Pentchev 
as he/she has reported ITA earlier than your ITA.
And would you really want to maintain these packages without Debian
Python Team? No other meaning, just considering these packages should
be maintained under DPT sounds more reasonable.

BR,
Bo

> * d/control:
>   - Change Maintainer name
>   - Add python-click-doc in Suggests for python3-click
> * d/copyright:
>   - Add new maintainer name in copyright stanza
>
> Regards,
> --
>Akash Doppalapudi

Bug#1063170: nettle: NMU diff for 64-bit time_t transition

[Steve Langasek]

The previous NMU overlooked a hard-coded reference to the old library name
in debian/rules.  Please find an amended NMU 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 nettle-3.9.1/debian/changelog nettle-3.9.1/debian/changelog
--- nettle-3.9.1/debian/changelog   2023-07-27 14:31:36.0 +
+++ nettle-3.9.1/debian/changelog   2024-03-04 01:24:40.0 +
@@ -1,3 +1,17 @@
+nettle (3.9.1-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix documentation link target to fix nettle-bin uninstallability.
+
+ -- Steve Langasek   Mon, 04 Mar 2024 01:24:40 +
+
+nettle (3.9.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.  Closes: #1063170
+
+ -- Benjamin Drung   Wed, 28 Feb 2024 22:51:33 +
+
 nettle (3.9.1-2) unstable; urgency=low
 
   * Upload to unstable.
diff -Nru nettle-3.9.1/debian/control nettle-3.9.1/debian/control
--- nettle-3.9.1/debian/control 2023-07-27 14:31:36.0 +
+++ nettle-3.9.1/debian/control 2024-02-28 22:51:33.0 +
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Magnus Holmgren 
-Build-Depends: dpkg-dev (>= 1.15.7), debhelper-compat (= 12),
+Build-Depends: dpkg-dev (>= 1.22.5), dpkg-dev (>= 1.15.7), debhelper-compat (= 
12),
  libgmp-dev, m4, texinfo
 Standards-Version: 4.6.2
 Vcs-Git: https://salsa.debian.org/holmgren/nettle.git
@@ -10,7 +10,10 @@
 Homepage: http://www.lysator.liu.se/~nisse/nettle/
 Rules-Requires-Root: no
 
-Package: libnettle8
+Package: libnettle8t64
+Provides: ${t64:Provides}
+Replaces: libnettle8
+Breaks: libnettle8 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
@@ -32,7 +35,10 @@
  algorithms. To avoid having this package depend on libgmp, the
  asymmetric cryptos reside in a separate library, libhogweed.
 
-Package: libhogweed6
+Package: libhogweed6t64
+Provides: ${t64:Provides}
+Replaces: libhogweed6
+Breaks: libhogweed6 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
@@ -58,7 +64,7 @@
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: libnettle8 (= ${binary:Version}), libhogweed6 (= ${binary:Version}),
+Depends: libnettle8t64 (= ${binary:Version}), libhogweed6t64 (= 
${binary:Version}),
  libgmp-dev, ${misc:Depends}
 Replaces: libnettle-dev
 Conflicts: libnettle-dev
diff -Nru nettle-3.9.1/debian/libhogweed6.install 
nettle-3.9.1/debian/libhogweed6.install
--- nettle-3.9.1/debian/libhogweed6.install 2023-07-27 14:31:36.0 
+
+++ nettle-3.9.1/debian/libhogweed6.install 1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-usr/lib/*/libhogweed*.so.*
diff -Nru nettle-3.9.1/debian/libhogweed6.symbols 
nettle-3.9.1/debian/libhogweed6.symbols
--- nettle-3.9.1/debian/libhogweed6.symbols 2023-07-27 14:31:36.0 
+
+++ nettle-3.9.1/debian/libhogweed6.symbols 1970-01-01 00:00:00.0 
+
@@ -1,292 +0,0 @@
-libhogweed.so.6 libhogweed6 #MINVER#
-* Build-Depends-Package: nettle-dev
- HOGWEED_6@HOGWEED_6 0
- HOGWEED_INTERNAL_6_8@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_cnd_copy@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_curve25519@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_curve25519_eh_to_x@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_curve448@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_curve448_eh_to_x@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_dsa_hash@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_a_to_j@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_add_eh@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_add_ehh@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_add_jja@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_add_jjj@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_add_th@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_add_thh@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_curve25519_modp@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_curve448_modp@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_dup_eh@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_dup_jj@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_dup_th@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_eh_to_a@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_hash@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_j_to_a@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_mod@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_mod_add@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_mod_addmul_1@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_mod_equal_p@HOGWEED_INTERNAL_6_8 3.9.1~
- (optional)_nettle_ecc_mod_inv@HOGWEED_INTERNAL_6_8 3.9.1~
- 

Bug#1065081: [Tts-project] Bug#1065081: Doesn't include the systemd unit needed for socket activation

[Samuel Thibault]

Hello,

Sebastien Bacher, le jeu. 29 févr. 2024 15:49:03 +0100, a ecrit:
> While rebasing the Ubuntu package on the new Debian version I noticed that
> the .install doesn't include the new systemd socket activation units (which
> is needed for tts in the firefox snap for example). THe attached patch fixes
> the issue, I've also bumped the compat level to 13 which default to
> --fail-missing and would catch such errors

Indeed, thanks!

Samuel

> diff -Nru speech-dispatcher-0.12.0~rc2/debian/changelog 
> speech-dispatcher-0.12.0~rc2/debian/changelog
> --- speech-dispatcher-0.12.0~rc2/debian/changelog 2024-02-22 
> 20:26:39.0 +0100
> +++ speech-dispatcher-0.12.0~rc2/debian/changelog 2024-02-29 
> 14:50:31.0 +0100
> @@ -1,3 +1,13 @@
> +speech-dispatcher (0.12.0~rc2-2) UNRELEASED; urgency=medium
> +
> +  * debian/control: 
> +- update to compat 13 which default to dh_missing --fail-missing
> +  * debian/rules, debian/speech-dispatcher.install:
> +- include the usr/lib/systemd/user directory which has the new
> +  socket activation entry
> +
> + -- Sebastien Bacher   Thu, 29 Feb 2024 14:50:31 +0100
> +
>  speech-dispatcher (0.12.0~rc2-1) experimental; urgency=medium
>  
>* New upstream RC release
> diff -Nru speech-dispatcher-0.12.0~rc2/debian/control 
> speech-dispatcher-0.12.0~rc2/debian/control
> --- speech-dispatcher-0.12.0~rc2/debian/control   2024-02-22 
> 20:20:46.0 +0100
> +++ speech-dispatcher-0.12.0~rc2/debian/control   2024-02-29 
> 14:50:31.0 +0100
> @@ -5,7 +5,7 @@
>  Uploaders:
>   Paul Gevers , Samuel Thibault 
>  Build-Depends:
> - debhelper-compat (= 12), dh-exec, dh-sequence-python3,
> + debhelper-compat (= 13), dh-exec, dh-sequence-python3,
>   automake, libtool,
>   python3:any, python3-xdg,
>   flite1-dev (>= 1.4), flite,
> diff -Nru speech-dispatcher-0.12.0~rc2/debian/rules 
> speech-dispatcher-0.12.0~rc2/debian/rules
> --- speech-dispatcher-0.12.0~rc2/debian/rules 2024-02-22 20:20:46.0 
> +0100
> +++ speech-dispatcher-0.12.0~rc2/debian/rules 2024-02-29 14:50:31.0 
> +0100
> @@ -4,6 +4,7 @@
>  include /usr/share/dpkg/pkg-info.mk
>  
>  export deb_systemdsystemunitdir = $(shell pkgconf 
> --variable=systemdsystemunitdir systemd | sed s,^/,,)
> +export deb_systemduserunitdir = $(shell pkgconf 
> --variable=systemduserunitdir systemd | sed s,^/,,)
>  
>  # NAS is in universe in Ubuntu
>  ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
> diff -Nru speech-dispatcher-0.12.0~rc2/debian/speech-dispatcher.install 
> speech-dispatcher-0.12.0~rc2/debian/speech-dispatcher.install
> --- speech-dispatcher-0.12.0~rc2/debian/speech-dispatcher.install 
> 2024-02-22 20:26:39.0 +0100
> +++ speech-dispatcher-0.12.0~rc2/debian/speech-dispatcher.install 
> 2024-02-29 14:50:31.0 +0100
> @@ -10,5 +10,7 @@
>  usr/share/speech-dispatcher
>  etc/speech-dispatcher
>  [linux-any] ${deb_systemdsystemunitdir}/speech-dispatcherd.service
> +[linux-any] ${deb_systemduserunitdir}/speech-dispatcher.service
> +[linux-any] ${deb_systemduserunitdir}/speech-dispatcher.socket
>  usr/share/man/man1/speech-dispatcher.1
>  usr/share/man/man1/spd-say.1

> ___
> Tts-project mailing list
> tts-proj...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/tts-project


-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Bug#1065409: graphicsmagick: text to image generation fails not able to get font metrics

[Leon Yu]

Package: graphicsmagick
Version: 1.4+really1.3.40-4
Severity: normal
X-Debbugs-Cc: l...@leonyu.net

Dear Maintainer,

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

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

I ran `gm convert -pointsize 40 label:"lorem ipsum" test.png`, command return 
with error:

gm convert: Unable to get type metrics (lorem ipsum) [No such file or 
directory].

I expect PNG image to be generated.

Since I use stable, I tried pulling Docker image of debian:experimental using 
Podman with the following one-liner, same result:

podman run -it debian:experimental bash -c 'apt-get update && apt-get -y 
install graphicsmagick && gm convert -debug All -font "Helvetica" -pointsize 40 
label:"lorem ipsum" test.png && ls -al test.png'

I tried Ubuntu, it works:

podman run -it ubuntu bash -c 'apt-get update && apt-get -y install 
graphicsmagick && gm convert -debug All -font "Helvetica" -pointsize 40 
label:"lorem ipsum" test.png && ls -al test.png'

I ran with `-debug All` and it produced the followig output: 

20:06:40 0:0.000283  0.000u 552121 log.c/SetLogEventMask/1520/Configure:
  Set log event mask: All
20:06:40 0:0.000329  0.000u 552121 constitute.c/ReadImage/1553/Blob:
  Magick=LABEL, Filename=lorem ipsum
20:06:40 0:0.000342  0.000u 552121 static.c/OpenModule/317/Configure:
  Magick "LABEL"
20:06:40 0:0.000357  0.000u 552121 static.c/OpenModule/347/Configure:
  Loaded static module "LABEL"
20:06:40 0:0.000370  0.000u 552121 constitute.c/ReadImage/1676/Coder:
  Invoking "LABEL" decoder (Image label) subimage=0 subrange=0
20:06:40 0:0.000451  0.000u 552121 type.c/ReadTypeConfigureFile/633/Configure:
  File path="type.mgk", recursion depth=0
20:06:40 0:0.000480  0.000u 552121 blob.c/GetConfigureBlob/2112/Configure:
  Searching for file "type.mgk" in path 
"/usr/share/GraphicsMagick-1.3.40/config/:/usr/lib/GraphicsMagick-1.3.40/config/"
20:06:40 0:0.000596  0.000u 552121 blob.c/GetConfigureBlob/2157/Configure:
  Tried: /usr/share/GraphicsMagick-1.3.40/config/type.mgk [No such file or 
directory]
20:06:40 0:0.000620  0.000u 552121 blob.c/GetConfigureBlob/2135/Configure:
  Found: /usr/lib/GraphicsMagick-1.3.40/config/type.mgk
20:06:40 0:0.000647  0.000u 552121 type.c/ReadTypeConfigureFile/633/Configure:
  File path="/usr/lib/GraphicsMagick-1.3.40/config/type-ghostscript.mgk", 
recursion depth=1
20:06:40 0:0.000907  0.000u 552121 utility.c/IsAccessible/2900/Configure:
  Tried: monospace [No such file or directory]
20:06:40 0:0.001001  0.000u 552121 annotate.c/RenderFreetype/1174/Type:
  Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb)
20:06:40 0:0.001035  0.000u 552121 label.c/ReadLABELImage/149/Type:
  Unable to get type metrics (lorem ipsum)
20:06:40 0:0.001051  0.000u 552121 pixel_cache.c/DestroyCacheInfo/3664/Cache:
  destroy cache
20:06:40 0:0.001063  0.000u 552121 blob.c/DestroyBlob/1169/Blob:
  Destroy blob (ref counted): image 0x55cb453fad40, blob 0x55cb453f7720, ref 1, 
filename "lorem ipsum"
20:06:40 0:0.001073  0.000u 552121 blob.c/DestroyBlob/1184/Blob:
Destroy blob (real): image 0x55cb453fad40, blob 0x55cb453f7720, ref 0, 
filename "lorem ipsum"
20:06:40 0:0.001083  0.000u 552121 constitute.c/ReadImage/1702/Coder:
  Returned from "LABEL" decoder, returned image is NULL!
gm convert: Unable to get type metrics (lorem ipsum) [No such file or 
directory].
20:06:40 0:0.001109  0.000u 552121 magick.c/DestroyMagick/173/Configure:
  Destroy Magick

*** 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/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages graphicsmagick depends on:
ii  libc62.36-9+deb12u4
ii  libgraphicsmagick-q16-3  1.4+really1.3.40-4

graphicsmagick recommends no packages.

Versions of packages graphicsmagick suggests:
ii  graphicsmagick-dbg  1.4+really1.3.40-4

-- no debconf information

Bug#1060270: cryptsetup /usr-move DEP17

[Guilhem Moulin]

Hi Helmut,

On Tue, 27 Feb 2024 at 14:28:33 +0100, Helmut Grohne wrote:
> Please reupload the patch to experimental (with a version higher than
> unstable) assuming that cryptsetup-nuke-password will use version 5 as I
> am in contact with Raphael Hertzog.

Done in 2:2.7.0-1+exp2.  Note though that this version (like all uploads
to experimental since December) isn't suitable for an upload to sid
since it uses OpenSSL's own argon2 implementation rather than
libargon2's, and sid's openssl is currently too old for that.

I was hopping the openssl transition would happen sooner, but for now
we're stuck with rebase/merge/revert between the two branches.  I didn't
revert the argon2-related changes in 2:2.7.0-1+exp1 or 2:2.7.0-1+exp2 as
they are orthogonal to DEP-17.

> I hope cryptsetup makes it to testing soon (it'll migrate with lvm2)
> such that we can move forward here.

I rest my case about this anyway: what I hoped to be a smooth transition
to testing will likely take longer as lvm2 is currently RC-buggy :-/
Moreover Ubuntu picked 2:2.7.0-1 already.

Let me know once it is time for an upload to sid.  If you want to upload
both packages in a single dput call I can provide the _source.changes
for cryptsetup.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1065408: isc-kea: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: isc-kea
Version: 2.4.1-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for isc-kea's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


isc-kea_2.4.1-2_pt.po.gz
Description: application/gzip

Bug#1064194: 535.86.05 breaks Xorg

[Andreas Beckmann]

Hi,

On 03/03/2024 18.01, Harald Dunkel wrote:

Are you sure that you really need nvidia-vulkan-icd (i.e.
nvidia-vulkan-common) and libnvidia-glvkspirv alone isn't enough?



Yes, installing libnvidia-glvkspirv is sufficient as a fix. If I remove
this package the problem is back.


Thanks for confirming my assumption.

I've moved the libnvidia-glvkspirv dependency to libnvidia-(e)glcore 
which seem to make more use of that in experimental.

Furthermore I've promoted nvidia-vulkan-icd to Recommends.


Andreas

Bug#1065407: debian-dvd-1: To enable Japanese input using anthy and uim, uim-anthy package is neccessary for Debian-DVD-1 installation media

[Green]

Package: debian-dvd-1
Version: 12.5.0
Severity: normal
Tags: l10n
X-Debbugs-Cc: usergr...@users.osdn.me

Dear Maintainer,

To enable Japanese input using anthy and uim,
uim-anthy package is neccessary for Debian-DVD-1 installation media.
Without it, we need to downlowd that package via internet.
Please include it in the future update.

This will help users in Japanese.

-- 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/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1064332: Bug#1065217: libpetsc-complex3.19-dev fails to install

[Steve Langasek]

Attached is a patch for a follow-up NMU correcting this issue.

On Sat, Mar 02, 2024 at 02:15:57AM +0200, Adrian Bunk wrote:
> Package: libpetsc-complex3.19-dev
> Version: 3.19.6+dfsg1-2.1
> Severity: serious
> Tags: ftbfs
> X-Debbugs-Cc: Benjamin Drung , Steve Langasek 
> 
> Control: affects -1 src:slepc
> 
> https://buildd.debian.org/status/fetch.php?pkg=slepc=amd64=3.19.2%2Bdfsg1-2.1=1709337662=0
> 
> ...
> Setting up libpetsc-complex3.19-dev:amd64 (3.19.6+dfsg1-2.1) ...
> update-alternatives: error: no alternatives for petsc
> update-alternatives: error: alternative path 
> /usr/lib/petscdir/petsc3.19t64/x86_64-linux-gnu-complex doesn't exist
> dpkg: error processing package libpetsc-complex3.19-dev:amd64 (--configure):
>  installed libpetsc-complex3.19-dev:amd64 package post-installation script 
> subprocess returned error exit status 2
> ...
> 

-- 
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 petsc-3.19.6+dfsg1/debian/changelog 
petsc-3.19.6+dfsg1/debian/changelog
--- petsc-3.19.6+dfsg1/debian/changelog 2024-01-21 06:41:21.0 +
+++ petsc-3.19.6+dfsg1/debian/changelog 2024-03-03 21:40:10.0 +
@@ -1,3 +1,18 @@
+petsc (3.19.6+dfsg1-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix extraneous X-Time64-Compat declarations.
+  * Fix substitution of soname in maintainer scripts.  Closes: #1065217.
+
+ -- Steve Langasek   Sun, 03 Mar 2024 21:40:10 +
+
+petsc (3.19.6+dfsg1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.  Closes: #1064332
+
+ -- Benjamin Drung   Thu, 29 Feb 2024 20:22:10 +
+
 petsc (3.19.6+dfsg1-2) unstable; urgency=medium
 
   * Update debian/patches/soname_extension to also add a define PETSC_LIB_EXT,
diff -Nru petsc-3.19.6+dfsg1/debian/control petsc-3.19.6+dfsg1/debian/control
--- petsc-3.19.6+dfsg1/debian/control   2024-01-21 06:41:21.0 +
+++ petsc-3.19.6+dfsg1/debian/control   2024-03-03 21:34:32.0 +
@@ -4,7 +4,7 @@
 Maintainer: Debian Science Maintainers 

 Uploaders: "Adam C. Powell, IV" , Drew Parsons 

 Standards-Version: 4.6.2
-Build-Depends: debhelper-compat (= 13), python3, gfortran,
+Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13), python3, 
gfortran,
  pkg-config, dh-python,
  dh-fortran-mod,
  gdb,
@@ -86,7 +86,7 @@
 Multi-Arch: same
 Architecture: any
 Section: libdevel
-Depends: libpetsc-real3.19 (= ${binary:Version}),
+Depends: libpetsc-real3.19t64 (= ${binary:Version}),
  libpetsc3.19-dev-common (= ${source:Version}),
  ${MPI:Depends},
  libhypre-dev (>= 2.15.1),
@@ -99,7 +99,7 @@
 Conflicts: libpetsc3.6.3-dev (<< 3.6.3.dfsg2-2), libpetsc-complex-3.6.3-dev 
(<< 3.6.3.dfsg2-2),
  libpetsc3.6.2-dev (<= 3.6.2.dfsg1-3), libpetsc-complex-3.6.2-dev (<= 
3.6.2.dfsg1-3)
 Recommends: libpetsc3.19-dev-examples, ksh | mksh | pdksh | zsh
-Suggests: petsc-dev, libpetsc-real3.19-dbg (= ${binary:Version}), 
petsc3.19-doc, libluminate-dev
+Suggests: petsc-dev, libpetsc-real3.19t64-dbg (= ${binary:Version}), 
petsc3.19-doc, libluminate-dev
 Description: Static libraries, shared links, header files for PETSc
  PETSc is the "Portable Extensible Toolkit for Scientific
  Computation", a suite of data structures and routines for the
@@ -112,16 +112,16 @@
  This package provides the development files for building applications
  using PETSc 3.19 with real numbers.
 
-Package: libpetsc-real3.19
+Package: libpetsc-real3.19t64
 Architecture: any
 Multi-Arch: same
 Section: libs
-Provides: libpetsc3.19
+Provides: ${t64:Provides}, libpetsc3.19
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Conflicts: libpetsc3.6 (<< 3.6.2.dfsg1-4)
-Breaks: libpetsc-real3.10, libslepc-real3.10, libpetsc3.10-dev-common, 
libpetsc3.10-dev-examples
-Replaces: libpetsc3.6 (<< 3.6.2.dfsg1-4)
+Breaks: libpetsc-real3.19 (<< ${source:Version}), libpetsc-real3.10, 
libslepc-real3.10, libpetsc3.10-dev-common, libpetsc3.10-dev-examples
+Replaces: libpetsc-real3.19, libpetsc3.6 (<< 3.6.2.dfsg1-4)
 Description: Shared libraries for version 3.19 of PETSc
  PETSc is the "Portable Extensible Toolkit for Scientific
  Computation", a suite of data structures and routines for the
@@ -133,7 +133,7 @@
  .
  This package contains the PETSc 3.19 shared library for real numbers.
  .
- It provides soname libpetsc-real3.19
+ It provides soname libpetsc-real3.19t64
 
 Package: libpetsc3.19-dev-common
 Architecture: all
@@ -173,7 +173,7 @@
 Depends: ${misc:Depends}, ${python3:Depends},
  libjs-mathjax
 Recommends: ksh | mksh | pdksh | zsh,
- libpetsc-real3.19-dev | libpetsc-complex3.19-dev | libpetsc-real3.19-dbg | 
libpetsc-complex3.19-dbg
+ libpetsc-real3.19-dev | libpetsc-complex3.19-dev | 

Bug#1065406: steam-installer: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: steam-installer
Version: 1_1.0.0.79~ds-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for steam-installer's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


steam-installer_1_1.0.0.79~ds-2_pt.po.gz
Description: application/gzip

Bug#1065405: rocm_agent_enumerator: invalid escape sequence

[Cordell Bloor]

Package: rocminfo
Version: 5.7.1-1
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz

Dear Maintainer,

There are warnings emitted on stderr when running rocm_agent_enumerator:

# rocm_agent_enumerator
/usr/bin/rocm_agent_enumerator:152: SyntaxWarning: invalid escape sequence '\A'
  line_search_term = re.compile("\A\s+Name:\s+(amdgcn-amd-amdhsa--gfx\d+)")
/usr/bin/rocm_agent_enumerator:154: SyntaxWarning: invalid escape sequence '\A'
  line_search_term = re.compile("\A\s+Name:\s+(gfx\d+)")
/usr/bin/rocm_agent_enumerator:175: SyntaxWarning: invalid escape sequence '\w'
  target_search_term = re.compile("1002:\w+")
gfx000
gfx906

These regular expressions should use raw strings.

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

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

Versions of packages rocminfo depends on:
ii  kmod31+20240202-2
ii  libc6   2.38-6
ii  libgcc-s1   14-20240221-2.1
ii  libhsa-runtime64-1  5.7.1-1
ii  libstdc++6  14-20240221-2.1
ii  pciutils1:3.10.0-2+b1
ii  python3 3.12.1-1

rocminfo recommends no packages.

rocminfo suggests no packages.

-- no debconf information

Bug#1065404: virt-manager: Cannot load AooArmor profile

[Erik de Castro Lopo]

Package: virt-manager
Version: 1:4.1.0-3
Severity: normal

Dear Maintainer,

I moved the `/var/lib/libvirt/images` directory to a new disk at 
`/libvirt/images`
and created a symlink from the former to the later.

The 3 VM disk images were working at the old location but at the new location
I get an error:

libvirt.libvirtError: internal error: cannot load AppArmor profile 
'libvirt-'

Running virt-manager as recommended:

  > virt-manager  --debug  --no-fork
  [Mon, 04 Mar 2024 10:21:10 virt-manager 32] DEBUG (cli:204) Version 4.1.0 
launched with command line: /usr/bin/virt-manager --debug --no-fork
  [Mon, 04 Mar 2024 10:21:10 virt-manager 32] DEBUG (virtmanager:167) 
virt-manager version: 4.1.0
  [Mon, 04 Mar 2024 10:21:10 virt-manager 32] DEBUG (virtmanager:168) 
virtManager import: /usr/share/virt-manager/virtManager
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (virtmanager:205) 
PyGObject version: 3.47.0
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (virtmanager:209) GTK 
version: 3.24.41
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (systray:84) Imported 
AppIndicator3=
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (systray:86) 
AppIndicator3 is available, but didn't find any dbus watcher.
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (systray:476) Showing 
systray: False
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (inspection:206) python 
guestfs is not installed
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (engine:113) Loading 
stored URIs:
  qemu:///system
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (engine:461) processing 
cli command uri= show_window=manager domain=
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (engine:464) No cli 
action requested, launching default window
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (manager:185) Showing 
manager
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (engine:316) window 
counter incremented to 1
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (engine:211) Initial 
gtkapplication activated
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (connection:482) 
conn=qemu:///system changed to state=Connecting
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (connection:903) 
Scheduling background open thread for qemu:///system
  [Mon, 04 Mar 2024 10:21:15 virt-manager 32] DEBUG (connection:128) 
libvirt URI versions library=10.0.0 driver=10.0.0 hypervisor=8.2.1
  [Mon, 04 Mar 2024 10:21:15 virt-manager 32] DEBUG (connection:109) 
Fetched capabilities for qemu:///system: 
  

  03d502e0-045e-0541-c606-a40700080009
  
x86_64
Skylake-Client
Intel
































  
  



  
  
  


  tcp
  rdma

  
  

  
49290208
12322552
0
0

  


  
  
  
  
  
  
  
  
  
  
  
  

  

  
  

  
  
apparmor
0
  
  
dac
0
+64055:+64055
+64055:+64055
  

  

  hvm
  
32
/usr/bin/qemu-system-i386
pc-i440fx-8.2
pc
pc-q35-5.2
pc-i440fx-2.12
pc-i440fx-2.0
pc-i440fx-6.2
pc-q35-4.2
pc-i440fx-2.5
pc-i440fx-4.2
pc-i440fx-5.2
pc-q35-2.7
pc-q35-7.1
pc-i440fx-2.2
pc-q35-8.1
pc-i440fx-8.1
pc-i440fx-2.7
pc-q35-6.1
pc-q35-2.4
pc-i440fx-7.1
pc-q35-2.10
x-remote
pc-q35-5.1
pc-q35-2.9
pc-i440fx-2.11
pc-q35-3.1
pc-i440fx-6.1
pc-q35-4.1
pc-i440fx-2.4
pc-i440fx-4.1
pc-i440fx-5.1
pc-i440fx-2.9
isapc
pc-q35-2.6
pc-i440fx-3.1
pc-q35-2.12
pc-q35-7.0
pc-i440fx-2.1
pc-q35-8.0
pc-i440fx-8.0
pc-q35-6.0
pc-i440fx-2.6
pc-q35-4.0.1
pc-i440fx-7.0
pc-q35-5.0
pc-q35-2.8
pc-i440fx-2.10
pc-q35-3.0
pc-q35-7.2
pc-q35-4.0
pc-i440fx-6.0
microvm
pc-i440fx-2.3
pc-i440fx-4.0
pc-q35-8.2
q35
pc-i440fx-5.0
pc-i440fx-2.8
pc-q35-6.2
pc-q35-2.5
pc-i440fx-3.0
pc-i440fx-7.2
pc-q35-2.11
 

Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

[Matthew Garrett]

I agree with the conclusions drawn here, but feel that it's possibly 
worth making a stronger general statement that policy should never 
prevent the implementation of a well-considered simple solution. I would 
like some further analysis of Sam's proposal, though - I don't think 
there's any advantage in undoing the existing solution, but if it would 
work then it's maybe a more straightforward solution for any similar 
issues in future?

Bug#1065099: [Pkg-utopia-maintainers] Bug#1065099: network-manager: Upgrading to ver 1.46.0-1 from 1.44.2-7 removes system tray functionality

[Neal Heinecke]

Thanks for the insight. Yes the issue is reproduced when I run:
sudo systemctl restart NetworkManager.service

The issue is resolved when I logout and back in.

On Sun, Mar 3, 2024 at 7:26 AM Michael Biebl  wrote:

> Am 29.02.24 um 20:39 schrieb Neal:
> > Package: network-manager
> > Version: 1.44.2-7
> > Severity: important
> > X-Debbugs-Cc: nealheine...@gmail.com
> >
> > Dear Maintainer,
> >
> > Reporting again, but with the requested info.
> >
> > When I upgrade network manager, the wireless system tray icon is
> replaced by
> > the icon that indicates no internet connection. Clicking on the icon
> shows no
> > available connections. Wireless connectivity is still active though, the
> system
> > tray functionality is just borked.
> >
> > System Info:
> > Operating System: Debian GNU/Linux Trixie
> > KDE Plasma Version: 5.27.10
> > KDE Frameworks Version: 5.107.0
> > Qt Version: 5.15.10
> > Kernel Version: 6.6.15-amd64 (64-bit)
> > Graphics Platform: Wayland
> > Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz
> > Memory: 15.4 GiB of RAM
> > Graphics Processor: Mesa Intel® UHD Graphics 620
> > Manufacturer: Dell Inc.
> > Product Name: Inspiron 7573
>
> Your bug is probably
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053707
>
> As part of the upgrade process, the NetworkManager.service is restarted.
> My guess is, that plasma-nm does not properly reconnect when
> NetworkManager.service is restarted and you need to logout/login.
>
> You can try to reproduce the issue by running
> sudo systemctl restart NetworkManager.service
>
>

Bug#1064998: guile-lib: broken package when cross building

[David Pirotte]

Hello debian maintainers,
Vagrant,

> Forwarding this upstream, originally submitted in the Debian bug
> tracking system at:

>   https://bugs.debian.org/1064998
> ...

> Would the guile-lib developers consider merging this? Are there any
> use-cases where this is inappropriate?

Certainly! Thanks for the report, it somehow did skip my attention
when i worked on this (a long long time ago ...), that calling
GUILE_SITE_DIR also defines GUILE_SITE_CCACHE

I'll fix this for the next release.

> Thanks!

I am the one who thanks (all of you)
David


pgpIY56GkC7Pr.pgp
Description: OpenPGP digital signature

Bug#1046041: ivtools: Fails to build source after successful build

[Agustin Martin]

El dom, 13 ago 2023 a las 22:16, Lucas Nussbaum () escribió:
>
> Source: ivtools
> Version: 2.0.11d.a1-1
> Severity: minor
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-sab-20230813 ftbfs-source-after-build
> User: debian...@lists.debian.org
> Usertags: qa-doublebuild

> > dpkg-source: error: cannot represent change to refman.pdf: binary file 
> > contents changed
> > dpkg-source: error: add refman.pdf in debian/source/include-binaries if you 
> > want to store the modified binary in the debian tarball
> > dpkg-source: error: unrepresentable changes to source
> > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 1

Hi,

I have been playing with a patch (attached) to handle this from
debian/rules. Besides refman.pdf there were some other things to
remove on clean target.

Regards,
diff --git a/debian/rules b/debian/rules
index 71543bf..9ab42e5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,11 @@ override_dh_auto_configure:
 		--with-PSFontDir=/usr/share/fonts/type1/gsfonts	\
 		--with-clippoly=no
 
+override_dh_clean:
+	rm -f refman.pdf
+	rm -f *.la pnmtopgm Idemo InterViews comterp_run
+	dh_clean
+
 execute_after_dh_install:
 	@echo prevent library files in libiv2 from being duplicated in libiv-unidraw2
 	find debian/libiv2t64/usr/lib -type f -o -type l		\

Bug#1062611: libiv-unidraw2t64 has an undeclared file conflict

[Agustin Martin]

El vie, 2 feb 2024 a las 6:57, Helmut Grohne () escribió:
>
> Package: libiv-unidraw2t64
> Version: 2.0.11d.a1-1.1~exp1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: fileconflict
> Control: affects -1 + libiv2 libiv2t64
> X-Debbugs-Cc: Graham Inggs , vor...@debian.org
>
> libiv-unidraw2t64 has an undeclared file conflict. This may result in an
> unpack error from dpkg.
>
> The files
>  * /usr/lib/x86_64-linux-gnu/libIV.so.2
>  * /usr/lib/x86_64-linux-gnu/libIV.so.2.0.0
> are contained in the packages
>  * libiv-unidraw2t64/2.0.11d.a1-1.1~exp1 as present in experimental
>  * libiv2
>* 2.0.11d.a1-1+b4 as present in bookworm
>* 2.0.11d.a1-1+b5 as present in trixie|unstable
>* 2.0.4a1-2 as present in bullseye
>  * libiv2t64/2.0.11d.a1-1.1~exp1 as present in experimental

Hi, Helmut.

I wonder if this is still an issue. Some uploads happened in the
meantime and seems that  those files are currently shipped by a
different package

$ dpkg -S libIV.so.2
libiv2t64:amd64: /usr/lib/x86_64-linux-gnu/libIV.so.2.0.0
libiv2t64:amd64: /usr/lib/x86_64-linux-gnu/libIV.so.2

which apparently handles things well

Package: libiv2t64
Replaces: libiv2
Provides: libiv2 (= 2.0.11d.a1-1.1)
Breaks: libiv2 (<< 2.0.11d.a1-1.1)

Bug#1065403: RFP: gtklock-powerbar-module -- gtklock module adding power controls to the lockscreen

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: maytha8the...@gmail.com, werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: gtklock-powerbar-module
  Version : 2.0.1
  Upstream Contact: Jovan Lanik
* URL : https://github.com/jovanlanik/gtklock-powerbar-module 
* License : GPL-3.0+
  Programming Lang: C
  Description : gtklock module adding power controls to the lockscreen

This module adds power controls to the lockscreen allowing to
reboot/shutdown/suspend the machine from the lockscreen.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmXk9+EVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1/JsP/0GEqyW94sAh/jX29TgBCBwG8m+Q
usOHmuU/w0+ma37PhB7qk73EDwbdySvmQTTrB9j8gFMaaMZkjkXlCHlk/i37xQ+L
QjDDwc72/vP3c+cae1wXV1QM8MVs7L1S3NkXLTlawWBaxUdTMY8nahECZ1BDV++b
aXPXLZCTohzxiN7dDz57iPWrffobOjh1DXjc2NzjBqxJfehqVfwRoegwm6dGuAVT
rW1oxj/iDbyd4iQLnXOPF4qOqYVN0mve2u7SDwa0jY9cpJ7p7h4cDPc7ab0dv1N4
l9f3a6TEWpP3rVyMB+O48iac+NHYb4kARNhBk1Jb4uzJYTW+qG00HMcfKD3pzYYj
Y3+dISB6YeIil9ZNBKC9V09cEZQVJdYz6L0Swpru+lu8Vgo6nl9iUCyDe7bjLv95
BoucCCSaB6ZuTqaxwjKt52HBmhRFyIcY7ho3+prW1wz7fj6XNSJw3R5XD6bfMtF0
VD3l64l6LxMf9sO0O7WgpzqHrR4ITY76wCNH/ITtpcQmheOfU1GMXH7GsEbIETHl
gm3Ku9wugMKE+41qD/tgoVqJallK9EdPKfsrixbJj/EmCoYFmT8wjnNAZOVjxXrS
UDzVAqA4FdnXwO8PH2WuNQ3/TAx9294ycannQ+0wVe3Q6s7aoGghNDHwTV6CHBih
o1SYpSZBzML9pc+K
=UD5x
-END PGP SIGNATURE-

Bug#1065402: RFP: fonts-weather-icons -- font with 222 weather themed icons

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-fo...@lists.debian.org, werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: fonts-weather-icons
  Version : 2.0.10
  Upstream Contact: Erik Flowers
* URL : https://github.com/erikflowers/weather-icons
* License : SIL-OFL, MIT, CC-BY-SA 3.0
  Programming Lang: CSS
  Description : font with 222 weather themed icons

weather-icons is an icon font containing weather icons.
It used as part of NerdFonts.
Filing as RFP since I do not have the time at the moment to maintain it.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmXk9V0VHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1WaIP/18hOr5/Q/aB/YFfiIjCkIG2Z4lj
wzXzjRiH96n6CUMPPhp9z3BW9lZIm3P8OOV/Ejjckekok70L8vJgFP2XbPm+/YxS
+9zYThcrcDeGt1D9lDn0F0CZNJimCj5x68Hb82PBWfAV45JsUWlBPjU0+WMFchAm
cK4iunR93u71gKl/tWLdT1vV+Yg242ly0D2S2IMp2yI2MsA5cqhO74+a4WUSC0T0
lz1NvRUQTvF/IoCsFu76QY4Nrzb9BNTq2jIzYM1xjMqo8c31SJ/bJj6AL2VjB7Kh
gvhUuXJyKJl+5ALGY4k9dSe9eqbszptpAI0MlWJqr2u4/LsEDlm6HSACa4NegFSu
DYvKvbuyqSmgdzEUx/6z7G4hAip1LXxki7mB3b5eitBZMHSY22dtzac2Knk0c2Bs
c3QdlqY71My/HOMTOglTofUWabBoGisO9YNE26aNigrn1VREii+hexMDEDX5wobS
FVAD3csaA3TJQ+fUk8YK2AyI4V5a+MQiWQVVqzg59+66sLa8NIRNJbpG4+nZQofX
pcLxEUp7nxRBw9QDhTiJSaWX5WYmPo01HyQoUSGueTzKDAkx5vz0udR8Rlw+tyGR
3Br23iQFLxU2LerQwwJ8lgcu0aFBgIP6JTQOfvpidTSUj0zdLSIU4GmwdP5KC7TZ
9YpEcdjebqVbVzvB
=BA3G
-END PGP SIGNATURE-

Bug#1032366: bts --smtp-host=reportbug.d.o fails with "certificate verify failed"

[Gioele Barabucci]

Version: 2.23.7

This issue does not occur anymore with 2.23.7 and the current setup of 
reportbug.d.o.


Regards,

--
Gioele Barabucci

Bug#1062218: libaio: NMU diff for 64-bit time_t transition

[Guillem Jover]

Hi!

On Thu, 2024-02-29 at 02:35:16 +0100, Guillem Jover wrote:
> Control: tags -1 - pending

> On Wed, 2024-01-31 at 19:36:09 +, Steve Langasek wrote:
> > Source: libaio
> > Version: 0.3.113-5
> > Severity: serious
> > Tags: patch pending
> > Justification: library ABI skew on upgrade
> > User: debian-...@lists.debian.org
> > Usertags: time-t
> 
> > Please find the patch for this NMU attached.
> > 
> > If you have any concerns about this patch, please reach out ASAP.  Although
> > this package will be uploaded to experimental immediately, there will be a
> > period of several days before we begin uploads to unstable; so if 
> > information
> > becomes available that your package should not be included in the 
> > transition,
> > there is time for us to amend the planned uploads.
> 
> Unfortunately I just realized this patch is not enough. :/ This library
> emits direct syscalls, so these are going to be broken with the time_t
> size change, the syscalls need to be updated. I'm checking how to best
> fix this, perhaps even via dual-ABI, to avoid the transition
> altogether, but let's see.
> 
> I guess this might have been missed for other packages that that emit
> direct syscalls and are not using the time64 variants for those
> already.

Just as a status update, I've got most of this working, but upstream
does not tend to be very responsive, so I think I'll do a proper
SONAME bump with my proposed changes for the dual-ABI, to avoid any
potential clashes with anything that gets upstream, and to make a
revert easier, by reusing the t64 library names. And then once/if this
gets merged upstream I can revert that and simply do the proper
dual-ABI on the old SONAME and package names, as if nothing had
happened (except for the required rebuilds).

Hopefully I can have something for upload today or tomorrow, hoping
that this delay up to now, does not block too many things. :/

Thanks,
Guillem

Bug#1049943: wrap-and-sort: always place the build-system packages (e.g., debhelper-compat) first

[Gioele Barabucci]

Control: tags + patch

Dear devscripts maintainers,

please find a MR that implements this feature (placing build-system 
packages such as "debhelper-compat" first) at 
https://salsa.debian.org/debian/devscripts/-/merge_requests/392


Regards,

--
Gioele Barabucci

Bug#1065400: atril: Please drop suggestion of no longer used unrar

[Adrian Bunk]

Package: atril
Version: 1.26.1-4
Severity: normal

atril is now using libarchive instead:
https://bugs.debian.org/1060751
https://security-tracker.debian.org/tracker/CVE-2023-51698

Bug#1065399: evince: Please drop suggestion of no longer used unrar

[Adrian Bunk]

Package: evince
Version: 3.25.92-1
Severity: normal

evince is using libarchive instead since buster:
https://security-tracker.debian.org/tracker/CVE-2023-51698

Bug#1064376: 1064376-d...@bugs.debian.org

[Marcos Fouces]

Hello

i changed my mind on this subject. ganglia-web was updated to run on
PHP8 [1] so i will (try to) continue to use and maintain ganglia,
ganglia-modules-linux and ganglia-web packages.

Greetings, 

Marcos

[1] https://github.com/ganglia/ganglia-web/releases/tag/3.7.6

Bug#1065398: vim-runtime overwrites file from vim-tiny

[bixcntha]

Source: vim
Version: 2:9.1.0016-1
Severity: normal

Dear Maintainer,

both vim-runtime and vim-tiny packages unpack the
/usr/share/vim/vim91/doc/help.txt and /usr/share/vim/vim91/doc/tags files.

This means that for example performing the md5sum check using
/var/lib/dpkg/info/vim-runtime.md5sums and
/var/lib/dpkg/info/vim-tiny.md5sums will give error messages because the
contents of the help.txt and tags files differ between the two packages.

Would it not be better to have some sort of conflicts or replaces or
provides relationship between vim-runtime and vim-tiny, so that the
packages don't overwrite each other's files and don't cause checksum
errors?

Bug#1065331: libhdf5-103-1t64: depends on libcurl4 instead of libcurl4t64

[Vincent Lefevre]

On 2024-03-03 01:08:10 +0100, Vincent Lefevre wrote:
> Package: libhdf5-103-1t64
> Version: 1.10.10+repack-3.1
> Severity: serious
> 
> libhdf5-103-1t64 depends on libcurl4 instead of libcurl4t64.
> This makes the upgrade of curl impossible.

It seems that this was actually a bug in curl, where libcurl4t64
had an incorrect X-Time64-Compat and which has just been fixed in

https://salsa.debian.org/debian/curl/-/commit/40bdd3894230d325d382d59684c32d74202eee5c

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1062407: liblopsub: NMU diff for 64-bit time_t transition

[Andre Noll]

On Sun, Mar 03, 11:47, Steve Langasek wrote

> > Below it what I've just applied. The patch looks different to what
> > you've sent, but the resulting tree is identical. Please let me know
> > if you're OK with the commit message.
> 
> No objections.

Merged and pushed out to the public repo.

Thanks
Andre
-- 
Max Planck Institute for Biology
Tel: (+49) 7071 601 829
Max-Planck-Ring 5, 72076 Tübingen, Germany
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

Bug#1065397: RFS: libunistring/1.2-1 -- Unicode string library for C

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : libunistring
   Version  : 1.2-1
   Upstream contact : Bruno Haible 
 * URL  : https://www.gnu.org/software/libunistring/
 * License  : GPL-2+ with distribution exception, Expat and GPL-2+, 
  LGPL-3+ or GPL-2+, FreeSoftware, GPL-3+, GPL-3+ or 
  GFDL-NIV-1.2+, X11, GPL-2+ with distribution exception, 
  GPL-2+
 * Vcs  : https://git.jff.email/cgit/libunistring.git
   Section  : libs

The source builds the following binary packages:

  libunistring-dev - Unicode string library for C - development files
  libunistring5 - Unicode string library for C

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/libu/libunistring/libunistring_1.2-1.dsc

or from 

 git https://git.jff.email/cgit/libunistring.git/?h=release%2Fdebian%2F1.2-1


Changes since the last upload:

 libunistring (1.2-1) unstable; urgency=medium
 .
   * New upstrem release.
 - Refresh / Rebuild symbols file.
   * debian/copyright:
 - Add 2024 to myself.
 - Refresh uploader copyright years.
   * Remove unused patches:
 - debian/patches/0100-float-endian-detection.patch.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://git.jff.email/cgit/

Skype:jff-skype@jff.email
Jami: joergfringsfuerst
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.






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

Bug#1060270: cryptsetup /usr-move DEP17

[Helmut Grohne]

Hi Guilhem,

On Tue, Feb 27, 2024 at 02:00:05PM +0100, Guilhem Moulin wrote:
> The first message of this bug reads:
> 
> |  * Please upload these changes to experimental first. That allows
> |running them past QA systems such as piuparts, dumat and others and
> |also lets us double check the version constraints.
> 
> There is also a coming freeze for Ubuntu 24.04 and I hear they'd like to
> have 2.7.0.  My bad for delaying this, but right now I want 2.7.0 to
> transition to testing first and not risk blocking on cryptsetup-nuke-password
> or potential regressions.  I intend to upload to sid after the
> transition.

Thank you! The reason you give makes sense to me. Indeed, we should have
both cryptsetup and cryptsetup-ask-password in experimental (with
verified version constraints) before proceeeding to unstable. You are
correct that cryptsetup-nuke-password did not make it to experimental
and hence you were not good to proceed to unstable. I call that
attention to detail. :)

Please reupload the patch to experimental (with a version higher than
unstable) assuming that cryptsetup-nuke-password will use version 5 as I
am in contact with Raphael Hertzog.

Your concern with the Ubuntu freeze also is valid, but it actually is
the other way round. Ubuntu already has made the changes in base-files
at al that this bug is blocking in Debian. Ubuntu needs this change even
more urgently than Debian does.

I hope cryptsetup makes it to testing soon (it'll migrate with lvm2)
such that we can move forward here.

Helmut

Bug#1057386: ITP: imsprog -- linux chip programmer for CH341a devices

[Carsten Schoenert]

Hello Mikhail,

Am 03.03.24 um 20:35 schrieb Kosolapov Ivan:

Hello, Carsten!
Regarding W: imsprog: appstream-metadata-missing-modalias:
I was already informed yesterday by Alt-Linux colleagues about the 
erroneous comment format in file 99-CH341.rules.
I have already fixed it in 
https://github.com/bigbigmdm/IMSProg/commit/8be1584358b6c7a4cb0224bc813e3e284d62cb42

Is there an urgent need for a new release because of this fix?


I think no, but I can upload a newer version to NEW every time.
It might be that a FTP-Admin is "complaining" about that warning, but a 
reject of the package should not happen.


My guess is that a review of the package will take a bit of time, I'd be 
surprised if it will get processed within of days.
So proceed with your usual development process and ping me once you 
released a new version which has fix included. I'll prepare a new upload 
then.


--
Regards
Carsten

Bug#453891: unrar-free doesn't have an option to extract a file to stdout

[Bastian Germann]

On Sat, 01 Dec 2007 21:00:03 -0500 Stefan Monnier  
wrote:

As the subject says, there's no easy way to extract one of the files in a
rar archive to stdout (or to a specific file).


Please import version 0.2.0 which fixes this.

Bug#1065396: ghostscript: Coordinate uploads for German man page transfer

[Helge Kreutzmann]

Package: ghostscript
Version: 10.0.0~dfsg-11+deb12u3
Severity: normal

Hello Steve,
ghostscript used to contain German man pages, however, they were not
properly maintained. As detailed in [1] ghostscript removed the 
German man pages from its git repository on January 4th 2023.

So the files are gone since Version 10.01.0rc1.

I imported them into manpages-de and will start shipping them with the
next release.

As per transition rules [2] you will need to add 
Breaks: manpages-l10n (<4.22) 
in your debian/control.

I will then add
Breaks: ghostscript (

Bug#1065395: spirv-llvm-translator-14: autopkgtest on s390x uses huge amount of disk space

[Paul Gevers]

Source: spirv-llvm-translator-14
Version: 14.0.0-10
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: issue

Dear maintainers,

Since a couple of days, our workers on s390x are dying because some test
is filling up all disk space. Several days ago, I wrongly suspected 
src:fenics-dolfinx (bug #1064995) and added it to our reject-list. It 
didn't solve the issue, so today I spend more time on finding the 
culprit. Basically every spike above 40% in the graph [1] is a moment 
that we see issues like:


Feb 28 05:38:18 ci-worker-s390x-01 debci[1738391]: gzip:
/tmp/debci-worker-43383540-cNnbLE372K/autopkgtest-incoming/testing/s390x/f/fenics-dolfinx/43383540/log.gz: 


No space left on device
Feb 28 05:38:18 ci-worker-s390x-01 debci[1424101]: E: Test for package
fenics-dolfinx produced no exit code, aborting

One of the suspects started to be spirv-llvm-translator-14, so I ran its 
autopkgtest manually, while logging disk use every 10 seconds (I started 
slightly delayed because I monitored the wrong partition first). As you 
can see below, during the test it grows from 17 GB (at the end) to its 
peak at 179 GB. That's not acceptable on our infrastructure. One file I 
happened to spot on the way was 
build/test/test_output/DebugInfo/Generic/Output/two-cus-from-same-file.ll.tmp:

-rw-r--r-- 1 root root  41G Mar  3 19:18 two-cus-from-same-file.ll.tmp

I have added spirv-llvm-translator-14 to our reject-list on s390x.

As this seems to be a rather new issue, I'm wondering if it's due to:
* Add build-needed autopkgtest for spirv-headers compat check.

Or maybe something in the toolchain that broke on s390x?

Paul

[1]
https://ci.debian.net/munin/ci-worker-s390x-01/ci-worker-s390x-01/df.html

/dev/mapper/3600507630affd250004a  196G   40G  146G  22% 
/scratch
/dev/mapper/3600507630affd250004a  196G   49G  138G  27% 
/scratch
/dev/mapper/3600507630affd250004a  196G   57G  130G  31% 
/scratch
/dev/mapper/3600507630affd250004a  196G   65G  122G  35% 
/scratch
/dev/mapper/3600507630affd250004a  196G   66G  121G  36% 
/scratch
/dev/mapper/3600507630affd250004a  196G   67G  120G  36% 
/scratch
/dev/mapper/3600507630affd250004a  196G   70G  117G  38% 
/scratch
/dev/mapper/3600507630affd250004a  196G   73G  114G  40% 
/scratch
/dev/mapper/3600507630affd250004a  196G   76G  111G  41% 
/scratch
/dev/mapper/3600507630affd250004a  196G   79G  108G  43% 
/scratch
/dev/mapper/3600507630affd250004a  196G   83G  104G  45% 
/scratch
/dev/mapper/3600507630affd250004a  196G   85G  101G  46% 
/scratch
/dev/mapper/3600507630affd250004a  196G   88G   98G  48% 
/scratch
/dev/mapper/3600507630affd250004a  196G   92G   95G  50% 
/scratch
/dev/mapper/3600507630affd250004a  196G   95G   92G  51% 
/scratch
/dev/mapper/3600507630affd250004a  196G   98G   89G  53% 
/scratch
/dev/mapper/3600507630affd250004a  196G  101G   86G  54% 
/scratch
/dev/mapper/3600507630affd250004a  196G  104G   83G  56% 
/scratch
/dev/mapper/3600507630affd250004a  196G  107G   80G  58% 
/scratch
/dev/mapper/3600507630affd250004a  196G   65G  122G  35% 
/scratch
/dev/mapper/3600507630affd250004a  196G   65G  122G  35% 
/scratch
/dev/mapper/3600507630affd250004a  196G   66G  121G  36% 
/scratch
/dev/mapper/3600507630affd250004a  196G   68G  118G  37% 
/scratch
/dev/mapper/3600507630affd250004a  196G   72G  115G  39% 
/scratch
/dev/mapper/3600507630affd250004a  196G   75G  112G  41% 
/scratch
/dev/mapper/3600507630affd250004a  196G   78G  109G  42% 
/scratch
/dev/mapper/3600507630affd250004a  196G   81G  106G  44% 
/scratch
/dev/mapper/3600507630affd250004a  196G   85G  102G  46% 
/scratch
/dev/mapper/3600507630affd250004a  196G   87G   99G  47% 
/scratch
/dev/mapper/3600507630affd250004a  196G   90G   96G  49% 
/scratch
/dev/mapper/3600507630affd250004a  196G   94G   93G  51% 
/scratch
/dev/mapper/3600507630affd250004a  196G   97G   90G  52% 
/scratch
/dev/mapper/3600507630affd250004a  196G  100G   87G  54% 
/scratch
/dev/mapper/3600507630affd250004a  196G  103G   84G  56% 
/scratch
/dev/mapper/3600507630affd250004a  196G  106G   81G  57% 
/scratch
/dev/mapper/3600507630affd250004a  196G  109G   78G  59% 
/scratch
/dev/mapper/3600507630affd250004a  196G  112G   74G  61% 
/scratch
/dev/mapper/3600507630affd250004a  196G  116G   71G  63% 
/scratch
/dev/mapper/3600507630affd250004a  196G  119G   68G  64% 
/scratch
/dev/mapper/3600507630affd250004a  196G  123G   64G  66% 
/scratch
/dev/mapper/3600507630affd250004a  196G  126G   61G  68% 

Bug#1062407: liblopsub: NMU diff for 64-bit time_t transition

[Steve Langasek]

On Sun, Mar 03, 2024 at 05:08:19PM +0100, Andre Noll wrote:
> On Fri, Mar 01, 05:37, Steve Langasek wrote:

> > Please find attached a final version of this patch for the time_t
> > transition.  This patch is being uploaded to unstable.

> > Note that this adds a versioned build-dependency on dpkg-dev, to guard
> > against accidental backports with a wrong ABI.

> Applied. Since the previous version was applied and made public
> last month, I've reverted that patch, applied this final version and
> squashed the two new commits into one.

> Below it what I've just applied. The patch looks different to what
> you've sent, but the resulting tree is identical. Please let me know
> if you're OK with the commit message.

No objections.

Cheers,
-- 
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#1060246: perl: proposed patch for perl ABI change due to 64-bit time_t

[Steve Langasek]

On Sun, Mar 03, 2024 at 12:46:40PM +0200, Niko Tyni wrote:
> > Well, this hasn't happened but now I think it's urgent that it happens.  As
> > I mentioned on IRC, we're entangled with gdbm and db5.3 time_t transitions,
> > and we can't safely rebuild perl on armhf *without* bumping the ABI
> > declarations.

> > I can NMU this today if you want or I can leave it to you, please let me
> > know.

> As I already told Julian a few days ago on this bug, any necessary NMUs
> are welcome. Given the urgency we've ended up with, I'd prefer you do
> the upload and take responsibility for any bugs possibly introduced.

Ok.  I haven't NMUed yet because I'm still finishing a bootstrap build on
armel to go with the upload. (Bootstrap on armhf is already done.)  As soon
as it is done today, I'll be uploading.

-- 
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#1060838: meson: should use the host gobject-introspection-1.0.pc for looking up g-ir-scanner

[Jussi Pakkanen]

On Mon, 26 Feb 2024 at 17:58, Simon McVittie  wrote:

> I did consider that, but if I'm understanding what you propose
> correctly, that would involve going through these steps for every
> possible cross-tool:
>
> * inventing a new environment variable similar to CC and PKG_CONFIG, for
>   example perhaps G_IR_SCANNER in this case
> * making debhelper (or dpkg) add it to the environment
> * making `meson env2mfile` (or the older debcrossgen) read it from the
>   environment and add it to the generated cross-file

That is not how it would work at all. Meson's env2mfile has a command
line option that tells it to generate things for Debian package
building. The idea is that then you can add any custom detection logic
you could possibly want. In this way custom logic can be added in the
main project in an actual programming language rather than trying to
replicate the same via envvars and magic hacks.

Bug#1065394: libuuid1t64: file overlap with libuuid1 causes dependency conflicts

[MichaIng]

Package: libuuid1t64
Version: 2.39.3-6.1

I am currently unable to generate riscv64 images via debootstrap:
---
I: Extracting libuuid1...
I: Extracting libuuid1t64...
E: Tried to extract package, but file already exists. Exit...
---

Both packages obviously provide the same files. "apt upgrade" on an 
existing riscv64 system does not have the issue, likely since libuuid1 
"Provides" libuuid1t64, and APT resolves this. debootstrap however seems 
to not resolve this.


Checking which actual package pulls them: 
https://packages.debian.org/sid/e2fsprogs
e2fsprogs depends, for most architectures, explicitly on both: libuuid1 
and libuuid1t64. While libuuid1 alone could satisfy both dependencies, 
of course this double-dependency of naturally conflicting packages does 
not make sense and is an issue in e2fsprogs. But on the other hand, 
maybe there is some information missing/misunderstanding about how to 
deal with this *t64 packages, which have been introduced all over the 
place in Debian Sid/unstable.


So I am not sure where to fix this best, but since it is all around the 
introduction of libuuid1t64, I report it here.


Adding either "Breaks"/"Conflicts" between the 2 packages would makes 
things pretty clear for everyone else, to only either add dependency for 
one or the other, but not both. But not sure whether this works well 
with "Provides". A "Provides" in the other direction, that libuuid1t64 
provides "libuuid1" might help as well. Or "Replaces" for libuuid1t64 on 
libuuid1 so that those can be installed concurrently, but I think this 
does not make sense as they really provide only different variants of 
the same library.


Let me know whether I should better re-assign the issue to e2fsprogs 
and/or debootstrap.


Best regards,

Micha

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Scott Kitterman]

Generally in the FTP Team we trust maintainer's judgement when it comes to 
deciding if a package should be removed rather than orphaned and left to rot.

I looked and it's been about 5 years since anyone other than Chris has uploaded 
the package and he's the only human maintainer.

It is both a feature and a bug that in Debian, we're all volunteers and can 
choose how we volunteer.

I don't see anyone volunteering to step up and take over, so in the end, the 
maintainer's judgement is what has to control.

Scott K

Bug#1064898: /usr/bin/sshd: mktemp - literal X-s in /tmp directory names

[Colin Watson]

On Tue, Feb 27, 2024 at 12:56:47PM +0100, Csillag Tamas wrote:
>* What led up to the situation?
>  After upgrading to debian 12 I am seeing directories in /tmp like:
>  ssh-XXnOKqkt, ssh-XXtGmfLV
>* What was the outcome of this action?
>* What outcome did you expect instead?
>  These directories are created by sshd.
>  In oldstable and OpenBSD the directories are as expected:
>  ssh-LwxtSMoGSV, ssh-JPcQMaBN6s
> 
>  The regression might be only in openssh-portable?
> 
> As there are still 6 variable characters this might not be easily exploitable
> security-wise and it used to be 10 just as in OpenBSD current.

This is the same as https://bugs.debian.org/1001186; it's fixed for the
next development release, but not yet for bookworm.

Since this doesn't appear to be immediately serious, my inclination is
to queue this up to fix along with the next bookworm openssh security
update (whenever that might be), but not to trouble the security team
with it right away.  Does that sound reasonable?

Thanks,

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

Bug#1057386: Subject: ITP: imsprog -- linux chip programmer for CH341a devices

[Carsten Schoenert]

Hello Mikhail,

Am Mon, Dec 04, 2023 at 01:48:14PM +0300 schrieb Mikhail Medvedev:
> Package: wnpp
> Severity: wishlist
> Owner: Mikhail Medvedev 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name    : imsprog
>   Version : 1.1.2-12
>   Upstream Author : Mikhail Medvedev 
> * URL : https://github.com/bigbigmdm/IMSProg
> * License : GPL-3
>   Programming Lang: C, C++, Bash
>   Description : GUI Chip programmer for CH341a devices
> 
> 
> IMSProg  -  QT-based  GUI  application  -  I2C,  MicroWire and SPI EEP‐
> ROM/Flash chip programmer for CH341a devices. The IMSProm is a free I2C
> EEPROM  programmer tool for CH341A device based on QhexEdit2 and modify
> SNANDer programmer.
> 
>  IMSProg consists of three executable modules:
> 
>  1. IMSProg - the chip programmer itself.
> 
>  2. IMSProg_editor - chip database editor.
> 
>  3. IMSProg_database_update - online chip database update from  the ex‐
> ternal web-server.

the content and the build of the package is fine, also no real blockers
through Lintian vissible.

Except this warning:

W: imsprog: appstream-metadata-missing-modalias-provide 
usr/lib/udev/rules.d/99-CH341.rules

I'm not thiat deep in the internals of imsprog and maybe this is a false
positive, if not have a loo at these resources to hopefully get this
warning fixed:

>From https://freedesktop.org/software/appstream/docs/chap-Metadata.html

...


A modalias glob representing the hardware types (for example USB,
PCI, ACPI, DMI) this component handles. Useful for installing
printer drivers or other USB protocol drivers for smartphones,
firmware, and out of tree kernel drivers.
...

In the Debian Wiki
https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware

The Lintian warning should get addressed in a further new release.

For now to me it's o.k. to upload the current version 1.3.2-1

Regrads
Carsten

Bug#1064852: incus: missing depends on iproute2

[Colin Watson]

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?

Would you mind reassessing your view in light of Policy 3.5
(https://www.debian.org/doc/debian-policy/ch-binary.html#dependencies)?
I think it's quite straightforward and unambiguous.

Section 2.5 has traditionally not been what controls decisions about
when dependencies ought to be specified, and this particular case is one
that I'm surprised to find being controversial.  The fine distinction
between "Priority: required" and "Essential: yes" has sometimes confused
people in the past and has needed some discussion, but it's always been
my experience that if one package needs another "Priority: important"
package for proper functioning then it's been quite uncontroversial that
the first package must declare a dependency.

Thanks,

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

Bug#1065393: libphonenumber: phonenumberprotoabi not computed correctly after time64 transition

[Simon McVittie]

Source: libphonenumber
Version: 8.12.57+ds-4.1
Severity: important
X-Debbugs-Cc: vor...@debian.org

After the time64 transition, libphonenumber8t64 Provides
libphonenumber8t64-protobuf with no version suffix. This appears to be
caused by the rename of libprotobuf32 to libprotobuf32t64: the regex in

> phonenumberprotoabi := libphonenumber8t64-protobuf$(shell dpkg-query -W -f 
> '$${Depends}' libprotobuf-dev | sed -n 's/.*libprotobuf\([0-9]*\) .*/\1/p')

will not match libprotobuf32t64.

This also has the effect that the compatibility glue that seems to
have been intended to avoid mandatory rebuilds on 64-bit architectures
and i386:

>   phonenumberprotocompatabi := , libphonenumber8-protobuf$(shell dpkg-query 
> -W -f '$${Depends}' libprotobuf-dev | sed -n 's/.*libprotobuf\([0-9]*\) 
> .*/\1/p')

doesn't work as intended, because it generates a virtual package name
libphonenumber8-protobuf and not the required libphonenumber8-protobuf32.

I don't know whether the virtual package should be named
libphonenumber8t64-protobuf32 or libphonenumber8t64-protobuf32t64 (the
latter would probably be easiest), but presumably one of those?

I've reported this as important for now, but maybe it should be RC.

smcv

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Christoph Biedl]

Chris Hofstaedtler wrote...

> You are welcome to write a new tool or implement all the missing
> parts in deborphan and deal with users thinking deborphan is a magic
> tool that knows everything and its output can be used by
> non-thinking humans. Various people in the past have suggested its
> "trivial" and "obvious" how it should work, yet we don't seem to
> have a lot of these tools that are not "partially right but also
> wrong a lot".

That's not my point.

When we remove a package from Debian, we create a situation where
users lose a feature, and it is our task to keep the inconvenience
low.

For many packages we don't even have to care - packages with an
embedded version number like libraries or python have a natural
replacement, and in general it's drawn in automatically. Packages that
no longer work (dropped kernel feature, retired API usage), well, too
bad. Packages with a low popcon count, two digits at most, tell, too
bad as well.

Packages like deborphan (popcon high four digits) fall in neither
category. Users want it, big scale. So If you think is no longer good
for the job - I trust your judgement - the remaining task is to provide
users guidance how they get this job done in the future. And that should
be part of the initial RM request without being asked for.


You pointed to the release notes. The two methods suggested there fail
miserably: On an unstable chroot here, not updated without a week, so
before the beginning of the t64 transition, deborphan reports:

  # deborphan
  libb2-1
  libcanberra0
  libhiredis0.14
  liblua5.2-0
  libmpdec3
  libnewt0.52
  libpcre3
  libsigsegv2

Which alternative tool provides this list?

The suggested alternative "apt list" - note I have to enhance the
expression since my internal distribtion is okay as well:

  # apt list '?narrow(?installed, ?not(?or(?origin(Debian),?origin(local'
  Listing... Done
  #

So, nope. Also, 38 times slower.

The suggested "apt-forktracker" seems to do the same thing as the "apt
list" command, without being extensible for other origins. So, nope.
Also, 56 times slower.


Perhaps it can be done using debfoster, but that requires some
configuration which I didn't understand in a quick test.

The last thing I found was "apt list '?garbage'" - but this lists more
packages, and I fail to see the difference. Also, 38 times slower.


This is the kind of research users of deborphan will have to to,
or they look into the net, and will possibly not get the best adivce.


My objections against removing deborphan are mostly nostalgic ones as it
served me well for more than 20 years. Quite frankly, not a real point.
So, I can live without deborphan - if it was let go with dignity. Which
means I can have a different tool that serves the purpose, being telling
me which packages can be removed from the system because they are just
cruft from old times.

My point is solely about not giving users good advice how the get
deborphan's job done. And not giving it in the first place.

Christoph


signature.asc
Description: PGP signature

Bug#1065392: linux-image-6.7.7-amd64: Regression : "Failed to unseal secret using TPM2: Invalid argument"

[pdormeau]

Package: src:linux
Version: 6.7.7-1
Severity: normal

Dear Maintainer,

Decryting my home LUKS partition at boot with tpm2 works fine with 
linux-image-6.6.15-amd64 but fails with linux-image-6.7.7-amd64.

systemd-cryptsetup gives the folowing messages:

mars 03 17:10:51 myrtille systemd[1]: Starting systemd-cryptsetup@home.service 
- Cryptography Setup for home...
mars 03 17:10:52 myrtille systemd-cryptsetup[500]: 
WARNING:esys:src/tss2-esys/api/Esys_Unseal.c:295:Esys_Unseal_Finish() Received 
TPM Error
mars 03 17:10:52 myrtille systemd-cryptsetup[500]: 
ERROR:esys:src/tss2-esys/api/Esys_Unseal.c:98:Esys_Unseal() Esys Finish 
ErrorCode (0x0128)
mars 03 17:10:52 myrtille systemd-cryptsetup[500]: Failed to unseal secret 
using TPM2: Invalid argument
mars 03 17:10:52 myrtille systemd-cryptsetup[500]: Set cipher aes, mode 
xts-plain64, key size 512 bits for device 
/dev/disk/by-uuid/e560bff8-34ab-40d7-ac80->
mars 03 17:10:53 myrtille systemd-cryptsetup[500]: 
WARNING:esys:src/tss2-esys/api/Esys_Unseal.c:295:Esys_Unseal_Finish() Received 
TPM Error
mars 03 17:10:53 myrtille systemd-cryptsetup[500]: 
ERROR:esys:src/tss2-esys/api/Esys_Unseal.c:98:Esys_Unseal() Esys Finish 
ErrorCode (0x0128)
mars 03 17:10:53 myrtille systemd-cryptsetup[500]: Failed to unseal secret 
using TPM2: Invalid argument

I enrool the tpm key with systemd-cryptenroll using the default PCR 7 and 
secure boot is enabled.

$ systemd-cryptenroll --tpm2-device=list
PATHDEVICE DRIVER 
/dev/tpmrm0 IFX1522:00 tpm_tis

Regards

-- Package-specific info:
** Version:
Linux version 6.7.7-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.2.0-16.1) 13.2.0, GNU ld (GNU Binutils for 
Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.7.7-1 (2024-03-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.7.7-amd64 
root=UUID=6dc0e7ec-e588-4c76-8c94-0ad097ce4975 ro acpi_backlight=video 
systemd.show-status=true systemd.restore_state=0 quiet

** Not tainted

** Kernel log:
[6.374921] skl_hda_dsp_generic skl_hda_dsp_generic: 
hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 3
[6.389974] usb 3-10: new full-speed USB device number 3 using xhci_hcd
[6.392506] usb 3-4: Found UVC 1.50 device Integrated RGB Camera (30c9:0050)
[6.402456] input: sof-hda-dsp Mic as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input16
[6.402480] input: sof-hda-dsp Headphone as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input17
[6.402552] input: sof-hda-dsp HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input18
[6.402587] input: sof-hda-dsp HDMI/DP,pcm=4 as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input19
[6.402614] input: sof-hda-dsp HDMI/DP,pcm=5 as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input20
[6.406427] usbcore: registered new interface driver uvcvideo
[6.461599] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x20
[6.461657] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
[6.461666] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90
[6.461675] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x0
[6.463101] iwlwifi :00:14.3: RFIm is deactivated, reason = 4
[6.550379] usb 3-10: New USB device found, idVendor=8087, idProduct=0033, 
bcdDevice= 0.00
[6.550392] usb 3-10: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
[6.558698] iwlwifi :00:14.3: Registered PHC clock: iwlwifi-PTP, with 
index: 1
[6.595787] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[6.716051] Bluetooth: Core ver 2.22
[6.716070] NET: Registered PF_BLUETOOTH protocol family
[6.716072] Bluetooth: HCI device and connection manager initialized
[6.716074] Bluetooth: HCI socket layer initialized
[6.716076] Bluetooth: L2CAP socket layer initialized
[6.716080] Bluetooth: SCO socket layer initialized
[6.760417] usbcore: registered new interface driver btusb
[6.764010] Bluetooth: hci0: Device revision is 0
[6.764014] Bluetooth: hci0: Secure boot is enabled
[6.764016] Bluetooth: hci0: OTP lock is enabled
[6.764017] Bluetooth: hci0: API lock is enabled
[6.764017] Bluetooth: hci0: Debug lock is disabled
[6.764018] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[6.764020] Bluetooth: hci0: Bootloader timestamp 2019.40 buildtype 1 build 
38
[6.764244] ACPI Warning: \_SB.PC00.XHCI.RHUB.HS10._DSM: Argument #4 type 
mismatch - Found [Integer], ACPI requires [Package] (20230628/nsarguments-61)
[6.764274] Bluetooth: hci0: DSM reset method type: 0x00
[6.768607] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-0040-0041.sfi
[6.771091] Bluetooth: hci0: Found device firmware: intel/ibt-0040-0041.sfi
[6.771411] Bluetooth: hci0: Boot Address: 0x100800
[6.771412] Bluetooth: hci0: Firmware Version: 98-13.23
[7.490605] typec port1: bound usb3-port6 (ops connector_ops 

Bug#1064031: rustc-web 1.70.0+dfsg1-7~deb12u1 flagged for acceptance

[Adam D. Barratt]

On Sat, 2024-03-02 at 03:54 -0500, Andres Salomon wrote:
> rustc-web (1.70.0+dfsg1-7~deb12u2) bookworm; urgency=medium
> 
>    * Non-maintainer upload.
>    * Increase allowed test failures on armhf and ppc64el to fix
> FTBFS.
>    * Provide Conflicts/Replaces for rust*-mozilla*, which could still
> be
>  installed from oldstable (closes: #1064562).
>    * Add Provides/Conflicts/Replaces for libstd-rust-1.70 (closes: 
> #1064563).

Please go ahead.

Regards,

Adam

Bug#1065356: Issues in man pages of cron

[Helge Kreutzmann]

Hello Georges,
Am Sun, Mar 03, 2024 at 06:37:25PM +0100 schrieb Georges Khaznadar:
> thank you for your detailed bug report.

You are welcome.

> Helge Kreutzmann a écrit :
> > We use several distributions as sources and update regularly (at
> > least every 2 month). 
> 
> Most changes here are probably specific to Debian; however they will
> also apply to Debian derivatives.

Yes, given that I could not reach upstream, I only reported those
issues which were actually present in the Debian version. I don't know
when and how I can report the rest.

> > Secondly we translators see the manpages in the neutral po format,
> > i.e. converted and harmonized, but not the original source (be it man,
> > groff, xml or other). So we cannot provide a true patch (where
> > possible), but only an approximation which you need to convert into
> > your source format.
> 
> The original format for Debian's manpages regarding cron is groff.

That's usual, but po4a transforms this in a more friendly format for
us translators.

> Unfortunately, it is not the easiest format for human translators, as it
> is probably split in small chunks written to PO files, with little
> meaning in each of them.

That's fine, don't worry. If in doubt we can always build the full
translated page and read it for consisteny. And small paragraphs are
usually better to handle and, potentially, reuse.

> > (Btw., do you have a working e-mail address of upstream?)
> 
> The upstream developer, Paul Vixie, had an e-mail address: p...@vix.com

Ok, so nothing new.

> However, he does no longer maintain cron, and Debian's cron package
> comes from a fork, dated "Sun, 1 Dec 1996 16:21:52 -0600".  So, for
> twenty eight years now, all of the development was made by various
> debian developers, and is structured as a heap of 84 patches
> (see the file
> https://salsa.debian.org/debian/cron/-/blob/master/debian/patches/series?ref_type=heads)
> 
> Regarding the issues listed below, I do not fully understand the syntax.
> 
> If I consider the very first issue:
> > 
> > Man page: cron.8
> > Issue:B<-L loglevel> → B<-L> I
> > 
> > "B<-L loglevel>"
> > --
> 
> and take a look at the manpage, which is in groff format, I can find some
> matching line:
> 
> 8<---
> $ zgrep loglevel /usr/share/man/man8/cron.8.gz 
> .IR loglevel ]
> .B \-L loglevel
> 8<---
> 
> The last line (in groff) means: write "-L loglevel" with a bold font.
> This probably has the same meaning as the line "B<-L loglevel>" in the
> snipped above.

Yes, and this is what should be corrected.

> So how can I help? can I answer that the line "B<-L loglevel>" is the
> current valid source for localizations?

I'm not very good (if at all) at groff, by I think
the following might work:
.B \-L
.I loglevel

or even
.BI \-L loglevel

> Now let us consider the next issues:
> 
> > Man page: crontab.1
> > Issue 1:  I<-h> → B<-h>
> > Issue 2:  I → B
> > 
> > "If the I<-h> option is given, I shows a help message and quits "
> > "immediately."
> > --
> 
> 
> How can I help? Here is the match which I can find:
> 
> 8<---
> zgrep -- -h  /usr/share/man/man1/crontab.1.gz 
> crontab [ \-h]
> .I \-h
> 8<---
> 
> The last line (in groff format) would probably match Issue 1 above,
> however once again I do not guess how I can help.

You put it in Italics, but the convention (see man-pages(7) and
man(7)) is to use bold, so this one is simply:

.B \-h

> It would probably be a waste of energy to discuss now all and every
> issue you sent me. Maybe we can first agree about a method to make the
> task easier for both of us, and for the many contributors to translation
> teams.

I hope this explains it. 

> Please can you suggest me one or more techniques which might improve the
> feedback, regarding the simple examples cited above? The main question
> is "how can I help?", which can be rephrased as "what kind of answer
> would you expect?".

First thanks for your ultra fast response - this is extraordinary
help already. And for your verbose questions, which make it easier for
me to respond.

I think most of the report boils down that you update the patches by
using .B instead of .I or sometimes .BI

I hope this explains it better.

Greetings

   Helge

P.S. And since there is probably little changes in cron nowadays, most
 likely few if none further reports from my side…

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


signature.asc
Description: PGP signature

Bug#1065391: xtrace interactive mode stutters with multiple clients

[Daniel Manjarres]

Package: xtrace
Version: 1.4.0-1+b1
Severity: normal
Tags: patch

Dear Maintainer,

The loop in main.c checks for input on multiple clients, but lines
292-305 should be outside of this loop, and only checked once per
invocation of select(). Otherwise when N clients are connected it
leads to blocking reads from stdin, typically waiting N times and then
allowing N requests through all at once.

The patch below also uses STDIN_FILENO instead of 0, for easier
readability.

--- main.c.orig 2024-03-03 09:40:41.443380046 -0800
+++ main.c  2024-03-03 10:32:13.911321696 -0800
@@ -288,21 +288,21 @@
}
continue;
}
-   for( c = connections ; c != NULL ; c = c->next ) {
-   if( interactive && FD_ISSET(0,) ) {
-   char buffer[201];
-   ssize_t isread;
-   isread = read(0,buffer,200);
-   if( isread == 0 )
-   exit(EXIT_SUCCESS);
-   if( isread > 0 ) {
-   buffer[isread]='\0';
-   int number = atoi(buffer);
-   if( number <= 0 )
-   number = 1;
-   allowsent += number;
-   }
+   if( interactive && FD_ISSET(STDIN_FILENO,) ) {
+   char buffer[201];
+   ssize_t isread;
+   isread = read(STDIN_FILENO,buffer,200);
+   if( isread == 0 )
+   exit(EXIT_SUCCESS);
+   if( isread > 0 ) {
+   buffer[isread]='\0';
+   int number = atoi(buffer);
+   if( number <= 0 )
+   number = 1;
+   allowsent += number;
}
+   }
+   for( c = connections ; c != NULL ; c = c->next ) {
if( c->client_fd != -1 ) {
if( FD_ISSET(c->client_fd,) ) {
close(c->client_fd);

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

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

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

xtrace recommends no packages.

Versions of packages xtrace suggests:
ii  xauth  1:1.1.2-1

-- debconf-show failed

Bug#1064995: fenics-dolfinx: suspicious autopkgtest on s390x seems to use (nearly) all disk space

[Paul Gevers]

Hi,

On Wed, 28 Feb 2024 20:48:06 +0100 Paul Gevers  wrote:
Since a couple of days, our workers on s390x are dying because some test 
is filling up all disk space. It *appears* that fenics-dolfinx is always 
involved, so I suspect it doing something inappropriate.


Yesterday we were in the same (or very similar) situation again despite 
fenics-dolfinx being on the reject_list for s390x. So, most likely it 
was not its fault.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065380: ausweisapp2 FTBFS with pcsc-lite 2.0.2

[Adrian Bunk]

Control: reassign -1 libpcsclite-dev 2.0.2-1
Control: affects -1 src:ausweisapp2

On Sun, Mar 03, 2024 at 06:41:25PM +0100, Ludovic Rousseau wrote:
> Le 03/03/2024 à 17:13, Adrian Bunk a écrit :
> > Source: ausweisapp2
> > Version: 2.0.3-1
> > Severity: serious
> > Tags: ftbfs
> > X-Debbugs-Cc: Ludovic Rousseau 
> > 
> > https://buildd.debian.org/status/logs.php?pkg=ausweisapp2=2.1.0-1
> > 
> > ...
> > /<>/src/card/pcsc/PcscUtils.h:112:46: error: 
> > ‘SCARD_E_UNKNOWN_RES_MNG’ was not declared in this scope; did you mean 
> > ‘SCARD_E_UNKNOWN_RES_MSG’?
> >112 | Scard_E_Unknown_Res_Mng = 
> > returnCode(SCARD_E_UNKNOWN_RES_MNG), /**< An unrecognized error 
> > code was returned from a layered component. */
> >|  
> > ^~~
> > ...
> > 
> > 
> > This is not a regression in the new ausweisapp2 upload,
> > but due to a change in pcsc-lite 2.0.2 (maintainer Cc'ed):
> > 
> > https://salsa.debian.org/rousseau/PCSC/-/commit/65f9b610138c8a4a5563d0332120f684682e0237
> > "Fix typo in (unused) error code SCARD_E_UNKNOWN_RES_MSG"
> 
> Exact.
> 
> I now discover that Windows does define BOTH values:
> SCARD_E_UNKNOWN_RES_MSG 0x8010002B in 
> https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpesc/9861f8da-76fe-41e6-847e-40c9aa35df8d
> SCARD_E_UNKNOWN_RES_MNG 0x8010002B in 
> https://learn.microsoft.com/en-us/windows/win32/secauthn/authentication-return-values
> 
> I guess pcsc-lite will also have to define both values.
> I will release a new pcsc-lite version soon.
>...

Thanks, I'm reassigning the bug to libpcsclite-dev since that's where it 
will be fixed.

cu
Adrian

Bug#1065371: unable to disable bug-implicit-func for time64

[Guillem Jover]

Hi!

On Sun, 2024-03-03 at 16:46:33 +0100, Guillem Jover wrote:
> On Sun, 2024-03-03 at 16:11:36 +0100, Matthias Klose wrote:
> >  - please provide an opt-out option.
> 
> This is a bug, which I should fix.

The first attached patch is what I'd use to fix this.

> >  - turn it on on all architectures, so that everbody
> >can reproduce the effects.
> 
> I'd be fine with that.

The second attached patch is what I'd use to implement this, if
there's agreement. (Barring manual page updates here.)

I'll wait for Steve's input, before proceeding, otherwise I might just
upload the first patch for now, either later today or tomorrow, so that
people can opt-out of this until there's agreement on how to proceed.
(Even though I guess people could already use DEB_CFLAGS_MAINT_STRIP to
forcibly disable the -Werror=implicit-function-declaration flag.)

Thanks,
Guillem
From f747a38746cbf0fa4279e773835b7d872c0d313c Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 3 Mar 2024 18:42:34 +0100
Subject: [PATCH] Dpkg::Vendor::Debian: Make it possible to disable
 qa=-bug-implicit-func

We do not need to forcibly enable this feature if the user explicitly
specified it.

Closes: #1065371
---
 scripts/Dpkg/Vendor/Debian.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
index fcf5b1e2a..ad727d2cf 100644
--- a/scripts/Dpkg/Vendor/Debian.pm
+++ b/scripts/Dpkg/Vendor/Debian.pm
@@ -299,8 +299,8 @@ sub set_build_features {
 $use_feature{abi}{lfs} = 1 if $libc eq 'gnu';
 
 # Require -Werror=implicit-function-declaration, to avoid linking
-# against the wrong symbol.
-$use_feature{qa}{'bug-implicit-func'} = 1;
+# against the wrong symbol, unless it has been set explicitly.
+$use_feature{qa}{'bug-implicit-func'} //= 1;
 }
 
 # XXX: Handle lfs alias from future abi feature area.
-- 
2.43.0

From 87702728876e96891d02df2d1b0419f709939190 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sun, 3 Mar 2024 18:53:12 +0100
Subject: [PATCH] Dpkg::Vendor::Debian: Unconditionally set qa
 bug-implicit-func

For the time64 default change, we conditionally enabled
bug-implicit-func to avoid silent ABI breakage due to implicit function
declarations that end up using the time32 symbols, but that is causing
confusion as the effects are not visible on the most commonly used
architectures. Instead enable this globally, unless the maintainer has
specified otherwise.
---
 scripts/Dpkg/Vendor/Debian.pm | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
index ad727d2cf..b3be69e86 100644
--- a/scripts/Dpkg/Vendor/Debian.pm
+++ b/scripts/Dpkg/Vendor/Debian.pm
@@ -117,7 +117,7 @@ sub set_build_features {
 time64 => undef,
 },
 qa => {
-bug => 0,
+bug => undef,
 'bug-implicit-func' => undef,
 canary => 0,
 },
@@ -297,10 +297,6 @@ sub set_build_features {
 if ($use_feature{abi}{time64} && ! $builtin_feature{abi}{time64}) {
 # On glibc 64-bit time_t support requires LFS.
 $use_feature{abi}{lfs} = 1 if $libc eq 'gnu';
-
-# Require -Werror=implicit-function-declaration, to avoid linking
-# against the wrong symbol, unless it has been set explicitly.
-$use_feature{qa}{'bug-implicit-func'} //= 1;
 }
 
 # XXX: Handle lfs alias from future abi feature area.
@@ -311,7 +307,14 @@ sub set_build_features {
 
 ## Area: qa
 
-$use_feature{qa}{'bug-implicit-func'} //= $use_feature{qa}{bug};
+# For time64 we require -Werror=implicit-function-declaration, to avoid
+# linking against the wrong symbol. Instead of enabling this conditionally
+# on time64 being enabled, do it unconditionally so that the effects are
+# uniform and visible on all architectures. Unless it has been set
+# explicitly.
+$use_feature{qa}{'bug-implicit-func'} //= $use_feature{qa}{bug} // 1;
+
+$use_feature{qa}{bug} //= 0;
 
 ## Area: reproducible
 
-- 
2.43.0

Bug#1065382: trap int3 ip:7fed77a24587 sp:7ffc8e859b40 error:0 in libglib-2.0.so.0.7800.4[7fed779e0000+99000]

[Simon McVittie]

On Sun, 03 Mar 2024 at 17:34:25 +0100, Harald Dunkel wrote:
> I got a few messages in kern.log:
> 
> 2024-03-03T17:10:55.375204+01:00 cecil kernel: traps: at-spi-bus-laun[2238] 
> trap int3 ip:7f52523f5587 sp:7ffded761730 error:0 in 
> libglib-2.0.so.0.7800.4[7f52523b1000+99000]

Please try reinstalling the libglib2.0-0t64 package. If you have multiarch
(e.g. amd64 + i386), reinstall each instance (e.g. libglib2.0-0t64:amd64
+ libglib2.0-0t64:i386).

If that workaround is successful, then this is probably #1065022, for
which a real fix is pending. I am sorry that this bug has taken time
to resolve.

Or, if that workaround is unsuccesful, then this is some other bug,
in which case we will not be able to solve it without more information:
please see .

Thanks,
smcv

Bug#1065356: Issues in man pages of cron

[Georges Khaznadar]

Dear Helge,

thank you for your detailed bug report.

Helge Kreutzmann a écrit :
> We use several distributions as sources and update regularly (at
> least every 2 month). 

Most changes here are probably specific to Debian; however they will
also apply to Debian derivatives.

> Secondly we translators see the manpages in the neutral po format,
> i.e. converted and harmonized, but not the original source (be it man,
> groff, xml or other). So we cannot provide a true patch (where
> possible), but only an approximation which you need to convert into
> your source format.

The original format for Debian's manpages regarding cron is groff.

Unfortunately, it is not the easiest format for human translators, as it
is probably split in small chunks written to PO files, with little
meaning in each of them.

> I'm now reporting the errors for your project. If future reports
> should use another channel, please let me know.

Debian bug reports are a valid channel for me.

> (Btw., do you have a working e-mail address of upstream?)

The upstream developer, Paul Vixie, had an e-mail address: p...@vix.com

However, he does no longer maintain cron, and Debian's cron package
comes from a fork, dated "Sun, 1 Dec 1996 16:21:52 -0600".  So, for
twenty eight years now, all of the development was made by various
debian developers, and is structured as a heap of 84 patches
(see the file
https://salsa.debian.org/debian/cron/-/blob/master/debian/patches/series?ref_type=heads)

Regarding the issues listed below, I do not fully understand the syntax.

If I consider the very first issue:
> 
> Man page: cron.8
> Issue:B<-L loglevel> → B<-L> I
> 
> "B<-L loglevel>"
> --

and take a look at the manpage, which is in groff format, I can find some
matching line:

8<---
$ zgrep loglevel /usr/share/man/man8/cron.8.gz 
.IR loglevel ]
.B \-L loglevel
8<---

The last line (in groff) means: write "-L loglevel" with a bold font.
This probably has the same meaning as the line "B<-L loglevel>" in the
snipped above.

So how can I help? can I answer that the line "B<-L loglevel>" is the
current valid source for localizations?

Now let us consider the next issues:

> Man page: crontab.1
> Issue 1:  I<-h> → B<-h>
> Issue 2:  I → B
> 
> "If the I<-h> option is given, I shows a help message and quits "
> "immediately."
> --


How can I help? Here is the match which I can find:

8<---
zgrep -- -h  /usr/share/man/man1/crontab.1.gz 
crontab [ \-h]
.I \-h
8<---

The last line (in groff format) would probably match Issue 1 above,
however once again I do not guess how I can help.

It would probably be a waste of energy to discuss now all and every
issue you sent me. Maybe we can first agree about a method to make the
task easier for both of us, and for the many contributors to translation
teams.

Please can you suggest me one or more techniques which might improve the
feedback, regarding the simple examples cited above? The main question
is "how can I help?", which can be rephrased as "what kind of answer
would you expect?".

Best regards,   Georges.



signature.asc
Description: PGP signature

Bug#1065390: xkeystone: depedency on nickle not available

[Adam Majer]

Package: x11-xserver-utils
Version: 7.7+10

There seems to be a dependency missing, or at least a recommends if a 
strict dependency would pull in too many things


$ xkeystone
/usr/bin/env: ‘nickle’: No such file or directory

$ head /usr/bin/xkeystone
#!/usr/bin/env nickle

To make this utility work, had to install

  cairo-5c, nickle

Bug#1065389: RFS: python-click/8.1.7-1 [ITA] -- Wrapper around optparse for command line utilities - documentation

[Akash Doppalapudi]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-click":

 * Package name : python-click
   Version  : 8.1.7-1
   Upstream contact : cont...@palletsprojects.com
 * URL  : https://github.com/pallets/click
 * License  : BSD-3-clause
 * Vcs  : 
https://salsa.debian.org/python-team/packages/python-click

   Section  : python

The source builds the following binary packages:

  python3-click - Wrapper around optparse for command line utilities - 
Python 3.x
  python-click-doc - Wrapper around optparse for command line utilities 
- documentation


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


  https://mentors.debian.net/package/python-click/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-click/python-click_8.1.7-1.dsc


Changes since the last upload:

 python-click (8.1.7-1) unstable; urgency=medium
 .
   * New upstream version 8.1.7
   * New Maintainer (Closes: #1065251)
   * d/control:
 - Change Maintainer name
 - Add python-click-doc in Suggests for python3-click
   * d/copyright:
 - Add new maintainer name in copyright stanza

Regards,
--
  Akash Doppalapudi


OpenPGP_0xBCBCAE31ECE05007.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065380: ausweisapp2 FTBFS with pcsc-lite 2.0.2

[Ludovic Rousseau]

Le 03/03/2024 à 17:13, Adrian Bunk a écrit :

Source: ausweisapp2
Version: 2.0.3-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Ludovic Rousseau 

https://buildd.debian.org/status/logs.php?pkg=ausweisapp2=2.1.0-1

...
/<>/src/card/pcsc/PcscUtils.h:112:46: error: 
‘SCARD_E_UNKNOWN_RES_MNG’ was not declared in this scope; did you mean 
‘SCARD_E_UNKNOWN_RES_MSG’?
   112 | Scard_E_Unknown_Res_Mng = returnCode(SCARD_E_UNKNOWN_RES_MNG),
 /**< An unrecognized error code was returned from a layered component. */
   |  ^~~
...


This is not a regression in the new ausweisapp2 upload,
but due to a change in pcsc-lite 2.0.2 (maintainer Cc'ed):

https://salsa.debian.org/rousseau/PCSC/-/commit/65f9b610138c8a4a5563d0332120f684682e0237
"Fix typo in (unused) error code SCARD_E_UNKNOWN_RES_MSG"


Exact.

I now discover that Windows does define BOTH values:
SCARD_E_UNKNOWN_RES_MSG 0x8010002B in 
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpesc/9861f8da-76fe-41e6-847e-40c9aa35df8d
SCARD_E_UNKNOWN_RES_MNG 0x8010002B in 
https://learn.microsoft.com/en-us/windows/win32/secauthn/authentication-return-values

I guess pcsc-lite will also have to define both values.
I will release a new pcsc-lite version soon.

Sorry.

--
Dr. Ludovic Rousseau

Bug#1061371: gcc-14 ftbfs on loong64

[Adrian Bunk]

On Tue, Jan 23, 2024 at 09:08:00AM +0100, Matthias Klose wrote:
> Package: src:gcc-14
> Version: 14-20240121-1
> Severity: important
> Tags: sid trixie ftbfs
> X-Debbugs-CC: debian-loonga...@lists.debian.org
> 
> gcc-14 ftbfs on loong64:
>...

The remaining build failure is now:

https://buildd.debian.org/status/fetch.php?pkg=gcc-14=loong64=14-20240303-1=1709485913=0

...
dh_installdirs -plibgcc-s1 usr/share/doc/libgcc-s1 usr/lib/loongarch64-linux-gnu
mv debian/tmp/usr/lib/loongarch64-linux-gnu/libgcc_s.so.1 
debian/libgcc-s1/usr/lib/loongarch64-linux-gnu/.
mv: cannot stat 'debian/tmp/usr/lib/loongarch64-linux-gnu/libgcc_s.so.1': No 
such file or directory
make[1]: *** [debian/rules.d/binary-libgcc.mk:291: 
stamps/08-binary-stamp-libgcc] Error 1


cu
Adrian

Bug#1065388: libqt5core5t64: control files are wrong for all t64 qt libraries

[Eric Valette]

Package: libqt5core5t64
Version: 5.15.10+dfsg-7.1
Severity: grave
Justification: renders package unusable

Package: libqt5core5t64
Source: qtbase-opensource-src
Version: 5.15.10+dfsg-7.1
Architecture: amd64
Maintainer: Debian Qt/KDE Maintainers 
Installed-Size: 6061
Depends: shared-mime-info, libc6 (>= 2.35), libdouble-conversion3 (>= 2.0.0), 
libgcc-s1 (>= 3.4), libglib2.0-0t64 (>= 2.22.0), libicu72 (>= 72.1~rc-1~), 
libpcre2-16-0 (>= 10.22), libstdc++6 (>= 11), libzstd1 (>= 1.5.5), zlib1g (>= 
1:1.1.4)
Recommends: qttranslations5-l10n
Suggests: libthai0
Breaks: libqt5core5a (<< 5.15.10+dfsg-7.1)
Replaces: libqt5core5a
Provides: libqt5core5a (= 5.15.10+dfsg-7.1), qtbase-abi-5-15-10
Section: libs
Priority: optional
Multi-Arch: same
Homepage: https://www.qt.io/developers/
Description: Qt 5 core module
 Qt is a cross-platform C++ application framework. Qt's primary feature
 is its rich set of widgets that provide standard GUI functionality.
 .
 The QtCore module contains core non-GUI functionality.


The Breaks: makes apt to search for a  libqt5core5a >=  5.15.10+dfsg-7.1 but it
will never exist as long as the package is not FIRST replaced by the t64 
version.

Removing the Breaks: make it installable and the provides expose the 
libqt5core5a
as present.

It has been stuck for 5 days already and I do not think this is due to the 
transition
(except many package are uninstalable due to various error in control files).

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

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

Versions of packages libqt5core5t64 depends on:
ii  libc6  2.38-6
ii  libdouble-conversion3  3.3.0-1+b1
ii  libgcc-s1  14-20240221-2.1
ii  libglib2.0-0t642.78.4-2.1+b1
ii  libicu72   72.1-4+b1
ii  libpcre2-16-0  10.42-4+b1
ii  libstdc++6 14-20240221-2.1
ii  libzstd1   1.5.5+dfsg2-2
ii  shared-mime-info   2.4-1
ii  zlib1g 1:1.3.dfsg-3.1

Versions of packages libqt5core5t64 recommends:
ii  qttranslations5-l10n  5.15.10-2

Versions of packages libqt5core5t64 suggests:
ii  libthai0  0.1.29-2

Bug#1064369: gobject-introspection dropped versioned dependency on python3

[Simon McVittie]

Control: severity -1 important

On Tue, 20 Feb 2024 at 23:15:09 +0100, Matthias Klose wrote:
> On 20.02.24 22:50, Simon McVittie wrote:
> > If gobject-introspection explicitly depended on gobject-introspection-bin
> > by name (not just via a virtual package), would that help?
> 
> I think that would do it

I will upload this change soon. It is not clear to me why it would be
helpful, but it's also unlikely to cause a problem.

If I am wrong about this and it somehow causes a regression, I will
try to revert it immediately, but I am quite burned-out at the moment
and I have responsibilities outside Debian, so I would appreciate it if
someone else in the team could keep an eye on this package.

> > On Tue, 20 Feb 2024 at 22:15:21 +0100, Matthias Klose wrote:
> > > The package had in the past dependencies of the form
> > > 
> > >python3 (<< 3.12), python3 (>= 3.11~), python3:any
> > > 
> > > the new one just
> > > 
> > >python3:any
> > 
> > The parts that require a specific python3 version are now in the
> > gobject-introspection-bin binary package, which correctly depends on:
> > 
> >  python3 (<< 3.12), python3 (>= 3.11~), python3:any
> > 
> > via dh_python and ${python3:Depends}. The gobject-introspection package
> > no longer contains any binary Python extensions.

I've explained why I believe this arrangement is correct, and therefore I
don't think there is a bug to be resolved here (certainly not a RC bug).
I am sorry if I have failed to understand the point you were making.

If you disagree and still consider there to be a serious bug here,
please describe a test scenario where the wrong thing happening can be
reproduced (either dependencies that permit an incorrect situation to
be installed, or package relationships that cause some other component
like britney or autopkgtest to misbehave), the result you would expect
from that test scenario, and the actual result.

Thanks,
smcv

Bug#1065309: transition: gnat 12 -> 13 + time_t64

[Nicolas Boulenguez]

Package: release.debian.org
X-Debbugs-Cc: debian-...@lists.debian.org

Hello.
In addition to the information in https://bugs.debian.org/1065309,
here is the usual summary preparing a gnat transition.

--

This bug requests a green light for a transition of Ada packages from
gnat-12 to gnat-13 in unstable.

The gcc-V source package builds the Ada compiler (gnat-V) and
companion library (libgnat-V).
The default Ada compiler is selected by the gnat package.
In unstable and testing, gnat Depends: gnat-12.
In experimental, gnat Depends: gnat-13.

This transition breaks the ABI of Ada libraries.  Each Ada library has
been uploaded to experimental with a new Shared Object version in the
library package name (and hence, a passage through NEW).

This is unrelated with gnat-13, but this transition also introduces a
new naming scheme for Ada -dev packages in Debian.  They stop carrying
a version identifying the API, and instead provide a versioned virtual
package instead.  The effect is the same, an API break in an Ada
library (this includes libgnat-V) requires a transition, but the NEW
queue will not be involved anymore.

Ben file:

title = "gnat-13";
is_affected = .depends ~ "libgnat-8/libgnat-9/libgnat-10/libgnat-11/libgnat-12" 
| .depends ~ "libgnat-13";
is_good = .depends ~ "libgnat-13";
is_bad = .depends ~ "libgnat-8/libgnat-9/libgnat-10/libgnat-11/libgnat-12";

These packages provide a library and are ready in experimental.
 adacgi
 adasockets
 ahven
 anet
 dbusada
 gprbuild
 libalog
 libaunit
 libflorist
 libgmpada
 libgnatcoll  The transition closes #1061631.
 libgnatcoll-db   The transition closes #1064745.
 libgnatcoll-bindings
 libgtkada
 liblog4ada
 libncursesada
 libtemplates-parser  The transition closes #1061633.
 libtexttools
 libxmlada
 libxmlezout
 pcscada
 plplot   The reupload must merge 5.15.0+dfsg2-7+deb13u2/unstable
  and 5.15.0+dfsg2-8/experimental. The changes are small
  and unrelated with Ada.

These packages, although not Ada libraries, are part of the transition.
They are ready in experimental and need a rebuild in unstable.
 alire
 dh-ada-library
 gnat

These packages produce no library. They need a bin-NMU.
nmu music123_16.6-6  . ANY . -m 'Rebuild with gnat-13'
dw  music123_16.6-6  . ANY . -m 'gnat (>= 13.1)'
nmu phcpack_2.4.89+dfsg-1. ANY . -m 'Rebuild with gnat-13'
dw  phcpack_2.4.89+dfsg-1. ANY . -m 'gnat (>= 13.1)'
nmu topal_81-2   . ANY . -m 'Rebuild with gnat-13'
dw  topal_81-2   . ANY . -m 'gnat (>= 13.1)'
nmu whitakers-words_0.2020.10.27-1.3 . ANY . -m 'Rebuild with gnat-13'
dw  whitakers-words_0.2020.10.27-1.3 . ANY . -m 'gnat (>= 13.1)'

ada-reference-manual only requires gnat at build time.
It should not be affected.

ghdl build-depends on an explicit gnat version for reasons unrelated
with the normal Ada policy.
It should not be affected.

These packages have been removed from testing for a while because of
unrelated RC bugs.
 adabrowse
 adacontrol
 asis
 gnat-gps
 libaws

Bug#1065015: the control file for the akonadi libraries are palin wrong

[Eric Valette]

The transition is completed but the package cannot install because of 
Breaks: in the control file


And I second that the abi provided should be without 
t64libkf5akonadisearchpim5-22.12



I managed to install removing the breaks in the package name and 
modifying the abi provided


So nothing to do with transition.

And You are not alone to make mistake in control files.

-- eric

Bug#1043828: astroid: Fails to build source after successful build

[Nicolas Boulenguez]

Source: astroid
Followup-For: Bug #1043828
Control: tags -1 + patch

Hello.
A trivial patch is available as a salsa merge request at
https://salsa.debian.org/python-team/packages/astroid/-/merge_requests/5

Bug#1065384: RFS: psocksxx/1.1.1-4 -- psocksxx is a C++ wrapper for POSIX sockets (documentation)

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : psocksxx
   Version  : 1.1.1-4
   Upstream contact : [fill in name and email of upstream]
 * URL  : https://nukedzn.github.io/psocksxx
 * License  : LGPL-3+
 * Vcs  : https://git.jff.email/cgit/psocksxx.git
   Section  : libs

The source builds the following binary packages:

  libpsocksxx0t64 - psocksxx is a C++ wrapper for POSIX sockets
  libpsocksxx-dev - psocksxx is a C++ wrapper for POSIX sockets (development 
files)
  libpsocksxx-doc - psocksxx is a C++ wrapper for POSIX sockets (documentation)

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/p/psocksxx/psocksxx_1.1.1-4.dsc

or from 

 git https://git.jff.email/cgit/psocksxx.git/?h=release%2Fdebian%2F1.1.1-4


Changes since the last upload:

 psocksxx (1.1.1-4) unstable; urgency=medium
 .
   * debian/control:
 - Change to new repository URL.
   * Declare compliance with Debian Policy 4.6.2.0 (No changes needed).
   * debian/changelog:
 - Add 2024 to myself.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://git.jff.email/cgit/

Skype:jff-skype@jff.email
Jami: joergfringsfuerst
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.






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

Bug#1064194: 535.86.05 breaks Xorg

[Harald Dunkel]

Hi Andreas,

On 2024-03-01 11:36:43, Andreas Beckmann wrote:

Hi Harald,

On 24/02/2024 11.31, Harald Dunkel wrote:

[INSTALL, DEPENDENCIES] libnvidia-glvkspirv:amd64 535.86.10-1
[INSTALL, DEPENDENCIES] nvidia-vulkan-common:amd64 535.86.10-1
[INSTALL] nvidia-vulkan-icd:amd64 535.86.10-1


Are you sure that you really need nvidia-vulkan-icd (i.e.
nvidia-vulkan-common) and libnvidia-glvkspirv alone isn't enough?



Yes, installing libnvidia-glvkspirv is sufficient as a fix. If I remove
this package the problem is back.


Regards

Harri

Bug#1064558: [Pkg-javascript-devel] Bug#1064558: node-leveldown: FTBFS on mips64el: not ok 1397 Error: batch(array) element must be an object and not `null`

[Jérémy Lal]

Le dim. 3 mars 2024 à 07:57, Yadd  a écrit :

> On 2/24/24 13:10, Sebastian Ramacher wrote:
> > Source: node-leveldown
> > Version: 5.6.0+dfsg-4
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source (but built successfully in the
> past)
> > X-Debbugs-Cc: sramac...@debian.org
> >
> >
> https://buildd.debian.org/status/fetch.php?pkg=node-leveldown=mips64el=5.6.0%2Bdfsg-4%2Bb1=1708632735=0
> >
> > not ok 1397 Error: batch(array) element must be an object and not `null`
> >---
> >  operator: error
> >  stack: |-
> >Error: batch(array) element must be an object and not `null`
> >at AbstractLevelDOWN.batch
> (/usr/share/nodejs/abstract-leveldown/abstract-leveldown.js:163:33)
> >at /<>/test/iterator-recursion-test.js:48:8
> >at
> /usr/share/nodejs/abstract-leveldown/abstract-leveldown.js:41:5
> >...
> >
> > Cheers
>
> Hi Jérémy,
>
> when trying to build on mips64el porterbox, i got this:
>
> make[1]: Entering directory '/home/yadd/node-leveldown'
> node-gyp clean
> node: error while loading shared libraries: libnode.so.108: cannot open
> shared object file: No such file or directory
>

In Sid, I am afraid it has been renamed to libnode108t64 or something like
that.
I'll have a look later today.

Jérémy

Bug#1029068: vcswatch: fails to run due to full file system.

[Ricardo Mones]

Package: qa.debian.org
Followup-For: Bug #1029068

Hi,

Just noticed at least one of my packages¹ got also hit by this one:

Error: fatal: Unable to create temporary file 
'/srv/scratch/qa.debian.org/vcswatch/c/claws-mail/objects/pack/tmp_idx_XX': 
No space left on device fatal: index-pack failed

Is this fixable or just a temporary server issue?
In case of the former, can I help to fix this somehow?

best regards,

¹ https://qa.debian.org/cgi-bin/vcswatch?package=claws-mail
-- 
 Ricardo Mones
 http://people.debian.org/~mones
 «Not responsible for typographical errors.»

Bug#1065371: unable to disable bug-implicit-func for time64

[Guillem Jover]

On Sun, 2024-03-03 at 16:57:28 +0100, Matthias Klose wrote:
> On 03.03.24 16:46, Guillem Jover wrote:
> > On Sun, 2024-03-03 at 16:11:36 +0100, Matthias Klose wrote:
> > > I just filed another bug report for bc, together with the one for heimdal.
> > > 
> > > Please turn this off for a while, it's really harmful for the time64
> > > bootstrap.
> > 
> > This was added on request by Steve, to help with the time64 changes.
> > 
> > > When you turn it on again,
> > > 
> > >   - please provide an opt-out option.
> > 
> > This is a bug, which I should fix.
> > 
> > >   - turn it on on all architectures, so that everbody
> > > can reproduce the effects.
> > 
> > I'd be fine with that.
> > 
> > >   - before turning it on again, please do an archive wide
> > > test rebuild and file bug reports for it.
> > 
> > My impression is that this was done as part of the time64 checks? If
> > not, and the consensus is to disable the flag, I'm very unlikely to
> > drive this, and someone else will need to do those rebuilds and post
> > results.
> 
> I can do that, but we will need a stable dpkg version and a dpkg upload
> providing that setting on amd64 without time64 set. Then I'll ask Lucas for
> two test rebuilds (at this stage, that would be testing).

> Doing test rebuilds with time64 enabled on testing doesn't make sense for
> now, and unstable is too unstable.

Hmm, I'm not sure I understand what you are asking here, so let me try
to rephrase, you'd like to see:

  - a dpkg 1.22.6 upload for unstable to the Debian archive with the
bug-implicit-func unconditionally set?
  - a dpkg 1.21.x version out-of-archive with the bug-implicit-func
support  backported and also enabled by default?

For the former you should be able to do that already by setting the
flag to enable via DEB_BUILD_OPTIONS with the version already in sid,
if you don't want time64 then you can also disable that there. The
latter I don't understand, so perhaps I interpreted that incorrectly
from what you said.

> > I think making the opt-out functional might be enough to help with
> > this, and I could upload a fix later today, which would not disarm
> > this safety net for the time64 transition. But at this point I don't
> > mind either way, and if people prefer disabling the warning then I can
> > do that instead.
> 
> at least for heimdal, three people spent several hours looking for the cause
> of the failure. I'm not sure we want these kind of delays for the
> transition.

While that's unfortunate, I think that might be better than silently
letting ABI breakage through due to the missing Werror flag.

Thanks,
Guillem

Bug#1065383: O: xf86-input-wacom -- X.Org X server -- Wacom input driver

[Boyuan Yang]

Package: wnpp
Control: affects -1 + src:xf86-input-wacom
X-Debbugs-Cc: xf86-input-wa...@packages.debian.org
Severity: normal

I intend to orphan the xf86-input-wacom package since I no longer
use Wacom devices.

The package description is:
 This package provides the X.Org driver for Wacom tablet devices.

Thanks,
Boyuan Yang


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

Bug#1057562: closed by Debian FTP Masters (reply to Jeremy Bícha ) (Bug#1057562: fixed in gcr4 4.2.0-2)

[Jeremy Bícha]

Control: severity -1 important
Control: affects -1 src:gcr

On Fri, Mar 1, 2024 at 6:36 AM Santiago Vila  wrote:
> > Ignore build test failures on s390x (Closes: #1057562)
>
> This is wrong for several reasons.
>
> - The bug report did not say anything about s390x.

s390x is the only architecture where the flakiness of the gcr:gck /
object build test is severe enough to unreasonably interfere with
timely building of gcr & gcr4.

Debian is full of packages where the build tests and autopkgtests are
flaky enough to be disruptive to someone expecting 100% pass rates.
There is currently no one on the Debian GNOME team with the time to
investigate and properly fix these issues.

The occasional failure is enough to remind us of this issue. I don't
think it's helpful to just disable the test since it may disguise a
real problem that someone can work on once they get sufficiently
annoyed by the issue. Also, it may be important to recognize if the
failure rate for this test on official buildds increases
significantly. The failure rate did increase on s390x but we don't
really treat s390x as a supported Desktop architecture and don't have
capacity to spend much time dealing with s390x.

I am demoting this bug because it is a valid bug, but also not severe
enough to get gcr excluded from Debian Testing.

Thank you,
Jeremy Bícha

Bug#1065382: trap int3 ip:7fed77a24587 sp:7ffc8e859b40 error:0 in libglib-2.0.so.0.7800.4[7fed779e0000+99000]

[Harald Dunkel]

Package: libglib2.0-0t64
Version: 2.78.4-2.1+b1

I got a few messages in kern.log:

2024-03-03T17:10:55.375204+01:00 cecil kernel: traps: at-spi-bus-laun[2238] 
trap int3 ip:7f52523f5587 sp:7ffded761730 error:0 in 
libglib-2.0.so.0.7800.4[7f52523b1000+99000]
2024-03-03T17:22:53.095180+01:00 cecil kernel: traps: at-spi-bus-laun[23272] 
trap int3 ip:7fed77a24587 sp:7ffc8e859b40 error:0 in 
libglib-2.0.so.0.7800.4[7fed779e+99000]
2024-03-03T17:24:13.153221+01:00 cecil kernel: traps: xdg-desktop-por[23404] 
trap int3 ip:7f7c51093587 sp:7ffd231baf30 error:0 in 
libglib-2.0.so.0.7800.4[7f7c5104f000+99000]
2024-03-03T17:24:13.207256+01:00 cecil kernel: traps: xdg-desktop-por[23457] 
trap int3 ip:7f2f6aa79587 sp:7ffdbf96c360 error:0 in 
libglib-2.0.so.0.7800.4[7f2f6aa35000+99000]
2024-03-03T17:26:04.761329+01:00 cecil kernel: traps: at-spi-bus-laun[24107] 
trap int3 ip:7f9da8a36587 sp:7ffe756825b0 error:0 in 
libglib-2.0.so.0.7800.4[7f9da89f2000+99000]
2024-03-03T17:26:29.769213+01:00 cecil kernel: traps: xdg-desktop-por[24101] 
trap int3 ip:7f4faaaea587 sp:7ffca0af3c30 error:0 in 
libglib-2.0.so.0.7800.4[7f4f6000+99000]
2024-03-03T17:26:29.783223+01:00 cecil kernel: traps: xdg-desktop-por[24106] 
trap int3 ip:7f7275a6c587 sp:7ffce2b87940 error:0 in 
libglib-2.0.so.0.7800.4[7f7275a28000+99000]

Platform is amd64.


Regards

Harri

Bug#1010751: clone: handle -b optional branch specification in VCS-Git

[Guido Günther]

Hi,
On Thu, Feb 29, 2024 at 10:49:32PM +0100, Nicolas Boulenguez wrote:
> Package: git-buildpackage
> Followup-For: Bug #1010751
> 
> Ping?

I'll have a look over the next days (I missed your last update).
Cheers,
 -- Guido

Bug#1065381: O: kupfer -- fast and lightweight desktop summoner/launcher

[Boyuan Yang]

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

I intend to orphan the kupfer package.

The package description is:
 Kupfer is a summoner/launcher in the style of Quicksilver or GNOME Do. It
 can search and browse your files, launch desired applications and object you
 need in a quicker way.
 .
 Kupfer is written in Python 3 and has a flexible architecture based on plugins
 to extend its features.

Thanks,
Boyuan Yang


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

Bug#1065380: ausweisapp2 FTBFS with pcsc-lite 2.0.2

[John Paul Adrian Glaubitz]

Hi Adrian,

On Sun, 2024-03-03 at 18:13 +0200, Adrian Bunk wrote:
> https://buildd.debian.org/status/logs.php?pkg=ausweisapp2=2.1.0-1
> 
> ...
> /<>/src/card/pcsc/PcscUtils.h:112:46: error: 
> ‘SCARD_E_UNKNOWN_RES_MNG’ was not declared in this scope; did you mean 
> ‘SCARD_E_UNKNOWN_RES_MSG’?
>   112 | Scard_E_Unknown_Res_Mng = 
> returnCode(SCARD_E_UNKNOWN_RES_MNG), /**< An unrecognized error code 
> was returned from a layered component. */
>   |  ^~~
> ...
> 
> 
> This is not a regression in the new ausweisapp2 upload,
> but due to a change in pcsc-lite 2.0.2 (maintainer Cc'ed):
> 
> https://salsa.debian.org/rousseau/PCSC/-/commit/65f9b610138c8a4a5563d0332120f684682e0237
> "Fix typo in (unused) error code SCARD_E_UNKNOWN_RES_MSG"

I've already seen that and also notified upstream. He is also now CC'ed here.

Adrian

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

Bug#1061155: closed by Debian FTP Masters (reply to Georges Khaznadar ) (Bug#1061155: fixed in cron 3.0pl1-186)

[Georges Khaznadar]

Jonathan H N Chin a écrit :
> Since there is an existing "standard" for crontab error reporting
> ( check_error() diagnostic + non-zero exit ), I am suggesting
> not inventing a new one ( warning message + zero exit ).

Looks fine; I shall use check_error() in the future release (3.0pl1-187)

Best regards,   Georges.



signature.asc
Description: PGP signature

Bug#1065380: ausweisapp2 FTBFS with pcsc-lite 2.0.2

[Adrian Bunk]

Source: ausweisapp2
Version: 2.0.3-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Ludovic Rousseau 

https://buildd.debian.org/status/logs.php?pkg=ausweisapp2=2.1.0-1

...
/<>/src/card/pcsc/PcscUtils.h:112:46: error: 
‘SCARD_E_UNKNOWN_RES_MNG’ was not declared in this scope; did you mean 
‘SCARD_E_UNKNOWN_RES_MSG’?
  112 | Scard_E_Unknown_Res_Mng = returnCode(SCARD_E_UNKNOWN_RES_MNG),  
   /**< An unrecognized error code was returned from a layered component. */
  |  ^~~
...


This is not a regression in the new ausweisapp2 upload,
but due to a change in pcsc-lite 2.0.2 (maintainer Cc'ed):

https://salsa.debian.org/rousseau/PCSC/-/commit/65f9b610138c8a4a5563d0332120f684682e0237
"Fix typo in (unused) error code SCARD_E_UNKNOWN_RES_MSG"

Bug#1062407: liblopsub: NMU diff for 64-bit time_t transition

[Andre Noll]

On Fri, Mar 01, 05:37, Steve Langasek wrote:

> Please find attached a final version of this patch for the time_t
> transition.  This patch is being uploaded to unstable.
> 
> Note that this adds a versioned build-dependency on dpkg-dev, to guard
> against accidental backports with a wrong ABI.

Applied. Since the previous version was applied and made public
last month, I've reverted that patch, applied this final version and
squashed the two new commits into one.

Below it what I've just applied. The patch looks different to what
you've sent, but the resulting tree is identical. Please let me know
if you're OK with the commit message.

Thanks
Andre
---
commit b156a0cabd42582e9c430ae4a284f8815746914e
Author: Steve Langasek 
Date:   Sun Mar 3 16:47:53 2024 +0100

debian: Final version of 64-bit time_t transition.

This partially reverts reverts commit b4d4de17a5c8, replacing it with
the version that has been uploaded to unstable.

It adds a versioned build-dependency on dpkg-dev to guard against
accidental backports with a wrong ABI.

Signed-off-by: Andre Noll 

diff --git a/debian/changelog b/debian/changelog
index 44bbaeb..53995e3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,9 @@
-liblopsub (1.0.4-1.1) experimental; urgency=medium
+liblopsub (1.0.4-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
-  * Rename libraries for 64-bit time_t transition.
+  * Rename libraries for 64-bit time_t transition.  Closes: #1062407
 
- -- Steve Langasek   Thu, 01 Feb 2024 09:30:36 +
+ -- Steve Langasek   Fri, 01 Mar 2024 05:37:06 +
 
 liblopsub (1.0.4-1) unstable; urgency=low
 
diff --git a/debian/control b/debian/control
index fe135b9..f488fe2 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: liblopsub
 Section: libdevel
 Priority: optional
 Maintainer: Andre Noll 
-Build-Depends: m4, flex, debhelper (>= 10.0)
+Build-Depends: dpkg-dev (>= 1.22.5), m4, flex, debhelper (>= 10.0)
 Standards-Version: 4.3.0
 Homepage: http://people.tuebingen.mpg.de/maan/lopsub
 Vcs-Browser: http://git.tuebingen.mpg.de/lopsub.git
diff --git a/debian/liblopsub1t64.install b/debian/liblopsub1t64.install
deleted file mode 100644
index 6234859..000
--- a/debian/liblopsub1t64.install
+++ /dev/null
@@ -1,2 +0,0 @@
-debian/tmp/usr/share/man/man7/*
-debian/tmp/usr/lib/*/liblopsub.so.*
diff --git a/debian/liblopsub1t64.lintian-overrides 
b/debian/liblopsub1t64.lintian-overrides
deleted file mode 100644
index bac78b9..000
--- a/debian/liblopsub1t64.lintian-overrides
+++ /dev/null
@@ -1 +0,0 @@
-liblopsub1t64: package-name-doesnt-match-sonames liblopsub1
-- 
Max Planck Institute for Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

Bug#1065371: unable to disable bug-implicit-func for time64

[Matthias Klose]

[CCing Lucas]

On 03.03.24 16:46, Guillem Jover wrote:

Hi!

On Sun, 2024-03-03 at 16:11:36 +0100, Matthias Klose wrote:

Control: severity -1 serious



I just filed another bug report for bc, together with the one for heimdal.

Please turn this off for a while, it's really harmful for the time64
bootstrap.


This was added on request by Steve, to help with the time64 changes.


When you turn it on again,

  - please provide an opt-out option.


This is a bug, which I should fix.


  - turn it on on all architectures, so that everbody
can reproduce the effects.


I'd be fine with that.


  - before turning it on again, please do an archive wide
test rebuild and file bug reports for it.


My impression is that this was done as part of the time64 checks? If
not, and the consensus is to disable the flag, I'm very unlikely to
drive this, and someone else will need to do those rebuilds and post
results.


I can do that, but we will need a stable dpkg version and a dpkg upload 
providing that setting on amd64 without time64 set. Then I'll ask Lucas 
for two test rebuilds (at this stage, that would be testing).


Doing test rebuilds with time64 enabled on testing doesn't make sense 
for now, and unstable is too unstable.



I think making the opt-out functional might be enough to help with
this, and I could upload a fix later today, which would not disarm
this safety net for the time64 transition. But at this point I don't
mind either way, and if people prefer disabling the warning then I can
do that instead.


at least for heimdal, three people spent several hours looking for the 
cause of the failure. I'm not sure we want these kind of delays for the 
transition.


Matthias

Bug#1065371: unable to disable bug-implicit-func for time64

[Guillem Jover]

Hi!

On Sun, 2024-03-03 at 16:11:36 +0100, Matthias Klose wrote:
> Control: severity -1 serious

> I just filed another bug report for bc, together with the one for heimdal.
> 
> Please turn this off for a while, it's really harmful for the time64
> bootstrap.

This was added on request by Steve, to help with the time64 changes.

> When you turn it on again,
> 
>  - please provide an opt-out option.

This is a bug, which I should fix.

>  - turn it on on all architectures, so that everbody
>can reproduce the effects.

I'd be fine with that.

>  - before turning it on again, please do an archive wide
>test rebuild and file bug reports for it.

My impression is that this was done as part of the time64 checks? If
not, and the consensus is to disable the flag, I'm very unlikely to
drive this, and someone else will need to do those rebuilds and post
results.


I think making the opt-out functional might be enough to help with
this, and I could upload a fix later today, which would not disarm
this safety net for the time64 transition. But at this point I don't
mind either way, and if people prefer disabling the warning then I can
do that instead.

Thanks,
Guillem

Bug#1065230: ITA three more Python packages

[Peter Pentchev]

package wnpp
retitle 1065150 ITA: pymdown-extensions -- Extension pack for Python Markdown
owner 1065150 !
retitle 1065230 ITA: python-regex -- alternative regular expression module 
(Python 3)
owner 1065230 !
retitle 1065251 ITA: python-click -- Wrapper around optparse for command line 
utilities - documentation
owner 1065251 !
thanks

I intend to maintain these packages within the Debian Python packaging team.

G'luck,
Peter

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


signature.asc
Description: PGP signature

Bug#1065360: libopencv-dev: dependency issues, can't install

[Linus Lüssing]

Ok, while apt-get wasn't able to resolve the dependencies,
aptitude was to able to find a solution to simply install
libopencv-dev and this seems to confirm that it's an issue with the
time_t migration, I think?

```
Start-Date: 2024-03-03  16:13:08
Requested-By: user (1000)
Install: libevent-pthreads-2.1-7:amd64 (2.1.12-stable-8, automatic), 
libgl2ps1.4:amd64 (1.4.2+dfsg1-2, automatic), libcharls2:amd64 (2.4.2-2+b1, 
automatic), libexif-dev:amd64 (0.6.24-1+b1, automatic), python3.12:amd64 
(3.12.2-4, automatic), libgeotiff5:amd64 (1.7.1-5, automatic), 
liburiparser1:amd64 (0.9.7+dfsg-2+b1, automatic), libgdal34t64:amd64 
(3.8.4+dfsg-3, automatic), libopencv-shape406t64:amd64 (4.6.0+dfsg-13.1, 
automatic), libamd-comgr2:amd64 (6.0+git20231212.4510c28+dfsg-3, automatic), 
libtesseract5:amd64 (5.3.4-1, automatic), libopencv-videoio-dev:amd64 
(4.6.0+dfsg-13.1, automatic), libopencv-objdetect-dev:amd64 (4.6.0+dfsg-13.1, 
automatic), librdmacm1t64:amd64 (50.0-2, automatic), libxerces-c3.2t64:amd64 
(3.2.4+debian-1.2, automatic), gdal-plugins:amd64 (3.8.4+dfsg-3, automatic), 
libopencv-superres-dev:amd64 (4.6.0+dfsg-13.1, automatic), libaec0:amd64 
(1.1.2-1, automatic), libarmadillo12:amd64 (1:12.6.7+dfsg-1, automatic), 
libopencv-contrib-dev:amd64 (4.6.0+dfsg-13.1, automatic), opencv-data:amd64 
(4.6.0+dfsg-13.1, automatic), libmunge2:amd64 (0.5.15-3+b1, automatic), 
libpoppler-cpp0t64:amd64 (22.12.0-2.2, automatic), libwebpdecoder3:amd64 
(1.3.2-0.4, automatic), libamdhip64-5:amd64 (5.2.3-13, automatic), 
libopencv-features2d406t64:amd64 (4.6.0+dfsg-13.1, automatic), 
libpoppler126t64:amd64 (22.12.0-2.2, automatic), libibverbs1:amd64 (50.0-2, 
automatic), libwebp-dev:amd64 (1.3.2-0.4, automatic), 
libopencv-imgcodecs-dev:amd64 (4.6.0+dfsg-13.1, automatic), mysql-common:amd64 
(5.8+1.1.0, automatic), libpython3.12-minimal:amd64 (3.12.2-4, automatic), 
libopencv-imgcodecs406t64:amd64 (4.6.0+dfsg-13.1, automatic), 
libnetcdf19t64:amd64 (1:4.9.2-5, automatic), liblerc-dev:amd64 (4.0.0+ds-4+b1, 
automatic), libtiffxx6:amd64 (4.5.1+git230720-4, automatic), 
libopencv-video406t64:amd64 (4.6.0+dfsg-13.1, automatic), libfreexl1:amd64 
(2.0.0-1+b1, automatic), libopenexr-dev:amd64 (3.1.5-5.1+b1, automatic), 
libsuperlu6:amd64 (6.0.1+dfsg1-1+b1, automatic), libtcl8.6:amd64 
(8.6.14+dfsg-1, automatic), libopencv-objdetect406t64:amd64 (4.6.0+dfsg-13.1, 
automatic), libminizip1t64:amd64 (1:1.3.dfsg-3.1, automatic), 
libkmldom1t64:amd64 (1.3.0-12, automatic), libopencv-video-dev:amd64 
(4.6.0+dfsg-13.1, automatic), liblept5:amd64 (1.82.0-3+b3, automatic), 
libjbig-dev:amd64 (2.1-6.1+b1, automatic), libgphoto2-dev:amd64 (2.5.31-2.1, 
automatic), libopencv-shape-dev:amd64 (4.6.0+dfsg-13.1, automatic), 
libtk8.6:amd64 (8.6.14-1, automatic), libopencv-calib3d406t64:amd64 
(4.6.0+dfsg-13.1, automatic), libopencv-photo406t64:amd64 (4.6.0+dfsg-13.1, 
automatic), libopencv-highgui406t64:amd64 (4.6.0+dfsg-13.1, automatic), 
libopencv-core406t64:amd64 (4.6.0+dfsg-13.1, automatic), libproj25:amd64 
(9.4.0-1, automatic), libcfitsio10t64:amd64 (4.3.1-1.1, automatic), 
libnettle8t64:amd64 (3.9.1-2.1, automatic), libnettle8t64:i386 (3.9.1-2.1, 
automatic), libarpack2t64:amd64 (3.9.1-1.1, automatic), libsocket++1:amd64 
(1.12.13+git20131030.5d039ba-1+b1, automatic), libraw1394-tools:i386 (2.1.2-2, 
automatic), libcurl3t64-gnutls:amd64 (8.6.0-3.2, automatic), 
libcurl3t64-gnutls:i386 (8.6.0-3.2, automatic), libkmlbase1t64:amd64 (1.3.0-12, 
automatic), libimath-dev:amd64 (3.1.9-3.1, automatic), 
libopencv-highgui-dev:amd64 (4.6.0+dfsg-13.1, automatic), liblzma-dev:amd64 
(5.6.0-0.2, automatic), libdc1394-dev:amd64 (2.2.6-4, automatic), 
libopencv-core-dev:amd64 (4.6.0+dfsg-13.1, automatic), librttopo1:amd64 
(1.1.0-3, automatic), libswscale-dev:amd64 (7:6.1.1-2, automatic), 
libopencv-stitching-dev:amd64 (4.6.0+dfsg-13.1, automatic), 
libhdf5-103-1t64:amd64 (1.10.10+repack-3.1, automatic), 
libopencv-stitching406t64:amd64 (4.6.0+dfsg-13.1, automatic), 
libdeflate-dev:amd64 (1.19-1, automatic), libopencv-ml406t64:amd64 
(4.6.0+dfsg-13.1, automatic), python3-numpy:amd64 (1:1.24.2-2, automatic), 
libopencv-videoio406t64:amd64 (4.6.0+dfsg-13.1, automatic), 
libopencv-contrib406t64:amd64 (4.6.0+dfsg-13.1, automatic), libodbcinst2:amd64 
(2.3.12-1+b1, automatic), libqhull-r8.0:amd64 (2020.2-6+b1, automatic), 
libblosc1:amd64 (1.21.5+ds-1+b1, automatic), libkmlengine1t64:amd64 (1.3.0-12, 
automatic), libhsakmt1:amd64 (5.7.0-1, automatic), 
libopencv-imgproc406t64:amd64 (4.6.0+dfsg-13.1, automatic), libzstd-dev:amd64 
(1.5.5+dfsg2-2, automatic), mariadb-common:amd64 (1:10.11.7-2, automatic), 
libspatialite8t64:amd64 (5.1.0-3, automatic), libfabric1:amd64 (1.17.0-3, 
automatic), libgeos3.12.1t64:amd64 (3.12.1-3, automatic), 
libopencv-dnn406t64:amd64 (4.6.0+dfsg-13.1, automatic), ibverbs-providers:amd64 
(50.0-2, automatic), libgdcm-dev:amd64 (3.0.22-2.1, automatic), 
libopencv-viz-dev:amd64 (4.6.0+dfsg-13.1, automatic), libgdcm3.0t64:amd64