Bug#1076968: closed by Debian FTP Masters (reply to Roman Lebedev ) (Bug#1076968: fixed in halide 18.0.0-2)

[Santiago Vila]

reopen 1076968
thanks

El 26/7/24 a las 8:54, Debian Bug Tracking System escribió:

This is an automatic notification regarding your Bug report
which was filed against the src:halide package:

#1076968: halide: FTBFS: 31 - mullapudi2016_reorder (Failed)

It has been closed by Debian FTP Masters  (reply to 
Roman Lebedev ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to Roman Lebedev 
) by
replying to this email.


Hi. I don't know what exactly you did in version 18.0.0-2 to fix
this bug, but I believe it didn't work.

I've put a failed build log for version 18.0.0-2 in the same directory
as before:

https://people.debian.org/~sanvila/build-logs/202407/

The original offer still holds:

If you could not reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

Thanks.

Bug#1077827: even with [[featureset]] name = 'rt' enable = false in config.local/defines.toml, linux-headers-*-common-rt is still getting built

[Johannes Schauer Marin Rodrigues]

Source: linux
Severity: normal

Hi,

steps to reproduce:

cat << END >> debian/config.local/defines.toml
[[featureset]]
name = 'rt'
enable = false
END

according to Ben [1] this should disable the rt build and it mostly does but
the package linux-headers-*-common-rt will still be built.

[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/957#note_507817


Thanks!

cheers, josch

Bug#1075396: Reopen as requested

[Santiago Vila]

close 1075396 1.7-1
thanks

El 3/8/24 a las 0:35, Khalid Aziz escribió:

Keeping this bug open as requested by originator. This bug will be closed once 
the package has been built successfully in a test rebuild.


Hi. Closing this bug was perfectly ok, because the package builds ok with 
gcc-14 indeed:

https://buildd.debian.org/status/package.php?p=prctl

All those build logs that you see in green are successful builds, and they
were made with gcc-14, because gcc-14 was already the default four days ago.

I believe you are interpreting the original message in a non-standard way.
Let me translate it to plain English:

The original report said this:

"Please keep the issue open until the package can be built in
a follow-up test rebuild".

Apparently, you interpreted this in the following way:

"Please keep this open until I actually rebuild it again in another test 
rebuild"

However, for mass bug filings like this one, the usual meaning is like this:

"Please keep this open until there is a release of the package in unstable
which builds ok with gcc-14".

i.e. the important thing here is not that the bug reporter himself has
to make another test rebuild before the bug may be closed, but the fact
that he *could* do it now and it would work.

And that's indeed the case: if he would test the package right now,
it would work, the successful build logs above prove it, so unless
I'm missing anything, the bug is fixed in unstable and it was
completely ok to close it four days ago using the changelog.

Thanks.

Bug#1077826: RFS: emacs-corfu/1.5-1 -- Completion Overlay Region FUnction in Emacs

[Xiyue Deng]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "emacs-corfu":

 * Package name : emacs-corfu
   Version  : 1.5-1
   Upstream contact : Daniel Mendler 
 * URL  : https://github.com/minad/corfu/
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/emacsen-team/emacs-corfu
   Section  : editors

The source builds the following binary packages:

  elpa-corfu - Completion Overlay Region FUnction in Emacs

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

  https://mentors.debian.net/package/emacs-corfu/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/emacs-corfu/emacs-corfu_1.5-1.dsc

Changes since the last upload:

 emacs-corfu (1.5-1) unstable; urgency=medium
 .
   * New upstream release

Regards,
-- 
Xiyue Deng

Bug#1020703: unifont-bin: Mark unifont-bin Multi-Arch: foreign?

[Samuel Thibault]

Hello,

Samuel Thibault, le dim. 25 sept. 2022 19:13:40 +0200, a ecrit:
> AIUI, the unifont-bin package behaves the same on any architecture since
> it only acts on font files in an architecture-independent way?  If so,
> could you mark it Multi-Arch: foreign, so that packages depending on it
> (e.g. bterm-unifont) can be cross-compiled?

Pinging on this, because unifont-bin is a build-dependency for the
debian installer, and since unifont build-depend on wxwidgets,
that uselessly makes wxwidgets an indirect build-dependency of
debian-installer.

Samuel

Bug#1053360: ITP: python-pytest-subprocess -- Pytest plugin to fake subprocess

[Yogeswaran Umasankar]

Control: retitle 1053360 ITP: python-pytest-subprocess -- Pytest plugin to fake 
subprocess
Control: owner 1053360 Yogeswaran Umasankar 

Hi,

I can assist you with this package. I can create a salsa repository for
this package under the Debian Python Team and grant you access, let me
know.

Cheers!
Yogeswaran.

Bug#1075396: Reopen as requested

[Khalid Aziz]

Keeping this bug open as requested by originator. This bug will be 
closed once the package has been built successfully in a test rebuild.

Bug#1077812: clapper: Please split library and development files to separate packages

[Johannes Schauer Marin Rodrigues]

Control: severity -1 important

Hi,

Quoting Arnaud Ferraris (2024-08-02 22:24:09)
> It's not strictly "breaking" anything, but I'm packaging tuba[1] which 
> is now built against libclapper, and I'd appreciate if this package could:
> * build-depend only on libclapper-dev (or whatever) rather than the 
> whole clapper package
> * depend only on libclapper rather than all of clapper
> * not have to explicitly build-depend on libclapper-dev's dependencies; 
> this is somehow orthogonal to the split, but without the split those 
> should be made dependencies of clapper itself, which is clearly 
> suboptimal (no need for a mere video player to pull a whole bunch of 
> gstreamer development files)
> 
> This would bring a (admittedly minor) improvement to bandwidth usage for 
> buildds and disk usage for users, not mentioning the fact that it aligns 
> with current practice in Debian.

you do not need to convince me with more than "tuba needs it". ;)

For the most of its existance, libclapper was only an internal implementation
which was not supposed to be used by others. This changed with the recent (2
weeks ago) upload of clapper 0.6. Since then, libclapper is supposed to be used
by others with the caveat that its API is still not deemed to be stable. Thus,
I did not yet split up the packaging into clapper and libclapper-dev with my
upload 2 weeks ago and was waiting if somebody even would need it because if
that's not the case, why bother FTP master and increase the package count in
the archive?

Now that tuba needs it, the split has to be done. If you want it be done
faster, feel free to submit a patch either via the BTS or as a MR against the
clapper packaging repository.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1077825: Duplicated desktop entries

[asciiwolf]

Package: trustedqsl
Version: 2.7.3-1

The desktop entries of TrustedQSL are duplicated. Both the entries run the same 
app with the same parameters.

The duplication is caused by the downstream (d/tqsl.desktop and 
d/trustedqsl.png) files that were added years ago and are still there along 
with the actual upstream files (org.arrl.trustedqsl.desktop and 
org.arrl.trustedqsl.png).

The outdated (d/tqsl.desktop and d/trustedqsl.png) files should be removed 
along with their d/trustedqsl.install rules.

Bug#1077768: ui-utilcpp: Will FTBFS with upcoming recode 3.7.14

[Santiago Vila]

severity 1077768 serious
thanks

Hello. After recode 3.7.14-1 is now available in unstable,
this bug becomes RC for trixie.

Note: recode has been built for all architectures, so you
could upload as soon as you have the fixed package ready.

Thanks.

Bug#1077765: openssh: can't be started by ssh.socket anymore

[Raphaël Halimi]

Le 02/08/2024 à 00:12, Colin Watson a écrit :

My best guess is that this has something to do with the refactoring of
sshd into a listener binary and a per-session binary, which touched the
re-exec path that's also involved in socket activation.  I'll try to
figure it out, but it may take a little while.

I think we should probably also add an autopkgtest for the socket
activation case.  Since it's not the default and not otherwise
automatically tested right now, it's easy for it to break accidentally.


Dear maintainers,

I confirm that this new upload fixes the problem.

Thank you for acting so quickly ! :)

Regards,

--
Raphaël Halimi

Bug#1076236: python3-numpy: python3-numpy doesn't support cross-building well

[Dima Kogan]

Hi Timo.


> I'm not opposed to splitting the package per se, but I want to point
> out that long before I became NumPy maintainer, there used to be a
> separate python-numpy-dev package already, and I'd like to find out
> why it was discontinued and if the reason is still relevant before I
> go ahead with a new split.

Looking at version control I see there was a python-numpy-ext that was
transitional even at the start of the git history in 2007. Is that what
you're referring to? I don't see any other such packages in version
control.

I'm currently implementing the split, to see what that would look like,
and to confirm that it would solve the issues I'd like it to solve.
Would it be true to say that you're planning to push numpy 2.0 into
Debian soon-ish? If so, it would be good to do this package split (if we
proceed with that) at the same time.

So I'm experimenting on my local machine, and when I get something
that's functoinal, I'll report back here to talk about merging.

Thank you!

Bug#1077824: Ubuntu bug link

[Florent 'Skia' Jacquet]

The issue is tracked in Ubuntu in the following bug: 
https://bugs.launchpad.net/debian/+source/python-amqplib/+bug/2075183

Bug#1076350: May be related

[Bastien Roucariès]

Hi

Can this bug could be due to libuv

According to 
https://lists.archlinux.org/pipermail/arch-ports/2018-November/000839.html 
thread

Did you try to recompile without  --shared-libuv  ?

Bastien

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

Bug#1074976: fweb: ftbfs with GCC-14

[Preuße]

On 03.07.2024 14:27, Matthias Klose wrote:

Hi Yann,


The package fails to build in a test rebuild on at least amd64 with
gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The
severity of this report will be raised before the trixie release.

Here are the first two patches in case you are interested. They solve a 
few issues, but of course not all.


In 2023 version 1.70 was released, not sure if it makes sense to have a 
look at that version.


Hilmar
--
sigfault

--- fweb-1.62.orig/Web/configure
+++ fweb-1.62/Web/configure
@@ -614,7 +614,7 @@
 cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && 
test -s conftest; then
   ac_cv_prog_cc_works=yes
--- fweb-1.62.orig/Web/ftangle.c
+++ fweb-1.62/Web/ftangle.c
@@ -1402,7 +1402,7 @@
 
 static boolean is_label= NO;
 static boolean should_continue= NO;
-static continuation_line= NOT_CONTINUATION;
+static int continuation_line= NOT_CONTINUATION;
 
 static STMT_LBL stmt_num[50];
 
--- fweb-1.62.orig/Web/ftangle.web
+++ fweb-1.62/Web/ftangle.web
@@ -460,7 +460,7 @@
 /* Various flags help \Fortran\ out. */
 static boolean is_label = NO;
 static boolean should_continue = NO;
-static continuation_line = NOT_CONTINUATION;
+static int continuation_line = NOT_CONTINUATION;
 
 static STMT_LBL stmt_num[50]; /* Archaic; for numbering
|do|s in \Fortran. Should use \Ratfor\ instead. */


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1015936: forward patches

[Nicholas D Steeves]

forwarded 1015936 
https://nmbug.notmuchmail.org/nmweb/show/20240802211048.1840273-3-sten%40debian.org
forwarded 1029190
https://nmbug.notmuchmail.org/nmweb/show/20240802211048.1840273-3-sten%40debian.org


signature.asc
Description: PGP signature

Bug#1077824: python3-amqplib: Produced binary package is Python2 only

[Florent 'Skia' Jacquet]

Package: python3-amqplib
Version: 1.0.2-4
Severity: serious
Justification: 5p
X-Debbugs-Cc: florent.jacq...@canonical.com

The `python3-amqplib/1.0.2-4` package build is broken: it's missing a magical 
2to3 step.

Using it leads to that kind of traceback:
```
  File "/usr/lib/python3/dist-packages/amqplib/client_0_8/connection.py", line 
96, in __init__
login_response.write_table({'LOGIN': userid, 'PASSWORD': password})
  File "/usr/lib/python3/dist-packages/amqplib/client_0_8/serialization.py", 
line 370, in write_table
table_data.write_shortstr(k)
  File "/usr/lib/python3/dist-packages/amqplib/client_0_8/serialization.py", 
line 338, in write_shortstr
if isinstance(s, unicode):
 ^^^
NameError: name 'unicode' is not defined
```

A very quick test to check the Python 3 compatibility is the following:

$ grep 'isinstance.*unicode' 
/usr/lib/python3/dist-packages/amqplib/client_0_8/serialization.py
if isinstance(s, unicode):
if isinstance(s, unicode):
if isinstance(v, unicode):

Those `unicode` invokations should have been converted to `str` during the 
build process, which worked beforehand, but has been broken. I've detected this 
bug on Ubuntu, and it worked correctly at the time of Noble, and has only been 
broken in Oracular.

I did not investigate much further, but a local manual build also produces a 
broken binary package. From what I've seen in the launchpad build logs, 
previous version were installing python3-lib2to3 during the build, and this is 
not the case anymore. I guess it would be similar in Debian's infrastructure.


A quick workaround for anyone affected is to run the following:
sudo 2to3 -w /usr/lib/python3/dist-packages/amqplib/client_0_8/*


-- System Information:
Debian Release: trixie/sid
  APT prefers oracular
  APT policy: (500, 'oracular'), (400, 'oracular-proposed'), (200, 
'noble-updates'), (200, 'noble'), (200, 'jammy-updates'), (200, 'jammy')
Architecture: amd64 (x86_64)

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

Versions of packages python3-amqplib depends on:
ii  python3  3.12.3-0ubuntu1

python3-amqplib recommends no packages.

Versions of packages python3-amqplib suggests:
pn  python-amqplib-doc  

-- no debconf information

Bug#1057656: firmware-amd-graphics: No display on Raphael in 20230625-1

[Jesse Rhodes]

Hi,

This appears to be fixed since the update to 20240709-1.

sney

Bug#996689: Update link to migration guide

[Martin Dosch]

It seems the previously linked migration guide is dead, but I found 
another one: 
https://gnome.pages.gitlab.gnome.org/gtksourceview/gtksourceview5/porting-guide-3-to-4.html


signature.asc
Description: PGP signature

Bug#1077764: Ruling request on os-release specification implementation

[Helmut Grohne]

Hi Luca,

On Fri, Aug 02, 2024 at 01:43:04AM +0100, Luca Boccassi wrote:
> 1) The os-release specification must be adhered to, and it must be
> possible to tell the difference between testing vs unstable, and each
> must be correctly identified by the respective metadata

Given the state of discussion, I think it is fairly evident that we do
not have consensus for the need to distinguish testing and unstable. We
have people arguing in favour and we have people arguing against that.
This is a point of disagreement.

> 2) Testing and unstable can continue to remain indistinguishable, and
> both be erroneously identified as trixie

Isn't there the third option of adhering to the os-release specification
without making testing and unstable distinguishable? I did not see this
ranked in your preference. Do you see it as even worse than the status
quo?

> Again you'll know better than me, but it seems to me rulings were made
> in the past that were along similar lines (eg: usrmerge) - there
> wasn't reviewable code there, no?

I think /usr-merge was quite different. The usrmerge package existed for
a long time before things to to the CTTE. The changes to debootstrap
were uploaded before things escalated to the CTTE another time and what
remained was basically a question of what defaults debootstrap should
have. In the case of os-release, the disagreement reached CTTE before
actual changes to the disputed status quo have been uploaded to unstable
and the available solution space is wider. Also the transition cost is
lower.

Keep in mind that our constitution says that you cannot be asked to work
(2.1) and in particular the CTTE cannot request work to be done either.
Instead, it can authorize a solution and require that developers do not
work against the chosen solution. Furthermore, the CTTE should select
among designs that have been proposed and "reasonably thoroughly
discussed" (6.3.5).  My perception is that your initial filing did not
meet this bar, but you later clarified your design and discussion is
ongoing.

> Sorry but I do not think that is an accurate representation. First of
> all, the implementation of the spec is bugged, period - it's not about
> being pedantic about it, it's about being completely incompatible: sid
> is identified as trixie, and that is just plain wrong, and there's no
> room for interpretation, no matter how one might try to bend it. You
> might say that you don't _care_ that the implementation is buggy, you
> might even say that it is worth, nay _good_ it to leave it buggy - but
> buggy it is, if I create a sid image, it will never in a million years
> be trixie, and yet it says it's trixie.

I think it has become abundantly clear that your view on this does not
represent consensus of discussion participants. It is not as black and
white as you paint it. Simon compared unstable to Ubuntu's proposed
pocket. It also happens that testing and unstable share the same pool
hierarchy and the vast majority of packages. On the other hand, Devuan
operates as an overlay repository to be added on top of a Debian
repository. I don't think it matters that Ubuntu's proposed is
implemented as a partial distribution overlaid onto another as that's
what other derivatives (that do update their os-release file) do as
well.

It would help if you could stop dismissing other people's views and
respectfully disagree with their views instead. Refer to Simon's reply
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#118 for more
details on this aspect.

> Secondly, I am not even sure what these conflicting requirements
> actually are? Could you please spell them out? If trixie was
> identified as trixie, and sid was identified as unstable, what
> compromise would be, er, compromised, precisely? Because the only
> practical objections I could find were based on the idea that
> implementations would be ugly or hard to maintain or so - as already
> mentioned, I am happy to relieve anybody else and take that hard and
> ugly maintenance burden for myself. What other actual problem would
> suddenly appear? What feature or advantage do we leave behind? How are
> things made worse for our users?

The devil is in the detail. Debian currently does not provide a simple
way to distinguish testing and unstable. As a result, some users have
opted to not rely on such differentiation and instead inspect particular
package versions for the features they are interested in. Others have
implemented heuristics to somehow tell testing and unstable apart as
they saw a need for doing so (that I still fail to see at this time).
Whilst you and others have presented code for telling testing and
unstable apart in multiple places, I am still having a hard time
figuring out why we had to tell them apart and in what way code would
behave differently for one or the other. If Debian were to differentiate
testing and unstable in a simple way, people would start relying on
that. That in turn (as laid out by Russ and Simon) would 

Bug#1064408: [PATCH] duplicate aliased diversions for DEP17

[Helmut Grohne]

Hi Roland,

On Fri, Aug 02, 2024 at 03:01:51PM +0200, Roland Clobus wrote:
> I've prepared a MR which takes a different approach.
> https://salsa.debian.org/live-team/live-build/-/merge_requests/359

Thank you for working on this matter.

> Since the support of live-build starts from bullseye, and symlinks are
> present since then, should using only '/usr/X' be sufficient?

The unfortunate answer is "no". dpkg-diversions apply to the path as
seen by the dpkg database only and are not affected by symlinks such as
/bin -> usr/bin. Even if the symlink moves /bin/hostname to
/usr/bin/hostname, as long as hostname is still named as /bin/hostname
in the hostname package, it can only be diverted via /bin/hostname. As
long as you want to support bullseye or bookworm, the diversions should
be duplicated.

> I was able to generate functional ISO images for bullseye, bookworm, trixie
> and sid.

Despite me claiming your MR to be buggy, this test result of yours is
plausible.

> Since the live-build scripts do no need an upgrade (they are used for fixed
> version) do I need the doubled diversion?

You convey a very crucial bit of information in this question. The
diversions (doubled or not) are only really needed for upgrading. If you
just create a chroot and then replace a few files normally owned some
package and you never intend to use the package manager again, the
benefit of using a diversion becomes questionable. It is not clear to me
whether you install or upgrade packages after setting up diversions. If
you do, you should keep and double diversions (as long as bookworm is
supported in live-build). If you do not, you may just overwrite the
files without doing any diversions.

> Also: do I need to update all shebangs from `/bin/sh` to `/usr/bin/sh` as
> well?

Please don't. You already changed more places than I recommend to
change. What really needs to change is the placement of files in the
data.tar inside Debian binary packages (to eliminate aliasing problems).
As a result of this move, the diversions need to be duplicated. However,
accessing files can use either path and I recommend leaving such
references as is. We will forever rely on the aliasing links. For
instance, the dynamic loader explicitly uses an aliased path. Hence
there is little benefit in referencing files via their /usr paths.

For instance, `Chroot chroot "/bin/bash --login"` and `Check_package
host /sbin/fdisk fdisk` are still fully valid.

Would you reconsider my patch with this explanation?

Helmut

Bug#1077803: transition: recode

[Santiago Vila]

- How are binNMUs handled? Is the maintainer (me in this case) in charge
of requesting them (at appropriate times), or maybe there is some automated
procedure to trigger them?


It's documented on the wiki (linked from the transition page): 
https://wiki.debian.org/Teams/ReleaseTeam/Transitions (under "How transitions work 
in general")
TL;DR: the RT takes care.


Great, thanks. I actually had the above wiki page in a firefox tab but somehow 
I missed it:

[RT]: Schedules binNMUs for reverse dependencies that just need a rebuild

While we are at it, is the wording of this item ok?

[MTL]: Bumps all blocking bugs to RC.

Bug #1077768 is non-blocking because package is not in testing,
but now the affected package will FTBFS, so the bug also needs to be
raised to RC, which I will do after recode is built for all archs.

Thanks a lot.

Bug#1077812: clapper: Please split library and development files to separate packages

[Arnaud Ferraris]

Hi,

Le 02/08/2024 à 21:51, Johannes Schauer Marin Rodrigues a écrit :

Hi,

Quoting Arnaud Ferraris (2024-08-02 18:36:23)

Could you please split this package so the shared libraries, development files
and gobject-introspection data are all shipped in separate packages?


is this a request out of necessity? Is the current packaging breaking something
for you?


It's not strictly "breaking" anything, but I'm packaging tuba[1] which 
is now built against libclapper, and I'd appreciate if this package could:
* build-depend only on libclapper-dev (or whatever) rather than the 
whole clapper package

* depend only on libclapper rather than all of clapper
* not have to explicitly build-depend on libclapper-dev's dependencies; 
this is somehow orthogonal to the split, but without the split those 
should be made dependencies of clapper itself, which is clearly 
suboptimal (no need for a mere video player to pull a whole bunch of 
gstreamer development files)


This would bring a (admittedly minor) improvement to bandwidth usage for 
buildds and disk usage for users, not mentioning the fact that it aligns 
with current practice in Debian.


Best regards,
Arnaud

[1] https://tracker.debian.org/pkg/tuba
[2] 
https://salsa.debian.org/DebianOnMobile-team/tuba/-/blob/debian/latest/debian/control?ref_type=heads#L17

Bug#1077671:

[Andreas Hasenack]

Attached is the patch I'm proposing for ubuntu. Let me know if you
would like a Salsa PR as well.
From d454f62c73e069199e4a706dcd50be580f06e5c7 Mon Sep 17 00:00:00 2001
From: Sam James 
Date: Sun, 5 Nov 2023 22:17:02 +
Subject: [PATCH] libpkgconf: fix -Walloc-size

GCC 14 introduces a new -Walloc-size included in -Wextra which gives:
```
libpkgconf/personality.c:260:11: warning: allocation of insufficient size '1' for type 'pkgconf_cross_personality_t' {aka 'struct pkgconf_cross_personality_'} with size '48' [-Walloc-size]
libpkgconf/queue.c:46:33: warning: allocation of insufficient size '1' for type 'pkgconf_queue_t' {aka'struct pkgconf_queue_'} with size '16' [-Walloc-size]
libpkgconf/client.c:164:33: warning: allocation of insufficient size '1' for type 'pkgconf_client_t' {aka 'struct pkgconf_client_'} with size '120' [-Walloc-size]
libpkgconf/path.c:105:14: warning: allocation of insufficient size '1' for type 'pkgconf_path_t' {aka 'struct pkgconf_path_'} with size '24' [-Walloc-size]
libpkgconf/path.c:237:22: warning: allocation of insufficient size '1' for type 'pkgconf_path_t' {aka 'struct pkgconf_path_'} with size '24' [-Walloc-size]
libpkgconf/tuple.c:239:34: warning: allocation of insufficient size '1' for type 'pkgconf_tuple_t' {aka 'struct pkgconf_tuple_'} with size '24' [-Walloc-size]
libpkgconf/dependency.c:133:13: warning: allocation of insufficient size '1' for type 'pkgconf_dependency_t' {aka 'struct pkgconf_dependency_'} with size '44' [-Walloc-size]
libpkgconf/dependency.c:472:17: warning: allocation of insufficient size '1' for type 'pkgconf_dependency_t' {aka 'struct pkgconf_dependency_'} with size '44' [-Walloc-size]
libpkgconf/fragment.c:146:22: warning: allocation of insufficient size '1' for type 'pkgconf_fragment_t' {aka 'struct pkgconf_fragment_'} with size '24' [-Walloc-size]
libpkgconf/fragment.c:195:22: warning: allocation of insufficient size '1' for type 'pkgconf_fragment_t' {aka 'struct pkgconf_fragment_'} with size '24' [-Walloc-size]
libpkgconf/fragment.c:356:14: warning: allocation of insufficient size '1' for type 'pkgconf_fragment_t' {aka 'struct pkgconf_fragment_'} with size '24' [-Walloc-size]
libpkgconf/pkg.c:422:13: warning: allocation of insufficient size '1' for type 'pkgconf_pkg_t' {aka 'struct pkgconf_pkg_'} with size '188' [-Walloc-size]
libpkgconf/client.c:164:33: warning: allocation of insufficient size '1' for type 'pkgconf_client_t' {aka 'struct pkgconf_client_'} with size '224' [-Walloc-size]
libpkgconf/personality.c:260:11: warning: allocation of insufficient size '1' for type 'pkgconf_cross_personality_t' {aka 'struct pkgconf_cross_personality_'} with size '96' [-Walloc-size]
libpkgconf/dependency.c:133:13: warning: allocation of insufficient size '1' for type 'pkgconf_dependency_t' {aka 'struct pkgconf_dependency_'} with size '80' [-Walloc-size]
libpkgconf/dependency.c:472:17: warning: allocation of insufficient size '1' for type 'pkgconf_dependency_t' {aka 'struct pkgconf_dependency_'} with size '80' [-Walloc-size]
libpkgconf/path.c:105:14: warning: allocation of insufficient size '1' for type 'pkgconf_path_t' {aka 'struct pkgconf_path_'} with size '48' [-Walloc-size]
libpkgconf/path.c:237:22: warning: allocation of insufficient size '1' for type 'pkgconf_path_t' {aka 'struct pkgconf_path_'} with size '48' [-Walloc-size]
libpkgconf/queue.c:46:33: warning: allocation of insufficient size '1' for type 'pkgconf_queue_t' {aka 'struct pkgconf_queue_'} with size '32' [-Walloc-size]
libpkgconf/tuple.c:239:34: warning: allocation of insufficient size '1' for type 'pkgconf_tuple_t' {aka 'struct pkgconf_tuple_'} with size '48' [-Walloc-size]
libpkgconf/fragment.c:146:22: warning: allocation of insufficient size '1' for type 'pkgconf_fragment_t' {aka 'struct pkgconf_fragment_'} with size '48' [-Walloc-size]
libpkgconf/fragment.c:195:22: warning: allocation of insufficient size '1' for type 'pkgconf_fragment_t' {aka 'struct pkgconf_fragment_'} with size '48' [-Walloc-size]
libpkgconf/fragment.c:356:14: warning: allocation of insufficient size '1' for type 'pkgconf_fragment_t' {aka 'struct pkgconf_fragment_'} with size '48' [-Walloc-size]
libpkgconf/pkg.c:422:13: warning: allocation of insufficient size '1' for type 'pkgconf_pkg_t' {aka 'struct pkgconf_pkg_'} with size '360' [-Walloc-size]
```

The calloc prototype is:
```
void *calloc(size_t nmemb, size_t size);
```

So, just swap the number of members and size arguments to match the prototype, as
we're initialising 1 struct of size `sizeof(struct ...)`. GCC then sees we're not
doing anything wrong.

The only exception there is for argv which I fixed while at it.

Signed-off-by: Sam James 
---
 libpkgconf/argvsplit.c   | 2 +-
 libpkgconf/client.c  | 2 +-
 libpkgconf/dependency.c  | 4 ++--
 libpkgconf/fragment.c| 8 
 libpkgconf/path.c| 4 ++--
 libpkgconf/personality.c | 2 +-
 libpkgconf/pkg.c | 4 ++--
 libpkgconf/queue.c   | 2 +-
 libpkgconf/tuple.c   | 4 ++--
 9 

Bug#1077764: Ruling request on os-release specification implementation

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Fri, 2 Aug 2024 at 13:00, Simon McVittie  wrote:
>> 
>> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
>> > To further clarify why the status quo with
>> VERSION_CODENAME=trixie in > sid is really bad: it used to be
>> that if you had "debian" mentioned in > os-release but no other
>> version identifying fields, you knew you were > on testing OR
>> unstable and you'd have to deploy horrendous hacks to > attempt
>> and figure out which of the two it was really.
>> 
>> OK, I think this is progress:
>> 
>> What is the scenario / use-case in which it becomes necessary to
>> distinguish between those two suites?
>> 
>> To put that another way, what external piece of software needs to
>> change its behaviour, dependent on whether you are running
>> testing (of an unspecified datestamp) or unstable (of an
>> unspecified datestamp)?
>> 
>> Or perhaps you are thinking of a scenario in which a *person*
>> needs to change their behaviour, dependent on whether they are
>> running testing or unstable?

Luca> Are the examples I provided at:

Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43
Luca> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5

Not to me.
I read what I think is the examples you linked from both bug reports.
I didn't dig too far into the github links you provided though.
What I see from your mail is that people want to distinguish unstable
from testing and have created various hacks to do so.

What I do not see is a compelling explanation of why Debian as a project
wants to encourage that distinction.
I agree that people doing a thing is evidence that it has value to those
people.
But I do not think you provided an explanation of what that value is.

If it were easy to distinguish testing from unstable, why would I want
to do that?

--Sam

Bug#1077585: [DKIM] Bug#1077585: Stuck on blank window after the loading splash

[Ceppo]

On Thu, Aug 01, 2024 at 05:31:45AM GMT, Sebastiaan Couwenberg wrote:
> On 7/31/24 11:47 PM, Ceppo wrote:
> > 1. the VM uses Gnome and my physical machine doesn't,
>
> That's where you should looks for the problem.
>
> Chances are good Java apps only work correctly in common DEs like Gnome and
> KDE.

I think I understood the issue and found a solution.

It looks like many Java applcations don't work properly on a non-reparenting
window manager like the one I use, but they do if you pretend to be using a
reparenting one. The Arch Wiki suggests to set the _JAVA_AWT_WM_NONREPARENTING
environment variable to 1 if using JRE 8, or AWT_TOOLKIT=MToolkit for a later
version - but only the first one works for me, despite using JRE 17.
Alternatively, wmname [2] may be used to pretend to be using a supported window
manager [3]. I do not know how bad workarounds these are, though.


[1]: 

[2]: 
[3]: 


--
Ceppo


signature.asc
Description: PGP signature

Bug#1077823: elpa-ligature: Please drop transitional package fonts-nanum-coding from d/control

[Boyuan Yang]

Source: elpa-ligature
Version: 1+60+g5eb950a-3
Severity: normal

Dear Debian elpa-ligature package maintainer,

Please drop mentioning of fonts-nanum-coding from debian/control.
It is a transitional package, has been released in the past Debian
releases, and will be dropped soon.

Thanks,
Boyuan Yang


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

Bug#1077803: transition: recode

[Paul Gevers]

Hi,

On 02-08-2024 19:53, Santiago Vila wrote:

- How are binNMUs handled? Is the maintainer (me in this case) in charge
of requesting them (at appropriate times), or maybe there is some automated
procedure to trigger them?


It's documented on the wiki (linked from the transition page): 
https://wiki.debian.org/Teams/ReleaseTeam/Transitions (under "How 
transitions work in general")

TL;DR: the RT takes care.

- The only package which FTBFS (ui-utilcpp, filed as #1077768) is not 
currently

in testing. Does this mean that in this case the FTBFS bug should
not block the transition bug?


Correct.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1076236: python3-numpy: python3-numpy doesn't support cross-building well

[Timo Röhling]

Hi Dima,

* Dima Kogan  [2024-08-01 16:47]:

I THINK this is currently impossible, or at least I can't figure out a
set of Build-Depends that would achive this result. It maybe would be
enough to add a Multi-Arch tag, but it would be clearer to split the dev
stuff (*.h and *.pc) into a separate package, and that package should be
Multi-Arch:same.


Thinking about this some more, I'm fairly certain that splitting the
package is the correct way to do this because the -dev package shouldn't
require python3 to be installed, which is currently required by numpy.
Installing a foreign-architecture python3 requires qemu, so that's never
what we want.

Furthermore, some packages (like "mrcal", for instance) require numpy at
build-time for two purposes:

- Build-time code generation. This needs numpy:native
- Accessing numpy.pc to build the extension module. this needs
 numpy:foreign

So if we really wanted to make this work without splitting the current
python3-numpy package, it would need to be Multi-Arch:same AND be happy
installing only the native python3. This isn't obviously possible, and
even if it were, splitting the package would make this much clearer.

Unless I hear an objection or a better idea here, I'm going to implement
this, and propose a patch in a reply to this bug.
I'm not opposed to splitting the package per se, but I want to point 
out that long before I became NumPy maintainer, there used to be a 
separate python-numpy-dev package already, and I'd like to find out 
why it was discontinued and if the reason is still relevant before I 
go ahead with a new split.



Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#1077812: clapper: Please split library and development files to separate packages

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Arnaud Ferraris (2024-08-02 18:36:23)
> The current "clapper" package includes not only the software and its data
> files, but also several shared libraries, gobject-introspection data and
> development files (C headers, pkg-config files...).
> 
> This implies any software linked against libclapper, for example, will have to
> depend on the full "clapper" package instead of just the library. Likewise, 
> any
> user of this software will also have all the development files installed, 
> which
> are only necessary for actually developing with libclapper.
> 
> Additionally, the development files also need the development files for
> gstreamer-plugins-base and several other libs, which should therefore be
> dependencies for this package.
> 
> Could you please split this package so the shared libraries, development files
> and gobject-introspection data are all shipped in separate packages?

is this a request out of necessity? Is the current packaging breaking something
for you?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1077470: python3-lsprotocol: Request for backport / Intend to backport

[Niels Thykier]

Arto Jantunen:

Niels Thykier  writes:

Please give me a heads up when you uploaded it to backports NEW. Then I will
upload `python3-pygls` to backports well, which is the last piece that
I need.


I just uploaded the package and received the confirmation that it's in
NEW.



Thanks. I have uploaded `pygls`, so now we wait. :)

Best regards,
Niels

Bug#1077822: neatvnc: CVE-2024-42458

[Moritz Mühlenhoff]

Source: neatvnc
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for neatvnc.

CVE-2024-42458[0]:
| server.c in Neat VNC (aka neatvnc) before 0.8.1 does not properly
| validate the security type.

https://www.openwall.com/lists/oss-security/2024/08/02/1


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-42458
https://www.cve.org/CVERecord?id=CVE-2024-42458

Please adjust the affected versions in the BTS as needed.

Bug#1077821: node-elliptic: CVE-2024-42459 CVE-2024-42460 CVE-2024-42461

[Moritz Mühlenhoff]

Source: node-elliptic
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for node-elliptic.

CVE-2024-42459[0]:
| In the Elliptic package 6.5.6 for Node.js, EDDSA signature
| malleability occurs because there is a missing signature length
| check, and thus zero-valued bytes can be removed or appended.

CVE-2024-42460[1]:
| In the Elliptic package 6.5.6 for Node.js, ECDSA signature
| malleability occurs because there is a missing check for whether the
| leading bit of r and s is zero.

CVE-2024-42461[2]:
| In the Elliptic package 6.5.6 for Node.js, ECDSA signature
| malleability occurs because BER-encoded signatures are allowed.

All addressed by https://github.com/indutny/elliptic/pull/317

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-42459
https://www.cve.org/CVERecord?id=CVE-2024-42459
[1] https://security-tracker.debian.org/tracker/CVE-2024-42460
https://www.cve.org/CVERecord?id=CVE-2024-42460
[2] https://security-tracker.debian.org/tracker/CVE-2024-42461
https://www.cve.org/CVERecord?id=CVE-2024-42461

Please adjust the affected versions in the BTS as needed.

Bug#1077820: clickhouse: CVE-2024-6873

[Moritz Mühlenhoff]

Source: clickhouse
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for clickhouse.

CVE-2024-6873[0]:
| It is possible to crash or redirect the execution flow of the
| ClickHouse server process from an unauthenticated vector by sending
| a specially crafted request to the ClickHouse server native
| interface. This redirection is limited to what is available within a
| 256-byte range of memory at the time of execution, and no known
| remote code execution (RCE) code has been produced or exploited.
|  Fixes have been merged to all currently supported version of
| ClickHouse. If you are maintaining your own forked version of
| ClickHouse or using an older version and cannot upgrade, the fix for
| this vulnerability can be found in this commit 
| https://github.com/ClickHouse/ClickHouse/pull/64024 .

https://github.com/ClickHouse/ClickHouse/security/advisories/GHSA-432f-r822-j66f
https://github.com/ClickHouse/ClickHouse/pull/64024


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-6873
https://www.cve.org/CVERecord?id=CVE-2024-6873

Please adjust the affected versions in the BTS as needed.

Bug#1076008: qemu-system-ppc: Missing NIC ?

[Michael Tokarev]

Control: severity -1 normal


On Tue, 9 Jul 2024 15:34:03 +0300 Michael Tokarev  wrote:

09.07.2024 15:29, Christian Marillat пишет:
> On 09 juil. 2024 15:25, Michael Tokarev  wrote:
> 
>> 09.07.2024 15:23, Christian Marillat wrote:

>>> On 09 juil. 2024 13:18, Michael Tokarev  wrote:
>>> [...]
>>>
>> I don't know what "NIC support is missing" means.  Qemu can't be built
>> without support for networking.  The -nic option is obsolete for a long
>> time, that's true, but it works still.
> Missing network card support.

 You gave no additional information here.  I already read the same in your
 first email, and I can't understand it.  I also wrote back that the above
 command parameters works just fine on my system with qemu 9.0.0+ds-1.
 There's no need for this ping-pong, - if you want the issue to be fixed,
 you have to provide the information requested, instead of repeating the
 same information as before.
>>> I expect to see the same output with 1:8.2.5+ds-2 when qemu 9 return
>>> nothing.
>>
>> I'll keep this bug report hanging there for now, requesting for more info
>> about the original issue.  Unless such info will be available, I'll just
>> close it so it doesn't dusturb my work, - because in the way it now is,
>> it's useless.
> 
> Last time I'll report a bug against qemu. It's a shame.


Indeed it is a shame that you can't provide info requested 3 times.
Thank you for not filing more useless bug reports in the future.


So, almost a month has passed, and there's nothing in this bug report which
I can work with, I still have no idea what did you have in mind.

Lowering severity to normal at least - having "serious" severity with no
information to work with uselessly prevents migration to testing.

Thanks,

/mjt

Bug#1035620: New release 2024-07

[Martin]

On 2024-08-02 08:26, Matt Palmer wrote:
> On Thu, Aug 01, 2024 at 09:10:05PM +, Martin wrote:
>> are you OK with the new version and new upstream?
>> I'ld try my luck and upload then.
>
> I'm happy for you to adopt the package, if you're up for taking on
> permanent maintenance.  Otherwise, I'd like to be able to cast an eye
> over a diff before upload, just for paranoia's sake.

No, I don't want to adopt the package. If you are OK with it, I'ld
prepare a complete debdiff and attach it to this bug report. Not sure,
when. Maybe this weekend, depends very much on the weather :-)

Bug#756841: Seeing this in bullseye, bookworm, and trixie.

[Charles Curley]

Seeing this in bullseye, bookworm, and trixie. And other problems as
well.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#1075082: icon: ftbfs with GCC-14

[Mechtilde Stehmann]

Hello,

I uploaded a new version of icon (9.5.24a).

I built it in pbuilder and installed gcc 14.

I hope the issue will be fixed and noweb won't be removed.

kind regards
--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#994189: RFP: jellyfin-server -- The Free Software Media System

[Nicolas Peugnet]

On Wed, 17 Jul 2024 12:51:18 +0200 Petter Reinholdtsen  
wrote:> I had a look at the source package for jellyfin-server provided by

upstream, and the build dependencies were not sufficient to build the
source.  I installed nodejs and ran 'debuild', and the build imediately
stopped because 'dotnet' was missing.  I suspect this is the Visual
Studio compiler for C#, and that the first step will be to get the
source to build with xbuild from mono or some ohter free software
compiler.


Another possibility would be to try to integrate Ubuntu's packaging of 
dotnet (https://launchpad.net/ubuntu/+source/dotnet8) as it is finally 
free software now, but this won't probably be easy.


I wonder if an initiative to integrate this package in Debian has 
already emerged? I guess it will not be easy to maintain over time.

--
Nicolas Peugnet

Bug#1071827: mozc: Cannot find pristine tar commit for archive 'mozc_2.28.4715.102+dfsg.orig.tar.xz'

[Boyuan Yang]

notfound 1071827 2.28.4715.102+dfsg-2.2
close 1071827
thanks

On Sat, 25 May 2024 17:45:49 +0900 Kentaro HAYASHI  wrote:
> Source: mozc
> Version: 2.28.4715.102+dfsg-2.2
> Severity: normal
> X-Debbugs-Cc: ken...@xdump.org
> 
> Dear Maintainer,
> 
>    * What led up to the situation?
> 
>    When try to build package from git repository, it 
>    can't be built because of missing pristine tar commmit.
> 
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>    $ git clone https://salsa.debian.org/debian/mozc
>    $ cd mozc
>    $ LANG=C gbp buildpackage
> 
> 
>    * What was the outcome of this action?
> 
>  $ LANG=C gbp buildpackage
>  gbp:info: Creating /debian/mozc_2.28.4715.102+dfsg.orig.tar.xz
>  gbp:error: Cannot find pristine tar commit for archive
>  'mozc_2.28.4715.102+dfsg.orig.tar.xz'
> 
>    * What outcome did you expect instead?
> 
>    pristine-tar branch is updated and no missing 
>    pristine tar commit for archive
>    'mozc_2.28.4715.102+dfsg.orig.tar.xz'.
> 
>    It also succeeds to build gbp buildpackage
>    mozc package without error.

I have pushed the updates to the pristine-tar branch. Closing
this bug accordingly.

Thanks,
Boyuan Yang


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

Bug#1077819: python3-xopen: xopen dist-info declares a dependency on isal for x86_6

[Diane Trout]

Package: python3-xopen
Version: 1.7.0-2
Severity: normal

Dear Maintainer,

When trying to run a local program that uses pkg_resources with an
xopen dependency, that generated this error.

pkg_resources.DistributionNotFound: The 'isal>=1.0.0;
platform_python_implementation == "CPython" and (platform_machine ==
"x86_64" or platform_machine == "AMD64")' distribution was not found
and is required by xopen

Ideally the debian packaging for python3-xopen should probably have a
python3-isal dependency, which doesn't appear to be in Debian
currently.

But baring that I got it to work by commenting out this line in
/usr/lib/python3/dist-packages/xopen-1.7.0.dist-info/METADATA

#Requires-Dist: isal (>=1.0.0) ; platform_python_implementation ==
"CPython" and (platform_machine == "x86_64" or platform_machine ==
"AMD64")

Diane

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

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

Versions of packages python3-xopen depends on:
ii  pigz   2.6-1
ii  python33.11.2-1+b1
ii  python3-pkg-resources  66.1.1-1
ii  python3-typing-extensions  4.4.0-1

python3-xopen recommends no packages.

python3-xopen suggests no packages.

-- no debconf information

Bug#1077818: snmp-mibs-downloader: Consider adding RFC-1212, RFC-1215 and IANA-ENTITY-MIB

[Matthijs Kooijman]

Package: snmp-mibs-downloader
Version: 1.6
Severity: wishlist

Hi,

I've been using snmp-mibs-downloader for getting MIB files for my
netgear switch, but I'm running into problems because RFC-1212, RFC-1215
and IANA-ENTITY-MIB are not present.

# RFC-1212 and RFC-1215
Looking at these rfcs, they are a bit different than most others. The
RFC does not contain a full MIB with a "XXX DEFINITIONS ::= BEGIN", but
instead offer a lot of textual advice and examples about how other RFCs
could define their MIBs.

However, these two RFCs do define macros (OBJECT-TYPE and TRAP-TYPE
respectively), that *are* used by other MIBs:

  $ grep -R -B 1 RFC-1215 /usr/share/snmp/mibs
  /usr/share/snmp/mibs/ietf/RFC1382-MIB-TRAP-TYPE
  /usr/share/snmp/mibs/ietf/RFC1382-MIB:FROM RFC-1215
  $ grep -R -B 1 RFC-1212 /usr/share/snmp/mibs | head -n 5
  /usr/share/snmp/mibs/ietf/FDDI-SMT73-MIB-OBJECT-TYPE
  /usr/share/snmp/mibs/ietf/FDDI-SMT73-MIB:FROM RFC-1212;
  --
  /usr/share/snmp/mibs/ietf/PPP-LCP-MIB- OBJECT-TYPE
  /usr/share/snmp/mibs/ietf/PPP-LCP-MIB:  FROM RFC-1212;
  (15 more imports omitted)

Also note that one reference is made to RFC1212 instead of RFC-1212 and
since the RFC itself does not define the MIB name, this is not
necessarily incorrect, but the consensus does seem to be to use
RFC-1212:

  $ grep -R FROM.RFC1212 /usr/share/snmp/mibs | wc -l
  1
  $ grep -R FROM.RFC-1212 /usr/share/snmp/mibs | wc -l
  17

See also:

  https://www.rfc-editor.org/rfc/rfc1212.txt
  https://www.rfc-editor.org/rfc/rfc1215.txt

# Adding RFC-1212 and RFC-1215
Adding these to snmp-mibs-downloader might be a bit tricky - because
the relevant definitions are not contained in an "XXX DEFINITIONS ::
BEGIN" block, the current script cannot extract these definitions as-is.

A pragmatic approach to this could be to add a PREDIFF config option
that patches the downloaded RFC file before running smistrip, though
that does require saving the RFC to a file to patch it, it seems that
patch does not support patching stdin: 
https://unix.stackexchange.com/questions/737104/how-to-apply-a-patch-as-part-of-a-pipe-in-other-words-how-to-patch-stdin



# IANA-ENTITY-MIB
In addition to these RFCs, I'm also missing the IANA-ENTITY-MIB,
which is referenced once:

  $ grep -R FROM.IANA-ENTITY-MIB /usr/share/snmp/mibs
  /usr/share/snmp/mibs/ietf/ENTITY-MIB:FROM IANA-ENTITY-MIB; -- RFC 6933

This one is easy - it is contained in RFC 6933 that also contains
ENTITY-MIB, so this adding IANA-ENTITY-MIB is a matter of editing
rfclist to:

  6933ENTITY-MIB:IANA-ENTITY-MIB:UUID-TC-MIB

Tried, works.


Thanks,

Matthijs


-- System Information:
Debian Release: trixie/sid
  APT prefers noble
  APT policy: (500, 'noble'), (500, 'mantic-updates'), (500, 
'mantic-security'), (500, 'mantic'), (100, 'mantic-backports'), (50, 
'unstable-debug'), (50, 'testing-debug'), (50, 'oldstable-debug'), (50, 
'unstable'), (50, 'stable'), (50, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-44-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 snmp-mibs-downloader depends on:
ii  patch 2.7.6-7build2
ii  smistrip  0.4.8+dfsg2-16
ii  wget  1.21.3-1ubuntu1.1

snmp-mibs-downloader recommends no packages.

Versions of packages snmp-mibs-downloader suggests:
ii  unzip  6.0-28ubuntu1.1

-- Configuration Files:
/etc/snmp-mibs-downloader/rfc.conf changed [not included]
/etc/snmp-mibs-downloader/rfclist changed [not included]

-- no debconf information

Bug#1075427: qdbm: ftbfs with GCC-14

[Niko Tyni]

Control: tag -1 patch

On Wed, Jul 03, 2024 at 12:41:30PM +, Matthias Klose wrote:
> Package: src:qdbm
> Version: 1.8.78-12.1
> Severity: important
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-14

The actual error here is

make[1]: Entering directory '/<>/ruby/curia'
gcc -fdebug-prefix-map=/<>/ruby=. -I. 
-I/usr/include/x86_64-linux-gnu/ruby-3.1.0 
-I/usr/include/ruby-3.1.0/ruby/backward -I/usr/include/ruby-3.1.0 -I. 
-Wdate-time -D_FORTIFY_SOURCE=2   -fPIC -I. -I../.. -I/nonexistent/include 
-I/usr/local/include  -o mod_curia.o -c mod_curia.c
mod_curia.c:92:1: error: return type defaults to ‘int’ [-Wimplicit-int]
   92 | Init_mod_curia(){
  | ^~
make[1]: *** [Makefile:253: mod_curia.o] Error 1
make[1]: Leaving directory '/<>/ruby/curia'
 
and it is fixed by declaring the Ruby extension Init_* functions as void.

Patch attached. The build succeeds for me with this on current sid.
I have not tested the resulting binaries in any way (but it looked
like the build includes a test suite of some kind.)

Hope this helps,
-- 
Niko Tyni   nt...@debian.org
From: Niko Tyni 
Date: Fri, 2 Aug 2024 18:58:34 +0100
X-Dgit-Generated: 1.8.78-12.1 107c05d8cdc8a28b0d0abd837c0abe4bef8c9f48
Subject: Mark Ruby init functions as void

This fixes building with GCC 14.

  mod_curia.c:92:1: error: return type defaults to ‘int’ [-Wimplicit-int]
 92 | Init_mod_curia(){
| ^~
  make[1]: *** [Makefile:253: mod_curia.o] Error 1

Bug-Debian: https://bugs.debian.org/1075427

---

diff --git a/ruby/curia/mod_curia.c b/ruby/curia/mod_curia.c
index 5774ef5..de681eb 100644
--- a/ruby/curia/mod_curia.c
+++ b/ruby/curia/mod_curia.c
@@ -89,7 +89,7 @@ static VALUE rbcrfatalerror(VALUE vself, VALUE vindex);
  */
 
 
-Init_mod_curia(){
+void Init_mod_curia(){
   crinit();
   ccuriaerror = rb_define_class("CuriaError", rb_eStandardError);
   ccuriaerror_ENOERR = rb_define_class("CuriaError_ENOERR", ccuriaerror);
diff --git a/ruby/depot/mod_depot.c b/ruby/depot/mod_depot.c
index b9f46d6..7438e62 100644
--- a/ruby/depot/mod_depot.c
+++ b/ruby/depot/mod_depot.c
@@ -88,7 +88,7 @@ static VALUE rbdpfatalerror(VALUE vself, VALUE vindex);
  */
 
 
-Init_mod_depot(){
+void Init_mod_depot(){
   dpinit();
   cdepoterror = rb_define_class("DepotError", rb_eStandardError);
   cdepoterror_ENOERR = rb_define_class("DepotError_ENOERR", cdepoterror);
diff --git a/ruby/villa/mod_villa.c b/ruby/villa/mod_villa.c
index 80b83a0..5695b36 100644
--- a/ruby/villa/mod_villa.c
+++ b/ruby/villa/mod_villa.c
@@ -102,7 +102,7 @@ static VALUE rbvltranabort(VALUE vself, VALUE vindex);
  */
 
 
-Init_mod_villa(){
+void Init_mod_villa(){
   vlinit();
   cvillaerror = rb_define_class("VillaError", rb_eStandardError);
   cvillaerror_ENOERR = rb_define_class("VillaError_ENOERR", cvillaerror);

Bug#1077817: chirp: Reading from Quansheng causes logout

[Hilary Snaden]

Package: chirp
Version: 1:20240413-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: hilary.sna...@zoho.com

Dear Maintainer,

Attempting to read the contents of two Quansheng UV-K5(8) transcievers has 
causes logout, using the Debian package version and the current version 
installed from Python, and on two different laptops running Debian. The 
software still works normally with older Baofeng transcievers.

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

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

Versions of packages chirp depends on:
ii  python3   3.12.3-1
ii  python3-requests  2.32.3+dfsg-1
ii  python3-serial3.5-2
ii  python3-six   1.16.0-7
ii  python3-yattag1.15.2-1
ii  wxpython-tools4.2.1+dfsg-4

Versions of packages chirp recommends:
ii  python3-suds  1.1.2-1

chirp suggests no packages.

-- no debconf information

Bug#1077803: transition: recode

[Santiago Vila]

I'd like to request a transition slot to upload recode for unstable
and start this transition.


Please go ahead


Done.

Some minor questions:

- How are binNMUs handled? Is the maintainer (me in this case) in charge
of requesting them (at appropriate times), or maybe there is some automated
procedure to trigger them?

- The only package which FTBFS (ui-utilcpp, filed as #1077768) is not currently
in testing. Does this mean that in this case the FTBFS bug should
not block the transition bug?

Thanks a lot.

Bug#1074938: epic4: ftbfs with GCC-14

[Niko Tyni]

Control: tag -1 patch

On Wed, Jul 03, 2024 at 12:25:59PM +, Matthias Klose wrote:
> Package: src:epic4
> Version: 1:2.10.10-1.1
> Severity: important
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-14

> checking whether the C compiler (gcc  ) works... no
> configure: error: installation or configuration problem: C compiler cannot 
> create executables.
> make: *** [debian/rules:14: build-stamp] Error 1

Turns out this was recently broken on sid both by GCC 14 and glibc 2.39.

The above error is because the generated configure script is outdated
and fails with GCC 14 due to implicit int types (-Werror=implicit-int).

This is fixed by the first attached patch, which adds a dh_autoreconf
call to regenerate the configure script.

With that, we see

make[2]: Entering directory '/<>/source'
gcc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wdate-time -D_FORTIFY_SOURCE=2  -I./../include -I../include -c alias.c
In file included from ./../include/irc.h:28,
 from alias.c:39:
./../include/irc_std.h:299:8: error: redefinition of ‘struct 
sockaddr_storage’
  299 | struct sockaddr_storage {
  |^~~~
In file included from /usr/include/x86_64-linux-gnu/sys/socket.h:33,
 from ./../include/irc_std.h:52:
/usr/include/x86_64-linux-gnu/bits/socket.h:196:39: note: originally 
defined here
  196 | struct __attribute_struct_may_alias__ sockaddr_storage
  |   ^~~~
make[2]: *** [Makefile:31: alias.o] Error 1
 
because the configure probe for sockaddr_storage no longer detects it
properly on glibc >= 2.39. The socket headers in glibc were changed
to include the may_alias attribute, making the tightly specified
regex in AC_EGREP_HEADER not match anymore, see

  https://sourceware.org/git/?p=glibc.git;a=commit;h=26e7005728

The second attached patch relaxes all the AC_EGREP_HEADER regexes
to allow for other similar changes in the future.

I have tested that the package builds for me with these, and checked
that the changed AC_EGREP_HEADER probes get the same result on amd64
as they did in the last successful buildd log. I have not checked the
configure results otherwise, and I have not tested the resulting binaries
in any way.

Hope this helps,
-- 
Niko Tyni   nt...@debian.org
>From d05f5406b2fe63b7c351906ce275020c0511239d Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Fri, 2 Aug 2024 09:23:23 +0100
Subject: [PATCH] Run dh_autoreconf before the build

The bundled configure script fails with GCC 14
due to implicit int types (-Werror=implicit-int).
---
 debian/control | 2 +-
 debian/rules   | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 42663e2..e7cfc91 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: net
 Priority: optional
 Maintainer: Kurt Roeckx 
 Standards-Version: 3.8.3
-Build-depends: debhelper (>= 5), libncurses5-dev, libssl-dev, libperl-dev
+Build-depends: debhelper (>= 5), libncurses5-dev, libssl-dev, libperl-dev, dh-autoreconf
 Homepage: http://www.epicsol.org/
 
 Package: epic4
diff --git a/debian/rules b/debian/rules
index 11a502e..f4ffd5a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,7 @@ build-arch: build-stamp
 build-indep: build-stamp
 build-stamp:
 	dh_testdir
+	dh_autoreconf
 	./configure --prefix=/usr --mandir=/usr/share/man \
 	  --with-ssl \
 	  --with-ipv6 \
-- 
2.45.2

From: Niko Tyni 
Date: Fri, 2 Aug 2024 09:31:19 +0100
X-Dgit-Generated: 1:2.10.10-1.1 0171eb699acbdd8569c31b2a5ebe0ac173571ed3
Subject: Fix configure probes for sockaddr_storage et al on glibc >= 2.39

glibc 2.39 changed the socket headers to include the may_alias attribute
in https://sourceware.org/git/?p=glibc.git;a=commit;h=26e7005728

  -struct sockaddr
  +struct __attribute_struct_may_alias__ sockaddr

This makes the tightly specified regex in the corresponding
AC_EGREP_HEADER probe miss the definition.

Pre-emptively loosen other AC_EGREP_HEADER as well.

---

diff --git a/configure.in b/configure.in
index 50cc684..d1e5fd4 100644
--- a/configure.in
+++ b/configure.in
@@ -297,7 +297,7 @@ dnl check for struct linger
 dnl
 
 AC_MSG_CHECKING(for struct linger)
-AC_EGREP_HEADER([struct( |	)*linger], sys/socket.h, 
+AC_EGREP_HEADER([struct.*linger], sys/socket.h, 
   AC_MSG_RESULT(yes), 
   AC_DEFINE(NO_STRUCT_LINGER) 
   AC_MSG_RESULT(no. ugh.))
@@ -518,19 +518,19 @@ AC_ARG_WITH(ipv6,
 ],[AC_MSG_RESULT(yes)])
 
 AC_MSG_CHECKING(for struct sockaddr_storage)
-AC_EGREP_HEADER([struct( |	)*sockaddr_storage], sys/socket.h, 
+AC_EGREP_HEADER([struct.*sockaddr_storage], sys/socket.h, 
   AC_MSG_RESULT(yes) 
   AC_DEFINE(HAVE_STRUCT_SOCKADDR_STORAGE),
   AC_MSG_RESULT(no))
 
 AC_MSG_CHECKING(for struct sockaddr_in6)
-AC_EGREP_HEADER([struct( |	

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 18:01, Russ Allbery  wrote:
>
> Simon McVittie  writes:
> > On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
> >> Luca Boccassi  writes:
>
> >>> It is correct as-is. VERSION_ID is meant to identify a release, not
> >>> updates or point releases. A release as in, Debian Bookworm, or Fedora
> >>> 40, or Ubuntu Noble, and so on.
>
> >> Why would you not want to identify point releases?  This really
> >> surprises me.
>
> > I think the idea is that two releases have a different VERSION_ID if and
> > only if they can both be fully up to date, but still remain
> > different. If we make the analogy of git, VERSION_ID labels a branch,
> > not a tag.
>
> Oh, thank you, this was not at all obvious to me.  If this is indeed the
> case, that would be a useful clarification to add to the specification.
>
> This also explains the desire to identify testing as trixie, but not
> identify unstable as trixie.  If one configures a testing system to point
> to trixie, then fully updating it will move it into the stable release
> when the stable release comes out.  However, if one points a system at
> unstable, that system will never become a trixie system and will always
> continue to point to a different release.
>
> This is not an entirely clean analogy, since it's also possible to point a
> system at the testing suite directly, rather than using the code name, in
> which case that system will also never become trixie.  So in that sense
> testing is simultaneously both trixie and not trixie depending on exactly
> how you configure apt.
>
> This sort of ambiguity is, I think, part of why this proposal generates so
> much discussion.  Debian simply doesn't currently have clean semantics for
> testing.  It exists in a sort of quantum superposition where it is
> multiple things simultaneously for different people, and this proposal is
> trying to label it in a way that collapses that state to match the mental
> model of one group of people, invalidating the mental model of a different
> group of people.

If you instantiate it as 'testing', using that keyword through your
configuration, including apt, then it will be updated to the next
version when that is created in the archive. So it is still trixie
today, and tomorrow it will be forky, and everything, including the
os-release file, will be updated accordingly with my proposal.

>From the point of view of the os-release specification, this is
exactly the same as using 'stable' to build and manage an image. Today
that is bookworm, yesterday it was buster, tomorrow it will be trixie.
It is still correct that today os-release says it's bookworm. Once it
is upgraded, the os-release will be upgraded too and say 'trixie'
because that's released and that's what the 'stable' alias points to.
It's the same installation, and it gets upgraded to a new release -
that's entirely supported by the os-release spec. That's the same if
you are tracking 'testing'. And that is why in my very first mail at
the top of this bug, I said that testing is _not_ a rolling release,
because there's a -1 and a +1 and it has a limited lifespan. Support
status is different than stable, but there are other fields to
indicate that, and again it applies just as well to oldoldoldstable.

So again, while I see why there could be different points of views and
some confusion around what means what, my view is that this proposal
doesn't really introduce anything new, and doesn't change anything
that happens today in any fundamental way. As already mentioned, I do
not see anything fundamentally incompatible between the os-release
concept and the unstable or testing concepts as they are today,
whether they are considered with their codenames or the aliases.

Bug#1077816: opencc: Please add python binding support

[Boyuan Yang]

Source: opencc
Version: 1.1.8+ds1-1
Severity: normal
Control: block 1077603 by -1
X-Debbugs-CC: felixonm...@archlinux.org

It has become apparent that we need to build the Python3 binding for OpenCC
in Debian. It is at least needed by fcitx5-pinyin-zhwiki as a build-dependency.

Thanks,
Boyuan Yang


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

Bug#1077815:

[Miriam Espana Acebal]

-- 
[image: Canonical-20th-anniversary]

Miriam España Acebal

Software Engineer II - Ubuntu Public Cloud/Server

Email:

miriam.esp...@canonical.com

Location:

Spain  (GMT+2)

canonical.com

ubuntu.com


fix-gcc-14-incompatible-pointer-types
Description: Binary data

Bug#1077815: form: ftbfs with GCC-14 on armhf

[Miriam España Acebal]

Source: form
Version: 4.3.0+git20230104+ds-1build2
Severity: serious
Tags: ftbfs patch upstream
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: miriam.esp...@canonical.com

Dear Maintainer,


   While building form with the new gcc-14 with the form package synced
   from Debian, we noticed it was failing: you can find the buildlog
   here [1]. Relevant part of the log is:

   [3~gcc -DHAVE_CONFIG_H -I. -I..   -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=3 -Wall 
-Wextra -Wno-misleading-indentation -Wno-stringop-overflow -O3 
-fomit-frame-pointer -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -fno-stack-clash-protection 
-fdebug-prefix-map=/<>=/usr/src/form-4.3.1+git20240409+ds-2build1 
-c -o form-compcomm.o `test -f 'compcomm.c' || echo './'`compcomm.c
compcomm.c:125:33: error: initialization of ‘int *’ from incompatible pointer 
type ‘WORD *’ {aka ‘short int *’} [-Wincompatible-pointer-types]
  125 | ,{"fewerstats", &(AC.ShortStatsMax),10, 
0}
  | ^
compcomm.c:125:33: note: (near initialization for ‘onoffoptions[24].var’)
compcomm.c:126:29: error: initialization of ‘int *’ from incompatible pointer 
type ‘WORD *’ {aka ‘short int *’} [-Wincompatible-pointer-types]
  126 | ,{"fewerstatistics",&(AC.ShortStatsMax),10, 
0}
  | ^
compcomm.c:126:29: note: (near initialization for ‘onoffoptions[25].var’)
compcomm.c:131:29: error: initialization of ‘int *’ from incompatible pointer 
type ‘WORD *’ {aka ‘short int *’} [-Wincompatible-pointer-types]
  131 | ,{"indentspace",&(AO.IndentSpace),INDENTSPACE,0}
  | ^
compcomm.c:131:29: note: (near initialization for ‘onoffoptions[30].var’)
compcomm.c:137:29: error: initialization of ‘int *’ from incompatible pointer 
type ‘WORD *’ {aka ‘short int *’} [-Wincompatible-pointer-types]
  137 | ,{"innertest",  &(AC.InnerTest),  1,  0}
  | ^
compcomm.c:137:29: note: (near initialization for ‘onoffoptions[36].var’)

We fixed it in Ubuntu following the recommendations in [2], 
I'm attaching here the patch (also forwarded to Upstream) for your 
consideration hoping it helps.

Thanks,

Miriam

[1] 
https://launchpadlibrarian.net/741624061/buildlog_ubuntu-oracular-armhf.form_4.3.1+git20240409+ds-2build1_BUILDING.txt.gz
   
[2] https://gcc.gnu.org/gcc-14/porting_to.html#warnings-as-errors

Bug#1075380: petsc: ftbfs with GCC-14

[Drew Parsons]

Source: petsc
Followup-For: Bug #1075380
Control: block 1075380 by 1075495

The error refers to scotch.
I'm working through the scotch gcc-14 error first.

Bug#1077788: clblas: autopkgtest regressions with gcc-14

[Gianfranco Costamagna]

Hello, the patch needed more tweaks, please check it out there
https://github.com/clMathLibraries/clBLAS/pull/362

I'll keep it updated if I find more issues

G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1041547: fixed in shadow 1:4.13+dfsg1-2

[Milo Mak]

seems the shadow package does not exist

# apt-cache policy shadow
N: Unable to locate package shadow

extract of /etc/apt/sources.list

deb http://debian.proxad.net/debian/ stable main contrib non-free 
non-free-firmware
deb http://debian.proxad.net/debian/ testing main contrib non-free 
non-free-firmware
deb http://debian.proxad.net/debian/ sid main contrib non-free 
non-free-firmware



On Wed, 27 Sep 2023 07:11:14 + Debian FTP Masters wrote:
> Source: shadow
> Source-Version: 1:4.13+dfsg1-2
> Done: Balint Reczey
>
> We believe that the bug you reported is fixed in the latest version of
> shadow, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed. If you
> have further comments please address them to 1041...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Balint Reczey (supplier of updated shadow package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Tue, 26 Sep 2023 22:01:52 +0200
> Source: shadow
> Built-For-Profiles: noudeb
> Architecture: source
> Version: 1:4.13+dfsg1-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Shadow package maintainers
> Changed-By: Balint Reczey
> Closes: 1034482 1040064 1041547 1051062 1051827
> Changes:
> shadow (1:4.13+dfsg1-2) unstable; urgency=medium
> .
> [ Balint Reczey ]
> * debian/gitlab-ci.yml: Use sudo to fix reprotest test
> * debian/login.pam: Drop reference to Debian Etch (Closes: #1040064)
> * debian/NEWS: Fix false claim about PREVENT_NO_AUTH affecting 
authentication.
> Also drop setting PREVENT_NO_AUTH in shipped login.defs. (Closes: 
#1041547)

> * Cherry-pick upstream patch to fix gpasswd passwd leak
> (CVE-2023-4641) (Closes: #1051062)
> * Cherry-pick upstream patch to fix chfn vulnerability allowing 
injection of

> control characters into some /etc/passwd fields.
> (CVE-2023-29383) (Closes: #1034482)
> .
> [ Gioele Barabucci ]
> * Support build profile
> `xsltproc`, `docbook` and all other XML-related packages are not needed
> when the `` build profile is active, as long as `./configure` is
> called with `--disable-man`. (Closes: #1051827)
> Checksums-Sha1:
> c296cd50c74c5b50d050e1ac23085ac10ea87b83 2447 shadow_4.13+dfsg1-2.dsc
> 62928d4593fc88611ac506f4e7c0c8e2cd2a1d12 82300 
shadow_4.13+dfsg1-2.debian.tar.xz
> d439a6fd94c942288dabd2be42bd002f122c85ce 8923 
shadow_4.13+dfsg1-2_source.buildinfo

Bug#1074627: gammapy: tests fail with matplotlib 3.8

[Drew Parsons]

severity 1074627 serious
thanks

matplotlib 3.8 is now uploaded to unstable, so raising this bug to 
severity serious

Bug#1077814: nmu: mapnik rdeps

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: libapache2-mod-t...@packages.debian.org, 
python-map...@packages.debian.org, ti...@packages.debian.org
Control: affects -1 + src:libapache2-mod-tile src:python-mapnik src:tirex
User: release.debian@packages.debian.org
Usertags: binnmu

Please rebuild the mapnik rdeps with the new version in unstable:

nmu libapache2-mod-tile_0.7.1-2 . ANY . unstable . -m "Rebuild with 
libmapnik-dev (>= 4.0.1)"
nmu python-mapnik_1:0.0~20240222-5ab32f020-1 . ANY . unstable . -m "Rebuild 
with libmapnik-dev (>= 4.0.1)"
nmu tirex_0.7.1-3 . ANY . unstable . -m "Rebuild with libmapnik-dev (>= 4.0.1)"

nmu libapache2-mod-tile_0.8.0~beta-1~exp1 . ANY . experimental . -m "Rebuild 
with libmapnik-dev (>= 4.0.1)"

To ensure the new version used everywhere:

dw libapache2-mod-tile_0.7.1-2 . ANY . unstable . -m "libmapnik-dev (>= 4.0.1)"
dw python-mapnik_1:0.0~20240222-5ab32f020-1 . ANY . unstable . -m 
"libmapnik-dev (>= 4.0.1)"
dw tirex_0.7.1-3 . ANY . unstable . -m "libmapnik-dev (>= 4.0.1)"

dw libapache2-mod-tile_0.8.0~beta-1~exp1 . ANY . experimental . -m 
"libmapnik-dev (>= 4.0.1)"

Kind Regards,

Bas

Bug#1077806: libreoffice-core: libreoffice (i386) crashes on startup

[Rene Engelhard]

tag 1077806 + unreproducible

tag 1077806 + moreinfo

thanks


Hi,

Am 02.08.24 um 17:25 schrieb Andres Alla:

Package: libreoffice-core
Version: 4:24.2.5-1
Severity: important

Dear Maintainer,

libreoffice (i386) crashes on startup (backtrace attached).

Splash is shown and then nothing, application window does not show up. It is
the same in safe-mode.

I suspect it may be i386 specific.

I suspect, too. Works definitely on amd64.

System is Debian unstable, mix of i386 and amd64; i386 is primary
architecture, most of X desktop applications are i386, as is libreoffice.


*sigh*. Why are you using libreoffice for i386 then? And why people do think 
this mix makes sense in any wy?

(Yes, I know there is multiarch and I always didn't care because it always 
didn't make sense.)


4:7.4.7-1+deb12u3 from stable works somewhat, writer at least, calc crashes
because of some libxml discrepancy.

What exactly? That sounds like the (broken) libxml2 in unstable also needs an 
other conflict...

Installing amd64 version in that kind of mixed environment is not trivial
(aptitude could not find workable solution) but I did it through some abuse of
dpkg (+f1 packages in the list below, just added Multi-Arch: foreign to
control and repacked). Works just fine.

Then just don't mix it and use amd64?

List of packages below that reportbug generated corresponds to currently
installed and working amd64 version but is essentially same for i386.


This is not helpful. Post what you use, not what you think you use. If you 
can't, use a sane evironment.



Attached backtrace (of crashing i386 version) looks rather sparse to me, gdb
supposedly loaded symbols through debuginfod. Happy to debug further but would
need some guidance on where to look.


-- Andres Alla


-- Package-specific info:
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:
false

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----
=
un  libreoffice-gtk3   (no description available)
un  libreoffice-kf5(no description available)
un  libreoffice-qt5(no description available)

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

even armel there?

Kernel: Linux 6.9.10-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=, 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 libreoffice-core depends on:
ii  fontconfig  2.15.0-1.1
ii  fonts-opensymbol4:102.12+LibO24.2.5-1
ii  libabsl20230802 20230802.1-4
ii  libargon2-1 0~20190702+dfsg-4+b1
ii  libboost-locale1.83.0   1.83.0-3+b2
ii  libc6   2.39-6
ii  libcairo2   1.18.0-3+b1
ii  libclucene-contribs1t64 2.3.3.4+dfsg-1.2
ii  libclucene-core1t64 2.3.3.4+dfsg-1.2
ii  libcmis-0.6-6t640.6.2-2.1+b1
ii  libcups2t64 2.4.10-1
ii  libcurl4t64 8.9.0-3
ii  libdbus-1-3 1.14.10-4+b1
ii  libdconf1   0.40.0-4+b2
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.10-1+b2
ii  libexpat1   2.6.2-1
ii  libexttextcat-2.0-0 3.4.7-1
ii  libfontconfig1  2.15.0-1.1
ii  libfreetype62.13.2+dfsg-1+b4
ii  libgcc-s1   14.1.0-5
ii  libglib2.0-0t64 2.80.4-1
ii  libgpgmepp6t64  1.18.0-4.1+b2
ii  libgraphite2-3  1.3.14-2
ii  libgstreamer-plugins-base1.0-0  1.24.6-dmo1
ii  libgstreamer1.0-0   1.24.6-1
ii  libharfbuzz-icu08.3.0-2+b1
ii  libharfbuzz0b   8.3.0-2+b1
ii  libhunspell-1.7-0   1.7.2+really1.7.2-10+b2
ii  libhyphen0  2.8.8-7+b1
ii  libice6 2:1.0.10-1+b1
ii  libicu7272.1-5
ii  libjpeg62-turbo 1:2.1.5-3
ii  liblcms2-2  2.14-2+b1
ii  libldap-2.5-0   2.5.18+dfsg-2
ii  libmythes-1.2-0 2:1.2.5-1+b1
ii  libnspr42:4.35-1.1+b1
ii  libnss3 2:3.102-1
ii  libnumbertext-1.0-0 1.0.11-4+b1
ii  libopenjp2-72.5.0-2+b3
ii  liborcus-0.18-0 0.19.2-3+b3
ii  

Bug#1077764: Ruling request on os-release specification implementation

[Russ Allbery]

Simon McVittie  writes:
> On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
>> Luca Boccassi  writes:

>>> It is correct as-is. VERSION_ID is meant to identify a release, not
>>> updates or point releases. A release as in, Debian Bookworm, or Fedora
>>> 40, or Ubuntu Noble, and so on.

>> Why would you not want to identify point releases?  This really
>> surprises me.

> I think the idea is that two releases have a different VERSION_ID if and
> only if they can both be fully up to date, but still remain
> different. If we make the analogy of git, VERSION_ID labels a branch,
> not a tag.

Oh, thank you, this was not at all obvious to me.  If this is indeed the
case, that would be a useful clarification to add to the specification.

This also explains the desire to identify testing as trixie, but not
identify unstable as trixie.  If one configures a testing system to point
to trixie, then fully updating it will move it into the stable release
when the stable release comes out.  However, if one points a system at
unstable, that system will never become a trixie system and will always
continue to point to a different release.

This is not an entirely clean analogy, since it's also possible to point a
system at the testing suite directly, rather than using the code name, in
which case that system will also never become trixie.  So in that sense
testing is simultaneously both trixie and not trixie depending on exactly
how you configure apt.

This sort of ambiguity is, I think, part of why this proposal generates so
much discussion.  Debian simply doesn't currently have clean semantics for
testing.  It exists in a sort of quantum superposition where it is
multiple things simultaneously for different people, and this proposal is
trying to label it in a way that collapses that state to match the mental
model of one group of people, invalidating the mental model of a different
group of people.

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

Bug#1077803: transition: recode

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-recode.html

On 2024-08-02 17:15:14 +0200, Santiago Vila wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: rec...@packages.debian.org, sanv...@debian.org, 
> ui-util...@packages.debian.org
> Control: affects -1 + src:recode
> 
> Dear Release Managers:
> 
> I'd like to request a transition slot to upload recode for unstable
> and start this transition.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1077793: pandoc: Pandoc trying to use python2 for filter

[John G Macfarlane]

> On Aug 2, 2024, at 2:19 AM, Kyle Robbertze  wrote:

> It appears that pandoc will try execute the binary 'python' when running
> a .py filter, when it should be using 'python3'.

Why should it be using python3?  Pandoc filters can be written in any version 
of pandoc.

It is true that in your sample you have a shebang line specifying python3.  
That will have an effect (like any shebang line) only if you make the file 
executable.

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 17:07, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > That's yet another Debian-specific workaround. The point of this is,
> > again, answering the question "what is this vendor tree" _without_
> > distro specific kludges. That's the entire reason for os-release to
> > exist. If the answer at any point is "check os-release AND THEN run this
> > distro specific set of scripts or binaries", then the answer is wrong,
> > and the implementation of the spec is buggy. Again, one might say "I am
> > ok with this being buggy because we gain X Y and Z in exchange", but
> > buggy it is and buggy it will remain.
>
> This talk about "buggy" and "workarounds" didn't help me understand what
> you meant, but I think what you're saying is that I'm right, you *do* only
> care about the apt configuration, BUT apt is Debian-specific and figuring
> out how it is configured is not something that can be done portably, so
> you do want to use os-release as a proxy for that information because it's
> a cross-distro tool.
>
> That makes sense to me.  It's a fallible proxy and it will get a bunch of
> edge cases wrong, but it's probably not possible to do better with an
> equivalently simple tool.

Right, but one important correction though - it's not _only_ apt, it's
_also_ apt. Apt is one of the common issues, yes, but it's not the
only one. It is entirely valid to create an OS vendor tree without apt
or its configuration, for a minimal read-only image deployment for a
VM or a container, that you update with an image-based tool with A/B
style partitioning, for example. How do you identify such a vendor
tree? There's no apt. The answer on every other distro is: read
usr/lib/os-release. In Debian it's: read os-release and pray the old
gods and the new that it returns something identifiable, and otherwise
just despair and take a wild guess.

> Fundamentally, you want to change Debian's policy about testing to
> complete the separation from unstable and treat it as a first-class
> release in its own right in our metadata.  Debian has historically not
> done this and generally discouraged people from doing this (this is *not*
> just Santiago's position; Santiago is correctly reflecting the previous
> consensus of the project), but there's always been a fair bit of
> controversy over that point, and I personally tend towards the side that
> thinks testing can be usefully treated as a rolling release with very
> substantial caveats and limitations.
>
> I do agree that it's often useful to be able to quickly determine if an
> image is pointing to testing or to unstable.

I see what you are saying, but I have to say that expressing it like
that makes it sound like I am asking to flip the thing on its head
completely, and do something new and unprecedented, but I'm really
not? I am asking to add one line to a text file. I'm not asking to
change a policy. Nothing else will change - all workflows, all usages,
all intentions, all procedures, all tools, everything will be exactly
the same before and after. Because you can already, today, build and
install a testing image, run it, update it, manage it, use it for
workloads, and never, ever get even a hint that something called
"unstable" even exists. We know this happens, and it always has
happened, and it will continue to happen. And the same is true for
unstable. They each have their own section of the archive, which are
independent from each other and fully complete on their own (as
opposed to other things already mentioned like ubuntu-proposed or
experimental or stable-proposed-updates). You can do 'debootstrap
unstable' build an image and run it, you can do 'debootstrap trixie'
build an image and run it, and you were always able to do so. So, I
don't know, it seems excessive and scary to say it's a change in
policy? No policy changes here, no?

> > On Fri, 2 Aug 2024 at 04:00, Russ Allbery  wrote:
>
> >> Well, it's related to your example of the zoom package basing decisions
> >> on the version number.  If they had done that based on a version number
> >> of testing, there's a fairly high chance that whatever decisions they
> >> made would be wrong by the time the stable release happens,
> >> particularly if they do that early in a release cycle.
>
> >> That said, I would expect most third-party non-free packages like that
> >> to not care at all about anything in Debian until it reached stable, so
> >> the chances of them doing that may be low.
>
> > Uh, I did not provide an example regarding zoom? Where's that from?
>
> Ugh, I'm sorry, I was reading a lot of bug history and completely
> misattributed that message (and, for that matter, when it was sent).  I
> was thinking of:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008735#91
>
> which was from Kipp Cannon.  My apologies for the confusion.

Right, I can see things like that happening - that's both a symptom of
a bug in zoom and a bug in Debian. It's a bug in zoom because
VERSION_ID is not 

Bug#1077764: Ruling request on os-release specification implementation

[Simon McVittie]

On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
> Luca Boccassi  writes:
> > It is correct as-is. VERSION_ID is meant to identify a release, not
> > updates or point releases. A release as in, Debian Bookworm, or Fedora
> > 40, or Ubuntu Noble, and so on.
> 
> Why would you not want to identify point releases?  This really surprises
> me.

I think the idea is that two releases have a different VERSION_ID if and
only if they can both be fully up to date, but still remain different. If
we make the analogy of git, VERSION_ID labels a branch, not a tag.

If Debian 12 is like a git branch (and unstable is like git main),
then Debian 12.0 and 12.6 are more like tags on the Debian 12 branch.
Debian 12 is still maintained and changing, but Debian 12.6 was a point
in time, it already happened, and now it's never going to change.

So, 11 vs. 12 vs. 13 are different VERSION_IDs, because a fully updated
Debian 11 is not the same as a fully updated Debian 12 or 13.

But 12.5 vs. 12.6 don't have different VERSION_IDs, because if you upgrade
Debian 12.5, it *becomes* 12.6: there is no separate 12.5.x branch that
anyone is maintaining as something distinct from 12.6.

(It might make sense for there to be a defined field in os-release for
"what's the most recent point release we've caught up with?" *as well*,
but VERSION_ID is not that.)

smcv

Bug#1077439: Fwd: Bug#1077439: latex-cjk-japanese-wadalab: FTBFS: wftodm.c:57:1: error: return type defaults to ‘int’ [-Wimplicit-int]

[韓達耐]

Hi Hilmar,

Sorry, I should have stated that we keep -Wall to keep all the warnings, we
just add -ansi.

Yes, I'll do the dput and try pbuilder too for good measure.  It's been a
while, time to stretch my Debian tendons again.  ;-)

Have a good weekend, mate.

-- 
Danai

On Fri, 2 Aug 2024, 19:17 Preuße, Hilmar,  wrote:

> On 01.08.2024 14:30, Danai SAE-HAN (韓達耐) wrote:
>
> Hi Danai,
>
> sounds rather like a wacky solution, as we hide the code issues, instead of
> solving them However as explained: the code is never used by the end
> user,
> hence the quality does not matter.
>
> I checked with diffoscope, everything fine. Go ahead and many thanks!
> Will you run
> dput after salsa commit?
>
> Hilmar
>
> > The easiest fix is to replace the following line in debian/rules:
> >
> >cc -Wall -g -O2 -o build/wftodm wftodm.c
> >
> > with:
> >
> >cc -ansi -g -O2 -o build/wftodm wftodm.c
> >
> > It works under GCC 14 as well.
> >
> > The "wftodm" binary is only used during build time to build AFM and PFA
> > fonts; it is not shipped to the end user of the package.
> > So IMHO this easy fix is enough.  What do you think?  If you agree, I
> > will upload the change to Salsa.
> >
>
>
>
>
> --
> sigfault
>
>

Bug#1077813: RM: python-jose -- ROM; dead upstream; open CVEs

[Michael Fladischer]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: python-j...@packages.debian.org
Control: affects -1 + src:python-jose
User: ftp.debian@packages.debian.org
Usertags: remove

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please remove python-jose. It's dead upstream, has unresolved CVEs and has
become a leaf package.

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmatC60bHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqkD8H/jtBnNBZPTnL1r+s6/mX
HW5zdcIf5To7TUHx1JWGe6EWu/j8cuyK48CRj/bNKovC/Eawm/lWSkye0OawchqQ
vdxExcsk0Yt9v2ngi+gSCIRoW23MTcmyzSxFewY0GNdQMA9vvZLhm2VtaFHB/dAN
lv0kz7UF/bri6suUy1TQP8yIo8FRuO+iXwlhrj8wcsIhll4DckR0BnkT+0kodr5x
/cFRadYq847Vq8Pulg4nPwLbzINR7qAP6tFil3sAhyd+aiXSHCHB1CnuIdITQrDh
xG1EbSNTvUiHoMbnDHP5BD0QdwCb98xF5T6B2+nBB7+adQyUonx4NhhJZ7UirNYt
B7w=
=smjv
-END PGP SIGNATURE-

Bug#1077812: clapper: Please split library and development files to separate packages

[Arnaud Ferraris]

Package: clapper
Version: 0.6.1-4
Severity: normal
X-Debbugs-Cc: aferra...@debian.org

Dear Maintainer,

The current "clapper" package includes not only the software and its data
files, but also several shared libraries, gobject-introspection data and
development files (C headers, pkg-config files...).

This implies any software linked against libclapper, for example, will have to
depend on the full "clapper" package instead of just the library. Likewise, any
user of this software will also have all the development files installed, which
are only necessary for actually developing with libclapper.

Additionally, the development files also need the development files for
gstreamer-plugins-base and several other libs, which should therefore be
dependencies for this package.

Could you please split this package so the shared libraries, development files
and gobject-introspection data are all shipped in separate packages?

Best regards,
Arnaud


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (900, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages clapper depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  gir1.2-adw-1 1.5.2-1
ii  gir1.2-gst-plugins-base-1.0  1.24.5-1
ii  gir1.2-gstreamer-1.0 1.24.5-1
ii  gir1.2-gtk-4.0   4.14.4+ds-8
ii  gir1.2-soup-3.0  3.4.4-5+b1
ii  gstreamer1.0-plugins-good1.24.5-1
ii  libadwaita-1-0   1.5.2-1
ii  libc62.39-6
ii  libglib2.0-0t64  2.80.4-1
ii  libgraphene-1.0-01.10.8-3+b1
ii  libgstreamer-gl1.0-0 1.24.5-1
ii  libgstreamer-plugins-base1.0-0   1.24.5-1
ii  libgstreamer1.0-01.24.5-1
ii  libgtk-4-1   4.14.4+ds-8
ii  libmicrodns1 0.2.0-1+b1
ii  libpango-1.0-0   1.54.0+ds-1
ii  libsoup-3.0-03.4.4-5+b1

Versions of packages clapper recommends:
ii  gstreamer1.0-libav1.24.5-1
ii  gstreamer1.0-plugins-bad  1.24.5-1+b1

clapper suggests no packages.

-- no debconf information

Bug#1077811: meson: Unnecessary debian/.pc/ directory in the source package

[Boyuan Yang]

在 2024-08-02星期五的 19:25 +0300，Jussi Pakkanen写道：
> On Fri, 2 Aug 2024 at 19:03, Boyuan Yang  wrote:
> 
> > To prevent this issue in the future, you may consider managing your 
> > packaging
> > work using git-buildpackage or dgit. On the very least, doing a plain 
> > debdiff(1)
> > between each upload against the /debian/ dir would still be useful.
> 
> Will be fixed in the next upload.
> 
> But speaking more generally, if this really is an issue then a _much_
> better solution would be to have an automated test that blocks uploads
> that have this extra dir. In that way it would be fixed once and would
> never occur again. Sending emails like these after the fact is just
> playing whack-a-mole, which wastes precious human time for everyone
> involved.

It's actually not a big issue; that's why I tagged it as severity:minor.
Cleaning the workspace is beneficial but not required.

Thanks,
Boyuan Yang


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

Bug#1076296: src:slime: fails to migrate to testing for too long: autopkgtest regression

[David Bremner]

Paul Gevers  writes:

>
> 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:slime has been trying to migrate for 37 
> days [2]. Hence, I am filing this bug. The version in unstable fails its 
> own autopkgtest. Ironically the log shows: 0 errors, 0 warnings. It also 
> shows this:
> File #P"/usr/share/common-lisp/source/slime/xref.lisp" does not exist

The problem referenced in this bug is fixed (at least in my local runs
of autopkgtest), but slime cannot migrate to testing until after sbcl
2.4.*. 

Bug#1077811: meson: Unnecessary debian/.pc/ directory in the source package

[Jussi Pakkanen]

On Fri, 2 Aug 2024 at 19:03, Boyuan Yang  wrote:

> To prevent this issue in the future, you may consider managing your packaging
> work using git-buildpackage or dgit. On the very least, doing a plain 
> debdiff(1)
> between each upload against the /debian/ dir would still be useful.

Will be fixed in the next upload.

But speaking more generally, if this really is an issue then a _much_
better solution would be to have an automated test that blocks uploads
that have this extra dir. In that way it would be fixed once and would
never occur again. Sending emails like these after the fact is just
playing whack-a-mole, which wastes precious human time for everyone
involved.

Bug#1077299: git: Not migrating to testing for long time due to autopkgtest results

[Simon McVittie]

Control: block -1 by 1076751 1076750

On Sun, 28 Jul 2024 at 07:50:26 +0200, Salvatore Bonaccorso wrote:
>   • Issues preventing migration:
>   □ autopkgtest for ikiwiki-hosting/0.20220716-2: amd64: Regression

This is #1076751, for which the root cause is #1076750 in which I asked the
git maintainers for advice on how to proceed.

Obviously git is more important than ikiwiki-hosting, so if the
release/security teams would prefer to push git into testing and break
ikiwiki-hosting, I believe removing ikiwiki-hosting from testing or
ignoring its autopkgtest regression would work.

ikiwiki-hosting is up for removal on 2024-08-21 anyway.

I am the current maintainer of ikiwiki-hosting, but I intend to orphan
it in the next upload if it isn't adopted, and the amount of time I can
spend on it is limited.

smcv

Bug#1077764: Ruling request on os-release specification implementation

[Russ Allbery]

Luca Boccassi  writes:

> That's yet another Debian-specific workaround. The point of this is,
> again, answering the question "what is this vendor tree" _without_
> distro specific kludges. That's the entire reason for os-release to
> exist. If the answer at any point is "check os-release AND THEN run this
> distro specific set of scripts or binaries", then the answer is wrong,
> and the implementation of the spec is buggy. Again, one might say "I am
> ok with this being buggy because we gain X Y and Z in exchange", but
> buggy it is and buggy it will remain.

This talk about "buggy" and "workarounds" didn't help me understand what
you meant, but I think what you're saying is that I'm right, you *do* only
care about the apt configuration, BUT apt is Debian-specific and figuring
out how it is configured is not something that can be done portably, so
you do want to use os-release as a proxy for that information because it's
a cross-distro tool.

That makes sense to me.  It's a fallible proxy and it will get a bunch of
edge cases wrong, but it's probably not possible to do better with an
equivalently simple tool.

Fundamentally, you want to change Debian's policy about testing to
complete the separation from unstable and treat it as a first-class
release in its own right in our metadata.  Debian has historically not
done this and generally discouraged people from doing this (this is *not*
just Santiago's position; Santiago is correctly reflecting the previous
consensus of the project), but there's always been a fair bit of
controversy over that point, and I personally tend towards the side that
thinks testing can be usefully treated as a rolling release with very
substantial caveats and limitations.

I do agree that it's often useful to be able to quickly determine if an
image is pointing to testing or to unstable.

> On Fri, 2 Aug 2024 at 04:00, Russ Allbery  wrote:

>> Well, it's related to your example of the zoom package basing decisions
>> on the version number.  If they had done that based on a version number
>> of testing, there's a fairly high chance that whatever decisions they
>> made would be wrong by the time the stable release happens,
>> particularly if they do that early in a release cycle.

>> That said, I would expect most third-party non-free packages like that
>> to not care at all about anything in Debian until it reached stable, so
>> the chances of them doing that may be low.

> Uh, I did not provide an example regarding zoom? Where's that from?

Ugh, I'm sorry, I was reading a lot of bug history and completely
misattributed that message (and, for that matter, when it was sent).  I
was thinking of:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008735#91

which was from Kipp Cannon.  My apologies for the confusion.

>> I am surprised that point releases don't change VERSION_ID, and now I'm
>> curious why that's the case.  I was assuming, having not previously
>> looked at it, that VERSION_ID would match /etc/debian_release, but I
>> see that it doesn't and has only the major version.

> It is correct as-is. VERSION_ID is meant to identify a release, not
> updates or point releases. A release as in, Debian Bookworm, or Fedora
> 40, or Ubuntu Noble, and so on.

Why would you not want to identify point releases?  This really surprises
me.

>> Regardless, security uploads do potentially create this problem, but we
>> also try pretty hard to not change major functionality in security
>> uploads in ways that may prompt someone to want to change behavior
>> based on that version.  There is a window of possibility there, I think
>> it's sufficiently narrow to not worry that much about.  It's at least a
>> much narrower problem than version numbers in testing.

> See other mail. It is really not narrow at all, because of kernel
> upstream LTS updates. The upstream kernel quality of these branches is
> really, really low, and massive regressions sneak in at all times. The
> difference of behaviour between point releases is huge.

I believe kernels are usually (not always, but usually) updated as part of
point releases, which is yet another reason why I am so baffled as to why
the VERSION_ID would not track point releases.

> Debian stable updates do not, and pretty much never have, include only
> security fixes.

Exactly, which is why they should result in a VERSION_ID bump.

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

Bug#1077811: meson: Unnecessary debian/.pc/ directory in the source package

[Boyuan Yang]

Source: meson
Version: 1.5.1-1
Severity: minor
X-Debbugs-CC: jpakk...@gmail.com

Dear Debian meson package maintainer,

In the source package for meson/1.5.1-1, an unnecessary directory exists
as /debian/.pc/. This should not happen. Please consider stripping this
directory in the upcoming package uploads.

To prevent this issue in the future, you may consider managing your packaging
work using git-buildpackage or dgit. On the very least, doing a plain debdiff(1)
between each upload against the /debian/ dir would still be useful.

Thanks,
Boyuan Yang


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

Bug#1077810: documentation: dcut cancel does not actually cancel a regular upload

[Michael Tokarev]

Package: dput-ng
Version: 1.39
Severity: grave

The documentation (manpage) for `dcut cancel` states:

   cancel
   Cancel an upload entirely. The upload is referred to as a changes file
   name existing remote in the incoming or deferred queues.

This is wrong, because cancel actually can only be applied to DELAYED queue,
but the description suggests it is valid to cancel a regular upload too.

Suggest to use wording for cancel and rm subcommands as for regular dcut
command (without -ng suffix).

Severity is grave because this wrong wording leads to huge efforts to work
around mistaken upload which can't be cancelled in time because of the
wrong expectation, - resorting to version strings like FOO+reallyBAR and
jumping through hoops for both users and maintainers.

/mjt

Bug#1077805: adequate: Unexpected output from /usr/sbin/update-binfmts --display: " mask = "

[Patrice Duroux]

same here ;-)
But I am not sure about the "trailing" space :

$ /usr/sbin/update-binfmts --display | cat -A
cli (enabled):$
 package = mono-runtime$
type = magic$
  offset = 0$
   magic = MZ$
mask = $
 interpreter = /usr/bin/cli$
detector = /usr/lib/cli/binfmt-detector-cli$
jar (enabled):$
 package = openjdk-11$
type = magic$
  offset = 0$
   magic = PK\x03\x04$
mask = $
 interpreter = /usr/bin/jexec$
detector = $
llvm-16-runtime.binfmt (enabled):$
 package = llvm-16-runtime$
type = magic$
  offset = 0$
   magic = BC$
mask = $
 interpreter = /usr/bin/lli-16$
detector = $
llvm-17-runtime.binfmt (enabled):$
 package = llvm-17-runtime$
type = magic$
  offset = 0$
   magic = BC$
mask = $
 interpreter = /usr/bin/lli-17$
detector = $
love (enabled):$
 package = love$
type = extension$
  offset = 0$
   magic = love$
mask = $
 interpreter = /usr/bin/love$
detector = $
python3.12 (enabled):$
 package = python3.12$
type = magic$
  offset = 0$
   magic = \xcb\x0d\x0d\x0a$
mask = $
 interpreter = /usr/bin/python3.12$
detector = $
wine (enabled):$
 package = wine$
type = magic$
  offset = 0$
   magic = MZ$
mask = $
 interpreter = /usr/bin/wine$
detector = $

Could this be a consequence of:
https://salsa.debian.org/debian/adequate/-/commit/9455382d8b8b60372dc0aabb802d5993e161bac3
?

Regards,
Patrice

Bug#1077809: ITP: python-googlemaps -- client library for Google Maps Platform

[EiPi Fun]

Package: wnpp
Severity: wishlist
Owner: DONG XU 

* Package name: python-googlemaps
  Version : 4.10.0
  Upstream Contact: Justin Poehnelt 
* URL : https://github.com/googlemaps/google-maps-services-python
* License : Apache-2.0
  Programming Lang: Python
  Description : client library for Google Maps Platform

 Use Python? Want to geocode something? Looking for directions?
 Maybe matrices of directions? This library brings the Google Maps Platform Web
 Services to your Python application.
 .
 The Python Client for Google Maps Services is a Python Client library for the 
 following Google Maps APIs:
  - Directions API
  - Distance Matrix API
  - Elevation API
  - Geocoding API
  - Geolocation API
  - Time Zone API
  - Roads API
  - Places API
  - Maps Static API
  - Address Validation API

I intend to maintain this package within the Home Assistant team.

Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"

[Andrea Zagli]

Colin Watson  writes:

> On Fri, Aug 02, 2024 at 05:16:57PM +0200, Andrea Zagli wrote:
>> i have "sshd: ALL" in hosts.allow and "ALL: ALL" in hosts.deny...
>
> Perfect, thanks, I see the problem now.  Will upload a fix shortly.


ok, i added sshd-session to hosts.allow and it works

Bug#1077808: jquery: FTBFS on amd64/unstable: Error: Cannot find module '/usr/lib/nodejs/requirejs/r.js'

[Chris Lamb]

Source: jquery
Version: 3.3.1~dfsg-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Tags: fbtfs

Dear maintainer,

jquery fails to build from source in unstable/amd64:

  […]

  Error: Cannot find module '/usr/lib/nodejs/requirejs/r.js'
  at Module._resolveFilename (node:internal/modules/cjs/loader:1145:15)
  at Module._load (node:internal/modules/cjs/loader:986:27)
  at Function.executeUserEntryPoint [as runMain] 
(node:internal/modules/run_main:174:12)
  at node:internal/main/run_main_module:28:49 {
code: 'MODULE_NOT_FOUND',
requireStack: []
  }
  […]

This looked similar to #847740, so I updated the reference in
debian/rules to /usr/share/nodejs/requirejs/r.js. But it then fails
with a different error:

  TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be of type string 
or an instance of Buffer, TypedArray, or DataView. Received an instance of 
Object
  at Object.writeFileSync (node:fs:2376:5)
  at done (/usr/lib/nodejs/uglify-js/bin/uglifyjs:516:20)
  at cb (/usr/lib/nodejs/uglify-js/bin/uglifyjs:324:39)
  at /usr/lib/nodejs/uglify-js/bin/uglifyjs:391:9
  at FSReqCallback.readFileAfterClose [as oncomplete] 
(node:internal/fs/read/context:68:3) {
code: 'ERR_INVALID_ARG_TYPE'
  }


The full build log of the (first) FTBFS is attached.

Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

jquery.3.3.1~dfsg-3.unstable.amd64.log.txt.gz
Description: Binary data

Bug#1077807: elpa-ac-rtags: Error updating package

[Ron Murray]

Package: elpa-ac-rtags
Version: 2.38-12
Severity: important

Dear Maintainer,

Package elpa-ac-rtags fails to update, with this error:

-
Setting up elpa-ac-rtags (2.38-12) ...
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Install elpa-popup for emacs
install/popup-0.5.8: Handling install of emacsen flavor emacs
install/popup-0.5.8: byte-compiling for emacs
Install elpa-rtags for emacs
install/rtags-2.38.130: Handling install of emacsen flavor emacs
install/rtags-2.38.130: byte-compiling for emacs
Install elpa-auto-complete for emacs
install/auto-complete-1.5.0: Handling install of emacsen flavor emacs
install/auto-complete-1.5.0: byte-compiling for emacs
cp: cannot overwrite non-directory './dict' with directory 
'/usr/share/emacs/site-lisp/elpa-src/auto-complete-1.5.0/dict'
ERROR: install script from elpa-auto-complete package failed
dpkg: error processing package elpa-ac-rtags (--configure):
 installed elpa-ac-rtags package post-installation script subprocess returned 
error exit status 1
-


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

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

Versions of packages elpa-ac-rtags depends on:
ii  dh-elpa-helper  2.1.5
ii  elpa-auto-complete  1.5.1-0.2
ii  elpa-rtags  2.38-12
ii  emacsen-common  3.0.5

Versions of packages elpa-ac-rtags recommends:
ii  emacs  1:29.4+1-3
ii  emacs-gtk [emacs]  1:29.4+1-3

elpa-ac-rtags suggests no packages.

-- no debconf information

**
This email and any attachments may contain information that has been classified 
as Confidential or Restricted if indicated as such. It is intended exclusively 
for the use of the individual(s) to whom it is addressed. If inappropriately 
disclosed, this information could seriously damage the mission, safety or 
integrity of an agency, its staff, or its constituents. This information may be 
protected by federal and state laws or regulations. Retransmission or 
forwarding of this email must only be done after receiving explicit written 
approval from the original sender of the email. The data must only be stored in 
encrypted format.

If you are not the intended recipient, you may not use, copy, distribute, or 
forward this message or contents to anyone. If you have received this email in 
error, please notify the sender immediately and delete the email from your 
email system.

Bug#1077806: libreoffice-core: libreoffice (i386) crashes on startup

[Andres Alla]

Package: libreoffice-core
Version: 4:24.2.5-1
Severity: important

Dear Maintainer,

libreoffice (i386) crashes on startup (backtrace attached).

Splash is shown and then nothing, application window does not show up. It is 
the same in safe-mode.

I suspect it may be i386 specific.

System is Debian unstable, mix of i386 and amd64; i386 is primary 
architecture, most of X desktop applications are i386, as is libreoffice.

I am unable to pinpoint what change caused it. Machine was not rebooted since 
february but was gradually upgraded. Libreoffice has been open for weeks. It is 
possible that actual breaking change happened several versions past but went 
unnoticed because previous versions of libraries were used by still running 
program. Problem did not appear until reboot.

I see pdf-s generated by 24.2 in the end of june but there is no more specific 
version in metadata.

Reinstalled libreoffice and stripped down to just libreoffice-writer, -calc and 
strictly required dependencies, no DE or language-specific packages, no java-
support etc. Still crashing.

Tried all 24.2 versions (with corresponding dependencies) that have ever been 
in unstable from https://snapshot.debian.org/package/libreoffice/ and 
4:24.8.0~rc1-1 from experimental. All crashing.

4:7.4.7-1+deb12u3 from stable works somewhat, writer at least, calc crashes 
because of some libxml discrepancy.

Installing amd64 version in that kind of mixed environment is not trivial 
(aptitude could not find workable solution) but I did it through some abuse of 
dpkg (+f1 packages in the list below, just added Multi-Arch: foreign to 
control and repacked). Works just fine.

List of packages below that reportbug generated corresponds to currently 
installed and working amd64 version but is essentially same for i386.

Attached backtrace (of crashing i386 version) looks rather sparse to me, gdb 
supposedly loaded symbols through debuginfod. Happy to debug further but would 
need some guidance on where to look.


-- Andres Alla


-- Package-specific info:
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:
false

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----
=
un  libreoffice-gtk3   (no description available)
un  libreoffice-kf5(no description available)
un  libreoffice-qt5(no description available)

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

Kernel: Linux 6.9.10-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=, 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 libreoffice-core depends on:
ii  fontconfig  2.15.0-1.1
ii  fonts-opensymbol4:102.12+LibO24.2.5-1
ii  libabsl20230802 20230802.1-4
ii  libargon2-1 0~20190702+dfsg-4+b1
ii  libboost-locale1.83.0   1.83.0-3+b2
ii  libc6   2.39-6
ii  libcairo2   1.18.0-3+b1
ii  libclucene-contribs1t64 2.3.3.4+dfsg-1.2
ii  libclucene-core1t64 2.3.3.4+dfsg-1.2
ii  libcmis-0.6-6t640.6.2-2.1+b1
ii  libcups2t64 2.4.10-1
ii  libcurl4t64 8.9.0-3
ii  libdbus-1-3 1.14.10-4+b1
ii  libdconf1   0.40.0-4+b2
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.10-1+b2
ii  libexpat1   2.6.2-1
ii  libexttextcat-2.0-0 3.4.7-1
ii  libfontconfig1  2.15.0-1.1
ii  libfreetype62.13.2+dfsg-1+b4
ii  libgcc-s1   14.1.0-5
ii  libglib2.0-0t64 2.80.4-1
ii  libgpgmepp6t64  1.18.0-4.1+b2
ii  libgraphite2-3  1.3.14-2
ii  libgstreamer-plugins-base1.0-0  1.24.6-dmo1
ii  libgstreamer1.0-0   1.24.6-1
ii  libharfbuzz-icu08.3.0-2+b1
ii  libharfbuzz0b   8.3.0-2+b1
ii  libhunspell-1.7-0   1.7.2+really1.7.2-10+b2
ii  libhyphen0  2.8.8-7+b1
ii  libice6 2:1.0.10-1+b1
ii  libicu7272.1-5
ii  libjpeg62-turbo 1:2.1.5-3
ii  liblcms2-2  2.14-2+b1
ii  libldap-2.5-0   2.5.18+dfsg-2
ii  libmythes-1.2-0 2:1.2.5-1+b1
ii  libnspr4   

Bug#1077805: adequate: Unexpected output from /usr/sbin/update-binfmts --display: " mask = "

[Sven Joachim]

Package: adequate
Version: 0.16.7
Severity: grave

The current version of adequate fails on any package for me, complaining
about unexpected output from update-binfmts:

,
| $ adequate ncurses-base
| 2024/08/02 17:20:41 Unexpected output from /usr/sbin/update-binfmts 
--display: "mask = "
| $ echo $?
| 1
| $ /usr/sbin/update-binfmts --display
| llvm-16-runtime.binfmt (enabled):
|  package = llvm-16-runtime
| type = magic
|   offset = 0
|magic = BC
| mask =
|  interpreter = /usr/bin/lli-16
| detector =
| python3.12 (enabled):
|  package = python3.12
| type = magic
|   offset = 0
|magic = \xcb\x0d\x0d\x0a
| mask =
|  interpreter = /usr/bin/python3.12
| detector =
| wine (enabled):
|  package = wine
| type = magic
|   offset = 0
|magic = MZ
| mask =
|  interpreter = /usr/bin/wine-auto
| detector =
`

Note the trailing space in the "mask" and "detector" lines, maybe this
is unexpected?


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

Kernel: Linux 6.1.102-nouveau (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages adequate depends on:
ii  debconf  1.5.87
ii  libc62.39-6

Versions of packages adequate recommends:
ii  pkgconf  1.8.1-3

adequate suggests no packages.

-- no debconf information

Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)

[Daniel Gröber]

Hi Samo,

On Mon, Jun 24, 2024 at 04:53:01PM +0200, Samo Pogačnik wrote:
> i prepared another candidate for the 0.4.6-1 release (
> https://salsa.debian.org/spog/git-subrepo/-/commit/f96eeedd0e96b6f2bbcc8c013909de5d5325cafe
> ), hoping it ticks all the boxes and more :)

Excellent!

I did run into some more issues during build/testing unfortunately. Some
beurocratic, some related to tests:

 - you are still missing from d/copyright :)

 - d/changelog should not contain versions that were never in Debian.
   consequently everything that isn't the "Intial release" entry also doesn't
   make sense. Not sure why I didn't catch that before.

 - tests fail in a git checkout (but not during clean sbuild it seems)

 - d/rules clean doesn't cleanup after tests

The package looks good sans tests so I'll upload that to NEW so we can keep
working on the tests in the meantime. Remeber to pull my changes from
debian/git-subrepo before you continue working :)

For the cleanup requirement see
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

> clean (required)
>
>This must undo any effects that the build and binary targets may have
>had, except that it should leave alone any output files created in the
>parent directory by a run of a binary target.

Right now I have to `git reset --hard HEAD; git clean -xfd` to get rid of
all the build byproducts.

This is one of the more onerous requirements of Debian policy rooted in a
world that didn't have git yet. It's important because some people still
work on packages without git and they need a way to reset the build tree.

Looking at what remains after `quilt pop -a` I see untracked files
test/repo/* which you create with your 0005 patch. Really that should
probably be in test/tmp which upstream has already setup to be removed by
their clean target.

Other than that I see changes to upstream files:

modified   test/repo/bar/config
@@ -2,3 +2,7 @@
repositoryformatversion = 0
filemode = true
bare = true
+   logallrefupdates = true
+[user]
+   name = BarUser
+   email = bar@bar
deletedtest/repo/bar/objects/94/c86ffc745232d89f78c6f895e11e71272518db
deletedtest/repo/bar/objects/f6/2a8ff3feadf39b0a98f1a86ec6d1eb33858ee9
modified   test/repo/bar/refs/heads/master
@@ -1 +1 @@
-94c86ffc745232d89f78c6f895e11e71272518db
+e2aebf65b96f0be7595bffed8ff42cc69334f150
modified   test/repo/bar/refs/tags/A
@@ -1 +1 @@
-f62a8ff3feadf39b0a98f1a86ec6d1eb33858ee9
+f8206189232afa81e999b1b3aeb524fc4d9bae46
modified   test/repo/foo/config
@@ -2,3 +2,7 @@
repositoryformatversion = 0
filemode = true
bare = true
+   logallrefupdates = true
+[user]
+   name = FooUser
+   email = foo@foo
deletedtest/repo/foo/objects/e2/1291a1ad392a9d4c51dd9586804f1467b28afd
modified   test/repo/foo/refs/heads/master
@@ -1 +1 @@
-e21291a1ad392a9d4c51dd9586804f1467b28afd
+e51641c054bb9e0591a8a95d0789e10abb308de2
modified   test/repo/init/config
@@ -1,5 +1,8 @@
 [core]
repositoryformatversion = 0
filemode = true
-   bare = false
+   bare = true
logallrefupdates = true
+[user]
+   name = InitUser
+   email = init@init
deletedtest/repo/init/objects/32/5180321750a21cd7a4e7ecda319e557a4f6a09
deletedtest/repo/init/objects/3d/918c6901c02f43af5d31779dd5e1f9166aeb36
deletedtest/repo/init/objects/58/931fc1bd559b59c41ea738fc7ad04f9ad01bd3
deletedtest/repo/init/objects/94/7b3d714c38791e95ad6f928b48c98bb8708acd
deletedtest/repo/init/objects/c3/ee8978c4c5d84c3b7d00ba8e5906933d027882
modified   test/repo/init/refs/heads/master

In general you must not change upstream files during the Debian package
build. Sometimes this is necessary, in such cases a save+restore approach
is taken cf. dh_autoreconf. However this is not appropriate here.


Also, looking at 0005:

> diff --git a/Makefile b/Makefile
> index f84b83d..1927073 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -47,6 +47,18 @@ help:
>   @echo 'uninstall  Uninstall $(NAME)'
>   @echo 'envShow environment variables to set'
>  
> +.PHONY: genfoo
> +genfoo:
> + test/genfoo test/repo
> +
> +.PHONY: genbar
> +genbar:
> + test/genbar test/repo
> +
> +.PHONY: geninit
> +geninit:
> + test/geninit test/repo
> +
>  .git:
>   git init -b main .
>   git config user.email "you@you"
> @@ -57,6 +69,9 @@ help:
>  
>  .PHONY: test
>  test: .git
> + make genfoo
> + make genbar
> + make geninit
>   prove $(prove) $(test)

Recursive make calls are uncessary here, but you're also ignoring the
arcane convention to call $(MAKE), see
https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html.

Easy fix is to just add dependencies to the test target, like so:
 
 .PHONY: test
-test: .git
+test: .git genfoo genbar geninit
prove $(prove) $(test)

Upstream's suggestion to put it in test/setup is even better though so
that's the way to go.

> I made the PR 

Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"

[Colin Watson]

On Fri, Aug 02, 2024 at 05:16:57PM +0200, Andrea Zagli wrote:
> i have "sshd: ALL" in hosts.allow and "ALL: ALL" in hosts.deny...

Perfect, thanks, I see the problem now.  Will upload a fix shortly.

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

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 08:22:55 +0200 Helmut Grohne 
wrote:
> Hi Russ,
> 
> Let me adress the essential/bootstrap aspects of this sub-discussion
> only.
> 
> On Thu, Aug 01, 2024 at 08:00:40PM -0700, Russ Allbery wrote:
> > Given that it's included in base-files now and base-files is
essential, I
> > believe it has to continue to be provided by an essential package,
unless
> > we want to try to do the work of figuring out if os-release can be
removed
> > from essential (and I would not be eager to do that).
> 
> I concur.
> 
> > Since it is part of the essential set, though, I'm not sure the
dependency
> > from base-files is actually needed (but also it may not really
matter).  I
> > think dependencies between essential packages are only really used
during
> > the bootstrapping phase, and presumably os-release is not needed by
> > bootstrapping.
> 
> It actually is the other way round. debootstrap-like tools will
> automatically pick up all packages marked with "Essential: yes".
> Bootstrapped systems will not magically install newly essential
packages
> though. So doing an upload of base-files that releases /etc/os-
release
> will not magically cause a newly essential os-release package to be
> installed and thus our essential promise of /etc/os-release may be
> temporarily broken. (There is no implication of how bad breaking this
> promise is.) So whenever we want to add a new package to the
essential
> set, we need some existing essential package to declare a dependency
on
> that new package for the duration of one release cycle (as we do not
> support skip upgrades).
> 
> The obvious candidate to express such a dependency would be base-
files
> here and that brings us back to the aspects you (Russ) mentioned
earlier
> regarding the fragility of the bootstrap order related to base-files.
> Admittedly, bootstrapping is more empirically solved in Debian than
> well-defined. As I attempted clarifying this in Debian policy
earlier,
> the outcome was to explicitly leave it undefined. If I remember
> correctly, randomly ordering the maintainer scripts executed during
> filesystem bootstrap makes things fail every now and then and the
order
> that most tools produce works well enough currently.  Any new
dependency
> inside the essential set poses a risk of perturbing this order that
> happens to work by chance. Hence my request to validate the proposed
> changes.  With luck, things just work, but we better figure out
before
> we upload to unstable.
> 
> This is not pretty, but it is what we have. And then I see this
mostly
> as a work item rather than a blocking issue once we agree on the
other
> matters.

Validating is of course necessary. If the worry is around changing the
dependencies of base-files, I would be happy to carry the dependency on
a new os-release binary package in init-system-helpers, which is
already Essential: yes. I already did something similar in Bookworm to
force all installations to become usrmerged, and I do not recall issues
with the bootstrapping order. This would be even easier in practice as
the new package would have a single file, no maintainer scripts, no
dependencies and no build dependencies. Would that solve your concerns?

-- 
Kind regards,
Luca Boccassi


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

Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"

[Andrea Zagli]

Andrea Zagli  writes:

> Colin Watson  writes:
>
>> (CCing the bug report again so that this is archived)
>>
>> On Fri, Aug 02, 2024 at 04:30:35PM +0200, Andrea Zagli wrote:
>>> i think it's disabled
>>> 
>>> ○ ssh.socket - OpenBSD Secure Shell server socket
>>>  Loaded: loaded (/usr/lib/systemd/system/ssh.socket; disabled; preset: 
>>> enabled)
>>>  Active: inactive (dead)
>>>Triggers: ● ssh.service
>>>  Listen: [::]:22 (Stream)
>>> 
>>> 
>>> the sshd service starts without problems
>>> 
>>> i tried with a clean sshd_config file, but same problem
>>> 
>>> i downgraded openssh to 9.7 and it works
>>
>> In that case I need all the ssh-related log entries you can give me -
>> "journalctl -u ssh.service --lines=1000", /var/log/auth.log, and so on.
>
>
> the only log produced 
>
> ago 02 16:30:11 deimos sshd[27821]: Received signal 15; terminating.
> ago 02 16:30:11 deimos systemd[1]: Stopping ssh.service - OpenBSD Secure 
> Shell server...
> ago 02 16:30:11 deimos systemd[1]: ssh.service: Deactivated successfully.
> ago 02 16:30:11 deimos systemd[1]: Stopped ssh.service - OpenBSD Secure Shell 
> server.
> ago 02 16:30:25 deimos systemd[1]: Starting ssh.service - OpenBSD Secure 
> Shell server...
> ago 02 16:30:25 deimos sshd[32054]: Server listening on 0.0.0.0 port 22.
> ago 02 16:30:25 deimos sshd[32054]: Server listening on :: port 22.
> ago 02 16:30:25 deimos systemd[1]: Started ssh.service - OpenBSD Secure Shell 
> server.
> ago 02 16:30:29 deimos sshd-session[32063]: refused connect from 10.0.0.99 
> (10.0.0.99)
>
>
> last line also on auth.log


i set sshd loglevel to debug3 and i found


ago 02 17:06:21 deimos sshd-session[35156]: debug1: Connection refused by tcp 
wrapper


i have "sshd: ALL" in hosts.allow and "ALL: ALL" in hosts.deny... never
changed these files from years

Bug#1077804: adduser autopkgtest assumes backslash is a valid char

[Chris Hofstaedtler]

Source: adduser
Version: 3.137
Control: affects -1 src:shadow
Severity: serious

Hi,

in #1076619 it was reported that usernames ending with backslashes
break useradd/usermod/userdel, etc (from src:shadow).
Allowing backslashes was a Debian patch. To fix #1076619,
backslashes are now forbidden. However, adduser's autopkgtests
assume that backslashes are good to use.

Please stop using backslashes.

I've filed this as sev: serious, as it prevents the fix for #1076619
from entering testing, and the release-team considers packages
out-of-sync between testing and unstable to have an rc-bug.

Chris

Bug#1077803: transition: recode

[Santiago Vila]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: rec...@packages.debian.org, sanv...@debian.org, 
ui-util...@packages.debian.org
Control: affects -1 + src:recode

Dear Release Managers:

I'd like to request a transition slot to upload recode for unstable
and start this transition. I already did a test rebuild of
affected packages and this is the result:

enca
  -> will need binNMU
fortune-mod
  -> will need binNMU
units-filter
  -> will need binNMU
ui-utilcpp
  -> this one FTBFS and will need a new source upload
  The maintainer, who is also upstream, is aware via Bug #1077768.
  Also: The package is currently *not* in testing,
  I guess this simplifies things.

This is the Ben file generated by reportbug, which seems equivalent
to the one autogenerated in the transition page:

title = "recode";
is_affected = .depends ~ "librecode0" | .depends ~ "librecode3";
is_good = .depends ~ "librecode3";
is_bad = .depends ~ "librecode0";

The only caveat is that the package in experimental has not been built
for s390x yet, but I have checked that the package builds ok in
such architecture using zelenka.debian.org (s390x porter box).

Thanks.

Bug#1077087: bpfcc: please enable build for ppc64el

[Ritesh Raj Sarraf]

On Fri, 2024-07-26 at 14:59 +1200, Vladimir Petko wrote:
> Source: bpfcc
> Version: 0.30.0+ds-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> It seems that build issues for ppc64el are resolved[1]. I have tested
> it by
> building the package in sid ppc64el chroot.
> Would it be possible to consider enabling ppc64el?
> 
> Best Regards,
>  Vladimir.
> 
> [1] https://bugs.launchpad.net/ubuntu/+source/bpfcc/+bug/2074121
> 

Building the software is one part. But does the built software function
proper ? And does upstream support that architecture ?

We'd like to stick to what upstream is doing. So if there's an official
list of supported architectures upstream, we'd be glad to enable them
in Debian as well.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"

[Colin Watson]

On Fri, Aug 02, 2024 at 04:57:55PM +0200, Andrea Zagli wrote:
> Colin Watson  writes:
> > In that case I need all the ssh-related log entries you can give me -
> > "journalctl -u ssh.service --lines=1000", /var/log/auth.log, and so on.
> 
> the only log produced 
> 
> ago 02 16:30:11 deimos sshd[27821]: Received signal 15; terminating.
> ago 02 16:30:11 deimos systemd[1]: Stopping ssh.service - OpenBSD Secure 
> Shell server...
> ago 02 16:30:11 deimos systemd[1]: ssh.service: Deactivated successfully.
> ago 02 16:30:11 deimos systemd[1]: Stopped ssh.service - OpenBSD Secure Shell 
> server.
> ago 02 16:30:25 deimos systemd[1]: Starting ssh.service - OpenBSD Secure 
> Shell server...
> ago 02 16:30:25 deimos sshd[32054]: Server listening on 0.0.0.0 port 22.
> ago 02 16:30:25 deimos sshd[32054]: Server listening on :: port 22.
> ago 02 16:30:25 deimos systemd[1]: Started ssh.service - OpenBSD Secure Shell 
> server.
> ago 02 16:30:29 deimos sshd-session[32063]: refused connect from 10.0.0.99 
> (10.0.0.99)

Are there any entries matching 10.0.0.99 or related to sshd in
/etc/hosts.allow or /etc/hosts.deny?  If so, can I please see them (with
sensitive details edited out if necessary)?

Thanks,

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

Bug#1077802: UDD: janitor service unavailable -- currently disabled

[Lucas Nussbaum]

Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: udd

UDD has an importer for https://janitor.debian.net/.
Unfortunately, the service has been down for some time now.

In the meantime the importer has been removed from UDD's configuration
in commit a13247444876aed518bba5058423ba3a4b932d94

Bug#1077801: UDD: ddtp importer broken -- currently disabled

[Lucas Nussbaum]

Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: udd

The ddtp importer is broken since 2024-06-23 with:

Traceback (most recent call last):
  File "/srv/udd.debian.org/udd//udd.py", line 83, in 
getattr(gatherer, command)()
  File "/srv/udd.debian.org/udd/udd/ddtp_gatherer.py", line 172, in run
self.import_translations(trfile, rel, comp, lang)
  File "/srv/udd.debian.org/udd/udd/ddtp_gatherer.py", line 199, in 
import_translations
for stanza in deb822.Deb822.iter_paragraphs(g, shared_storage=False):
  File "/usr/lib/python3/dist-packages/debian/deb822.py", line 772, in 
iter_paragraphs
x = cls(iterable, fields, encoding=encoding, strict=strict)
  File "/usr/lib/python3/dist-packages/debian/deb822.py", line 685, in __init__
self._internal_parser(iterable, fields, strict)
  File "/usr/lib/python3/dist-packages/debian/deb822.py", line 869, in 
_internal_parser
self[curkey] = content
  File "/usr/lib/python3/dist-packages/debian/deb822.py", line 1264, in 
__setitem__
self.validate_input(key, value)
  File "/usr/lib/python3/dist-packages/debian/deb822.py", line 1260, in 
validate_input
raise ValueError("each line must start with whitespace")
ValueError: each line must start with whitespace

It was removed from UDD's configuration in commit
f5fb17e6a6a23f4424f38903955cf4aeb6ce6f22

Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"

[Andrea Zagli]

Colin Watson  writes:

> (CCing the bug report again so that this is archived)
>
> On Fri, Aug 02, 2024 at 04:30:35PM +0200, Andrea Zagli wrote:
>> i think it's disabled
>> 
>> ○ ssh.socket - OpenBSD Secure Shell server socket
>>  Loaded: loaded (/usr/lib/systemd/system/ssh.socket; disabled; preset: 
>> enabled)
>>  Active: inactive (dead)
>>Triggers: ● ssh.service
>>  Listen: [::]:22 (Stream)
>> 
>> 
>> the sshd service starts without problems
>> 
>> i tried with a clean sshd_config file, but same problem
>> 
>> i downgraded openssh to 9.7 and it works
>
> In that case I need all the ssh-related log entries you can give me -
> "journalctl -u ssh.service --lines=1000", /var/log/auth.log, and so on.


the only log produced 

ago 02 16:30:11 deimos sshd[27821]: Received signal 15; terminating.
ago 02 16:30:11 deimos systemd[1]: Stopping ssh.service - OpenBSD Secure Shell 
server...
ago 02 16:30:11 deimos systemd[1]: ssh.service: Deactivated successfully.
ago 02 16:30:11 deimos systemd[1]: Stopped ssh.service - OpenBSD Secure Shell 
server.
ago 02 16:30:25 deimos systemd[1]: Starting ssh.service - OpenBSD Secure Shell 
server...
ago 02 16:30:25 deimos sshd[32054]: Server listening on 0.0.0.0 port 22.
ago 02 16:30:25 deimos sshd[32054]: Server listening on :: port 22.
ago 02 16:30:25 deimos systemd[1]: Started ssh.service - OpenBSD Secure Shell 
server.
ago 02 16:30:29 deimos sshd-session[32063]: refused connect from 10.0.0.99 
(10.0.0.99)


last line also on auth.log

Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"

[Colin Watson]

(CCing the bug report again so that this is archived)

On Fri, Aug 02, 2024 at 04:30:35PM +0200, Andrea Zagli wrote:
> i think it's disabled
> 
> ○ ssh.socket - OpenBSD Secure Shell server socket
>  Loaded: loaded (/usr/lib/systemd/system/ssh.socket; disabled; preset: 
> enabled)
>  Active: inactive (dead)
>Triggers: ● ssh.service
>  Listen: [::]:22 (Stream)
> 
> 
> the sshd service starts without problems
> 
> i tried with a clean sshd_config file, but same problem
> 
> i downgraded openssh to 9.7 and it works

In that case I need all the ssh-related log entries you can give me -
"journalctl -u ssh.service --lines=1000", /var/log/auth.log, and so on.

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

Bug#1077800: mutter: flaky test basic-x11: In pixman_region32_init_rect: Invalid rectangle passed; cogl_texture_2d_new_from_data: assertion 'data != NULL' failed

[Simon McVittie]

On Fri, 02 Aug 2024 at 15:02:14 +0100, Simon McVittie wrote:
> Please consider other
> failures to be out-of-scope here unless there is evidence that they share
> a root cause.

Actually, the first few of the other ppc64el failures that I looked at
(in the "stacking" test suite) seem like they might have the same root
cause after all, for example:

> # mutter-test-runner-DEBUG: 
> closed-transient-no-input-no-take-focus-parent.metatest:3: 'show 1/1'
> # mutter-test-runner-DEBUG: 
> closed-transient-no-input-no-take-focus-parent.metatest:5: 'create 1/2 csd'
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
> 
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
> 
> Bail out! FATAL-CRITICAL: cogl_texture_2d_new_from_data: assertion 'data != 
> NULL' failed
> (EE) failed to read Wayland events: Connection reset by peer
> ――
> 152/185 mutter:core+mutter/stacking / 
> closed-transient-no-input-no-take-focus-parent   FAIL 
> 2.69s   (exit status 251 or signal 123 SIGinvalid)

So I'd suggest that our debugging efforts concentrate on basic-x11
for now, because this failure mode has been seen in that test even on
amd64, and its name suggests that it might be quite ... basic. And then
hopefully if we can figure out a solution for that one, it will also
fix the intermittent failures in the stacking suite on ppc64el. If not,
we can look at any remaining failures separately.

smcv

Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"

[Colin Watson]

On Fri, Aug 02, 2024 at 03:47:02PM +0200, Andrea Zagli wrote:
> *** Reporter, please consider answering these questions, where appropriate ***

There isn't enough information in this bug for me to go on as yet.
Please tell me any custom configuration that you have.  In particular,
are you using socket activation (#1077765)?

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

Bug#833256: util-linux: Please use login/passwd implementations provided by util-linux

[Luca Boccassi]

On Fri, 2 Aug 2024 at 14:51, Chris Hofstaedtler  wrote:
>
> Control: block -1 by 1074394
>
> Hi Luca,
>
> * Luca Boccassi  [240802 15:09]:
> > What's the state on this?
>
> Package: login currently provides these separate interfaces:
>
> * /usr/bin/login
> * /usr/bin/newgrp
> * /usr/bin/sg
> * /usr/sbin/nologin
>
> For these 4, I need to reread this bug and see if util-linux has
> direct replacements.
>
> * /etc/login.defs
>
> Getting this out of Package: login is #1074394, added a block.
>
> > Any chance we can get util-linux's login in
> > for trixie?
>
> Unsure. Lets see if time permits it.
>
> > Some folks have done a _ton_ of work to make util-linux's
> > login work nicely with autologin for containers and VMs with zero guest
> > configuration, using systemd credentials over smbios and such things.
> > It would be great if we could reap the benefits of this in trixie.
>
> Is this all already part of Debian's util-linux or will it become
> part of a newer release or sth else?

It's all part of the latest releases of util-linux and systemd

Bug#1072063: one of the external monitors randomly blank for 2-3 seconds with 6.8/6.9 Linux kernels (regression)

[Vincent Lefevre]

Control: found -1 6.9.12-1
Control: forwarded -1 
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11821

On 2024-07-31 20:21:12 +0200, Ben Hutchings wrote:
> Could you please report this upstream following
> ?

Done: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11821

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

Bug#1077800: mutter: flaky test basic-x11: In pixman_region32_init_rect: Invalid rectangle passed; cogl_texture_2d_new_from_data: assertion 'data != NULL' failed

[Simon McVittie]

Source: mutter
Version: 46.3.1-7
Severity: important
Tags: ftbfs
User: debian...@lists.debian.org
Usertags: flaky

The build-time tests for mutter 46.3.1-7 failed once on amd64, and three
times on ppc64el, before succeeding after a bunch of retries. This bug
report is about the failure that was seen on amd64, which was also seen
(among others) in two of the three ppc64el failures. Please consider other
failures to be out-of-scope here unless there is evidence that they share
a root cause.

Part of the test log from amd64:

> # 1..1
> # libmutter-MESSAGE: Added virtual monitor Meta-0
> # mutter-test-runner-DEBUG: basic-x11.metatest:1: 'new_client 1 x11'
> Xwayland glamor: GBM Wayland interfaces not available
> Failed to initialize glamor, falling back to sw
> # mutter-test-runner-DEBUG: basic-x11.metatest:2: 'create 1/1'
> MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
> libEGL warning: egl: failed to create dri2 screen
> # mutter-test-runner-DEBUG: basic-x11.metatest:3: 'show 1/1'
> # mutter-test-runner-DEBUG: basic-x11.metatest:4: 'create 1/2'
> # mutter-test-runner-DEBUG: basic-x11.metatest:5: 'show 1/2'
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
> 
> *** BUG ***
> In pixman_region32_init_rect: Invalid rectangle passed
> Set a breakpoint on '_pixman_log_error' to debug
> 
> Bail out! FATAL-CRITICAL: cogl_texture_2d_new_from_data: assertion 'data != 
> NULL' failed

The reason for failure is the cogl_texture_2d_new_from_data assertion
failure (something passed an invalid argument to that function), but the
pixman assertion failures are probably related.

I imagine that this must be timing-related, and it will probably also
happen intermittently in autopkgtests (I think we run essentially the same
set of tests in both places).

smcv

Bug#1077799: openssh-server: cannot login anymore: error "kex_exchange_identification: read: Connection reset by peer"

[Andrea Zagli]

Package: openssh-server
Version: 1:9.8p1-1
Severity: important

Dear Maintainer,

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

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

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


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

Kernel: Linux 6.9.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 openssh-server depends on:
ii  adduser   3.137
ii  debconf [debconf-2.0] 1.5.87
ii  init-system-helpers   1.66
ii  libaudit1 1:3.1.2-4+b1
ii  libc6 2.39-6
ii  libcom-err2t64 [libcom-err2]  1.47.0-2.3+b1
ii  libcrypt1 1:4.4.36-4
ii  libgssapi-krb5-2  1.21.3-3
ii  libkrb5-3 1.21.3-3
ii  libpam-modules1.5.3-7
ii  libpam-runtime1.5.3-7
ii  libpam0g  1.5.3-7
ii  libselinux1   3.5-2+b3
ii  libssl3t643.2.2-1
ii  libwrap0  7.6.q-33
ii  lsb-base  11.6
ii  openssh-client1:9.8p1-1
ii  openssh-sftp-server   1:9.8p1-1
ii  procps2:4.0.4-5
ii  runit-helper  2.16.3
ii  sysvinit-utils [lsb-base] 3.09-2
ii  ucf   3.0043+nmu1
ii  zlib1g1:1.3.dfsg+really1.3.1-1

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  256.4-2
ii  ncurses-term 6.5-2
ii  xauth1:1.1.2-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  ssh-askpass   
pn  ufw   

-- debconf information excluded

Bug#833256: util-linux: Please use login/passwd implementations provided by util-linux

[Chris Hofstaedtler]

Control: block -1 by 1074394

Hi Luca,

* Luca Boccassi  [240802 15:09]:
> What's the state on this?

Package: login currently provides these separate interfaces:

* /usr/bin/login
* /usr/bin/newgrp
* /usr/bin/sg
* /usr/sbin/nologin

For these 4, I need to reread this bug and see if util-linux has
direct replacements.

* /etc/login.defs

Getting this out of Package: login is #1074394, added a block.

> Any chance we can get util-linux's login in
> for trixie?

Unsure. Lets see if time permits it.

> Some folks have done a _ton_ of work to make util-linux's
> login work nicely with autologin for containers and VMs with zero guest
> configuration, using systemd credentials over smbios and such things.
> It would be great if we could reap the benefits of this in trixie.

Is this all already part of Debian's util-linux or will it become
part of a newer release or sth else?

Chris

Bug#1077788: clblas: autopkgtest regressions with gcc-14

[Gianfranco Costamagna]

Hello, I found another issue on non amd64,

From 05afa5dd63ece9c6e43b40705f3c7dc1a9e6049e Mon Sep 17 00:00:00 2001
From: Gianfranco Costamagna 
Date: Fri, 2 Aug 2024 15:40:39 +0200
Subject: [PATCH] Update example_csscal.c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

with gcc-14 this warning becomes a failure

 90s /tmp/autopkgtest.g0L4Ek/autopkgtest_tmp/example_csscal.c: In function 
‘main’:
 90s /tmp/autopkgtest.g0L4Ek/autopkgtest_tmp/example_csscal.c:67:26: error: 
implicit declaration of function ‘abs’ [-Wimplicit-function-declaration]
 90s67 | int lenX = 1 + (N-1)*abs(incx);
 90s   |  ^~~
 90s /tmp/autopkgtest.g0L4Ek/autopkgtest_tmp/example_csscal.c:26:1: note: include 
‘’ or provide a declaration of ‘abs’
 90s25 | #include 
 90s   +++ |+#include 
 90s26 |
 90s /tmp/autopkgtest.g0L4Ek/autopkgtest_tmp/example_csscal.c:89:5: warning: 
‘clCreateCommandQueue’ is deprecated [-Wdeprecated-declarations]
 90s89 | queue = clCreateCommandQueue(ctx, device, 0, );
 90s   | ^
---
 src/samples/example_csscal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/samples/example_csscal.c b/src/samples/example_csscal.c
index c78bc550..c03030f3 100644
--- a/src/samples/example_csscal.c
+++ b/src/samples/example_csscal.c
@@ -16,6 +16,7 @@
 
 #include 

 #include 
+#include 
 #include 
 #include 
 



Already reported upstream.

G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1077798: Reverse dependency build fails with Imported target "PkgConfig::QALCULATE" includes non-existent path "/usr/include/p11-kit-1"

[Aurélien COUDERC]

Package: libqalculate-dev
Version: 5.2.0.1-1
Severity: important
X-Debbugs-Cc: Debian Qt/KDE Maintainers 

Dear Maintainer,

since 5.2.0.1-1, plasma-workspace fails to build with the following
error message:

CMake Error in runners/calculator/CMakeLists.txt:
  Imported target "PkgConfig::QALCULATE" includes non-existent path

"/usr/include/p11-kit-1"

  in its INTERFACE_INCLUDE_DIRECTORIES. […]


This is due to libqalculate’s pc file now referencing p11-kit, which it
wasn’t until 5.1.1-2.

$ grep p11-kit /usr/lib/x86_64-linux-gnu/pkgconfig/libqalculate.pc 
Cflags: -I/usr/include/x86_64-linux-gnu -I/usr/include/p11-kit-1   
-I${includedir}


The libp11-kit-dev package is pulled transitively via libgnutls28-dev by
your libcurl4-gnutls-dev build dependency.

As far as I can tell the build dependency chain was already there down
to libp11-kit-dev until your previous upload, and I couldn’t make out
why it’s appearing in libqalculate’s pc file just now…


Could you please have a look and fix this issue ? We could work around
it by adding libp11-kit-dev to our build deps but it doesn’t look like
a valid solution.


Thank you.
--
Aurélien



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

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

Versions of packages libqalculate-dev depends on:
ii  libcln-dev  1.3.7-1
ii  libmpfr-dev 4.2.1-1+b1
ii  libqalculate23  5.2.0.1-1
ii  libxml2-dev 2.12.7+dfsg-3+b1

libqalculate-dev recommends no packages.

libqalculate-dev suggests no packages.

-- no debconf information

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Fri, 2 Aug 2024 at 13:00, Simon McVittie  wrote:
>
> On Fri, 02 Aug 2024 at 12:19:20 +0100, Luca Boccassi wrote:
> > To further clarify why the status quo with VERSION_CODENAME=trixie in
> > sid is really bad: it used to be that if you had "debian" mentioned in
> > os-release but no other version identifying fields, you knew you were
> > on testing OR unstable and you'd have to deploy horrendous hacks to
> > attempt and figure out which of the two it was really.
>
> OK, I think this is progress:
>
> What is the scenario / use-case in which it becomes necessary to
> distinguish between those two suites?
>
> To put that another way, what external piece of software needs to
> change its behaviour, dependent on whether you are running testing
> (of an unspecified datestamp) or unstable (of an unspecified datestamp)?
>
> Or perhaps you are thinking of a scenario in which a *person* needs to
> change their behaviour, dependent on whether they are running testing
> or unstable?

Are the examples I provided at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#43
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#5

enough to answer this question? (I'm trying to avoid copy/pasting the
same stuff multiple times in an already long and
probably-going-to-be-even-longer thread)

> > Sorry, but there's no other way to define this than a bug.
>
> I would personally characterize it as a potential root cause for bugs,
> more than as a bug itself. To me, an example of one of those bugs might
> look more like "I run ansible/Puppet/etc. against my test VM, and I
> expect it to do a useful thing, but actually it..." (with the buggy result
> perhaps being to crash, or to install the wrong package, or something).

It's not running code, but we consider mistakes in documentation bugs
too, and treat them as such in our tools and processes. A wrong
implementation of a specification, that results in wrong text being
published, should still qualify as a bug given precedents, even if
it's not in itself running code. It might or might not cause other
bugs/bad behaviour, but that should be orthogonal.