Bug#1033900: pre-approval: dkms/3.0.10-10

2023-05-04 Thread Paul Gevers

Control: tags -1 moreinfo

Hi Andreas,

On 27-04-2023 18:53, Andreas Beckmann wrote:
So unless 
something else appears that warrants an unblock, let's not do this.

   ^^^


I've just uploaded a new upstream release 3.0.11-1 with some additional
bugfixes to experimental. Most patches are now applied upstream.


While you elaborated how you created a nice debdiff, you forgot to tell 
why a new upstream release is a targeted fix. What is it fixing? (Does 
this really follow the freeze policy?)


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1035539: unblock: binutils-mingw-w64/10.4

2023-05-04 Thread Stephen Kitt
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear release team,

Please unblock package binutils-mingw-w64.

[ Reason ]
Version 10.4 includes a two-line upstream fix for a crash when
handling certain import libraries.

[ Impact ]
Users with affected libraries can’t use Bookworm’s binutils-mingw-w64
at all; this is a regression from Bullseye.

[ Tests ]
The reporter of https://bugs.debian.org/1029841 provided a test case;
see also https://sourceware.org/bugzilla/show_bug.cgi?id=30079

[ Risks ]
The fix is tiny:

diff --git a/ld/ldlang.c b/ld/ldlang.c
index 84a2914fc26..b5e0d026ae4 100644
--- a/upstream/ld/ldlang.c
+++ b/upstream/ld/ldlang.c
@@ -649,7 +649,8 @@ wild_sort (lang_wild_statement_type *wild,
 looking at the sections for this file.  */
 
   /* Find the correct node to append this section.  */
-  if (compare_section (sec->spec.sorted, section, (*tree)->section) < 0)
+  if (sec && sec->spec.sorted != none && sec->spec.sorted != by_none
+ && compare_section (sec->spec.sorted, section, (*tree)->section) < 0)
tree = &((*tree)->left);
   else
tree = &((*tree)->right);

The risk is minute.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock binutils-mingw-w64/10.4


Regards,

Stephen
diff -Nru binutils-mingw-w64-10.3/debian/changelog 
binutils-mingw-w64-10.4/debian/changelog
--- binutils-mingw-w64-10.3/debian/changelog2023-01-11 13:02:20.0 
+0100
+++ binutils-mingw-w64-10.4/debian/changelog2023-05-03 08:49:22.0 
+0200
@@ -1,3 +1,9 @@
+binutils-mingw-w64 (10.4) unstable; urgency=medium
+
+  * Apply upstream patch to fix an internal error. Closes: #1029841.
+
+ -- Stephen Kitt   Wed, 03 May 2023 08:49:22 +0200
+
 binutils-mingw-w64 (10.3) unstable; urgency=medium
 
   * Drop another failing codeview test.
diff -Nru binutils-mingw-w64-10.3/debian/patches/pr30079.patch 
binutils-mingw-w64-10.4/debian/patches/pr30079.patch
--- binutils-mingw-w64-10.3/debian/patches/pr30079.patch1970-01-01 
01:00:00.0 +0100
+++ binutils-mingw-w64-10.4/debian/patches/pr30079.patch2023-05-03 
08:49:22.0 +0200
@@ -0,0 +1,26 @@
+commit b7eab2a9d4f4e92692daf14b09fc95ca11b72e30
+Author: Michael Matz 
+Date:   Thu Feb 9 15:29:00 2023 +0100
+
+Fix PR30079: abort on mingw
+
+the early-out in wild_sort is not enough, it might still be
+that filenames are equal _and_ the wildcard list doesn't specify
+a sort order either.  Don't call compare_section then.
+
+Tested on all targets.
+
+diff --git a/ld/ldlang.c b/ld/ldlang.c
+index 84a2914fc26..b5e0d026ae4 100644
+--- a/upstream/ld/ldlang.c
 b/upstream/ld/ldlang.c
+@@ -649,7 +649,8 @@ wild_sort (lang_wild_statement_type *wild,
+looking at the sections for this file.  */
+ 
+   /* Find the correct node to append this section.  */
+-  if (compare_section (sec->spec.sorted, section, (*tree)->section) < 0)
++  if (sec && sec->spec.sorted != none && sec->spec.sorted != by_none
++&& compare_section (sec->spec.sorted, section, (*tree)->section) < 0)
+   tree = &((*tree)->left);
+   else
+   tree = &((*tree)->right);
diff -Nru binutils-mingw-w64-10.3/debian/patches/series 
binutils-mingw-w64-10.4/debian/patches/series
--- binutils-mingw-w64-10.3/debian/patches/series   2021-10-25 
10:49:54.0 +0200
+++ binutils-mingw-w64-10.4/debian/patches/series   2023-05-03 
08:46:34.0 +0200
@@ -3,3 +3,4 @@
 dont-run-objcopy.patch
 disable-flags.patch
 reproducible-import-libraries.patch
+pr30079.patch


Bug#1035538: nautilus: Missing dependency on "eject" package

2023-05-04 Thread Andrew Ruthven
Package: nautilus
Version: 43.2-1
Severity: important

Dear Maintainer,

If the eject package isn't installed, when you try to eject a USB device
(I didn't test anything else), then Nautilus is unable to eject the device
and throws up an error like:

Error ejecting /dev/sda: Error spawning command-line `eject '/dev/sda'': Failed 
to execute chidl process "eject" (No such file or directory) 
(g-exec-error-quark, 8).

I reckon that the natilus package should depend on the eject package.

Cheers,
Andrew

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

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

Versions of packages nautilus depends on:
ii  bubblewrap  0.8.0-2
ii  desktop-file-utils  0.26-1
ii  gsettings-desktop-schemas   43.0-1
ii  gvfs1.50.3-1
ii  libadwaita-1-0  1.2.2-1
ii  libc6   2.36-9
ii  libcairo2   1.16.0-7
ii  libcloudproviders0  0.3.1-2
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libgexiv2-2 0.14.0-1+b1
ii  libglib2.0-02.74.6-2
ii  libglib2.0-data 2.74.6-2
ii  libgnome-autoar-0-0 0.4.3-1
ii  libgnome-desktop-4-243.2-2
ii  libgstreamer-plugins-base1.0-0  1.22.0-3
ii  libgstreamer1.0-0   1.22.0-2
ii  libgtk-4-1  4.8.3+ds-2
ii  libnautilus-extension4  43.2-1
ii  libpango-1.0-0  1.50.12+ds-1
ii  libportal-gtk4-10.6-4
ii  libportal1  0.6-4
ii  libselinux1 3.4-1+b5
ii  libtracker-sparql-3.0-0 3.4.2-1
ii  nautilus-data   43.2-1
ii  shared-mime-info2.2-1
ii  tracker 3.4.2-1
ii  tracker-extract 3.4.3-1
ii  tracker-miner-fs3.4.3-1

Versions of packages nautilus recommends:
ii  gnome-sushi   43.0-2
ii  gvfs-backends 1.50.3-1
pn  libgdk-pixbuf2.0-bin  
ii  librsvg2-common   2.54.5+dfsg-1

Versions of packages nautilus suggests:
ii  eog 43.2-1
ii  evince [pdf-viewer] 43.1-2+b1
pn  nautilus-extension-brasero  
ii  nautilus-sendto 3.8.6-3.1
ii  totem   43.0-2
ii  vlc [mp3-decoder]   3.0.18-2
ii  xdg-user-dirs   0.18-1

-- no debconf information



Bug#1035537: split -n k/N gives incorrect data on blocks after the first

2023-05-04 Thread Chris Frey
Package: coreutils
Version: 8.32-4+b1

This bug exists in both Debian Buster and Debian Bullseye.

It has been fixed in upstream.

It can be reproduced by splitting a file such that size of each
chunk produced by split is larger than the block size used to read
the files (io_blksize(), bufsize, in split.c).

Example:

# create source file
dd if=/dev/urandom of=/tmp/datafile bs=317634560 count=1

# create known good chunks
split -n 635 /tmp/datafile /tmp/datafile.

# attempt to extract one of the chunks using -n
split -n 4/635 /tmp/datafile > /tmp/chunk4

# compare - this will fail
cmp /tmp/datafile.ad /tmp/chunk4

The reason is that when bytes_chunk_extract() is called, the previous
call to input_file_size() has already read bufsize bytes and left
the file pointer there.  Then bytes_chunk_extract() performs an
lseek(fd, start, SEEK_CUR) using its calculated offset "start",
and seeks past the real start point.

Here's the fix against Debian Buster, but the same can be done on Bullseye.
Upstream has an extra if statement, but is unnecessary since it is already
handled by the surrounding if(start < initial_read) check.  We are
in the else statement, so we know start >= initial_read.


diff -ru coreutils-8.30/src/split.c coreutils-8.30-chunk-fix/src/split.c
--- coreutils-8.30/src/split.c  2018-05-14 00:20:24.0 -0400
+++ coreutils-8.30-chunk-fix/src/split.c2023-05-04 22:31:29.521398067 
-0400
@@ -1000,7 +1000,7 @@
 }
   else
 {
-  if (lseek (STDIN_FILENO, start, SEEK_CUR) < 0)
+  if (lseek (STDIN_FILENO, start - initial_read, SEEK_CUR) < 0)
 die (EXIT_FAILURE, errno, "%s", quotef (infile));
   initial_read = SIZE_MAX;
 }



Bug#1035536: codemirror-js: Codemirror 6 is now available

2023-05-04 Thread Wookey
Source: codemirror-js
Version: 5.65.0+~cs5.83.9-2
Severity: normal
Tags: upstream

uscan and the tracking system indicate that v5.65.13 is available,
but more significantly codemirror 6 is available too (since june 2022):
https://marijnhaverbeke.nl/blog/codemirror-6.html
https://discuss.codemirror.net/t/codemirror-6-0-has-been-released/4498
You probably already know this, but I thought it worth filing a bug as
tracker.debian.org does not know about v6 so gives a misleading
impression about the state of the package with respect to upstream
versions.

v6 is a complete rewrite but is also the current stable version.
It would be good to see it in Debian in the not too distant.
What's a bit confusing is exactly where one gets an upstream v6
release from as the project seems to have been split up into multiple
repos.

-- 
Wookey



Bug#1035535: Debian 11 -> 12: manual "apt install" needed to update some packages (vkd3d, appindicator, wx)

2023-05-04 Thread kolafl...@kolahilft.de

Package: upgrade-reports

I upgraded my system from Debian 11 to 12 some days ago.
But "apt dist-upgrade" didn't upgrade some packages. So I had to do it 
manually. Should it be that way?


  apt install \
vkd3d-compiler/bookworm \
libvkd3d-dev/bookworm \
libvkd3d-dev:i386/bookworm \
libappindicator1/bookworm

By this the vkd3d packages where upgraded to bookworm and 
libappindicator1 was replaced with libayatana-appindicator1 and 
libayatana-indicator7.



I also had wx3.0-headers installed.
And I had to install the new +version manually.

  apt install wx3.2-headers


Maybe related:
My "apt dist-upgrade" from Debian 11 to 12 ended with an error.
See here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994081#32


OpenPGP_0xEA831012D83C3408.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1035489: krb5-config: missing dependency to C compiler

2023-05-04 Thread Moessbauer, Felix
On Thu, 2023-05-04 at 09:21 -0700, Russ Allbery wrote:
> Sam Hartman  writes:
> 
> > We could represent this as a dependency or a recommends if there is
> > some
> > special reason that libkrb5-dev needs the dependency.  krb5-config
> > not
> > working alone is not enough to justify a depends relationship: as I
> > understand it (Russ please correct me if I'm getting this wrong
> > from
> > memory), the policy requirement is not that every program in a
> > package
> > work with the installed dependencies, but that the package as a
> > whole
> > work.
> 
> Right, the requirement is that the core functionality work, but some
> things may not unless Recommends and Suggests are met.  But we don't
> put
> Recommends and Suggests of compilers on every *-dev package either,
> so I
> think *-dev packages are a bit of an unenumerated special case.

Agree. I found this issue in a more complex dependency chain of python
packages, where one package called this tool during during the build of
the wheel (pip of course...). In the end, `krb5-config --cflags krb5`
was called, which will definitely be consumed by a c compiler (and by
that build-essential should be installed anyways).

However, when looking at the manpage of krb5-config, not all options
are actually related to the build environment. That's why I opened this
issue, as the tool cannot be used at all in case no compiler is
installed. If this is acceptable according to the debian policies, we
can also close this bug.

> 
> > I.E.  I could say that we care far more about the pkgconfig .pc
> > files,
> > krb5-config is legacy, and so policy does not force us to depend on
> > a
> > compiler even though krb5-config is kind of useless without it.
> 
> I would argue that the pkgconfig .pc files are also fairly useless
> without
> a compiler, just with one more step of separation.  :)  I could

IMHO this is somehow different, as .pc files are basically just
configuration and the pkg-config tool also works without having a build
environment.

> imagine
> theoretical use cases where one wanted to inspect what flags would be
> recommended without using them on that system, but I would want to
> know
> that someone encountered that situation in the real world before
> worrying
> too much about it.
> 
> My personal experience watching folks who are new to Debian who want
> to
> compile something is that they encounter the missing toolchain
> somewhat
> randomly and attribute that to somewhat random missing dependencies
> until
> someone points out they should just install build-essential if
> they're
> going to be compiling software, and then they encode that in their
> normal
> practices and resolve the problem that way.  This isn't the most
> user-friendly setup, to be sure, but I wonder if the path is to more
> prominently document that people should install build-essential or
> the
> equivalent if they're going to be building software, rather than
> adding
> individual dependencies.

Agree.

Felix

> 
> If we go down the dependency route, IMO it should be handled by
> debhelper
> or similar machinery; I don't think libkrb5-dev is particularly
> special in
> this regard, so fixing this in the krb5 package feels wrong to me.
> 
> > There does appear to be a c-compiler virtual package.
> > We could depend on gcc|c-compiler.
> 
> Oh, there is indeed, sorry.  I missed that because I was looking at
> the
> clang package instead of the clang-16 package.
> 



Bug#1035534: coreutils: pr: -s broken entirely?

2023-05-04 Thread наб
Package: coreutils
Version: 8.32-4+b1
Version: 9.1-1
Severity: normal

Dear Maintainer,

POSIX says (lines 1003.1-202x/D3):
-- >8 --
110789  −s[char]  Separate text columns by the single character char instead of 
by the appropriate
110790number of  characters (default for char shall be 
).

110817  LC_CTYPE  Determine the locale for the interpretation of sequences of 
bytes of text data as
110818characters (for example, single-byte as opposed to multi-byte 
characters in
110819arguments and input files) and which characters are defined 
as printable (character
110820class print). Non-printable characters are still written to 
standard output, but are
110821not counted for the purpose for column-width and line-length 
calculations.
-- >8 --

So how does this map onto
-- >8 --
% pr -w22 -2 -s | cat -As
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
$
2023-05-05 03:16  Page 1$
$
abcdefghijkabcdefghijk$
$
% pr -w22 -2 -s'' | cat -As
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
$
2023-05-05 03:16  Page 1$
$
abcdefghij abcdefghij$
$
-- >8 --
(that's a literal tab in the second one).

Not only ought these to be the same,
in the first one the separator is lost,
and in the second it's turned into a space.

The correct output for both is, naturally,
  abcdefghijk^Iabcdefghijk$

Oddly, specifying -sQ behaves as expected.

Best,
наб

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b5

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#1035533: coreutils: pr: manual says -F changes header depth

2023-05-04 Thread наб
Package: coreutils
Version: 9.1-1
Severity: normal

Dear Maintainer,

The manual says
   -F, -f, --form-feed
  use form feeds instead of  newlines  to  separate  pages  (by  a
  3-line  page header with -F or a 5-line header and trailer with‐
  out -F)

This doesn't hold, which is good, because it'd diverge from SysVr4
and be a POSIX violation, but still.

Best,
наб

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b5

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#1035331: jackd2: reproducible-builds: Locale and timezone dependent date in manpages

2023-05-04 Thread Nicholas D Steeves
Vagrant Cascadian  writes:

> On 2023-05-04, Nicholas D Steeves wrote:
>> By the way, were any of the jackd2 patches forwarded upstream?
>
> I did not. Would be happy if you could; could also take it on if
> needed...
>

Done.


signature.asc
Description: PGP signature


Bug#1035532: unblock: alsa-tools/1.2.5-3

2023-05-04 Thread Jordi Mallach
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: alsa-to...@packages.debian.org
Control: affects -1 + src:alsa-tools

Please unblock package alsa-tools

As reported in #1035104, alsa-tools-gui is missing a dependency on
pkexec, which is required by one of the included tools.

[ Reason ]

This fixes a RC bug in alsa-tools-gui.

[ Impact ]

One of the tools is unable to work properly, without useful
indication to the user of that fact.

[ Tests ]

The main change is the addition of the missing dependency on pkexec.

[ Risks ]

Adding pkexec to -tools-gui dependencies adds a setuid binary to the
system, in the case it wasn't installed already.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

This update includes a couple minor packaging changes that had been waiting
in the git repo for over a year:

- the addition of the upstream signing key
- the removal of two obsolete documents (d/NOTES and d/changelog.ALSA,
  which was a dump of the upstream git log and wasn't being updated since
  2016)

unblock alsa-tools/1.2.5-3
diff -Nru alsa-tools-1.2.5/debian/changelog alsa-tools-1.2.5/debian/changelog
--- alsa-tools-1.2.5/debian/changelog   2021-09-09 02:28:58.0 +0200
+++ alsa-tools-1.2.5/debian/changelog   2023-05-05 00:35:19.0 +0200
@@ -1,3 +1,13 @@
+alsa-tools (1.2.5-3) unstable; urgency=medium
+
+  * Drop changelog.ALSA.
+  * Drop obsolete debian/NOTES.
+  * Import upstream signing key and configure watch file to check for
+sigs.
+  * Add pkexec to alsa-tools-gui's Depends (closes: #1035104).
+
+ -- Jordi Mallach   Fri, 05 May 2023 00:35:19 +0200
+
 alsa-tools (1.2.5-2) unstable; urgency=medium
 
   * Install AppStream metadata in /usr/share/metainfo.
diff -Nru alsa-tools-1.2.5/debian/changelog.ALSA 
alsa-tools-1.2.5/debian/changelog.ALSA
--- alsa-tools-1.2.5/debian/changelog.ALSA  2019-11-07 00:42:01.0 
+0100
+++ alsa-tools-1.2.5/debian/changelog.ALSA  1970-01-01 01:00:00.0 
+0100
@@ -1,3136 +0,0 @@
-commit b01cf30
-Author: Jaroslav Kysela 
-Date:   Tue Dec 20 10:12:29 2016 +0100
-
-  * Release v1.1.3
-
-commit 70118f5
-Author: Michel Normand 
-Date:   Mon Jun 20 15:26:06 2016 +0200
-
-  * gcc6 narrowing error
-
-commit 44f3750
-Author: Jaroslav Kysela 
-Date:   Tue Oct 27 14:34:05 2015 +0100
-
-  * Release v1.1.0
-
-commit ed9c1b7
-Author: Takashi Iwai 
-Date:   Fri Oct 2 12:41:02 2015 +0200
-
-  * Add */compile to .gitignore
-
-commit 8a241fa
-Author: Takashi Iwai 
-Date:   Fri Oct 2 12:38:33 2015 +0200
-
-  * Add some hdajacksensetest/* files to .gitignore
-
-commit 471ba9b
-Author: Stéphane Aulery 
-Date:   Wed Mar 25 18:38:53 2015 +0100
-
-  * cspctl.1: remove ".LO" macro. This macro don't exist for manpages
-syntax.
-
-commit 42b826d
-Author: Jaroslav Kysela 
-Date:   Thu Feb 26 13:35:49 2015 +0100
-
-  * Release v1.0.29
-
-commit 9dca16c
-Author: David Henningsson 
-Date:   Tue Jan 13 09:12:29 2015 +0100
-
-  * hdajackretask: Add dock hp/mic/line to simple options
-
-commit 7a7d94a
-Author: David Henningsson 
-Date:   Mon Oct 6 15:30:03 2014 +0200
-
-  * Add a small "hdajacksensetest" helper
-
-commit eb6408a
-Author: David Henningsson 
-Date:   Fri Aug 1 16:20:30 2014 +0200
-
-  * hdajackretask: Add "hints" functionality
-
-commit 406f80c
-Author: Takashi Iwai 
-Date:   Fri Jun 27 16:48:33 2014 +0200
-
-  * ld10k1: Fix missing parentheses for functions
-
-commit c3eb625
-Author: Jaroslav Kysela 
-Date:   Fri Jun 13 11:28:13 2014 +0200
-
-  * Release v1.0.28
-
-commit 1e7b618
-Author: Jaroslav Kysela 
-Date:   Fri Jun 13 11:26:43 2014 +0200
-
-  * qlo10k1: packing fix (configure.ac)
-
-commit 07896d3
-Author: Jaroslav Kysela 
-Date:   Thu Jun 12 11:28:22 2014 +0200
-
-  * Modernize configure.ac
-
-commit ab01047
-Author: David Henningsson 
-Date:   Tue May 27 09:12:36 2014 +0200
-
-  * hdajackretask: Make sure codecs do not show up twice under 3.15
-kernel
-
-commit f3c2688
-Author: Adrian Knoth 
-Date:   Sat Jan 4 21:38:23 2014 +0100
-
-  * hdspmixer: Add support for RME AIO AEB boards
-
-commit 772fbde
-Author: David Henningsson 
-Date:   Thu Jun 13 16:26:43 2013 +0200
-
-  * hdajackretask: Fix killing PulseAudio on newer PulseAudio versions
-
-commit 472c414
-Author: Jordi Mallach 
-Date:   Wed May 15 19:19:11 2013 +0200
-
-  * Add AM_MAINTAINER_MODE([enable]) macro to all configure scripts.
-
-commit e79e201
-Author: Jordi Mallach 
-Date:   Wed May 15 19:19:09 2013 +0200
-
-  * Fix build errors caused by -Werror=format-security.
-
-commit a172825
-Author: Elimar Riesebieter 
-Date:   Wed May 15 19:19:07 2013 +0200
-
-  * Fix bashisms.
-
-commit c1fdd75
-Author: Jordi Mallach 
-Date:   Wed May 15 19:19:08 2013 +0200
-
-  * Fix spelling of “successfully”.
-
-commit 2fcce93
-Author: Elimar Riesebieter 
-Date:   Wed May 15 19:19:05 2013 +0200
-
-  

Bug#1035096: installation-report Bookworm RC2 GRUB not installed

2023-05-04 Thread Peter Ehlert



On May 4, 2023 3:35:40 PM Pascal Hambourg  wrote:


On 04/05/2023 at 16:21, Peter Ehlert wrote:


"Install the GRUB boot loader" menu ... 6 items
Enter device manually
/dev/sda (usb-SanDisk ...
/dev/sdb (ata-WL4000G ...
/dev/sdc (ata-WDC_WD300...
/dev/sdd (ata-WDC_WD300...
/dev/sde (ata-SanDisk_SDSSDA240G_162248447811)


I selected /dev/sde and pressed the Continue button

then the GUI progress bar Installing GRUB and I see Running
"grub-install /dev/sdd" ...

in this case sdd was the install location, sde is the drive that has a
bios_grub flagged partition


OK, I think I managed to reproduce the issue and it shares the root
cause with another bug I am currently chasing (GRUB is not installed at
all). Some logic in grub-installer seems to be flawed but I still need
to understand the original intent before I can submit a patch for both bugs.

Meanwhile, a workaround is to enter the boot device manually.

Thanks. Best of luck. I appreciate your assistance




setting up BIOS to boot from a drive that does not have a bios_grub
flagged partition results in:

"GPT-formatted disk.

Legacy boot not supported. Press any key to reboot."


If this is a message from the BIOS, then it is flawed. A compliant
BIOS should not care about the partition table, even less the presence
of any kind of partition. All a BIOS should care about is the presence
of the "boot signature" 0x55, 0xAA at the end of the boot sector.


Yes, that is from the BIOS

(...)

root@z820-3:~# grub-install /dev/sda && update-grub
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot
Partition; embedding won't be possible.
grub-install: error: embedding is not possible, but this is required for
cross-disk install.


This failure has nothing to do with the above. You are trying to install
GRUB on a GPT disk which is not the one containing /boot ("cross-disk"),
and this requires a BIOS boot partition.




Bug#1035096: installation-report Bookworm RC2 GRUB not installed

2023-05-04 Thread Pascal Hambourg

On 04/05/2023 at 16:21, Peter Ehlert wrote:


"Install the GRUB boot loader" menu ... 6 items
Enter device manually
/dev/sda (usb-SanDisk ...
/dev/sdb (ata-WL4000G ...
/dev/sdc (ata-WDC_WD300...
/dev/sdd (ata-WDC_WD300...
/dev/sde (ata-SanDisk_SDSSDA240G_162248447811)


I selected /dev/sde and pressed the Continue button

then the GUI progress bar Installing GRUB and I see Running 
"grub-install /dev/sdd" ...


in this case sdd was the install location, sde is the drive that has a 
bios_grub flagged partition


OK, I think I managed to reproduce the issue and it shares the root 
cause with another bug I am currently chasing (GRUB is not installed at 
all). Some logic in grub-installer seems to be flawed but I still need 
to understand the original intent before I can submit a patch for both bugs.


Meanwhile, a workaround is to enter the boot device manually.

setting up BIOS to boot from a drive that does not have a bios_grub 
flagged partition results in:


"GPT-formatted disk.

Legacy boot not supported. Press any key to reboot."


If this is a message from the BIOS, then it is flawed. A compliant 
BIOS should not care about the partition table, even less the presence 
of any kind of partition. All a BIOS should care about is the presence 
of the "boot signature" 0x55, 0xAA at the end of the boot sector.


Yes, that is from the BIOS

(...)

root@z820-3:~# grub-install /dev/sda && update-grub
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot 
Partition; embedding won't be possible.
grub-install: error: embedding is not possible, but this is required for 
cross-disk install.


This failure has nothing to do with the above. You are trying to install 
GRUB on a GPT disk which is not the one containing /boot ("cross-disk"), 
and this requires a BIOS boot partition.




Bug#1035531: coreutils: fix regressions in copy dir-relative operations

2023-05-04 Thread Pádraig Brady

Package: coreutils
Version: 9.1-1
Severity: important

There are regressions wrt how some directory-relative operations
performed by cp,mv,install as detailed in the following upstream reports:

 From https://bugs.gnu.org/55910
 From https://bugs.gnu.org/63245

These should be addressed by the attached patch,

Note this has already been applied to Fedora at:
https://src.fedoraproject.org/rpms/coreutils/raw/f38/f/coreutils-9.1-copy-relative-dir.patchdiff -Naur coreutils-9.1.orig/src/copy.c coreutils-9.1/src/copy.c
--- coreutils-9.1.orig/src/copy.c	2022-04-15 13:53:28.0 +
+++ coreutils-9.1/src/copy.c	2023-05-04 21:09:46.290253081 +
@@ -1954,6 +1954,7 @@
   bool restore_dst_mode = false;
   char *earlier_file = NULL;
   char *dst_backup = NULL;
+  char const *drelname = *dst_relname ? dst_relname : ".";
   bool delayed_ok;
   bool copied_as_regular = false;
   bool dest_is_symlink = false;
@@ -1971,7 +1972,7 @@
   if (x->move_mode)
 {
   if (rename_errno < 0)
-rename_errno = (renameatu (AT_FDCWD, src_name, dst_dirfd, dst_relname,
+rename_errno = (renameatu (AT_FDCWD, src_name, dst_dirfd, drelname,
RENAME_NOREPLACE)
 ? errno : 0);
   nonexistent_dst = *rename_succeeded = new_dst = rename_errno == 0;
@@ -1983,7 +1984,7 @@
 {
   char const *name = rename_errno == 0 ? dst_name : src_name;
   int dirfd = rename_errno == 0 ? dst_dirfd : AT_FDCWD;
-  char const *relname = rename_errno == 0 ? dst_relname : src_name;
+  char const *relname = rename_errno == 0 ? drelname : src_name;
   int fstatat_flags
 = x->dereference == DEREF_NEVER ? AT_SYMLINK_NOFOLLOW : 0;
   if (follow_fstatat (dirfd, relname, _sb, fstatat_flags) != 0)
@@ -2051,8 +2052,7 @@
   int fstatat_flags = use_lstat ? AT_SYMLINK_NOFOLLOW : 0;
   if (!use_lstat && nonexistent_dst < 0)
 new_dst = true;
-  else if (follow_fstatat (dst_dirfd, dst_relname, _sb,
-   fstatat_flags)
+  else if (follow_fstatat (dst_dirfd, drelname, _sb, fstatat_flags)
== 0)
 {
   have_dst_lstat = use_lstat;
@@ -2077,7 +2077,7 @@
   bool return_now = false;
 
   if (x->interactive != I_ALWAYS_NO
-  && ! same_file_ok (src_name, _sb, dst_dirfd, dst_relname,
+  && ! same_file_ok (src_name, _sb, dst_dirfd, drelname,
  _sb, x, _now))
 {
   error (0, 0, _("%s and %s are the same file"),
@@ -2140,7 +2140,7 @@
  cp and mv treat -i and -f differently.  */
   if (x->move_mode)
 {
-  if (abandon_move (x, dst_name, dst_dirfd, dst_relname, _sb))
+  if (abandon_move (x, dst_name, dst_dirfd, drelname, _sb))
 {
   /* Pretend the rename succeeded, so the caller (mv)
  doesn't end up removing the source file.  */
@@ -2321,14 +2321,11 @@
  Otherwise, use AT_SYMLINK_NOFOLLOW, in case dst_name is a symlink.  */
   if (have_dst_lstat)
 dst_lstat_sb = _sb;
+  else if (fstatat (dst_dirfd, drelname, _buf, AT_SYMLINK_NOFOLLOW)
+   == 0)
+dst_lstat_sb = _buf;
   else
-{
-  if (fstatat (dst_dirfd, dst_relname, _buf,
-   AT_SYMLINK_NOFOLLOW) == 0)
-dst_lstat_sb = _buf;
-  else
-lstat_ok = false;
-}
+lstat_ok = false;
 
   /* Never copy through a symlink we've just created.  */
   if (lstat_ok
@@ -2475,8 +2472,7 @@
   if (x->move_mode)
 {
   if (rename_errno == EEXIST)
-rename_errno = ((renameat (AT_FDCWD, src_name, dst_dirfd, dst_relname)
- == 0)
+rename_errno = (renameat (AT_FDCWD, src_name, dst_dirfd, drelname) == 0
 ? 0 : errno);
 
   if (rename_errno == 0)
@@ -2576,7 +2572,7 @@
  or not, and this is enforced above.  Therefore we check the src_mode
  and operate on dst_name here as a tighter constraint and also because
  src_mode is readily available here.  */
-  if ((unlinkat (dst_dirfd, dst_relname,
+  if ((unlinkat (dst_dirfd, drelname,
  S_ISDIR (src_mode) ? AT_REMOVEDIR : 0)
!= 0)
   && errno != ENOENT)
@@ -2646,7 +2642,7 @@
  to ask mkdir to copy all the CHMOD_MODE_BITS, letting mkdir
  decide what to do with S_ISUID | S_ISGID | S_ISVTX.  */
   mode_t mode = dst_mode_bits & ~omitted_permissions;
-  if (mkdirat (dst_dirfd, dst_relname, mode) != 0)
+  if (mkdirat (dst_dirfd, drelname, mode) != 0)
 {
   error (0, errno, _("cannot create directory %s"),
  quoteaf (dst_name));
@@ -2657,8 +2653,7 @@
  for writing the directory's contents. Check if these
 

Bug#1035505: firmware-nonfree: debian/bin/gencontrol.py fails on spaces and backslashes

2023-05-04 Thread James Addison
Followup-For: Bug #1035505
X-Debbugs-Cc: didi.deb...@cknow.org, 1029...@bugs.debian.org, k...@debian.org

Yep, those two issues seem accurate to me: splitting the config file list (a
trickier prospect than it seemed it should be, because newlines have been
converted into spaces), and then quoting the filename mappings provided to the
rules-gen stage.

(and I think I was already stating the obvious when mentioning the config file
as the source of problems earlier)

Either way, and although it lacks the excitement of Unicode snowpeople, I've
developed an alternative possible fixup approach at:

https://salsa.debian.org/diederik/firmware-nonfree/-/merge_requests/1

Cheers,
James



Bug#1035530: coreutils: fix regressions in copy backup operations

2023-05-04 Thread Pádraig Brady

Package: coreutils
Version: 9.1-1
Severity: important

There are regressions wrt how backups are performed by cp,mv,install
as detailed in the following upstream reports:

From https://bugs.gnu.org/55029
From https://bugs.gnu.org/62607

These should be addressed by the attached patch,

Note this has already been applied to Fedora at:
https://src.fedoraproject.org/rpms/coreutils/raw/f38/f/gnulib-simple-backup-fix.patchdiff -Naur coreutils-9.1.orig/lib/backupfile.c coreutils-9.1/lib/backupfile.c
--- coreutils-9.1.orig/lib/backupfile.c	2022-04-08 11:22:26.0 +
+++ coreutils-9.1/lib/backupfile.c	2023-05-04 17:07:20.784911071 +
@@ -332,7 +332,7 @@
 return s;
 
   DIR *dirp = NULL;
-  int sdir = AT_FDCWD;
+  int sdir = -1;
   idx_t base_max = 0;
   while (true)
 {
@@ -371,10 +371,10 @@
   if (! rename)
 break;
 
-  int olddirfd = sdir < 0 ? dir_fd : sdir;
+  dir_fd = sdir < 0 ? dir_fd : sdir;
   idx_t offset = sdir < 0 ? 0 : base_offset;
   unsigned flags = backup_type == simple_backups ? 0 : RENAME_NOREPLACE;
-  if (renameatu (olddirfd, file + offset, sdir, s + offset, flags) == 0)
+  if (renameatu (dir_fd, file + offset, dir_fd, s + offset, flags) == 0)
 break;
   int e = errno;
   if (! (e == EEXIST && extended))
diff -Naur coreutils-9.1.orig/tests/cp/backup-dir.sh coreutils-9.1/tests/cp/backup-dir.sh
--- coreutils-9.1.orig/tests/cp/backup-dir.sh	2022-04-08 11:22:18.0 +
+++ coreutils-9.1/tests/cp/backup-dir.sh	2023-05-04 17:07:24.851960384 +
@@ -1,5 +1,5 @@
 #!/bin/sh
-# Ensure that cp -b doesn't back up directories.
+# Ensure that cp -b handles directories appropriately
 
 # Copyright (C) 2006-2022 Free Software Foundation, Inc.
 
@@ -29,4 +29,10 @@
 test -d y/x || fail=1
 test -d y/x~ && fail=1
 
+# Bug 62607.
+# This would fail to backup using rename, and thus fail to replace the file
+mkdir -p src/foo dst/foo || framework_failure_
+touch src/foo/bar dst/foo/bar || framework_failure_
+cp --recursive --backup src/* dst || fail=1
+
 Exit $fail
diff -Naur coreutils-9.1.orig/tests/mv/backup-dir.sh coreutils-9.1/tests/mv/backup-dir.sh
--- coreutils-9.1.orig/tests/mv/backup-dir.sh	2022-04-08 11:22:18.0 +
+++ coreutils-9.1/tests/mv/backup-dir.sh	2023-05-04 17:03:29.593098230 +
@@ -36,4 +36,10 @@
 mv -T --backup=numbered C E/ || fail=1
 mv -T --backup=numbered D E/ || fail=1
 
+# Bug#55029
+mkdir F && echo 1 >1 && echo 2 >2 && cp 1 F/X && cp 2 X || framework_failure_
+mv --backup=simple X F/ || fail=1
+compare 1 F/X~ || fail=1
+compare 2 F/X || fail=1
+
 Exit $fail


Bug#876983: bmap-tools: Remove Recommends on python-gpgme

2023-05-04 Thread Agathe Porte

I have created a MR on Salsa to fix this bug:

https://salsa.debian.org/debian/bmap-tools/-/merge_requests/2

Since we are in freeze and this is not a RC bug, I think it will be 
fixed after the bookworm release.




Bug#1035331: jackd2: reproducible-builds: Locale and timezone dependent date in manpages

2023-05-04 Thread Vagrant Cascadian
On 2023-05-04, Nicholas D Steeves wrote:
> By the way, were any of the jackd2 patches forwarded upstream?

I did not. Would be happy if you could; could also take it on if
needed...

live well,
  vagrant


signature.asc
Description: PGP signature


Bug#1035331: jackd2: reproducible-builds: Locale and timezone dependent date in manpages

2023-05-04 Thread Nicholas D Steeves
Hi Vagrant,

Vagrant Cascadian  writes:

> On 2023-05-03, Nicholas D Steeves wrote:
>> Vagrant Cascadian  writes:
>>
>> This bug contains [PATCH 1/5], and #1035329 (reproducible-builds:
>> Missing manpages when /bin/sh -> dash) contains [PATCH 3/5].  Did you
>> intend for {2,4,5} to also reach src:jackd2?
>
> Sorry for the confusion, those other "missing" patches were just cruft
> from my dgit workflow. Pretty sure I got the right patches included in
> the respective bug reports. :)
>

I think so, yes :)  I was also confused because I had missed the 2/5
patch.  It would be really nice if those patch series could be numbered
correctly.

By the way, were any of the jackd2 patches forwarded upstream?

Cheers,
Nicholas



Bug#1035529: ITP: ruby-semver-dialects -- utility function to process semantic versions expressed in different dialects

2023-05-04 Thread Pirate Praveen

Package: wnpp
severity: wishlist
Owner: Pirate Praveen 

Package https://rubygems.org/gems/semver_dialects



Bug#1035528: ssh-audit: Please update the debian package

2023-05-04 Thread Martin Dosch
Package: ssh-audit
Version: 2.5.0-1
Severity: wishlist

Dear Maintainer,

upstream recently released v2.9.0 while Debian still ships v2.5.0, 
therefore I'd like to kindly ask you to update the debian package to the 
latest upstream version after the bookworm release.

Best regards,
Martin

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (900, 'testing-security'), (900, 'testing'), (600, 'unstable'), 
(500, 'unstable-debug'), (500, 'testing-debug'), (500, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-7-amd64 (SMP w/8 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)
LSM: AppArmor: enabled

Versions of packages ssh-audit depends on:
ii  python3  3.11.2-1+b1

ssh-audit recommends no packages.

ssh-audit suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#1035527: ITP: fonts-kode-mono -- Developer mono typeface

2023-05-04 Thread Gürkan Myczko

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: fonts-kode-mono
  Version : 1.013+ds
  Upstream Authors: Isa Ozler 
  URL : https://kodemono.com/
* License : OFL-1.1
  Description : Developer mono typeface
 This typeface is designed to enhance the user experience and reflect 
our

 principles of functionality and timelessness.



Bug#1035280: pipewire-pulse 0.3.70 client side crash when load-module module-zeroconf-discover against a pipewire-pulse with module-native-protocol-tcp and module-zeroconf-publish

2023-05-04 Thread Alban Browaeys
The issue was triggered by a LibreElec 11.0.1 box that advertises a
PulseAudio protocol tcp service on port 4713 but does not listen there.

I believe this could be reproduced via a fake avahi service XML
definition.

Issue fixed upstream in
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/ffa21d696d7d364e9d46e519b513c2780bd7b6f3
.
I made a merge request against salsa debian/experimental at
https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/20

On Thu, 04 May 2023 17:11:31 +0200 Alban Browaeys
 wrote:
> reported upstream as
> https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3199
> 
> likely the bug is triggered by the module erroring out when trying to
> connect on a non existent remote port.
> Then the segfault is bug in pipewire.
> 
> On Tue, 02 May 2023 02:57:36 +0200 Alban Browaeys
>  wrote:
> > Just a quick note that I am able to reproduce this issue with
master.
> > Though at times it works with upstream master, running from
builddir
> > via "make run" under the ./pw-uninstalled.sh environment.
> > Maybe this only works because the settings are different.
> > 
> > Likely an upstream issue.
> > 
> > Cheers,
> > Alban
> > 
> > 
> 
> 
> 



Bug#1035505: firmware-nonfree: debian/bin/gencontrol.py fails on spaces and backslashes

2023-05-04 Thread Cyril Brulebois
Cyril Brulebois  (2023-05-04):
> The problem is the next stage, distributing the relevant files into the
> appropriate binary packages. That part is controlled by the defines, and
> that's what needs to be adjusted (file format and/or how it's used).
> 
> A quick look suggests files_orig isn't set properly, with each part of
> the path being considered a path on its own. I'm not familiar with the
> config object yet, but if that's indeed the correct thing, that can't
> work as it is:
> 
> class SchemaItemList(object):
> def __init__(self, type=r"\s+"):
> self.type = type
> 
> def __call__(self, i):
> i = i.strip()
> if not i:
> return []
> return [j.strip() for j in re.split(self.type, i)]

Side-stepping that one with the dumb patch attached confirms that
there's an issue reading from the config, but it's not the only issue:
while the immediate one goes away (file lookup that used to fail), the
next one happens after copying all files into place, when the symlinking
begins:

ln -s brcmfmac43430-sdio.AP6212.txt 
debian/firmware-brcm80211/lib/firmware/brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-plus.txt
ln -s brcmfmac43430-sdio.AP6212.txt 
debian/firmware-brcm80211/lib/firmware/brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-ultra.txt
ln -s brcmfmac43430-sdio.AP6212.txt 
debian/firmware-brcm80211/lib/firmware/brcm/brcmfmac43430-sdio.sinovoip,bpi-m2-zero.txt
ln -s brcmfmac43430-sdio.AP6212.txt 
debian/firmware-brcm80211/lib/firmware/brcm/brcmfmac43430-sdio.sinovoip,bpi-m3.txt
ln -s brcm/brcmfmac43455-sdio.Raspberry 
debian/firmware-brcm80211/lib/firmware/brcm/brcmfmac43455-sdio.Raspberry
ln -s Pi debian/firmware-brcm80211/lib/firmware/Pi
ln -s Foundation-Raspberry 
debian/firmware-brcm80211/lib/firmware/Foundation-Raspberry
ln -s Pi debian/firmware-brcm80211/lib/firmware/Pi
ln: failed to create symbolic link 
'debian/firmware-brcm80211/lib/firmware/Pi': File exists
make[2]: *** [debian/rules.real:17: install] Error 1

This is due to the way the debian/rules.gen file is built, leading to
such a line:

$(MAKE) -f debian/rules.real binary-indep FILES='[…]' LINKS='[…] 
brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model 
B.txt:brcmfmac43455-sdio.raspberrypi,4-model-b.txt […]' PACKAGE='brcm80211'

and of course the spaces are going to be problemating here as well…

Applying another dumb patch (using a lambda to make it clear which
transformation is happening and to give me one single thing to update if
the first attempt didn't work, using it on both source and destination)
gave me a symlink…

$ dpkg --contents ../firmware-brcm80211_20230210-5_all.deb | grep Foundation
lrwxrwxrwx root/root 0 2023-05-01 19:30 
./lib/firmware/brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 
Model B.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt

Attaching both patches for illustration only (and therefore not tagging
with “patch”). I didn't check for possible fallouts in other packages,
I stopped the build once the firmware-brcm80211 package has been built,
and I only checked the one bit I cared about, the presence of the
symlink (via the aforementioned dpkg|grep command).

Note that the second patch doesn't really on the specifics of the first
patch (using a specific character to avoid the splitting issue, then
getting rid of it). There might be more similar fun depending on the
characters being embedded in firmware files or symlinks, the way both
source and destination are passed together as a single word, with the
':' separator, via the LINKS command.

I suppose the same problem could happen for the FILES variable, and a
similar trick might help there too.


I don't plan on spending more time on this, I just wanted to see if I
could explore the issues at hand and provide some heads-up. I'll be on
stand-by for the hw-detect side once the symlinks are available in a
fixed package.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
From ca3ece1a1dd45bbe349bd14809ffca4e704ee588 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Thu, 4 May 2023 19:09:29 +
Subject: [PATCH 1/2] do you wanna build a snowman?

---
 debian/config/brcm80211/defines | 1 +
 debian/lib/python/config.py | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/debian/config/brcm80211/defines b/debian/config/brcm80211/defines
index 80041d5..f5a4430 100644
--- a/debian/config/brcm80211/defines
+++ b/debian/config/brcm80211/defines
@@ -48,6 +48,7 @@ files:
  brcm/brcmfmac43455-sdio.raspberrypi,3-model-a-plus.txt
  brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt
  brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
+ brcm/brcmfmac43455-sdio.Raspberry☃Pi☃Foundation-Raspberry☃Pi☃4☃Model☃B.txt
  brcm/brcmfmac4350c2-pcie.bin
  brcm/brcmfmac4350-pcie.bin
  brcm/brcmfmac4354-sdio.bin
diff 

Bug#998166: Upstream PR

2023-05-04 Thread Vincent Legoll
This bug is maybe related to :

https://github.com/collectd/collectd/pull/3974

-- 
Vincent Legoll



Bug#1035505: firmware-nonfree: debian/bin/gencontrol.py fails on spaces and backslashes

2023-05-04 Thread Diederik de Haas
On Thursday, 4 May 2023 12:25:29 CEST Diederik de Haas wrote:
> While trying to prepare a MR to fix bug #1029843, I encountered a
> failure which seems to be `gencontrol.py`'s inability to deal with
> spaces and/or backslashes (used to escape the spaces).

Here's the branch that I created:
https://salsa.debian.org/diederik/firmware-nonfree/-/commits/add-rpi-symlinks/

And this is the Salsa CI job (extract source) that failed:
https://salsa.debian.org/diederik/firmware-nonfree/-/jobs/4187253

At the end of the output I found the `debian/rules debian/control-real` 
command and with that I verified locally that if I removed the `\` (but kept 
the spaces), that it would still fail.

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


Bug#1035452: libmousepad-dev: missing Depends: libmousepad0 (= ${binary:Version})

2023-05-04 Thread Andreas Beckmann

On 04/05/2023 20.32, Yves-Alexis Perez wrote:

Indeed, for some reason that depend is missing, we'll fix it for the next
upload. Not sure about the severity though (especially at freeze time).


Well, the -dev package is apparently useless without it (there seem to 
be no users currently, otherwise it should have been caught earlier). 
And a simple targeted bugfix would be perfectly fine for the freeze.


Andreas

PS: I filed a dozen or so of these bugs yesterday, fixes are getting 
uploaded ...




Bug#1035525: sendmail-bin: Change log level of saslauthd failed auth attempts

2023-05-04 Thread E Harris
Package: sendmail-bin
Version: 8.15.2-22
Severity: normal
Tags: upstream

It seems to be a pretty big security issue that there is no coherent 
reporting/logging
of failed auth login attempts when using saslauthd with sendmail.

The saslauthd log lines for failed auth attempts are similar to this:

May 04 13:32:49 somehost saslauthd[2996]: : auth failure: 
[user=mailtest] [service=smtp] [realm=somerealm] [mech=pam] [reason=PAM auth 
error]

But saslauthd does not report the ip address that originated the auth attempt
(probably because it doesn't know it?), and sendmail (by default) doesn't seem
to report the failed auth attempt at all.

This deficiency prevents trying to take active steps (for example using 
fail2ban) to
try to protect against repeated brute force auth hacking attempts.

I think that sendmail may already have the ability to report AUTH failures, but 
that those
are only enabled with high log levels that include lots of other log spam.

It seems to me that a failed auth login should be reported by default by 
sendmail,
since it both knows the IP the attempt originated from, as well as the status 
of the
auth attempt, and I would like to see this reporting enabled in the standard 
packages.

If there is a way to easily indicate that the auth attempt is for a user that 
doesn't
even exist, that would be even better, as that would be a pretty clear 
indication of a
potential hack attempt.

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

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

Versions of packages sendmail-bin depends on:
ii  debconf  1.5.77
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u5
ii  libdb5.3 5.3.28+dfsg1-0.8
ii  libldap-2.4-22.4.57+dfsg-3+deb11u1
ii  liblockfile1 1.17-1+b1
ii  libnsl2  1.3.0-2
ii  libsasl2-2   2.1.27+dfsg-2.1+deb11u1
ii  libssl1.11.1.1n-0+deb11u4
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0
ii  procps   2:3.3.17-5
ii  sendmail-base8.15.2-22
ii  sendmail-cf  8.15.2-22

sendmail-bin recommends no packages.

Versions of packages sendmail-bin suggests:
ii  libsasl2-modules  2.1.27+dfsg-2.1+deb11u1
ii  openssl   1.1.1n-0+deb11u4
ii  sasl2-bin 2.1.27+dfsg-2.1+deb11u1
ii  sendmail-doc  8.15.2-22

Versions of packages libmilter1.0.1 depends on:
ii  libc6  2.31-13+deb11u5

-- no debconf information



Bug#1035515: [pre-approval] unblock: gdb/13.1-2.1

2023-05-04 Thread Emanuele Rocca
Hi Hector,

On Thu, May 04, 2023 at 05:53:24PM +0200, Hector Oron wrote:
>   Since you have not uploaded the package yet, are you fine if I do a
> regular upload with the patch, then use this unblock request to add
> the package to bookworm.

Of course, please go ahead.

Thanks,
  Emanuele



Bug#1035482: ITP: webext-svg-screenshots -- SVG screenshots browser extension

2023-05-04 Thread Gabriel Collado Rodríguez
Hello Martín pls silence, Ok?

El mié, 3 may 2023 23:30, Martin  escribió:

> Package: wnpp
> Owner: deba...@debian.org
> Severity: wishlist
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: webext-svg-screenshots
>   Version : 0.11.6
>   Upstream Author : Felix Becker 
> * URL or Web page : https://github.com/felixfbecker/svg-screenshots/
> * License : MIT
>   Programming Lang: JavaScript
>   Description : SVG screenshots browser extension
>
> Browser extension to take semantic, scalable, accessible screenshots of
> websites, as SVG - as simple as taking a PNG screenshot.
>
>


Bug#1035482: ITP: webext-svg-screenshots -- SVG screenshots browser extension

2023-05-04 Thread Gabriel Collado Rodríguez
And sorry

El jue, 4 may 2023 20:40, Gabriel Collado Rodríguez <
gabrielcolladorodri...@gmail.com> escribió:

> Hello Martín pls silence, Ok?
>
> El mié, 3 may 2023 23:30, Martin  escribió:
>
>> Package: wnpp
>> Owner: deba...@debian.org
>> Severity: wishlist
>> X-Debbugs-Cc: debian-de...@lists.debian.org
>>
>> * Package name: webext-svg-screenshots
>>   Version : 0.11.6
>>   Upstream Author : Felix Becker 
>> * URL or Web page : https://github.com/felixfbecker/svg-screenshots/
>> * License : MIT
>>   Programming Lang: JavaScript
>>   Description : SVG screenshots browser extension
>>
>> Browser extension to take semantic, scalable, accessible screenshots of
>> websites, as SVG - as simple as taking a PNG screenshot.
>>
>>


Bug#1029843: Bug#1035505: firmware-nonfree: debian/bin/gencontrol.py fails on spaces and backslashes

2023-05-04 Thread Cyril Brulebois
James Addison  (2023-05-04):
> I think that the edits to 'debian/config/brcm80211/defines' may be the cause
> of the space-escaping issue (noticed that in your fork on Salsa).
> 
> Building locally without modifications from firmware-nonfree_20230210-5 I get:

>   lrwxrwxrwx 1 jka jka   44 May  4 18:45 
> 'debian/build/install/brcm/brcmfmac43455-sdio.Raspberry Pi 
> Foundation-Raspberry Pi 4 Model B.txt' -> 
> brcmfmac43455-sdio.raspberrypi,4-model-b.txt
>   lrwxrwxrwx 1 jka jka   44 May  4 18:45 
> 'debian/build/install/brcm/brcmfmac43455-sdio.Raspberry Pi 
> Foundation-Raspberry Pi Compute Module 4.txt' -> 
> brcmfmac43455-sdio.raspberrypi,4-model-b.txt
> 
> 
> So I think the symlinks are created.. but then lost when the .deb is built?

If you start from the git repository, at the appropriate tag
(debian/20230210-5), you'll find need to unpack the upstream tarball:

tar xf ../firmware-nonfree_20230210.orig.tar.xz --strip 1

Then generate stuff:

(unstable-amd64-devel)kibi@tokyo:~/debian-kernel/firmware-nonfree.git 
(sid)$ ./debian/rules debian/control
mkdir -p debian/build
printf >debian/build/version-info 'Source: %s\nVersion: %s\n' 
firmware-nonfree 20230210-5
/usr/bin/make -f debian/rules debian/control-real
make[1]: Entering directory '/home/kibi/debian-kernel/firmware-nonfree.git'
./copy-firmware.sh debian/build/install
debian/bin/gencontrol.py /usr/src/linux-support-6.1.0-8
md5sum [ edited for brevity ] > debian/control.md5sum

This target is made to fail intentionally, to make sure
that it is NEVER run during the automated build. Please
ignore the following error, the debian/control file has
been generated SUCCESSFULLY.

exit 1
make[1]: *** [debian/rules:61: debian/control-real] Error 1
make[1]: Leaving directory '/home/kibi/debian-kernel/firmware-nonfree.git'
make: *** [debian/rules:43: debian/control] Error 2

See the ./copy-firmware.sh step? That's using the upstream WHENCE file.

That step is also called when building from the source package directly.


The problem is the next stage, distributing the relevant files into the
appropriate binary packages. That part is controlled by the defines, and
that's what needs to be adjusted (file format and/or how it's used).

A quick look suggests files_orig isn't set properly, with each part of
the path being considered a path on its own. I'm not familiar with the
config object yet, but if that's indeed the correct thing, that can't
work as it is:

class SchemaItemList(object):
def __init__(self, type=r"\s+"):
self.type = type

def __call__(self, i):
i = i.strip()
if not i:
return []
return [j.strip() for j in re.split(self.type, i)]


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#1035452: libmousepad-dev: missing Depends: libmousepad0 (= ${binary:Version})

2023-05-04 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2023-05-03 at 16:10 +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
> 0m9.1s ERROR: FAIL: Broken symlinks:
>   /usr/lib/x86_64-linux-gnu/libmousepad.so -> libmousepad.so.0.0.0
> (libmousepad-dev)

Indeed, for some reason that depend is missing, we'll fix it for the next
upload. Not sure about the severity though (especially at freeze time).

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmRT+kEACgkQ3rYcyPpX
RFs/YAf9EdzJoXD2doBL26HIb1Lzfeli0uI3ZhvgdiwB+9mYuUzI2S+sYGM1v/X3
ZQ0BGkJhClQmnLdeNjRUbbRjNr6p3m4TCFb9o1oHXBVwvv7mTTK61ODgwjkMUqVw
SGkWlxUQfwAsZxR3gnLAUw+pWkOXh1rm3fstZz2Q+FEkEJHDqnqJqilwOOwKDC3G
Wx5Q40+ZOe2JDc8eCE3B2shpZtbOQL5eNkjIwlxQIoyeilrrJ6tl3WieKtQ2YeEZ
bj3ldm2tl9QZpOLQLppR6zLx5VN8R+tJwDI69+T3UYkSsDF8jCc6BBLgpq5oOdvC
Usx94Q39HLvxKvWjoWfI+StoVEGk6w==
=o9iA
-END PGP SIGNATURE-



Bug#1035522: bullseye-pu: package debian-security-support/1:11+2023.05.04

2023-05-04 Thread Holger Levsen
On Thu, May 04, 2023 at 07:50:37PM +0200, Holger Levsen wrote:
> [ Checklist ]
>   [x] *all* changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in (old)stable
>   [x] the issue is verified as fixed in unstable

I forgot to mention: I also reviewed the (only recently added checklist
in README.source about what to do for a new release cycle and confirmed
this checklist is correct and complete, so that I'm quite very hopeful 
we wont have something like #1034077 for forky.

(#1034077 is fixed in unstable (thus trixie) and those two bugs in To: are
to get the fix into bullseye and bookworm.)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Das Leben ist schön. Von 'einfach' war nie die Rede. (@lernzyklus)


signature.asc
Description: PGP signature


Bug#1035469: libwebkit2gtk-4.0-37: After upgrading to libwebkit2gtk-4.0-37_2.40.1-1~deb11u1, Gnome Evolution does not load the body content of emails.

2023-05-04 Thread Jim Popovitch
Thank you very very much!



Bug#1035505: firmware-nonfree: debian/bin/gencontrol.py fails on spaces and backslashes

2023-05-04 Thread James Addison
Source: firmware-nonfree
Followup-For: Bug #1035505
X-Debbugs-Cc: didi.deb...@cknow.org, 1029...@bugs.debian.org, k...@debian.org

Looks like a silently-handled exception here: 
https://salsa.debian.org/kernel-team/firmware-nonfree/-/blob/9f189a7f81d40694ee71a36906de5637dada950f/debian/bin/gencontrol.py#L235

Translating the 'pass' into a 'yield' results in:

  Traceback (most recent call last):
File 
"/home/jka/Documents/personal/firmware-nonfree-20230210/debian/bin/gencontrol.py",
 line 341, in 
  GenControl()()
File 
"/home/jka/Documents/personal/firmware-nonfree-20230210/debian/bin/gencontrol.py",
 line 94, in __call__
  self.do_main(packages, makefile)
File 
"/home/jka/Documents/personal/firmware-nonfree-20230210/debian/bin/gencontrol.py",
 line 128, in do_main
  self.do_package(packages, makefile, package, vars.copy(), 
makeflags.copy())
File 
"/home/jka/Documents/personal/firmware-nonfree-20230210/debian/bin/gencontrol.py",
 line 234, in do_package
  f = f + ', ' + ', '.join(sorted(links_rev[f]))
  ~^^^
  KeyError: 'amdgpu/aldebaran_mec.bin'



Bug#1035509: [pre-approval] unblock: vim/2:9.0.1378-2

2023-05-04 Thread Sebastian Ramacher
Control: tags -1 confirmed moreinfo

On 2023-05-04 07:50:01 -0400, James McCoy wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: v...@packages.debian.org
> Control: affects -1 + src:vim
> 
> Please unblock package vim

Please go ahead and remove the moreinfo tag once the package is
available in unstable.

Cheers

> 
> [ Reason ]
> - Fix for CVE-2023-2426 (using uninitialized memory)
> - Minor fix for indenting of Perl scripts (regression from bullseye)
> 
> [ Impact ]
> - Shipping with a known CVE, whose fix was requested by the security
>   team
> - Thousands of wasted keystrokes indenting Perl scripts
> 
> [ Tests ]
> - New test was added upstream for the CVE, but its mainly useful for
>   running under valgrind
> 
> [ Risks ]
> Fixes are small and straight forward.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> unblock vim/2:9.0.1378-2

> diffstat for vim-9.0.1378 vim-9.0.1378
> 
>  changelog
> |7 
>  patches/Fix-GH-267-where-indent-after-a-sub-would-not-work.patch 
> |   22 +
>  patches/debian/Support-sourcing-a-vimrc.tiny-when-Vim-is-invoked-as-vi.patch 
> |2 
>  patches/patch-9.0.1499-using-uninitialized-memory-with-fuzzy-matc.patch  
> |  147 ++
>  patches/series   
> |2 
>  5 files changed, 179 insertions(+), 1 deletion(-)
> 
> diff -Nru vim-9.0.1378/debian/changelog vim-9.0.1378/debian/changelog
> --- vim-9.0.1378/debian/changelog 2023-03-04 14:41:33.0 -0500
> +++ vim-9.0.1378/debian/changelog 2023-05-04 06:24:44.0 -0400
> @@ -1,3 +1,10 @@
> +vim (2:9.0.1378-2) unstable; urgency=medium
> +
> +  * Backport 9.0.1499 to fix CVE-2023-2426 (Closes: #1035323)
> +  * Backport fix for indenting of Perl subroutines (Closes: #1034529)
> +
> + -- James McCoy   Thu, 04 May 2023 06:24:44 -0400
> +
>  vim (2:9.0.1378-1) unstable; urgency=medium
>  
>* Merge upstream patch v9.0.1378
> diff -Nru 
> vim-9.0.1378/debian/patches/debian/Support-sourcing-a-vimrc.tiny-when-Vim-is-invoked-as-vi.patch
>  
> vim-9.0.1378/debian/patches/debian/Support-sourcing-a-vimrc.tiny-when-Vim-is-invoked-as-vi.patch
> --- 
> vim-9.0.1378/debian/patches/debian/Support-sourcing-a-vimrc.tiny-when-Vim-is-invoked-as-vi.patch
>   2023-03-04 14:41:33.0 -0500
> +++ 
> vim-9.0.1378/debian/patches/debian/Support-sourcing-a-vimrc.tiny-when-Vim-is-invoked-as-vi.patch
>   2023-05-04 06:24:44.0 -0400
> @@ -86,7 +86,7 @@
>   # define SYS_VIMRC_FILE "$VIM/vimrc"
>   #endif
>  diff --git a/src/structs.h b/src/structs.h
> -index d020449..dbbecb4 100644
> +index 46a71cb..ac661a6 100644
>  --- a/src/structs.h
>  +++ b/src/structs.h
>  @@ -4468,6 +4468,9 @@ typedef struct
> diff -Nru 
> vim-9.0.1378/debian/patches/Fix-GH-267-where-indent-after-a-sub-would-not-work.patch
>  
> vim-9.0.1378/debian/patches/Fix-GH-267-where-indent-after-a-sub-would-not-work.patch
> --- 
> vim-9.0.1378/debian/patches/Fix-GH-267-where-indent-after-a-sub-would-not-work.patch
>   1969-12-31 19:00:00.0 -0500
> +++ 
> vim-9.0.1378/debian/patches/Fix-GH-267-where-indent-after-a-sub-would-not-work.patch
>   2023-05-04 06:24:44.0 -0400
> @@ -0,0 +1,22 @@
> +From: Andy Lester 
> +Date: Tue, 26 Apr 2022 20:07:43 -0500
> +Subject: Fix GH#267 where indent after a sub would not work
> +
> +Closes: #1034529
> +Signed-off-by: James McCoy 
> +---
> + runtime/indent/perl.vim | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/runtime/indent/perl.vim b/runtime/indent/perl.vim
> +index 4c91fa1..bd2a1a9 100644
> +--- a/runtime/indent/perl.vim
>  b/runtime/indent/perl.vim
> +@@ -133,6 +133,7 @@ function! GetPerlIndent()
> + \ || synid == "perlHereDoc"
> + \ || synid == "perlBraces"
> + \ || synid == "perlStatementIndirObj"
> ++\ || synid == "perlSubDeclaration"
> + \ || synid =~ "^perlFiledescStatement"
> + \ || synid =~ '^perl\(Sub\|Block\|Package\)Fold'
> + let brace = strpart(line, bracepos, 1)
> diff -Nru 
> vim-9.0.1378/debian/patches/patch-9.0.1499-using-uninitialized-memory-with-fuzzy-matc.patch
>  
> vim-9.0.1378/debian/patches/patch-9.0.1499-using-uninitialized-memory-with-fuzzy-matc.patch
> --- 
> vim-9.0.1378/debian/patches/patch-9.0.1499-using-uninitialized-memory-with-fuzzy-matc.patch
>1969-12-31 19:00:00.0 -0500
> +++ 
> vim-9.0.1378/debian/patches/patch-9.0.1499-using-uninitialized-memory-with-fuzzy-matc.patch
>2023-05-04 06:24:44.0 -0400
> @@ -0,0 +1,147 @@
> +From: Bram Moolenaar 
> +Date: Sat, 29 Apr 2023 21:38:04 +0100
> 

Bug#1035469: libwebkit2gtk-4.0-37: After upgrading to libwebkit2gtk-4.0-37_2.40.1-1~deb11u1, Gnome Evolution does not load the body content of emails.

2023-05-04 Thread Alberto Garcia
On Wed, May 03, 2023 at 01:32:18PM -0400, Jim Popovitch wrote:
> > Thanks for the report, we'll prepare an update asap.
> > 
> 
> Best wishes!

It took longer than I would have wished, but this is now fixed in
evolution 3.38.3-1+deb11u2

Berto



Bug#1035505: firmware-nonfree: debian/bin/gencontrol.py fails on spaces and backslashes

2023-05-04 Thread James Addison
Source: firmware-nonfree
Followup-For: Bug #1035505
X-Debbugs-Cc: didi.deb...@cknow.org, 1029...@bugs.debian.org, k...@debian.org

Hey Diederik,

I think that the edits to 'debian/config/brcm80211/defines' may be the cause
of the space-escaping issue (noticed that in your fork on Salsa).

Building locally without modifications from firmware-nonfree_20230210-5 I get:

  $ debian/rules debian/control-real
  mkdir -p debian/build
  printf >debian/build/version-info 'Source: %s\nVersion: %s\n' 
firmware-nonfree 20230210-5
  ./copy-firmware.sh debian/build/install
  debian/bin/gencontrol.py /usr/src/linux-support-6.1.0-8
  W: brcm80211: unused files: .defines.swp
  md5sum debian/bin/gencontrol.py debian/build/version-info 
debian/templates/control.binary.in debian/templates/control.extra.in 
debian/templates/control.source.in debian/templates/metainfo.xml.firmware.in 
debian/templates/metainfo.xml.in debian/templates/metainfo.xml.modalias.in 
debian/templates/postinst.initramfs-tools.in 
debian/templates/preinst.license.in debian/templates/templates.license.in 
debian/config/defines debian/config/amd-graphics/defines 
debian/config/atheros/defines debian/config/bnx2/defines 
debian/config/bnx2x/defines debian/config/brcm80211/defines 
debian/config/cavium/defines debian/config/intel-sound/defines 
debian/config/ipw2x00/defines debian/config/ivtv/defines 
debian/config/iwlwifi/defines debian/config/libertas/defines 
debian/config/misc-nonfree/defines debian/config/myricom/defines 
debian/config/netronome/defines debian/config/netxen/defines 
debian/config/qcom-soc/defines debian/config/qlogic/defines 
debian/config/realtek/defines debian/config/samsung/defines 
debian/config/siano/defines debian/config/ti-connectivity/defines 
debian/modinfo.json > debian/control.md5sum
  
  This target is made to fail intentionally, to make sure
  that it is NEVER run during the automated build. Please
  ignore the following error, the debian/control file has
  been generated SUCCESSFULLY.
  
  exit 1
  make: *** [debian/rules:61: debian/control-real] Error 1
  $ ls -l debian/build/install/brcm/brcmfmac43455-sdio.*
  -rw-r--r-- 1 jka jka 1723 May  4 18:45  
debian/build/install/brcm/brcmfmac43455-sdio.acepc-t8.txt
  -rw-r--r-- 1 jka jka 1475 May  4 18:45  
debian/build/install/brcm/brcmfmac43455-sdio.AW-CM256SM.txt
  lrwxrwxrwx 1 jka jka   33 May  4 18:45  
debian/build/install/brcm/brcmfmac43455-sdio.beagle,am5729-beagleboneai.txt -> 
brcmfmac43455-sdio.AW-CM256SM.txt
  lrwxrwxrwx 1 jka jka   31 May  4 18:45  
debian/build/install/brcm/brcmfmac43455-sdio.bin -> 
../cypress/cyfmac43455-sdio.bin
  lrwxrwxrwx 1 jka jka   36 May  4 18:45  
debian/build/install/brcm/brcmfmac43455-sdio.clm_blob -> 
../cypress/cyfmac43455-sdio.clm_blob
  -rw-r--r-- 1 jka jka 2510 May  4 18:45 
'debian/build/install/brcm/brcmfmac43455-sdio.MINIX-NEO Z83-4.txt'
  lrwxrwxrwx 1 jka jka   33 May  4 18:45  
debian/build/install/brcm/brcmfmac43455-sdio.pine64,pinebook-pro.txt -> 
brcmfmac43455-sdio.AW-CM256SM.txt
  lrwxrwxrwx 1 jka jka   33 May  4 18:45  
debian/build/install/brcm/brcmfmac43455-sdio.pine64,pinephone-pro.txt -> 
brcmfmac43455-sdio.AW-CM256SM.txt
  lrwxrwxrwx 1 jka jka   33 May  4 18:45  
debian/build/install/brcm/brcmfmac43455-sdio.pine64,quartz64-b.txt -> 
brcmfmac43455-sdio.AW-CM256SM.txt
  lrwxrwxrwx 1 jka jka   49 May  4 18:45  
debian/build/install/brcm/brcmfmac43455-sdio.raspberrypi,3-model-a-plus.txt -> 
brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt
  -rw-r--r-- 1 jka jka 1884 May  4 18:45  
debian/build/install/brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt
  -rw-r--r-- 1 jka jka 1883 May  4 18:45  
debian/build/install/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt
  lrwxrwxrwx 1 jka jka   44 May  4 18:45 
'debian/build/install/brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry 
Pi 4 Model B.txt' -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt
  lrwxrwxrwx 1 jka jka   44 May  4 18:45 
'debian/build/install/brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry 
Pi Compute Module 4.txt' -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt


So I think the symlinks are created.. but then lost when the .deb is built?



Bug#1035524: unblock: debian-security-support/1:12+2023.05.04

2023-05-04 Thread Holger Levsen
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package debian-security-support to fix #1034077
"debian-security-support: Lots of noise about DEBIAN_VERSION 12 being invalid 
when upgrading bullseye→bookworm" in bookworm as well.

Else #1034077 will hit future upgrades to trixie as well.

#1035522 is the request for pre-approval for fixing this in bullseye and
has some more information why this is needed, though in principle just
look at #1034077 and the diff here :) Thanks!

 check-support-status.in  |2 +-
 debian/changelog |   14 ++
 debian/po/tr.po  |   36 +++-
 debian/rules |2 +-
 security-support-limited |2 ++
 5 files changed, 33 insertions(+), 23 deletions(-)

The full debdiff is attached.

unblock debian-security-support/1:12+2023.05.04


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Punk ist nicht tot.
Punk trägt Maske, ist solidarisch und schützt sich und andere.
(@Kreuzpirat)
diff -Nru debian-security-support-12+2023.03.23/check-support-status.in debian-security-support-12+2023.05.04/check-support-status.in
--- debian-security-support-12+2023.03.23/check-support-status.in	2023-03-05 20:33:23.0 +0100
+++ debian-security-support-12+2023.05.04/check-support-status.in	2023-05-04 19:02:24.0 +0200
@@ -13,7 +13,7 @@
 # Oldest Debian version included in debian-security-support
 DEB_LOWEST_VER_ID=9
 # Version ID for next Debian stable
-DEB_NEXT_VER_ID=12
+DEB_NEXT_VER_ID=13
 
 if [ -z "$DEBIAN_VERSION" ] ; then
 DEBIAN_VERSION="$(cat /etc/debian_version | grep '[0-9.]' | cut -d. -f1)"
diff -Nru debian-security-support-12+2023.03.23/debian/changelog debian-security-support-12+2023.05.04/debian/changelog
--- debian-security-support-12+2023.03.23/debian/changelog	2023-03-23 22:38:23.0 +0100
+++ debian-security-support-12+2023.05.04/debian/changelog	2023-05-04 19:09:45.0 +0200
@@ -1,3 +1,17 @@
+debian-security-support (1:12+2023.05.04) unstable; urgency=medium
+
+  [ Holger Levsen ]
+  * set DEB_NEXT_VER_ID=13 in anticipation of the bookworm release.
+Closes: #1034077. Thanks to Stuart Prescott.
+  * security-support-limited: add rust.* as discussed in
+https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/153
+  * Update Turkish translation, thanks to Atila KOÇ. Closes: #1033928.
+
+  [ Sylvain Beucler ]
+  * security-support-limited: add gnupg1, see #982258.
+
+ -- Holger Levsen   Thu, 04 May 2023 19:09:45 +0200
+
 debian-security-support (1:12+2023.03.23) unstable; urgency=medium
 
   * d/README.source: list steps to be done at the beginning of each release
diff -Nru debian-security-support-12+2023.03.23/debian/po/tr.po debian-security-support-12+2023.05.04/debian/po/tr.po
--- debian-security-support-12+2023.03.23/debian/po/tr.po	2018-03-16 15:39:59.0 +0100
+++ debian-security-support-12+2023.05.04/debian/po/tr.po	2023-05-04 19:09:45.0 +0200
@@ -1,21 +1,22 @@
-# Turkish translation of debian-security-support package
-# Copyright (C) 2014 Mert Dirik
+# Turkish debconf translation of debian-security-support
 # This file is distributed under the same license as the debian-security-support package.
 # Mert Dirik , 2014.
+# Atila KOÇ , 2023.
 #
 msgid ""
 msgstr ""
 "Project-Id-Version: debian-security-support\n"
 "Report-Msgid-Bugs-To: debian-security-supp...@packages.debian.org\n"
 "POT-Creation-Date: 2016-05-12 09:42+0200\n"
-"PO-Revision-Date: 2014-08-03 17:04+0200\n"
-"Last-Translator: Mert Dirik \n"
+"PO-Revision-Date: 2023-03-04 22:32+0300\n"
+"Last-Translator: Atila KOÇ \n"
 "Language-Team: Debian L10n Turkish \n"
 "Language: tr\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"X-Generator: Poedit 1.5.4\n"
+"Plural-Forms: nplurals=2; plural=(n > 1);\n"
+"X-Generator: Poedit 2.4.2\n"
 
 #. Type: text
 #. Description
@@ -30,8 +31,8 @@
 "Unfortunately, it has been necessary to end security support for some "
 "packages before the end of the regular security maintenance life cycle."
 msgstr ""
-"Maalesef bazı paketlerin güvenlik desteğine dağıtım için normalde öngörülen "
-"güvenlik desteği süresi dolmadan önce son vermek zorunda kaldık."
+"Bazı paketlerin güvenlik desteğine, dağıtım için öngörülen güvenlik desteği "
+"süresi dolmadan önce son vermek gerekti."
 
 #. Type: text
 #. Description
@@ -43,14 +44,14 @@
 #: ../debian-security-support.templates:3001
 #: ../debian-security-support.templates:4001
 msgid "The following packages found on this system are affected by this:"
-msgstr "Sisteminizde kurulu olan şu paketler bu durumdan etkilenmektedir:"
+msgstr "Sisteminizde bu durumdan etkilenen şu paketler bulundu:"
 
 #. Type: text
 #. Description
 #: ../debian-security-support.templates:3001
 msgid 

Bug#1035523: gimp: broken symlink /usr/bin/gimp-script-fu-interpreter

2023-05-04 Thread Patrice Duroux
Package: gimp
Version: 2.99.14-2+b1
Severity: minor

Dear Maintainer,

$ adequate gimp
gimp: broken-symlink /usr/bin/gimp-script-fu-interpreter -> gimp-script-fu-
interpreter-2.99

I think it should be:
/usr/bin/gimp-script-fu-interpreter -> gimp-script-fu-interpreter-3.0

no?

Thanks,
Patrice


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

Kernel: Linux 6.1.0-8-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 gimp depends on:
ii  gimp-data2.99.14-2
ii  graphviz 2.42.2-7+b3
ii  libaa1   1.4p5-50
ii  libappstream-glib8   0.8.2-1
ii  libarchive13 3.6.2-1
ii  libasound2   1.2.8-1+b1
ii  libbabl-0.1-01:0.1.98-1+b1
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-5
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgegl-0.4-01:0.4.44-1
ii  libgexiv2-2  0.14.0-1+b1
ii  libgimp-3.0-02.99.14-2+b1
ii  libglib2.0-0 2.76.2-1
ii  libgs10  10.0.0~dfsg-11
ii  libgtk-3-0   3.24.37-2
ii  libgudev-1.0-0   237-2
ii  libharfbuzz0b6.0.0+dfsg-3
ii  libheif1 1.15.1-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libjxl0.70.7.0-10
ii  liblcms2-2   2.14-2
ii  liblzma5 5.4.1-0.2
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.5-1 1.6.0-2
ii  libopenexr-3-1-303.1.5-5
ii  libopenjp2-7 2.5.0-1+b1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpangoft2-1.0-01.50.12+ds-1
ii  libpng16-16  1.6.39-2
ii  libpoppler-glib8 22.12.0-2+b1
ii  librsvg2-2   2.54.5+dfsg-1
ii  libstdc++6   12.2.0-14
ii  libtiff6 4.5.0-5
ii  libwebp7 1.2.4-0.1
ii  libwebpdemux21.2.4-0.1
ii  libwebpmux3  1.2.4-0.1
ii  libwmf-0.2-7 0.2.12-5
ii  libwmflite-0.2-7 0.2.12-5
ii  libx11-6 2:1.8.4-2
ii  libxcursor1  1:1.2.1-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxmu6  2:1.1.3-3
ii  libxpm4  1:3.5.12-1.1
ii  xdg-utils1.1.3-4.1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  10.0.0~dfsg-11

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
ii  gjs   1.76.0-3
ii  gvfs-backends 1.50.4-1
pn  luajit
ii  python3   3.11.2-1+b1

-- no debconf information



Bug#1035522: bullseye-pu: package debian-security-support/1:11+2023.05.04

2023-05-04 Thread Holger Levsen
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

hi,

this is a pre-approval request, I have not uploaded this yet (except to
unstable). 

[ Reason ]

unfortunatly debian-security-support in both bullseye and bookworm
are affected by - #1034077 
"debian-security-support: Lots of noise about DEBIAN_VERSION 12 being 
invalid when upgrading bullseye→bookworm"

though fortunatly the fix is trivial and buster is not affected.

(And unfortunatly I forgot to fix this in the last bullseye point release...)

[ Impact ]

Lots of noise on bullseye to bookworm upgrades with debian-security-support
installed (which has a popcon of ~2750)

[ Tests ]

none, but the diff is really small & straightforward, see attachment.

 check-support-status.in  |2 +-
 debian/changelog |   11 +++
 debian/rules |2 +-
 security-support-limited |1 +
 4 files changed, 14 insertions(+), 2 deletions(-)

[ Risks ]

more users complaining about noise.

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

[ Other info ]

As there will be no more bullseye point releases before the bookworm
release, this probably needs to go in via bullseye-updates. Is d/changelog
correct for this like it is?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If we'd ban all cars from cities tomorrow, next week we will wonder why we
waited for so long.
diff -Nru debian-security-support-11+2022.08.23/check-support-status.in debian-security-support-11+2023.05.04/check-support-status.in
--- debian-security-support-11+2022.08.23/check-support-status.in	2022-08-23 18:24:26.0 +0200
+++ debian-security-support-11+2023.05.04/check-support-status.in	2023-05-04 19:24:04.0 +0200
@@ -13,7 +13,7 @@
 # Oldest Debian version included in debian-security-support
 DEB_LOWEST_VER_ID=9
 # Version ID for next Debian stable
-DEB_NEXT_VER_ID=11
+DEB_NEXT_VER_ID=12
 
 if [ -z "$DEBIAN_VERSION" ] ; then
 DEBIAN_VERSION="$(cat /etc/debian_version | grep '[0-9.]' | cut -d. -f1)"
diff -Nru debian-security-support-11+2022.08.23/debian/changelog debian-security-support-11+2023.05.04/debian/changelog
--- debian-security-support-11+2022.08.23/debian/changelog	2022-08-23 18:26:34.0 +0200
+++ debian-security-support-11+2023.05.04/debian/changelog	2023-05-04 19:27:19.0 +0200
@@ -1,3 +1,14 @@
+debian-security-support (1:11+2023.05.04) bullseye; urgency=medium
+
+  [ Holger Levsen ]
+  * set DEB_NEXT_VER_ID=12 as bookworm is the next release. Closes: #1034077.
+Thanks to Stuart Prescott.
+
+  [ Sylvain Beucler ]
+  * security-support-limited: add gnupg1, see #982258.
+
+ -- Holger Levsen   Thu, 04 May 2023 19:27:19 +0200
+
 debian-security-support (1:11+2022.08.23) bullseye; urgency=medium
 
   * Update security-support-limited from 1:12+2022.08.19 from unstable,
diff -Nru debian-security-support-11+2022.08.23/debian/rules debian-security-support-11+2023.05.04/debian/rules
--- debian-security-support-11+2022.08.23/debian/rules	2022-08-23 18:24:26.0 +0200
+++ debian-security-support-11+2023.05.04/debian/rules	2023-05-04 19:24:04.0 +0200
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 
-NEXT_VERSION_ID=11
+NEXT_VERSION_ID=12
 
 DEBIAN_VERSION ?= $(shell cat /etc/debian_version | grep '[0-9.]' | cut -d. -f1)
 ifeq (,$(DEBIAN_VERSION))
diff -Nru debian-security-support-11+2022.08.23/security-support-limited debian-security-support-11+2023.05.04/security-support-limited
--- debian-security-support-11+2022.08.23/security-support-limited	2022-08-23 18:24:26.0 +0200
+++ debian-security-support-11+2023.05.04/security-support-limited	2023-05-04 19:24:04.0 +0200
@@ -12,6 +12,7 @@
 ganglia See README.Debian.security, only supported behind an authenticated HTTP zone, #702775
 ganglia-web See README.Debian.security, only supported behind an authenticated HTTP zone, #702776
 golang*		See https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#golang-static-linking
+gnupg1  See #982258 and https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html#modern-gnupg
 kde4libskhtml has no security support upstream, only for use on trusted content
 khtml   khtml has no security support upstream, only for use on trusted content, see #1004293
 mozjs68 Not covered by security support, only suitable for trusted content, see #959804


signature.asc
Description: PGP signature


Bug#1035307: Update ruby-ruby-parser to 3.20.x

2023-05-04 Thread Praveen Arimbrathodiyil



On 04/05/23 11:05 pm, Praveen Arimbrathodiyil wrote:



On 04/05/23 10:44 pm, Pirate Praveen wrote:
Running the tests like upstream would with ruby 3.1 installed via rvm, 
the same errors are reproduced.


https://github.com/seattlerb/ruby_parser/issues/337#issuecomment-1535023385



on bullseye with rvm installed ruby 3.0, all tests pass. Though on sid, 
rvm install 3.0 fails.


on bullseye too, with rvm installed ruby 3.1, the failures were 
reproduced. So we can confirm the failure is with ruby 3.1.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1035307: Update ruby-ruby-parser to 3.20.x

2023-05-04 Thread Praveen Arimbrathodiyil



On 04/05/23 10:44 pm, Pirate Praveen wrote:
Running the tests like upstream would with ruby 3.1 installed via rvm, 
the same errors are reproduced.


https://github.com/seattlerb/ruby_parser/issues/337#issuecomment-1535023385



on bullseye with rvm installed ruby 3.0, all tests pass. Though on sid, 
rvm install 3.0 fails.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1029843: brcmfmac: requested firmware filename inconsistent with linux-firmware.git on non-devicetree systems

2023-05-04 Thread Cyril Brulebois
Hi,

Diederik de Haas  (2023-05-04):
> Assuming the '55' stands for max 55 chars, that could be an issue?

That's not how format strings work. :)

That happily overflows:

$ printf "%-10s and the rest of the line\n" kibi
kibi   and the rest of the line

$ printf "%-10s and the rest of the line\n" "Diederik de Haas"
Diederik de Haas and the rest of the line

> It turns out that spaces (and or backslashes to escape them) seems to
> be an issue for the Debian scripts used to make the Debian
> firmware-nonfree packages too. See https://bugs.debian.org/1035505 for
> details. Once that is fixed, I can submit my MR to add those missing
> symlinks.

Oh, d-i isn't the only one expecting non-crazy paths! :)

> Seems doable. I'm not going to spend time trying to make that though.
> I know virtually nothing about d-i/hw-detect internals, so it seems
> very unwise for me to even try it.
> Given the (specific) subject at hand, you won't be surprised that
> there's also a motivational issue ;-)

I was merely writing it out so that it could be sanity-checked, I wasn't
suggesting you would be the one to implement that. (Instead, I was
implicitly volunteering myself…)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#1035307: Update ruby-ruby-parser to 3.20.x

2023-05-04 Thread Pirate Praveen
On Sun, 30 Apr 2023 20:35:00 +0530 Praveen Arimbrathodiyil 
 wrote:

> Package: ruby-ruby-parser
> Version: 3.19.2-1
> Severity: important
>
> Gitlab 15.11.0 needs ruby-ruby-parser 3.20 and while trying to update
> it, the build fails with
>
>   13) Failure:
> TestRubyParserV32#test_unless_pre_not__18
> [/usr/lib/ruby/vendor_ruby/pt_testcase.rb:159]:
> failed on input: "unless not b then a end".
> --- expected
> +++ actual
> @@ -1 +1,4 @@
> -s(:if, s(:call, nil, :b), s(:call, nil, :a), nil)
> +s(:if,
> + s(:call, s(:call, nil, :b).line(1), :!).line(1),
> + nil,
> + s(:call, nil, :a).line(1)).line(1)
>
>
>   14) Failure:
> TestRubyParserV32#test_str_question_literal__18
> [/usr/lib/ruby/vendor_ruby/pt_testcase.rb:159]:
> failed on input: "?a".
> --- expected
> +++ actual
> @@ -1 +1 @@
> -s(:lit, 97)
> +s(:str, "a").line(1)
>
>
>   15) Failure:
> TestRubyParserV32#test_while_pre_not__18
> [/usr/lib/ruby/vendor_ruby/pt_testcase.rb:159]:
> failed on input: "while not true do\n  (1 + 1)\nend".
> --- expected
> +++ actual
> @@ -1 +1,4 @@
> -s(:until, s(:true), s(:call, s(:lit, 1), :+, s(:lit, 1)), true)
> +s(:while,
> + s(:call, s(:true).line(1), :!).line(1),
> + s(:call, s(:lit, 1).line(2), :+, s(:lit, 1).line(2)).line(2),
> + true).line(1)
>
>
>   16) Failure:
> TestRubyParserV32#test_unless_post_not__18
> [/usr/lib/ruby/vendor_ruby/pt_testcase.rb:159]:
> failed on input: "a unless not b".
> --- expected
> +++ actual
> @@ -1 +1,4 @@
> -s(:if, s(:call, nil, :b), s(:call, nil, :a), nil)
> +s(:if,
> + s(:call, s(:call, nil, :b).line(1), :!).line(1),
> + nil,
> + s(:call, nil, :a).line(1)).line(1)
>
>

Running the tests like upstream would with ruby 3.1 installed via rvm, 
the same errors are reproduced.


https://github.com/seattlerb/ruby_parser/issues/337#issuecomment-1535023385



Bug#1035521: gcc: broken liblto_plugin.so symlink

2023-05-04 Thread Helmut Grohne
Package: gcc
Version: 4:13.1.0-1
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

Hi Matthias,

$ ls -la usr/lib/bfd-plugins/liblto_plugin.so
lrwxrwxrwx  1 0 0  43 May  1 09:22 liblto_plugin.so -> 
../gcc/x86_64-linux-gnu/13/liblto_plugin.so
$ ls -la usr/lib/gcc/x86_64-linux-gnu/13/liblto_plugin.so
ls: cannot access 'usr/lib/gcc/x86_64-linux-gnu/13/liblto_plugin.so': No such 
file or directory
$ ls -la usr/libexec/gcc/x86_64-linux-gnu/13/liblto_plugin.so
-rwxr-xr-x 1 0 0 63952 Apr 27 11:28 
usr/libexec/gcc/x86_64-linux-gnu/13/liblto_plugin.so
$

The liblto_plugin.so symlink shipped by gcc is broken. For some reason,
gcc-13 installs to usr/libexec rather than usr/lib, but the symlink does
not take that move into account. Consequently, lto is broken in gcc-13.
This affects e.g. building systemd. I think you need to change

https://sources.debian.org/src/gcc-defaults/1.204/debian/rules/#L827

from

  /usr/lib/gcc/$(DEB_HOST_GNU_TYPE)/$(PV_GCC)/liblto_plugin.so 
/usr/lib/bfd-plugins/liblto_plugin.so \

to

  /usr/libexec/gcc/$(DEB_HOST_GNU_TYPE)/$(PV_GCC)/liblto_plugin.so 
/usr/lib/bfd-plugins/liblto_plugin.so \

Helmut



Bug#1035520: unblock: python-django/3:3.2.19-1

2023-05-04 Thread Chris Lamb
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: t...@security.debian.org

Dear Release Team,

Please consider unblocking python-django 3:3.2.19-1:
  
  python-django (3:3.2.19-1) unstable; urgency=medium
  .
* New upstream security release.
* CVE-2023-31047: Prevent a potential bypass of validation when uploading
  multiple files using one form field.
  .
  Uploading multiple files using one form field has never been supported by
  forms.FileField or forms.ImageField as only the last uploaded file was
  validated. Unfortunately, Uploading multiple files topic suggested
  otherwise. In order to avoid the vulnerability, the ClearableFileInput and
  FileInput form widgets now raise ValueError when the multiple HTML
  attribute is set on them. To prevent the exception and keep the old
  behavior, set the allow_multiple_selected attribute to True.
  .
  For more details on using the new attribute and handling of multiple files
  through a single field, see:
  .


  .
  (Closes: #1035467)
  .
* Bump Standards-Version to 4.6.2.


The full debdiff is attached.


Regards,

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


debdiff
Description: Binary data


Bug#1027993: Solved;

2023-05-04 Thread Hoareau Jean Pierre


Hello sir, I inform you that I solved the problem by purging all the 
"nvidia" files using the command "apt purge *nvidia* and by uninstalling 
the "new" module. Then I installed driver "nvidia-driver/ 
nvidia-driver-bin" then restarted the system. Bumblebee, optirun and 
primusrun are ok. Thank you in advance. Jean Pierre


Bug#487755: grub2 does not install on boot sector of the current (or a mounted) partition

2023-05-04 Thread Emyr Williams

Hello there,

Is this still an on-going issue?  Given that the last entry was 2012, 
I'm leaning towards no, and propose the ticket should be closed.


Best wishes

Emyr


On Sat, 29 Dec 2012 16:30:13 + Martin Naughton 
 wrote:


> Hello
>
> Is there problem solved in the latest grub software? 1.99-24
>
> --
> Regards
> Martin Naughton



Bug#1035489: krb5-config: missing dependency to C compiler

2023-05-04 Thread Russ Allbery
Sam Hartman  writes:

> We could represent this as a dependency or a recommends if there is some
> special reason that libkrb5-dev needs the dependency.  krb5-config not
> working alone is not enough to justify a depends relationship: as I
> understand it (Russ please correct me if I'm getting this wrong from
> memory), the policy requirement is not that every program in a package
> work with the installed dependencies, but that the package as a whole
> work.

Right, the requirement is that the core functionality work, but some
things may not unless Recommends and Suggests are met.  But we don't put
Recommends and Suggests of compilers on every *-dev package either, so I
think *-dev packages are a bit of an unenumerated special case.

> I.E.  I could say that we care far more about the pkgconfig .pc files,
> krb5-config is legacy, and so policy does not force us to depend on a
> compiler even though krb5-config is kind of useless without it.

I would argue that the pkgconfig .pc files are also fairly useless without
a compiler, just with one more step of separation.  :)  I could imagine
theoretical use cases where one wanted to inspect what flags would be
recommended without using them on that system, but I would want to know
that someone encountered that situation in the real world before worrying
too much about it.

My personal experience watching folks who are new to Debian who want to
compile something is that they encounter the missing toolchain somewhat
randomly and attribute that to somewhat random missing dependencies until
someone points out they should just install build-essential if they're
going to be compiling software, and then they encode that in their normal
practices and resolve the problem that way.  This isn't the most
user-friendly setup, to be sure, but I wonder if the path is to more
prominently document that people should install build-essential or the
equivalent if they're going to be building software, rather than adding
individual dependencies.

If we go down the dependency route, IMO it should be handled by debhelper
or similar machinery; I don't think libkrb5-dev is particularly special in
this regard, so fixing this in the krb5 package feels wrong to me.

> There does appear to be a c-compiler virtual package.
> We could depend on gcc|c-compiler.

Oh, there is indeed, sorry.  I missed that because I was looking at the
clang package instead of the clang-16 package.

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



Bug#1035519: coreutils: pr: -i not respected for -o in header

2023-05-04 Thread наб
Package: coreutils
Version: 9.1-1
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

-- >8 --
% echo a | pr -i -o20 | cat -sA
^I^I$
$
2023-05-04 18:12
  Page 1$
$
^I^Ia$
$
-- >8 --

POSIX mandates these be folded as well.
SysVr4 folds them correctly as
-- >8 --
% echo a | ~/uwu/a.out -i -o20 | cat -sA
$
^I^IMay  4 18:14 2023   Page 1$
$
^I^Ia$
$
-- >8 --

Best,
наб

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b5

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#1035494: moonshot-trust-router: fails to purge - command deluser in postrm not found

2023-05-04 Thread Sam Hartman
> "Andreas" == Andreas Beckmann  writes:
Andreas> The fix should be easy: your package is using adduser or
Andreas> deluser from the adduser package, which is only priority
Andreas> important. Using useradd or userdel from the passwd package
Andreas> (priority required) should fix this problem.
Well, and also essential: yes.

I don't think I want to switch adduser over in the postinst because that
would require thinking too much about the  semantics and I suspect
longterm, moonshot-trust-router wants to use sysusers.
But using userdel sounds reasonable for bookworm.
Thanks for noticing the issue.



Bug#1035518: telegram-desktop: Can't join video chats (group calls)

2023-05-04 Thread Nicholas Guriev
Package: telegram-desktop
Version: 3.7.3+ds-2
Severity: important
Forwarded: https://github.com/telegramdesktop/tdesktop/issues/26108

A user can't join video chats (which are actually group calls).

Steps to reproduce:
1. Find any active video chat or start one in any group (you need to be an
   admin with sufficient privileges).
2. Join the video chat.

Actual behavior:
Telegram Desktop hangs when connecting and the user hears nobody.

Expected behavior:
The feature should work and you can see or hear other participants.


The error was somehow caused by failed call to the SSL_read() function.

(openssl_stream_adapter.cc:967): OpenSSLStreamAdapter::Error(SSL_read, 1, 0)



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


Bug#1035489: krb5-config: missing dependency to C compiler

2023-05-04 Thread Sam Hartman
> "Russ" == Russ Allbery  writes:
Russ> krb5-config on a system without a compiler.  In general, all
Russ> *-dev packages in Debian are only useful with a compiler,
Russ> since their whole purpose is to provide support for linking
Russ> new binaries with libraries.  We generally don't make that
Russ> dependency explicit, though, since it adds a lot of edges to
Russ> the dependency graph and it's not clear they serve much
Russ> purpose.

Ah, thanks for saving me the trouble to ask what common practice is
here.

We could represent this as a dependency or a recommends if there is some
special reason that libkrb5-dev needs the dependency.
krb5-config not working alone is not enough to justify a depends
relationship: as I understand it (Russ please correct me if I'm getting
this wrong from memory), the policy requirement is not that every
program in a package work with the installed dependencies, but that the
package as a whole work.  I.E.  I could say that we care far more about
the pkgconfig .pc files, krb5-config is legacy, and so policy does not
force us to depend on a compiler even though krb5-config is kind of
useless without it.

But if there's some special reason that we need a compiler dependency
(or recommendation) I think we have options.
There does appear to be a c-compiler virtual package.
We could depend on gcc|c-compiler.

It looks like over the years, a few things have provided c-compiler that
probably shouldn't (for example bcc, a 16-bit x86 only c-compiler).  But
the list appears reasonably clean now.
I did try krb5-config with pcc as /usr/bin/cc, and it did work.

But like Russ, I'd want to see a special reason why libkrb5-dev needs a
dependency.


signature.asc
Description: PGP signature


Bug#1035515: [pre-approval] unblock: gdb/13.1-2.1

2023-05-04 Thread Hector Oron
Hello,

  While I agree we should get this fixed on bookworm, I believe to be
able to unblock a package, the package should exist in the archive.

  Since you have not uploaded the package yet, are you fine if I do a
regular upload with the patch, then use this unblock request to add
the package to bookworm.

Regards

On Thu, 4 May 2023 at 16:21, Emanuele Rocca  wrote:
>
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: g...@packages.debian.org, debian-...@lists.debian.org
> Control: affects -1 + src:gdb
>
> Hello release team,
>
> Please unblock package gdb.
>
> [ Reason ]
> The most basic functionality of GDB, namely debugging an hello world C
> program, is currently broken in Bookworm for arm64 systems with pointer
> authentication enabled. See https://bugs.debian.org/1034611.
>
> There is a patch merged upstream addressing the issue [0]. I've tested
> it on a arm64 system and can confirm that it works. See also:
> https://bugs.debian.org/1034611#15
>
> I've prepared an NMU, not yet uploaded. Please find the debdiff
> attached.
>
> [ Impact ]
> GDB entirely unusable for most arm64 users.
>
> [ Tests ]
> Upstream test suite passes. Manually verified that #1034611 can be
> reproduced with gdb 13.1-2 from Bookworm, and it cannot with the
> proposed changes.
>
> [ Risks ]
> Minimal, the patch is small and targeted. Additionally, it only touches
> arm64-specific code.
>
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
>
> unblock gdb/13.1-2.1
>
> Thanks,
>   Emanuele
>
> [0] 
> https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=b3eff3e15576229af9bae026c5c23ee694b90389



-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.



Bug#1034996: libomemo0: missing Breaks+Replaces for libomemo-dev when upgrading from bullseye

2023-05-04 Thread Pirate Praveen
On Thu, 27 Apr 2023 14:59:11 +0200 Helmut Grohne  
wrote:

> Package: libomemo0
> Version: 0.8.1-1
> Severity: serious
> Justification: dpkg unpack error
>
> Attempting to unpack libomemo0/0.8.1-1 from Debian bookworm
> on a minimal Debian bullseye with libomemo-dev/0.7.0-1
> installed, causes an unpack error from dpkg due to
> /usr/lib/x86_64-linux-gnu/libomemo.so being contained in both 
packages.

>
> | (Reading database ... 12426 files and directories currently 
installed.)

> | Preparing to unpack ./libomemo0_0.8.1-1_amd64.deb ...
> | Unpacking libomemo0:amd64 (0.8.1-1) over (0.7.0-1) ...
> | dpkg: error processing archive ./libomemo0_0.8.1-1_amd64.deb 
(--unpack):
> |  trying to overwrite '/usr/lib/x86_64-linux-gnu/libomemo.so', 
which is also in package libomemo-dev:amd64 0.7.0-1

> | Processing triggers for libc-bin (2.31-13+deb11u5) ...
> | Errors were encountered while processing:
> |  ./libomemo0_0.8.1-1_amd64.deb
>
>
> Please ensure that libomemo0 has sufficient Breaks and Replaces 
declarations.

>
> Helmut
>
>

I could add the Breaks and Replaces, but looks like moving .so link out 
of -dev package is wrong as per lintian warning.


W: libomemo0: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libomemo.so 
[usr/lib/x86_64-linux-gnu/libomemo.so.0.8.1]
W: libomemo0: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libomemo.so.0.8.1 
[usr/lib/x86_64-linux-gnu/libomemo.so]


This was moved to libomemo-dev in commit 
6ebca2f07eed072226503432b6149e671341f2c4 Should we move back 
libomemo.so to libomemo-dev ?




Bug#1035517: evolution: Text display of mails a narrow strip

2023-05-04 Thread nullproblemo
Package: evolution
Version: 3.38.3-1+deb11u1
Severity: important

Dear Maintainer,


starting Evolution:
In Evolution the text display of the mails is only a narrow strip since 4 May
2023 so nothing nothing can be read. This is identical in the preview and in
the large view. The same situation on 3 computers. The problem is known in the
german forum: https://debianforum.de/forum/viewtopic.php?p=1326471#p1326471


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

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

Versions of packages evolution depends on:
ii  dbus   1.12.24-0+deb11u1
ii  evolution-common   3.38.3-1+deb11u1
ii  evolution-data-server  3.38.3-1+deb11u2
ii  libc6  2.31-13+deb11u6
ii  libcamel-1.2-623.38.3-1+deb11u2
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-2.0-1  3.38.3-1+deb11u2
ii  libedataserver-1.2-25  3.38.3-1+deb11u2
ii  libevolution   3.38.3-1+deb11u1
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4+deb11u3
ii  libical3   3.0.9-2
ii  libnotify4 0.7.9-3
ii  libsoup2.4-1   2.72.0-2
ii  libwebkit2gtk-4.0-37   2.40.1-1~deb11u1
ii  libxml22.9.10+dfsg-6.7+deb11u4
ii  psmisc 23.4-2

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.38.3-1+deb11u1
ii  evolution-plugin-pstimport   3.38.3-1+deb11u1
ii  evolution-plugins3.38.3-1+deb11u1
ii  yelp 3.38.3-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.27-2+deb11u2
ii  network-manager 1.30.6-1+deb11u1



Bug#919785: Yad new version available

2023-05-04 Thread Sebastian Späth
By now, version 12.3 of yad has been released. The new upstream source 
location is https://github.com/v1cont/yad although the maintainer 
(v1cont) is the same as in the original sourceforge location.


Debian has not updated yad since 2018, and it shows (wayland support 
etc), so it would be great to bump yad.




Bug#1035280: pipewire-pulse 0.3.70 client side crash when load-module module-zeroconf-discover against a pipewire-pulse with module-native-protocol-tcp and module-zeroconf-publish

2023-05-04 Thread Alban Browaeys
reported upstream as
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3199

likely the bug is triggered by the module erroring out when trying to
connect on a non existent remote port.
Then the segfault is bug in pipewire.

On Tue, 02 May 2023 02:57:36 +0200 Alban Browaeys
 wrote:
> Just a quick note that I am able to reproduce this issue with master.
> Though at times it works with upstream master, running from builddir
> via "make run" under the ./pw-uninstalled.sh environment.
> Maybe this only works because the settings are different.
> 
> Likely an upstream issue.
> 
> Cheers,
> Alban
> 
> 



Bug#1035489: krb5-config: missing dependency to C compiler

2023-05-04 Thread Russ Allbery
Moessbauer Felix  writes:

> the krb5-config tool needs a C compiler to work at all:

> krb5-config
> /usr/bin/krb5-config: 1: cc: not found
> Failed to find installation architecture

> To reproduce, just install libkrb5-dev (e.g. in the debian:bookworm
> container) and call krb5-config. Once a cc is installed (e.g. gcc), the
> tool works properly.

> This bug affects at least bullseye and bookworm.

Technically, I suppose this could be represented with a dependency, but
I'm curious how you ended up wanting to run krb5-config on a system
without a compiler.  In general, all *-dev packages in Debian are only
useful with a compiler, since their whole purpose is to provide support
for linking new binaries with libraries.  We generally don't make that
dependency explicit, though, since it adds a lot of edges to the
dependency graph and it's not clear they serve much purpose.

One of the technical problems with trying to declare this dependency
explicitly is that Debian comes with multiple compilers and we don't
currently have a mechanism so far as I know to depend on a generic C
compiler.  (Build dependencies for Debian packages themselves depend on
build-essential, but build-essential forces installation of gcc,
specifically, as opposed to, say, clang.)

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



Bug#1035516: php-smbclient broke with samba 4.17.5

2023-05-04 Thread Alan Krempler
Package: php-smbclient
Version: 1.0.6-8
Severity: grave
Justification: renders package unusable

php-smbclient does not work with samba versions 4.17.5 and above:
https://github.com/eduardok/libsmbclient-php/issues/98
https://github.com/nextcloud/server/issues/36773

php-smbclient upstream version 1.1.1 fixes the issue. 


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:de:hr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages php-smbclient depends on:
ii  php-common2:93
pn  php8.2-smbclient  
ii  ucf   3.0043+nmu1

php-smbclient recommends no packages.

php-smbclient suggests no packages.



Bug#1035096: installation-report Bookworm RC2 GRUB not installed

2023-05-04 Thread Peter Ehlert



On 5/2/23 11:59, Pascal Hambourg wrote:

On 02/05/2023 at 15:21, Peter Ehlert wrote:


DI asks on which drive to install GRUB
User says disk X
DI attempts to install on Drive Y
result ... GRUB does not get installed at all


This is completely different from what I understood.

The statement "GRUB does not get installed at all" is refuted by 
/var/log/syslog which indicates clearly that GRUB was successfully 
installed on /dev/sdb:


Apr 28 23:55:51 grub-installer: info: Running chroot /target 
grub-install  --force "/dev/sdb"

(...)
Apr 28 23:56:01 grub-installer: Installation finished. No error 
reported.


Can you described what happened exactly ?
Were you prompted to "Install the GRUB boot loader to your primary 
drive?" ? If yes, did you answer "yes" or "no" ?
Where you then prompted to select the "Device for boot loader 
installation" ? If yes, what option did you select exactly ?

from my initial installation-report:
"when install was finished, a list of drives was displayed, asking where 
to install GRUB.

the install drive was highlighted
I selected the drive with bios_grub
the display showed "installing GRUB on (...drive it was installed on...)"

Pardon me for not being more clear. I will elaborate from the photos I took

"Install the GRUB boot loader" menu ... 6 items
Enter device manually
/dev/sda (usb-SanDisk ...
/dev/sdb (ata-WL4000G ...
/dev/sdc (ata-WDC_WD300...
/dev/sdd (ata-WDC_WD300...
/dev/sde (ata-SanDisk_SDSSDA240G_162248447811)


I selected /dev/sde and pressed the Continue button

then the GUI progress bar Installing GRUB and I see Running 
"grub-install /dev/sdd" ...


in this case sdd was the install location, sde is the drive that has a 
bios_grub flagged partition




setting up BIOS to boot from a drive that does not have a bios_grub 
flagged partition results in:


"GPT-formatted disk.

Legacy boot not supported. Press any key to reboot."


If this is a message from the BIOS, then it is flawed. A compliant 
BIOS should not care about the partition table, even less the presence 
of any kind of partition. All a BIOS should care about is the presence 
of the "boot signature" 0x55, 0xAA at the end of the boot sector.


Yes, that is from the BIOS

running Debian, from the terminal:

peter@z820-3:~$ su -
Password:
root@z820-3:~# grub-install /dev/sda && update-grub
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot 
Partition; embedding won't be possible.
grub-install: error: embedding is not possible, but this is required for 
cross-disk install.

root@z820-3:~#








Bug#1035515: [pre-approval] unblock: gdb/13.1-2.1

2023-05-04 Thread Emanuele Rocca
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: g...@packages.debian.org, debian-...@lists.debian.org
Control: affects -1 + src:gdb

Hello release team,

Please unblock package gdb.

[ Reason ]
The most basic functionality of GDB, namely debugging an hello world C
program, is currently broken in Bookworm for arm64 systems with pointer
authentication enabled. See https://bugs.debian.org/1034611.

There is a patch merged upstream addressing the issue [0]. I've tested
it on a arm64 system and can confirm that it works. See also:
https://bugs.debian.org/1034611#15

I've prepared an NMU, not yet uploaded. Please find the debdiff
attached.

[ Impact ]
GDB entirely unusable for most arm64 users.

[ Tests ]
Upstream test suite passes. Manually verified that #1034611 can be
reproduced with gdb 13.1-2 from Bookworm, and it cannot with the
proposed changes.

[ Risks ]
Minimal, the patch is small and targeted. Additionally, it only touches
arm64-specific code.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock gdb/13.1-2.1

Thanks,
  Emanuele

[0] 
https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=b3eff3e15576229af9bae026c5c23ee694b90389
diff -Nru gdb-13.1/debian/changelog gdb-13.1/debian/changelog
--- gdb-13.1/debian/changelog	2023-02-24 22:58:29.0 +0100
+++ gdb-13.1/debian/changelog	2023-05-04 13:40:28.0 +0200
@@ -1,3 +1,11 @@
+gdb (13.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * aarch64: add aarch64-pauth-registers.patch to check for valid inferior
+thread/regcache before reading pauth registers. (Closes: #1034611)
+
+ -- Emanuele Rocca   Thu, 04 May 2023 13:40:28 +0200
+
 gdb (13.1-2) unstable; urgency=medium
 
   * Apply upstream proposed fix for PR/30158
diff -Nru gdb-13.1/debian/patches/aarch64-pauth-registers.patch gdb-13.1/debian/patches/aarch64-pauth-registers.patch
--- gdb-13.1/debian/patches/aarch64-pauth-registers.patch	1970-01-01 01:00:00.0 +0100
+++ gdb-13.1/debian/patches/aarch64-pauth-registers.patch	2023-05-04 13:40:28.0 +0200
@@ -0,0 +1,283 @@
+From b3eff3e15576229af9bae026c5c23ee694b90389 Mon Sep 17 00:00:00 2001
+From: Luis Machado 
+Date: Fri, 24 Mar 2023 07:58:38 +
+Subject: [PATCH] aarch64: Check for valid inferior thread/regcache before
+ reading pauth registers
+
+There were reports of gdb throwing internal errors when calling
+inferior_thread ()/get_current_regcache () on a system with
+Pointer Authentication enabled.
+
+In such cases, gdb produces the following backtrace, or a variation
+of it (for gdb's with the non-address removal implemented only in
+the aarch64-linux-tdep.c file).
+
+../../../repos/binutils-gdb/gdb/thread.c:86: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.
+A problem internal to GDB has been detected,
+further debugging may prove unreliable.
+- Backtrace -
+0xe04a571f gdb_internal_backtrace_1
+../../../repos/binutils-gdb/gdb/bt-utils.c:122
+0xe04a57f3 _Z22gdb_internal_backtracev
+../../../repos/binutils-gdb/gdb/bt-utils.c:168
+0xe0b52ccf internal_vproblem
+../../../repos/binutils-gdb/gdb/utils.c:401
+0xe0b5310b _Z15internal_verrorPKciS0_St9__va_list
+../../../repos/binutils-gdb/gdb/utils.c:481
+0xe0e24b8f _Z18internal_error_locPKciS0_z
+../../../repos/binutils-gdb/gdbsupport/errors.cc:58
+0xe0a88983 _Z15inferior_threadv
+../../../repos/binutils-gdb/gdb/thread.c:86
+0xe0956c87 _Z20get_current_regcachev
+../../../repos/binutils-gdb/gdb/regcache.c:428
+0xe035223f aarch64_remove_non_address_bits
+../../../repos/binutils-gdb/gdb/aarch64-tdep.c:3572
+0xe03e8abb _Z31gdbarch_remove_non_address_bitsP7gdbarchm
+../../../repos/binutils-gdb/gdb/gdbarch.c:3109
+0xe0a692d7 memory_xfer_partial
+../../../repos/binutils-gdb/gdb/target.c:1620
+0xe0a695e3 _Z19target_xfer_partialP10target_ops13target_objectPKcPhPKhmmPm
+../../../repos/binutils-gdb/gdb/target.c:1684
+0xe0a69e9f target_read_partial
+../../../repos/binutils-gdb/gdb/target.c:1937
+0xe0a69fdf _Z11target_readP10target_ops13target_objectPKcPhml
+../../../repos/binutils-gdb/gdb/target.c:1977
+0xe0a69937 _Z18target_read_memorymPhl
+../../../repos/binutils-gdb/gdb/target.c:1773
+0xe08be523 ps_xfer_memory
+../../../repos/binutils-gdb/gdb/proc-service.c:90
+0xe08be6db ps_pdread
+../../../repos/binutils-gdb/gdb/proc-service.c:124
+0x40001ed7c3b3 _td_fetch_value
+/build/glibc-RIFKjK/glibc-2.31/nptl_db/fetch-value.c:115
+0x40001ed791ef td_ta_map_lwp2thr
+/build/glibc-RIFKjK/glibc-2.31/nptl_db/td_ta_map_lwp2thr.c:194
+0xe07f4473 thread_from_lwp
+../../../repos/binutils-gdb/gdb/linux-thread-db.c:413
+0xe07f6d6f 

Bug#1035514: unblock: nncp/8.8.2-3

2023-05-04 Thread John Goerzen
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package nncp

[ Reason ]

This unblock request is to support a small three-line diff that
corrects a data handling bug in NNCP.

[ Impact ]

At
http://lists.cypherpunks.ru/archive/nncp-devel/CAACH8H_3XugxyUQkgbOMNK=H_WAw-XNPR5ZH4Si29OR2fef=m...@mail.gmail.com/T/
, a bug was reported relating to the NNCP chunked (split) file transfer mode.
When chunked mode is used, large files are split into smaller chunks to make
transport possible over small media (eg, a 1TB file across a 128GB USB drive).
The bug resulted in reassembly being impossible with certain combinations of
chunk size and file size.

A fix already in my tree was also applied to postinst, which prevents it exiting
in error if a user had manually created the nncp user prior to installing nncp.

[ Tests ]

Sergey Matveev, author of NNCP, fixed the bug upstream.  The original reporter
confirmed it was fixed.

[ Risks ]

The fix itself is trivial as seen in the attached debdiff.  It is limited in
scope to the chunked transfer mode.  The chunked transfer mode isn't used all
that often, but for those that do wish to use it, this prevents possible data
loss.

In the release announcement for NNCP 8.8.3 at
https://nncp.mirrors.quux.org/Release-8_005f8_005f3.html , you can see it
includes this fix, as well as a bunch of updated Go dependencies.  The updated
Go dependencies would not be suitable for the transition at this point.
Therefore, I applied just the fix for this bug from the 8.8.3 branch and
uploaded 8.8.2-3 with it to unstable.  To say I "backported" it would, I
suppose, be technically accurate but overstating things; it applied directly to
the 8.8.2 tree since that it what it was targeted to upstream anyhow.  "Cherry
picked" would be a more accurate term.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]

unblock nncp/8.8.2-3
diff -Nru nncp-8.8.2/debian/changelog nncp-8.8.2/debian/changelog
--- nncp-8.8.2/debian/changelog 2023-01-01 15:32:04.0 -0600
+++ nncp-8.8.2/debian/changelog 2023-04-29 10:25:52.0 -0500
@@ -1,3 +1,11 @@
+nncp (8.8.2-3) unstable; urgency=medium
+
+  * Apply upstream bugfix to chunk reassembly.
+  * Tweak postinst to not generate an error if the nncp user was
+previously created by the user.
+
+ -- John Goerzen   Sat, 29 Apr 2023 10:25:52 -0500
+
 nncp (8.8.2-2) unstable; urgency=medium
 
   * Team upload
diff -Nru nncp-8.8.2/debian/nncp.postinst nncp-8.8.2/debian/nncp.postinst
--- nncp-8.8.2/debian/nncp.postinst 2021-09-21 07:29:18.0 -0500
+++ nncp-8.8.2/debian/nncp.postinst 2023-01-07 08:25:29.0 -0600
@@ -25,7 +25,7 @@
mkdir /var/spool/nncp
 CREATED=1
fi
-   adduser --no-create-home --home /var/spool/nncp --system --group 
nncp
+   adduser --no-create-home --home /var/spool/nncp --system --group 
nncp || true
 if [ "$CREATED" = "1" ]; then
chown nncp:nncp /var/spool/nncp 
 fi
diff -Nru nncp-8.8.2/debian/patches/reass-backport.diff 
nncp-8.8.2/debian/patches/reass-backport.diff
--- nncp-8.8.2/debian/patches/reass-backport.diff   1969-12-31 
18:00:00.0 -0600
+++ nncp-8.8.2/debian/patches/reass-backport.diff   2023-04-29 
10:24:50.0 -0500
@@ -0,0 +1,29 @@
+Description: Fix bug in reassembly of certain chunked files
+ On April 28 2023, a bug was reported describing that reassembly of chunked
+ files could fail when the file size is an integer multiple of the chunk size.
+ 
http://lists.cypherpunks.ru/archive/nncp-devel/zez6w5vhuvzr2...@stargrave.org/T/#t
+ .
+ NNCP author Sergey Matveev released NNCP 8.8.3, which also contained updates
+ to the Go dependencies, including to Go 1.20.  This makes it unsuitable for
+ upload to unstable or transition to testing at this time.
+ .
+ This patch isolates just the bugfix from NNCP 8.8.3, backporting it to NNCP
+ 8.8.2.
+Author: Sergey Matveev
+Origin: upstream
+Applied-Upstream: 523ac7e7dd5a2f97711fa369f7a73e43ff7b49bc
+Last-Update: 2023-04-29
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/cmd/nncp-reass/main.go
 b/src/cmd/nncp-reass/main.go
+@@ -124,7 +124,8 @@
+   }
+   var badSize bool
+   if chunkNum+1 == len(chunksPaths) {
+-  badSize = uint64(fi.Size()) != 
metaPkt.FileSize%metaPkt.ChunkSize
++  left := metaPkt.FileSize % metaPkt.ChunkSize
++  badSize = left != 0 && uint64(fi.Size()) != left
+   } else {
+   badSize = uint64(fi.Size()) != metaPkt.ChunkSize
+   }
diff -Nru nncp-8.8.2/debian/patches/series nncp-8.8.2/debian/patches/series
--- nncp-8.8.2/debian/patches/series

Bug#1035513: unblock: onionshare/2.6-3

2023-05-04 Thread Hefee
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: onionsh...@packages.debian.org, he...@debian.org
Control: affects -1 + src:onionshare

Please unblock package onionshare

[ Reason ]
The new version fixes #1014966. It is only a fix in autopkgtests to make
them non flaky.

[ Impact ]
As the new version only fixes autopkgtests, nothing for the users
changes.

[ Tests ]
Run together with people of debianci the tests around 30 times to make
sure, that is not flaky.

[ Risks ]
The risks are very low,as it does not toches the code itself.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
onionshare is marked as autoremoval on 20th, May. With the current aging
of 20 days, the package would be kicked out of testing before the
20-days delay is over.

unblock onionshare/2.6-3
diff -Nru onionshare-2.6/debian/changelog onionshare-2.6/debian/changelog
--- onionshare-2.6/debian/changelog 2022-11-19 17:38:57.0 +0100
+++ onionshare-2.6/debian/changelog 2023-05-04 15:24:12.0 +0200
@@ -1,3 +1,15 @@
+onionshare (2.6-3) unstable; urgency=medium
+
+  * source only upload.
+
+ -- Sandro Knauß   Thu, 04 May 2023 15:24:12 +0200
+
+onionshare (2.6-2) unstable; urgency=medium
+
+  * The verbose flag makes the chat test not flaky. (Closes: #1034688)
+
+ -- Sandro Knauß   Tue, 02 May 2023 22:27:57 +0200
+
 onionshare (2.6-1) unstable; urgency=medium
 
   * new upstream release
diff -Nru onionshare-2.6/debian/tests/control 
onionshare-2.6/debian/tests/control
--- onionshare-2.6/debian/tests/control 2022-11-19 17:38:57.0 +0100
+++ onionshare-2.6/debian/tests/control 2023-04-25 23:45:25.0 +0200
@@ -18,7 +18,7 @@
 Restrictions: allow-stderr,
 Features: test-name=share_website
 
-Test-Command: XDG_CONFIG_HOME="$AUTOPKGTEST_TMP" onionshare-cli --local-only 
--chat --auto-stop-timer 2
+Test-Command: XDG_CONFIG_HOME="$AUTOPKGTEST_TMP" onionshare-cli -v 
--local-only --chat --auto-stop-timer 2
 Depends: onionshare-cli
 Restrictions: allow-stderr,
 Features: test-name=chat_server


Bug#1034650: debian-installer: bookworm d-i rc1: apt-get clean breaks bash-completion

2023-05-04 Thread Cyril Brulebois
Hi David,

David Kalnischkies  (2023-05-04):
> before I am playing bug ping-pong (as I don't think we can do much
> about this on the apt side), let me ask a d-i question first:

Entirely fair, thanks. Putting debian-boot@ in copy since currently the
bug is assigned to apt… and others might have some feedback about my
proposal(s).

> Why is d-i calling 'apt-get clean' to begin with?

Checking occurrences of `apt-get clean` (I didn't check for variations)
in our packages, I see two callers.

One is pkgsel (which deals with tasksel and pulls many/most packages),
and one later on in finish-install (which as you can guess runs at the
end).

> Is it perhaps just wanting to remove /var/cache/apt/archives/*.deb ?
> If so, could you switch to: -o APT::Keep-Downloaded-Packages=false
> (well, probably in a conf file rather than on each command line).

There are various apt-get (not clean) calls, some of them wrapped, and I
have no idea what the consequences of tweaking them could be. In any
case, while deplying a conf file during the installation process could
be attempted, it's far too late to try toying with that…

We can probably keep track of the suggestion via some bug report against
debian-installer, so that someone can investigate that post-Bookworm
(probably removing the possible tweak discussed below).

> This instructs apt(-get) to remove the deb file right after it has
> installed them with dpkg, which might even be beneficial for space
> constraint installation targets. At the very least it is a much used
> & tested option as it is the default with apt (but not apt-get).

OK, thanks.

> d-i could also "just" run 'apt-cache gencaches' to create the caches;
> but perhaps it is intended that the caches are gone (docker people e.g.
> like to do that I am told, but they nuke other things as well…).

The finish-install call can be traced back to:
  https://bugs.debian.org/586434

> > > - Fix "bash-completion". Make it work even if /var/cache/apt/*.bin are
> > >   not present (for example, by recreating them on-the-fly)
> 
> The completion script explicitly disables the recreation on-the-fly as
> creating the files takes a while robbing users for many seconds of their
> interactivity. So, we can't just "fix" the completion script as that has
> a(nother?) set of users complain as well.

With all the backstory, the interactions/dependencies between
bash-completion and apt's internal files became clear, thanks.

For Bookworm, I'm tempted to add `apt-cache gencaches` after `apt-get
clean` in finish-install, restoring the files bash-completion relies on.

That'd waste some little time, rebuilding some of the files that were
just deleted… but at least we wouldn't risk anything in the rest of the
installation process.

(Maybe making the extra call conditional to bash-completion's being
installed? Not sure about the “small optimization” vs. “different apt
files depending on the installed packages” balance.)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#1035512: unblock: fvwm/1:2.7.0-2

2023-05-04 Thread Jaimos Skriletz
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: f...@packages.debian.org
Control: affects -1 + src:fvwm

Please unblock package fvwm 1:2.7.0-2

The newly uploaded package fixes bug #1034054 in which a change in
libX11 1.8.1 can cause fvwm to crash when handling expose events. The
patch is backported from fvwm3. Here is the commit (diff) between
1:2.7.0-1 and 1:2.7.0-2:

https://github.com/somiaj/fvwm2-debian/commit/d4d1a7d8f66eddb09080c5f6a5b15f21b343b92a

[ Reason ]
Fix a bug that causes fvwm to crash in some cases.

[ Impact ]
The current fvwm package may crash and could cause minor data loss
losing any unsaved data when fvwm and xorg crash.

[ Tests ]
The patch has been tested with fvwm3, confirmed to fix the issue,
and no additional issues have been reported. In addition the patch
has been tested by a user in bug #1034054, and they have not had any
crash since applying the patch.

[ Risks ]
Minor. Code is straight forward, and currently running just fine
in fvwm3. The new fvwm package runs just fine with all my tests.

[ Checklist ]
  [*] all changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing
  (I linked to the actual diff to the debian/ of the source package)

unblock fvwm/1:2.7.0-2

jaimos



Bug#1035392: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

2023-05-04 Thread James Addison
[ replying with some re-ordering ]

On Wed, 3 May 2023 at 21:23, Pete Batard  wrote:

> Obviously, with the idea of not having ARM based device that are
> constrained to a single OS (be it Windows, Linux, BSD or something> else), 
> and considering that Windows and Device Tree don't work together,
> you want to go with a mode of operation that isn't Linux specific,
> which, even if ACPI has its drawbacks, pretty much forces the use of
> ACPI over Device Tree. Else, you have Linux going into the exact
> Microsoft strong-arm tactics that it should strive to avoid...

Yep, and for those situations, that's a point in favour of the third
"System Table Selection" value that I failed to mention:
"ACPI+Devicetree".

I'm cautious about recommending it, given an understanding that
enabling ACPI could increase the amount of non-free code (ACPI Machine
Language, in particular) that may run on the system as a result.
Perhaps there could be counterbalancing functionality benefits and/or
energy-usage savings... even then I'd recommend proceeding cautiously.

I'm not sure I'm qualified to say much about Debian's compatibility
with other operating systems on the same machine, other than to
mention that I do think it's highly compatible and that that's
something that maintainers, developers and users care about.

> On 2023.05.03 17:29, James Addison wrote:
> >* Perhaps Devicetree is a better default in EDK2 for ARM systems?
> > (that wouldn't solve the root cause, though)
>
> Please note that the reason why the Raspberry Pi UEFI firmware defaults
> to ACPI is so that this ARM device follows the relatively new ARM SBBR
> standard [3], which we (hopefully) expect more and more ARM64 based
> device to follow.

Slightly off-topic: do you know of cases where ACPI has helped a
vendor to adapt to shifting operating system interfaces or achieve
significant energy-usage savings?  I think that understanding some of
those could help to begin to address gaps that Debian/Linux/other
components have.

(and to mention why I ask.. I've been reading some of the history[1],
definitions[2], rationale[3], and state-of-support[4] around
DeviceTree and ACPI in Linux, including in relation to ARM servers.
it looks like I have a decade-or-so of history to catch up on there)

[1] - 
https://lore.kernel.org/linux-arm-kernel/CAOesGMjKeRb=ffjm0mabdihbeicgm4eqw9d5i_6-rfxtnpb...@mail.gmail.com/

[2] - https://elinux.org/Device_Tree_What_It_Is

[3] - https://www.secretlab.ca/archives/151

[4] - https://www.kernel.org/doc/html/v6.3/arm64/arm-acpi.html



Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script

2023-05-04 Thread Kovid Goyal
And yet having shell scripts opened in the shell is a perfectly
reasonable thing to do, for example when browsing shell scripts in your
file manager. Indeed this feature exists because it was requested by
users. It cant be the URL handling applications responsibility to
know what the user intended and protect them from themselves.

In this case, mutt should be modified to have a separate view vs open
action. Or it's the users responsibility to configure their system to
view shell files rather than execute them, if they are in the habit of
clicking exe's attached to emails or otherwise clicking untrusted shell
scripts. Removing or crippling a capability in URL consuming software is
not the solution to clicking URLs.


On Wed, May 03, 2023 at 02:07:37PM -0400, James McCoy wrote:
> Keeping the full text for Kovid's benefit.
> 
> On Wed, Apr 26, 2023 at 02:50:47PM +0200, Raphael Hertzog wrote:
> > Package: kitty
> > Version: 0.26.5-4
> > Severity: serious
> > Tags: security
> > X-Debbugs-Cc: Debian Security Team 
> > 
> > Hello,
> > 
> > I was reading https://lists.debian.org/20230425190728.ga1471...@subdivi.de
> > in mutt and that mail contains 3 shell scripts as attachments
> > (application/x-sh). I wanted to have a look at the scripts and thus I
> > "opened" those attachments... that open operation has been handled by
> > Kitty due its MimeType declaration in
> > /usr/share/applications/kitty-open.desktop [1] and the shell script has
> > thus been fed to "kitty +open 

Bug#697821: dependencies

2023-05-04 Thread matthias . geiger1024

4) is already packaged so that's one less concern.

bye,

---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-


Bug#1035500: libhwloc-dev ships uncompilable headers

2023-05-04 Thread Samuel Thibault
Control: tags -1 + wontfix

Hello,

Steve Langasek, le jeu. 04 mai 2023 11:31:19 +0200, a ecrit:
> libhwloc-dev ships header files which have includes that are not satisfied
> by its dependencies.  For my purposes, I've worked around these unusable
> headers by adding quirks to my scripts, but it seems worth reporting as a
> bug that headers are being shipped that aren't usable.
> 
> - /usr/include/hwloc/cuda*.h include cuda.h from nvidia-cuda-dev, which a)
>   is not depended on, b) is only available on amd64, arm64, and ppc64el.
> 
> - /usr/include/hwloc/nvml.h includes nvml.h from libnvidia-ml-dev, same
>   as above.
> 
> - /usr/include/hwloc/levelzero.h includes level_zero/ze_api.h which does not
>   exist in Debian.
> 
> - /usr/include/hwloc/opencl.h includes CL/cl.h from opencl-c-headers.
> 
> - /usr/include/hwloc/openfabrics-verbs.h includes infiniband/verbs.h from
>   libibverbs-dev.
> 
> - /usr/include/hwloc/rsmi.h includes rocm_smi/rocm_smi.h which doesn't exist
>   in Debian.

Yes, all of these are only useful in the respective particular cases.

Samuel



Bug#1029843: brcmfmac: requested firmware filename inconsistent with linux-firmware.git on non-devicetree systems

2023-05-04 Thread Diederik de Haas
Control: block -1 1035505

On Thursday, 4 May 2023 01:41:12 CEST Cyril Brulebois wrote:
> Diederik de Haas  (2023-05-04):
> > And that makes it a firmware-brcm80211 issue and now it all does make
> > sense as it now all does tie together :-)
> 
> Great, that's what it looked like to me but I was afraid I could have
> misunderstood the situation and I didn't want to digress in a wrong
> direction…
> 
> > So while upstream does define the link from what I earlier called
> > 'weird' name to brcmfmac43455-sdio.raspberrypi,4-model-b.txt, the Debian
> > firmware-brcm80211 package does not define that link and is therefor
> > missing.
> 
> Adding the links will at least make those paths shows up in the
> Contents-firmware indices generated by debian-cd. Those contain 3
> “columns”: path, package, component (the current format string is
> "%-55s %s %s\n").

Assuming the '55' stands for max 55 chars, that could be an issue?

> Even if hw-detect didn't misbehave because of spaces in filenames (i.e.

It turns out that spaces (and or backslashes to escape them) seems to be an 
issue for the Debian scripts used to make the Debian firmware-nonfree packages 
too. See https://bugs.debian.org/1035505 for details.
Once that is fixed, I can submit my MR to add those missing symlinks.

> For Bookworm, given we expect the firmware package to be adjusted to
> include those symlinks, what if hw-detect had some little cheatsheet,

Seems doable. I'm not going to spend time trying to make that though.
I know virtually nothing about d-i/hw-detect internals, so it seems very 
unwise for me to even try it.
Given the (specific) subject at hand, you won't be surprised that there's also 
a motivational issue ;-)

Cheers, 
 Diederik

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


Bug#1033953: unblock: gimp-help/2.10.34-1

2023-05-04 Thread Jordi Mallach
Hey Paul,

El dc. 03 de 05 de 2023 a les 19:48 +0200, en/na Paul Gevers va
escriure:
> Control: tags -1 moreinfo
> 
> Hi,
> 
> On 03-05-2023 12:03, Jordi Mallach wrote:
> > This is the final .debdiff for this unblock request.
> 
> There might have been a misunderstanding, but your debdiff misses the
> vast majority of upstream changes:
>   4255 files changed, 2256958 insertions(+), 1205010 deletions(-)
> 
> Can you please explain?

I honestly thought you were more interested in the packaging changes
than the upstream diff, sorry.

The diff is huge because there are a lot of new translations, and many
documentation additions. As I said in my original message, this
documentation update was due years ago and it finally captures the real
state of the GIMP version we shipped in bullseye and will ship in
bookworm.

This source has no binary code and comparing the contents of gimp-help-
en 2.10.0 and 2.10.34, everything seems sane.

I have made available a diff that can more or less be skimmed at
https://oskuro.net/gimp-help-full.diff.xz. I have excluded
automake/autoconf/aclocal generated bits from it with

debdiff --exclude INSTALL --exclude missing --exclude install-sh --
exclude aclocal.m4 --exclude config.guess --exclude config.sub --
exclude configure --exclude Makefile.in --exclude ChangeLog /tmp/gimp-
help_2.10.0-1.dsc ~/git/debian/gnome-team/gimp-help_2.10.34-1.dsc

I'm also attaching the output of diffstat.

Thanks,
Jordi
-- 
Jordi Mallach 
Debian Project


diffstat.xz
Description: application/xz


Bug#1035511: iptables-netflow-dkms: fails to upgrade from bullseye: fails to build a module for the bullseye kernel

2023-05-04 Thread Andreas Beckmann
Package: iptables-netflow-dkms
Version: 2.6-3.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'bullseye'.
It installed fine in 'bullseye' (with linux-headers-amd64 installed),
then the upgrade to 'bullseye' fails.

>From the attached log (scroll to the bottom...):

  Setting up iptables-netflow-dkms (2.6-3.1) ...
  Loading new ipt-netflow-2.6 DKMS files...
  It is likely that 5.10.28 belongs to a chroot's host
  Building for 5.10.0-22-amd64 and 6.1.0-7-amd64
  Building initial module for 5.10.0-22-amd64
  Error! Bad return status for module build on kernel: 5.10.0-22-amd64 (x86_64)
  Consult /var/lib/dkms/ipt-netflow/2.6/build/make.log for more information.
  dpkg: error processing package iptables-netflow-dkms (--configure):
   installed iptables-netflow-dkms package post-installation script subprocess 
returned error exit status 10

As during the upgrade phase it is very likely that both the old and new
kernel and their headers are installed, the dkms module should be able
to build for both kernel versions (or use some BUILD_EXCLUSIVE_*
settings to exclude unsupported versions, this will be easier from
bookworm+1 onwards).

The dkms.log says:

DKMS make.log for ipt-netflow-2.6 for kernel 5.10.0-22-amd64 (x86_64)
Thu May  4 11:57:32 UTC 2023
./gen_compat_def > compat_def.h
Test symbol xt_family linux/netfilter_ipv4/ip_tables.h  declared
Test struct timeval linux/ktime.h  undeclared
Test struct proc_ops linux/proc_fs.h  declared
Test symbol synchronize_sched linux/rcupdate.h  undeclared
Test symbol nf_bridge_info_get linux/netfilter_bridge.h  declared
Test struct vlan_dev_priv linux/if_vlan.h  declared
Test member nf_ct_event_notifier.ct_event net/netfilter/nf_conntrack_ecache.h  
undeclared
Compiling 2.6 for kernel 5.10.178
make -C /lib/modules/5.10.0-22-amd64/build 
M=/var/lib/dkms/ipt-netflow/2.6/build modules
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
make[1]: Entering directory '/usr/src/linux-headers-5.10.0-22-amd64'
  CC [M]  /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.o
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:96:4: warning: #warning 
"Requested physdev is not compiled." [-Wcpp]
   96 | #  warning "Requested physdev is not compiled."
  |^~~
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: In function 'nf_seq_show':
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:762:39: warning: format '%lu' 
expects argument of type 'long unsigned int', but argument 3 has type 's64' 
{aka 'long long int'} [-Wformat=]
  762 |seq_printf(seq, " Flows selected %lu, discarded %lu.",
  | ~~^
  |   |
  |   long unsigned int
  | %llu
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:762:54: warning: format '%lu' 
expects argument of type 'long unsigned int', but argument 4 has type 's64' 
{aka 'long long int'} [-Wformat=]
  762 |seq_printf(seq, " Flows selected %lu, discarded %lu.",
  |~~^
  |  |
  |  long unsigned int
  |%llu
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:766:39: warning: format '%lu' 
expects argument of type 'long unsigned int', but argument 3 has type 's64' 
{aka 'long long int'} [-Wformat=]
  766 |seq_printf(seq, " Flows selected %lu.", 
atomic64_read(_selected));
  | ~~^
  |   |
  |   long unsigned int
  | %llu
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: In function 
'netflow_conntrack_event':
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:4622:36: warning: passing 
argument 2 of 'notifier->fcn' discards 'const' qualifier from pointer target 
type [-Wdiscarded-qualifiers]
 4622 |   ret = notifier->ct_event(events, item);
  |^~~~
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:4622:36: note: expected 
'struct nf_ct_event *' but argument is of type 'const struct nf_ct_event *'
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: At top level:
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:4687:14: error: 
initialization of 'int (*)(unsigned int,  struct nf_ct_event *)' from 
incompatible pointer type 'int (*)(const unsigned int,  const struct 
nf_ct_event *)' [-Werror=incompatible-pointer-types]
 4687 |  .ct_event = netflow_conntrack_event
  |  ^~~
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:4687:14: note: (near 
initialization for 'ctnl_notifier.fcn')
cc1: some warnings being treated as 

Bug#1035509: [pre-approval] unblock: vim/2:9.0.1378-2

2023-05-04 Thread James McCoy
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: v...@packages.debian.org
Control: affects -1 + src:vim

Please unblock package vim

[ Reason ]
- Fix for CVE-2023-2426 (using uninitialized memory)
- Minor fix for indenting of Perl scripts (regression from bullseye)

[ Impact ]
- Shipping with a known CVE, whose fix was requested by the security
  team
- Thousands of wasted keystrokes indenting Perl scripts

[ Tests ]
- New test was added upstream for the CVE, but its mainly useful for
  running under valgrind

[ Risks ]
Fixes are small and straight forward.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock vim/2:9.0.1378-2
diffstat for vim-9.0.1378 vim-9.0.1378

 changelog| 
   7 
 patches/Fix-GH-267-where-indent-after-a-sub-would-not-work.patch | 
  22 +
 patches/debian/Support-sourcing-a-vimrc.tiny-when-Vim-is-invoked-as-vi.patch | 
   2 
 patches/patch-9.0.1499-using-uninitialized-memory-with-fuzzy-matc.patch  | 
 147 ++
 patches/series   | 
   2 
 5 files changed, 179 insertions(+), 1 deletion(-)

diff -Nru vim-9.0.1378/debian/changelog vim-9.0.1378/debian/changelog
--- vim-9.0.1378/debian/changelog   2023-03-04 14:41:33.0 -0500
+++ vim-9.0.1378/debian/changelog   2023-05-04 06:24:44.0 -0400
@@ -1,3 +1,10 @@
+vim (2:9.0.1378-2) unstable; urgency=medium
+
+  * Backport 9.0.1499 to fix CVE-2023-2426 (Closes: #1035323)
+  * Backport fix for indenting of Perl subroutines (Closes: #1034529)
+
+ -- James McCoy   Thu, 04 May 2023 06:24:44 -0400
+
 vim (2:9.0.1378-1) unstable; urgency=medium
 
   * Merge upstream patch v9.0.1378
diff -Nru 
vim-9.0.1378/debian/patches/debian/Support-sourcing-a-vimrc.tiny-when-Vim-is-invoked-as-vi.patch
 
vim-9.0.1378/debian/patches/debian/Support-sourcing-a-vimrc.tiny-when-Vim-is-invoked-as-vi.patch
--- 
vim-9.0.1378/debian/patches/debian/Support-sourcing-a-vimrc.tiny-when-Vim-is-invoked-as-vi.patch
2023-03-04 14:41:33.0 -0500
+++ 
vim-9.0.1378/debian/patches/debian/Support-sourcing-a-vimrc.tiny-when-Vim-is-invoked-as-vi.patch
2023-05-04 06:24:44.0 -0400
@@ -86,7 +86,7 @@
  # define SYS_VIMRC_FILE "$VIM/vimrc"
  #endif
 diff --git a/src/structs.h b/src/structs.h
-index d020449..dbbecb4 100644
+index 46a71cb..ac661a6 100644
 --- a/src/structs.h
 +++ b/src/structs.h
 @@ -4468,6 +4468,9 @@ typedef struct
diff -Nru 
vim-9.0.1378/debian/patches/Fix-GH-267-where-indent-after-a-sub-would-not-work.patch
 
vim-9.0.1378/debian/patches/Fix-GH-267-where-indent-after-a-sub-would-not-work.patch
--- 
vim-9.0.1378/debian/patches/Fix-GH-267-where-indent-after-a-sub-would-not-work.patch
1969-12-31 19:00:00.0 -0500
+++ 
vim-9.0.1378/debian/patches/Fix-GH-267-where-indent-after-a-sub-would-not-work.patch
2023-05-04 06:24:44.0 -0400
@@ -0,0 +1,22 @@
+From: Andy Lester 
+Date: Tue, 26 Apr 2022 20:07:43 -0500
+Subject: Fix GH#267 where indent after a sub would not work
+
+Closes: #1034529
+Signed-off-by: James McCoy 
+---
+ runtime/indent/perl.vim | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/runtime/indent/perl.vim b/runtime/indent/perl.vim
+index 4c91fa1..bd2a1a9 100644
+--- a/runtime/indent/perl.vim
 b/runtime/indent/perl.vim
+@@ -133,6 +133,7 @@ function! GetPerlIndent()
+ \ || synid == "perlHereDoc"
+ \ || synid == "perlBraces"
+ \ || synid == "perlStatementIndirObj"
++\ || synid == "perlSubDeclaration"
+ \ || synid =~ "^perlFiledescStatement"
+ \ || synid =~ '^perl\(Sub\|Block\|Package\)Fold'
+ let brace = strpart(line, bracepos, 1)
diff -Nru 
vim-9.0.1378/debian/patches/patch-9.0.1499-using-uninitialized-memory-with-fuzzy-matc.patch
 
vim-9.0.1378/debian/patches/patch-9.0.1499-using-uninitialized-memory-with-fuzzy-matc.patch
--- 
vim-9.0.1378/debian/patches/patch-9.0.1499-using-uninitialized-memory-with-fuzzy-matc.patch
 1969-12-31 19:00:00.0 -0500
+++ 
vim-9.0.1378/debian/patches/patch-9.0.1499-using-uninitialized-memory-with-fuzzy-matc.patch
 2023-05-04 06:24:44.0 -0400
@@ -0,0 +1,147 @@
+From: Bram Moolenaar 
+Date: Sat, 29 Apr 2023 21:38:04 +0100
+Subject: patch 9.0.1499: using uninitialized memory with fuzzy matching
+
+Problem:Using uninitialized memory with fuzzy matching.
+Solution:   Initialize the arrays used to store match positions.
+
+Closes: #1035323
+---
+ src/quickfix.c  |  5 -
+ src/search.c| 17 +++--
+ src/testdir/test_matchfuzzy.vim | 27 +++
+ src/version.c   |  2 ++
+ 4 

Bug#1035510: unblock: waylandpp/1.0.0-4

2023-05-04 Thread Georges Khaznadar
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: waylan...@packages.debian.org
Control: affects -1 + src:waylandpp

Please unblock package waylandpp


[ Reason ]
The new release is a fix for the RC bug #1035462

[ Impact ]
waylandpp rdepends ... kodi: "Kodi, formerly known as XBMC is an award winning
free and
open source software media-player and entertainment hub"

[ Tests ]
non-superficial tests are run during the build: see
https://salsa.debian.org/debian/waylandpp/-/pipelines/524875

[ Risks ]
The change is trivial: adding a seldom used library to the package
libwayland-client++0, which is libwayland-client-unstable++.so

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock waylandpp/1.0.0-4
diff -Nru waylandpp-1.0.0/debian/changelog waylandpp-1.0.0/debian/changelog
--- waylandpp-1.0.0/debian/changelog2022-05-17 09:32:49.0 +0200
+++ waylandpp-1.0.0/debian/changelog2023-05-03 17:39:41.0 +0200
@@ -1,3 +1,13 @@
+waylandpp (1.0.0-4) unstable; urgency=medium
+
+  * added usr/lib/*/libwayland-client-unstable++.so.* in the file
+d/libwayland-client++1.install, removed it from d/not-installed.
+Closes: #1035462
+  * fixed Standards-Version: 4.6.0.2 -> 4.6.2
+  * declared libwayland-client-unstable++.so in d/libwayland-client++1.shlib
+
+ -- Georges Khaznadar   Wed, 03 May 2023 17:39:41 +0200
+
 waylandpp (1.0.0-3) unstable; urgency=medium
 
   * Closes: #1011107, thanks to Thadeu Lima de Souza Cascardo;
diff -Nru waylandpp-1.0.0/debian/control waylandpp-1.0.0/debian/control
--- waylandpp-1.0.0/debian/control  2022-05-17 09:32:49.0 +0200
+++ waylandpp-1.0.0/debian/control  2023-05-03 17:39:41.0 +0200
@@ -12,7 +12,7 @@
libegl1-mesa-dev,
wayland-scanner++:any ,
   doxygen,
-Standards-Version: 4.6.0.2
+Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/debian/waylandpp
 Vcs-Git: https://salsa.debian.org/debian/waylandpp.git
 Homepage: https://github.com/NilsBrause/waylandpp
diff -Nru waylandpp-1.0.0/debian/libwayland-client++1.install 
waylandpp-1.0.0/debian/libwayland-client++1.install
--- waylandpp-1.0.0/debian/libwayland-client++1.install 2022-05-14 
17:21:55.0 +0200
+++ waylandpp-1.0.0/debian/libwayland-client++1.install 2023-05-03 
17:37:14.0 +0200
@@ -1 +1,2 @@
 usr/lib/*/libwayland-client++.so.*
+usr/lib/*/libwayland-client-unstable++.so.*
\ Pas de fin de ligne à la fin du fichier
diff -Nru waylandpp-1.0.0/debian/libwayland-client++1.shlibs 
waylandpp-1.0.0/debian/libwayland-client++1.shlibs
--- waylandpp-1.0.0/debian/libwayland-client++1.shlibs  2022-05-14 
17:21:55.0 +0200
+++ waylandpp-1.0.0/debian/libwayland-client++1.shlibs  2023-05-03 
17:39:41.0 +0200
@@ -1 +1,2 @@
-libwayland-client++ 1 libwayland-client++1 (>= 1.0.0)
+libwayland-client++  1 libwayland-client++1  (>= 1.0.0)
+libwayland-client-unstable++ 1 libwayland-client-unstable++1 (>= 1.0.0)
\ Pas de fin de ligne à la fin du fichier
diff -Nru waylandpp-1.0.0/debian/not-installed 
waylandpp-1.0.0/debian/not-installed
--- waylandpp-1.0.0/debian/not-installed2022-05-06 18:38:30.0 
+0200
+++ waylandpp-1.0.0/debian/not-installed2023-05-03 17:38:04.0 
+0200
@@ -1,3 +1,2 @@
-usr/lib/*/libwayland-client-unstable++.so.*
 usr/lib/*/cmake/*
 usr/share/doc/waylandpp/latex


Bug#1035508: dh-golang requires golang

2023-05-04 Thread Harald Dunkel

Package: dh-golang
Version: 1.59

Apparently there is a dependency between dh-golang and golang
missing in the control file:

:
dh clean
Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
Use of uninitialized value in pattern match (m//) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
Use of uninitialized value in pattern match (m//) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
Use of uninitialized value $_gcc_major in multiplication (*) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 450.
   dh_auto_clean
Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
Use of uninitialized value in pattern match (m//) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
Use of uninitialized value in pattern match (m//) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
Use of uninitialized value $_gcc_major in multiplication (*) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 450.
make -j8 clean
:
:
   dh_autoreconf
Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
Use of uninitialized value in pattern match (m//) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
Use of uninitialized value in pattern match (m//) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
Use of uninitialized value $_gcc_major in multiplication (*) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 450.
   dh_auto_configure
Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
Use of uninitialized value in pattern match (m//) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
Use of uninitialized value in pattern match (m//) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
Use of uninitialized value $_gcc_major in multiplication (*) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 450.
   dh_auto_build
Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
Use of uninitialized value in pattern match (m//) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443.
Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
Use of uninitialized value in pattern match (m//) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449.
Use of uninitialized value $_gcc_major in multiplication (*) at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 450.
:


Regards

Harri



Bug#1034650: debian-installer: bookworm d-i rc1: apt-get clean breaks bash-completion

2023-05-04 Thread David Kalnischkies
Hi,

before I am playing bug ping-pong (as I don't think we can do much about
this on the apt side), let me ask a d-i question first:

On Thu, Apr 20, 2023 at 10:33:08PM +0200, Cyril Brulebois wrote:
> Askar Safin  (2023-04-20):
> > I don't know what should really be done. I can list possible solutions:
> > 
> > - Fix d-i. Remove /usr/lib/finish-install.d/60cleanup or replace it with
> >   something else
> 
> d-i is merely exposing a bug in bash-completion, so I don't think we
> should change anything there.
> 
> > - Fix "apt-get clean". Make it not remove /var/cache/apt/*.bin

Why is d-i calling 'apt-get clean' to begin with?

Is it perhaps just wanting to remove /var/cache/apt/archives/*.deb ?
If so, could you switch to: -o APT::Keep-Downloaded-Packages=false
(well, probably in a conf file rather than on each command line).

This instructs apt(-get) to remove the deb file right after it has
installed them with dpkg, which might even be beneficial for space
constraint installation targets. At the very least it is a much used
& tested option as it is the default with apt (but not apt-get).


d-i could also "just" run 'apt-cache gencaches' to create the caches;
but perhaps it is intended that the caches are gone (docker people e.g.
like to do that I am told, but they nuke other things as well…).


> > - Fix "bash-completion". Make it work even if /var/cache/apt/*.bin are
> >   not present (for example, by recreating them on-the-fly)

The completion script explicitly disables the recreation on-the-fly as
creating the files takes a while robbing users for many seconds of their
interactivity. So, we can't just "fix" the completion script as that has
a(nother?) set of users complain as well.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature


Bug#1025165: No opus transcoding available after asterisk install

2023-05-04 Thread Faidon Liambotis
Control: found -1 1:20.2.1~dfsg+~cs6.13.40431413-1
Control: tags -1 patch

On Wed, Nov 30, 2022 at 04:18:24PM +0100, IB Development Team wrote:
> Package: asterisk
> Version: 1:16.28.0~dfsg-0+deb10u1
> 
> In clean Debian 10 after
> 
>     apt-get install asterisk
> 
> internal opus codec seems to be available in 'core show codecs' but not in
> 'core show translation' and transcoding with opus does not work; same in
> Debian 11 and asterisk 1:16.28.0~dfsg-0+deb11u1.

I believe the reason is that codec_opus_open_source.so is not shipped,
due to it not being built.

Adding "ADDONS_ENABLE += codec_opus_open_source" to debian/rules (e.g.
near the other ADDONS_ENABLE lines) addresses this issue. I've verified
that "core show translation" shows opus in the matrix after that. I'm
not sure why menuselect doesn't enable it by default.

Separately, it looks like there is a patch (2015_opus.patch) to add
libopusenc detection, used conditionally -if found- by the module
format_ogg_opus_open_source. However, libopusenc-dev is not in
Build-Depends. I've verified that the (already patched) build system
picks it up if I add it, and shlibs etc. are added.

Thanks,
Faidon



Bug#1035507: RM: bumblebee-nvidia [armhf i386] -- ANAIS; RoM; no more 32-bit nvidia drivers

2023-05-04 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

please remove the cruft packages

bumblebee-nvidia | 3.2.1-28+b1  | unstable/contrib | armhf, i386

Andreas



Bug#1035506: New upstream version 0.4.0

2023-05-04 Thread Guido Günther
Package: source
Version: 0.3.0-1
Severity: wishlist

There's a new upstream version 0.4.1

  https://gitlab.freedesktop.org/emersion/libliftoff/-/tags/v0.4.1

Would be great to have that in experimental as current sway, wlroots
requires it.
Cheers,
 -- Guido


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

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



Bug#1035505: firmware-nonfree: debian/bin/gencontrol.py fails on spaces and backslashes

2023-05-04 Thread Diederik de Haas
Source: firmware-nonfree
Version: 20230210-5
Severity: normal
X-Debbugs-Cc: 1029...@bugs.debian.org, k...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

While trying to prepare a MR to fix bug #1029843, I encountered a
failure which seems to be `gencontrol.py`'s inability to deal with
spaces and/or backslashes (used to escape the spaces).

$ debian/rules debian/control-real
mkdir -p debian/build
printf >debian/build/version-info 'Source: %s\nVersion: %s\n' firmware-nonfree 
20230210-6
./copy-firmware.sh debian/build/install
debian/bin/gencontrol.py /usr/src/linux-support-6.1.0-8
Traceback (most recent call last):
  File 
"/home/diederik/dev/debian/salsa/kernel-team/firmware-nonfree/debian/bin/gencontrol.py",
 line 341, in 
GenControl()()
  File 
"/home/diederik/dev/debian/salsa/kernel-team/firmware-nonfree/debian/bin/gencontrol.py",
 line 94, in __call__
self.do_main(packages, makefile)
  File 
"/home/diederik/dev/debian/salsa/kernel-team/firmware-nonfree/debian/bin/gencontrol.py",
 line 128, in do_main
self.do_package(packages, makefile, package, vars.copy(), makeflags.copy())
  File 
"/home/diederik/dev/debian/salsa/kernel-team/firmware-nonfree/debian/bin/gencontrol.py",
 line 228, in do_package
f, f_real, version = files_real[f]
 ~~^^^
KeyError: 'brcm/brcmfmac43455-sdio.Raspberry\\'
make: *** [debian/rules:53: debian/control-real] Error 1

The upstream WHENCE file contains these lines:
Link: brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ 4\ 
Model\ B.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt
Link: brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ Compute\ 
Module\ 4.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt

Removing the `\`, but keeping the spaces, resulted in a similar error:

$ debian/rules debian/control-real
./copy-firmware.sh debian/build/install
debian/bin/gencontrol.py /usr/src/linux-support-6.1.0-8
Traceback (most recent call last):
  File 
"/home/diederik/dev/debian/salsa/kernel-team/firmware-nonfree/debian/bin/gencontrol.py",
 line 341, in 
GenControl()()
  File 
"/home/diederik/dev/debian/salsa/kernel-team/firmware-nonfree/debian/bin/gencontrol.py",
 line 94, in __call__
self.do_main(packages, makefile)
  File 
"/home/diederik/dev/debian/salsa/kernel-team/firmware-nonfree/debian/bin/gencontrol.py",
 line 128, in do_main
self.do_package(packages, makefile, package, vars.copy(), makeflags.copy())
  File 
"/home/diederik/dev/debian/salsa/kernel-team/firmware-nonfree/debian/bin/gencontrol.py",
 line 228, in do_package
f, f_real, version = files_real[f]
 ~~^^^
KeyError: 'brcm/brcmfmac43455-sdio.Raspberry'
make: *** [debian/rules:53: debian/control-real] Error 1

So AFAICT this means that firmware files or links with spaces in them
can not be added to the Debian packages.

I'm guessing this was the reason that the non-CM link was added, but
then removed again before the upload (but there's still an entry about
it in `debian/changelog`.
See commits 53779c7b6131a541 and b42c40616208270a.


- -- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZFOIDwAKCRDXblvOeH7b
bkAhAP97KDfuB6CsxAokJnAUCcJvXT4APdYaVYtAjrzoJXYiVgEA8hjbsBy13Yp7
4OfoxKsQnbdFeSv35gQxAauaSvAJdAU=
=11HZ
-END PGP SIGNATURE-



Bug#1035504: canna: [INTL:tr] turkish translation of debconf messages

2023-05-04 Thread Atila KOÇ

Package: canna
Severity: wishlist
Tags: l10n patch

Hello,

Find attached the updated Turkish translation of the canna debconf messages.
It has been submitted for review to the debian-l10n-turkish mailing list.
Please include it in your next upload.

Regards,
Atila KOÇ
--- YASAL UYARI ---

# Turkish debconf translation of canna
# This file is distributed under the same license as the canna package.
# Mert Dirik , 2008.
# Atila KOÇ , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: canna\n"
"Report-Msgid-Bugs-To: ca...@packages.debian.org\n"
"POT-Creation-Date: 2009-05-03 07:53+0200\n"
"PO-Revision-Date: 2023-04-17 21:49+0300\n"
"Last-Translator: Atila KOÇ \n"
"Language-Team: Debian L10n Turkish \n"
"Language: tr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
"X-Generator: Poedit 2.4.2\n"

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Should the Canna server run automatically?"
msgstr "Canna sunucusu otomatikman çalışsın mı?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"This package contains the Canna server and server-related utilities. If you "
"are only interested in these utilities, you can disable the Canna server now."
msgstr ""
"Bu paket Canna sunucusunu ve sunucuyla ilgili araçları içerir. Eğer yalnızca "
"bu araçlarla ilgileniyorsanız, Canna sunucusunu şimdi "
"etkisizleştirebilirsiniz."

#. Type: boolean
#. Description
#: ../templates:3001
msgid "Should the Canna server run in network mode?"
msgstr "Canna sunucusu ağ kipinde mi çalışmalı?"

#. Type: boolean
#. Description
#: ../templates:3001
msgid ""
"By default the Canna server will run without support for network "
"connections, and will only accept connections on UNIX domain sockets, from "
"clients running on the same host."
msgstr ""
"Öntanımlı olarak Canna sunucusu ağ bağlantılarına destek vermeden çalışır ve "
"yalnızca aynı makinede çalışan istemcilerden gelen UNIX etki alanı soketi "
"bağlantılarını kabul eder."

#. Type: boolean
#. Description
#: ../templates:3001
msgid ""
"If you choose this option, network support will be activated, and the Canna "
"server will accept connections on TCP sockets from clients that may be on "
"remote hosts. Some clients (such as egg and yc-el) require this mode even if "
"they run on the local host."
msgstr ""
"Eğer bu seçeneği seçerseniz, ağ desteği etkinleştirilecek ve Canna sunucusu "
"uzak makinelerde çalışan istemcilerden gelen TCP soketi bağlantılarını da "
"kabul edecektir. egg ve yc-el gibi bazı istemciler, aynı makinede çalışsalar "
"bile bu kipi gerektirebilirler."

#. Type: boolean
#. Description
#: ../templates:4001
msgid "Manage /etc/hosts.canna automatically?"
msgstr "/etc/hosts.canna otomatikman yönetilsin mi?"

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"The /etc/hosts.canna file lists hosts allowed to connect to the Canna server."
msgstr ""
"/etc/hosts.canna dosyası Canna sunucusuna bağlanabilecek makineleri listeler."

#. Type: boolean
#. Description
#: ../templates:4001
msgid ""
"You should not accept this option if you prefer managing the file's contents "
"manually."
msgstr "Dosyanın içeriğini elle yönetecekseniz, bu seçeneği seçmemelisiniz."

#. Type: string
#. Description
#: ../templates:5001
msgid "Hosts allowed to connect to this Canna server:"
msgstr "Bu Canna sunucusuna bağlanma izni verilen makineler:"

#. Type: string
#. Description
#: ../templates:5001
msgid ""
"Please enter the names of the hosts allowed to connect to this Canna server, "
"separated by spaces."
msgstr ""
"Lütfen Canna sunucusuna bağlanma izni verilen makinelerin adlarını "
"boşluklarla ayrılmış olarak girin."

#. Type: string
#. Description
#: ../templates:5001
msgid "You can use \"unix\" to allow access via UNIX domain sockets."
msgstr ""
"UNIX etki alanı soketleri üzerinden bağlantıları kabul etmek için 'unix' "
"kullanabilirsiniz."

#. Type: select
#. Description
#: ../libcanna1g.templates:2001
msgid "Canna input style:"
msgstr "Canna girdi biçimi:"

#. Type: select
#. Description
#: ../libcanna1g.templates:2001
msgid ""
"Please choose the default Canna input style:\n"
" verbose: Canna3.5 default style with verbose comments;\n"
" 1.1: old Canna style (ver. 1.1);\n"
" 1.2: old Canna style (ver. 1.2);\n"
" jdaemon: jdaemon style;\n"
" just   : JustSystems ATOK style;\n"
" lan5   : LAN5 style;\n"
" matsu  : Matsu word processor style;\n"
" skk: SKK style;\n"
" tut: TUT-Code style;\n"
" unix   : UNIX style;\n"
" vje: vje style;\n"
" wx2+   : WX2+ style."
msgstr ""
"Öntanımlı Canna girdi biçimini seçin:\n"
" verbose: ayrıntılı açıklamalar içeren Canna3.5 öntanımlı biçimi;\n"
" 1.1: eski Canna biçimi (sürüm 1.1);\n"
" 1.2: eski Canna biçimi (sürüm 1.2);\n"
" jdaemon: jdaemon biçimi;\n"
" just   : JustSystems ATOK biçimi;\n"
" lan5   : LAN5 biçimi;\n"
" matsu  : MATSU kelime işlemcisi biçimi;\n"
" skk: SKK biçimi;\n"
" tut   

Bug#1034790: apt: APT::Get::AutomaticRemove true + --no-remove results in failure to install: Handler silently failed

2023-05-04 Thread Simon McVittie
On Wed, 03 May 2023 at 23:52:54 +0200, David Kalnischkies wrote:
> The problem with those two is that they are contradicting each other and
> giving a preference to one or the other is hard as the code has no idea
> if any, all or none of them were given on the command line, via
> a config file (and which one at that) or via the command line but as
> a conf option / in a conf file…  it all the same from a code pov.

Hmm, I can see that being an issue, but I wasn't actually thinking of
conffile vs. CLI priority here. The reason I say that I would expect
--no-remove to win is that I thought of "don't remove anything, ever"
as being a "stronger" option than "try to remove unused packages".

> It is kinda unlikely that users really have --no-remove in a config file
> as it a rather unpractical option, so that might make sense/be fine.

In my use-case (Valve's steam-launcher package), you're correct to guess
that --no-remove is a command-line option, while
APT::Get::AutomaticRemove=true was coming from (some) users' configuration.

Of course the *correct* way to do this would be to have actual
dependencies, more like src:steam-installer in Debian (which has a
hard dependency on steam-libs and steam-libs-i386 metapackages);
but unfortunately Valve has always documented the way to install
steam-launcher as "download the .deb file and then install it" (with gdebi
or GNOME Software or "apt install ./steam-launcher_*.deb"); so at
the time the .deb is installed, the apt source that would provide its
dependency metapackages is not in place yet, leaving it with no choice
but to try to fix up dependencies via pkexec (or historically sudo)
during first-run after the apt source is in place.

I realise that if Valve was willing to either change their installation
instructions, or bless steam-installer as official, the problem would be
solved; but that's not something that I am able to force, so at the moment
I'm stuck with that constraint.

Given that constraint, we're trying to make steam-launcher do the
least-bad thing, where failing to install dependencies is less bad than
accidentally removing the desktop environment if the dependencies are
uninstallable (perhaps due to multiarch skew or use of other third-party
repositories).

> That said, if you are scared of "important" packages being removed, you
> could just mark them as "Protected: yes" and have apt (and dpkg) ask for
> more force…

For a use-case with third-party apt repositories, I don't have the
opportunity to put Protected: yes on the user's desktop environment
(and nor would I want to - users sometimes genuinely want to uninstall
GNOME and swap it for Plasma, or similar, and third-party packages
shouldn't prevent that).

> Also, you might be able to slightly abuse 'apt upgrade ' after
> all this command does not upgrade , but upgrades the system
> after tagging  for installation (that is the most simple form
> of what the commit I pointed to means with "allowing pkg modifiers for
> the upgrade commands" btw).

At the moment I'm intending to use -oAPT::Get::AutomaticRemove=false on
the command line, because this needs to work with historical versions
of apt, so I'd still need this override even if newer apt versions changed
the priority of these options to match what I had expected.

I need a CLI that is intended to be scriptable, which AIUI means it
should be apt-get rather than apt, and I need to pull in dependencies,
so it would have to be "apt-get --with-new-pkgs upgrade "
or similar. Are there other reasons to prefer this over
"apt-get install "?

(Unfortunately steam-launcher is still aiming to at least semi-support
Ubuntu 16.04, which is apt 1.2, so I can't rely on new features either.)

smcv



Bug#1035503: glewlwyd-common: prompting due to modified conffiles which were not modified by the user: /etc/glewlwyd/config.json

2023-05-04 Thread Andreas Beckmann
Package: glewlwyd-common
Version: 2.7.5-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + glewlwyd

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

>From the attached log (scroll to the bottom...):

  Setting up glewlwyd-common (2.7.5-2) ...
  
  Configuration file '/etc/glewlwyd/config.json'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** config.json (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
glewlwyd-common (--configure):
   end of file on stdin at conffile prompt
  Setting up libgssapi-krb5-2:amd64 (1.20.1-1+b1) ...
  Setting up ucf (3.0043+nmu1) ...
  dpkg: dependency problems prevent configuration of glewlwyd:
   glewlwyd depends on glewlwyd-common; however:
Package glewlwyd-common is not configured yet.
  
  dpkg: error processing package glewlwyd (--configure):
   dependency problems - leaving unconfigured


cheers,

Andreas


glewlwyd_2.7.5-2.log.gz
Description: application/gzip


Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."

2023-05-04 Thread Axel Beckert
Hi Emanuele,

Emanuele Rocca wrote:
> On 2023-05-03 08:16, Axel Beckert wrote:
> > Machine: Thinkpad X13s (ARM)
> 
> Sorry, I've realized only after sending my previous message and having a
> coffee that this is about the X13s. :)

:-)

> The X13s is unfortunately not supported by Linux 6.1 that Bookworm will
> ship with.

Oh, ok. I see.

> Hopefully 6.4 will include all the needed patches.

xnox's image uses 6.2 so far, i.e. also something newer than 6.1.

> > But Dimitri's Ubuntu Installer Live image lunar-desktop-arm64.iso from
> > https://people.canonical.com/~xnox/ubuntu-concept/full/daily-live/current/
> > as of 2023-03-07 20:08 booted fine without these issues.
> > 
> > It would be nice if Dimitri (xnox@d.o, Cc'ed) could tell us which fix
> > has been applied by him (or Ubuntu) to this image so that we can fix
> > this issue also in Debian, maybe even before the release of Bookworm.
> 
> If that image works, then it includes quite a few of out of tree kernel
> patches.

I see. I kinda hoped it would just be some not enabled drivers or bugs
in the .dtb file or so as the D-I RC2 announcement mentioned the X13s
explicitly (admittelly only with flash-kernel having gotten support
for it).

> As per [1] they are unfortunately not going to be applied to
> the Debian kernel, we have to wait for upstream inclusion.

Sure. I intend to run Debian Unstable on it anyway, so I can wait. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#1035502: libclxclient-dev ships uncompilable headers

2023-05-04 Thread Steve Langasek
Package: libclxclient-dev
Version: 3.9.2-1
Severity: minor
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic

Dear maintainers,

As part of an investigation to establish the feasibility of moving 32-bit
archs to 64-bit time_t, I am running an analysis of all header files in the
archive to determine which libraries' ABIs are affected.  This requires the
headers in question to be compilable.

libclxclient-dev ships header files which have includes that are not
satisfied by its dependencies.  For my purposes, I've worked around these
unusable headers by adding quirks to my scripts, but it seems worth
reporting as a bug that headers are being shipped that aren't usable.

Specifically, this package includes clthreads.h without a dependency on
libclthreads-dev.

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


signature.asc
Description: PGP signature


Bug#1016903: closing for real

2023-05-04 Thread Mathieu Malaterre
Version: 12.2.0-8

malat@barriere ~ % apt-cache policy gcc-12
gcc-12:
  Installed: 12.2.0-18
  Candidate: 12.2.0-18
  Version table:
 *** 12.2.0-18 100
  1 https://deb.debian.org/debian experimental/main i386 Packages
100 /var/lib/dpkg/status
 12.2.0-14 500
500 https://deb.debian.org/debian sid/main i386 Packages
malat@barriere ~ % gcc-12 -O2 pr106322.c && ./a.out && echo fixed
fixed

Thanks



Bug#1035501: thunderbird-l10n-si: uninstallable cruft package from src:thunderbird

2023-05-04 Thread Andreas Beckmann
Package: thunderbird-l10n-si,icedove-l10n-si,iceowl-l10n-si,lightning-l10n-si
Version: 1:68.10.0-1~deb9u1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: found -1 1:91.10.0-1~deb9u1
Control: close -1

This cruft package is no longer built by the current version of its
source package, but the obsolete binaries are still lingering around in
the (old)(old)stable/updates repository.

This package is no longer installable since it has versioned
dependencies on no longer available package versions built from its
source package.

This bug is intended for tracking these packages which fail their
piuparts tests.


Andreas



Bug#1035500: libhwloc-dev ships uncompilable headers

2023-05-04 Thread Steve Langasek
Package: libhwloc-dev
Version: 2.9.0-1
Severity: minor
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic

Hi Samuel,

As part of an investigation to establish the feasibility of moving 32-bit
archs to 64-bit time_t, I am running an analysis of all header files in the
archive to determine which libraries' ABIs are affected.  This requires the
headers in question to be compilable.

libhwloc-dev ships header files which have includes that are not satisfied
by its dependencies.  For my purposes, I've worked around these unusable
headers by adding quirks to my scripts, but it seems worth reporting as a
bug that headers are being shipped that aren't usable.

- /usr/include/hwloc/cuda*.h include cuda.h from nvidia-cuda-dev, which a)
  is not depended on, b) is only available on amd64, arm64, and ppc64el.

- /usr/include/hwloc/nvml.h includes nvml.h from libnvidia-ml-dev, same
  as above.

- /usr/include/hwloc/levelzero.h includes level_zero/ze_api.h which does not
  exist in Debian.

- /usr/include/hwloc/opencl.h includes CL/cl.h from opencl-c-headers.

- /usr/include/hwloc/openfabrics-verbs.h includes infiniband/verbs.h from
  libibverbs-dev.

- /usr/include/hwloc/rsmi.h includes rocm_smi/rocm_smi.h which doesn't exist
  in Debian.

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


signature.asc
Description: PGP signature


Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."

2023-05-04 Thread Emanuele Rocca
Hi again,

On 2023-05-03 08:16, Axel Beckert wrote:
> Machine: Thinkpad X13s (ARM)

Sorry, I've realized only after sending my previous message and having a
coffee that this is about the X13s. :)

The X13s is unfortunately not supported by Linux 6.1 that Bookworm will
ship with. Hopefully 6.4 will include all the needed patches.

> But Dimitri's Ubuntu Installer Live image lunar-desktop-arm64.iso from
> https://people.canonical.com/~xnox/ubuntu-concept/full/daily-live/current/
> as of 2023-03-07 20:08 booted fine without these issues.
> 
> It would be nice if Dimitri (xnox@d.o, Cc'ed) could tell us which fix
> has been applied by him (or Ubuntu) to this image so that we can fix
> this issue also in Debian, maybe even before the release of Bookworm.

If that image works, then it includes quite a few of out of tree kernel
patches. As per [1] they are unfortunately not going to be applied to
the Debian kernel, we have to wait for upstream inclusion.

  Emanuele

[1] https://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines



Bug#1035499: crowdsec-custom-bouncer: fails to install with --install-recommends: open /etc/crowdsec/config.yaml: no such file or directory

2023-05-04 Thread Andreas Beckmann
Package: crowdsec-custom-bouncer
Version: 0.0.15-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package crowdsec.
  Preparing to unpack .../4-crowdsec_1.4.6-3+b1_i386.deb ...
  Unpacking crowdsec (1.4.6-3+b1) ...
  Selecting previously unselected package crowdsec-custom-bouncer.
  Preparing to unpack .../5-crowdsec-custom-bouncer_0.0.15-2+b1_i386.deb ...
  Unpacking crowdsec-custom-bouncer (0.0.15-2+b1) ...
  Setting up crowdsec-custom-bouncer (0.0.15-2+b1) ...
  [ESC][31mFATA[ESC][0m[03-05-2023 23:19:26] while reading yaml file: open 
/etc/crowdsec/config.yaml: no such file or directory 
  dpkg: error processing package crowdsec-custom-bouncer (--configure):
   installed crowdsec-custom-bouncer package post-installation script 
subprocess returned error exit status 1
  Setting up libsqlite3-0:i386 (3.40.1-2) ...
  Setting up libssl3:i386 (3.0.8-1) ...
  Setting up openssl (3.0.8-1) ...
  Setting up ca-certificates (20230311) ...
  Updating certificates in /etc/ssl/certs...
  140 added, 0 removed; done.
  Setting up crowdsec (1.4.6-3+b1) ...
  I: Registering to LAPI (/etc/crowdsec/local_api_credentials.yaml)
  W: Missing /etc/machine-id, initializing
  I: Registering to CAPI (/etc/crowdsec/online_api_credentials.yaml)
  I: Setting up offline hub (see README.Debian)
  I: Enabling upstream-recommended items, first installation (via symlinks from 
/etc/crowdsec)
  I: Enabling WAL for SQLite [fstype=] (see README.Debian)
  Processing triggers for libc-bin (2.36-9) ...
  Processing triggers for ca-certificates (20230311) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   crowdsec-custom-bouncer

Note that crowdsec gets configured after crowdsec-custom-bouncer in
this case because there is only a Recommends.


cheers,

Andreas


crowdsec-custom-bouncer_0.0.15-2+b1.log.gz
Description: application/gzip


Bug#1035498: golang-github-gin-gonic-gin: CVE-2023-26125

2023-05-04 Thread Salvatore Bonaccorso
Source: golang-github-gin-gonic-gin
Version: 1.8.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-github-gin-gonic-gin.

CVE-2023-26125[0]:
| Versions of the package github.com/gin-gonic/gin before 1.9.0 are
| vulnerable to Improper Input Validation by allowing an attacker to use
| a specially crafted request via the X-Forwarded-Prefix header,
| potentially leading to cache poisoning. **Note:** Although this issue
| does not pose a significant threat on its own it can serve as an input
| vector for other more impactful vulnerabilities. However, successful
| exploitation may depend on the server configuration and whether the
| header is used in the application logic.


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-2023-26125
https://www.cve.org/CVERecord?id=CVE-2023-26125
[1] https://github.com/gin-gonic/gin/pull/3500
[2] https://github.com/gin-gonic/gin/pull/3503
[3] 
https://github.com/gin-gonic/gin/commit/81ac7d55a09e34013225db0aeac6e70c1ae68928

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#1035497: ufw: Deny forwarding but still forward ping requests

2023-05-04 Thread Marek Küthe
Package: ufw
Version: 0.36-7.1
Severity: normal

Dear Maintainer,

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

Hello,

I use my server as a kind of VPN server, but I only want my client to
use a specific IP address. So I used the following rules: ```
ufw route deny out on client09 from any to any comment 'vpn client09'
ufw route deny in on client09 from any to any comment 'vpn client09'
ufw route prepend allow in on client09 from 172.22.149.116 comment 'vpn
client09' ufw route prepend allow in on client09 from
fd04:234e:fc31:e::9 comment 'vpn client09' ```

However, I can send ping requests without 'ufw route prepend allow' and
get a response, whereas the rule clearly says Deny. Apparently ping
requests are always allowed through.

As a workaround I can add the following manually:
```
-A ufw-before-forward -i client09 -p icmp -s 172.22.149.116 -j ACCEPT
-A ufw-before-forward -i client09 -p icmp -j DROP

-A ufw6-before-forward -i client09 -p ipv6-icmp -s fd92:58b6:2b2:e::9
-j ACCEPT -A ufw6-before-forward -i client09 -p ipv6-icmp -j DROP
```

I have set `DEFAULT_FORWARD_POLICY="ACCEPT"`.

However, I think (and hope) that this behavior is not intentional.
Hence this bug report. If I forbid a forwarding it has a good reason
and then I also want this to be forbidden.

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


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

Kernel: Linux 5.10.0-22-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot
set LC_ALL to default locale: No such file or directory 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 ufw depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  iptables   1.8.7-1
ii  lsb-base   11.1.0
ii  python33.9.2-3
ii  ucf3.0043

ufw recommends no packages.

Versions of packages ufw suggests:
ii  rsyslog  8.2102.0-2+deb11u1

-- debconf information excluded

-- debsums errors found:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "de_DE.UTF-8",
LC_MONETARY = "de_DE.UTF-8",
LC_ADDRESS = "de_DE.UTF-8",
LC_TELEPHONE = "de_DE.UTF-8",
LC_NAME = "de_DE.UTF-8",
LC_MEASUREMENT = "de_DE.UTF-8",
LC_IDENTIFICATION = "de_DE.UTF-8",
LC_NUMERIC = "de_DE.UTF-8",
LC_PAPER = "de_DE.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").


pgpwQxmw08GBe.pgp
Description: OpenPGP digital signature


Bug#1035495: tcpcryptd: fails to purge - command deluser in postrm not found

2023-05-04 Thread Andreas Beckmann
Package: tcpcryptd
Version: 0.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to purge due
to a command not found. According to policy 7.2 you cannot rely on the
depends being available during purge, only the essential packages are
available for sure.

The fix should be easy: your package is using adduser or deluser from
the adduser package, which is only priority important. Using useradd or
userdel from the passwd package (priority required) should fix this
problem.

There is ongoing discussion how to handle system users on package
removal, see https://bugs.debian.org/621833
Consensus seems to be not to remove system users (to avoid reusing UIDs
which could grant access to the wrong files) but to "lock" them (where
"locking"/"unlocking" is not yet precisely defined). Until that has
been decided it should be sufficient to have the postrm script ignore
any errors from deluser:
  deluser ... || true

>From the attached log (scroll to the bottom...):

0m17.5s DEBUG: Starting command: ['chroot', 
'/srv/piuparts.debian.org/tmp/tmp8wigy40m', 'dpkg', '--purge', 'tcpcryptd']
0m17.5s DUMP: 
  (Reading database ... 8066 files and directories currently installed.)
  Purging configuration files for tcpcryptd (0.5-1+b3) ...
  /var/lib/dpkg/info/tcpcryptd.postrm: 9: deluser: not found
  dpkg: error processing package tcpcryptd (--purge):
   installed tcpcryptd package post-removal script subprocess returned error 
exit status 127
  Errors were encountered while processing:
   tcpcryptd
0m17.5s ERROR: Command failed (status=1): ['chroot', 
'/srv/piuparts.debian.org/tmp/tmp8wigy40m', 'dpkg', '--purge', 'tcpcryptd']


cheers,

Andreas


tcpcryptd_0.5-1+b3.log.gz
Description: application/gzip


Bug#1035483: debsums: false positives on removed conffiles retaining a remove-on-upgrade entry in Conffiles

2023-05-04 Thread Andreas Beckmann

On 04/05/2023 10.02, Axel Beckert wrote:

Actually its even more embarrassing: A patch for that is already in
Git, albeit a bit less elegant and maybe less performant:


But perhaps more correct. This should probably not be limited to 
--ignore-obsolete.


Andreas



Bug#1035494: moonshot-trust-router: fails to purge - command deluser in postrm not found

2023-05-04 Thread Andreas Beckmann
Package: moonshot-trust-router
Version: 3.5.4+1+nmu1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to purge due
to a command not found. According to policy 7.2 you cannot rely on the
depends being available during purge, only the essential packages are
available for sure.

The fix should be easy: your package is using adduser or deluser from
the adduser package, which is only priority important. Using useradd or
userdel from the passwd package (priority required) should fix this
problem.

There is ongoing discussion how to handle system users on package
removal, see https://bugs.debian.org/621833
Consensus seems to be not to remove system users (to avoid reusing UIDs
which could grant access to the wrong files) but to "lock" them (where
"locking"/"unlocking" is not yet precisely defined). Until that has
been decided it should be sufficient to have the postrm script ignore
any errors from deluser:
  deluser ... || true

>From the attached log (scroll to the bottom...):

0m23.9s DEBUG: Starting command: ['chroot', 
'/srv/piuparts.debian.org/tmp/tmp31k0hsgy', 'dpkg', '--purge', 
'moonshot-trust-router']
0m23.9s DUMP: 
  (Reading database ... 8067 files and directories currently installed.)
  Purging configuration files for moonshot-trust-router (3.5.4+1+nmu1+b1) ...
  Removing /var/lib/trust_router/
  Removing trustrouter user from system
  /var/lib/dpkg/info/moonshot-trust-router.postrm: 11: deluser: not found
  dpkg: error processing package moonshot-trust-router (--purge):
   installed moonshot-trust-router package post-removal script subprocess 
returned error exit status 127
  Errors were encountered while processing:
   moonshot-trust-router
0m23.9s ERROR: Command failed (status=1): ['chroot', 
'/srv/piuparts.debian.org/tmp/tmp31k0hsgy', 'dpkg', '--purge', 
'moonshot-trust-router']


cheers,

Andreas


moonshot-trust-router_3.5.4+1+nmu1+b1.log.gz
Description: application/gzip


Bug#1035493: python3-spyder-memory-profiler: incompatible with spyder 5

2023-05-04 Thread Andreas Beckmann
Package: python3-spyder-memory-profiler
Version: 0.2.1-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

  The following packages have unmet dependencies:
   python3-spyder : Conflicts: python3-spyder-memory-profiler (<= 0.2.1-1) but 
0.2.1-1 is to be installed

My guess is that the conflict was added with the update to
python3-spyder 5.x.


Cheers,

Andreas



Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."

2023-05-04 Thread Emanuele Rocca
Hi Axel,

On 2023-05-03 08:16, Axel Beckert wrote:
> After choosing either "expert install" (first and prefered try) or
> "graphical expert install" (second try and second choice) I saw these
> three lines and then nothing more happened:
> 
>   EFI stub: Booting Linux Kernel...
>   EFI stub: Using DTB from configuration table
>   EFI stub: Exiting boot services...
> 
> Waited 10 minutes at least, i.e. left it alone, did something else and
> came back later. Even adding the "debug" kernel parameter didn't bring
> up any more details on what's happening.

Perhaps we can get some more output by adding 'earlycon=efifb
keep_bootcon' after 'debug' to the kernel CLI.

Additionally, please try adding 'set debug=linux' to grub's
configuration as well -- after the setparams directive for example.

See attached screenshot.

Thanks,
  Emanuele


  1   2   >