Bug#1069098: emboss: all executables segfault on s390x

[Andreas Tille]

Hi Andrius,

I'd recommend following the procedure you supposed in
   https://lists.debian.org/debian-med/2024/04/msg00034.html

Someone needs to file removal requests for s390x for the
rdepends from emboss, thought.

Kind regards
   Andreas.

-- 
https://fam-tille.de

Bug#1069140: easytag: Support wav files for tagging like kid3 please

[Huey Chen]

Package: easytag
Version: 2.4.3-5+b2
Severity: wishlist
X-Debbugs-Cc: hueyche...@outlook.com

Dear Maintainer,
Wav files are not supported, and many (80%) of my audio files are .wav files. I 
want to tag them for their original source, but I can do that with only kid3 
and audacity.  
I use EasyTAG for its thumbnail features, but I am forced to use another 
application for .wav files.  
So, will you add support for .wav files soon? Thanks.

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

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

Versions of packages easytag depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  libc62.37-17
ii  libflac12t64 1.4.3+ds-2.1
ii  libgcc-s114-20240330-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b3
ii  libglib2.0-0t64  2.78.4-6
ii  libgtk-3-0t643.24.41-4
ii  libid3-3.8.3v5   3.8.3-18+b1
ii  libid3tag0   0.15.1b-14
ii  libogg0  1.3.5-3
ii  libopus0 1.4-1+b1
ii  libopusfile0 0.12-4+b2
ii  libspeex11.2.1-2+b1
ii  libstdc++6   14-20240330-1
ii  libtag1v51.13.1-1+b1
ii  libvorbis0a  1.3.7-2
ii  libvorbisfile3   1.3.7-2
ii  libwavpack1  5.7.0-1

Versions of packages easytag recommends:
ii  gnome-icon-theme  3.12.0-5
ii  gvfs  1.54.0-1+b1
ii  yelp  42.2-1+b2

easytag suggests no packages.

-- no debconf information

Bug#1069139: developers-reference: out-of-date section "Make transition packages deborphan compliant"

[Vincent Lefevre]

Package: developers-reference
Version: 13.5
Severity: normal

Now that the deborphan package has been removed from unstable,
the section "Make transition packages deborphan compliant" in
"Best Packaging Practices" is out of date and should be updated.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065312
where "apt-mark auto ..." (for autoremove) is suggested as a
replacement. But with it, putting transition packages to oldlibs
is even more necessary.

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

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

developers-reference depends on no packages.

Versions of packages developers-reference recommends:
ii  debian-policy4.7.0.0
ii  libjs-sphinxdoc  7.2.6-6
ii  sensible-utils   0.0.22

Versions of packages developers-reference suggests:
pn  doc-base   
ii  elinks [www-browser]   0.16.1.1-4.1+b2
ii  firefox [www-browser]  124.0.1-1
ii  firefox-esr [www-browser]  115.9.1esr-1
ii  links [www-browser]2.29-1+b3
ii  links2 [www-browser]   2.29-1+b3
ii  lynx [www-browser] 2.9.0rel.0-2+b1
ii  w3m [www-browser]  0.5.3+git20230121-2+b3

-- no debconf information

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

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

[Vincent Lefevre]

On 2024-04-17 01:39:48 +0200, Vincent Lefevre wrote:
> On 2024-03-11 15:18:44 +0100, Chris Hofstaedtler wrote:
> > Thus, a good approximation of the default deborphan functionality
> > (no additional options passed) is:
> > 
> > $ apt-mark auto '~i !~M 
> > (~slibs|~soldlibs|~slibdevel|~sintrospection|~sdebug)'
> > possibly followed by
> 
> No, to mimic deborphan, you should exclude ~slibdevel and ~sdebug
> from this list. So
> 
>   apt-mark auto '~i !~M (~slibs|~soldlibs|~sintrospection)'
[...]

I forgot: deborphan also had other rules. Something useful is that
it could detect dummy / transitional packages. It seems that apt
patterns cannot work on the package description.

https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html

recommends "Also, it is recommended to adjust its section to oldlibs
and its priority to optional in order to ease deborphan's job." but
this is not always done (this was not absolutely necessary for
deborphan, which could also look at the package descrption, but
for apt-mark, this is now a must).

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

Bug#1069138: sbsigntool: FTBFS: add support for loongarch

[zhangdandan]

Source: sbsigntool
Version: 0.9.4-3.1
Severity: wishlist
Tags: ftbfs patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling sbsigntool package failed on my local loong64 rootfs environment.
I have added support for loongarch in sbsigntool package.
In addition, we should add build support for loongarch.

The sbsigntool was built successfully in my local ENV.
Please consider the patch I attached.
Your opinions are welcome.

Thanks,
Dandan Zhang

diff -Nru sbsigntool-0.9.4/debian/control sbsigntool-0.9.4/debian/control
--- sbsigntool-0.9.4/debian/control 2021-09-14 06:39:01.0 +
+++ sbsigntool-0.9.4/debian/control 2022-06-04 11:37:27.0 +
@@ -17,7 +17,7 @@
 Standards-Version: 4.5.1
 
 Package: sbsigntool
-Architecture: any-amd64 any-i386 arm64 armhf any-riscv64
+Architecture: any-amd64 any-i386 arm64 armhf any-riscv64 any-loong64
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Multi-Arch: foreign
 Description: Tools to manipulate signatures on UEFI binaries and drivers
diff -Nru 
sbsigntool-0.9.4/debian/patches/add-support-for-LoongArch-images.patch 
sbsigntool-0.9.4/debian/patches/add-support-for-LoongArch-images.patch
--- sbsigntool-0.9.4/debian/patches/add-support-for-LoongArch-images.patch  
1970-01-01 00:00:00.0 +
+++ sbsigntool-0.9.4/debian/patches/add-support-for-LoongArch-images.patch  
2022-06-04 11:37:27.0 +
@@ -0,0 +1,36 @@
+Description: Add support for LoongArch images
+ .
+ sbsigntool (0.9.4-3.1+loong64) unreleased; urgency=medium
+ .
+   * Add support for LoongArch images.
+Author: Dandan Zhang 
+---
+Last-Update: 2024-04-17
+
+--- sbsigntool-0.9.4.orig/src/coff/pe.h
 sbsigntool-0.9.4/src/coff/pe.h
+@@ -133,6 +133,8 @@
+ #define IMAGE_FILE_MACHINE_EBC   0x0ebc
+ #define IMAGE_FILE_MACHINE_I386  0x014c
+ #define IMAGE_FILE_MACHINE_IA64  0x0200
++#define IMAGE_FILE_MACHINE_LOONGARCH32   0x6232
++#define IMAGE_FILE_MACHINE_LOONGARCH64   0x6264
+ #define IMAGE_FILE_MACHINE_M32R  0x9041
+ #define IMAGE_FILE_MACHINE_M68K  0x0268
+ #define IMAGE_FILE_MACHINE_MIPS160x0266
+--- sbsigntool-0.9.4.orig/src/image.c
 sbsigntool-0.9.4/src/image.c
+@@ -240,11 +240,13 @@ static int image_pecoff_parse(struct ima
+   case IMAGE_FILE_MACHINE_AMD64:
+   case IMAGE_FILE_MACHINE_AARCH64:
+   case IMAGE_FILE_MACHINE_RISCV64:
++  case IMAGE_FILE_MACHINE_LOONGARCH64:
+   rc = image_pecoff_parse_64(image);
+   break;
+   case IMAGE_FILE_MACHINE_I386:
+   case IMAGE_FILE_MACHINE_THUMB:
+   case IMAGE_FILE_MACHINE_RISCV32:
++  case IMAGE_FILE_MACHINE_LOONGARCH32:
+   rc = image_pecoff_parse_32(image);
+   break;
+   default:
diff -Nru sbsigntool-0.9.4/debian/patches/series 
sbsigntool-0.9.4/debian/patches/series
--- sbsigntool-0.9.4/debian/patches/series  2022-06-04 11:36:09.0 
+
+++ sbsigntool-0.9.4/debian/patches/series  2022-06-04 11:37:27.0 
+
@@ -2,3 +2,4 @@
 fix-efi-arch-detection.patch
 0001-sbsigntool-add-support-for-RISC-V-images.patch
 OpenSSL3.patch
+add-support-for-LoongArch-images.patch

Bug#1056939: auctex: auctex is incompatible with use-package/elpa

[Xiyue Deng]

I have made a new MR[1] using a separate branch so that I can continue
to experiment on master.  It also changes how *-pkg.el is generated.
PTAL.

-- 
Xiyue Deng

[1] https://salsa.debian.org/salve/auctex/-/merge_requests/4

Bug#1069137: auctex: New upstream version 13.3

[Xiyue Deng]

Package: auctex
Severity: wishlist
X-Debbugs-Cc: none, Xiyue Deng 

Hi,

A new upstream version 13.3 is available[1].  It is also a little
confusing in that the auctex version on ELPA is already at 14.0.4[2].
It may worth figuring out which is the authentic upstream.

I have made 2 pull requests based on the 13.3 release, one is for the
upstream branch[3] and the other is for the master branch[4].  As noted
in [3], a tag `upstream/13.3' should be created on upstream branch for
`git deborig' to work.

[1] https://www.gnu.org/software/auctex/
[2] https://elpa.gnu.org/packages/auctex.html
[3] https://salsa.debian.org/salve/auctex/-/merge_requests/5
[4] https://salsa.debian.org/salve/auctex/-/merge_requests/6

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

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

Bug#1069136: wabt: Typo in repacksuffix

[Adrian Bunk]

Source: wabt
Version: 1.0.34+dsfg2+~cs1.0.32-1
Severity: normal

https://sources.debian.org/src/wabt/1.0.34%2Bdsfg2%2B~cs1.0.32-1/debian/watch/#L2
  
opts=filenamemangle=s/.+\/@ANY_VERSION@(@ARCHIVE_EXT@)$/@PACKAGE@-$1$2/,repacksuffix=+dsfg
 \


It's dfsg, not dsfg.

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

[Vincent Lefevre]

On 2024-03-11 15:18:44 +0100, Chris Hofstaedtler wrote:
> Thus, a good approximation of the default deborphan functionality
> (no additional options passed) is:
> 
> $ apt-mark auto '~i !~M (~slibs|~soldlibs|~slibdevel|~sintrospection|~sdebug)'
> possibly followed by

No, to mimic deborphan, you should exclude ~slibdevel and ~sdebug
from this list. So

  apt-mark auto '~i !~M (~slibs|~soldlibs|~sintrospection)'

Let's recall the deborphan(1) man page:

  The default operation is to search within the libs, oldlibs and
  ^^^
  introspection sections to hunt down unused libraries.
  ^

Indeed, -dev packages are necessary to do development work on
non-Debian software (or just build such software); so, if such
packages have been manually installed, they must probably remain
installed and not be marked as auto.

Similarly, -dbgsym packages are typically installed by the user for
debugging purpose. However, such packages should be removed when
the associated library package would be removed if the -dbgsym
package were not there, but the above pattern will not catch that.
This was already an issue with deborphan:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742196

On 2024-03-17 15:54:27 +0200, Martin-Éric Racine wrote:
> Another issue I've run into to try and replace deborphan with some
> apt-mark recipe: apt-mark's regex syntax is not documented. The man
> page merely lists the commands and options available.

I suspect that this is apt-patterns(7). The apt-mark(8) man page just
gives a reference to apt-get(8), which mentions apt-patterns(7), but
I think that a more direct reference should be given.

> For instance, I have no idea how you came up with the above regex
> recipe, or how I would tell apt-mark to never mark as "auto" anything
> with a priority important or higher.

I don't think that you should care of the priority. This was needed
for deborphan in order to ignore the "required" priority, but AFAIK,
apt will never propose to remove such packages.

The only thing that is missing with patterns is to be able to specify
a package list from a file, in order to mimic deborphan's keep-list:
/var/lib/deborphan/keep

But one could still write a simple wrapper to add "!?name(package_name)"
to the pattern for each package_name found in a keep-list file. It could
even be possible to provide regular expressions, which deborphan did not
support. For instance you could have a pattern_file file with

  ~i !~M (~slibs|~soldlibs|~sintrospection) !~n(pkg1|pkg2|pkg3)

and use

  apt-mark auto "$(cat /path/to/pattern_file)"

Before doing that, you could check with

  apt-mark showmanual "$(cat /path/to/pattern_file)"

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

Bug#1064559: Forwarded upstream (+ same ftbfs in Ubuntu)

[Bryce Harrington]

Ubuntu is seeing the same failures after its own rebuilds of the package
in Ubuntu noble, also on ppc64el only.  I investigated if it was a known
issue in pdbq or valgrind but did not find convincing matches.  I'm also
not certain if this is a single issue, or multiple.  There are also some
"Invalid opcode" errors from valgrind which I wonder might be a separate
problem.  In Ubuntu I'm going to test if disabling TEST5 is sufficient.

Ubuntu bug:  https://bugs.launchpad.net/ubuntu/+source/pmdk/+bug/2061913

Upstream bug:  https://github.com/pmem/pmdk/issues/5635

Bug#1067054: Debian 12 - Copy files on USB 3

[pham...@bluewin.ch]

Extra information :
It is stable when you initialize the disk in MBR/MS-DOS format, but only with a 
USB A to USB C cable, if you use a USB c to USB-C cable the problems persist.

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[James Addison]

On Tue, 16 Apr 2024 at 22:47, James Addison  wrote:>
> Thanks Holger,
>
> On Mon, 15 Apr 2024 at 20:43, Holger Wansing  wrote:
> >
> > Hi,
> >
> > James Addison  wrote (Sun, 14 Apr 2024 23:52:03 +0100):
> > > From some testing of these: the search results have a problem that they
> > > hyperlink to a language-less .html URL, meaning that clicking a result 
> > > link in
> > > the DE-language search results takes the user to a EN-language page.
> >
> > Yes, good catch.
> > However it's even worse: if you view a German page and use the Search 
> > function,
> > the search index for English is used.
>
> Wait, I'm confused.  Not on your site, though.  There you have the 
> per-language
> search indices.
>
> And in fact, when deployed to the debian.org website, requested-language 
> search
> (mapping of the browser language to an appropriate searchindex.*.js
> file) could be
> (and is already) a better user experience.  If you hypothetically send
> me a hyperlink
> to a policy section auf Deutsch, that's fine, but when I search for
> 'configuration'
> after reading that, I might want my browser settings to have been respected, 
> in
> terms of what is searched.
>
> > I have tried to deal with this by some adaptions in the cronjob - see the
> > first two additions in my patch: change all links to search.html into
> > search.§lang.html, and rename the language-specific searchindex files into
> > searchindex.$lang.js.
> > However, that does not seem to be enough.
>
> When you say it is not enough: could I check what you mean by that?
>
> > > The _other_ hyperlinks in the static content are replaced as part of the
> > > cronjob[1] - but that doesn't work for items in the searchindex.js file.
> >
> > Why is that a problem at all (maybe you know this already):
> > since we use content negotiation at Debian website (so the pages are
> > delivered in the correct language according to user's browser setting), we
> > change the directory structure away from the default how it's build by 
> > Sphinx:
> > after Sphinx' make there are separate directories for every language,
> > and they contain everything for that language, including the searchindex.js
> > file. And in that structure it works fine.
> > On Debian website we put everything in one directory, adding the language
> > code into the filename in front of the .html extension.
> > While this works fine for static content, it does not for the search
> > function here.
>
> I think this is a reasonable solution; serving the content from a
> single directory
> is simple and logical because the permissions and content should be the same;
> the latter only differs as a result of locale and therefore translation.
>
> > > Fortunately I think there might be a better way to do this.  Sphinx 
> > > itself has
> > > an HTML builder option 'html_file_suffix' and I think we could use that 
> > > instead
> > > to define the filenames.  That option is respected by the search 
> > > JavaScript
> > > using a template variable[3] in the documentation_options.js file.
> > >
> > > We should be careful of other side-effects if making that change, but it
> > > would remove a deployment transformation step on the static content, and I
> > > think that's beneficial.
> >
> > I don't understand how that could affect our search function problem,
> > but I could give it a try.
>
> The main change that it would introduce is that the dynamic search results 
> that
> appear in the search results (as gathered by the JavaScript) have
> hyperlinks that
> include the build-time suffix in the filename.  So in the example
> above, you have
> linked me to a German-language dokumentation page, and when I search from
> that page, I find (based on a DE search index) and am linked to (based on DE
> file suffixes) Deutsch results; foo.de.html instead of foo.html for example.
>
> I'm in two minds about this: if my browser settings say that my locale is 
> en-150
> and I land on a de-DE page, what language should search be performed in, and
> what language should the results link to?
>
> An answer that I find straightforward is that if the page is de-DE -- which 
> your
> hypothetical link to me was -- then because everything on that page _should_
> (with sufficient translation availability) be in German, then I would expect 
> to
> search and be linked to pages accordingly.  If you'd linked to a language-less
> URL, then that would (a) have been thoughtful if you suspected that I did not
> comprehend Deutsch, and (b) also be provided in my default locale, with search
> and results taking place accordingly, and without any specific locale in the
> result hyperlinks (because the server will select a resource to serve).
>
> Note also: there does _not_ appear to be an equivalent to the 
> 'html_file_suffix'
> config setting to adjust the search index filename.
>
> Regards,
> James

I'm don't think that I communicated clearly, which means that I should have
taken more time before adding a reply; I'd also like to 

Bug#1069133:

[Forest]

Note that this is a headless system, so there is no other way to display a
prompt or enter the passphrase.

Just in case this was merely a display problem, I tried entering the
passphrase at the serial console despite the missing prompt. It didn't work.

Bug#1069135: org-bullets: please consider switching to a more up-to-date upstream

[Nicholas D Steeves]

Source: org-bullets
Version: 0.2.4-3
Severity: normal

Hi,

I noticed some deprecation warnings in org-bullets' native-compilation log, so 
searched for an upstream fix.  What I found was that our current upstream 
source is a decade old:

  https://github.com/sabof/org-bullets

and that MELPA provides their users with a package from this fork, which has 
activity from four years ago:

  https://github.com/integral-dw/org-bullets

It looks like integral-dw's fork might now the defacto upstream, because 
sabof's project looks dead.  Maybe a PR/MR for some of those compilation 
warnings could be a useful way to test for a living and responsive upstream?

Regards,
Nicholas

Bug#1069132: gm-assistant: Openclipart public domain dedication is misrepresented as CC0

[Bastian Germann]

I am uploading a NMU to fix this. The debdiff is included.diff -Nru gm-assistant-1.2.4/debian/changelog 
gm-assistant-1.2.4/debian/changelog
--- gm-assistant-1.2.4/debian/changelog 2022-03-02 19:42:26.0 +
+++ gm-assistant-1.2.4/debian/changelog 2024-04-16 21:59:05.0 +
@@ -1,3 +1,10 @@
+gm-assistant (1.2.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Correct CC public domain dedication (Closes: #1069132)
+
+ -- Bastian Germann   Tue, 16 Apr 2024 21:59:05 +
+
 gm-assistant (1.2.4-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru gm-assistant-1.2.4/debian/copyright 
gm-assistant-1.2.4/debian/copyright
--- gm-assistant-1.2.4/debian/copyright 2022-03-02 19:42:26.0 +
+++ gm-assistant-1.2.4/debian/copyright 2024-04-16 21:53:53.0 +
@@ -15,13 +15,38 @@
 
 Files: data/images/*
 Copyright: None
-License: CC0-1.0
 Comment: Found on http://openclipart.org
+License: CC-PDDC
+ The person or persons who have associated work with this document (the
+ "Dedicator" or "Certifier") hereby either (a) certifies that, to the best of
+ his knowledge, the work of authorship identified is in the public domain of 
the
+ country from which the work is published, or (b) hereby dedicates whatever
+ copyright the dedicators holds in the work of authorship identified below (the
+ "Work") to the public domain. A certifier, moreover, dedicates any copyright
+ interest he may have in the associated work, and for these purposes, is
+ described as a "dedicator" below.
+ .
+ A certifier has taken reasonable steps to verify the copyright status of this
+ work. Certifier recognizes that his good faith efforts may not shield him from
+ liability if in fact the work certified is not in the public domain.
+ .
+ Dedicator makes this dedication for the benefit of the public at large and to
+ the detriment of the Dedicator's heirs and successors. Dedicator intends this
+ dedication to be an overt act of relinquishment in perpetuity of all present
+ and future rights under copyright law, whether vested or contingent, in the
+ Work. Dedicator understands that such relinquishment of all rights includes 
the
+ relinquishment of all rights to enforce (by lawsuit or otherwise) those
+ copyrights in the Work.
+ .
+ Dedicator recognizes that, once placed in the public domain, the Work may be
+ freely reproduced, distributed, transmitted, used, modified, built upon, or
+ otherwise exploited by anyone for any purpose, commercial or non-commercial,
+ and in any way, including by methods that have not yet been invented or
+ conceived.
 
-Files: data/images/empty.svg
-Copyright: None
+Files: fr.free.gmassistant.metainfo.xml.in
+Copyright: Vincent Prat & Simon Nicolas
 License: CC0-1.0
-Comment: Created by Vincent Prat
 
 Files: data/images/GMA.svg
 Copyright: 2011 Vincent Prat

Bug#1069134: libsundials-dev: Wrong path for klu.h

[Christophe TROESTLER]

Package: libsundials-dev
Version: 6.4.1+dfsg1-3+b3
Severity: normal
X-Debbugs-Cc: none, Christophe Troestler 

Dear Maintainer,

When activating the KLU feature of sundials, the file

/usr/include/sunlinsol/sunlinsol_klu.h

is read.  On line 34, there is

#include 

but, even with suitesparse installed, that file is not found.  It must be 
changed into

#include 

Best regards,
Christophe


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

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

Versions of packages libsundials-dev depends on:
ii  cmake  3.28.3-1
ii  gfortran   4:13.2.0-7
ii  libhypre-dev   2.28.0-8
ii  libsundials-arkode56.4.1+dfsg1-3+b3
ii  libsundials-cvode6 6.4.1+dfsg1-3+b3
ii  libsundials-cvodes66.4.1+dfsg1-3+b3
ii  libsundials-ida6   6.4.1+dfsg1-3+b3
ii  libsundials-idas5  6.4.1+dfsg1-3+b3
ii  libsundials-kinsol66.4.1+dfsg1-3+b3
ii  libsundials-nvecparallel-hypre66.4.1+dfsg1-3+b3
ii  libsundials-nvecparallel-mpi6  6.4.1+dfsg1-3+b3
ii  libsundials-nvecparallel-openmp6   6.4.1+dfsg1-3+b3
ii  libsundials-nvecparallel-petsc66.4.1+dfsg1-3+b3
ii  libsundials-nvecparallel-pthread6  6.4.1+dfsg1-3+b3
ii  libsundials-nvecserial66.4.1+dfsg1-3+b3
ii  libsundials-sunlinsol3 6.4.1+dfsg1-3+b3
ii  libsundials-sunmatrix4 6.4.1+dfsg1-3+b3
ii  mpi-default-dev1.15
ii  petsc-dev  3.19.6+dfsg1-2
ii  pkg-config 1.8.1-1+b2
ii  pkgconf [pkg-config]   1.8.1-1+b2

libsundials-dev recommends no packages.

libsundials-dev suggests no packages.

-- no debconf information

Bug#1069133: linux-image-6.6.15-arm64: luks unlock passphrase prompt is not offered on serial console

[Forest]

Package: src:linux
Version: 6.6.15-2
Severity: normal
X-Debbugs-Cc: fores...@nom.one

Dear Maintainer,

When booting with an encrypted root filesystem, the LUKS unlock
passphrase prompt normally appears on the serial console shortly after
the first device-mapper messages. It looks like this:

  Please unlock disk devname_crypt:

After upgrading from kernel 6.1.0-20 (bookworm) to 6.6.15-2 (testing), the
passphrase prompt never appears.

I was only able to continue the boot process because this system happens
to have network access and dropbear-initramfs, for remote unlocking via
ssh.  Were that not the case, it seems the system would be unbootable
with this kernel.

Kernel 6.7.9-2 (unstable) does not have this problem.


-- Package-specific info:
** Version:
Linux version 6.6.15-arm64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.2.0-13) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP Debian 
6.6.15-2 (2024-02-04)

** Command line:
root=/dev/mapper/devname_crypt net.ifnames=0

** Tainted: C (1024)
 * staging driver was loaded

** Kernel log:
[  149.090747] systemd[1]: Started systemd-journald.service - Journal Service.
[  149.254649] systemd-journald[1729]: Received client request to flush runtime 
journal.
[  150.667782] cpu cpu0: EM: created perf domain
[  150.692323] cpu cpu4: EM: OPP:408000 is inefficient
[  150.692622] cpu cpu4: EM: created perf domain
[  150.729385]  cs_system_cfg: CoreSight Configuration manager initialised
[  150.815867] sd 3:0:0:0: Attached scsi generic sg0 type 0
[  150.846507] mc: Linux media interface: v0.10
[  150.854523] coresight-cpu-debug fe43.debug: Coresight debug-CPU0 
initialized
[  150.855314] coresight-cpu-debug fe432000.debug: Coresight debug-CPU1 
initialized
[  150.856041] coresight-cpu-debug fe434000.debug: Coresight debug-CPU2 
initialized
[  150.856798] coresight-cpu-debug fe436000.debug: Coresight debug-CPU3 
initialized
[  150.857544] coresight-cpu-debug fe61.debug: Coresight debug-CPU4 
initialized
[  150.858287] coresight-cpu-debug fe71.debug: Coresight debug-CPU5 
initialized
[  150.869439] spi-nor spi0.0: gd25q128 (16384 Kbytes)
[  150.942070] dw_wdt ff848000.watchdog: No valid TOPs array specified
[  150.971530] Registered IR keymap rc-empty
[  150.972060] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0
[  150.985430] rc rc0: lirc_dev: driver gpio_ir_recv registered at minor = 0, 
raw IR receiver, no transmitter
[  151.005373] input: gpio_ir_recv as 
/devices/platform/ir-receiver/rc/rc0/input1
[  151.008902] Registered IR keymap rc-cec
[  151.009376] rc rc1: dw_hdmi as /devices/platform/ff94.hdmi/rc/rc1
[  151.010046] input: dw_hdmi as /devices/platform/ff94.hdmi/rc/rc1/input2
[  151.031943] rk3288-crypto ff8b.crypto: will run requests pump with 
realtime priority
[  151.032761] rk3288-crypto ff8b.crypto: Register ecb(aes) as ecb-aes-rk
[  151.054216] rk3288-crypto ff8b.crypto: Register cbc(aes) as cbc-aes-rk
[  151.058400] rk3288-crypto ff8b.crypto: Register ecb(des) as ecb-des-rk
[  151.081600] videodev: Linux video capture interface: v2.00
[  151.184800] rk3288-crypto ff8b.crypto: Register cbc(des) as cbc-des-rk
[  151.190566] panfrost ff9a.gpu: clock rate = 5
[  151.202576] rk3288-crypto ff8b.crypto: Register ecb(des3_ede) as 
ecb-des3-ede-rk
[  151.228527] Bluetooth: Core ver 2.22
[  151.229070] NET: Registered PF_BLUETOOTH protocol family
[  151.229535] rk3288-crypto ff8b.crypto: Register cbc(des3_ede) as 
cbc-des3-ede-rk
[  151.229552] Bluetooth: HCI device and connection manager initialized
[  151.230931] Bluetooth: HCI socket layer initialized
[  151.231406] Bluetooth: L2CAP socket layer initialized
[  151.231919] Bluetooth: SCO socket layer initialized
[  151.256807] rk3288-crypto ff8b.crypto: Register sha1 as rk-sha1
[  151.284343] panfrost ff9a.gpu: mali-t860 id 0x860 major 0x2 minor 0x0 
status 0x0
[  151.285070] panfrost ff9a.gpu: features: ,0407, issues: 
,24040400
[  151.285791] panfrost ff9a.gpu: Features: L2:0x07120206 Shader:0x 
Tiler:0x0809 Mem:0x1 MMU:0x2830 AS:0xff JS:0x7
[  151.286827] panfrost ff9a.gpu: shader_present=0xf l2_present=0x1
[  151.309637] rk3288-crypto ff8b.crypto: Register sha256 as rk-sha256
[  151.311614] [drm] Initialized panfrost 1.2.0 20180908 for ff9a.gpu on 
minor 1
[  151.314713] rockchip-rga ff68.rga: HW Version: 0x03.02
[  151.317607] rockchip-rga ff68.rga: Registered rockchip-rga as /dev/video0
[  151.356517] rk3288-crypto ff8b.crypto: Register md5 as rk-md5
[  151.419453] rockchip_vdec: module is from the staging directory, the quality 
is unknown, you have been warned.
[  151.423455] rkvdec ff66.video-codec: Adding to iommu group 1
[  151.427788] rk3288-crypto ff8b8000.crypto: will run requests pump with 
realtime priority
[  151.462746] hantro-vpu ff65.video-codec: Adding to iommu group 0
[  151.464075] hantro-vpu ff65.video-codec: 

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[James Addison]

Thanks Holger,

On Mon, 15 Apr 2024 at 20:43, Holger Wansing  wrote:
>
> Hi,
>
> James Addison  wrote (Sun, 14 Apr 2024 23:52:03 +0100):
> > From some testing of these: the search results have a problem that they
> > hyperlink to a language-less .html URL, meaning that clicking a result link 
> > in
> > the DE-language search results takes the user to a EN-language page.
>
> Yes, good catch.
> However it's even worse: if you view a German page and use the Search 
> function,
> the search index for English is used.

Wait, I'm confused.  Not on your site, though.  There you have the per-language
search indices.

And in fact, when deployed to the debian.org website, requested-language search
(mapping of the browser language to an appropriate searchindex.*.js
file) could be
(and is already) a better user experience.  If you hypothetically send
me a hyperlink
to a policy section auf Deutsch, that's fine, but when I search for
'configuration'
after reading that, I might want my browser settings to have been respected, in
terms of what is searched.

> I have tried to deal with this by some adaptions in the cronjob - see the
> first two additions in my patch: change all links to search.html into
> search.§lang.html, and rename the language-specific searchindex files into
> searchindex.$lang.js.
> However, that does not seem to be enough.

When you say it is not enough: could I check what you mean by that?

> > The _other_ hyperlinks in the static content are replaced as part of the
> > cronjob[1] - but that doesn't work for items in the searchindex.js file.
>
> Why is that a problem at all (maybe you know this already):
> since we use content negotiation at Debian website (so the pages are
> delivered in the correct language according to user's browser setting), we
> change the directory structure away from the default how it's build by Sphinx:
> after Sphinx' make there are separate directories for every language,
> and they contain everything for that language, including the searchindex.js
> file. And in that structure it works fine.
> On Debian website we put everything in one directory, adding the language
> code into the filename in front of the .html extension.
> While this works fine for static content, it does not for the search
> function here.

I think this is a reasonable solution; serving the content from a
single directory
is simple and logical because the permissions and content should be the same;
the latter only differs as a result of locale and therefore translation.

> > Fortunately I think there might be a better way to do this.  Sphinx itself 
> > has
> > an HTML builder option 'html_file_suffix' and I think we could use that 
> > instead
> > to define the filenames.  That option is respected by the search JavaScript
> > using a template variable[3] in the documentation_options.js file.
> >
> > We should be careful of other side-effects if making that change, but it
> > would remove a deployment transformation step on the static content, and I
> > think that's beneficial.
>
> I don't understand how that could affect our search function problem,
> but I could give it a try.

The main change that it would introduce is that the dynamic search results that
appear in the search results (as gathered by the JavaScript) have
hyperlinks that
include the build-time suffix in the filename.  So in the example
above, you have
linked me to a German-language dokumentation page, and when I search from
that page, I find (based on a DE search index) and am linked to (based on DE
file suffixes) Deutsch results; foo.de.html instead of foo.html for example.

I'm in two minds about this: if my browser settings say that my locale is en-150
and I land on a de-DE page, what language should search be performed in, and
what language should the results link to?

An answer that I find straightforward is that if the page is de-DE -- which your
hypothetical link to me was -- then because everything on that page _should_
(with sufficient translation availability) be in German, then I would expect to
search and be linked to pages accordingly.  If you'd linked to a language-less
URL, then that would (a) have been thoughtful if you suspected that I did not
comprehend Deutsch, and (b) also be provided in my default locale, with search
and results taking place accordingly, and without any specific locale in the
result hyperlinks (because the server will select a resource to serve).

Note also: there does _not_ appear to be an equivalent to the 'html_file_suffix'
config setting to adjust the search index filename.

Regards,
James

Bug#1067596: FTBFS: error: ‘const struct input_event’ has no member named ‘time’

[Gianfranco Costamagna]

Control: tags 1067596 + patch
Control: tags 1067596 + pending

Dear maintainer,

I've prepared an NMU for xf86-input-multitouch (versioned as 1.0~rc3-2.1) and
uploaded it.

diff -Nru xf86-input-multitouch-1.0~rc3/debian/changelog 
xf86-input-multitouch-1.0~rc3/debian/changelog
--- xf86-input-multitouch-1.0~rc3/debian/changelog  2018-03-12 
06:38:28.0 +0100
+++ xf86-input-multitouch-1.0~rc3/debian/changelog  2024-04-16 
23:27:03.0 +0200
@@ -1,3 +1,17 @@
+xf86-input-multitouch (1.0~rc3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  [ Gianfranco Costamagna ]
+  * Drop libmtdev1 runtime dependency
+
+  [ Benjamin Drung ]
+  * debian/rules: Pass CPPFLAGS and CFLAGS to make call
+  * Port usage of struct input_event to input_event_*
+(Closes: #1067596, LP: #2061591)
+  * Include headers to fix implicit function declaration
+
+ -- Gianfranco Costamagna   Tue, 16 Apr 2024 
23:27:03 +0200
+
 xf86-input-multitouch (1.0~rc3-2) unstable; urgency=medium

   [ Helmut Grohne ]
diff -Nru xf86-input-multitouch-1.0~rc3/debian/control 
xf86-input-multitouch-1.0~rc3/debian/control
--- xf86-input-multitouch-1.0~rc3/debian/control2018-03-12 
06:38:28.0 +0100
+++ xf86-input-multitouch-1.0~rc3/debian/control2024-04-16 
23:27:03.0 +0200
@@ -15,8 +15,7 @@
 Architecture: linux-any
 Depends: ${shlibs:Depends},
  ${misc:Depends},
- ${xinpdriver:Depends},
- libmtdev1
+ ${xinpdriver:Depends}
 Provides: ${xinpdriver:Provides}
 Description: Multitouch X input driver
  This X input driver provides gestures support for multitouch touchpads,
diff -Nru 
xf86-input-multitouch-1.0~rc3/debian/patches/Include-headers-to-fix-implicit-function-declaration.patch
 
xf86-input-multitouch-1.0~rc3/debian/patches/Include-headers-to-fix-implicit-function-declaration.patch
--- 
xf86-input-multitouch-1.0~rc3/debian/patches/Include-headers-to-fix-implicit-function-declaration.patch
 1970-01-01 01:00:00.0 +0100
+++ 
xf86-input-multitouch-1.0~rc3/debian/patches/Include-headers-to-fix-implicit-function-declaration.patch
 2024-04-16 23:27:03.0 +0200
@@ -0,0 +1,46 @@
+From: Benjamin Drung 
+Date: Mon, 15 Apr 2024 20:11:11 +0200
+Subject: Include headers to fix implicit function declaration
+
+---
+ driver/multitouch.c | 1 +
+ src/mtouch.c| 1 +
+ src/test.c  | 1 +
+ 3 files changed, 3 insertions(+)
+
+diff --git a/driver/multitouch.c b/driver/multitouch.c
+index a083adc..0c4615c 100644
+--- a/driver/multitouch.c
 b/driver/multitouch.c
+@@ -22,6 +22,7 @@
+ #include "gestures.h"
+
+ #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) >= 7
++#include 
+ #include 
+ #include 
+ #endif
+diff --git a/src/mtouch.c b/src/mtouch.c
+index a6b96b8..335c61e 100644
+--- a/src/mtouch.c
 b/src/mtouch.c
+@@ -20,6 +20,7 @@
+  **/
+
+ #include "mtouch.h"
++#include 
+
+ static const int use_grab = 0;
+
+diff --git a/src/test.c b/src/test.c
+index 1b67986..77b723e 100644
+--- a/src/test.c
 b/src/test.c
+@@ -22,6 +22,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+
+ static void loop_device(int fd)
+ {
diff -Nru 
xf86-input-multitouch-1.0~rc3/debian/patches/Port-usage-of-struct-input_event-to-input_event_.patch
 
xf86-input-multitouch-1.0~rc3/debian/patches/Port-usage-of-struct-input_event-to-input_event_.patch
--- 
xf86-input-multitouch-1.0~rc3/debian/patches/Port-usage-of-struct-input_event-to-input_event_.patch
 1970-01-01 01:00:00.0 +0100
+++ 
xf86-input-multitouch-1.0~rc3/debian/patches/Port-usage-of-struct-input_event-to-input_event_.patch
 2024-04-16 23:27:03.0 +0200
@@ -0,0 +1,40 @@
+From: Benjamin Drung 
+Date: Mon, 15 Apr 2024 19:56:58 +0200
+Subject: Port usage of struct input_event to input_event_*
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+It fails to build on armhf:
+
+```
+src/hwstate.c: In function ‘finish_packet’:
+src/hwstate.c:43:24: error: ‘const struct input_event’ has no member named
+‘time’
+   43 | s->evtime = syn->time.tv_usec / ms + syn->time.tv_sec * ms;
+  | ^~
+src/hwstate.c:43:49: error: ‘const struct input_event’ has no member named
+‘time’
+   43 | s->evtime = syn->time.tv_usec / ms + syn->time.tv_sec * ms;
+  | ^~
+```
+
+Closes: #1067596
+LP: #2061591
+---
+ src/hwstate.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/hwstate.c b/src/hwstate.c
+index 076efa1..ab2ac48 100644
+--- a/src/hwstate.c
 b/src/hwstate.c
+@@ -40,7 +40,7 @@ static void finish_packet(struct HWState *s, const struct 
Capabilities *caps,
+   if (!caps->has_abs[MTDEV_WIDTH_MINOR])
+   s->data[i].width_minor = s->data[i].width_major;
+   }
+-  s->evtime = syn->time.tv_usec / ms + syn->time.tv_sec * ms;
++  s->evtime = syn->input_event_usec / ms + syn->input_event_sec * ms;
+ }
+
+ static int read_event(struct 

Bug#1066547: xf86-input-mtrack: FTBFS: src/gestures.c:763:13: error: implicit declaration of function ‘mtdev_empty’; did you mean ‘mtdev_get’? [-Werror=implicit-function-declaration]

[Gianfranco Costamagna]

updated diff:

debdiff xf86-input-mtrack_0.3.1-1.dsc xf86-input-mtrack_0.3.1-1.1.dsc
diff -Nru xf86-input-mtrack-0.3.1/debian/changelog 
xf86-input-mtrack-0.3.1/debian/changelog
--- xf86-input-mtrack-0.3.1/debian/changelog2015-06-02 07:09:33.0 
+0200
+++ xf86-input-mtrack-0.3.1/debian/changelog2024-04-16 23:32:48.0 
+0200
@@ -1,3 +1,11 @@
+xf86-input-mtrack (0.3.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Add patch to fix implicit-function-declaration build failures
+(Closes: #1066547)
+
+ -- Gianfranco Costamagna   Tue, 16 Apr 2024 
23:32:48 +0200
+
 xf86-input-mtrack (0.3.1-1) unstable; urgency=medium
 
   * Upload to unstable.

diff -Nru 
xf86-input-mtrack-0.3.1/debian/patches/missing-includes-implicit-function-declaration-fix.patch
 
xf86-input-mtrack-0.3.1/debian/patches/missing-includes-implicit-function-declaration-fix.patch
--- 
xf86-input-mtrack-0.3.1/debian/patches/missing-includes-implicit-function-declaration-fix.patch
 1970-01-01 01:00:00.0 +0100
+++ 
xf86-input-mtrack-0.3.1/debian/patches/missing-includes-implicit-function-declaration-fix.patch
 2024-04-16 23:32:48.0 +0200
@@ -0,0 +1,24 @@
+Description: Add patch to fix missing includes
+Author: Gianfranco Costamagna 
+Last-Update: 2024-04-16
+
+--- xf86-input-mtrack-0.3.1.orig/include/common.h
 xf86-input-mtrack-0.3.1/include/common.h
+@@ -33,6 +33,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+
+--- xf86-input-mtrack-0.3.1.orig/tools/mtrack-test.c
 xf86-input-mtrack-0.3.1/tools/mtrack-test.c
+@@ -23,6 +23,7 @@
+ #include "mtouch.h"
+ #include 
+ #include 
++#include 
+
+ void xf86Msg(int type, const char *format, ...)
+ {
diff -Nru xf86-input-mtrack-0.3.1/debian/patches/series 
xf86-input-mtrack-0.3.1/debian/patches/series
--- xf86-input-mtrack-0.3.1/debian/patches/series   2012-07-05 
09:57:49.0 +0200
+++ xf86-input-mtrack-0.3.1/debian/patches/series   2024-04-16 
23:32:48.0 +0200
@@ -1,3 +1,4 @@
 #drop-mtrack-test
 #aa
 upsteam-commit
+missing-includes-implicit-function-declaration-fix.patch


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069132: gm-assistant: Openclipart public domain dedication is misrepresented as CC0

[Bastian Germann]

Source: gm-assistant
Version: 1.2.4-1
Control: forwarded -1 https://github.com/ViviCoder/GM-Assistant/issues/158

The metadata of the openclipart SVGs links to https://creativecommons.org/licenses/publicdomain/ which d/copyright and 
upstream's COPYRIGHT file claim to be CC0-1.0. That is not true. CC0-1.0 is not a mere public domain dedication that is 
represented by that link. SPDX assigned the short license name CC-PDDC for that.


fr.free.gmassistant.metainfo.xml.in, which is indeed licensed under CC0, is not mentioned in d/copyright but has to be 
documented.

Bug#1066547: xf86-input-mtrack: FTBFS: src/gestures.c:763:13: error: implicit declaration of function ‘mtdev_empty’; did you mean ‘mtdev_get’? [-Werror=implicit-function-declaration]

[Gianfranco Costamagna]

control: tags -1 patch pending


Dear maintainer,

I've prepared an NMU for xf86-input-mtrack (versioned as 0.3.1-1.1) and
uploaded it.



diff -Nru xf86-input-mtrack-0.3.1/debian/changelog 
xf86-input-mtrack-0.3.1/debian/changelog
--- xf86-input-mtrack-0.3.1/debian/changelog2024-04-01 10:36:37.0 
+0200
+++ xf86-input-mtrack-0.3.1/debian/changelog2024-04-16 23:32:48.0 
+0200
@@ -1,3 +1,10 @@
+xf86-input-mtrack (0.3.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Add patch to fix implicit-function-declaration build failures (Closes: 
#1066547)
+
+ -- Gianfranco Costamagna   Tue, 16 Apr 2024 
23:32:48 +0200
+
 xf86-input-mtrack (0.3.1-1build5) noble; urgency=medium

   * No-change rebuild for CVE-2024-3094
diff -Nru 
xf86-input-mtrack-0.3.1/debian/patches/missing-includes-implicit-function-declaration-fix.patch
 
xf86-input-mtrack-0.3.1/debian/patches/missing-includes-implicit-function-declaration-fix.patch
--- 
xf86-input-mtrack-0.3.1/debian/patches/missing-includes-implicit-function-declaration-fix.patch
 1970-01-01 01:00:00.0 +0100
+++ 
xf86-input-mtrack-0.3.1/debian/patches/missing-includes-implicit-function-declaration-fix.patch
 2024-04-16 23:32:48.0 +0200
@@ -0,0 +1,24 @@
+Description: Add patch to fix missing includes
+Author: Gianfranco Costamagna 
+Last-Update: 2024-04-16
+
+--- xf86-input-mtrack-0.3.1.orig/include/common.h
 xf86-input-mtrack-0.3.1/include/common.h
+@@ -33,6 +33,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+
+--- xf86-input-mtrack-0.3.1.orig/tools/mtrack-test.c
 xf86-input-mtrack-0.3.1/tools/mtrack-test.c
+@@ -23,6 +23,7 @@
+ #include "mtouch.h"
+ #include 
+ #include 
++#include 
+
+ void xf86Msg(int type, const char *format, ...)
+ {
diff -Nru xf86-input-mtrack-0.3.1/debian/patches/series 
xf86-input-mtrack-0.3.1/debian/patches/series
--- xf86-input-mtrack-0.3.1/debian/patches/series   2012-07-05 
09:57:49.0 +0200
+++ xf86-input-mtrack-0.3.1/debian/patches/series   2024-04-16 
23:32:48.0 +0200
@@ -1,3 +1,4 @@
 #drop-mtrack-test
 #aa
 upsteam-commit
+missing-includes-implicit-function-declaration-fix.patch

Bug#1068890: diffoscope: --hard-timeout option

[Vagrant Cascadian]

On 2024-04-16, Chris Lamb wrote:
> However, I think this first iteration of --hard-timeout time has a few
> things that would need ironing out first, and potentially make it not
> worth implementing:
>
> (1) You suggest it should start again with "--max-container-depth 3",
> but it would surely need some syntax (or another option?) to control
> that "3" (but for the second time only).

What about going the other direction ... starting with a very small
value for max-container-depth, and incrementally increasing it,
generating a report (or at least storing sufficient data to generate
one) in between each increment, so you always get some information, but
essentially incrementally increase the resolution?

Or would that approach just be too inefficient?


> (2) In fact, its easy to imagine that one would want to restart with
> other restrictions as well: not just --max-container-depth. For
> instance, excluding external commands like readelf and objdump that
> you know to be slow.

Ah, yes, knowing the common time sinks would be tremendously helpful!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1069077: Re: Bug#1069077: es8316 driver causes kernel oops / panic on rockpro64

[Forest]

Control: found -1 6.6.15-2


On Tue, 16 Apr 2024 10:34:45 +0200, Diederik de Haas wrote:

>Can you try the Debian Testing kernel, which is at version 6.6.15?

6.6.15-2 also has the bug.

Bug#1068409: dovecot-core: avoid linking against libsystemd0

[Noah Meyerhans]

On Thu, Apr 04, 2024 at 08:34:28PM +0200, Jörg-Volker Peetz wrote:
> in light of the recent xz security breach, I'd like to ask if it
> would be possible to rework systemd readiness notification and socket
> activation patches to not link against libsystemd as just achieved for
> the openssh-server package in version 1:9.7p1-4 ?
> This would avoid /usr/bin/dovecot being linked also to three compression
> libraries (liblz4, liblzma, libzstd) and to libgpg-error.

Yes, I believe this is reasonable.  I believe the systemd upstream
maintainers have just released an updated MIT-0 licensed example of the
socket activation patches that avoids requiring libsystemd0.  I'll see
about adapting this patch to dovecot.

noah

Bug#1068794: sane-utils: (x)scanimage only works once, a second scan right after the first one fails

[Paul Cobbaut]

We managed to solve this bug upstream.
https://gitlab.com/sane-project/backends/-/issues/742

Paul

Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Salvatore Bonaccorso]

Hi,

On Tue, Apr 16, 2024 at 05:46:33PM +0200, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi
> 
> 
> On Tue, Apr 16, 2024 at 02:17:49PM +0200, Manfred Larcher wrote:
> > Package: src:linux
> > Version: 6.1.85-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> > kernel update from version 6.1.0-18 to 6.1.0-20
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > out system mounted a samba share via autofs (cifs) and we tried to access
> > some files and directories
> > 
> >* What was the outcome of this action?
> > the mount point of our share is /srv/samba/shares/company and the directory
> > it/MIJ had another directory "digitale kommunikation" which did not shop up
> > on the computer which mounted the samba share. before the kernel update it
> > did and when we renamed the file to "digitale_kommunikation" or to "digitalo
> > kommunikation" we could see it.
> > in the syslog we found the following messages:
> > CIFS: VFS: directory entry name would overflow frame end of buf ...
> > we could move that direcotry into another directory and it was useable, we
> > created another directory it/abc and created the "digitale kommunikation"
> > inside and it was hidden again. after switching back to kernel 6.1.0-20
> > everything was ok.
> > upgrade to kernel 6.5.0-0.deb12.4-amd64 package was ok too.
> > 
> >* What outcome did you expect instead?
> > we expected to just see the "digitale kommunikation" directory as before.
> 
> Can you share details on how the cifs mounts are done? Which mount
> options are used?
> 
> Were you able to find a minimal reproducing case which would help
> debug the issue on non production systems?

Can you confirm you are seeing the issue only if mounting with using
'noserverino' mount option?

Would you be in the position of building a kernel with a commit
reverted and verify the issue is gone with it?

If you follow
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
with the attached patch, you should be able to get a kernel image to
test with.

Regards,
Salvatore
>From 00ab6d9874ba6adc3c8edb61c0a583e8e516ccbd Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Tue, 16 Apr 2024 22:46:24 +0200
Subject: [PATCH] Revert "smb: client: set correct d_type for reparse points
 under DFS mounts"

This reverts commit 0947d0d463d4e6fad75f3a3066613cb3d9689b26.
---
 fs/smb/client/readdir.c | 15 +++
 fs/smb/client/smb2pdu.c |  6 --
 2 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/fs/smb/client/readdir.c b/fs/smb/client/readdir.c
index 5990bdbae598..2d75ba5aaa8a 100644
--- a/fs/smb/client/readdir.c
+++ b/fs/smb/client/readdir.c
@@ -304,16 +304,14 @@ cifs_dir_info_to_fattr(struct cifs_fattr *fattr, FILE_DIRECTORY_INFO *info,
 }
 
 static void cifs_fulldir_info_to_fattr(struct cifs_fattr *fattr,
-   const void *info,
+   SEARCH_ID_FULL_DIR_INFO *info,
    struct cifs_sb_info *cifs_sb)
 {
-	const FILE_FULL_DIRECTORY_INFO *di = info;
-
 	__dir_info_to_fattr(fattr, info);
 
-	/* See MS-FSCC 2.4.14, 2.4.19 */
+	/* See MS-FSCC 2.4.19 FileIdFullDirectoryInformation */
 	if (fattr->cf_cifsattrs & ATTR_REPARSE)
-		fattr->cf_cifstag = le32_to_cpu(di->EaSize);
+		fattr->cf_cifstag = le32_to_cpu(info->EaSize);
 	cifs_fill_common_info(fattr, cifs_sb);
 }
 
@@ -427,7 +425,7 @@ _initiate_cifs_search(const unsigned int xid, struct file *file,
 	} else if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM) {
 		cifsFile->srch_inf.info_level = SMB_FIND_FILE_ID_FULL_DIR_INFO;
 	} else /* not srvinos - BB fixme add check for backlevel? */ {
-		cifsFile->srch_inf.info_level = SMB_FIND_FILE_FULL_DIRECTORY_INFO;
+		cifsFile->srch_inf.info_level = SMB_FIND_FILE_DIRECTORY_INFO;
 	}
 
 	search_flags = CIFS_SEARCH_CLOSE_AT_END | CIFS_SEARCH_RETURN_RESUME;
@@ -1021,9 +1019,10 @@ static int cifs_filldir(char *find_entry, struct file *file,
    (FIND_FILE_STANDARD_INFO *)find_entry,
    cifs_sb);
 		break;
-	case SMB_FIND_FILE_FULL_DIRECTORY_INFO:
 	case SMB_FIND_FILE_ID_FULL_DIR_INFO:
-		cifs_fulldir_info_to_fattr(, find_entry, cifs_sb);
+		cifs_fulldir_info_to_fattr(,
+	   (SEARCH_ID_FULL_DIR_INFO *)find_entry,
+	   cifs_sb);
 		break;
 	default:
 		cifs_dir_info_to_fattr(,
diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c
index cc425a616899..f95623b24405 100644
--- a/fs/smb/client/smb2pdu.c
+++ b/fs/smb/client/smb2pdu.c
@@ -5010,9 +5010,6 @@ int SMB2_query_directory_init(const unsigned int xid,
 	case SMB_FIND_FILE_POSIX_INFO:
 		req->FileInformationClass = SMB_FIND_FILE_POSIX_INFO;
 		break;
-	case SMB_FIND_FILE_FULL_DIRECTORY_INFO:
-		req->FileInformationClass = FILE_FULL_DIRECTORY_INFORMATION;
-		break;
 	default:
 		cifs_tcon_dbg(VFS, "info level %u isn't supported\n",
 			info_level);
@@ -5082,9 +5079,6 @@ smb2_parse_query_directory(struct cifs_tcon *tcon,
 		/* note 

Bug#1068890: diffoscope: --hard-timeout option

[Holger Levsen]

On Tue, Apr 16, 2024 at 04:51:09PM +0100, Chris Lamb wrote:
> Just to say that I am totally on board with the idea of ensuring we
> get _something_ out of diffoscope on tests.reproducible-builds.org.

:) great!

> Way better than 250 timeouts.

https://tests.reproducible-builds.org/debian/stats_breakages.png
showed that in the last 3-4 years there was constant progress on that! \o/

> However, I think this first iteration of --hard-timeout time has a few
> things that would need ironing out first, and potentially make it not
> worth implementing:
> 
> (1) You suggest it should start again with "--max-container-depth 3",
> but it would surely need some syntax (or another option?) to control
> that "3" (but for the second time only).

another option, --second-pass-max-container-depth or some such

> (2) In fact, its easy to imagine that one would want to restart with
> other restrictions as well: not just --max-container-depth. For
> instance, excluding external commands like readelf and objdump that
> you know to be slow.

yes, that's a good idea and IMO should be automatically implied for the
2nd pass or round or try.

> (3) The output might need some comment saying "this was re-run with
> restrictions as we hit a timeout".

absolutly.

> (4) My gut feel that it would not be all that great to rely on CPython
> to really properly clear up child processes after a certain amount of
> time. Although I believe the most reliable top-level description to do
> this kind of thing inside CPython is to start a watchdog thread that
> sleeps until the timeout and then tries to kill everything, but my
> experience of doing anything like this within Python itself is not
> great, and essentially always needed something at the process level
> outside of it for it to be reliable. A container would be even more
> effective, I'm sure.

hmmm.

> In other words, I think the best way of achieving the result we want
> is, alas, by doing it outside of diffoscope at the level of the
> Jenkins. As in, exactly what you describe here:
> 
> > Else we could also extend the current code for tests.r-b.o/debian, 
> > which currently
> > just kills diffoscope after 2h, to then run diffoscope 
> > --max-container-depth 3 :)
> 
> Is that a massive faff?  :/

not really, I guess it would be rather simple even, I just thought
(or think?) that it would be a nice feature for diffoscope proper.


-- 
cheers,
Holger

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

The purpose of propaganda isn't to make you believe something. It's to make you
believe nothing. So that you do nothing. (@DarthPutinKGB)


signature.asc
Description: PGP signature

Bug#1068478: dovecot-core: Wildcard !include statements fail if nothing matches

[Noah Meyerhans]

Control: tags -1 + confirmed upstream
Control: severity -1 minor

On Fri, Apr 05, 2024 at 10:04:29PM +, Einhard Leichtfuß wrote:
> when the Dovecot configuration contains an `!include` statement with a
> wildcard that does not match anything, dovecot prints an error and
> terminates.
> 
> Expected behaviour: Dovecot processes the configuration as if the
> `!include` statement was not present.
> 
> The upstream on-line documentation [0] says on `!include`:
> > It’s not an error if wildcards don’t result in any matching files.
> 
> [0] 
> 

Confirmed based on your repro steps.  The documentation does indeed
claim that this should not result in an error, but that's not consistent
with the code.  Some relevant snippets of code from
src/config/config-parser.c:

from config_parse_line():
if (strcmp(key, "!include") == 0)
return CONFIG_LINE_TYPE_INCLUDE;
if (strcmp(key, "!include_try") == 0)
return CONFIG_LINE_TYPE_INCLUDE_TRY;

This return value is later handled with a case statement in 
config_parser_apply_line():
case CONFIG_LINE_TYPE_INCLUDE:
case CONFIG_LINE_TYPE_INCLUDE_TRY:
(void)settings_include(ctx, fix_relative_path(value, 
ctx->cur_input),
   type == CONFIG_LINE_TYPE_INCLUDE_TRY);
break;

The result of the "type == CONFIG_LINE_TYPE_INCLUDE_TRY" statement is
passed as the bool ignore_errors parameter to bool ignore_errors(), so
if it evaluates to false as it does when type ==
CONFIG_LINE_TYPE_INCLUDE, then we return an error:

case GLOB_NOMATCH:
if (ignore_errors)
return 0;
ctx->error = "No matches";
return -1;

I will pass this along to upstream.  It's not clear from here whether
the issue is with the code or with the documentation.

noah

Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

[Salvatore Bonaccorso]

Control: forwarded -1 
https://lore.kernel.org/regressions/zh7flxvnddfat...@eldamar.lan/T/#u

Hi both,

On Tue, Apr 16, 2024 at 08:31:23PM +0200, Roland Rosenfeld wrote:
> Hi Salvatore and Diederik!
> 
> On Di, 16 Apr 2024, Salvatore Bonaccorso wrote:
> 
> > If you revert that commit, does that fix your issue? Note that it
> > opens up again as well the referenced issue, but it would be helpfull
> > for reporting as regression if we know that's the case.
> 
> Thanks to the support by Diederik, I was able to build a new kernel
> with the two patches reverted and this kernel solves the issue and
> uses the correct MAC and renames the interface to enx as before
> instead of using a random MAC and using eth0 as the inerface name.
> 
> On Di, 16 Apr 2024, Diederik de Haas wrote:
> 
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
> > describes a procedure with which you can apply (the attached) patches
> 
> Thanks for this hint and pointing to the perfect chapter, which made
> building a test kernel really easy.
> 
> I used the two patches, that you suggested, they are exactly the
> reverse of the two problem patches, that lead us to this issue.

Many thanks for testing!

I have forward your found regression to the regressions list:

https://lore.kernel.org/regressions/zh7flxvnddfat...@eldamar.lan/T/#u

Regards,
Salvatore

Bug#1069131: e1000e driver Network Card Detected Hardware Unit Hang

[Jamie]

Package: linux-image-6.1.0-20-amd64

So  there is a very nasty bug in the e1000e network card
driver.

I am running Debian 12 Bookworm.

You will get the message "Detected Hardware Unit Hang" and then
the network card just stops working.

This is a built in NIC  on the computer
The computer is a is a HP Prodesk 600 G4 MT

This is the mini tower version as denoted by the MT.


This log comes from my /var/log/syslog.


Apr 15 01:57:12 gateway vmunix: [ 7743.893557] e1000e :00:1f.6 eth1: 
Detected Hardware Unit Hang:

Apr 15 01:57:12 gateway vmunix: [ 7743.893557] TDH  
Apr 15 01:57:12 gateway vmunix: [ 7743.893557] TDT  
Apr 15 01:57:12 gateway vmunix: [ 7743.893557] next_to_use  
Apr 15 01:57:12 gateway vmunix: [ 7743.893557] next_to_clean    
Apr 15 01:57:12 gateway vmunix: [ 7743.893557] buffer_info[next_to_clean]:
Apr 15 01:57:12 gateway vmunix: [ 7743.893557] time_stamp   
<1001c6345>

Apr 15 01:57:12 gateway vmunix: [ 7743.893557] next_to_watch    
Apr 15 01:57:12 gateway vmunix: [ 7743.893557] jiffies  
<1001c6550>

Apr 15 01:57:12 gateway vmunix: [ 7743.893557] next_to_watch.status <0>
Apr 15 01:57:12 gateway vmunix: [ 7743.893557] MAC Status 
<80083>

Apr 15 01:57:12 gateway vmunix: [ 7743.893557] PHY Status <796d>
Apr 15 01:57:12 gateway vmunix: [ 7743.893557] PHY 1000BASE-T Status  <3800>
Apr 15 01:57:12 gateway vmunix: [ 7743.893557] PHY Extended Status    <3000>
Apr 15 01:57:12 gateway vmunix: [ 7743.893557] PCI Status <10>
Apr 15 01:57:13 gateway vmunix: [ 7744.123237] net-fw DROP IN=eth0 OUT= 
MAC=00:13:3b:e3:8f:b0:0c:a4:02:35:6d:87:08:00 SRC=75.159.223.219 
DST=199.126.41.116 LE>
Apr 15 01:57:13 gateway vmunix: [ 7744.417235] net-fw DROP IN=eth0 OUT= 
MAC=00:13:3b:e3:8f:b0:0c:a4:02:35:6d:87:08:00 SRC=75.159.223.219 
DST=199.126.41.116 LE>
Apr 15 01:57:14 gateway vmunix: [ 7745.412183] net-fw DROP IN=eth0 OUT= 
MAC=00:13:3b:e3:8f:b0:0c:a4:02:35:6d:87:08:00 SRC=75.159.223.219 
DST=199.126.41.116 LE>
Apr 15 01:57:14 gateway vmunix: [ 7745.659234] net-fw DROP IN=eth0 OUT= 
MAC=00:13:3b:e3:8f:b0:0c:a4:02:35:6d:87:08:00 SRC=75.159.223.219 
DST=199.126.41.116 LE>
Apr 15 01:57:14 gateway vmunix: [ 7745.877564] e1000e :00:1f.6 eth1: 
Detected Hardware Unit Hang:

Apr 15 01:57:14 gateway vmunix: [ 7745.877564] TDH  
Apr 15 01:57:14 gateway vmunix: [ 7745.877564] TDT  
Apr 15 01:57:14 gateway vmunix: [ 7745.877564] next_to_use  
Apr 15 01:57:14 gateway vmunix: [ 7745.877564] next_to_clean    
Apr 15 01:57:14 gateway vmunix: [ 7745.877564] buffer_info[next_to_clean]:
Apr 15 01:57:14 gateway vmunix: [ 7745.877564] time_stamp   
<1001c6345>

Apr 15 01:57:14 gateway vmunix: [ 7745.877564] next_to_watch    
Apr 15 01:57:14 gateway vmunix: [ 7745.877564] jiffies  
<1001c6740>

Apr 15 01:57:14 gateway vmunix: [ 7745.877564] next_to_watch.status <0>
Apr 15 01:57:14 gateway vmunix: [ 7745.877564] MAC Status 
<80083>

Apr 15 01:57:14 gateway vmunix: [ 7745.877564] PHY Status <796d>
Apr 15 01:57:14 gateway vmunix: [ 7745.877564] PHY 1000BASE-T Status  <3800>
Apr 15 01:57:14 gateway vmunix: [ 7745.877564] PHY Extended Status    <3000>
Apr 15 01:57:14 gateway vmunix: [ 7745.877564] PCI Status <10>
Apr 15 01:57:15 gateway vmunix: [ 7746.220253] net-fw DROP IN=eth0 OUT= 
MAC=00:13:3b:e3:8f:b0:0c:a4:02:35:6d:87:08:00 SRC=75.159.223.219 
DST=199.126.41.116 LE>
Apr 15 01:57:15 gateway vmunix: [ 7746.485268] net-fw DROP IN=eth0 OUT= 
MAC=00:13:3b:e3:8f:b0:0c:a4:02:35:6d:87:08:00 SRC=75.159.223.219 
DST=199.126.41.116 LE>
Apr 15 01:57:16 gateway vmunix: [ 7747.893578] e1000e :00:1f.6 eth1: 
Detected Hardware Unit Hang:

Apr 15 01:57:16 gateway vmunix: [ 7747.893578] TDH  
Apr 15 01:57:16 gateway vmunix: [ 7747.893578] TDT  
Apr 15 01:57:16 gateway vmunix: [ 7747.893578] next_to_use  
Apr 15 01:57:16 gateway vmunix: [ 7747.893578] next_to_clean    
Apr 15 01:57:16 gateway vmunix: [ 7747.893578] buffer_info[next_to_clean]:
Apr 15 01:57:16 gateway vmunix: [ 7747.893578] time_stamp   
<1001c6345>

Apr 15 01:57:16 gateway vmunix: [ 7747.893578] next_to_watch    
Apr 15 01:57:16 gateway vmunix: [ 7747.893578] jiffies  
<1001c6938>

Apr 15 01:57:16 gateway vmunix: [ 7747.893578] next_to_watch.status <0>
Apr 15 01:57:16 gateway vmunix: [ 7747.893578] MAC Status 
<80083>

Apr 15 01:57:16 gateway vmunix: [ 7747.893578] PHY Status <796d>
Apr 15 01:57:16 gateway vmunix: [ 7747.893578] PHY 1000BASE-T Status  <3800>
Apr 15 01:57:16 gateway vmunix: [ 7747.893578] PHY Extended Status    <3000>
Apr 15 01:57:16 gateway vmunix: [ 7747.893578] PCI Status <10>


It does this multiple times and the network interface in this case eth1 
becomes
unstable and just stops responding now I can't have that because this 
computer
is 

Bug#1068997: mailtextbody: feature request: optionally specify MIME type to extract (default: text/plain)

[Jonas Smedegaard]

Quoting gregor herrmann (2024-04-16 21:22:35)
> On Sun, 14 Apr 2024 21:38:08 +0200, Jonas Smedegaard wrote:
> 
> > What a neat little tool.  I have needed this many times over the years.
> 
> Thanks!
> 
> > One thing that I would want, which seems within the scope of this tiny
> > tool: An option to specify which MIME type to look for, with default
> > being the currently hardcoded text/plain.
> 
> Nice idea, expect a new release + upload soon :)

Awesome!

 - Jonas

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

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

signature.asc
Description: signature

Bug#1069119: gpsshogi: EPL missing from debian/copyright

[Bastian Germann]

I am uploading a NMU to fix this. The debdiff is included and also pushed to 
git.diff -Nru gpsshogi-0.7.0/debian/changelog gpsshogi-0.7.0/debian/changelog
--- gpsshogi-0.7.0/debian/changelog 2022-09-27 19:03:18.0 +
+++ gpsshogi-0.7.0/debian/changelog 2024-04-16 18:56:27.0 +
@@ -1,3 +1,11 @@
+gpsshogi (0.7.0-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/copyright: Convert to standardized format
+  * d/copyright: Include EPL text (Closes: #1069119)
+
+ -- Bastian Germann   Tue, 16 Apr 2024 18:56:27 +
+
 gpsshogi (0.7.0-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gpsshogi-0.7.0/debian/copyright gpsshogi-0.7.0/debian/copyright
--- gpsshogi-0.7.0/debian/copyright 2022-09-27 18:58:24.0 +
+++ gpsshogi-0.7.0/debian/copyright 2024-04-16 18:56:27.0 +
@@ -1,13 +1,13 @@
-Format-Specification: 
http://wiki.debian.org/Proposals/CopyrightFormat?action=recall=420
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: GPSShogi
-Upstream-Maintainer: 
+Upstream-Contact:
   TANAKA   Tetsurou  
   KANEKO   Tomoyuki  
   MORIWAKI Daigo 
   SOEDAShunsuke  
   HAYASHI  Yoshiki   
   TAKEUCHI Shougo
-Upstream-Source: http://gps.tanaka.ecc.u-tokyo.ac.jp/osl/
+Source: http://gps.tanaka.ecc.u-tokyo.ac.jp/osl/
 
 Files: *
 Copyright: Copyright (C) 2003-2010 Team GPS
@@ -25,7 +25,7 @@
  You should have received a copy of the GNU General Public License
  along with this program; if not, write to the Free Software
  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
- .
+Comment:
  On Debian systems, the complete text of the GNU General Public License can
  be found in `/usr/share/common-licenses/GPL-2'.
 
@@ -54,17 +54,212 @@
  .
  This file is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE
  WARRANTY OF DESIGN, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- .
+Comment:
  On Debian systems, the complete text of the GNU General Public License can
  be found in `/usr/share/common-licenses/GPL-2'.
 
 Files: sample/cluster_dashboard/src/net/n01se/clojure_jna.clj
 Copyright: Copyright (c) Chris Houser, May 2009. All rights reserved.
-License:  EPL-1
+Comment:
  The use and distribution terms for this software are covered by the
  Eclipse Public License 1.0 (http://opensource.org/licenses/eclipse-1.0.php)
  which can be found in the file epl-v10.html at the root of this distribution.
  By using this software in any fashion, you are agreeing to be bound by
  the terms of this license.
  You must not remove this notice, or any other, from this software.
-
+License: EPL-1
+ Eclipse Public License - v 1.0
+ .
+ THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE PUBLIC
+ LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM
+ CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.
+ .
+ 1. DEFINITIONS
+ .
+ "Contribution" means:
+ .
+ a) in the case of the initial Contributor, the initial code and documentation
+distributed under this Agreement, and
+ b) in the case of each subsequent Contributor:
+ i) changes to the Program, and
+ ii) additions to the Program;
+ where such changes and/or additions to the Program originate from and are
+ distributed by that particular Contributor. A Contribution 'originates' from
+ a Contributor if it was added to the Program by such Contributor itself or
+ anyone acting on such Contributor's behalf. Contributions do not include
+ additions to the Program which: (i) are separate modules of software
+ distributed in conjunction with the Program under their own license agreement,
+ and (ii) are not derivative works of the Program.
+ "Contributor" means any person or entity that distributes the Program.
+ .
+ "Licensed Patents" mean patent claims licensable by a Contributor which are
+ necessarily infringed by the use or sale of its Contribution alone or when
+ combined with the Program.
+ .
+ "Program" means the Contributions distributed in accordance with this 
Agreement.
+ .
+ "Recipient" means anyone who receives the Program under this Agreement,
+ including all Contributors.
+ .
+ 2. GRANT OF RIGHTS
+ .
+ a) Subject to the terms of this Agreement, each Contributor hereby grants
+Recipient a non-exclusive, worldwide, royalty-free copyright license to
+reproduce, prepare derivative works of, publicly display, publicly perform,
+distribute and sublicense the Contribution of such Contributor, if any, and
+such derivative works, in source code and object code form.
+ b) Subject to the terms of this Agreement, each Contributor hereby grants
+Recipient a non-exclusive, worldwide, royalty-free patent license under
+Licensed Patents to make, use, sell, offer to sell, import and otherwise
+transfer the Contribution of such Contributor, if any, in source code and
+object code form. This patent license shall apply to the combination of the
+   

Bug#1069129: ITP: rust-hypothesis -- wrapper and CLI for the Hypothesis API

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-hypothesis
  Version : 0.11.1
  Upstream Contact: OutOfCheeseError
* URL : https://github.com/out-of-cheese-error/rust-hypothesis
* License : BSD-2-clause
  Programming Lang: Rust
  Description : wrapper and CLI for the Hypothesis API

 The hypothesis crate provides a lightweight wrapper and CLI
 for the Hypothesis Web API v1.0.0.
 It includes all APIKey authorized endpoints
 related to...
  * annotations (create / update / delete / search / fetch / flag)
  * groups (create / update / list / fetch / leave / members)
  * profile (user information / groups)
 .
 This package contains the source for the Rust hypothesis crate,
 for use with cargo and dh-cargo.

This package is needed for gooseberry (bug#106).
It will be maintained in the collaborative Debian section of Salsa, at
.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYe1scACgkQLHwxRsGg
ASHzMg//TaU1z7OY+DS0MtsAiXpTO9yHdw6DJMogbDtuFS764y6fPK/A5JNC0NUw
ZJoY8ycArhOCzWYDbSFGxYz0llwJwO6VuaPtKa3EUy+www8WjxCkQMzmXiqlSbhl
2qnh3Aj03XyUhmFl4hqiCyVeV0RH7B3Ylj4JGEEgOZhvYZL99OdMixwgHtTZDg6y
2yOxUyhU7ULiuGa5JZaOSSnHqpPdygimny0GDdj5FM5KJ4h32v9u7q9QLoyYADQQ
eNVa1zT9hukTee9AlpD7uFtxhXF3IReArakTAjmxoEqAssc+DAZBp4DBHVquai/p
Mw6AQY2kX8QOTzaGlNVZ3cVmAGXUxjAhUJfxpJswRmou9mtuI+E1L8N0znfmqQJ4
QfUEq2ZCVvaAis6QysBSZ/AvRfzjX4mIrpeChifk1jxsa8CkIjRdwKEUpiqlpaDf
bIIr/K/PpTR2duo/b9U+Y62WyZo/7XTjQTe4pqxcR3E6JmuHSB+K7z8IVxDJzOIA
gHzllETerCbMoi+fM1qOKZlCzb5SBIRKyERnFUF1grMsQJr/73jFkS2Bxq+B5sSm
dfZsf7D4TeXcdIy6kBcAeZwQsNnINZT0xvHjvJ14oekqm3ayg80okAK8lL505aTE
VvkgO632KoD4AVG7GJemSmaKO0nF4djhtK1l9lHe6R0QhAs2uZc=
=PeP/
-END PGP SIGNATURE-

Bug#1069128: haskell-aeson: FTBFS from source - out of memory in SomeType2ElemArray test

[John David Anglin]

Source: haskell-aeson
Version: 2.1.2.1-5
Severity: normal
Tags: ftbfs

Dear Maintainer,

Build fails here:
ApproxDefault:  OK (0.03s)
  +++ OK, passed 100 tests.
SomeType2ElemArray: 
aeson-tests: out of memory (requested 2097152 bytes)
Test suite aeson-tests: FAIL
Test suite logged to: dist-ghc/test/aeson-2.1.2.1-aeson-tests.log
0 of 1 test suites (0 of 1 test cases) passed.
-e: error: debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct 
returned exit code 1
 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 875.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup test 
--builddir=dist-ghc --show-details"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 614
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup test 
--builddir=dist-ghc --show-details"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 477
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "test", 
"--builddir=dist-ghc", "--show-details=direct") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 692
Debian::Debhelper::Buildsystem::Haskell::Recipes::check_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:163: check-ghc-stamp] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=haskell-aeson=hppa=2.1.2.1-5%2Bb1=1713288523=0

Regards,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Bug#1068868: ITP: python3-pyzmq -- Python bindings for 0MQ

[Gordon Ball]

On 12/04/2024 15:35, Cody Scott wrote:

Package: wnpp
Severity: wishlist
Owner: Cody Scott 
X-Debbugs-Cc: debian-de...@lists.debian.org, cody.sc...@giatec.ca

* Package name: python3-pyzmq
   Version : 25.1.2
   Upstream Contact: ZeroMQ 
* URL : https://pyzmq.readthedocs.io/en/latest/
* License : BSD
   Programming Lang: Python
   Description : Python bindings for 0MQ


This will be used by Python applications that use ZeroMQ.

There doesn't appear to be any other Python bindings for ZeroMQ.

I plan to maintain it and I'm looking for a sponsor.



I believe this is already packaged - see 
https://tracker.debian.org/pkg/pyzmq


Gordon

Bug#1069127: python-idna: CVE-2024-3651

[Salvatore Bonaccorso]

Source: python-idna
Version: 3.6-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-idna.

CVE-2024-3651[0]:
| potential DoS via resource consumption via specially crafted inputs to
| idna.encode()


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-3651
https://www.cve.org/CVERecord?id=CVE-2024-3651
[1] https://github.com/kjd/idna/security/advisories/GHSA-jjg7-2v4v-x38h

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1069072: new upstream (0.36)

[Martijn van Brummelen]

Hi Daniel,

On 2024-04-15 22:03, Daniel Baumann wrote:

Package: nwipe

Hi,

it would be nice if you could upload the current nwipe release to 
Debian.


Thanks just uploaded a new version(0.36)

Kind regards,
Martijn van Brummelen

Bug#1068997: mailtextbody: feature request: optionally specify MIME type to extract (default: text/plain)

[gregor herrmann]

On Sun, 14 Apr 2024 21:38:08 +0200, Jonas Smedegaard wrote:

> What a neat little tool.  I have needed this many times over the years.

Thanks!

> One thing that I would want, which seems within the scope of this tiny
> tool: An option to specify which MIME type to look for, with default
> being the currently hardcoded text/plain.

Nice idea, expect a new release + upload soon :)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1069126: gunicorn: CVE-2024-1135

[Salvatore Bonaccorso]

Source: gunicorn
Version: 20.1.0-6
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gunicorn.

CVE-2024-1135[0]:
| Gunicorn fails to properly validate Transfer-Encoding headers,
| leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting
| requests with conflicting Transfer-Encoding headers, attackers can
| bypass security restrictions and access restricted endpoints. This
| issue is due to Gunicorn's handling of Transfer-Encoding headers,
| where it incorrectly processes requests with multiple, conflicting
| Transfer-Encoding headers, treating them as chunked regardless of
| the final encoding specified. This vulnerability allows for a range
| of attacks including cache poisoning, session manipulation, and data
| exposure.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-1135
https://www.cve.org/CVERecord?id=CVE-2024-1135
[1] https://huntr.com/bounties/22158e34-cfd5-41ad-97e0-a780773d96c1
[2] 
https://github.com/benoitc/gunicorn/commit/ac29c9b0a758d21f1e0fb3b3457239e523fa9f1d

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1069125: zfs-dkms: Update stable version to fix data corruption bug

[E Harris]

Package: zfs-dkms
Version: 2.1.11-1
Severity: important
Tags: upstream

OpenZFS version 2.1.14 (or later) contains an important data corruption
bugfix for prior versions.  Since stable still has 2.1.11, it would seem
that upgrading the zfs version to 2.1.14 or latest 2.1.15 is warranted?

See release notes here: https://github.com/openzfs/zfs/releases

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

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

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  dkms   3.0.10-8+deb12u1
ii  file   1:5.44-3
ii  libc6-dev [libc-dev]   2.36-9+deb12u4
ii  libpython3-stdlib  3.11.2-1+b1
ii  lsb-release12.0-1
ii  perl   5.36.0-7+deb12u1
ii  python3-distutils  3.11.2-3

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  6.1.85-1
ii  zfs-zed 2.1.11-1
ii  zfsutils-linux  2.1.11-1

Versions of packages zfs-dkms suggests:
ii  debhelper  13.11.4

-- debconf-show failed

Bug#1069124: RFP: tenacity -- easy-to-use, privacy-friendly, multi-track audio editor and recorder, based on Audacity

[Maxime Silvier]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: maxim.7x...@simplelogin.fr

* Package name: tenacity
  Version : 1.3.3
  Upstream Contact: tenacityteam <~tenacity/tenacity-disc...@lists.sr.ht>
* URL : https://tenacityaudio.org/
* VCS : https://codeberg.org/tenacityteam/tenacity
* License : GNU GPL Version 2
  Programming Lang: C++, C (mainly, with less than 10% for Common Lisp, CMake, 
Python, etc.)
  Description : easy-to-use, privacy-friendly, multi-track audio editor and 
recorder, based on Audacity

Tenacity is based on Audacity's code (version 3.0.X). It was created in 
response to controversy surrounding Muse Group's acquisition of Audacity and 
their addition of opt-in telemetry. Since then, Tenacity has merged with two 
other forks (Saucedacity and Audacium) and is now the most actively developed 
fork.

The latest stable release was issued in November 2023. Tenacity is diverging 
further from the original software, while Muse Group is trying to integrate 
Audacity more closely with their other products.

As a result, it may be worth creating an official Debian package for Tenacity 
in the future. The developers behind Tenacity—which I am not part of—have also 
expressed interest in working with Linux distribution packagers.

Bug#1014987: netsurf: FTBFS on the Hurd - refresh patch

[João]

X-Debbugs-CC: debian-h...@lists.debian.org

Dear Maintainer,

Refreshing the patch fixing the FTBFS on the hurd to version 3.11 of netsurf.

I don't know if the framebuffer package should be built on the hurd. With the
attached patch the package builds, but when I try to run the program with the
SDL frontend, it crashes. But perhaps it is not expected to work.
In any case that would be the case for a separate bug report.

Many thanks,
João
--- netsurf-3.11.orig/netsurf/frontends/framebuffer/fetch.c
+++ netsurf-3.11/netsurf/frontends/framebuffer/fetch.c
@@ -48,13 +48,16 @@
  */
 static nsurl *get_resource_url(const char *path)
 {
-	char buf[PATH_MAX];
+	char *buf = NULL;
 	nsurl *url = NULL;
 
 	if (strcmp(path, "favicon.ico") == 0)
 		path = "favicon.png";
 
-	netsurf_path_to_nsurl(filepath_sfind(respaths, buf, path), );
+	buf = filepath_find(respaths, path);
+	netsurf_path_to_nsurl(buf, );
+ 
+	free(buf);
 
 	return url;
 }
--- netsurf-3.11.orig/netsurf/frontends/framebuffer/font_freetype.c
+++ netsurf-3.11/netsurf/frontends/framebuffer/font_freetype.c
@@ -120,15 +120,16 @@ fb_new_face(const char *option, const ch
 fb_faceid_t *newf;
 FT_Error error;
 FT_Face aface;
-	char buf[PATH_MAX];
+	char *buf = NULL;
 
 newf = calloc(1, sizeof(fb_faceid_t));
 
 if (option != NULL) {
 newf->fontfile = strdup(option);
 } else {
-		filepath_sfind(respaths, buf, fontname);
+		buf = filepath_find(respaths, fontname);
 newf->fontfile = strdup(buf);
+		free(buf);
 }
 
 error = FTC_Manager_LookupFace(ft_cmanager, (FTC_FaceID)newf, );
--- netsurf-3.11.orig/netsurf/frontends/gtk/fetch.c
+++ netsurf-3.11/netsurf/frontends/gtk/fetch.c
@@ -250,14 +250,16 @@ const char *fetch_filetype(const char *u
 
 static nsurl *nsgtk_get_resource_url(const char *path)
 {
-	char buf[PATH_MAX];
+	char *buf = NULL;
 	nsurl *url = NULL;
 
 	/* favicon.ico -> favicon.png */
 	if (strcmp(path, "favicon.ico") == 0) {
 		nsurl_create("resource:favicon.png", );
 	} else {
-		netsurf_path_to_nsurl(filepath_sfind(respaths, buf, path), );
+		buf = filepath_find(respaths, path);
+		netsurf_path_to_nsurl(buf, );
+		free(buf);
 	}
 
 	return url;
--- netsurf-3.11.orig/netsurf/frontends/gtk/gui.c
+++ netsurf-3.11/netsurf/frontends/gtk/gui.c
@@ -909,8 +909,8 @@ static nserror nsgtk_add_named_icons_to_
  */
 static nserror nsgtk_setup(int argc, char** argv, char **respath)
 {
-	char buf[PATH_MAX];
-	char *resource_filename;
+	char *buf = NULL;
+	char *resource_filename = NULL;
 	char *addr = NULL;
 	nsurl *url;
 	nserror res;
@@ -986,8 +986,9 @@ static nserror nsgtk_setup(int argc, cha
 		.pma = true,
 	});
 
-	filepath_sfinddef(respath, buf, "mime.types", "/etc/");
+	buf = filepath_sfinddef(respath, "mime.types", "/etc/");
 	gtk_fetch_filetype_init(buf);
+	free(buf);
 
 	save_complete_init();
 
--- netsurf-3.11.orig/netsurf/frontends/monkey/fetch.c
+++ netsurf-3.11/netsurf/frontends/monkey/fetch.c
@@ -36,10 +36,12 @@ extern char **respaths;
 
 static nsurl *gui_get_resource_url(const char *path)
 {
-	char buf[PATH_MAX];
+	char *buf = NULL;
 	nsurl *url = NULL;
 
-	netsurf_path_to_nsurl(filepath_sfind(respaths, buf, path), );
+	buf = filepath_find(respaths, path);
+	netsurf_path_to_nsurl(buf, );
+	free(buf);
 
 	return url;
 }
--- netsurf-3.11.orig/netsurf/frontends/monkey/main.c
+++ netsurf-3.11/netsurf/frontends/monkey/main.c
@@ -390,7 +390,7 @@ main(int argc, char **argv)
 {
 	char *messages;
 	char *options;
-	char buf[PATH_MAX];
+	char *buf = NULL;
 	nserror ret;
 	struct netsurf_table monkey_table = {
 		.misc = _misc_table,
@@ -452,8 +452,9 @@ main(int argc, char **argv)
 		die("NetSurf failed to initialise");
 	}
 
-	filepath_sfinddef(respaths, buf, "mime.types", "/etc/");
+	buf = filepath_sfinddef(respaths, "mime.types", "/etc/");
 	monkey_fetch_filetype_init(buf);
+	free(buf);
 
 	urldb_load(nsoption_charp(url_file));
 	urldb_load_cookies(nsoption_charp(cookie_file));
--- netsurf-3.11.orig/netsurf/frontends/windows/fetch.c
+++ netsurf-3.11/netsurf/frontends/windows/fetch.c
@@ -76,10 +76,12 @@ static const char *fetch_filetype(const
  */
 static nsurl *nsw32_get_resource_url(const char *path)
 {
-	char buf[PATH_MAX];
+	char *buf = NULL;
 	nsurl *url = NULL;
 
-	netsurf_path_to_nsurl(filepath_sfind(G_resource_pathv, buf, path), );
+	buf = filepath_find(G_resource_pathv, path);
+	netsurf_path_to_nsurl(buf, );
+	free(buf);
 
 	return url;
 }
--- netsurf-3.11.orig/netsurf/frontends/windows/main.c
+++ netsurf-3.11/netsurf/frontends/windows/main.c
@@ -171,12 +171,13 @@ static nserror set_defaults(struct nsopt
 	DWORD buf_bytes_size = sizeof(TCHAR) * buf_tchar_size;
 	char *ptr = NULL;
 	char *buf;
+	char *buftest;
 	char *fname;
 	HRESULT hres;
 	char dldir[] = "Downloads";
 
 	buf = malloc(buf_bytes_size);
-	if (buf== NULL) {
+	if (buf == NULL) {
 		return NSERROR_NOMEM;
 	}
 	buf[0] = '\0';
@@ -191,8 +192,9 @@ static nserror set_defaults(struct nsopt
 	if 

Bug#1069048: All NICs tried with same retries and timeouts?

[Narcis Garcia]

"the first NIC that gets an IP address from DHCP will be used"

You mean second NIC that gets IP too, right?
And also third one, yes?
And if ten NICs get IP configuration from DHCP, they all will be 
configured; yes?


"All NICs will be tried one by one, with the default 15 seconds timeout"

You mean all NICs will be tried although first one succeeded already, am 
I right?


--

Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should remove and omit any @, dot and mailto combinations against 
automated addresses collectors.

Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

[Roland Rosenfeld]

Hi Salvatore and Diederik!

On Di, 16 Apr 2024, Salvatore Bonaccorso wrote:

> If you revert that commit, does that fix your issue? Note that it
> opens up again as well the referenced issue, but it would be helpfull
> for reporting as regression if we know that's the case.

Thanks to the support by Diederik, I was able to build a new kernel
with the two patches reverted and this kernel solves the issue and
uses the correct MAC and renames the interface to enx as before
instead of using a random MAC and using eth0 as the inerface name.

On Di, 16 Apr 2024, Diederik de Haas wrote:

> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
> describes a procedure with which you can apply (the attached) patches

Thanks for this hint and pointing to the perfect chapter, which made
building a test kernel really easy.

I used the two patches, that you suggested, they are exactly the
reverse of the two problem patches, that lead us to this issue.

Greetings
Roland

Bug#1069123: RM: libreoffice != 24.3/experimental [armhf ppc64el s390x mips64el riscv64] -- ROM, NVIU; obsolete cruft

[Rene Engelhard]

Package: ftp.debian.org

Hi,

The following packages are cruft:

$ rmadison -s experimental -S libreoffice | grep -v 24\.2\.3
fonts-opensymbol | 4:102.12+LibO7.5.4~rc2-1  | 
experimental | all
fonts-opensymbol | 4:102.12+LibO7.5.5~rc1-2  | 
experimental | all
fonts-opensymbol | 4:102.12+LibO7.6.3~rc2-1  | 
experimental | all
fonts-opensymbol | 4:102.12+LibO24.2.0~rc2-1 | 
experimental | all
fonts-opensymbol | 4:102.12+LibO24.2.1~rc2-1 | 
experimental | all
gir1.2-lokdocview-0.1| 4:7.5.4~rc2-1 | 
experimental | mips64el
gir1.2-lokdocview-0.1| 4:24.2.1~rc2-1| 
experimental | riscv64
liblibreoffice-java  | 4:7.5.4~rc2-1 | 
experimental | all
liblibreoffice-java  | 4:7.5.5~rc1-2 | 
experimental | all
liblibreoffice-java  | 4:7.6.3~rc2-1 | 
experimental | all
liblibreoffice-java  | 4:24.2.0~rc2-1| 
experimental | all
liblibreoffice-java  | 4:24.2.1~rc2-1| 
experimental | all
liblibreofficekitgtk | 4:7.5.4~rc2-1 | 
experimental | mips64el
liblibreofficekitgtk | 4:24.2.1~rc2-1| 
experimental | riscv64
libofficebean-java   | 4:7.5.4~rc2-1 | 
experimental | mips64el
libofficebean-java   | 4:7.5.5~rc1-2 | 
experimental | armhf, ppc64el, s390x
libofficebean-java   | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice  | 4:7.5.4~rc2-1 | 
experimental | source, mips64el
libreoffice  | 4:7.5.5~rc1-2 | 
experimental | source
libreoffice  | 4:7.6.3~rc2-1 | 
experimental | source
libreoffice  | 4:24.2.0~rc2-1| 
experimental | source
libreoffice  | 4:24.2.1~rc2-1| 
experimental | source, riscv64
libreoffice-base | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-base | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-base-core| 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-base-core| 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-base-drivers | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-base-drivers | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-calc | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-calc | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-common   | 4:7.5.4~rc2-1 | 
experimental | all
libreoffice-common   | 4:7.5.5~rc1-2 | 
experimental | all
libreoffice-common   | 4:7.6.3~rc2-1 | 
experimental | all
libreoffice-common   | 4:24.2.0~rc2-1| 
experimental | all
libreoffice-common   | 4:24.2.1~rc2-1| 
experimental | all
libreoffice-core | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-core | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-dev  | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-dev  | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-dev-common   | 4:7.5.4~rc2-1 | 
experimental | all
libreoffice-dev-common   | 4:7.5.5~rc1-2 | 
experimental | all
libreoffice-dev-common   | 4:7.6.3~rc2-1 | 
experimental | all
libreoffice-dev-common   | 4:24.2.0~rc2-1| 
experimental | all
libreoffice-dev-common   | 4:24.2.1~rc2-1| 
experimental | all
libreoffice-dev-doc  | 4:7.5.4~rc2-1 | 
experimental | all
libreoffice-dev-doc  | 4:7.5.5~rc1-2 | 
experimental | all
libreoffice-dev-doc  | 4:7.6.3~rc2-1 | 
experimental | all
libreoffice-dev-doc  | 4:24.2.0~rc2-1| 
experimental | all
libreoffice-dev-doc  | 4:24.2.1~rc2-1| 
experimental | all
libreoffice-dev-gui  | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-dev-gui  | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-draw | 4:7.5.4~rc2-1 | 
experimental | mips64el
libreoffice-draw | 4:24.2.1~rc2-1| 
experimental | riscv64
libreoffice-evolution| 4:7.5.4~rc2-1 | 
experimental | mips64el

Bug#1069122: RM: sambamba [armhf i386] -- ROM; Does not build on 32bit architectures any more

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: samba...@packages.debian.org, 1067...@bugs.debian.org
Control: affects -1 + src:sambamba
User: ftp.debian@packages.debian.org
Usertags: remove


Hi,

sambamba does not build on i386 architectures any more and also
has no practical relevance on those architectures use case wise.
I'll upload it Build-Depending from
   architecture-is-64-bit, architecture-is-little-endian
soon to reflect this fact.

Kind regards
   Andreas.

Bug#1069121: RM: libuno-sal3 libuno-cppu3 ibuno-salhelpergcc3-3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 -- ROM, NBS; obsolete cruft pre-t64

[Rene Engelhard]

Package: ftp.debian.org


Hi,


please remove

rene@frodo:~$ rmadison -s unstable libuno-sal3 libuno-cppu3 
libuno-salhelpergcc3-3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3
libuno-cppu3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, armhf, i386, 
ppc64el, s390x
libuno-cppuhelpergcc3-3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, 
armhf, i386, ppc64el, s390x
libuno-purpenvhelpergcc3-3 | 4:24.2.0-1 | unstable | amd64, arm64, 
armel, armhf, i386, ppc64el, s390x
libuno-sal3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, armhf, i386, 
ppc64el, s390x
libuno-salhelpergcc3-3 | 4:24.2.0-1 | unstable | amd64, arm64, armel, 
armhf, i386, ppc64el, s390x


on all those archs, they all have been renamed for t64. No idea why the 
auto-decrufter doesn't pick it up.


That also makes it possible to remove this cruft:

$ rmadison -s unstable -S libreoffice | grep 24\.2\.0
fonts-opensymbol | 4:102.12+LibO24.2.0-1 | unstable | all
liblibreoffice-java | 4:24.2.0-1 | unstable | all
libreoffice | 4:24.2.0-1 | unstable | source
libreoffice-common | 4:24.2.0-1 | unstable | all
libreoffice-dev-common | 4:24.2.0-1 | unstable | all
libreoffice-dev-doc | 4:24.2.0-1 | unstable | all
libreoffice-help-ca | 4:24.2.0-1 | unstable | all
libreoffice-help-common | 4:24.2.0-1 | unstable | all
libreoffice-help-cs | 4:24.2.0-1 | unstable | all
libreoffice-help-da | 4:24.2.0-1 | unstable | all
libreoffice-help-de | 4:24.2.0-1 | unstable | all
libreoffice-help-dz | 4:24.2.0-1 | unstable | all
libreoffice-help-el | 4:24.2.0-1 | unstable | all
libreoffice-help-en-gb | 4:24.2.0-1 | unstable | all
libreoffice-help-en-us | 4:24.2.0-1 | unstable | all
libreoffice-help-es | 4:24.2.0-1 | unstable | all
libreoffice-help-et | 4:24.2.0-1 | unstable | all
libreoffice-help-eu | 4:24.2.0-1 | unstable | all
libreoffice-help-fi | 4:24.2.0-1 | unstable | all
libreoffice-help-fr | 4:24.2.0-1 | unstable | all
libreoffice-help-gl | 4:24.2.0-1 | unstable | all
libreoffice-help-hi | 4:24.2.0-1 | unstable | all
libreoffice-help-hu | 4:24.2.0-1 | unstable | all
libreoffice-help-id | 4:24.2.0-1 | unstable | all
libreoffice-help-it | 4:24.2.0-1 | unstable | all
libreoffice-help-ja | 4:24.2.0-1 | unstable | all
libreoffice-help-km | 4:24.2.0-1 | unstable | all
libreoffice-help-ko | 4:24.2.0-1 | unstable | all
libreoffice-help-nl | 4:24.2.0-1 | unstable | all
libreoffice-help-om | 4:24.2.0-1 | unstable | all
libreoffice-help-pl | 4:24.2.0-1 | unstable | all
libreoffice-help-pt | 4:24.2.0-1 | unstable | all
libreoffice-help-pt-br | 4:24.2.0-1 | unstable | all
libreoffice-help-ru | 4:24.2.0-1 | unstable | all
libreoffice-help-sk | 4:24.2.0-1 | unstable | all
libreoffice-help-sl | 4:24.2.0-1 | unstable | all
libreoffice-help-sv | 4:24.2.0-1 | unstable | all
libreoffice-help-tr | 4:24.2.0-1 | unstable | all
libreoffice-help-vi | 4:24.2.0-1 | unstable | all
libreoffice-help-zh-cn | 4:24.2.0-1 | unstable | all
libreoffice-help-zh-tw | 4:24.2.0-1 | unstable | all
libreoffice-java-common | 4:24.2.0-1 | unstable | all
libreoffice-l10n-af | 4:24.2.0-1 | unstable | all
libreoffice-l10n-am | 4:24.2.0-1 | unstable | all
libreoffice-l10n-ar | 4:24.2.0-1 | unstable | all
libreoffice-l10n-as | 4:24.2.0-1 | unstable | all
libreoffice-l10n-ast | 4:24.2.0-1 | unstable | all
libreoffice-l10n-be | 4:24.2.0-1 | unstable | all
libreoffice-l10n-bg | 4:24.2.0-1 | unstable | all
libreoffice-l10n-bn | 4:24.2.0-1 | unstable | all
libreoffice-l10n-br | 4:24.2.0-1 | unstable | all
libreoffice-l10n-bs | 4:24.2.0-1 | unstable | all
libreoffice-l10n-ca | 4:24.2.0-1 | unstable | all
libreoffice-l10n-cs | 4:24.2.0-1 | unstable | all
libreoffice-l10n-cy | 4:24.2.0-1 | unstable | all
libreoffice-l10n-da | 4:24.2.0-1 | unstable | all
libreoffice-l10n-de | 4:24.2.0-1 | unstable | all
libreoffice-l10n-dz | 4:24.2.0-1 | unstable | all
libreoffice-l10n-el | 4:24.2.0-1 | unstable | all
libreoffice-l10n-en-gb | 4:24.2.0-1 | unstable | all
libreoffice-l10n-en-za | 4:24.2.0-1 | unstable | all
libreoffice-l10n-eo | 4:24.2.0-1 | unstable | all
libreoffice-l10n-es | 4:24.2.0-1 | unstable | all
libreoffice-l10n-et | 4:24.2.0-1 | unstable | all
libreoffice-l10n-eu | 4:24.2.0-1 | unstable | all
libreoffice-l10n-fa | 4:24.2.0-1 | unstable | all
libreoffice-l10n-fi | 4:24.2.0-1 | unstable | all
libreoffice-l10n-fr | 4:24.2.0-1 | unstable | all
libreoffice-l10n-ga | 4:24.2.0-1 | unstable | all
libreoffice-l10n-gd | 4:24.2.0-1 | unstable | all
libreoffice-l10n-gl | 4:24.2.0-1 | unstable | all
libreoffice-l10n-gu | 4:24.2.0-1 | unstable | all
libreoffice-l10n-gug | 4:24.2.0-1 | unstable | all
libreoffice-l10n-he | 4:24.2.0-1 | unstable | all
libreoffice-l10n-hi | 4:24.2.0-1 | unstable | all
libreoffice-l10n-hr | 4:24.2.0-1 | unstable | all
libreoffice-l10n-hu | 4:24.2.0-1 | unstable | all
libreoffice-l10n-id | 4:24.2.0-1 | unstable | all
libreoffice-l10n-in | 4:24.2.0-1 | unstable | all
libreoffice-l10n-is | 4:24.2.0-1 | unstable | all
libreoffice-l10n-it | 4:24.2.0-1 | unstable | all
libreoffice-l10n-ja | 4:24.2.0-1 

Bug#1069120: RM: ure-java libofficebean-java libreoffice-sdbc-hsqldb libreoffice-report-builder libreoffice-report-builder-bin [armhf ppc64el s390x] -- ROM, ANAIS; obsolete cruft

[Rene Engelhard]

Package: ftp.debian.org


Hi,


The following packages have been ANAIS for loong (sincd 7.6.x times.).


$ rmadison -s unstable ure-java libofficebean-java 
libreoffice-sdbc-hsqldb libreoffice-report-builder 
libreoffice-report-builder-bin | grep -v 24

libofficebean-java | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x
libreoffice-report-builder | 4:7.5.9~rc1-1 | unstable | all
libreoffice-report-builder-bin | 4:7.5.9~rc1-1 | unstable | armhf, 
ppc64el, s390x

libreoffice-sdbc-hsqldb | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x
ure-java | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x

but apparently are not recognized by the auto-cruft. Keeping all this 
*load of obsolete packages in sid:


$ rmadison -s unstable -S libreoffice | grep -v 24\.2
fonts-opensymbol | 4:102.12+LibO7.5.9~rc1-1 | unstable | all
liblibreoffice-java | 4:7.5.9~rc1-1 | unstable | all
libofficebean-java | 4:7.5.9~rc1-1 | unstable | armhf, ppc64el, s390x
libreoffice | 4:7.5.9~rc1-1 | unstable | source
libreoffice-common | 4:7.5.9~rc1-1 | unstable | all
libreoffice-dev-common | 4:7.5.9~rc1-1 | unstable | all
libreoffice-dev-doc | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-ca | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-common | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-cs | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-da | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-de | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-dz | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-el | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-en-gb | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-en-us | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-es | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-et | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-eu | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-fi | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-fr | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-gl | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-hi | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-hu | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-id | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-it | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-ja | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-km | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-ko | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-nl | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-om | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-pl | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-pt | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-pt-br | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-ru | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-sk | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-sl | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-sv | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-tr | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-vi | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-zh-cn | 4:7.5.9~rc1-1 | unstable | all
libreoffice-help-zh-tw | 4:7.5.9~rc1-1 | unstable | all
libreoffice-java-common | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-af | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-am | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-ar | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-as | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-ast | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-be | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-bg | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-bn | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-br | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-bs | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-ca | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-cs | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-cy | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-da | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-de | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-dz | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-el | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-en-gb | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-en-za | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-eo | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-es | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-et | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-eu | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-fa | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-fi | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-fr | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-ga | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-gd | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-gl | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-gu | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-gug | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-he | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-hi | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-hr | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-hu | 4:7.5.9~rc1-1 | unstable | all
libreoffice-l10n-id | 4:7.5.9~rc1-1 | 

Bug#1069119: gpsshogi: EPL missing from debian/copyright

[Bastian Germann]

Source: gpsshogi
Version: 0.7.0-3.1
Severity: serious

The EPL-1 that is mentioned in d/copyright is not included in that file with 
the complete text.
A copy is included in debian/epl-v10.txt. Please include it in d/copyright.

Bug#1061661: python3-tables-lib [s390x] -- RoM ANAIS

[Antonio Valentino]

Dear Paul,

On Tue, 27 Feb 2024 19:56:21 +0100 Paul Gevers  wrote:

Hi all,

On Sun, 28 Jan 2024 10:52:38 +0100 Antonio Valentino 
 wrote:

> Package: python3-tables-lib

This bug would need to be reassigned to the ftp.debian.org pseudo 
package to actually do anything.


> Version: 3.9.2-1
> Severity: normal
> Tags: ftbfs
> X-Debbugs-Cc: antonio.valent...@tiscali.it
> 
> Dear Maintainer,

> the new upstream version of pytables, v3.9.2, depends on c-blosc2
> that is not abailable on s390x.
> Removing the python3-tables-lib binary package from s390x/unstable
> should allow to pytables v3.9.2 to migrate into testing.

Indeed. If nothing happens soon, I'll file an out-of-sync bug report 
which would lead to autoremoval starting.


Paul


any news on this issue?
Is there still something missing on my side?

kind regards
--
Antonio Valentino

Bug#1059665: ITP: pandoc-filter-diagram -- Pandoc filter to render diagram in Markdown code sections as SVG

[Jonas Smedegaard]

Release 0.2.1 is uploaded and has been in NEW queue since 2024-02-23,
awaiting ftp-master inspection and (hopeful) approval.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1064762: Upstream has an incoming fix

[Markus Blatt]

Hi,

seems like upstream already has a proposed fix, see [1]

Best,

Markus

[1] https://gitlab.kitware.com/vtk/vtk/-/issues/19258#note_1510307

Bug#1068467: libgl1-mesa-dri: GPU hangs and resets while playing 3D games on Framework Laptop 13, AMD Ryzen 7640U

[Ivan Stanton]

On Fri, 05 Apr 2024 11:36:32 -0600 Ivan Stanton  
wrote:
> Package: libgl1-mesa-dri
> Version: 23.3.5-1
> Severity: important
> 
> Dear Maintainer,
> 
> I and some others have been unable to play 3D games or run GPU-intensive
> software on the Framework Laptop 13 AMD 7040 Edition due to GPU resets
> occurring while doing so. I've previously reported this to the Framework
> Community forums:
> 
> https://community.frame.work/t/solved-debian-12-on-laptop-13-ryzen-7640u-gpu-hangs-in-some-games/
> 
> And others have reported similar issues:
> 
> https://community.frame.work/t/vram-is-lost-due-to-gpu-reset-followed-by-a-crash/
> 
>* What led up to the situation? I attempted to play the Steam version of
> Garry's Mod. This also occurred with The Stanley Parable: Ultra Deluxe 
> (Steam),
> DSDA Doom (from the Debian repo) and Xonotic (from flathub). All 3D games > 
seem
> to be affected, and possibly other GPU-intensive applications.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? I first encountered this bug on bookworm, with mesa
> 22.3.6-1+deb12u1. Upgrading linux-firmware, both from upstream and from
> testing, had no effect. Upgrading the kernel from backports had no effect.
> Upgrading mesa, using the packages from trixie, made the crashes less  
frequent
> but did not resolve the issue. After some A/B testing, the crash seems to be
> resolved only by both upgrading mesa and setting the kernel parameter
> amdgpu.sg_display=0, which judging by the kernel documentation, I should not
> have to set unless there is a bug. It would also be nice to get this fixed 
for
> Debian Stable users, if possible.
>* What was the outcome of this action? A few seconds into the game, the
> display froze (though audio kept playing). After a few seconds, it flickered
> and the graphics became partially corrupted. About a minute later, I was 
> kicked to the login screen.
>* What outcome did you expect instead? Game continues playing without any
> graphical glitches or freezes.
> 
> I'm not an expert on the GNU/Linux graphics stack and I haven't reported a 
bug 
> to Debian in a while, so apologies if I got something wrong.
> 
> Here's an extract of dmesg from one occurrence of the bug:
> 
> [   62.824231] amdgpu :c1:00.0: amdgpu: [gfxhub] page fault (src_id:0
> ring:24 vmid:6 pasid:32787, for process dsda-doom pid 2910 thread dsda-
> doom:cs0
> pid 2926)
> [   62.824267] amdgpu :c1:00.0: amdgpu:   in page starting at address
> 0x00409b40c000 from client 10
> [   62.824285] amdgpu :c1:00.0: amdgpu:
> GCVM_L2_PROTECTION_FAULT_STATUS:0x00601030
> [   62.824297] amdgpu :c1:00.0: amdgpu:  Faulty UTCL2 client ID: TCP
> (0x8)
> [   62.824310] amdgpu :c1:00.0: amdgpu:  MORE_FAULTS: 0x0
> [   62.824321] amdgpu :c1:00.0: amdgpu:  WALKER_ERROR: 0x0
> [   62.824331] amdgpu :c1:00.0: amdgpu:  PERMISSION_FAULTS: 0x3
> [   62.824340] amdgpu :c1:00.0: amdgpu:  MAPPING_ERROR: 0x0
> [   62.824349] amdgpu :c1:00.0: amdgpu:  RW: 0x0
> [   72.941268] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0

I haven't been able to replicate this exact behavior since upgrading to 
Framework's BIOS version 3.05b and disabling all of my previous workarounds, 
but I did get this log from a regular app crash that was similar:

[75883.804346] amdgpu :c1:00.0: amdgpu: [gfxhub] page fault (src_id:0 
ring:24 vmid:2 pasid:32807, for process Discord pid 8547 thread Discord:cs0 
pid 8579)
[75883.804356] amdgpu :c1:00.0: amdgpu:   in page starting at address 
0x4d023e345000 from client 10
[75883.804359] amdgpu :c1:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:
0x00201430
[75883.804361] amdgpu :c1:00.0: amdgpu:  Faulty UTCL2 client ID: SQC 
(data) (0xa)
[75883.804363] amdgpu :c1:00.0: amdgpu:  MORE_FAULTS: 0x0
[75883.804365] amdgpu :c1:00.0: amdgpu:  WALKER_ERROR: 0x0
[75883.804368] amdgpu :c1:00.0: amdgpu:  PERMISSION_FAULTS: 0x3
[75883.804370] amdgpu :c1:00.0: amdgpu:  MAPPING_ERROR: 0x0
[75883.804371] amdgpu :c1:00.0: amdgpu:  RW: 0x0
[75893.925804] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 
timeout, but soft recovered

In this case, KWin reloaded due to a graphics reset, instead of logging me 
out, and I did not experience freezing.

Bug#1064730: stdgpu: FTBFS: type_traits.h:736:1: error: expected type-specifier before ‘template’

[Gianfranco Costamagna]

On Tue, 16 Apr 2024 15:40:12 +0200 Timo =?utf-8?Q?R=C3=B6hling?= 
 wrote:

* Gianfranco Costamagna  [2024-04-16 09:06]:
>I agree with Cory, to me looks also a regression in thrust
>
>I'm trying some hacky patch, lets see
>
>Description: Reintroduce fallback lost in 
https://github.com/ROCm/rocThrust/commit/2b80e29803d60f01701a67bc57ef06dacfe8af8b
>Author: Gianfranco Costamagna 
>Last-Update: 2024-04-16
>
>--- rocthrust-5.7.1.orig/thrust/detail/type_traits.h
>+++ rocthrust-5.7.1/thrust/detail/type_traits.h
>@@ -731,6 +731,8 @@ using invoke_result_t =
> #else // 2017+
>   ::cuda::std::invoke_result_t;
> #endif
>+#else
>+  std::invoke_result_t;
> #endif
>
> template 
>
Thanks for the patch and upstream PR. If that does not pan out, I 
could split stdgpu into two separate (source) packages to have the 
openmp backend built against libthrust-dev. I prefer your solution, 
though.





I would say, we NMU now to unblock the amdgpu transition to time64_t, and then 
we can
split or do whatever you prefer... There is some rush to finish time64_t 
without regressing
the current set of packages...
(whenever possible of course!)

G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064730: rocthrust: diff for NMU version 5.7.1-2.1

[Gianfranco Costamagna]

Control: tags 1064730 + patch
Control: tags 1064730 + pending

Dear maintainer,

I've prepared an NMU for rocthrust (versioned as 5.7.1-2.1) and
uploaded it.

Regards.

diff -Nru rocthrust-5.7.1/debian/changelog rocthrust-5.7.1/debian/changelog
--- rocthrust-5.7.1/debian/changelog2024-03-26 18:40:24.0 +0100
+++ rocthrust-5.7.1/debian/changelog2024-04-16 18:21:04.0 +0200
@@ -1,3 +1,11 @@
+rocthrust (5.7.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Reintroduce fallback in invoke_result with upstream proposed
+and acked patch (Closes: #1064730)
+
+ -- Gianfranco Costamagna   Tue, 16 Apr 2024 
18:21:04 +0200
+
 rocthrust (5.7.1-2) unstable; urgency=medium

   * Migrate to unstable
diff -Nru rocthrust-5.7.1/debian/patches/invoke_result-std.patch 
rocthrust-5.7.1/debian/patches/invoke_result-std.patch
--- rocthrust-5.7.1/debian/patches/invoke_result-std.patch  1970-01-01 
01:00:00.0 +0100
+++ rocthrust-5.7.1/debian/patches/invoke_result-std.patch  2024-04-16 
09:01:08.0 +0200
@@ -0,0 +1,17 @@
+Description: Reintroduce fallback lost in 
https://github.com/ROCm/rocThrust/commit/2b80e29803d60f01701a67bc57ef06dacfe8af8b
+Author: Gianfranco Costamagna 
+Forwarded: https://github.com/ROCm/rocThrust/pull/402
+Bug-Debian: https://bugs.debian.org/1064730
+Last-Update: 2024-04-16
+
+--- rocthrust-5.7.1.orig/thrust/detail/type_traits.h
 rocthrust-5.7.1/thrust/detail/type_traits.h
+@@ -731,6 +731,8 @@ using invoke_result_t =
+ #else // 2017+
+   ::cuda::std::invoke_result_t;
+ #endif
++#else
++  std::invoke_result_t;
+ #endif
+
+ template 


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1062719: bumping qpdf 64-bit time_t for 11.9.0 in experimental

[Adrian Bunk]

On Sat, Feb 24, 2024 at 05:36:53PM -0500, Jay Berkenbilt wrote:
> I need to upload qpdf 11.9.0-1 to unstable. Since this is newer than
> 11.8.0-1.1~exp1 in experimental with the 64-bit time_t NMU, it will
> cause that to disappear. In an effort to avoid that and keep things in
> sync with the time_t transition, I have ported the NMU forward to
> 11.9.0-1 and will upload 11.9.0-2~exp1 with the time_t changes to
> experimental right after I upload 11.9.0-1 to experimental. I am
> hoping that I am not messing anything up with this. Please feel free
> to adjust tags, do a separate NMU, or whatever is needed if I have
> gotten things out of sync. In any case, I want to get 11.9.0-1
> uploaded right away since I'd like it to sync to Ubuntu before the
> 24.04 feature freeze.
>...

It seems the new version of qpdf in experimental was by accident 
uploaded to unstable instead of the old version in unstable?

It doesn't seem to be a problem in any way, just FYI.

cu
Adrian

Bug#1068931: pom.xml version impact

[tsteven4]

Having the wrong version in pom.xml results in the deb having the 
following files incorrectly named:


root@d19edf0ef10b:/app# diff before after
9c9
< -rw-r--r-- root/root    323778 2024-01-05 16:32 
./usr/share/java/dom4j-2.1.1.jar

---
> -rw-r--r-- root/root    323778 2024-01-05 16:32 
./usr/share/java/dom4j-2.1.4.jar

18,19c18,19
< drwxr-xr-x root/root 0 2024-01-05 16:32 
./usr/share/maven-repo/org/dom4j/dom4j/2.1.1/
< -rw-r--r-- root/root  2230 2024-01-05 16:32 
./usr/share/maven-repo/org/dom4j/dom4j/2.1.1/dom4j-2.1.1.pom

---
> drwxr-xr-x root/root 0 2024-01-05 16:32 
./usr/share/maven-repo/org/dom4j/dom4j/2.1.4/
> -rw-r--r-- root/root  2230 2024-01-05 16:32 
./usr/share/maven-repo/org/dom4j/dom4j/2.1.4/dom4j-2.1.4.pom

22,24c22,24
< lrwxrwxrwx root/root 0 2024-01-05 16:32 
./usr/share/java/dom4j.jar -> dom4j-2.1.1.jar
< lrwxrwxrwx root/root 0 2024-01-05 16:32 
./usr/share/maven-repo/org/dom4j/dom4j/2.1.1/dom4j-2.1.1.jar -> 
../../../../../java/dom4j-2.1.1.jar
< lrwxrwxrwx root/root 0 2024-01-05 16:32 
./usr/share/maven-repo/org/dom4j/dom4j/debian/dom4j-debian.jar -> 
../../../../../java/dom4j-2.1.1.jar

---
> lrwxrwxrwx root/root 0 2024-01-05 16:32 
./usr/share/java/dom4j.jar -> dom4j-2.1.4.jar
> lrwxrwxrwx root/root 0 2024-01-05 16:32 
./usr/share/maven-repo/org/dom4j/dom4j/2.1.4/dom4j-2.1.4.jar -> 
../../../../../java/dom4j-2.1.4.jar
> lrwxrwxrwx root/root 0 2024-01-05 16:32 
./usr/share/maven-repo/org/dom4j/dom4j/debian/dom4j-debian.jar -> 
../../../../../java/dom4j-2.1.4.jar


That may be responsible for at least one tool flagging a security 
vulnerability that was fixed in 2.1.3.  Docker scout reports:


CRITICAL    CVE-2020-10683
pkg:maven/org.dom4j/dom4j@2.1.1

9.8

1 image
Yes

2.1.3

Bug#1068890: diffoscope: --hard-timeout option

[Chris Lamb]

Holger Levsen wrote:

> Anyhow, about my --hard-timeout option idea:
>
> my idea of "--hard-timeout $time" is that diffoscope terminates itself 
> after $time, no matter what *and* then re-starts itself with 
> "--max-container-depth 3"

Just to say that I am totally on board with the idea of ensuring we
get _something_ out of diffoscope on tests.reproducible-builds.org.
Way better than 250 timeouts.

However, I think this first iteration of --hard-timeout time has a few
things that would need ironing out first, and potentially make it not
worth implementing:

(1) You suggest it should start again with "--max-container-depth 3",
but it would surely need some syntax (or another option?) to control
that "3" (but for the second time only).

(2) In fact, its easy to imagine that one would want to restart with
other restrictions as well: not just --max-container-depth. For
instance, excluding external commands like readelf and objdump that
you know to be slow.

(3) The output might need some comment saying "this was re-run with
restrictions as we hit a timeout".

(4) My gut feel that it would not be all that great to rely on CPython
to really properly clear up child processes after a certain amount of
time. Although I believe the most reliable top-level description to do
this kind of thing inside CPython is to start a watchdog thread that
sleeps until the timeout and then tries to kill everything, but my
experience of doing anything like this within Python itself is not
great, and essentially always needed something at the process level
outside of it for it to be reliable. A container would be even more
effective, I'm sure.

In other words, I think the best way of achieving the result we want
is, alas, by doing it outside of diffoscope at the level of the
Jenkins. As in, exactly what you describe here:

> Else we could also extend the current code for tests.r-b.o/debian, 
> which currently
> just kills diffoscope after 2h, to then run diffoscope 
> --max-container-depth 3 :)

Is that a massive faff?  :/


Best wishes,

-- 
  o
⬋   ⬊  Chris Lamb
   o o reproducible-builds.org 
⬊   ⬋
  o

Bug#1069048: All NICs tried with same retries and timeouts?

[Thomas Goirand]

Hi,

With my patch, the first NIC that gets an IP address from DHCP will be 
used. All NICs will be tried one by one, with the default 15 seconds 
timeout. The order of NICs stays the same as before, as in: the first 
NIC that gets a link up will be tried first. So there's no regression 
possible.


Cheers,

Thomas Goirand (zigo)

Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi


On Tue, Apr 16, 2024 at 02:17:49PM +0200, Manfred Larcher wrote:
> Package: src:linux
> Version: 6.1.85-1
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> kernel update from version 6.1.0-18 to 6.1.0-20
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> out system mounted a samba share via autofs (cifs) and we tried to access
> some files and directories
> 
>* What was the outcome of this action?
> the mount point of our share is /srv/samba/shares/company and the directory
> it/MIJ had another directory "digitale kommunikation" which did not shop up
> on the computer which mounted the samba share. before the kernel update it
> did and when we renamed the file to "digitale_kommunikation" or to "digitalo
> kommunikation" we could see it.
> in the syslog we found the following messages:
> CIFS: VFS: directory entry name would overflow frame end of buf ...
> we could move that direcotry into another directory and it was useable, we
> created another directory it/abc and created the "digitale kommunikation"
> inside and it was hidden again. after switching back to kernel 6.1.0-20
> everything was ok.
> upgrade to kernel 6.5.0-0.deb12.4-amd64 package was ok too.
> 
>* What outcome did you expect instead?
> we expected to just see the "digitale kommunikation" directory as before.

Can you share details on how the cifs mounts are done? Which mount
options are used?

Were you able to find a minimal reproducing case which would help
debug the issue on non production systems?

Regards,
Salvatore

Bug#1065032: closed by Salvo Tomaselli ()

[Anthony Foglia]

Sorry, I hadn't seen your initial response

I was using the fortune program to show me random Italian quotes to work on 
learning the language. Before I could just point fortune at the folder with all 
the Italian fortunes. That's no longer easy without them in a separate folder.

So in my .bashrc I have

if [[ -x /usr/games/fortune ]]; then
if [[ -d /usr/share/games/fortunes/it ]]; then
/usr/games/fortune /usr/share/games/fortunes/it
elif type dpkg > /dev/null; then
# As of v2, debian's fortunes-it package no longer puts the
# fortunes in a separate directory.
dpkg -L fortunes-it | grep "/usr/share/games/fortunes/" | grep -v \\. | xargs 
-r /usr/games/fortune
fi
fi

The call to dpkg is an obvious kludge. I'm surprised all the debian fortune 
maintainers don't have a convention/best practice around this.

I'm just end-user, so take my opinion/usage with a grain of salt. (To be fair, 
I could just uninstall the other fortune-providing packages.)

Sent with Shortwave 


On Mon Apr 15, 2024, 04:51 PM GMT, Debian Bug Tracking System 
 wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the fortunes-it package:
>
> #1065032: fortunes-it: fortunes/it directory no longer used
>
> It has been closed by Salvo Tomaselli .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Salvo Tomaselli 
>  by
> replying to this email.
>
>
> --
> 1065032: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065032
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#1069094: [debian-mysql] Bug#1069094: mariadb: FTBFS on hurd-i386

[Otto Kekäläinen]

Thanks Svante for the patches!

I will test these next weekend.

Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

[Diederik de Haas]

On Tuesday, 16 April 2024 16:41:46 CEST Roland Rosenfeld wrote:
> A.B says on stackexchange, that both patches have to be reverted to
> make this working again.
> 
> I did not yet try this out myself, because I use precompiled kernels
> for ages and have to re-learn again how to patch and build a kernel.

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
describes a procedure with which you can apply (the attached) patches

HTH>From 21f7e476d0afe832f6656b917b976c6efe6b24f3 Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Tue, 16 Apr 2024 16:53:16 +0200
Subject: [PATCH 1/2] Revert "net: usb: ax88179_178a: avoid the interface
 always configured as random address"

This reverts commit fc77240f6316d17fc58a8881927c3732b1d75d51.
---
 drivers/net/usb/ax88179_178a.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index e0e9b4c53cb0..d837c1887416 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1273,8 +1273,6 @@ static void ax88179_get_mac_addr(struct usbnet *dev)
 
 	if (is_valid_ether_addr(mac)) {
 		eth_hw_addr_set(dev->net, mac);
-		if (!is_local_ether_addr(mac))
-			dev->net->addr_assign_type = NET_ADDR_PERM;
 	} else {
 		netdev_info(dev->net, "invalid MAC address, using random\n");
 		eth_hw_addr_random(dev->net);
-- 
2.43.0

>From 75b1a1f4d80ca93591e7833c0683a651d54edc38 Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Tue, 16 Apr 2024 16:53:36 +0200
Subject: [PATCH 2/2] Revert "net: usb: ax88179_178a: avoid two consecutive
 device resets"

This reverts commit 5c4cbec5106d2f3c055ad138165e60a73f5b355c.
---
 drivers/net/usb/ax88179_178a.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index d837c1887416..5a1bf42ce156 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1315,6 +1315,8 @@ static int ax88179_bind(struct usbnet *dev, struct usb_interface *intf)
 
 	netif_set_tso_max_size(dev->net, 16384);
 
+	ax88179_reset(dev);
+
 	return 0;
 }
 
-- 
2.43.0



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

Bug#1014266: hardinfo: Package new major hardinfo release from https://github.com/hardinfo2/hardinfo2

[Technologijų tinklas]

Please package new major hardinfo release from
https://github.com/hardinfo2/hardinfo2/releases
See more info at https://github.com/hardinfo2/hardinfo2/discussions/16

Upstream added GTK3 support 4 years ago, also lots of other important
improvements:

hardinfo is being rebooted as hardinfo2! Initial homepage with
pictures: https://www.hardinfo2.org/

News:
• GTK3 and Online Benchmarking
• 10 years of small nice changes
• Refreshed

Updates from 2.0.15
• LibSoup3 for distros having libsoup3 - remember to add build dependency
• Command Line Interface improved and added synchronize from CLI
• Minor fixes - deprecated functions, gcc warning, possible never seen crashes
• fixed benchmark stop crash, FFT Benchmark memory leak, Fix rerun
stopped benchmark
• added GPU drawing benchmark - for history and fun - numbers are bogos

Updates from 2.0.12
• Add license LGPL2.1+ and GPL3.0+ for parts of code
• Minor fixes - RiscV isaflags, FC39 manpages, kernel modules sorting,
fix po validation, desktopfile
• Packaging hardinfo2

Updates from 2.0.9pre
• Added define MAINTAINER for distro building
• Minor fixes - json to server was translated, sync window handling, pcie width

Updates from 2.0.7pre
• Updated data and translation for distro release
• Improved synchronize for bandwidth usage and initial usage
• Minor fixes, M4, M5, M9, M12, M16

Updates from 2.0.5pre
• Added Internal network speed benchmark from bp0
• Fixes for debian7, Risc-V
• Minor fixes, M3, M14, M15, L3

Updates from 2.0.3pre
• Minor fixes, M1, M2, M6, M7, M8, L1

Updates from 2.0.1pre
• Keep Packaging name for upgrades in distro
• Minor fixes, M10

Updates from hardinfo 0.6a
• Lots of missing maintenance
• GTK3 now working
• Long overdue PR finally added
• Backports and code stability across 10 years of tools.
• Lots of crashfix
• UI/UX improved
• Packaging system for deb/rpm.
• Benchmarking now works from very slow machines to very fast machines.

Known issues:
M11. Updated results from synchronize not updated without changing
between benchmarks, do a refresh without running benchmark again
M13. Status not updated when running single benchmark

-- 
Prekyba kompiuteriais ir programine įranga - http://tinklas.eu/prekyba
El. paštas: tink...@tinklas.eu
Naudokite laisvą Linux operacinę sistemą savo kompiuteryje - http://baltix.eu
Mantas Kriaučiūnas
Tel.: +370-614-53085
Use Baltix GNU/Linux OS ! http://launchpad.net/baltix

Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

[Roland Rosenfeld]

Hi Salvatore!

On Di, 16 Apr 2024, Salvatore Bonaccorso wrote:

> > Maybe it has to do with the following commit from
> > https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.85
> > 
> > commit fc77240f6316d17fc58a8881927c3732b1d75d51
> > Author: Jose Ignacio Tornos Martinez 
> > Date:   Wed Apr 3 15:21:58 2024 +0200
> > 
> > net: usb: ax88179_178a: avoid the interface always configured as random 
> > address
> > 
> > commit 2e91bb99b9d4f756e92e83c4453f894dda220f09 upstream.
> > 
> > After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two
> > consecutive device resets"), reset is not executed from bind operation 
> > and
> > mac address is not read from the device registers or the devicetree at 
> > that
> > moment. Since the check to configure if the assigned mac address is 
> > random
> > or not for the interface, happens after the bind operation from
> > usbnet_probe, the interface keeps configured as random address, 
> > although the
> > address is correctly read and set during open operation (the only reset
> > now).
> > 
> > In order to keep only one reset for the device and to avoid the 
> > interface
> > always configured as random address, after reset, configure correctly 
> > the
> > suitable field from the driver, if the mac address is read successfully 
> > from
> > the device registers or the devicetree. Take into account if a locally
> > administered address (random) was previously stored.
> > 
> > cc: sta...@vger.kernel.org # 6.6+
> > Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive 
> > device resets")
> > Reported-by: Dave Stevenson  
> > Signed-off-by: Jose Ignacio Tornos Martinez 
> > Reviewed-by: Simon Horman 
> > Link: 
> > https://lore.kernel.org/r/20240403132158.344838-1-jtorn...@redhat.com
> > Signed-off-by: Jakub Kicinski 
> > Signed-off-by: Greg Kroah-Hartman 
> > 
> > Seems, that I'm not alone with this issue, there are also reports in
> > https://www.reddit.com/r/debian/comments/1c304xn/linuximageamd64_61851_usb_link_interface_names/
> > and https://infosec.space/@topher/112276500329020316
> > 
> > 
> > All other (pci based) network interfaces still use there static names
> > (enp0s25, enp2s0, enp3s0), only the usb ethernet name is broken with
> > the new kernel.

> If you revert that commit, does that fix your issue? Note that it
> opens up again as well the referenced issue, but it would be helpfull
> for reporting as regression if we know that's the case.

I didn't try this out myself, but according to
https://unix.stackexchange.com/questions/774594/debian-12-all-of-sudden-my-usb3-lan-adapter-get-assigned-random-mac-address-ea
the root cause comes from the following patch:

https://mirrors.edge.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.77
commit 5c4cbec5106d2f3c055ad138165e60a73f5b355c
Author: Jose Ignacio Tornos Martinez 
Date:   Mon Nov 20 13:11:41 2023 +0100

net: usb: ax88179_178a: avoid two consecutive device resets

[ Upstream commit d2689b6a86b9d23574bd4b654bf770b6034e2c7e ]

The device is always reset two consecutive times (ax88179_reset is called
twice), one from usbnet_probe during the device binding and the other from
usbnet_open.

Remove the non-necessary reset during the device binding and let the reset
operation from open to keep the normal behavior (tested with generic ASIX
Electronics Corp. AX88179 Gigabit Ethernet device).

Reported-by: Herb Wei 
Tested-by: Herb Wei 
Signed-off-by: Jose Ignacio Tornos Martinez 
Link: https://lore.kernel.org/r/20231120121239.54504-1-jtorn...@redhat.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin 


A.B says on stackexchange, that both patches have to be reverted to
make this working again.

I did not yet try this out myself, because I use precompiled kernels
for ages and have to re-learn again how to patch and build a kernel.

Greetings
Roland

Bug#1069117: python3-evtx: evtx_filter_records.py fails to run

[Sudip Mukherjee]

Package: python3-evtx
Version: 0.7.4-1
Severity: normal
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Dear Maintainer,

evtx_filter_records.py fails to run in a Debian unstable docker image with the 
error:

$ evtx_filter_records.py 
Traceback (most recent call last):
  File "/usr/bin/evtx_filter_records.py", line 3, in 
from lxml import etree
ModuleNotFoundError: No module named 'lxml'

It will need a runtime dependency on python3-lxml.

-- 
Regards
Sudip


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

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

Versions of packages python3-evtx depends on:
ii  python3 3.11.8-1
ii  python3-more-itertools  10.2.0-1
ii  python3-pyparsing   3.1.1-1
ii  python3-six 1.16.0-6
ii  python3-zipp1.0.0-6

python3-evtx recommends no packages.

python3-evtx suggests no packages.

Bug#1069116: O: dfc -- display file system usage using graph and colors

[Petter Reinholdtsen]

Package: wnpp
Severity: normal

The current maintainer of dfce, Sabino Par , has
orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: dfc
Version: 3.1.1-1.2
Priority: optional
Section: utils
Maintainer: Sabino Par 
Installed-Size: 130 kB
Depends: libc6 (>= 2.34)
Homepage: https://github.com/rolinh/dfc
Description: display file system usage using graph and colors
 dfc displays file system space usage using graphs and colors. In some ways, it
 is a modernized version of df as it is able to use colors, draw graphs and
 export its output to different formats such as CSV or HTML.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1069115: RFS: libfilezilla/0.47.0-1 -- build high-performing platform-independent programs (runtime lib)

[Phil Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : libfilezilla
   Version  : 0.47.0-1
   Upstream contact : Tim Kosse 
 * URL  : https://lib.filezilla-project.org/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/debian/libfilezilla
   Section  : libs

The source builds the following binary packages:

  libfilezilla-dev - build high-performing platform-independent
programs (development)
  libfilezilla-common - build high-performing platform-independent
programs (translations)
  libfilezilla43t64 - build high-performing platform-independent
programs (runtime lib)

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.47.0-1.dsc

Changes since the last upload:

 libfilezilla (0.47.0-1) unstable; urgency=medium
 .
   * New upstream version 0.47.0.
   * Soname bump rename package to libfilezilla43.
   * 'd/control'.
 - Update 'libgnutls28-dev' required version to minimum of 3.8.4.
 - Update to standards version 4.7.0, no changes required.

Regards

Phil

-- 

Playing the game for the game's own sake.

Homepage: https://kathenas.org
Instagram: https://instgram.com/kathenas







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

Bug#1069114: apt installs package without confirmation

[Wesley Schwengle]

Package: apt
Version: 2.9.1
Severity: important
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

Testing the new apt UI with freeplane showed a rather interesting bug. Apt will
now install a package without confirmation if all the deps are met. 

I triggered this like so:

apt install freeplane # shows confirmation y/n
apt remove freeplane  # shows confirmation y/n
apt install freeplane # doesn't ask for confirmation and just starts installing

See https://asciinema.org/a/3KX3A1hshGiHL0qx42QFsMJQ5 for the behavior in
action.

-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (/etc/apt/preferences.d/buster present, but not submitted) --


-- (/etc/apt/preferences.d/chrome present, but not submitted) --


-- (/etc/apt/preferences.d/docker-ce present, but not submitted) --


-- (/etc/apt/preferences.d/firewalld present, but not submitted) --


-- (/etc/apt/preferences.d/kernel present, but not submitted) --


-- (/etc/apt/preferences.d/libssl present, but not submitted) --


-- (/etc/apt/preferences.d/mozilla present, but not submitted) --


-- (/etc/apt/preferences.d/nodejs present, but not submitted) --


-- (/etc/apt/preferences.d/oldstable present, but not submitted) --


-- (/etc/apt/preferences.d/steam present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/docker.sources present, but not submitted) --


-- (/etc/apt/sources.list.d/endpoint-verification.sources present, but not 
submitted) --


-- (/etc/apt/sources.list.d/google-chrome.sources present, but not submitted) --


-- (/etc/apt/sources.list.d/mozilla.sources present, but not submitted) --


-- (/etc/apt/sources.list.d/nodesource.sources present, but not submitted) --


-- (/etc/apt/sources.list.d/signal-xenial.sources present, but not submitted) --


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

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

Versions of packages apt depends on:
ii  adduser 3.137
ii  base-passwd 3.6.3
ii  debian-archive-keyring  2023.4
ii  gpgv2.2.40-3
ii  libapt-pkg6.0t642.9.1
ii  libc6   2.37-17
ii  libgcc-s1   14-20240330-1
ii  libgnutls30t64  3.8.5-2
ii  libseccomp2 2.5.5-1
ii  libstdc++6  14-20240330-1
ii  libsystemd0 255.4-1+b1

Versions of packages apt recommends:
ii  ca-certificates  20240203

Versions of packages apt suggests:
ii  apt-doc 2.9.1
ii  aptitude0.8.13-6
ii  dpkg-dev1.22.6
ii  gnupg   2.2.40-3
ii  powermgmt-base  1.37

-- debconf-show failed

Bug#1064730: stdgpu: FTBFS: type_traits.h:736:1: error: expected type-specifier before ‘template’

[Timo Röhling]

* Gianfranco Costamagna  [2024-04-16 09:06]:

I agree with Cory, to me looks also a regression in thrust

I'm trying some hacky patch, lets see

Description: Reintroduce fallback lost in 
https://github.com/ROCm/rocThrust/commit/2b80e29803d60f01701a67bc57ef06dacfe8af8b
Author: Gianfranco Costamagna 
Last-Update: 2024-04-16

--- rocthrust-5.7.1.orig/thrust/detail/type_traits.h
+++ rocthrust-5.7.1/thrust/detail/type_traits.h
@@ -731,6 +731,8 @@ using invoke_result_t =
#else // 2017+
  ::cuda::std::invoke_result_t;
#endif
+#else
+  std::invoke_result_t;
#endif

template 

Thanks for the patch and upstream PR. If that does not pan out, I 
could split stdgpu into two separate (source) packages to have the 
openmp backend built against libthrust-dev. I prefer your solution, 
though.



Cheers
Timo



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


signature.asc
Description: PGP signature

Bug#1069113: gnome-shell-extension-dash-to-panel: Please update to ver. 62 , because ver. 60 doesn't work with gnome-shell ver 46

[Mantas Kriaučiūnas Baltix]

Source: gnome-shell-extension-dash-to-panel
Version: 60-1~exp2
Tags: experimental

Please update gnome-shell-extension-dash-to-panel to latest upstream
ver. 62 , because ver. 60 doesn't work with gnome-shell ver. 46, which
is currently in Debian Experimental and Ubuntu 24.04, see
https://github.com/home-sweet-gnome/dash-to-panel/releases

-- 
Naudokite laisvą Linux operacinę sistemą savo kompiuteryje - http://baltix.eu

Mantas Kriaučiūnas
Tel.: +370-614-53085
Use Baltix GNU/Linux OS ! http://launchpad.net/baltix

Bug#1069111: RM: rust-gtk-layer-shell-sys -- ROM; depends on obsolete library

[Matthias Geiger]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: jbi...@debian.org, maytha8the...@gmail.com, werdah...@riseup.net
User: ftp.debian@packages.debian.org
Usertags: remove
Control: block 1064374 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear ftpmasters,

please remove rust-gtk-layer-shell-sys. It depends on rust-gtk which is
obsoleted by upstream and unmaintained. Since this blocks the cuurent
gtk-rs transition I'd appreciate a removal from the archive.

For the debian rust team,

werdahias


-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmYeemUVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1oawQAKuJW6glNQT/Llixrzxjd/pIiauz
9/c28+G8XzH7A0lO5o26f9oXdKLuTIEY2QsUEKscQB1n02B6vVgqqvPb4mKoUsSj
GH80Bvtksp2Qwy1aCIR+HGzIUUL6/l/P8yD6ihLRs/KU01g5+cGiLza+9LbTFLVw
dHlpsrxIFkSnECV5B5bCvi1YG2lhMU9dCaPSw4Co6TyXte3JpHdE5qqrhwZuqeyY
1fMakktmYy+TqmJnHBVG3idBcO5ao0fkOLEvQ/YcBElQ9xtYHCP67iLXa/mPwp0a
gvCsa0RWJMSLx7fnJQkvo974ta96lRBHrv4jiz7s12fzZisS2RlSJoODQmcgHF8F
5Gnv3FFzKs/Masve3TXb0dwNXtDU+JenhWhQwkISGV9Loz10mJyiLUYKIJ1OqO1H
acXjWj9NdugmwUByvPWeRofjerbQZpqrN/3FSaJ4K8K32ECb07LoK5V6TSaV8v+w
z841pFJthYNLg08OSX8gq8YOwM5RJscVY24QhexRlxNtRU6VMSxoYIfEK5cVbycj
ZBi37/nW7yODtfF0sJPGsYGGn5XwW+TxjviG9rNsFc6Kmy+ZjddEdNUchAoQP6Mc
sUDTdprEO0SZNzdkdtmZlk7T1FzbH0V3PpZUDlz4BX6c2kPqnsul6WzS5xTTLu6P
yyDamBpRFBO7J8C/
=xhRE
-END PGP SIGNATURE-

Bug#1069110: how-can-i-help FTBFS in unstable

[Athos Ribeiro]

Package: how-can-i-help
Version: 17
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: athos.ribe...@canonical.com

Dear Maintainer,

this package currently FTBFS when generating the manpages.

I ran a local buld with the a2x verbose mode enable, here is the output:

TZ=UTC a2x -v -f manpage how-can-i-help.1.txt
asciidoc: reading: /etc/asciidoc/asciidoc.conf
asciidoc: reading: /<>/how-can-i-help.1.txt
asciidoc: reading: /etc/asciidoc/docbook45.conf
asciidoc: reading: /etc/asciidoc/filters/code/code-filter.conf
asciidoc: reading: /etc/asciidoc/filters/graphviz/graphviz-filter.conf
asciidoc: reading: /etc/asciidoc/filters/latex/latex-filter.conf
asciidoc: reading: /etc/asciidoc/filters/music/music-filter.conf
asciidoc: reading: /etc/asciidoc/filters/source/source-highlight-filter.conf
asciidoc: reading: /etc/asciidoc/lang-en.conf
asciidoc: writing: /<>/how-can-i-help.1.xml
a2x: ERROR: "xmllint" --nonet --noout --valid 
"/<>/how-can-i-help.1.xml" returned non-zero exit status 4

a2x: args: ['-v', '-f', 'manpage', 'how-can-i-help.1.txt']
a2x: resource files: []
a2x: resource directories: ['/etc/asciidoc/stylesheets']
a2x: executing: asciidoc [('--doctype', 'manpage'), ('--verbose',), 
('--backend', 'docbook'), ('-a', 'a2x-format=manpage'), ('--out-file', 
'/<>/how-can-i-help.1.xml')]
a2x: executing: "xmllint" --nonet --noout --valid 
"/<>/how-can-i-help.1.xml"

I/O error : Attempt to load network entity 
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
/<>/how-can-i-help.1.xml:2: warning: failed to load external 
entity "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
D DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
   ^
/<>/how-can-i-help.1.xml:5: validity error : Validation failed: no 
DTD found !

Bug#1069109: tirex: FTBFS with Mapnik 4.0.0

[Bas Couwenberg]

Source: tirex
Version: 0.7.1-1
Severity: important
Tags: ftbfs upstream patch
User: debian-...@lists.debian.org

Dear Maintainer,

Your package FBTFS with Mapnik 4.0.0.

pkg-config needs to be used instead of mapnik-config and some includes got 
moved.

Kind Regards,

Bas
diff -Nru tirex-0.7.1/debian/control tirex-0.7.1/debian/control
--- tirex-0.7.1/debian/control  2023-11-03 17:20:43.0 +0100
+++ tirex-0.7.1/debian/control  2024-04-16 13:34:13.0 +0200
@@ -9,7 +9,7 @@
libboost-program-options-dev,
libipc-sharelite-perl,
libjson-perl,
-   libmapnik-dev
+   libmapnik-dev (>= 4.0.0~)
 Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/debian-gis-team/tirex
 Vcs-Git: https://salsa.debian.org/debian-gis-team/tirex.git
diff -Nru tirex-0.7.1/debian/patches/mapnik-4.0.patch 
tirex-0.7.1/debian/patches/mapnik-4.0.patch
--- tirex-0.7.1/debian/patches/mapnik-4.0.patch 1970-01-01 01:00:00.0 
+0100
+++ tirex-0.7.1/debian/patches/mapnik-4.0.patch 2024-04-16 13:34:13.0 
+0200
@@ -0,0 +1,27 @@
+Description: Use pkg-config for Mapnik 4.0.0.
+Author: Bas Couwenberg 
+
+--- a/backend-mapnik/Makefile
 b/backend-mapnik/Makefile
+@@ -1,8 +1,7 @@
+ INSTALLOPTS=-g root -o root
+-CFLAGS += -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
+-CXXFLAGS = `mapnik-config --cflags` $(CFLAGS)
++CXXFLAGS += `pkg-config --cflags libmapnik` -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64
+ CXXFLAGS += -Wall -Wextra -pedantic -Wredundant-decls -Wdisabled-optimization 
-Wctor-dtor-privacy -Wnon-virtual-dtor -Woverloaded-virtual -Wsign-promo 
-Wold-style-cast
+-LDFLAGS= `mapnik-config --libs --ldflags --dep-libs`
++LDFLAGS= `pkg-config --libs libmapnik` -lboost_filesystem
+ 
+ backend-mapnik: renderd.o metatilehandler.o networklistener.o 
networkmessage.o networkrequest.o networkresponse.o debuggable.o 
requesthandler.o
+   $(CXX) -o $@ $^ $(LDFLAGS)
+--- a/backend-mapnik/metatilehandler.cc
 b/backend-mapnik/metatilehandler.cc
+@@ -25,7 +25,7 @@
+ #include 
+ #include 
+ #include 
+-#include 
++#include 
+ 
+ #if MAPNIK_VERSION >= 30
+ # include 
diff -Nru tirex-0.7.1/debian/patches/series tirex-0.7.1/debian/patches/series
--- tirex-0.7.1/debian/patches/series   2024-02-28 13:15:07.0 +0100
+++ tirex-0.7.1/debian/patches/series   2024-04-16 13:34:13.0 +0200
@@ -1 +1,2 @@
 rules-requires-root.patch
+mapnik-4.0.patch

Bug#1069108: how-can-i-help use deprecated exists? methods, removed from Ruby 3.2

[Athos Ribeiro]

Package: how-can-i-help
Version: 17
Severity: normal
X-Debbugs-Cc: athos.ribe...@canonical.com
Control: tags -1 patch

Dear Maintainer,

how-can-i-help use deprecated exists? methods, removed from Ruby 3.2.

A fix was proposed in
https://salsa.debian.org/debian/how-can-i-help/-/merge_requests/1.

Bug#1064730: stdgpu: FTBFS: type_traits.h:736:1: error: expected type-specifier before ‘template’

[Gianfranco Costamagna]

control: tags -1 patch
control: forwarded -1 https://github.com/ROCm/rocThrust/pull/402

Looks like the build went fine
G.
On Tue, 16 Apr 2024 09:06:27 +0200 Gianfranco Costamagna 
 wrote:

Hello,
On Mon, 15 Apr 2024 16:31:39 -0600 Cordell Bloor  wrote:
> Hi Timo,
> 
> On Sat, 2 Mar 2024 09:21:43 +0100 Timo =?utf-8?Q?R=C3=B6hling?= 
>  wrote:
> 
>  >

>  > On Sun, 25 Feb 2024 20:28:53 +0100 Lucas Nussbaum 
>  > wrote:
>  > > > /usr/include/thrust/detail/type_traits.h:736:1: error: expected
>  > > > type-specifier before ‘template’
>  >
>  > This bug is caused by a #ifdef cascade for different
>  > THRUST_DEVICE_SYSTEM values, which sadly no longer works with
>  > THRUST_DEVICE_SYSTEM_OMP. This makes it effectively impossible to
>  > build the HIP backend and the OpenMP backend from the same source.
> 
> Am I understanding correctly that this was broken in a rocthrust update? 
> Should this be treated as a rocthrust bug? [1]
> 
> Sincerely,

> Cory Bloor
> 



I agree with Cory, to me looks also a regression in thrust

I'm trying some hacky patch, lets see

Description: Reintroduce fallback lost in 
https://github.com/ROCm/rocThrust/commit/2b80e29803d60f01701a67bc57ef06dacfe8af8b
Author: Gianfranco Costamagna 
Last-Update: 2024-04-16

--- rocthrust-5.7.1.orig/thrust/detail/type_traits.h
+++ rocthrust-5.7.1/thrust/detail/type_traits.h
@@ -731,6 +731,8 @@ using invoke_result_t =
  #else // 2017+
::cuda::std::invoke_result_t;
  #endif
+#else
+  std::invoke_result_t;
  #endif

  template 

> [1]: https://bugs.debian.org/1064730
> 
> 
> 


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052111: gnome-shell-extension-weather for GNOME Shell 46/45 fork: https://github.com/penguin-teal/gnome-openweather

[Technologijų tinklas]

There is a gnome-shell-extension-weather fork with GNOME Shell 46/45
support: https://github.com/penguin-teal/gnome-openweather

I think Debian should use this repo
-- 
Prekyba kompiuteriais ir programine įranga - http://tinklas.eu/prekyba
El. paštas: tink...@tinklas.eu
Naudokite laisvą Linux operacinę sistemą savo kompiuteryje - http://baltix.eu
Mantas Kriaučiūnas
Use Baltix GNU/Linux OS ! http://launchpad.net/baltix

Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Roland,

On Tue, Apr 16, 2024 at 09:29:28AM +0200, Roland Rosenfeld wrote:
> Package: src:linux
> Version: 6.1.85-1
> Severity: important
> 
> Dear Maintainer,
> 
> when upgrading from 6.1.76-1 to 6.1.85-1 my USB ethernet device
>  ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
> is no longer named enx00249bXX but eth0.
> 
> I see the following in dmsg:
> 
> [1.484345] usb 4-5: Manufacturer: ASIX Elec. Corp.
> [1.484661] usb 4-5: SerialNumber: 249BXX
> [1.496312] ax88179_178a 4-5:1.0 eth0: register 'ax88179_178a' at 
> usb-:00:14.0-5, ASIX AX88179 USB 3.0 Gigabit Ethernet, d2:60:4c:YY:YY:YY
> [1.497746] usbcore: registered new interface driver ax88179_178a
> 
> Unplugging and plugging again does not solve the issue, but the
> interface still is named eth0.
> 
> Maybe it has to do with the following commit from
> https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.85
> 
> commit fc77240f6316d17fc58a8881927c3732b1d75d51
> Author: Jose Ignacio Tornos Martinez 
> Date:   Wed Apr 3 15:21:58 2024 +0200
> 
> net: usb: ax88179_178a: avoid the interface always configured as random 
> address
> 
> commit 2e91bb99b9d4f756e92e83c4453f894dda220f09 upstream.
> 
> After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two
> consecutive device resets"), reset is not executed from bind operation and
> mac address is not read from the device registers or the devicetree at 
> that
> moment. Since the check to configure if the assigned mac address is random
> or not for the interface, happens after the bind operation from
> usbnet_probe, the interface keeps configured as random address, although 
> the
> address is correctly read and set during open operation (the only reset
> now).
> 
> In order to keep only one reset for the device and to avoid the interface
> always configured as random address, after reset, configure correctly the
> suitable field from the driver, if the mac address is read successfully 
> from
> the device registers or the devicetree. Take into account if a locally
> administered address (random) was previously stored.
> 
> cc: sta...@vger.kernel.org # 6.6+
> Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive 
> device resets")
> Reported-by: Dave Stevenson  
> Signed-off-by: Jose Ignacio Tornos Martinez 
> Reviewed-by: Simon Horman 
> Link: 
> https://lore.kernel.org/r/20240403132158.344838-1-jtorn...@redhat.com
> Signed-off-by: Jakub Kicinski 
> Signed-off-by: Greg Kroah-Hartman 
> 
> Seems, that I'm not alone with this issue, there are also reports in
> https://www.reddit.com/r/debian/comments/1c304xn/linuximageamd64_61851_usb_link_interface_names/
> and https://infosec.space/@topher/112276500329020316
> 
> 
> All other (pci based) network interfaces still use there static names
> (enp0s25, enp2s0, enp3s0), only the usb ethernet name is broken with
> the new kernel.

If you revert that commit, does that fix your issue? Note that it
opens up again as well the referenced issue, but it would be helpfull
for reporting as regression if we know that's the case.

Regards,
Salvatore

Bug#1069107: oregano: Oregano crashes when using multiple displays.

[Mike Haag]

Package: oregano
Version: 0.84.41+dfsg.1-1.1
Severity: important
X-Debbugs-Cc: mhaag85...@gmail.com

Dear Maintainer,

1) I use a three-monitor setup on Gnome - Wayland. When opening Oregano, the
splash screen displays briefly and the application crashes.

2) Attempting to start Oregano from the terminal, I get the following error
messages:

mike@Pro6300:~$ oregano

(oregano:150187): Gdk-CRITICAL **: 08:21:48.278: gdk_monitor_get_geometry:
assertion 'GDK_IS_MONITOR (monitor)' failed

(oregano:150187): Gdk-CRITICAL **: 08:21:48.373: gdk_monitor_get_geometry:
assertion 'GDK_IS_MONITOR (monitor)' failed

(oregano:150187): Gdk-WARNING **: 08:21:48.405: Native Windows wider than 65535
pixels are not supported

(oregano:150187): Gdk-CRITICAL **: 08:21:48.429:
../../../gdk/wayland/gdkdisplay-wayland.c:1346: Truncating shared memory file
failed: Invalid argument
Segmentation fault
mike@Pro6300:~$

3) When just using the primary display, after first turning off the two non-
primary displays, Oregano starts and opens as expected.



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

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

Versions of packages oregano depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libc62.36-9+deb12u4
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgoocanvas-2.0-9   2.0.4-1+b1
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libgtksourceview-3.0-1   3.24.11-2+b1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1

Versions of packages oregano recommends:
ii  gnucap  1:0.36~20171003-1.1

oregano suggests no packages.

-- no debconf information

Bug#1069106: openmpi: 32 bit pmix_init:startup:internal-failure: help-pmix-runtime.txt: No such file

[Drew Parsons]

Source: openmpi
Version: 4.1.6-9
Severity: serious
Justification: ftbfs
Control: affects -1 src:fenics-dolfinx src:petsc

openmpi 4.1.6-9 is failing its own tests on 32-bit systems,
presumeably after they were configuring to use a local copy of pmix
instead of libpmix-dev.

For instance on i386
https://ci.debian.net/data/autopkgtest/unstable/i386/o/openmpi/45463906/log.gz
the error message is

 69s autopkgtest [12:19:13]: test compile_run_mpicc: [---
 69s --
 69s Sorry!  You were supposed to get help about:
 69s pmix_init:startup:internal-failure
 69s But I couldn't open the help file:
 69s /usr/share/pmix/help-pmix-runtime.txt: No such file or directory.  
Sorry!
 69s --
 69s [ci-107-5e0ffbcf:02362] PMIX ERROR: NOT-FOUND in file 
../../../../../../../../opal/mca/pmix/pmix3x/pmix/src/server/pmix_server.c at 
line 237
 

The same error affects builds and debci testing of client packages on
the 32 bit architectures, e.g. petsc, dolfinx

Bug#1069105: viking: FTBFS with Mapnik 4.0.0

[Bas Couwenberg]

Source: viking
Version: 1.10-2
Severity: important
Tags: ftbfs upstream patch

Dear Maintainer,

Your package FBTFS with Mapnik 4.0.0.

Upstream doesn't support Multi-Arch library paths for the input plugins which 
are now installed under 
/usr/lib/$(DEB_HOST_MULTIARCH)/mapnik/$(MAPNIK_SO_VERSION)/input.

This path can be retrieved from pkg-config:

 pkgconf --variable=plugins_dir libmapnik

mapnik-config was removed in Mapnik 4.0.

Mapnik also requires C++14 which viking doesn't use causing configure to fail 
due to type issues.

The attached debdiff disables the Mapnik support unconditionally to resolve the 
build failure.

Kind Regards,

Bas
diff -Nru viking-1.10/debian/control viking-1.10/debian/control
--- viking-1.10/debian/control  2022-01-02 08:05:40.0 +0100
+++ viking-1.10/debian/control  2024-04-16 13:36:27.0 +0200
@@ -21,7 +21,6 @@
  libicu-dev,
  libjson-glib-dev,
  libmagic-dev,
- libmapnik-dev [!kfreebsd-amd64 !kfreebsd-i386],
  liboauth-dev,
  libpng-dev,
  libsqlite3-dev,
diff -Nru viking-1.10/debian/rules viking-1.10/debian/rules
--- viking-1.10/debian/rules2022-01-02 08:05:40.0 +0100
+++ viking-1.10/debian/rules2024-04-16 13:36:27.0 +0200
@@ -1,8 +1,6 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
-EXTRAFLAGS := $(strip $(shell if ! dpkg -L libmapnik-dev 2>/dev/null | grep -q 
mapnik/map.hpp; then echo '--disable-mapnik'; fi))
-
 %:
dh $@
 
@@ -11,4 +9,4 @@
intltoolize --force
 
 override_dh_auto_configure:
-   dh_auto_configure -- $(EXTRAFLAGS)
+   dh_auto_configure -- --disable-mapnik

Bug#1069104: maildir-utils: Version 1.12.4 is available upstream

[John Goerzen]

Package: maildir-utils
Version: 1.12.3-3~bpo12+1
Severity: wishlist

Hello, and thanks for maintaining maildir-utils!  Upstream has released 1.12.4
which fixes some bugs I have encountered.

Thanks!

- John

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

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

Versions of packages maildir-utils depends on:
ii  guile-3.0-libs  3.0.8-2
ii  libc6   2.36-9+deb12u4
ii  libcld2-0   0.0.0-git20150806-9
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgmime-3.0-0  3.2.13+dfsg-2
ii  libstdc++6  12.2.0-14
ii  libxapian30 1.4.22-1

maildir-utils recommends no packages.

maildir-utils suggests no packages.

-- no debconf information

Bug#1069103: Want better error message for git server infra problem

[Ian Jackson]

Package: dgit
Version: 8.5

https://git.dgit.debian.org is unreliable.  (This isn't dgit's fault.)
Currently, users get a message like this:

$ dgit clone debvm
canonical suite name for unstable is sid
fetching existing git history
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
dgit: failed command: git ls-remote -q --refs 
https://git.dgit.debian.org/debvm 'refs/tags/archive/debian/*' 
'refs/tags/debian/*' refs/dgit/sid refs/dgit-rewrite/map

dgit: error: subprocess failed with error exit status 128
$

It should maybe print something like this:

It appears that the git repository
   repository https://git.dgit.debian.org/debvm
is unreachable or broken.  If dgit worked before for this distro (and
therefore is properly configured), this probably means that your local
network is broken, or the git server is malfunctioning.

If you have push access, you may find that specifying --for-push
works around the problem by using a different repo access method.

To be useful, we'd maybe want to bnackport this change.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

[Manfred Larcher]

Package: src:linux
Version: 6.1.85-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
kernel update from version 6.1.0-18 to 6.1.0-20

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
out system mounted a samba share via autofs (cifs) and we tried to 
access some files and directories


   * What was the outcome of this action?
the mount point of our share is /srv/samba/shares/company and the 
directory it/MIJ had another directory "digitale kommunikation" which 
did not shop up on the computer which mounted the samba share. before 
the kernel update it did and when we renamed the file to 
"digitale_kommunikation" or to "digitalo kommunikation" we could see it.

in the syslog we found the following messages:
CIFS: VFS: directory entry name would overflow frame end of buf ...
we could move that direcotry into another directory and it was useable, 
we created another directory it/abc and created the "digitale 
kommunikation" inside and it was hidden again. after switching back to 
kernel 6.1.0-20 everything was ok.

upgrade to kernel 6.5.0-0.deb12.4-amd64 package was ok too.

   * What outcome did you expect instead?
we expected to just see the "digitale kommunikation" directory as before.


-- Package-specific info:
** Kernel log: boot messages should be attached


-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 linux-image-6.1.0-20-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.1.0-20-amd64 recommends:
ii  apparmor 3.0.8-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.1.0-20-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.06-13+deb12u1
pn  linux-doc-6.1   

Versions of packages linux-image-6.1.0-20-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#1069101: libdbd-oracle-perl: requires rebuild for time_t transition

[Sebastian Ramacher]

Source: libdbd-oracle-perl
Version: 1.83-3
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

libdbd-oracle-perl depends on libaio1 which is involved in the time_t
transition and needs to be rebuilt. Please upload builds against the new
package.

Cheers
-- 
Sebastian Ramacher

Bug#1069099: binNMUs to fix mtdev-using udebs

[Cyril Brulebois]

Cyril Brulebois  (2024-04-16):
> Please consider binNMU-ing both packages against libmtdev-dev (>= 1.1.6-1.2)
> on all archs, provided that doesn't interfere with the whole 64-bit time_t
> transition:
>  - libinput10

That ought to read:
 - libinput

Sorry about that.

>  - xserver-xorg-input-evdev


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


signature.asc
Description: PGP signature

Bug#1069100: libscout.jar has duplicate ZIP entries in the central directory

[Holger Levsen]

Package: libscout
Version: 2.3.2-3
Severity: normal
X-Debbugs-Cc: reproducible-bui...@alioth-lists.debian.net, Fay Stegerman 


Dear Maintainer,

a few days ago I filed "#1068705: diffoscope crashes on libscout 2.3.2-3 build
on unstable but not bullseye" which then led Fay Stegerman to discover than
src:libscout builds a libscout.jar that has duplicate ZIP entries in the central
directory, pointing to the same actual entry in the ZIP. Please don't do this.

#1068705 has been fixed in the meantime and diffoscope 264 can now correctly
display the differences, as can be seen in
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/libscout.html
this is still an incorrect and broken zip file.

Thanks for maintaining libscout!


-- 
cheers,
Holger

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

I miss the old days were billionaires’ vanity projects were to build 1000 public
libraries or giant music venues.


signature.asc
Description: PGP signature

Bug#1069093: odbc-mariadb: Unknown system variable 'session_track_schema' error while using isql

[Olivier]

Details on MySQL server with which issue was met are:

Debian 7.2
mysql  Ver 14.14 Distrib 5.5.31, for debian-linux-gnu (x86_64) using
readline 6.2

Bug#1069099: binNMUs to fix mtdev-using udebs

[Cyril Brulebois]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: debian-b...@lists.debian.org

Hi,

mtdev regressed a while back, leading a few udebs to become uninstallable
(initially one[1], now two).

 1. https://bugs.debian.org/1066071


No response in 1+ month, the package wasn't ready to migrate anyway since
it was waiting on dpkg but also regressing on 32-bit arms; I've uploaded
an NMU yesterday, built everywhere. I also verified that rebuilding the
following two packages gives appropriate dependencies for their udebs.

Please consider binNMU-ing both packages against libmtdev-dev (>= 1.1.6-1.2)
on all archs, provided that doesn't interfere with the whole 64-bit time_t
transition:
 - libinput10
 - xserver-xorg-input-evdev


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

Bug#1069098: emboss: all executables segfault on s390x

[Andrius Merkys]

Package: emboss
Version: 6.6.0+dfsg-9
Severity: important
Tags: bullseye bookworm trixie sid
X-Debbugs-CC: debian-...@lists.debian.org

Hello,

All emboss executables segfault on s390x since bullseye. Segfault is 
evident when calling any of emboss executables without CLI arguments or 
only with '--help'. Checking with GDB on sid for 'gdb seqret' says:


(gdb) run
Starting program: /usr/bin/seqret
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
cvt_s (code=, ap=0x3ff99c0, put=0x3fff77b79b8 
, cl=0x3ff9e70, flags=0x3ff99c8, width=-2147483648, 
precision=-2147483648) at ajfmt.c:352

352if(str)

GDB localises the issue for seqret in a string formatting function.

Andrius

Bug#1069097: openstack-dashboard: postinst error makes designate-dashboard to FTBFS randomly

[Santiago Vila]

Package: openstack-dashboard
Version: 3:24.0.0-2
Affects: src:designate-dashboard
Severity: serious
Justification: Breaks other packages

Dear maintainer:

During an incremental rebuild of all packages in trixie, package 
"designate-dashboard"
failed to build due to a postinst error in openstack-dashboard:


[...]
2717 static files copied to '/var/lib/openstack-dashboard/static'.
/usr/lib/python3/dist-packages/django/conf/__init__.py:267: 
RemovedInDjango50Warning: The USE_L10N setting is deprecat
ed. Starting with Django 5.0, localized formatting of data will always be 
enabled. For example Django will display num
bers and dates using the format of the current locale.
  warnings.warn(USE_L10N_DEPRECATED_MSG, RemovedInDjango50Warning)
/usr/lib/python3/dist-packages/debreach/__init__.py:6: DeprecationWarning: 
distutils Version classes are deprecated. U
se packaging.version instead.
  version_info = version.StrictVersion(__version__).version
CommandError: An error occurred during rendering serial_console.html: Syntax 
error: Found 'inline-blo' but expected one of ADD, ALPHA_FUNCTION, 
BANG_IMPORTANT, BAREWORD, COLOR, DOUBLE_QUOTE, FNCT, IF_FUNCTION, INTERP_START, 
LITERAL_FUNCTION, LPAR, NOT, NUM, SIGN, SINGLE_QUOTE, URL_FUNCTION, VAR
Compressing... dpkg: error processing package openstack-dashboard (--configure):
 installed openstack-dashboard package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of 
sbuild-build-depends-main-dummy:
 sbuild-build-depends-main-dummy depends on openstack-dashboard; however:
  Package openstack-dashboard is not configured yet.

dpkg: error processing package sbuild-build-depends-main-dummy (--configure):
 dependency problems - leaving unconfigured
Processing triggers for ca-certificates (20240203) ...
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:
 openstack-dashboard
 sbuild-build-depends-main-dummy
E: Sub-process /usr/bin/dpkg returned an error code (1)
apt-get failed.


The above is just how the build ends and not necessarily the most relevant part.
If required, the full build log (for designate-dashboard) is available here:

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

Note also how there is a gazillion of error messages like this:


Found another file with the destination path 
'horizon/lib/angular_schema_form/i18n/angular-locale_az-cyrl-az.js'. It will be 
ignored since only the first encountered file is collected. If this is not what 
you want, make sure every static file has a unique path.


That's apparently a django-related issue:

https://stackoverflow.com/questions/35571256/found-another-file-with-the-destination-path-where-is-that-other-file

which I would hope can be fixed as well (maybe it's part of the problem, maybe 
not,
I don't know).


About the archive rebuild: The build was made on virtual machines
of type m6a.large from AWS, using sbuild and a reduced chroot
with only build-essential packages.

I can't provide a "recipe" to reproduce the bug because it happens randomly,
but I expect the above error messages and the full build log will help to
determine the cause.

If required, I could provide ssh access to a virtual machine where
this random build failure happens, but I strongly suggest that
the build log is analyzed first to determine how it could happen.

Thanks.

Bug#1068705: diffoscope crashes on libscout 2.3.2-3 build on unstable but not bullseye

[Holger Levsen]

On Mon, Apr 15, 2024 at 03:00:42PM +0200, Fay Stegerman wrote:
> > (thanks again!), am I correct to assume that thus there's no need
> > to file a seperate bug against libscout?
> It's generating a broken ZIP file with duplicate entries.  It really shouldn't
> be doing that, regardless of whether we can extract the files nonetheless.
> That's still a bug that should be reported and fixed.

ok, will do, mostly using this bug as reference, thanks!

> > (which is nice, though maybe could only been shown once?)
> Ah.  It correctly shows that twice as there could be differences between the 
> two
> files being compared wrt whether they have duplicate entries (and if so how
> many).
> 
> And if you run 'diffoscope foo.zip bar.zip' it'll show those two different 
> file
> names.  But in this case we have nested archives and the path (and in this 
> case
> also the number of duplicate entries) is identical for both, so maybe we can
> tweak the output to show which top-level file it belongs to?

yes.

:)
 
> > though this later is done using diffoscope from unstable while the
> > rest of the userland is bullseye, so this might be expected as well?
> Ah.  Looks like zipdetails(1) on bullseye doesn't support the --redact, 
> --scan,
> and --utc options yet.

right, thanks for confirming in detail!


-- 
cheers,
Holger

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

Dance like no one's watching. Encrypt like everyone is.


signature.asc
Description: PGP signature

Bug#1066228: xjdic: FTBFS: implicit declaration of functions

[Ludovic Drolez]

On Wed, Mar 27, 2024 at 11:12:09AM +0100, Bastian Germann wrote:
> Please find a patch included.

Thanks ! Will upload this soon.

Ludo

--
https://drolez.com/blog/   - Music and Tech Blog
https://palmopensource.com - Raspberry, retro and solar tinkering

Bug#1069096: mrtg: MRTG installation hangs with SysV-rc

[Patrik Schindler]

Package: mrtg
Version: 2.17.10-5+deb12u2
Severity: important

Installing MRRTG with SysV-rc yields:

Selecting previously unselected package mrtg.
(Reading database ... 101360 files and directories currently installed.)
Preparing to unpack .../mrtg_2.17.10-5+deb12u2_amd64.deb ...
Unpacking mrtg (2.17.10-5+deb12u2) ...
Setting up mrtg (2.17.10-5+deb12u2) ...
Starting MRTG
Daemonizing MRTG ...
Created symlink /etc/systemd/system/multi-user.target.wants/mrtg.service → 
/lib/systemd/system/mrtg.service.

Then, the installation process hangs.

ps tree:

apt-get install mrtg
 \_ /usr/bin/dpkg --status-fd 51 --configure --pending
 \_ sh -c (test -x /usr/lib/needrestart/dpkg-status && 
/usr/lib/needrestart/dpkg-status || cat > /dev/null)
 |   \_ sh -c (test -x /usr/lib/needrestart/dpkg-status && 
/usr/lib/needrestart/dpkg-status || cat > /dev/null)
 |   \_ /bin/sh /usr/lib/needrestart/dpkg-status
 \_ /usr/bin/perl -w /usr/share/debconf/frontend 
/var/lib/dpkg/info/mrtg.postinst configure
 \_ [mrtg.postinst] 

Killing debconf fronted leaves package in iF state. Mrtg is started and runs in 
background, though.

Looking into where the hang occurs:

~ # bash -x /var/lib/dpkg/info/mrtg.postinst configure
+ set -e
+ getent group
+ grep -q mrtg
+ getent passwd
+ grep -q mrtg
+ chmod 2750 /etc/mrtg
+ chmod 0640 /etc/mrtg/mrtg.cfg
+ chown mrtg:mrtg /etc/mrtg
+ chown mrtg:mrtg /etc/mrtg/mrtg.cfg
+ . /usr/share/debconf/confmodule
++ '[' '!' '' ']'
++ PERL_DL_NONLAZY=1
++ export PERL_DL_NONLAZY
++ '[' '' ']'
++ exec /usr/share/debconf/frontend /var/lib/dpkg/info/mrtg.postinst configure
Starting MRTG
Daemonizing MRTG ...
/usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
/usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
/usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
=> And hangs here.

Adding an "exit 0" in line 56 (before the dh_installinit/13.11.4 block) allow 
the package configuration to succeed and the package state set to ii. Adding 
exit 0 later in the script does not solve the hang, I have no explanation for 
that.


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

Kernel: Linux 6.1.0-20-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mrtg depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u4
ii  libgd3 2.3.3-9
ii  libsnmp-session-perl   1.14~git20221124T101957-1
ii  perl   5.36.0-7+deb12u1

mrtg recommends no packages.

Versions of packages mrtg suggests:
ii  apache2 [httpd] 2.4.57-2
ii  lighttpd [httpd]1.4.69-1
ii  lynx [www-browser]  2.9.0dev.12-1
pn  mrtg-contrib

-- Configuration Files:
/etc/mrtg/mrtg.cfg [Errno 13] Permission denied: '/etc/mrtg/mrtg.cfg'

-- debconf information excluded

Bug#1058823: usbauth: diff for NMU version 1.0.5-1.1

[Chris Hofstaedtler]

Control: tags 1058823 + patch
Control: tags 1058823 + pending

Dear maintainer,

I've prepared an NMU for usbauth (versioned as 1.0.5-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Chris

diff -Nru usbauth-1.0.5/debian/changelog usbauth-1.0.5/debian/changelog
--- usbauth-1.0.5/debian/changelog	2023-01-11 09:51:24.0 +0100
+++ usbauth-1.0.5/debian/changelog	2023-12-16 22:35:58.0 +0100
@@ -1,3 +1,11 @@
+usbauth (1.0.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use udev.pc to place udev files. (Closes: #1058823)
+  * Switch from obsolete pkg-config to pkgconf.
+
+ -- Chris Hofstaedtler   Sat, 16 Dec 2023 22:35:58 +0100
+
 usbauth (1.0.5-1) unstable; urgency=medium
 
   [ Kun-Hung Tsai (蔡昆宏) ]
diff -Nru usbauth-1.0.5/debian/control usbauth-1.0.5/debian/control
--- usbauth-1.0.5/debian/control	2023-01-11 09:50:44.0 +0100
+++ usbauth-1.0.5/debian/control	2023-12-16 22:35:58.0 +0100
@@ -4,14 +4,15 @@
 Maintainer: Kun-Hung Tsai (蔡昆宏) 
 Uploaders: SZ Lin (林上智) 
 Build-Depends: debhelper-compat (= 13),
-   pkg-config,
automake,
flex,
bison,
libudev-dev,
libusbauth-configparser-dev,
libdbus-1-dev,
-   m4
+   m4,
+   pkgconf,
+   systemd-dev
 Standards-Version: 4.6.1
 Homepage: https://github.com/kochstefan/usbauth-all/tree/master/usbauth
 Vcs-Git: https://salsa.debian.org/debian/usbauth.git
diff -Nru usbauth-1.0.5/debian/rules usbauth-1.0.5/debian/rules
--- usbauth-1.0.5/debian/rules	2023-01-11 09:50:44.0 +0100
+++ usbauth-1.0.5/debian/rules	2023-12-16 22:35:58.0 +0100
@@ -6,5 +6,8 @@
 %:
 	dh $@
 
+override_dh_auto_install:
+	dh_auto_install -- udevrulesdir=$(shell pkg-config --variable=udevdir udev)/rules.d
+
 override_dh_missing:
 	dh_missing --fail-missing

Bug#1057804: guestfsd: move /lib/udev/rules.d/99-guestfs-serial.rules into /usr

[Chris Hofstaedtler]

Hi Hilko,

On Fri, Dec 08, 2023 at 06:28:14PM +0100, Chris Hofstaedtler wrote:
> your package installs a udev rule, into
> /lib/udev/rules.d/99-guestfs-serial.rules. This path appears
> hard-coded in the Debian packaging. Please move the rule into
> /usr/lib/udev, in trixie.

I see a number of uploads since this bug was filed. Did you see the
bug?

Thanks,
Chris

Bug#1069094: mariadb: FTBFS on hurd-i386

[Svante Signell]

Source: mariadb
Version: 10.11.7-4
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

mariadb FTBFS on hurd-i386. Attached are three patches enabling a
successful build:

- debian_rules.patch: 
override_dh_installsystemd: Install mariadb.service on Linux only.
override_dh_missing: Change dh_missing from fail to list on non-linux. 

- storage_connect_ioapi.h.patch:
Add Hurd to define __USE_FILE_OFFSET64 et al.

- plugin_disks_information_schema_disks.cc.patch:
Define PATH_MAX if not defined.

Unfortunately the build succeeds only with DEB_BUILD_OPTIONS=nocheck
since debian/rules override_dh_auto_test errors out with:
2024-04-16 11:09:38 0 [Note] Plugin 'INNODB_SYS_VIRTUAL' is disabled.
ERROR: 1017  Can't find file: '(temporary)' (errno: 1073741826 "No such
file or directory")
2024-04-16 11:09:38 0 [ERROR] Aborting

Additionally the file debian/unstable-tests.hurd should be linked to
unstable-tests.hurd-i386 (or equivalent) since
dpkg-architecture -qDEB_BUILD_ARCH results in hurd-i386.

Thanks!

--- a/debian/rules	2024-04-15 16:46:16.0 +0200
+++ b/debian/rules	2024-04-15 16:45:59.0 +0200
@@ -205,7 +205,14 @@
 	mv -v $(TMP)/usr/lib/mysql/plugin/qa_auth_client.so $(TMP)/usr/lib/$(DEB_HOST_MULTIARCH)/libmariadb3/plugin/
 
 override_dh_installsystemd:
+ifneq (,$(filter linux,$(DEB_HOST_ARCH_OS)))
 	dh_installsystemd -pmariadb-server mariadb.service
+endif
+
+override_dh_missing:
+ifneq (,$(filter linux,$(DEB_HOST_ARCH_OS)))
+	dh_missing --list-missing
+endif
 
 override_dh_installinit-arch:
 	dh_installinit --name=mariadb
Index: mariadb-10.11.7/plugin/disks/information_schema_disks.cc
===
--- mariadb-10.11.7.orig/plugin/disks/information_schema_disks.cc
+++ mariadb-10.11.7/plugin/disks/information_schema_disks.cc
@@ -32,6 +32,9 @@
 #include 
 #endif
 #endif
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
 #include 
 #include 
 #include /* check_global_access() */
--- a/storage/connect/ioapi.h	2024-02-01 18:36:14.0 +0100
+++ b/storage/connect/ioapi.h	2024-04-14 17:29:57.0 +0200
@@ -21,9 +21,10 @@
 #ifndef _ZLIBIOAPI64_H
 #define _ZLIBIOAPI64_H
 
-#if defined(__linux__)
+#if defined(__linux__) || defined (__GNU__)
 
-  // Linux needs this to support file operation on files larger then 4+GB
+  // Linux and Hurd needs this to support file operation on files larger
+  // than 4+GB.
   // But might need better if/def to select just the platforms that needs them.
 
 #ifndef __USE_FILE_OFFSET64

Bug#1069048: All NICs tried with same retries and timeouts?

[Narcis Garcia]

Hi Thomas,

And I'm asking about your patch contribution, when no NIC fails:
Will 5 linked NICs get network configuration from all respective 
DHCP-served networks, or only first succeeded one?


--

Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should remove and omit any @, dot and mailto combinations against 
automated addresses collectors.

Bug#1022143: I had this too

[Russell Coker]

Chrome regularly had sound stop when playing YouTube even though mpv could 
still play videos.  Running "systemctl --user restart pulseaudio.service" 
would make sound work again but pausing YouTube would usually trigger it 
again.

Running the following 2 commands to stop pipewire seems to have fixed the 
problem.  So it's related to the communication between pipewire and 
pulseaudio.


systemctl --user stop pipewire.service
systemctl --user stop pipewire.socket

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