Bug#1025879: xrdp: CVE-2022-23468 CVE-2022-23477 CVE-2022-23478 CVE-2022-23479 CVE-2022-23480 CVE-2022-23481 CVE-2022-23482 CVE-2022-23483 CVE-2022-23484 CVE-2022-23493

[Salvatore Bonaccorso]

Source: xrdp
Version: 0.9.19-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for xrdp.

CVE-2022-23468[0]:
| xrdp is an open source project which provides a graphical login to
| remote machines using Microsoft Remote Desktop Protocol (RDP). xrdp
| < v0.9.21 contain a buffer over flow in xrdp_login_wnd_create()
| function. There are no known workarounds for this issue. Users are
| advised to upgrade.


CVE-2022-23477[1]:
| xrdp is an open source project which provides a graphical login to
| remote machines using Microsoft Remote Desktop Protocol (RDP). xrdp
| < v0.9.21 contain a buffer over flow in audin_send_open() function.
| There are no known workarounds for this issue. Users are advised to
| upgrade.


CVE-2022-23478[2]:
| xrdp is an open source project which provides a graphical login to
| remote machines using Microsoft Remote Desktop Protocol (RDP). xrdp
| < v0.9.21 contain a Out of Bound Write in
| xrdp_mm_trans_process_drdynvc_channel_open() function. There are no
| known workarounds for this issue. Users are advised to upgrade.


CVE-2022-23479[3]:
| xrdp is an open source project which provides a graphical login to
| remote machines using Microsoft Remote Desktop Protocol (RDP). xrdp
| < v0.9.21 contain a buffer over flow in xrdp_mm_chan_data_in()
| function. There are no known workarounds for this issue. Users are
| advised to upgrade.


CVE-2022-23480[4]:
| xrdp is an open source project which provides a graphical login to
| remote machines using Microsoft Remote Desktop Protocol (RDP). xrdp
| < v0.9.21 contain a buffer over flow in
| devredir_proc_client_devlist_announce_req() function. There are no
| known workarounds for this issue. Users are advised to upgrade.


CVE-2022-23481[5]:
| xrdp is an open source project which provides a graphical login to
| remote machines using Microsoft Remote Desktop Protocol (RDP). xrdp
| < v0.9.21 contain a Out of Bound Read in
| xrdp_caps_process_confirm_active() function. There are no known
| workarounds for this issue. Users are advised to upgrade.


CVE-2022-23482[6]:
| xrdp is an open source project which provides a graphical login to
| remote machines using Microsoft Remote Desktop Protocol (RDP). xrdp
| < v0.9.21 contain a Out of Bound Read in
| xrdp_sec_process_mcs_data_CS_CORE() function. There are no known
| workarounds for this issue. Users are advised to upgrade.


CVE-2022-23483[7]:
| xrdp is an open source project which provides a graphical login to
| remote machines using Microsoft Remote Desktop Protocol (RDP). xrdp
| < v0.9.21 contain a Out of Bound Read in libxrdp_send_to_channel()
| function. There are no known workarounds for this issue. Users are
| advised to upgrade.


CVE-2022-23484[8]:
| xrdp is an open source project which provides a graphical login to
| remote machines using Microsoft Remote Desktop Protocol (RDP). xrdp
| < v0.9.21 contain a Integer Overflow in
| xrdp_mm_process_rail_update_window_text() function. There are no known
| workarounds for this issue. Users are advised to upgrade.


CVE-2022-23493[9]:
| xrdp is an open source project which provides a graphical login to
| remote machines using Microsoft Remote Desktop Protocol (RDP). xrdp
| < v0.9.21 contain a Out of Bound Read in
| xrdp_mm_trans_process_drdynvc_channel_close() function. There are no
| known workarounds for this issue. Users are advised to upgrade.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-23468
https://www.cve.org/CVERecord?id=CVE-2022-23468
[1] https://security-tracker.debian.org/tracker/CVE-2022-23477
https://www.cve.org/CVERecord?id=CVE-2022-23477
[2] https://security-tracker.debian.org/tracker/CVE-2022-23478
https://www.cve.org/CVERecord?id=CVE-2022-23478
[3] https://security-tracker.debian.org/tracker/CVE-2022-23479
https://www.cve.org/CVERecord?id=CVE-2022-23479
[4] https://security-tracker.debian.org/tracker/CVE-2022-23480
https://www.cve.org/CVERecord?id=CVE-2022-23480
[5] https://security-tracker.debian.org/tracker/CVE-2022-23481
https://www.cve.org/CVERecord?id=CVE-2022-23481
[6] https://security-tracker.debian.org/tracker/CVE-2022-23482
https://www.cve.org/CVERecord?id=CVE-2022-23482
[7] https://security-tracker.debian.org/tracker/CVE-2022-23483
https://www.cve.org/CVERecord?id=CVE-2022-23483
[8] https://security-tracker.debian.org/tracker/CVE-2022-23484
https://www.cve.org/CVERecord?id=CVE-2022-23484
[9] https://security-tracker.debian.org/tracker/CVE-2022-23493
https://www.cve.org/CVERecord?id=CVE-2022-23493

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1025880: libsyntax-keyword-multisub-perl: FTBFS on armhf et all due to wrong format string usage

[Steve Langasek]

Package: libsyntax-keyword-multisub-perl
Version: 0.02-2
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Hi Gregor,

libsyntax-keyword-multisub-perl fails to build from source on multiple
architectures because the build-time test suite successfully captures a bug
in the code for which there is a compiler warning during the build:

  lib/Syntax/Keyword/MultiSub.xs:52:11: warning: format ‘%d’ expects argument 
of type ‘int’, but argument 4 has type ‘IV’ {aka ‘long long int’} [-Wformat=]

(https://buildd.debian.org/status/fetch.php?pkg=libsyntax-keyword-multisub-perl&arch=armhf&ver=0.02-2&stamp=1658361396&raw=0)

The code uses a format string for an int, but passes nargs which is of type
IV which is almost never an int.  Therefore on some architectures the value
is being read from the wrong place in memory, resulting in a garbage value
instead of '3' as it should be in the test case:

[...]
#   Failed test 'f() complains with too many args'
#   at t/01multi.t line 22.
#   'Unable to find a function body for a call to &main::f 
having 40571528 arguments at t/01multi.t line 21.
# '
# doesn't match '(?^u:^Unable to find a function body for a call to 
&main::f having 3 arguments at )'
# Looks like you failed 1 test of 9.
[...]


The attached patch fixes the code by casting nargs to an int, which in
practice should always be sufficient.

Normally a build failure on architectures where the package has never built
before is an 'important' rather than 'serious' bug; because the new version
of libfuture-asyncawait-perl build-depends on
libsyntax-keyword-multisub-perl, it is also blocked by this bug so I am
marking it serious instead.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru 
libsyntax-keyword-multisub-perl-0.02/debian/patches/correct-format-string-arguments.patch
 
libsyntax-keyword-multisub-perl-0.02/debian/patches/correct-format-string-arguments.patch
--- 
libsyntax-keyword-multisub-perl-0.02/debian/patches/correct-format-string-arguments.patch
   1969-12-31 16:00:00.0 -0800
+++ 
libsyntax-keyword-multisub-perl-0.02/debian/patches/correct-format-string-arguments.patch
   2022-12-10 20:41:55.0 -0800
@@ -0,0 +1,23 @@
+Description: Ensure format string arguments are of the matching type
+ The code treats 'nargs' as an int, but it is of type IV which may be of a
+ different size.  This results in the code reading the wrong area of memory
+ on some architectures, and rightly failing the build because the resulting
+ error message is wrong (printing a garbage value for the number of arguments,
+ instead of '3').
+Author: Steve Langasek 
+Last-Update: 2022-12-10
+Forwarded: no
+
+Index: libsyntax-keyword-multisub-perl-0.02/lib/Syntax/Keyword/MultiSub.xs
+===
+--- libsyntax-keyword-multisub-perl-0.02.orig/lib/Syntax/Keyword/MultiSub.xs
 libsyntax-keyword-multisub-perl-0.02/lib/Syntax/Keyword/MultiSub.xs
+@@ -50,7 +50,7 @@
+ 
+   if(!jumpcv)
+ croak("Unable to find a function body for a call to &%s::%s having %d 
arguments",
+-  HvNAME(CvSTASH(runcv)), GvNAME(CvGV(runcv)), nargs);
++  HvNAME(CvSTASH(runcv)), GvNAME(CvGV(runcv)), (int)nargs);
+ 
+   /* Now pretend to be  goto &$cv
+* Reuse the same PL_op structure and just call that ppfunc */
diff -Nru libsyntax-keyword-multisub-perl-0.02/debian/patches/series 
libsyntax-keyword-multisub-perl-0.02/debian/patches/series
--- libsyntax-keyword-multisub-perl-0.02/debian/patches/series  1969-12-31 
16:00:00.0 -0800
+++ libsyntax-keyword-multisub-perl-0.02/debian/patches/series  2022-12-10 
20:38:30.0 -0800
@@ -0,0 +1 @@
+correct-format-string-arguments.patch

Bug#1025878: libkeduvocdocument-data: missing Breaks+Replaces: libkeduvocdocument5 (<< 4:22.11.90-2)

[Aurélien COUDERC]

Le dimanche 11 décembre 2022, 04:41:25 CET Andreas Beckmann a écrit :

> There are already
>   Breaks+Replaces: libkeduvocdocument5 (<< 4:21.12.3)
> but that versioning is insufficient to catch all package versions 
> predating the package split.

Ah yes, thank you Andreas.

Fix uploaded.


Happy hacking,
--
Aurélien

Bug#1023479: FTBFS: t/01struct.t fails

[Steve Langasek]

Package: libobject-pad-classattr-struct-perl
Version: 0.03-1
Followup-For: Bug #1023479
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
Control: tags -1 patch

Hi Gregor,

This failure is simply due to a string change in the exception output from
new libobject-pad-perl.  The attached patch fixes the build to look for the
new string with quotes.  Please consider applying in Debian.

It has been uploaded to Ubuntu to unblock the perl 5.36 transition there.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libobject-pad-classattr-struct-perl-0.03/debian/patches/series 
libobject-pad-classattr-struct-perl-0.03/debian/patches/series
--- libobject-pad-classattr-struct-perl-0.03/debian/patches/series  
1969-12-31 16:00:00.0 -0800
+++ libobject-pad-classattr-struct-perl-0.03/debian/patches/series  
2022-12-11 00:08:53.0 -0800
@@ -0,0 +1 @@
+updated-exception-formatting.patch
diff -Nru 
libobject-pad-classattr-struct-perl-0.03/debian/patches/updated-exception-formatting.patch
 
libobject-pad-classattr-struct-perl-0.03/debian/patches/updated-exception-formatting.patch
--- 
libobject-pad-classattr-struct-perl-0.03/debian/patches/updated-exception-formatting.patch
  1969-12-31 16:00:00.0 -0800
+++ 
libobject-pad-classattr-struct-perl-0.03/debian/patches/updated-exception-formatting.patch
  2022-12-11 00:10:33.0 -0800
@@ -0,0 +1,21 @@
+Description: update matching string for exception in test case
+ libobject-pad-perl 0.74-1 has added quotes around a variable in its
+ exception string, causing a test failure.  Update the string match to
+ work with the current version.
+Author: Steve Langasek 
+Last-Update: 2022-12-11
+Forwarded: no
+
+Index: libobject-pad-classattr-struct-perl-0.03/t/01struct.t
+===
+--- libobject-pad-classattr-struct-perl-0.03.orig/t/01struct.t
 libobject-pad-classattr-struct-perl-0.03/t/01struct.t
+@@ -27,7 +27,7 @@
+ok( !defined eval { Example->new( x => 0, y => 0, w => "no" ) },
+   'Example constructor does not like w param' );
+my $e = $@;
+-   like( $e, qr/^Unrecognised parameters for Example constructor: w /,
++   like( $e, qr/^Unrecognised parameters for Example constructor: 'w' /,
+   'exception from Example constructor param failure' );
+ }
+ 

Bug#1025881: libtickit-console-perl tests fail with new libobject-pad-perl

[Steve Langasek]

Package: libtickit-console-perl
Version: 0.10-3
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar

Hi Andrej,

The autopkgtests for the libtickit-console-perl package regress with
libobject-pad-perl 0.74, suggesting this package now also FTBFS in unstable
and blocks libobject-pad-perl from migrating:

[...]
autopkgtest [02:15:16]: test autodep8-perl-build-deps: [---
t/00use.t .. 
not ok 1 - use Tickit::Console;

#   Failed test 'use Tickit::Console;'
#   at t/00use.t line 8.
# Tried to use 'Tickit::Console'.
# Error:  'extends' modifier keyword is no longer supported; use :isa() 
attribute instead at /usr/share/perl5/Tickit/Console.pm line 11.
# Compilation failed in require at t/00use.t line 8.
# BEGIN failed--compilation aborted at t/00use.t line 8.
1..1
# Looks like you failed 1 test of 1.
[...]

  
(https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libtickit-console-perl/29218586/log.gz)


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


signature.asc
Description: PGP signature

Bug#1025882: libdatetime-perl ftbfs with new libdatetime-locale-perl

[Steve Langasek]

Package: libdatetime-perl
Version: 2:1.57-2
Severity: serious
Tags: patch
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Dear maintainers,

libdatetime-perl currently FTBFS in unstable because a of a test failure
introduced by a new libdatetime-locale-perl:

[...]
#   Failed test '%c is Sep 7, 1999, 1:02:42 PM'
#   at t/13strftime.t line 311.
#  got: 'Sep 7, 1999, 1:02:42<80>PM'
# expected: 'Sep 7, 1999, 1:02:42 PM'

#   Failed test '%X is 1:02:42 PM'
#   at t/13strftime.t line 311.
#  got: '1:02:42<80>PM'
# expected: '1:02:42 PM'
# Looks like you failed 2 tests of 49.
[...]

This also shows up as an autopkgtest failure at
.

I do no know why these format strings are now using a unicode non-breaking
space instead of a space as they were before, but it's simple enough to
update the test suite to match the current output.  Please see attached.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libdatetime-perl-1.57/debian/patches/series 
libdatetime-perl-1.57/debian/patches/series
--- libdatetime-perl-1.57/debian/patches/series 1969-12-31 16:00:00.0 
-0800
+++ libdatetime-perl-1.57/debian/patches/series 2022-12-11 00:31:48.0 
-0800
@@ -0,0 +1 @@
+strftime-output-change.patch
diff -Nru libdatetime-perl-1.57/debian/patches/strftime-output-change.patch 
libdatetime-perl-1.57/debian/patches/strftime-output-change.patch
--- libdatetime-perl-1.57/debian/patches/strftime-output-change.patch   
1969-12-31 16:00:00.0 -0800
+++ libdatetime-perl-1.57/debian/patches/strftime-output-change.patch   
2022-12-11 00:34:03.0 -0800
@@ -0,0 +1,31 @@
+Description: update test suite for changed strftime output
+ With libdatetime-locale-perl 1.37, en_US locale strings are now using a
+ unicode narrow no-break space instead of a regular space before the AM/PM
+ marker (?!).  Update the test suite to match since this change affects
+ nothing wrt the correctness of this module.
+Author: Steve Langasek 
+Last-Update: 2022-12-11
+Forwarded: no
+
+Index: libdatetime-perl-1.57/t/13strftime.t
+===
+--- libdatetime-perl-1.57.orig/t/13strftime.t
 libdatetime-perl-1.57/t/13strftime.t
+@@ -322,7 +322,7 @@
+ my $c_format = $en_locale->datetime_format;
+ $c_format
+ =~ s/\{1\}/$en_locale->month_format_abbreviated->[8] . ' 7, 1999'/e;
+-$c_format =~ s/\{0\}/'1:02:42 ' . $en_locale->am_pm_abbreviated->[1]/e;
++$c_format =~ s/\{0\}/'1:02:42 ' . $en_locale->am_pm_abbreviated->[1]/e;
+ 
+ return {
+ '%%'=> '%',
+@@ -366,7 +366,7 @@
+ '%w'=> '2',
+ '%W'=> '36',
+ '%x'=> $en_locale->month_format_abbreviated->[8] . ' 7, 1999',
+-'%X'=> '1:02:42 ' . $en_locale->am_pm_abbreviated->[1],
++'%X'=> '1:02:42 ' . $en_locale->am_pm_abbreviated->[1],
+ '%y'=> '99',
+ '%Y'=> '1999',
+ '%z'=> '+',

Bug#1025834: Not the full name of GPL at the bottom of the page

[Diederik de Haas]

Control: reassign -1 debbugs 2.6.0

On Sat, 10 Dec 2022 13:56:54 +0500 Akbarkhon Variskhanov 
 wrote:
> Package: bugs.debian.org
> Severity: minor
> Tags: newcomer patch
> X-Debbugs-Cc: akbarkhon.variskha...@gmail.com


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

Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel

[YunQiang Su]

Mathieu Malaterre  于2022年12月9日周五 17:51写道：
>
> On Fri, Dec 9, 2022 at 10:29 AM Andreas Tille  wrote:
> >
> > Hi Mathieu,
> >
> > Am Tue, Dec 06, 2022 at 08:38:43AM +0100 schrieb Mathieu Malaterre:
> > > I do not have a clean answer to this, but in my experience it is
> > > getting more and more difficult to compile anything on mipsel with
> > > g++-12. The default option `-g -O2` seems to imply `take as much
> > > memory as you want to get things to compile` so this end up crossing
> > > the 2GB hard-limit.
> > >
> > > For example here is what webkit is doing to work around the symptoms:
> > >
> > > * 
> > > https://salsa.debian.org/webkit-team/webkit/-/blob/debian/2.39.1-1/debian/rules#L66-71
> >
> > Thanks for the hint.  I tried this but this does not work since the R
> > build system does not respect external set variables.  Since chances
> > are really low that this package will be used on mipsel I asked for
> > removal on this architecture.
>
> Totally agree! Let's start the cabal against mipsel as a release arch.
>

As the MIPS porter, in fact I don't anticipate it.
Since the current version has some problems; Y2038 is the most serious.

And we are also working on new mipsel port with:
 * -mnan=2008
 * -mfp64
 * -mmsa
 * -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
 * -D_TIME_BITS=64

-- 
YunQiang Su

Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t

[Paul Gevers]

Control: found -1 2.115.3
Control: tag -1 - moreinfo

On 10-12-2022 22:55, Axel Beckert wrote:

Ehm, that version no more in the archive anywhere. Did you maybe mean
2.115.3 as currently in Testing and Unstable? (Feel free to remove the
moreinfo tag once this is clarified.)


I meant, I see the issue *since* that version. But indeed, that's a bit 
weird if not commented on. I have added a `found` version now.



Will have to look into it again, but I fear in short term, it means to
either reduce the tests or only run a subset on non-amd64
architectures.


If the test can't easily support other architectures (which is fine in 
my opinion) than please ensure it only runs on amd64. I advice to do 
that by adding a "Architecture: amd64" field to d/t/control.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025419: libunwind 1.6.2-2 upgrade makes xorg crash on startup

[Thomas Glanzmann]

Hello,
the issue is already fixed upstream in libunwind.

Cheers,
Thomas

Bug#1025419: libunwind 1.6.2-2 upgrade makes xorg crash on startup

[Thomas Glanzmann]

Hello,
at least the problem on apple silicon systems is due to libunwind
assuming 4k page size. Find the patch by Daniel Moody here:

https://tg.st/u/0001-libunwind-1.6.2-dynamic-page-size.patch

Janne Grunau pointed me to it.

Cheers,
Thomas

Bug#1025883: nvidia-driver: Please consider ingesting the 255.60 version.

[Lukasz Miller]

Package: nvidia-driver
Version: 515.48.07-1
Severity: wishlist
X-Debbugs-Cc: lukan...@gmail.com

Dear Maintainer,

please condsider ingesting the 525.60 series driver into experimental. Main 
points speaking for that would be:
* Ability to build and use wayland compositirs in Vulkan mode.
* Improved stability of sid wayland compoitors (potential, but seems to be the 
case for me)
* New features enabling many newgames to be run with DXVK/Proton usking RTX and 
DLSS.

Not opening the issue od open vs. closed kernrl modules here, but that may be a 
point too.

Thank you for your grat work maitiaining this.

Lukasz Miller 

Bug#1021562: pahole: Update for building Linux kernel with newer toolchains

[Domenico Andreoli]

On Sun, Dec 11, 2022 at 08:22:38AM +0100, Salvatore Bonaccorso wrote:
> Hi Domenico,
> 
> On Sat, Dec 10, 2022 at 09:01:06PM +0100, Salvatore Bonaccorso wrote:
> > Hi Domenico,
> > 
> > On Sat, Dec 10, 2022 at 04:32:33PM +, Domenico Andreoli wrote:
> > > On Sat, Dec 10, 2022 at 10:27 AM Domenico Andreoli  
> > > wrote:
> > > 
> > > > On Fri, Dec 09, 2022 at 11:24:23PM +0100, Salvatore Bonaccorso wrote:
> > > > > Hi Domenico,
> > > >
> > > > Hi Salvatore,
> > > >
> > > > > On Tue, Oct 11, 2022 at 01:41:23PM +0200, Domenico Andreoli wrote:
> > > > > > On Mon, Oct 10, 2022 at 08:51:48PM +0200, Jan-Benedict Glaw wrote:
> > > > > > > Package: pahole
> > > > > > > Distribution: sid
> > > > > > >
> > > > > > > Hi!
> > > > > >
> > > > > > Hi Jan-Benedict!
> > > > > >
> > > > > > >
> > > > > > > [...]
> > > > > > >
> > > > > > > I think that's caused wrt. this thread:
> > > > > > > https://www.spinics.net/lists/dwarves/msg01719.html, it would be
> > > > nice
> > > > > > > to have this fixed in Debian's `pahole`.
> > > > > >
> > > > > > Agreed, it's time for a new upload. I'll try to prepare it in the
> > > > coming days.
> > > > >
> > > > > Did you found time to work on a update including the required changes
> > > > > for pahole?
> > > >
> > > > No but I looked at it right now.
> > > >
> > > > >
> > > > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=bcc648a10cbcd0b96b84ff7c737d56ce70f7b501
> > > >
> > > > This is not enough, other commits are also needed. I'll try to finish
> > > > it this afternoon.
> > > >
> > > > > The last uploads for src:linux FTBFS on arm64 for both 6.0.12-1 and
> > > > > 6.1~rc8-1~exp1, with
> > > > >
> > > > >
> > > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=arm64&ver=6.0.12-1&stamp=1670586537&raw=0
> > > > >
> > > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=arm64&ver=6.1%7Erc8-1%7Eexp1&stamp=1670583119&raw=0
> > > >
> > > > By EOB you either will have an RFS (my sub-key expired, the new one
> > > > will not be usable soon enough) or will be free to proceed on your own.
> > > >
> > > 
> > > I managed to prepare a new upload, I tested it on both amd64 and arm64,
> > > where I was able to reproduce the problem.
> > > 
> > > As anticipated, here is my upload at
> > > https://mentors.debian.net/package/dwarves/ signed with a subkey not yet 
> > > in
> > > the keyring. Please review before uploading.
> > 
> > Thanks for your time on it! I just have uploaded your package.
> 
> And confirming linux/6.0.12-1 on arm64 did now built sucessfully:
> https://buildd.debian.org/status/fetch.php?pkg=linux&arch=arm64&ver=6.0.12-1&stamp=1670742711&raw=0

That's good, thank you for the update.

Dom

> 
> Regards,
> Salvatore

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05


signature.asc
Description: PGP signature

Bug#1025884: src:ddnet: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: ddnet
Version: 16.0.2-1
Severity: serious
Control: close -1 16.4-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ddnet has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package failed to build on 
s390x where it built successfully in the past.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=ddnet



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025885: src:gatb-core: fails to migrate to testing for too long: arch removal not handled adequately

[Paul Gevers]

Source: gatb-core
Version: 1.4.2+dfsg-9
Severity: serious
Control: close -1 1.4.2+dfsg-11
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:gatb-core has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. You filed a removal request 
(bug #1024827) but didn't follow up when more information was requested 
by ftp-master as far as I know.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=gatb-core



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025019: python-aiosmtpd: (autopkgtest) needs update for python3.11: Can't decode base64

[Charlemagne Lasse]

Control: tags -1 + fixed-upstream patch

Patch can be found at
https://github.com/aio-libs/aiosmtpd/commit/827f2321b7a926f3e8ba2aad6387b36c7c2e0b9a.patch

Bug#1025886: src:mozillavpn: fails to migrate to testing for too long: piuparts issue and FTBFS on mips*el

[Paul Gevers]

Source: mozillavpn
Version: 2.2.0-1
Severity: serious
Control: close -1 2.9.0-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:mozillavpn has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package failed to build 
on mipsel and mips64el, where it built successfully in the past. Also 
piuparts hints there is an issue in the version in unstable.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=mozillavpn



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025887: FTBFS: ambiguous method call

[Hans Joachim Desserud]

Source: biojava4-live
Version: 4.2.12+dfsg-7
Severity: serious
Tags: ftbfs patch

Dear Maintainer,

biojava4-live currently fails to build with the following error message:
compile:
[mkdir] Created dir: 
/build/1st/biojava4-live-4.2.12+dfsg/build/biojava4-structure/classes
[javac] 
/build/1st/biojava4-live-4.2.12+dfsg/biojava-structure/build.xml:86: 
warning: 'includeantruntime' was not set, defaulting to 
build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 483 source files to 
/build/1st/biojava4-live-4.2.12+dfsg/build/biojava4-structure/classes
[javac] 
/build/1st/biojava4-live-4.2.12+dfsg/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/ZipChemCompProvider.java:239: 
error: reference to newFileSystem is ambiguous
[javac] try (FileSystem fs = 
FileSystems.newFileSystem(m_zipFile, null)) {

[javac] ^
[javac]   both method newFileSystem(Path,ClassLoader) in FileSystems 
and method newFileSystem(Path,Map) in FileSystems match
[javac] 
/build/1st/biojava4-live-4.2.12+dfsg/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/ZipChemCompProvider.java:296: 
error: reference to newFileSystem is ambiguous
[javac] try (FileSystem zipfs = 
FileSystems.newFileSystem(zipFile, null)) {

[javac]^
[javac]   both method newFileSystem(Path,ClassLoader) in FileSystems 
and method newFileSystem(Path,Map) in FileSystems match

[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use or override a deprecated API that 
is marked for removal.

[javac] Note: Recompile with -Xlint:removal for details.
[javac] Note: 
/build/1st/biojava4-live-4.2.12+dfsg/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/MetalBondConsumer.java 
uses unchecked or unsafe operations.

[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors

(see 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/biojava4-live.html 
for details)


When casting the null value to match one of the signatures this resolves 
the build error. See the attached patch. I wasn't able to find the exact 
upstream commit to reference since the file has been moved around, but 
the patch is based on latest upstream and how they have chosen to 
resolve the issue.


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgDescription: Add explicit cast to fix ambiguos method call error

Taken from upstream to match expected method call 
https://github.com/biojava/biojava/blob/master/biojava-structure/src/main/java/org/biojava/nbio/structure/chem/ZipChemCompProvider.java

---

Origin: upstream
Forwarded: not-needed
Last-Update: 2022-12-11

--- biojava4-live-4.2.12+dfsg.orig/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/ZipChemCompProvider.java
+++ biojava4-live-4.2.12+dfsg/biojava-structure/src/main/java/org/biojava/nbio/structure/io/mmcif/ZipChemCompProvider.java
@@ -236,7 +236,7 @@ public class ZipChemCompProvider impleme
 		final String filename = "chemcomp/" + recordName+".cif.gz";
 
 		// try with resources block to read from the filesystem.
-		try (FileSystem fs = FileSystems.newFileSystem(m_zipFile, null)) {
+		try (FileSystem fs = FileSystems.newFileSystem(m_zipFile, (ClassLoader)null)) {
 			Path cif = fs.getPath(filename);
 
 			if (Files.exists(cif)) {
@@ -293,7 +293,7 @@ public class ZipChemCompProvider impleme
 		*/
 
 		// Copy in each file.
-		try (FileSystem zipfs = FileSystems.newFileSystem(zipFile, null)) {
+		try (FileSystem zipfs = FileSystems.newFileSystem(zipFile, (ClassLoader)null)) {
 			Files.createDirectories(pathWithinArchive);
 			for (File f : files) {
 if (!f.isDirectory() && f.exists()) {

Bug#1003242: python3-mailman-hyperkitty: Need a newer version to match mailman core

[Charlemagne Lasse]

Control: tags -1 + fixed-upstream patch security
Justification: CVE-2021-35058

https://gitlab.com/mailman/mailman-hyperkitty/-/commit/18816fbd4130a9f08b0885e0421c963879808921
https://gitlab.com/mailman/mailman-hyperkitty/-/commit/df9cdc44dc59c7ed78097ef8f5ba3db46e7a92e9

But it might be better to package 1.2.x instead of cherry-picking this patch

Bug#1024395: Fixed on my laptop with 1+2.06+7

[Eric Valette]

After upgrading all grub*2.06-7 at once,I confirm it works on both 
laptop and Desktop.


Now, the dependency still seems strange to me expeciallya s the signed 
version come usually later than the rest.


-- eric

Bug#1025888: msmtp: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: msmtp 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of msmtp debconf
messages. A draft was posted a few weeks ago to the debian-l10n-dutch
mailing list asking for review. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1025889: marisa: autopkgtest regression with ruby 3.1

[Sebastian Ramacher]

Source: marisa
Version: 0.2.6-11
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

marisa's autopkgtest fail with ruby 3.1 as default:

autopkgtest [01:14:47]: test ruby: [---
=== ruby ===
:85:in 
`require': cannot load such file -- marisa (LoadError)
from 
:85:in 
`require'
from bindings/ruby/sample.rb:1:in `'
autopkgtest [01:14:48]: test ruby: ---]
autopkgtest [01:14:48]: test ruby:  - - - - - - - - - - results - - - - - - - - 
- -
ruby FAIL non-zero exit status 1
autopkgtest [01:14:48]: test ruby:  - - - - - - - - - - stderr - - - - - - - - 
- -
:85:in 
`require': cannot load such file -- marisa (LoadError)
from 
:85:in 
`require'
from bindings/ruby/sample.rb:1:in `'


https://ci.debian.net/data/autopkgtest/testing/amd64/m/marisa/29170299/log.gz

Cheers
-- 
Sebastian Ramacher

Bug#1025890: RM: flang -- ROM; replaced by flang from llvm-toolchain

[Alastair McKinstry]

Package: ftp.debian.org
Severity: normal

Please remove flang from unstable (libflang-dev in particular) as flang is to 
be build directly from llvm-toolchain

Bug#1025685: [Pkg-rust-maintainers] Bug#1025685: rust-pyo3: please upgrade to v0.17

[Bastian Germann]

Am 11.12.22 um 04:40 schrieb Peter Michael Green:
I've prepared an upload of verion 0.17 of pyo3 and built/tested breezy with it. It built successfully the autopkgtest 
passed. Any objections if I go ahead and update to this version?


The backported patch for 0.16 in the proposed python-cryptography version was 
updated to fit 0.17:
https://github.com/pyca/cryptography/pull/6935

So I think it it okay to update. Please go ahead.

Bug#1025814: dput-ng: dcut: taunting documentation about 0-day upload differences

[Mattia Rizzolo]

Control: tag -1 moreinfo

On Fri, Dec 09, 2022 at 11:04:46AM -0800, Vagrant Cascadian wrote:
>-d, --days=DAYS
>
>   Reschedule the upload to DAYS days. Takes a
>   numeric argument from 0 to 15 corresponding to
>   the respective delayed queues. Note, 0-day is
>   not the same as uploading to incoming
>   straight.
> 
> So, 0-day is not the same as uploading directly, that much is clear, but
> ... how is it different?

Well, uploading directly means uploading to ftp:/pub/UploadQueue/
whereas uploading to 0-day means uploading to
ftp:/pub/UploadQueue/DELAYED/0-day/ ...

(incidentally, that mention of "incoming" is also wrong: incoming is the
archive (hmm is it only a suite nowadays?) where uploads are accepted
*into* before dinstall; it has nothing to do with the uploading queues
AFAIK)

> Does that mean I should not use 0-day?  Where
> is documentation about the differences? Does it really matter for any
> practical purposes?

Practical differences for the uploader however… I'm not really aware of
any indeed.

> Maybe it would be better to provide some reference where to look for
> more information, or if it doesn't really make much difference, just
> leave the comment about 0-day not being the same out entirely.

This part is quite old, and I'm not aware of the actual facts.

ISTR that word-of-mouth told me in the past that uploading to 0-day
would delay the upload for 1 queued run (i.e. 15 minutes if the
configuration hasn't changed), but this has never been proved to me, so
no idea really.  I'm CCing debian-dak in the hope that somebody will
shine some light.
I have a nagging sensation that the answer lies in the code :>
https://salsa.debian.org/ftp-team/dak/-/blob/master/tools/debianqueued-0.9/debianqueued
if somebody wants to read and figure it out.


Note that it *is* relevant when rescheduling a delayed upload, as there
is no way with .commands files to move an upload from the /DELAYED/
directories into the main queue directory for immediate processing, so
rescheduling to 0-day is AFAIK the only way to make a deferred upload to
skip the rest of the wait.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1025891: python3-acme: Sets invalid CSR version in bullseye

[Mathias Ertl]

Package: python3-acme
Version: 1.12.0-2
Severity: important
Tags: patch upstream
X-Debbugs-Cc: m...@er.tl

Dear Maintainer,
 x
The python3-acme library included in Debian stable sets an invalid CSR version
3 when creating CSRs. The issue has been solved upstream in version 1.29.0 and
2.1.0 [1], so Debian testing/unstable are no longer affected. Ubuntu versions
22.04 LTS and earlier are also affected.

The cryptography library implemented validation of the CSR version in
38.0.0 [2], so ACMEv2 server implementations based on this cryptography
version no longer work with older versions of certbot (which ofc uses
python3-acme).

The PR from the certbot repo[1] gives the (trivial) fix. Several other
affected clients also link to the PR. I have verified that applying the patch
solves the issue.


[1] https://github.com/certbot/certbot/pull/9334
[2] https://github.com/pyca/cryptography/issues/7231

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

Kernel: Linux 5.15.0-56-generic (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages python3-acme depends on:
ii  ca-certificates20210119
ii  python33.9.2-3
ii  python3-cryptography   3.3.2-1
ii  python3-josepy 1.2.0-2
ii  python3-openssl20.0.1-1
ii  python3-pkg-resources  52.0.0-4
ii  python3-requests   2.25.1+dfsg-2
ii  python3-requests-toolbelt  0.9.1-1
ii  python3-rfc33391.1-2
ii  python3-six1.16.0-2
ii  python3-tz 2021.1-1

python3-acme recommends no packages.

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

-- no debconf information

Bug#560245: [Logcheck-devel] Bug#560245: logcheck: violations.ignore.d causes lines to not show up at any level

[Richard Lewis]

On Fri, 21 May 2010 11:15:58 +0200 Hannes von Haugwitz
 wrote:
> Dan D Niles wrote:

> > suppose you have a program that outputs:
> >
> > This is a failure test
> >
> > This would show up a a SECURITY event.  It isn't really a SECURITY
> > event, so you exclude it in violations.ignore.d.  Now it does not show
> > up as a SECURITY event, but it also does not show up as a SYSTEM event.
> > That behavior is not what I would expect.

This (old) bug was marked wonfix, but I think it should be fixed - I
suspect many people find logcheck's current design confusing. And I
think there is a case for simplification, which i set out below. -
which would close this bug.

I just wasted a few hours failing to understand the logic in
logcheck's 'security events', (only to find i was
doing an entirely unrelated stupid thing with my rules - but getting
to that realisation took far too long because logcheck is
over-complicated)

I thought i would write down how logcheck works, which will illustrate
why I think it's a more complicated than it needs to be

Currently the approach to filtering rules is the following 4 steps - I
would suggest that step 2 and 3 are needlessly complicated and not
actually what users want.

1. Get log entries from logs/journal
1a. Extract recent log entries (function logoutput)
1b. Remove blank lines, sort and remove duplicates (function: none,
done in the top-level code)
1c rules are also cleaned - blank lines and comments are removed
(cleanrules function)

2. Find all lines that _do_ match patterns in /etc/logcheck/cracking.d
(grepoutput function does all of steps 2,3; actual work is done by
'cleanchecked')
- im not going to properly describe this but it is similar to step 3
below, although it depends on whether SUPPORT_CRACKING_IGNORE is set
to 1 or not.
 Report anything as "attack alerts"

3. Find all lines that _do_ match patterns in /etc/logcheck/violations.d
If a file /etc/logcheck/violations.d/foo finds any matches, then
function greplogoutput filters these through
/etc/logcheck/violations.ignore.d/foo
/etc/logcheck/violations.ignore.d/logcheck-foo

if 'foo' is 'logcheck' then:
   all files /etc/logcheck/violations.ignore.d/*  (ie all ignore files
filter matches from logcheck, whereas matches from 'su' are only
filtered by logcheck-su
   anything in /etc/violations.d that does _not_ start with 'logcheck'
(because matches have/will be separately reported)
end if

/etc/logcheck/violations.ignore.d/local
/etc/logcheck/violations.ignore.d/local-* (ie any file starting 'local')
/etc/logcheck/cracking.d/* (because any matches from were reported as
cracking attempts at step 2)

Within this step (which is all within greplogoutput function) it is
completely arbitrary whether a step is skipped if we already know
there are no more entries to match or not.
the naming convention is baffling and not correctly documented.

At the end, results are reported as "security events for foo", except
if foo is "logcheck" then just "security events".

4. Now start again with _all_ the log entries from step 1
4a. Filter _out_ anything matching any rules in /etc/logcheck/ignore.d.*
(but taking account of REPORTLEVEL, ie if REPORTLEVEL=server then we
use ignore.d.paranoid and ignore.d.workstation only)
The naming of files does not matter, but things are applies in the
order returned by run-parts
(Actually files from different reportlevels are concatenated)
4b. Filter _out_ anything left through cracking.d/* and violations.d/*
(because any matches from here were dealt with at steps 2 or 3)
(this does not use the cracking.ignore.d or violations.ignore.d at all)
4c, Anything left  is reported as "system events" - extremely easy to
miss that this is different from a "security event" imo

-

I think most people assume that step 4 is all that is happening, and i
think steps 2 and 3 probably cause more complication than they are
worth. They certainly caused this bug report.

For example - logcheck-database ships violations.d/logcheck-su and
violations.ignore.d/logcheck-su and ignore.d.server/su - these dont
work very well out of the box (doesnt the second line of
violations.ignore.d/su make all the other lines pointless?). but
working out which one to edit and why is baffling.

And number of times i have thought i found a bug because i failed to
spot a report was a "security event" rather than a "system event" i
dont want to think about

I would suggest logcheck could be simplified as follows

1. Extract log entries - no need for changes
2. Filter through ignore.d.* as above - no changes.
3. Look for potential violations attempts
3a. Any output from 2 (ie any rules not filtered out) is filtered
through /etc/logcheck/important.d/*
(I am suggesting merging everything currently in cracking.d and
violations.d into important.d. But we could keep them separate if
people want.
- 

Bug#1025658: libboost-python1.74-dev: Python 3.11 changes break loading of boost-python using extensions

[Nilesh Patra]

Hi Anton/Gio,

This is breaking a bunch of packages, including packages that directly
affect key-packages.
Since you maintain boost, could you please apply Stuart's patch and upload?

Thanks!

On Wed, 07 Dec 2022 12:25:10 +1100 Stuart Prescott  wrote:
> Package: libboost-python1.74-dev
> Version: 1.74.0-17+b2
> Severity: serious
> Tags: patch
> Justification: Breaks reverse dependencies with Python 3.11
> X-Debbugs-Cc: stu...@debian.org, debian-pyt...@lists.debian.org
> 
> 
> Dear Maintainer,
> 
> Python 3.11 has changed some details around types and GC; boost's enum.cpp
> needs modifying to cope. The result of this change is that trying to
> load an extension compiled with Debian's boost 1.74 results in a C++
> exception being thrown and, since not properly handled, the following
> rather obscure error:
> 
> SystemError: initialization of $module raised unreported exception
> 
> Further details courtesy of Alastair McKinstry's debugging work are to
> be found at
> 
> https://bugs.debian.org/1024911#14
> 
> So far, we've spotted this problem in:
> 
> cctbx: https://bugs.debian.org/1024859
> ecflow: https://bugs.debian.org/1024911
> python-pgmagick: https://bugs.debian.org/1023909
> 
> The attached patch is a (trivial) backport of the upstream change for
> this:
> 
> https://github.com/boostorg/python/commit/a218babc8daee904a83f550fb66e5cb3f1cb3013
> 
> I've verified that the attached patch solves the Python 3.11 incompatibility
> of python-pgmagick, allowing it to successfully build, meaning that it is
> now able to load its boost-python extensions for the test suite.
> 
> regards
> Stuart

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1025892: Installation at Ryzen 7000 not fully successfully

[Bernhard]

Package: installation-reports

Boot method: USB stick
Image version: Self-made installation files with daily build 20221210-00:19
Date: 2022-12-11

Machine: Self-made Desktop PC with Ryzen 7000
Processor: Ryzen 9 7900X
Memory: 32GB
Partitions: 

Output of lspci -knn:

> 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14d8]
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8877]
> 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Device [1022:14d9]
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8877]
> 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14da]
> 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14da]
> 00:02.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14db]
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8877]
>   Kernel driver in use: pcieport
> 00:02.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14db]
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8877]
>   Kernel driver in use: pcieport
> 00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14da]
> 00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14da]
> 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14da]
> 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14dd]
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8877]
>   Kernel driver in use: pcieport
> 00:08.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14dd]
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8877]
>   Kernel driver in use: pcieport
> 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
> [1022:790b] (rev 71)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8877]
> 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge 
> [1022:790e] (rev 51)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:8877]
> 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14e0]
> 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14e1]
> 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14e2]
> 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14e3]
> 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14e4]
> 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14e5]
> 00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14e6]
> 00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:14e7]
> 01:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:43f4] (rev 01)
>   Subsystem: ASMedia Technology Inc. Device [1b21:3328]
>   Kernel driver in use: pcieport
> 02:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:43f5] (rev 01)
>   Subsystem: ASMedia Technology Inc. Device [1b21:3328]
>   Kernel driver in use: pcieport
> 02:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:43f5] (rev 01)
>   Subsystem: ASMedia Technology Inc. Device [1b21:3328]
>   Kernel driver in use: pcieport
> 02:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:43f5] (rev 01)
>   Subsystem: ASMedia Technology Inc. Device [1b21:3328]
>   Kernel driver in use: pcieport
> 02:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:43f5] (rev 01)
>   Subsystem: ASMedia Technology Inc. Device [1b21:3328]
>   Kernel driver in use: pcieport
> 02:08.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:43f5] (rev 01)
>   Subsystem: ASMedia Technology Inc. Device [1b21:3328]
>   Kernel driver in use: pcieport
> 02:0c.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:43f5] (rev 01)
>   Subsystem: ASMedia Technology Inc. Device [1b21:3328]
>   Kernel driver in use: pcieport
> 02:0d.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device 
> [1022:43f5] (rev 01)
>   Subsystem: ASMedia Technology Inc. Device [1b21:3328]
>   Kernel driver in use: pcieport
> 04:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller 
> I225-V [8086:15f3] (rev 03)
>   DeviceName: Intel I225-V LAN
>   Subsystem: ASUSTeK Computer Inc. Device [1043:87d2]
>   Kernel driver in use: igc
>   Kernel modules: igc
> 05:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA 
> Controller [1b21:0612] (rev 02)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:858d]
>   Kernel driver in use: ahci
>   Kernel modules: ahci
> 06:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA 
> Controller [1b21:0612] (rev 02)
>   Subsystem: ASUSTeK Computer Inc. Device [1043:858d]
>

Bug#1025893: RFS: carburetor/4.0-1 [ITP] -- GTK frontend for Tractor

[Danial Behzadi]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : carburetor
  Version  : 4.0-1
  Upstream contact : Danial Behzadi 
* URL  : 
* License  : GPL-3+, CC-BY-SA-4.0
* Vcs  : 


  Section  : net

The source builds the following binary packages:

 carburetor - GTK frontend for Tractor

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


 

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


 dget -x 



Changes for the initial release:

carburetor (4.0-1) unstable; urgency=medium
.
  * Initial release. (Closes: #1025365)

Regards,
--
Danial Behzadi

Bug#1024160: base: Running XFCE under x2GO fails with grey screen

[Dmitry Shachnev]

Hi,

On Sat, Dec 10, 2022 at 06:55:14PM +, Graeme Vetterlein wrote:
> For My Information, where could I have watched the upstream commits ? That
> might have caused me to notice it sooner?

https://gitlab.gnome.org/GNOME/libwnck/-/commits/master

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1025870: libwlroots10: phosh crashes sometimes due to bug in wlroots (patch available)

[Guido Günther]

Hi Lukas,
On Sat, Dec 10, 2022 at 11:26:00PM +0100, Lukas Straub wrote:
> Package: libwlroots10
> Version: 0.15.1-3
> Severity: normal
> X-Debbugs-Cc: lukasstra...@web.de
> 
> Dear Maintainer,
> 
> I'm using Mobian phosh on a pinephone (non-pro). Sometimes (twice per week) 
> when waking from
> sleep, phosh crashes due to a bug in wlroots and brings down the whole 
> session with it.
> 
> This bug has been solved upstream, there's a patch in wlroots 0.16 that can 
> be backported
> to 0.15 and fixes this issue.
> 
> It's the patch here:
> https://gitlab.gnome.org/World/Phosh/phoc/-/issues/300#note_1595892
> 
> I tested wlroots 0.15.1-3 with this patch applied and that solved the
> issue for me.

I've had that on the list for this weekend, uploaded now. In the future
if you test a patch you can also make an MR right away on salsa (in this
case at https://salsa.debian.org/swaywm-team/wlroots) as this makes
things easier to apply.

Cheers,
 -- Guido

> 
> Regards,
> Lukas Straub
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: arm64 (aarch64)
> 
> Kernel: Linux 5.15-sunxi64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages libwlroots10 depends on:
> ii  libc62.36-5
> ii  libdrm2  2.4.114-1
> ii  libegl1  1.5.0-1
> ii  libgbm1  22.2.4-1
> ii  libgles2 1.5.0-1
> ii  libinput10   1.22.0-1
> ii  libpixman-1-00.42.2-1
> ii  libseat1 0.7.0-5+b1
> ii  libudev1 252.2-1
> ii  libwayland-client0   1.21.0-1
> ii  libwayland-server0   1.21.0-1
> ii  libxcb-composite01.15-1
> ii  libxcb-dri3-01.15-1
> ii  libxcb-icccm40.4.1-1.1
> ii  libxcb-present0  1.15-1
> ii  libxcb-render-util0  0.3.9-1+b1
> ii  libxcb-render0   1.15-1
> ii  libxcb-res0  1.15-1
> ii  libxcb-shm0  1.15-1
> ii  libxcb-xfixes0   1.15-1
> ii  libxcb-xinput0   1.15-1
> ii  libxcb1  1.15-1
> ii  libxkbcommon01.4.1-1
> 
> libwlroots10 recommends no packages.
> 
> libwlroots10 suggests no packages.
> 
> -- no debconf information

Bug#1024824: The software outputs: "No access to printer device file" ...

[Bernhard Übelacker]

The software outputs: "No access to printer device file".

Normal user should be added to lp group to make `mtink` work
and it has been added to it indeed, so it is in the /etc/group file
beside the `lp` and `lpadmin` groups, yet the software seems
to be unable to access device file from the USB-conncted EPSON XP-2100. 


Dependencies and suggestions are installed in the system.

I have experienced this package to be working on Ubuntu 22.04 a month ago.




Hello Nicholas,
I guess the Maintainer would need more information about this issue.
A first step might be to provide a "strace" of a mtink startup.

Therefore please install the packages: bsdutils strace

Then execute following line in a terminal:
  script -c "LANG=C strace -f mtink" -a "mtink-strace_$(date 
+%Y-%m-%d_%H-%M-%S).log"

This will create a file like mtink-strace_2022-12-11_14-16-46.log
Maybe you could compress this file and attach it to your answer to this mail?
(Please use the "reply all", to have the bug in CC in your answer.)

Kind regards,
Bernhard

Bug#1025894: breaks the autopkgtest of nipype

[Pierre Gruet]

Source: python3-nibabel
Version: 4.0.2-1
Severity: serious

Hi,

It seems the module nibabel.trackvis is not shipped anymore with nibabel 4.0.2,
which breaks the autopkgtest of nipype. See for instance
https://ci.debian.net/packages/n/nipype/testing/amd64/

Cheers,

-- 
Pierre

Bug#1025892: Installation at Ryzen 7000 not fully successfully

[Diederik de Haas]

On Sunday, 11 December 2022 14:16:04 CET Bernhard wrote:
> igc :04:00.0 eno1: PCIe link lost, device now detached

https://lore.kernel.org/all/20221031170535.77be0...@kernel.org/ looks relevant

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

Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel

[Jeffrey Walton]

On Thu, Dec 1, 2022 at 1:15 AM Andreas Tille  wrote:
>
> Hi,
>
> Am Wed, Nov 30, 2022 at 10:08:14PM +0100 schrieb Paul Gevers:
> > Source: r-cran-glmmtmb
> > Version: 1.1.4+dfsg-3
> > Severity: serious
> > Tags: ftbfs
> > Justification: ftbfs
> >
> > Dear maintainer(s),
> >
> > Your package failed to build from source on mipsel, where it built
> > successfully in the past.
> >
> > https://buildd.debian.org/status/fetch.php?pkg=r-cran-glmmtmb&arch=mipsel&ver=1.1.5%2Bdfsg-1&stamp=1669057119&raw=0
> > ...
> > cc1plus: out of memory allocating 1058400 bytes after a total of 59473920 
> > bytes
>
> Isn't this just a matter of the autobuilders hardware?
>
> If not I do not see any other clue but removing the package for mipsel.

You might also see how many make jobs the build system is using. If
it's more than 1, then halve the number of jobs.

I used to experience the crash often on early ARM dev-boards with 1GB
of RAM and no swap file when building Crypto++. I used to run 'make -j
4' and it would crash the compiler. The workaround (for us) was to run
'make -j 1'.

Eventually I decided to add a swap file to the SDcard and set
swappiness to a low number, like 2. That fixed most of the performance
problems, but we would eat SDcards about every 3 to 6 months.

Jeff

Bug#866314: linux-image-4.9.0-3-686-pae: 100+ times slower disk writes on 4.x+/i386/16+RAM, compared to 3.x

[Diederik de Haas]

Control: tag -1 -moreinfo

On Wednesday, 1 June 2022 01:27:32 CET Diederik de Haas wrote:
> What's the current status wrt this bug?

Just saw upstream commit 630dc25e43dacfb5af94cd41532e77c47ec1caff which should 
become part of 6.1-rc9 and/or 6.1 and it would be interesting to know if that 
would make a difference wrt this bug.

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

Bug#1025895: logcheck: Please add autopkgtests

[Richard Lewis]

Package: logcheck
Version: 1.3.24
Severity: important
Tags: patch
X-Debbugs-Cc: richard.lewis.deb...@googlemail.com

Dear Maintainer,

logcheck currently has a broken testsuite, and no autopkgtests. The first 
attached patch fixes both of these

The second patch adds salsa-ci.yml so these run on salsa.debian.org - piuparts 
will fail: I will submit a patch
to fix that as a separate bug report

The 3rd patch allows logcheck to work if there are no /etc/logcheck/ignore.d.* 
directories - this is a separate bug, but
if i recall correctly, the test will fail until this is fixed.

(Can submit as a MR on salsa once the ryslog bug is fixed - i have omitted some 
other local patch, but i've been using these locally
for nearly a year)

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

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

Versions of packages logcheck depends on:
ii  adduser3.118
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  lockfile-progs 0.1.18
ii  logtail1.3.24+local6
ii  mime-construct 1.11+nmu3

Versions of packages logcheck recommends:
ii  logcheck-database  1.3.25+local1

Versions of packages logcheck suggests:
ii  cron [cron-daemon]   3.0pl1-137
ii  rsyslog [system-log-daemon]  8.2102.0-2+deb11u1
ii  systemd  247.3-7+deb11u1

-- Configuration Files:
/etc/logcheck/header.txt [Errno 13] Permission denied: 
'/etc/logcheck/header.txt'
/etc/logcheck/logcheck.conf [Errno 13] Permission denied: 
'/etc/logcheck/logcheck.conf'
/etc/logcheck/logcheck.logfiles [Errno 13] Permission denied: 
'/etc/logcheck/logcheck.logfiles'
/etc/logcheck/logcheck.logfiles.d/journal.logfiles [Errno 13] Permission 
denied: '/etc/logcheck/logcheck.logfiles.d/journal.logfiles'
/etc/logcheck/logcheck.logfiles.d/syslog.logfiles [Errno 13] Permission denied: 
'/etc/logcheck/logcheck.logfiles.d/syslog.logfiles'

-- no debconf information
diff --git a/debian/tests/01-logcheck b/debian/tests/01-logcheck
index fae06f4d..b305cb48 100644
--- a/debian/tests/01-logcheck
+++ b/debian/tests/01-logcheck
@@ -1,20 +1,205 @@
-#!/bin/bash
+#!/bin/bash -ue
 
-set -eu
+LOGFILE="$(mktemp)"
+STATE="$(mktemp -d)"
+#shellcheck disable=SC2064 # we want to expand variables now
+trap "rm -rf '$LOGFILE' '$STATE'" 0 INT QUIT ABRT PIPE TERM
 
-LOGFILE=$(mktemp)
-trap 'rm -f ${LOGFILE}' 0 INT QUIT ABRT PIPE TERM
+chown root:adm "$LOGFILE"
+chmod 0640 "$LOGFILE"
+chown logcheck:logcheck "$STATE"
+chmod 0750 "$STATE"
 
-chmod 0640 "${LOGFILE}"
-chgrp adm "${LOGFILE}"
 
-echo "Jan 31 06:51:07 debian-sid-amd64 su: pam_unix(su-l:auth) failure; 
logname=testuser uid=1000 euid=0 tty=pts/7 ruser=testuser rhost=  user=root" >> 
"${LOGFILE}"
-echo "Jan 31 06:51:09 debian-sid-amd64 su: FAILED SU (to root) testuser on 
pts/7" >> "${LOGFILE}"
+STATUS="PASS"
 
-echo "Jan 31 07:15:01 debian-sid-amd64 CRON[588228]: (root) CMD (command -v 
debian-sa1 > /dev/null && debian-sa1 1 1)" >> "${LOGFILE}"
-echo "Jan 31 07:17:01 debian-sid-amd64 CRON[588240]: (root) CMD (   cd / && 
run-parts --report /etc/cron.hourly)" >> "${LOGFILE}"
+# usage: run_test "name of test - description" \
+#./expected_output.file  \
+# command_to_test arg1 arg2...
+# The global variable "$STATUS" is set to "FAIL" if this test fails
+run_test(){
+   local name="$1"
+   local expected_file="$2"
+   local expected_exit="$3"
+   shift 3
+   local my_status=""
+   local diff="" code="0"
 
-EXPECTED_OUTPUT="This email is sent by logcheck. If you no longer wish to 
receive
+   "$@" > ./actual_file 2>&1 || code="$?"
+
+   diff="$(diff -u -- "$expected_file" ./actual_file 2>&1 || :)"
+
+   if [ "$code" != "$expected_exit" ]; then
+   my_status="ERROR (expected exit: 
$expected_exit, actual: $code)"
+   elif [ -z "$diff" ]; then
+   my_status="PASS"
+   else
+   my_status="FAIL"
+   fi
+
+   echo "** $my_status: $name"
+   if [ "$my_status" != "PASS" ]; then
+   STATUS=FAIL
+   cat < "${LOGFILE}" < /dev/null && debian-sa1 1 1)
+Jan 31 07:17:01 debian-sid-amd64 CRON[588240]: (root) CMD (   cd / && 
run-parts --report /etc/cron.hourly)
+EOF
+
+cat > as-root< as-root-with-args< expected < expected < list
+run_test "-L list where list contains unreadable file" expected 1 \
+  

Bug#1025896: RFS: zope.security/5.8-1 [QA] -- Zope Security Framework

[Håvard F . Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "zope.security":

 * Package name : zope.security
   Version  : 5.8-1
   Upstream contact : Zope Foundation and Contributors 
 * URL  : https://github.com/zopefoundation/zope.security
 * License  : Zope-2.1
 * Vcs  :
   Section  : zope

The source builds the following binary packages:

  python3-zope.security - Zope Security Framework

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

  https://mentors.debian.net/package/zope.security/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zope.security/zope.security_5.8-1.dsc

Changes since the last upload:

 zope.security (5.8-1) unstable; urgency=medium
 .
   * QA upload.
   * New upstream release.
   * Change from nose to pytest. Closes: #1018676
 Using Colin Watson implementation from zope.interface.
   * Drop zope.testrunner as BD, mark BD used for testing with '!nocheck'

Regards,
Håvard

Bug#1025897: logcheck: Make logcheck piuparts clean

[Richard Lewis]

Package: logcheck
Version: 1.3.24
Severity: important
Tags: patch
X-Debbugs-Cc: richard.lewis.deb...@googlemail.com

Dear Maintainer,

logcheck currently fails the 'piuparts test' because its postinst does a 
recursive chown/chmod on all rules
- but logcheck is not the only package to install files in /etc/logcheck and so 
the postinst is actually changeing
permissions of files from other packages: if you install and purge logcheck the 
systems is not the same state
as if logcheck was never installed, because permissions have changed.

The chown/chmod is not needed: logcheck runs as the 'logcheck' user, and we 
'want'* to make /etc/logcheck not world-readable - but individual rules dont 
need to be
kept secret as long as the outer dir is closed.

(*do we really want this? it is pretty marginal benefit, but i suppose it 
prevents people seeing local modifications and local rules.)

So this patch to postinst:
- restores /etc/logcheck to root:root
- restores all contents of /etc/logcheck to a-sx,u=rwX,go=rX
- makes only the outer directories /var/lib/logcheck and /etc/logcheck owned 
logcheck:logcheck and sets permissions drwxr-x---

(the first two could be removed once bookworm is stable)


In postrm, when logcheck is purged, /etc/logcheck will still exit is other 
packages had rules installed. So reset /etc/logcheck to root:root and 
u=rwx,go=rx - this ensures that the system is in the
same state as wehn logcheck was installed. (Is this the right thing to do? i am 
not totally sure. it does mean anything left in
/etc/logcheck after purge becomes readable. not sure this matters, but maybe it 
does - and i dont see how logcheck can pass piuparts without this)

Again, can submit as a merge request in due course

(Surely there is a better way to add the logcheck user than is done here? but i 
didnt fundamentally change this part)


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

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

Versions of packages logcheck depends on:
ii  adduser3.118
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  lockfile-progs 0.1.18
ii  logtail1.3.24+local6
ii  mime-construct 1.11+nmu3

Versions of packages logcheck recommends:
ii  logcheck-database  1.3.25+local1

Versions of packages logcheck suggests:
ii  cron [cron-daemon]   3.0pl1-137
ii  rsyslog [system-log-daemon]  8.2102.0-2+deb11u1
ii  systemd  247.3-7+deb11u1

-- Configuration Files:
/etc/logcheck/header.txt [Errno 13] Permission denied: 
'/etc/logcheck/header.txt'
/etc/logcheck/logcheck.conf [Errno 13] Permission denied: 
'/etc/logcheck/logcheck.conf'
/etc/logcheck/logcheck.logfiles [Errno 13] Permission denied: 
'/etc/logcheck/logcheck.logfiles'
/etc/logcheck/logcheck.logfiles.d/journal.logfiles [Errno 13] Permission 
denied: '/etc/logcheck/logcheck.logfiles.d/journal.logfiles'
/etc/logcheck/logcheck.logfiles.d/syslog.logfiles [Errno 13] Permission denied: 
'/etc/logcheck/logcheck.logfiles.d/syslog.logfiles'

-- no debconf information
diff --git a/debian/logcheck.postinst b/debian/logcheck.postinst
index b38db801..fc5aff57 100644
--- a/debian/logcheck.postinst
+++ b/debian/logcheck.postinst
@@ -10,86 +10,65 @@ set -e
 #*  `abort-deconfigure' `in-favour'
 #`removing'
 #   
-# for details, see http://www.debian.org/doc/debian-policy/ or
-# the debian-policy package
-#
-# quoting from the policy:
-# Any necessary prompting should almost always be confined to the
-# post-installation script, and should be protected with a conditional
-# so that unnecessary prompting doesn't happen if a package's
-# installation fails and the `postinst' is called with `abort-upgrade',
-# `abort-remove' or `abort-deconfigure'.
 
 case "$1" in
   configure)
-# Add logcheck user
-# check for logcheck user or bad version without home
-# touch cron job on updating accounts to fix #284788
+# Ensure the logcheck user exists
+# touch cron job on to fix #284788
 if ! getent passwd logcheck > /dev/null; then
 adduser --quiet --system --home /var/lib/logcheck --no-create-home \
 --group logcheck || true
 touch /etc/cron.d/logcheck || true
 fi
 
-# check for logcheck group in case account exists without group
-if ! getent group logcheck >/dev/null; then
+# Ensure the logcheck group exists (the user could have been created 
without a group)
+if ! getent group logcheck > /dev/null; then
 addgroup --system logcheck
 usermod -g logcheck logcheck
 fi
 

Bug#1025822: golang-github-masterminds-sprig-v3-dev: missing package relationships (conflicting files)

[Peymaneh]

Hi

Am 10.12.22 um 01:06 schrieb Cyril Brulebois:

My sid development chroot broke during the latest dist-upgrade due to:

 Unpacking golang-github-masterminds-sprig-v3-dev (3.2.3-1) ...
 …
  trying to overwrite 
'/usr/share/gocode/src/github.com/Masterminds/sprig/crypto.go', which is also 
in package golang-github-masterminds-sprig-dev 3.2.2-1

The newer package has no Breaks/Replaces that are customary when moving files 
around:
   
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces


I am very sorry about that.
I uploaded a new revision declaring breaks/replaces relations.


And for what it's worth, even if it's too late, I'm not sure the package
rename was really required in the first place. We have a number of
packages with either -vN or .vN in their names, but there are no strict
naming rules that I know of. :)


masterminds-sprig was on of the first Go libraries I have packaged. When 
I re-read the Go Team conventions[1] over a year later, I had the 
impression the impression that former naming was not correct and that I 
should my beginners mistake, but I might have been overeager 🥴


Sorry again for the inconvenience

Peymaneh

[1] https://go-team.pages.debian.net/packaging.html#_naming_conventions_2


OpenPGP_signature
Description: OpenPGP digital signature

Bug#475553: This bug is fixed by the fix for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023755

[Richard Lewis]

Once 1023755 is fixed, this can be closed, i think
(the patch in 475553 is similar, but not as good as the one adopted
for the other bug - longer, does not account for the format in the
journal and lacks NEWS.Debian entry)

Bug#1019865: evolution Hangs and goes to 100% CPU usage on compose

[Jeremy Bicha]

Could y'all verify whether you still have this issue?

Please upgrade to Evolution 3.46.2 which just landed in Testing today.
Please log out and log back in to make sure you're running the latest
version of evolution-data-server also.

Thank you,
Jeremy Bicha

Bug#996780: gnome-boxes: Systematic system freeze few seconds after launching a Windows WM

[Jeremy Bicha]

It has been a year since the last comment and many things have changed
in Debian in that time. Are you still experiencing this issue?

Thank you,
Jeremy Bicha

Bug#1012428: gnome-shell-common: drmModeAddFB2WithModifiers Failed

[Jeremy Bicha]

Many things have changed in Debian in the past 6 months. Are you still
experiencing this issue?

Thank you,
Jeremy Bicha

On Mon, Jun 6, 2022 at 7:39 PM Tim McConnell  wrote:
> Package: gnome-shell-common
> Version: 42.1-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: tmcconnell...@gmail.com
>
> Dear Maintainer,
>
> What led up to the situation? Do not know, my logs are getting multiple 
> reports
> of this error(?)
>
> What exactly did you do (or not do) that was effective (or
>  ineffective)? Unknown
>
> What was the outcome of this action?
> 11433 lines of:
> gnome-shell[4883]: Failed to scan out client buffer: 
> drmModeAddFB2WithModifiers
> failed: Invalid argument
>
> What outcome did you expect instead?
> Not getting all of those errors in one hour
>
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386

Bug#1025871: RFS: d11amp/0.59-1 [ITP] -- Simple MP3 player (All green now)

[Adam Borowski]

On Sat, Dec 10, 2022 at 11:32:04PM +0100, Thomas Dettbarn wrote:
> The package is ready, and you can use it to have your
> very own retro MP3 player on your desktop. It has the
> big advantage that the license situation is 100% clear.

While, as Bastian mentioned, we have plenty of MP3 players in the archive
already, I don't believe that's a reason to block someone from working on
something they consider to be worth spending their time on -- as long as
there's no significant cost to the project.

A random package like this costs us ~1KB increase of Packages index
downloads, minor cycles during archive rebuilds, and basically that's it.

>  * Package name : d11amp
>Version  : 0.59-1
>Upstream contact : Thomas Dettbarn
>  * URL  :https://www.dettus.net/d11amp/
>  * License  : BSD-2-Clause
>  * Vcs  :https://github.com/dettus/d11amp/

> The source builds the following binary packages:
>   d11amp - Simple MP3 player

Alas, the package fails for me:
/bin/sh: 1: pkg-config: not found [eleventy times]
src/audiooutput/audiooutput_portaudio.c:28:10: fatal error: portaudio.h: No 
such file or directory
   28 | #include 
  |  ^
src/decoder/decoder.c:26:10: fatal error: gtk/gtk.h: No such file or directory
   26 | #include 
  |  ^~~
In file included from src/gui/theme_manager.c:33:
src/gui/theme_manager.h:30:10: fatal error: gdk-pixbuf/gdk-pixbuf.h: No such 
file or directory
   30 | #include 
  |  ^
... and so on.  Full log attached.


I see, your Build-Depends list binary libraries rather than headers:
Build-Depends: debhelper (>=11),
   debhelper-compat (= 13),
   libc6 (>= 2.34),
   libcairo2 (>= 1.2.4),
   libgdk-pixbuf-2.0-0 (>= 2.22.0),
   libglib2.0-0 (>= 2.31.8),
   libgtk-4-1 (>= 4.0.0),
   libmpg123-0 (>= 1.28.0),
   libportaudio2 (>= 19+svn20101113),
   libzip4 (>= 0.10)
What you need is to replace the runtimes with devel packages:
libgtk-4-dev
libzip-dev
and so on.

There's no need to list libc6/libc-dev (it's in build-essential), the
bdependency on debhelper is redundant (you already pull debhelper-compat),
and as shown by the "pkg-config: not found" you need pkgconf (which is
the new implementation of pkg-config that replaced it).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄
sbuild (Debian sbuild) 0.84.2 (08 December 2022) on valinor.angband.pl

+==+
| d11amp 0.59-1 (amd64)Sun, 11 Dec 2022 03:27:26 + |
+==+

Package: d11amp
Version: 0.59-1
Source Version: 0.59-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-be06e3f8-860f-46d9-bca5-2719e07ee12e'
 with '<>'
I: NOTICE: Log filtering will replace 'build/d11amp-0YbdFE/resolver-QbUZvN' 
with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

d11amp_0.59-1.dsc exists in .; copying to chroot
I: NOTICE: Log filtering will replace 'build/d11amp-0YbdFE/d11amp-0.59' with 
'<>'
I: NOTICE: Log filtering will replace 'build/d11amp-0YbdFE' with '<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper (>= 11), debhelper-compat (= 13), libc6 (>= 
2.34), libcairo2 (>= 1.2.4), libgdk-pixbuf-2.0-0 (>= 2.22.0), libglib2.0-0 (>= 
2.31.8), libgtk-4-1 (>= 4.0.0), libmpg123-0 (>= 1.28.0), libportaudio2 (>= 
19+svn20101113), libzip4 (>= 0.10), build-essential, fakeroot
Filtered Build-Depends: debhelper (>= 11), debhelper-compat (= 13), libc6 (>= 
2.34), libcairo2 (>= 1.2.4), libgdk-pixbuf-2.0-0 (>= 2.22.0), libglib2.0-0 (>= 
2.31.8), libgtk-4-1 (>= 4.0.0), libmpg123-0 (>= 1.28.0), libportaudio2 (>=

Bug#1025899: libtracefs: Please update to latest upstream version.

[Sebastian Andrzej Siewior]

Package: libtracefs
Version: 1.5.0-1
Severity: wishlist

Please update libtracefs to v1.6+. The later trace-cmd depends on 1.6+

Sebastian

Bug#963059: has_options and missing link

[Jan Rauberg]

The handling for options has moved to /etc/X11/Xsession. The following 
part is missing in /etc/x2go/Xsession:


OPTIONS="$(
  if [ -r "$OPTIONFILE" ]; then
cat "$OPTIONFILE"
  fi
  if [ -d /etc/X11/Xsession.options.d ]; then
run-parts --list --regex '\.conf$' /etc/X11/Xsession.options.d | 
xargs -d '\n' cat

  fi
)"

has_option() {
  # Ensure that a later no-foo overrides an earlier foo
  if [ "$(echo "$OPTIONS" | grep -Eo "^(no-)?$1\>" | tail -n 1)" = "$1" 
]; then

return 0
  else
return 1
  fi
}

Otherwise .Xresource in users home won't be parsed.



Also the font link is still missing:

/usr/share/nx/fonts -> /usr/share/fonts/X11

That causes also missing fonts in Xterm or Emacs.

Bug#1024805: bullseye-pu: package libvirt/7.0.0-3+deb11u1

[Guido Günther]

Hi Adam,
On Wed, Dec 07, 2022 at 08:22:41PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2022-11-25 at 15:19 +0100, Guido Günther wrote:
> > Fix lxc container reboots and shutdown (#983871, #991773).
> > 
> 
> Please go ahead.

Uploaded now, thanks!
 -- Guido

> 
> Regards,
> 
> Adam
> 

Bug#893083: with more history would be nice

[Geert Stappers]

Hi,

Three weeks ago it didn't came to my mind
that there could be more Debian history found.

In my defense, I had only the information
of a wishlist bug report open for as four years
and version 2.10-2 in unstable and 2.10-1 in old-old-stable.

I'm fine with deleting the current repo at Salsa
to make room for a repository that has more history.

And I'm fine with continueing with the current content
in the git repository at Salsa.

Thing I'm concerned about is having bookworm released
with a hello package without VCS fields.


Groeten
Geert Stappers
DD
-- 
Silence is hard to parse

Bug#1025739: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Andreas Tille]

Hi Andreas,

Am Sat, Dec 10, 2022 at 11:41:11AM +0100 schrieb Andreas Metzler:
> 
> I have given this a a little bit of time. This seems to work:
> 
> 1. Copy configure.ac from upstream's 2.3.2h2 branch.

Seems in tag 2.3.2h2 happened what I tried with 2.3.2[1] at least
the resulting configure.ac is identical after
autoupdate && autoreconf -f -i

> 2. Add 'export AUTOHEADER = true' to debian/rules.

I tried this, but the build fails for me and Salsa CI[2] with

  configure.ac:479: the top level
  sh: 1: Syntax error: Unterminated quoted string
  autoreconf: error: true' failed with exit status: 2

I admit I can't find that unterminated quoted string near line 479.

Thanks for the attempt to help anyway

Andreas.

[1] https://salsa.debian.org/med-team/hmmer2/-/blob/master/debian/rules#L25-L26 
[2] https://salsa.debian.org/med-team/hmmer2/-/jobs/3642966#L917

-- 
http://fam-tille.de

Bug#1025739: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Boyuan Yang]

Hi,

在 2022-12-11星期日的 16:35 +0100，Andreas Tille写道：
> Hi Andreas,
> 
> Am Sat, Dec 10, 2022 at 11:41:11AM +0100 schrieb Andreas Metzler:
> > 
> > I have given this a a little bit of time. This seems to work:
> > 
> > 1. Copy configure.ac from upstream's 2.3.2h2 branch.
> 
> Seems in tag 2.3.2h2 happened what I tried with 2.3.2[1] at least
> the resulting configure.ac is identical after
>     autoupdate && autoreconf -f -i
> 
> > 2. Add 'export AUTOHEADER = true' to debian/rules.
> 
> I tried this, but the build fails for me and Salsa CI[2] with
> 
>   configure.ac:479: the top level
>   sh: 1: Syntax error: Unterminated quoted string
>   autoreconf: error: true' failed with exit status: 2
> 
> I admit I can't find that unterminated quoted string near line 479.

Not sure if it is the root cause, but there's an obvious typo with quote at
L12:
https://salsa.debian.org/med-team/hmmer2/-/blob/423388accbb8c622edb663c845f1f5a6336256e1/debian/rules#L12
.



> Thanks for the attempt to help anyway
> 
>     Andreas.
> 
> [1]
> https://salsa.debian.org/med-team/hmmer2/-/blob/master/debian/rules#L25-L26 
> [2] https://salsa.debian.org/med-team/hmmer2/-/jobs/3642966#L917

Thanks,
Boyuan Yang


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

Bug#1025739: Is an autogenerated configure shell script non-editable source

[Andreas Tille]

Hi Paul,

Am Sun, Dec 11, 2022 at 12:21:18PM +0800 schrieb Paul Wise:
> > So far for the actual case (bug report in CC).
> > 
> > For the general case I somehow understand the consensus here on the list
> > that a missing configure.ac can be considered a bug but the severity
> > serious is not really rectified.  If I understood this correctly I would
> > reset the severity to important at the beginning of next week.
> 
> Personally I feel that severity serious is the correct one,

Could you give some arguents for your feeling.  May be I interpreted
posts in this thread wrongly but I read it like serious is a to high
severity.  Moreover what does this mean for other packages where
configure.ac is missing?  I'm 100% sure that we have quite some packages
where this is the case.  I admit I'm not motivated to seek for these
and file a MBF but if there is some consensus about this we should act
accordingly.  On the other hand if we have no consensus it should not
be of RC critical severity.

> but it sounds like the fix for the bug is quite simple:
> 
> https://lists.debian.org/msgid-search/y5rir8qidvj4r...@argenau.bebt.de

I think the fact whether a fix is simple or not does not matter for the
severity of a bug.  Unfortunately the solution is not as simple as
described (as I wrote in response to the said mail).

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1025739: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Andreas Tille]

Am Sun, Dec 11, 2022 at 10:43:37AM -0500 schrieb Boyuan Yang:
> 
> Not sure if it is the root cause, but there's an obvious typo with quote at
> L12:
> https://salsa.debian.org/med-team/hmmer2/-/blob/423388accbb8c622edb663c845f1f5a6336256e1/debian/rules#L12
> .

Ahhh, thanks - I was seeking for the quoting issue inside configure.ac!

Thanks a lot
   Andreas.

-- 
http://fam-tille.de

Bug#973617: fonts-materialdesignicons-webfont: New upstream release

[Julian Gilbey]

On Wed, Jan 13, 2021 at 05:06:43PM +, Julian Gilbey wrote:
> On Wed, Jan 13, 2021 at 10:51:08AM +, Julian Gilbey wrote:
> > On Mon, Nov 02, 2020 at 04:32:54PM +0100, Michele Cane wrote:
> > > Package: fonts-materialdesignicons-webfont
> > > Version: 1.6.50-3
> > > Severity: wishlist
> > > 
> > > Dear Maintainer,
> > > 
> > > Would it be possible to upload the latest upstream release.
> > [...]

There has been no progress or follow-up on this bug report in over two
years.

I also recently noticed that some of the icons in the existing font
are brand icons which should be removed because of licensing issues.
Also, this package is not built from source - it is the precompiled
fonts build using @mdi/font-build.

My proposal is to repackage this using @mdi/font-build to actually
build the font from source, removing the brand icons first.  I'll NMU
this when the required node packages are packaged and have reached
unstable.  If you'd prefer me to take the package over, or to add
myself as an uploader, I'm also happy to do that.  I'll do the work in
a new repository since the existing one (as already noted earlier in
this thread) is too muddled to really build on it.

Best wishes,

   Julian

Bug#1025739: Fwd: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Philip Rinn]

Forgot to keep the bug report in the loop :-/

+ here is a stable link to the unterminated quote: 
https://salsa.debian.org/med-team/hmmer2/-/blob/423388accbb8c622edb663c845f1f5a6336256e1/debian/rules#L12



 Weitergeleitete Nachricht 
Betreff: Re: Is an autogenerated configure shell script non-editable source 
(Was: Bug#1025739: hmmer2: missing source for configure)

Datum: Sun, 11 Dec 2022 16:52:49 +0100
Von: Philip Rinn 
An: debian-de...@lists.debian.org, Andreas Tille 

Hi Andreas,


Hi Andreas,

Am Sat, Dec 10, 2022 at 11:41:11AM +0100 schrieb Andreas Metzler:


I have given this a a little bit of time. This seems to work:

1. Copy configure.ac from upstream's 2.3.2h2 branch.


Seems in tag 2.3.2h2 happened what I tried with 2.3.2[1] at least
the resulting configure.ac is identical after
autoupdate && autoreconf -f -i


2. Add 'export AUTOHEADER = true' to debian/rules.


I tried this, but the build fails for me and Salsa CI[2] with

  configure.ac:479: the top level
  sh: 1: Syntax error: Unterminated quoted string
  autoreconf: error: true' failed with exit status: 2

I admit I can't find that unterminated quoted string near line 479.



that's not surprising as you indeed have an unterminated "'" in 
https://salsa.debian.org/med-team/hmmer2/-/blob/master/debian/rules#L12


Best regards
Philip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022703: dieharder: Broken output or infinite loop after sts_runs test

[Bernhard Übelacker]

On Mon, 24 Oct 2022 12:22:13 -0500 Dirk Eddelbuettel  wrote:

|diehard_birthdays|   0|   100| 100|0.99449351|  PASSED
| ###CUT OUT BY ME###
| sts_runs|   2|10| 100|0.93620636|  PASSED
| ###AND THEN MANY EMPTY LINES APPEARING EVERY ~30 SEC###

Darn. Would you have a moment to maybe jump into the code for sts_runs and
see what may be wrong now with its convergence criterion or count or ... ?

The upstream code is pretty 'dead' and I am being forced to update the code
every now and then for better compliance with update compilers so it could be
that I swapped in a size_t for another loop variable type and maybe created a
signed / unsigned bug?

Otherwise the only fix may be to take sts_run out of the set for 'all' tests.

Dirk




Hello Dirk,
but is the problem not the test following the passed sts_run, the test 
sts_serial?

I could reproduce it inside a VM with a current bookworm/testing installation.

The blank lines look like produced by output_table_line, output.c:527,
unfortunately with variable tflag=0, therefore no actual test information is 
printed.

As far as I see the tflag gets overwritten because the neighbour variable 
tsamples
got 4 bytes of memory reserved in global.c, but unfortunately in
sts_serial it gets written with a size of 8 bytes, therefore tflag gets a value 
of 0.
And therefore the following tests do execute but just output the "new line".

In the build log there are a few "warning: useless type name in empty 
declaration".
This I guess is the result of the semicolon, which makes the compiler see
the "unsigned int;" and the "tsamples;" separately
and, I guess, makes tsamples default to integer, therefore just the 4 bytes.

   globals.c:22  #define off_t unsigned int;

Because this define seems kind of dangerous and "unsigned int" would
still not be right I think it should get removed
and maybe sys/types.h get included. (See at the bottom)
A package with this change prints also the tests below sts_run.

Kind regards,
Bernhard




$ dieharder -a -g 13


$ gdb -q --pid $(pidof dieharder)
...
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/source/dieharder/orig/dieharder-3.31.1.3
Source directories searched: 
/home/benutzer/source/dieharder/orig/dieharder-3.31.1.3:$cdir:$cwd
(gdb) b output_table_line
Breakpoint 1 at 0x561a373b5050: file ./dieharder/output.c, line 350.
(gdb) cont
Continuing.

Breakpoint 1, output_table_line (dtest=0x7f886dee6aa0 , 
test=0x561a38b2e830) at ./dieharder/output.c:350
350 350  if(tflag & TDESCRIPTION){
(gdb) cont
Continuing.

Breakpoint 1, output_table_line (dtest=0x7f886dee6a60 
, test=0x561a38b2e830) at ./dieharder/output.c:350
350  if(tflag & TDESCRIPTION){
(gdb) print tflag
$1 = 12799
(gdb) print &tflag
$2 = (unsigned int *) 0x561a373e5d64 
(gdb) watch *(unsigned int *) 0x561a373e5d64
Hardware watchpoint 2: *(unsigned int *) 0x561a373e5d64
(gdb) dele 1
(gdb) cont
Continuing.

Hardware watchpoint 2: *(unsigned int *) 0x561a373e5d64

Old value = 12799
New value = 0
sts_serial (test=0x561a38b2fe30, irun=0) at ./libdieharder/sts_serial.c:117
117  MYDEBUG(D_STS_SERIAL){
(gdb) bt
#0  sts_serial (test=0x561a38b2fe30, irun=0) at ./libdieharder/sts_serial.c:117
#1  0x7f886de97437 in add_2_test (dtest=0x7f886dee65e0 , 
test=0x561a38b2fe30, count=100) at ./libdieharder/std_test.c:230
#2  0x561a373b69fc in execute_test (dtest_num=102) at 
./dieharder/run_test.c:92
#3  0x561a373b65ef in run_all_tests () at ./dieharder/run_all_tests.c:47
#4  0x561a373b3332 in main (argc=4, argv=0x7fffcca27f88) at 
./dieharder/dieharder.c:88
(gdb) list
112   * decently if we could farm out the blocks of bits to be run 
efficiently
113   * over a network relative to the time required to generate them.
114   */
115  nb = 16;/* Just ignore sts_serial_ntuple for now */
116  tsamples = test[0]->tsamples;  /* ditto */
117  MYDEBUG(D_STS_SERIAL){
118
printf("#==\n");
119printf("# Starting sts_serial.\n");
120printf("# sts_serial: Testing ntuple = %u\n",nb);
121  }
(gdb) display/i $pc
1: x/i $pc
=> 0x7f886de97c42 :  mov(%r15),%eax
(gdb) print &tsamples
$3 = (off_t *) 0x561a373e5d60 
(gdb) print sizeof(tsamples)
$4 = 8
(gdb) frame 4
#4  0x561a373b3332 in main (argc=4, argv=0x7fffcca27f88) at 
./dieharder/dieharder.c:88
88   run_all_tests();
(gdb) print sizeof(tsamples)
$6 = 4




$ grep -E "off_t.*tsamples" . -Rn
./dieharder/globals.c:29:off_t tsamples;/* Generally should be "a lot". 
 off_t is u_int64_t. */
./dieharder/globals.c:74:off_t tsamples;/* Generally should be "a lot". 
 off_t is u_int64_t. */
./include/dieharder/libdieharder.h:194: extern off_t tsamples;/* Generally should 
be "a lot".  off_t is u_int64_t. */




https://buildd.debian.org/status/fetch.php?pkg=dieharder&arch=amd64&ver=3.31.1.3-1&stamp=1659884648&raw=0

gcc -DH

Bug#991647: libisocodes: FTBFS in bullseye

[Santiago Vila]

reopen 991647
found 991647 1.2.3-1
retitle 991647 libisocodes: FTBFS in bullseye
thanks

Reopening because packages in stable must build in stable.

I know this removes the version tracking info that this was fixed in 
1.2.4-1, but that's ok, because (after the package was removed from 
instable) version 1.2.4-1 is not currently in any Debian release.


Thanks.

Bug#1025864: mesa-vulkan-drivers: no more vulkan support for Intel HD Graphics 4000

[Alexis Murzeau]

On Sat, 10 Dec 2022 20:31:50 +0100 Alexis Murzeau  wrote:

Package: mesa-vulkan-drivers
Version: 22.3.0-2
Severity: important

Dear Maintainer,

* What led up to the situation?
After upgrading mesa packages (including mesa-vulkan-drivers) from version
22.2.4-1 to 22.3.0-2, I found that the intel hd graphics 4000 has no more
vulkan drivers.

vulkaninfo does not list the GPU anymore (only the llvmpipe driver is listed
now):
[...]

Maybe something must be added to the Debian package build to enable the driver
again.
I guess "intel_hasvk" should be added to VULKAN_DRIVERS in d/rules to fix this
issue.


I've tried to build the package with intel_hasvk added to VULKAN_DRIVERS,
and it fixed the issue. My intel iGPU is back available with vulkan.

I've opened a merge request with the modification on Salsa:

https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/22

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

Bug#1025900: pw-mon doesn't accept -N option

[Michael Gold]

Package: pipewire-bin
Version: 0.3.62-1

Dear Maintainer,

The man page and help text of pw-mon list a '-N' option, but pw-mon does
not accept it:

$ pw-mon -N
pw-mon: invalid option -- 'N'
pw-mon [options]
  -h, --helpShow this help
  --version Show version
  -r, --remote  Remote daemon name
  -N, --no-colors   disable color output
  -C, --color[=WHEN]whether to enable color support. WHEN 
is `never`, `always`, or `auto`
$ 

- Michael


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

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

Versions of packages pipewire-bin depends on:
ii  libasound2   1.2.8-1
ii  libc62.36-6
ii  libdbus-1-3  1.14.4-1
ii  libncursesw6 6.3+20220423-2
ii  libpipewire-0.3-00.3.62-1
ii  libpipewire-0.3-modules  0.3.62-1
ii  libreadline8 8.2-1.2
ii  libsndfile1  1.1.0-3+b1
ii  libtinfo66.3+20220423-2

Versions of packages pipewire-bin recommends:
ii  dbus-user-session  1.14.4-1
ii  rtkit  0.13-4+b1
ii  wireplumber0.4.12-1+b1

pipewire-bin suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1025822: golang-github-masterminds-sprig-v3-dev: missing package relationships (conflicting files)

[Cyril Brulebois]

Hallo Peymaneh,

Peymaneh  (2022-12-11):
> I am very sorry about that.
> I uploaded a new revision declaring breaks/replaces relations.

No worries at all!

I was in the middle of dealing with other packages so I didn't patch it
out myself at the time (only filed this bug report), but your fix looks
good to me, thanks.

> masterminds-sprig was on of the first Go libraries I have packaged.
> When I re-read the Go Team conventions[1] over a year later, I had the
> impression the impression that former naming was not correct and that
> I should my beginners mistake, but I might have been overeager 🥴

I can definitely understand the feeling. :) I might be overcautious in
the opposite direction when it comes to changing package names, as that
might mean another trip to NEW, and chasing all packages depending (at
build time and/or at run time) on the old package names, which I suppose
means more work than the status quo (i.e. not renaming).


Tschüss!
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1025867: src:spyder: unsatisfied build dependency in testing: python3-qdarkstyle (< 3.1~)

[Julian Gilbey]

Hi Paul,

On Sat, Dec 10, 2022 at 10:14:22PM +0100, Paul Gevers wrote:
> Source: spyder
> Version: 5.3.3+dfsg-3
> Severity: serious
> Tags: sid bookworm
> User: debian...@lists.debian.org
> Usertags: edos-uninstallable
> 
> Dear maintainer(s),
> 
> Dose [1] is reporting a build issue with your package, it's missing a
> build dependency. Obviously your build dependencies shouldn't be
> removed from testing, but unfortunately there are multiple scenarios
> where that can happen nevertheless. To uphold our social contract,
> Debian requires that packages can be rebuild from source in the suite
> we are shipping them, so currently this is a serious issue with your
> package in testing.

Yes, something weird happened; I don't know why python3-qdarkstyle was
allowed to migrate to testing and break spyder.

But anyway, spyder is a complete mess right now because of the python
3.11 transition, and this is the least of the problems :(  When I am
able to upgrade to spyder 5.4.0, it uses the python3-qdarkstyle
currently in testing, so all will be OK again.  But it may well be
several weeks before that happens.

Best wishes,

   Julian

Bug#1025882: libdatetime-perl ftbfs with new libdatetime-locale-perl

[gregor herrmann]

On Sun, 11 Dec 2022 00:39:22 -0800, Steve Langasek wrote:

> libdatetime-perl currently FTBFS in unstable because a of a test failure
> introduced by a new libdatetime-locale-perl:
> 
> [...]
> #   Failed test '%c is Sep 7, 1999, 1:02:42 PM'
> #   at t/13strftime.t line 311.
> #  got: 'Sep 7, 1999, 1:02:42<80>PM'
> # expected: 'Sep 7, 1999, 1:02:42 PM'
> 
> #   Failed test '%X is 1:02:42 PM'
> #   at t/13strftime.t line 311.
> #  got: '1:02:42<80>PM'
> # expected: '1:02:42 PM'
> # Looks like you failed 2 tests of 49.
> [...]
> 
> This also shows up as an autopkgtest failure at
> .
> 
> I do no know why these format strings are now using a unicode non-breaking
> space instead of a space as they were before, but it's simple enough to
> update the test suite to match the current output.  Please see attached.

Thanks for this bug report.

A corresponding upstream issue is
https://github.com/houseabsolute/DateTime-Locale/issues/34

and this is fixed in DateTime 1.59, which I'm about to upload.


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#893083: with more history would be nice

[Santiago Vila]

El 11/12/22 a las 16:25, Geert Stappers escribió:

I'm fine with deleting the current repo at Salsa
to make room for a repository that has more history.


Please do so. It's not only about the history but about the conventions, 
there is a DEP document which recommends a layout for branches and so 
on, and the repo you created (I'm afraid) does not follow it at all.


This is really not a matter of adding fields to a control file, if that 
was all, it would be already done. This really involves a change in the 
way I'm maintaining the package, which at this point I'm still not 
comfortable.


My plan for this would be to create it under my "sanvila" namespace.
But there are a lot of other work to do which is more important than 
this. This is still wishlist.


Thanks.

Bug#1025901: libunistring2: Breaks system due to missing libunistring.so.2

[Eric Valette]

Package: libunistring2
Version: 1.1-1~experimental1
Severity: critical
Justification: breaks unrelated software

This breaks NetworkManaget, apt ...

nmcli 
nmcli: error while loading shared libraries: libunistring.so.2: cannot open 
shared object file: No such file or directory

apt-cache policy libunistring2
libunistring2:
  Installed: 1.1-1~experimental1
  Candidate: 1.1-1~experimental1
  Version table:
 *** 1.1-1~experimental1 100
  1 http://ftp.fr.debian.org/debian experimental/main amd64 Packages
100 /var/lib/dpkg/status
 1.0-2 500
500 http://ftp.fr.debian.org/debian testing/main amd64 Packages
500 http://ftp.fr.debian.org/debian unstable/main amd64 Packages
 0.9.10-4 500
500 http://ftp.fr.debian.org/debian stable/main amd64 Packages
root@tri-yann4:~# apt install libunistring2=1.0-2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
/usr/lib/apt/methods/http: error while loading shared libraries: 
libunistring.so.2: cannot open shared object file: No such file or directory
E: Method http has died unexpectedly!
E: Sub-process http returned an error code (127)
E: Method /usr/lib/apt/methods/http did not start correctly


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

Kernel: Linux 5.10.158 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libunistring2 depends on:
ii  libunistring5  1.1-1~experimental1

libunistring2 recommends no packages.

libunistring2 suggests no packages.

-- no debconf information

Bug#1023479: FTBFS: t/01struct.t fails

[gregor herrmann]

On Sun, 11 Dec 2022 00:14:51 -0800, Steve Langasek wrote:

> This failure is simply due to a string change in the exception output from
> new libobject-pad-perl.  The attached patch fixes the build to look for the
> new string with quotes.  Please consider applying in Debian.

Thanks, patch applied, package uploaded.
 

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#1025871: RFS: d11amp/0.59-1 [ITP] -- Simple MP3 player (All green now)

[Thomas Dettbarn]

On 12/11/22 15:44, Adam Borowski wrote:

On Sat, Dec 10, 2022 at 11:32:04PM +0100, Thomas Dettbarn wrote:

The package is ready, and you can use it to have your
very own retro MP3 player on your desktop. It has the
big advantage that the license situation is 100% clear.

While, as Bastian mentioned, we have plenty of MP3 players in the archive
already, I don't believe that's a reason to block someone from working on
something they consider to be worth spending their time on -- as long as
there's no significant cost to the project.

A random package like this costs us ~1KB increase of Packages index
downloads, minor cycles during archive rebuilds, and basically that's it.


  * Package name : d11amp
Version  : 0.59-1
Upstream contact : Thomas Dettbarn
  * URL  :https://www.dettus.net/d11amp/
  * License  : BSD-2-Clause
  * Vcs  :https://github.com/dettus/d11amp/
The source builds the following binary packages:
   d11amp - Simple MP3 player

Alas, the package fails for me:
/bin/sh: 1: pkg-config: not found [eleventy times]
src/audiooutput/audiooutput_portaudio.c:28:10: fatal error: portaudio.h: No 
such file or directory
28 | #include 
   |  ^
src/decoder/decoder.c:26:10: fatal error: gtk/gtk.h: No such file or directory
26 | #include 
   |  ^~~
In file included from src/gui/theme_manager.c:33:
src/gui/theme_manager.h:30:10: fatal error: gdk-pixbuf/gdk-pixbuf.h: No such 
file or directory
30 | #include 
   |  ^
... and so on.  Full log attached.


I see, your Build-Depends list binary libraries rather than headers:
Build-Depends: debhelper (>=11),
debhelper-compat (= 13),
libc6 (>= 2.34),
libcairo2 (>= 1.2.4),
libgdk-pixbuf-2.0-0 (>= 2.22.0),
libglib2.0-0 (>= 2.31.8),
libgtk-4-1 (>= 4.0.0),
libmpg123-0 (>= 1.28.0),
libportaudio2 (>= 19+svn20101113),
libzip4 (>= 0.10)
What you need is to replace the runtimes with devel packages:
 libgtk-4-dev
 libzip-dev
and so on.

There's no need to list libc6/libc-dev (it's in build-essential), the
bdependency on debhelper is redundant (you already pull debhelper-compat),
and as shown by the "pkg-config: not found" you need pkgconf (which is
the new implementation of pkg-config that replaced it).


Meow!


Hello Adam.

Thank you so much! My previous package did not have any dependencies, I 
am still learning. :)


So, I stripped down the Build-Depends slightly, they now look like this:

Build-Depends: debhelper-compat (= 13),
   libgdk-pixbuf-2.0-dev (>= 2.22.0),
   libgtk-4-dev (>= 4.0.0),
   libmpg123-dev (>= 1.28.0),
   libzip-dev (>= 0.10),
   portaudio19-dev,
   pkgconf

What do you think?  Upload #9 on mentors.debian.net looks okay to me.


Pur.

PS: As for the "too-many-mp3-players" argument... I think it is great 
for the user to have one more
alternative. To me, this is what Open Source is all about: Not having 
one software vendor, telling
me which software I have to use; but several, to choose from. And to 
decide what works best

for me, or to become another software vendor myself. :)

Bug#780484: filler: NMU to fix RC bugs.

[Ying-Chun Liu (PaulLiu)]

Hi all,

I plan to fix #965521 and #998958, and #780484.

The debdiff is as attachment.

The plan is,
I'll wait for 10 days to see if any more comments.
And then I'll upload it to delay/10 queue.

The changes are as following:
  * Non-maintainer upload.
  * Bump debhelper to 12 (Closes: #965521)
- debian/rules: port to use dh (Closes: #998958)
  * Port to DebSrc3.0 (quilt)
  * Distribute manpage (Closes: #780484)

Yours,
Paul
diff -Nru filler-1.02/debian/changelog filler-1.02/debian/changelog
--- filler-1.02/debian/changelog2022-12-12 00:45:39.0 +0800
+++ filler-1.02/debian/changelog2022-12-10 03:20:44.0 +0800
@@ -1,3 +1,16 @@
+filler (1.02-6.4) unstable; urgency=low
+
+  [ Ying-Chun Liu (PaulLiu) ]
+  * Non-maintainer upload.
+  * Bump debhelper to 12 (Closes: #965521)
+- debian/rules: port to use dh (Closes: #998958)
+  * Port to DebSrc3.0 (quilt)
+
+  [ Jean-Michel Nirgal Vourgère  ]
+  * Distribute manpage (Closes: #780484)
+
+ -- Ying-Chun Liu (PaulLiu)   Sat, 10 Dec 2022 03:20:44 
+0800
+
 filler (1.02-6.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru filler-1.02/debian/clean filler-1.02/debian/clean
--- filler-1.02/debian/clean1970-01-01 08:00:00.0 +0800
+++ filler-1.02/debian/clean2022-12-10 03:20:44.0 +0800
@@ -0,0 +1,3 @@
+other/filler.png
+debian/filler.xpm
+filler.jar
diff -Nru filler-1.02/debian/compat filler-1.02/debian/compat
--- filler-1.02/debian/compat   2022-12-12 00:45:39.0 +0800
+++ filler-1.02/debian/compat   1970-01-01 08:00:00.0 +0800
@@ -1 +0,0 @@
-5
diff -Nru filler-1.02/debian/control filler-1.02/debian/control
--- filler-1.02/debian/control  2022-12-12 00:45:39.0 +0800
+++ filler-1.02/debian/control  2022-12-10 03:20:44.0 +0800
@@ -2,13 +2,13 @@
 Section: games
 Priority: optional
 Maintainer: James Damour (Suvarov454) 
-Build-Depends: debhelper (>= 5.0.0), dh-strip-nondeterminism
+Build-Depends: debhelper-compat (= 12), dh-strip-nondeterminism
 Build-Depends-Indep: sharutils, default-jdk
 Standards-Version: 3.8.3
 
 Package: filler
 Architecture: all
-Depends: default-jre | java1-runtime | java2-runtime
+Depends: default-jre | java1-runtime | java2-runtime, ${misc:Depends}
 Description: simple game where two players try to capture half the board
  Filler is a simple game where two players try to capture half of the board.
  Players take turns selecting colours to capture all adjacent hexes of the
diff -Nru filler-1.02/debian/filler.manpages filler-1.02/debian/filler.manpages
--- filler-1.02/debian/filler.manpages  1970-01-01 08:00:00.0 +0800
+++ filler-1.02/debian/filler.manpages  2022-12-10 03:20:44.0 +0800
@@ -0,0 +1 @@
+debian/filler.6
diff -Nru filler-1.02/debian/patches/0001_Makefile.patch 
filler-1.02/debian/patches/0001_Makefile.patch
--- filler-1.02/debian/patches/0001_Makefile.patch  1970-01-01 
08:00:00.0 +0800
+++ filler-1.02/debian/patches/0001_Makefile.patch  2022-12-10 
03:20:44.0 +0800
@@ -0,0 +1,18 @@
+Index: filler-1.02/Makefile
+===
+--- filler-1.02.orig/Makefile
 filler-1.02/Makefile
+@@ -8,10 +8,10 @@ DIR=src/friendless/games/filler
+ 
+ $(JAR):
+   mkdir classes || $(RM) -rf classes/*
+-  javac -d classes src/friendless/awt/*.java
+-  javac -classpath classes -d classes $(DIR)/*.java $(DIR)/player/*.java 
$(DIR)/remote/*.java $(DIR)/remote/messages/*.java
++  $(JAVA_HOME)/bin/javac -d classes src/friendless/awt/*.java
++  $(JAVA_HOME)/bin/javac -classpath classes:src -d classes $(DIR)/*.java 
$(DIR)/player/*.java $(DIR)/remote/*.java $(DIR)/remote/messages/*.java
+   cp -R res/* classes
+-  cd classes && jar cmf ../other/metainfo.txt $(JAR) friendless
++  cd classes && $(JAVA_HOME)/bin/jar cmf ../other/metainfo.txt $(JAR) 
friendless
+   mv classes/$(JAR) .
+ 
+ clean:
diff -Nru filler-1.02/debian/patches/0002_filler_fix_path.patch 
filler-1.02/debian/patches/0002_filler_fix_path.patch
--- filler-1.02/debian/patches/0002_filler_fix_path.patch   1970-01-01 
08:00:00.0 +0800
+++ filler-1.02/debian/patches/0002_filler_fix_path.patch   2022-12-10 
03:20:44.0 +0800
@@ -0,0 +1,10 @@
+Index: filler-1.02/other/filler
+===
+--- filler-1.02.orig/other/filler
 filler-1.02/other/filler
+@@ -1,3 +1,3 @@
+ #!/bin/sh
+-cd /usr/local/filler
+-java -Duser.language=$LANG -jar /usr/local/filler/filler.jar $*
++cd /var/games
++java -Duser.language=$LANG -jar /usr/share/java/filler.jar $*
diff -Nru filler-1.02/debian/patches/0003_add_desktop_file.patch 
filler-1.02/debian/patches/0003_add_desktop_file.patch
--- filler-1.02/debian/patches/0003_add_desktop_file.patch  1970-01-01 
08:00:00.0 +0800
+++ filler-1.02/debian/patches/0003_add_desktop_file.patch  2022-12-10 
03:20:44.0 +0800
@@ -0,0 +1,33 @@
+Index: 

Bug#1025880: libsyntax-keyword-multisub-perl: FTBFS on armhf et all due to wrong format string usage

[gregor herrmann]

On Sun, 11 Dec 2022 00:04:05 -0800, Steve Langasek wrote:

> libsyntax-keyword-multisub-perl fails to build from source on multiple
> architectures because the build-time test suite successfully captures a bug
> in the code for which there is a compiler warning during the build:
> 
>   lib/Syntax/Keyword/MultiSub.xs:52:11: warning: format ‘%d’ expects argument 
> of type ‘int’, but argument 4 has type ‘IV’ {aka ‘long long int’} [-Wformat=]
> 
> (https://buildd.debian.org/status/fetch.php?pkg=libsyntax-keyword-multisub-perl&arch=armhf&ver=0.02-2&stamp=1658361396&raw=0)

Thanks for this bug report!

Turns out there already was an upstream issue for this problem:
https://rt.cpan.org/Public/Bug/Display.html?id=140687
with a patch from Fedora which changes to same call in a slightly
different way.

0.02-3 uploaded with the patch from RT.
 
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#1022218: xserver-xorg-core: X server seg fault when resuming

[Bernhard Übelacker]

Dear Maintainer, hello Kenneth,
Kenneth, if you still experience this issue, please check if
dmesg contains messages about missing firmwares.
E.g. by this command: dmesg | grep -i firmware

At least in this bug a similar backtrace was shown and
the user reported it got solved by
installing "firmware-amd-graphics and  amd64-microcode":

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


Otherwise below is a reconstructed backtrace containing the line numbers.
It might still be good to report this issue to upstream vesa driver?
  https://gitlab.freedesktop.org/xorg/driver/xf86-video-vesa/-/issues


Kind regard,
Bernhard


 #2 ...0e5 in inl at /usr/include/x86_64-linux-gnu/sys/io.h:83
 #3 ...f1a in x86emuOp_in_word_AX_DX at 
../../../../../../hw/xfree86/int10/../x86emu/ops.c:10364
 #4 ...024 in X86EMU_exec at 
../../../../../../hw/xfree86/int10/../x86emu/decode.c:135
 #5 ...995 in xf86ExecX86int10 at 
../../../../../../hw/xfree86/int10/xf86x86emu.c:39
 #6 ...486 in VBESetVBEMode at ../../../../../../hw/xfree86/int10/vbe.c:473
 #7 ...200 in VESASetMode at ../../src/vesa.c:1247
 #8 ...405 in VESAEnterVT at ../../src/vesa.c:1166
 #9 ...0f7 in CMapEnterVT at ../../../../../../hw/xfree86/common/xf86cmap.c:475
#10 ...e01 in xf86VTEnter at 
../../../../../../hw/xfree86/common/xf86Events.c:456
#11 ...233 in WakeupHandler at ../../../../dix/dixutils.c:427
#12 ...578 in WaitForSomething at ../../../../os/WaitFor.c:210
#13 ...463 in Dispatch at ../../../../dix/dispatch.c:492
#14 ...6bc in dix_main at ../../../../dix/main.c:272


(gdb) list /usr/include/x86_64-linux-gnu/sys/io.h:83
78  static __inline unsigned int
79  inl (unsigned short int __port)
80  {
81unsigned int _v;
82
83__asm__ __volatile__ ("inl %w1,%0":"=a" (_v):"Nd" (__port));
84return _v;
85  }
86
87  static __inline unsigned int

Bug#1025435: [PATCH] u-boot-update: use U_BOOT_FDT as absolute path if it is one

[Nicolas Frattaroli]

u-boot-update would try to load U_BOOT_FDT from U_BOOT_FTD_DIR
in all cases, which is a hindrance to specifying an absolute
unversioned path for a device tree file to be loaded from.

Change this so that the first thing the script tries with regards
to generating the FDT line is to check whether U_BOOT_FDT begins
with a slash. If it does, and the file exists as an absolute path,
use it as the fdt file.
---
 u-boot-update | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/u-boot-update b/u-boot-update
index 69da211..0c18358 100755
--- a/u-boot-update
+++ b/u-boot-update
@@ -182,7 +182,10 @@ do
else
_INITRD=""
fi
-   if [ -e "${_BOOT_PATH}${U_BOOT_FDT_DIR}${_VERSION}/${U_BOOT_FDT}" ] && 
[ -n "${U_BOOT_FDT}" ]
+   if [ -e "${U_BOOT_FDT}" ] && [ -n "${U_BOOT_FDT}" ] && [ "/" = $(echo 
"${U_BOOT_FDT}" | head -c1) ]
+   then
+   _FDT="fdt ${U_BOOT_FDT}"
+   elif [ -e "${_BOOT_PATH}${U_BOOT_FDT_DIR}${_VERSION}/${U_BOOT_FDT}" ] 
&& [ -n "${U_BOOT_FDT}" ]
then
_FDT="fdt ${U_BOOT_FDT_DIR}${_VERSION}/${U_BOOT_FDT}"
elif [ -d "${_BOOT_PATH}${U_BOOT_FDT_DIR}${_VERSION}/" ]
-- 
2.38.1

Bug#1025824: libmojo-ioloop-readwriteprocess-perl: wrong syscall use on armhf

[gregor herrmann]

On Fri, 09 Dec 2022 17:43:38 -0800, Steve Langasek wrote:

> The libmojo-ioloop-readwriteprocess-perl package is failing its autopkgtests
> on armhf in Ubuntu with a SIGILL, blocking the perl 5.36 transition, because
> upstream has added 'armv7l' to the list of uname() values for which it
> "knows" the correct syscall to use for prctl.
[…]
> The attached patch is sufficient to fix this module on armhf and make it
> pass in Ubuntu.  It also makes it correct for Debian, where armhf kernels
> are also not guaranteed to expose syscalls for an ABI that we don't use at
> all in the distro.

Thanks for the bug report and the patch.

Patch applied and forwarded upstream, package uploaded.

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#1025902: tlp: Battery charge thresholds are ignored

[Benedikt Ahrens]

Package: tlp
Version: 1.5.0-1
Severity: normal
X-Debbugs-Cc: benedikt.ahr...@gmx.net

Dear Maintainer,

TLP does not set the battery charge threshold configured in the TLP
configuration file.

Specifically, the configuration file (attached) aims to set the battery charge
thresholds to something like 75%. However, the battery is charged to 100%. The
output of `tlp-stat -b` is

```
# tlp-stat -b
--- TLP 1.5.0 

+++ Battery Care
Plugin: thinkpad
Supported features: charge thresholds, recalibration
Driver usage:
* natacpi (thinkpad_acpi) = active (charge thresholds, recalibration)
Parameter value ranges:
* START_CHARGE_THRESH_BAT0/1:  0(off)..96(default)..99
* STOP_CHARGE_THRESH_BAT0/1:   1..100(default)

+++ ThinkPad Battery Status: BAT0 (Main / Internal)
/sys/class/power_supply/BAT0/manufacturer   = SMP
/sys/class/power_supply/BAT0/model_name = 5B10W51864
/sys/class/power_supply/BAT0/cycle_count=  7
/sys/class/power_supply/BAT0/energy_full_design =  52500 [mWh]
/sys/class/power_supply/BAT0/energy_full=  52500 [mWh]
/sys/class/power_supply/BAT0/energy_now =  37640 [mWh]
/sys/class/power_supply/BAT0/power_now  =   4902 [mW]
/sys/class/power_supply/BAT0/status = Discharging

/sys/class/power_supply/BAT0/charge_control_start_threshold =  0 [%]
/sys/class/power_supply/BAT0/charge_control_end_threshold   =100 [%]
/sys/class/power_supply/BAT0/charge_behaviour   = [auto] inhibit-
charge force-discharge

Charge  =   71.7 [%]
Capacity=  100.0 [%]

```

Rebooting does not change the output, or the charging behaviour.


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

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

Versions of packages tlp depends on:
ii  hdparm9.65+ds-1
ii  iw5.19-1
ii  pciutils  1:3.9.0-2
ii  rfkill2.38.1-4
ii  usbutils  1:014-1

Versions of packages tlp recommends:
ii  ethtool  1:6.0-1
ii  tlp-rdw  1.5.0-1

Versions of packages tlp suggests:
pn  acpi-call-dkms  
pn  linux-cpupower  
pn  smartmontools   
ii  tp-smapi-dkms   0.43-1

-- Configuration Files:
/etc/tlp.conf changed:


-- no debconf information

Bug#967798: vmg: depends on deprecated GTK 2

[Santiago Vila]

Hi.

This package now FTBFS in bookworm:

Compiling resource ./magnifier.or
Linking ./vmg
/usr/bin/ld.bfd: cannot find -lgdk-x11-2.0: No such file or directory
/usr/bin/ld.bfd: cannot find -lgtk-x11-2.0: No such file or directory
/usr/bin/ld.bfd: cannot find -lX11: No such file or directory
/usr/bin/ld.bfd: cannot find -lgdk_pixbuf-2.0: No such file or directory
/usr/bin/ld.bfd: cannot find -lgobject-2.0: No such file or directory
/usr/bin/ld.bfd: cannot find -lglib-2.0: No such file or directory
/usr/bin/ld.bfd: cannot find -lgthread-2.0: No such file or directory
/usr/bin/ld.bfd: cannot find -lgmodule-2.0: No such file or directory
/usr/bin/ld.bfd: cannot find -lpango-1.0: No such file or directory
/usr/bin/ld.bfd: cannot find -lcairo: No such file or directory
/usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
magnifier.dpr(144,1) Error: Error while linking
magnifier.dpr(144,1) Fatal: There were 1 errors compiling module, stopping

Do we need a different bug for the FTBFS problem, or maybe raising this 
bug to serious would be enough?


Thanks.

Bug#916998: Mostly fixed upstream

[Jeremy Sowden]

The new 2.0.8 release includes an overhaul of the build-system which
introduces pkg-config support for libpq and libmysqlclient, and replaces
the previous fall-back code where pkg-config is not available.  It
should fix the cross-build problems, although I have just spotted a bug
in the libpq implementation (thanks to this report) for which I have
sent a patch (attached) upstream.

J.
From 981988f08864ae26b2e8c3993172ce68be2b84eb Mon Sep 17 00:00:00 2001
From: Jeremy Sowden 
Date: Sun, 11 Dec 2022 16:37:49 +
Subject: [PATCH ulogd2] build: fix pgsql fall-back configuration of CFLAGS

When using mysql_config and pcap_config to configure `CFLAGS`, one
requests the actual flags:

  $mysql_config --cflags
  $pcap_config --cflags

By constrast, when using pg_config, one requests the include-directory:

  $pg_config --includedir

Therefore, the `-I` option has to be explicitly added.

Signed-off-by: Jeremy Sowden 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 6ee29ce321d0..70eed9dc1745 100644
--- a/configure.ac
+++ b/configure.ac
@@ -92,7 +92,7 @@ AS_IF([test "x$enable_pgsql" != "xno"], [
 
 AS_IF([command -v "$pg_config" >/dev/null], [
 
-  libpq_CFLAGS="`$pg_config --includedir`"
+  libpq_CFLAGS="-I`$pg_config --includedir`"
   libpq_LIBS="`$pg_config --libdir` -lpq"
 
   AC_SUBST([libpq_CFLAGS])
-- 
2.35.1



signature.asc
Description: PGP signature

Bug#1025903: Please update to upstream release >= 1.8.0

[Ryan Kavanagh]

Source: golang-go.uber-multierr
Severity: wishlist
Control: block 1012721 by -1

The chezmoi package requires golang-go.uber-multierr-dev >= 1.8.0.
Please consider updating this package to its latest upstream release.

[ This bug filed to help track what remains to be done to close
#1012721. ]

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

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

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#1024805: libvirt 7.0.0-3+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1024805 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: libvirt
Version: 7.0.0-3+deb11u1

Explanation: fix container reboot-related issues

Bug#1007426: chroma: please consider upgrading to 3.0 source format

[Ian Jackson]

Control: tags -1 wontfix

Hi, Bastian.  Thanks for working to improve Debian.

I'm the usual sponsor for this package.  I've consulted Simon Tathan,
the maintainer, and, I'm afraid that we will be cancelling this NMU
(by making a no-change upload with a higher version number).

Our reasons are:

 * The NMU involves changing to source format "3.0 (quilt)".
   "3.0 (quilt)" is a troublesome format with unfortunate properties
   that complicate source code management.  For example, we don't want
   an in-tree debian/patches/.

 * Indeed, I don't agree with the the original decision to make
   a mass bug filing.  There was a debate before the Technical
   Committee:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007717
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007717#384
   Were you aware of this when you did your NMU ?  I think it would
   have been on debian-devel-announce.

We (Simon and I) would like to switch to `3.0 (native)`. But,
unfortunately, that isn't supportable with a non-native version
because dpkg-source currently rejects it (or at least, did so until
recently).  So for now we will be keeping 1.0.

I'm sorry that we (Simon and I) didn't update this bug to reflect our
decision not to switch the source format.  This has meant you've done
some wasted work.

Sorry about that.  For the avoidance of doubt, we don't bear you any
ill will over this.

Best wishes,
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#1025685: [Pkg-rust-maintainers] Bug#1025685: rust-pyo3: please upgrade to v0.17

[Jelmer Vernooij]

On Sun, Dec 11, 2022 at 03:40:59AM +, Peter Michael Green wrote:
> I've prepared an upload of verion 0.17 of pyo3 and built/tested breezy with
> it. It built successfully the autopkgtest passed. Any objections if I go
> ahead and update to this version?

No objections. Thanks!

Jelmer

Bug#1007426: chroma: please consider upgrading to 3.0 source format

[Bastian Germann]

Am 11.12.22 um 18:52 schrieb Ian Jackson:

I'm the usual sponsor for this package.  I've consulted Simon Tathan,
the maintainer, and, I'm afraid that we will be cancelling this NMU
(by making a no-change upload with a higher version number).


That is fine. Please make sure not to have a ubuntu suffix with your new 
version number.

Bug#893083: more as just VCS fields

[Geert Stappers]

On Sun, Dec 11, 2022 at 05:41:21PM +0100, Santiago Vila wrote:
> El 11/12/22 a las 16:25, Geert Stappers escribió:
> > I'm fine with deleting the current repo at Salsa
> > to make room for a repository that has more history.
> 
> Please do so.

https://salsa.debian.org/debian/hello/edit has no "Delete project"
button for me.  (privileges issue)

https://salsa.debian.org/stappers/hello/edit does have that button
(for reference purposes)

> It's not only about the history but about the conventions,
> there is a DEP document which recommends a layout for branches and so on,
> and the repo you created (I'm afraid) does not follow it at all.
> 
> This is really not a matter of adding fields to a control file, if that was
> all, it would be already done. This really involves a change in the way I'm
> maintaining the package, which at this point I'm still not comfortable.
> 
> My plan for this would be to create it under my "sanvila" namespace.
> But there are a lot of other work to do which is more important than this.
> This is still wishlist.

The wish is:  Make `debcheckout hello` possible.

Thanks for expressing "to create it in sanvila namespace".

I confirm that https://salsa.debian.org/debian/hello has only 1 branch.
And that one branch makes it possible what this bugreport is about.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#967798: vmg: depends on deprecated GTK 2

[Samuel Thibault]

Hello,

Santiago Vila, le dim. 11 déc. 2022 18:51:52 +0100, a ecrit:
> This package now FTBFS in bookworm:
> 
> Compiling resource ./magnifier.or
> Linking ./vmg
> /usr/bin/ld.bfd: cannot find -lgdk-x11-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lgtk-x11-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lX11: No such file or directory
> /usr/bin/ld.bfd: cannot find -lgdk_pixbuf-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lgobject-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lglib-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lgthread-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lgmodule-2.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lpango-1.0: No such file or directory
> /usr/bin/ld.bfd: cannot find -lcairo: No such file or directory
> /usr/bin/ld.bfd: cannot find -latk-1.0: No such file or directory
> magnifier.dpr(144,1) Error: Error while linking
> magnifier.dpr(144,1) Fatal: There were 1 errors compiling module, stopping
> 
> Do we need a different bug for the FTBFS problem, or maybe raising this bug
> to serious would be enough?

This particular issue rather seems to belong to fp-units-gtk2-3.2.2:
fp-units-gtk2-3.2.0 used to have the libgtk2.0-dev dependency, but
fp-units-gtk2-3.2.2 doesn't any more, but it should, it shouldn't be up
to users of the gtk2 unit to know which C dependency it should take.

Samuel

Bug#1025788: transition: numpy

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2022-12-08 22:36:41 -0500, Sandro Tosi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: nu...@packages.debian.org, mo...@debian.org
> Control: affects -1 + src:numpy
> 
> Hello,
> i would like to request a transition slot for numpy.
> 
> numpy/1.23.5 is in experimental, the autopkgtest for it are:
> 
>   https://qa.debian.org/excuses.php?experimental=1&package=numpy
> 
> I gave a look at the failures and several of them are due to other reasons
> (uninstallable packages and the like), others may be attributed to python3.11
> being added to unstable; issues related to the newer numpy are of the type
> 
>   AttributeError: module 'numpy' has no attribute 'asscalar'
> 
> which has been removed after being deprecated for 7 releases:
> 
>   https://numpy.org/doc/1.22/reference/generated/numpy.asscalar.html
> 
> 
> Please let me know when i can upload numpy/1.23.5 to unstable.

Which packages would be needed to be rebuilt for this transition?

Cheers
-- 
Sebastian Ramacher

Bug#965523: flobopuyo: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Ying-Chun Liu (PaulLiu)]

Hi all,

I think flobopuyo is still a very good game and deserved to keep in 
bookworm. So I made a patch to fix this RC bug and plan to NMU.


Please see the attachment for the debdiff.

I'll upload it to delay/10 queue after 10 days if no one complains.

The changes are:
  * Non-maintainer upload.
  * Change source format to 3.0 (qulit)
- Use quilt instead of simple-patchsys from cdbs.
  * Bump debhelper version to 9. (Closes: #965523)

Yours,
Paul

diff -Nru flobopuyo-0.20/debian/changelog flobopuyo-0.20/debian/changelog
--- flobopuyo-0.20/debian/changelog 2022-12-12 02:25:33.0 +0800
+++ flobopuyo-0.20/debian/changelog 2022-12-12 01:59:50.0 +0800
@@ -1,3 +1,12 @@
+flobopuyo (0.20-5.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Change source format to 3.0 (qulit)
+- Use quilt instead of simple-patchsys from cdbs.
+  * Bump debhelper version to 9. (Closes: #965523)
+
+ -- Ying-Chun Liu (PaulLiu)   Mon, 12 Dec 2022 01:59:50 
+0800
+
 flobopuyo (0.20-5) unstable; urgency=low
 
   * Fix "FTBFS with binutils-gold" (Closes: #554359).
diff -Nru flobopuyo-0.20/debian/compat flobopuyo-0.20/debian/compat
--- flobopuyo-0.20/debian/compat2022-12-12 02:25:33.0 +0800
+++ flobopuyo-0.20/debian/compat2022-12-12 01:06:58.0 +0800
@@ -1 +1 @@
-5
+9
diff -Nru flobopuyo-0.20/debian/control flobopuyo-0.20/debian/control
--- flobopuyo-0.20/debian/control   2022-12-12 02:25:33.0 +0800
+++ flobopuyo-0.20/debian/control   2022-12-12 01:07:20.0 +0800
@@ -2,7 +2,7 @@
 Section: games
 Priority: optional
 Maintainer: Uwe Hermann 
-Build-Depends: cdbs, debhelper (>= 5), libsdl-image1.2-dev, 
libsdl-mixer1.2-dev, libsdl1.2-dev, flex, bison, sharutils
+Build-Depends: cdbs, debhelper (>= 9), libsdl-image1.2-dev, 
libsdl-mixer1.2-dev, libsdl1.2-dev, flex, bison, sharutils
 Standards-Version: 3.9.1
 Homepage: http://www.fovea.cc/flobopuyo-en
 
diff -Nru flobopuyo-0.20/debian/patches/20_makefile_prefix.patch 
flobopuyo-0.20/debian/patches/20_makefile_prefix.patch
--- flobopuyo-0.20/debian/patches/20_makefile_prefix.patch  2022-12-12 
02:25:33.0 +0800
+++ flobopuyo-0.20/debian/patches/20_makefile_prefix.patch  2022-12-12 
01:29:35.0 +0800
@@ -1,6 +1,8 @@
 Makefile.orig  2008-04-15 13:54:47.0 +0200
-+++ Makefile   2008-04-15 13:58:35.0 +0200
-@@ -12,7 +12,7 @@
+Index: flobopuyo-0.20/Makefile
+===
+--- flobopuyo-0.20.orig/Makefile
 flobopuyo-0.20/Makefile
+@@ -12,7 +12,7 @@ ENABLE_DGA=false
  DEBUG_MODE=false
  
  # Unix/Linux settings
diff -Nru flobopuyo-0.20/debian/patches/30_datadir.patch 
flobopuyo-0.20/debian/patches/30_datadir.patch
--- flobopuyo-0.20/debian/patches/30_datadir.patch  2022-12-12 
02:25:33.0 +0800
+++ flobopuyo-0.20/debian/patches/30_datadir.patch  2022-12-12 
01:30:27.0 +0800
@@ -1,5 +1,7 @@
 main.cpp.orig  2006-04-21 23:09:02.0 +0200
-+++ main.cpp   2006-04-21 23:09:20.0 +0200
+Index: flobopuyo-0.20/main.cpp
+===
+--- flobopuyo-0.20.orig/main.cpp
 flobopuyo-0.20/main.cpp
 @@ -7,7 +7,7 @@
  #include "PuyoCommander.h"
  
diff -Nru flobopuyo-0.20/debian/patches/50_handle_nostrip.patch 
flobopuyo-0.20/debian/patches/50_handle_nostrip.patch
--- flobopuyo-0.20/debian/patches/50_handle_nostrip.patch   2022-12-12 
02:25:33.0 +0800
+++ flobopuyo-0.20/debian/patches/50_handle_nostrip.patch   2022-12-12 
01:31:14.0 +0800
@@ -1,6 +1,8 @@
 Makefile.orig  2008-04-15 16:43:36.0 +0200
-+++ Makefile   2008-04-15 16:43:42.0 +0200
-@@ -178,7 +178,6 @@
+Index: flobopuyo-0.20/Makefile
+===
+--- flobopuyo-0.20.orig/Makefile
 flobopuyo-0.20/Makefile
+@@ -178,7 +178,6 @@ clean:
rm -f  .DS_Store */.DS_Store */*/.DS_Store .gdb_history
  
  install: flobopuyo
diff -Nru flobopuyo-0.20/debian/patches/80_fix_typo.patch 
flobopuyo-0.20/debian/patches/80_fix_typo.patch
--- flobopuyo-0.20/debian/patches/80_fix_typo.patch 2022-12-12 
02:25:33.0 +0800
+++ flobopuyo-0.20/debian/patches/80_fix_typo.patch 2022-12-12 
01:32:03.0 +0800
@@ -1,8 +1,10 @@
 Fix a typo to silence lintian.
 
 sofont.c.orig  2011-03-13 22:55:42.0 +0100
-+++ sofont.c   2011-03-13 22:55:50.0 +0100
-@@ -291,7 +291,7 @@
+Index: flobopuyo-0.20/sofont.c
+===
+--- flobopuyo-0.20.orig/sofont.c
 flobopuyo-0.20/sofont.c
+@@ -291,7 +291,7 @@ SoFont_load (SoFont * font, IIM_Surface
int _Spacing[256];
  
if (!FontSurface) {
diff -Nru flobopuyo-0.20/debian/patches/series 
flobopuyo-0.20/debian/patches/series
--- flobopuyo-0.20/debian/patches/series1970-01-01 08:00:00.0 
+0800
+++ flobopuyo-0.20/deb

Bug#1025010: bullseye-pu: package jtreg6/6.1+2-1~deb11u1

[Moritz Mühlenhoff]

Am Wed, Dec 07, 2022 at 08:27:05PM + schrieb Adam D. Barratt:
> Control: tags -1 + confirmed
> 
> On Mon, 2022-11-28 at 20:35 +0100, Moritz Muehlenhoff wrote:
> > openjdk bumped the requirements for the test suite within
> > their 11.x branch (which is what we ship in Bullseye), it
> > now needs jtreg6.
> > 
> 
> "Yay". Please go ahead.

Uploaded (and hit NEW)

Cheers,
 Moritz

Bug#1024889: ntcard: ftbfs with nthash 2.3.0

[Andreas Tille]

Dear Nilesh,

Am Fri, Dec 09, 2022 at 03:12:35PM +0530 schrieb Nilesh Patra:
> > I'm considering reverting the version bump (shame on me I did not tested
> > ntcard before uploading).
> 
> I'm personally quite annoyed with this, I suppose your uploads, or rather
> team uploads have broken quite a few packages in the past days. It was
> first t-coffee update that broke biopython, and then mcl which broke pplacer
> and now this.

I think this "common feature to break something" is quite different in
the single cases.  It was pretty hard to estimate the effect of the
t-coffee case.  A lot of effort was done to fix its autopkgtest in
advance.  I simply assumed that passing its test is sufficient for an
upload.

While the breaking upload of MCL was not intended I would even insist
that there is a point in the breaking upload.  MCL is a popular program
which we should deliver in its recent version.  The support and
cooperation by upstream rectified this.  The fact that some packages
like pplacer depend from a patch by third party which is not maintained
by its author since 10 years might mean that we will possibly loose
these packages which is a shame but may be the fate of those packages.
However, there is some hope that MCL upstream might find a solution.
 
> The mcl update also most likely needs to be rolled back. The ocaml changes are
> not compatible with the new version of mcl, and someone needs to update 
> pplacer
> too to make sure that it is compatible with newer mcl.

There is some hope for an updated OCaml patch[1], thought.  If the OCaml
patch can be updated that would be great.  If not I see no chance to
keep pplacer in the long term.
 
> I want to make it a mandatory policy: do NOT upload packages randomly. Run 
> ratt
> or run https://salsa.debian.org/ruby-team/meta atleast given that we are 
> close to
> release, random updates of not so important packages is un-necessarily 
> breaking a
> lot of things.

I confirm that running ratt or meta of Ruby team would be a good idea in
some cases.  However, I disagree to make it mandatory in policy.
Picking three cases of uploads from the number of all uploads is not a
very strong argument.  We have *lots* of uploads pending for the next
couple of weeks to meet the freeze.  Delaying these just because three
broken uploads (one is fixed meanwhile and there is a clear way to fiy
the second for ntcard by reverting the vesion bump of nthash if upstream
does not respond timely) is not a good strategy in my eyes.  I perfectly
agree that running autopkgtest could be made mandatory in policy,
thought.

Kind regards
   Andreas.

[1] 
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2022-December/105589.html

-- 
http://fam-tille.de

Bug#1025904: flightgear: FTBFS on riscv64 [PATCH]

[Gianfranco Costamagna]

Source: flightgear
Version: 1:2020.3.16+dfsg-1
tags: patch
forwarded: https://sourceforge.net/p/flightgear/flightgear/merge-requests/306/

Hello, changing the atomic int to atomic bool makes the build succeed without 
need of any additional latomic slow linking
in riscv64, resulting in faster runtime code.
I already fowarded upstream.

thanks

G.

diff -Nru flightgear-2020.3.16+dfsg/debian/changelog 
flightgear-2020.3.16+dfsg/debian/changelog
--- flightgear-2020.3.16+dfsg/debian/changelog  2022-10-26 17:51:29.0 
+
+++ flightgear-2020.3.16+dfsg/debian/changelog  2022-12-10 22:18:14.0 
+
@@ -1,3 +1,9 @@
+flightgear (1:2020.3.16+dfsg-1.1) unstable; urgency=medium
+
+  * Fix build on riscv64 (Closes: #-1).
+
+ -- Gianfranco Costamagna   Sat, 10 Dec 2022 
23:18:14 +0100
+
 flightgear (1:2020.3.16+dfsg-1) unstable; urgency=medium
 
   * New upstream version 2020.3.16+dfsg

diff -Nru 
flightgear-2020.3.16+dfsg/debian/patches/fix-atomic-build-riscv64.patch 
flightgear-2020.3.16+dfsg/debian/patches/fix-atomic-build-riscv64.patch
--- flightgear-2020.3.16+dfsg/debian/patches/fix-atomic-build-riscv64.patch 
1970-01-01 00:00:00.0 +
+++ flightgear-2020.3.16+dfsg/debian/patches/fix-atomic-build-riscv64.patch 
2022-12-10 22:18:12.0 +
@@ -0,0 +1,19 @@
+Description: Don't use atomic_bool, but atomic_int, the latter doesn't need 
external latomic linking
+on riscv64
+Author: Gianfranco Costamagna 
+Origin: https://sourceforge.net/p/flightgear/flightgear/merge-requests/306/
+Last-Update: 2022-12-10
+
+--- flightgear-2020.3.16+dfsg.orig/src/GUI/QQuickDrawable.cxx
 flightgear-2020.3.16+dfsg/src/GUI/QQuickDrawable.cxx
+@@ -172,8 +172,8 @@ public:
+ QOpenGLContext* qtContext = nullptr;
+ osg::GraphicsContext* osgContext = nullptr;
+
+-std::atomic_bool renderControlInited;
+-std::atomic_bool syncPending;
++std::atomic_int renderControlInited;
++std::atomic_int syncPending;
+
+ void frameEvent()
+ {
diff -Nru flightgear-2020.3.16+dfsg/debian/patches/series 
flightgear-2020.3.16+dfsg/debian/patches/series
--- flightgear-2020.3.16+dfsg/debian/patches/series 2022-10-26 
17:50:15.0 +
+++ flightgear-2020.3.16+dfsg/debian/patches/series 2022-12-10 
22:17:15.0 +
@@ -9,3 +9,4 @@
 0009-Disable-some-newly-failing-tests.patch
 0010-Ignore-some-more-tests.patch
 0011-test-compilation-fix.patch
+fix-atomic-build-riscv64.patch



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025905: simgear: FTBFS on riscv64 [PATCH]

[Gianfranco Costamagna]

Source: simgear
Version: 1:2020.3.16+dfsg-1
tags: patch
forwarded: https://sourceforge.net/p/flightgear/simgear/merge-requests/119/

Hello, changing the atomic int to atomic bool makes the build succeed without 
need of any additional latomic slow linking
in riscv64, resulting in faster runtime code.
I already fowarded upstream.

thanks

G.

diff -Nru simgear-2020.3.16+dfsg/debian/changelog 
simgear-2020.3.16+dfsg/debian/changelog
--- simgear-2020.3.16+dfsg/debian/changelog 2022-10-26 08:53:00.0 
+
+++ simgear-2020.3.16+dfsg/debian/changelog 2022-12-10 22:27:56.0 
+
@@ -1,3 +1,9 @@
+simgear (1:2020.3.16+dfsg-1.1) unstable; urgency=medium
+
+  * Fix build on riscv64 (Closes: #-1).
+
+ -- Gianfranco Costamagna   Sat, 10 Dec 2022 
23:27:56 +0100
+
 simgear (1:2020.3.16+dfsg-1) unstable; urgency=medium
 
   * New upstream version 2020.3.16+dfsg

diff -Nru simgear-2020.3.16+dfsg/debian/patches/fix-atomic-build-riscv64.patch 
simgear-2020.3.16+dfsg/debian/patches/fix-atomic-build-riscv64.patch
--- simgear-2020.3.16+dfsg/debian/patches/fix-atomic-build-riscv64.patch
1970-01-01 00:00:00.0 +
+++ simgear-2020.3.16+dfsg/debian/patches/fix-atomic-build-riscv64.patch
2022-12-10 22:27:54.0 +
@@ -0,0 +1,23 @@
+Description: Don't use atomic_bool, but atomic_int, the latter doesn't need 
external latomic linking
+on riscv64
+Author: Gianfranco Costamagna 
+Origin: https://sourceforge.net/p/flightgear/simgear/merge-requests/119/
+Last-Update: 2022-12-10
+
+--- simgear-2020.3.16+dfsg.orig/simgear/threads/SGThread.hxx
 simgear-2020.3.16+dfsg/simgear/threads/SGThread.hxx
+@@ -171,10 +171,10 @@ private:
+ bool _terminated;
+ int last_await_time;
+
+-std::atomic dataReady;
+-std::atomic complete;
+-std::atomic process_ran;
+-std::atomic process_running;
++std::atomic dataReady;
++std::atomic complete;
++std::atomic process_ran;
++std::atomic process_running;
+
+ public:
+ SGExclusiveThread();
diff -Nru simgear-2020.3.16+dfsg/debian/patches/series 
simgear-2020.3.16+dfsg/debian/patches/series
--- simgear-2020.3.16+dfsg/debian/patches/series2022-10-24 
11:25:38.0 +
+++ simgear-2020.3.16+dfsg/debian/patches/series2022-12-10 
22:27:44.0 +
@@ -5,3 +5,4 @@
 disable_network_tests.patch
 spelling_fixes.patch
 fix-ftbfs-on-armel-armhf.patch
+fix-atomic-build-riscv64.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020560: diffutils: Missing LGPL-2.1+, GPL-2+ in d/copyright

[Santiago Vila]

Hi.

I'm looking at the proposed copyright file and found this:

   gnulib-tests/h*
   gnulib-tests/ioctl.c

What rule is being followed to use wildcards sometimes and sometimes 
not? This is a little bit crazy. How did you generate the file?


And more important, because without this I can't take the file "as is": 
How am I supposed to update the file when authors release a new version?


Thanks.

Bug#967798: vmg: depends on deprecated GTK 2

[Simon McVittie]

On Sun, 11 Dec 2022 at 19:23:07 +0100, Samuel Thibault wrote:
> Santiago Vila, le dim. 11 déc. 2022 18:51:52 +0100, a ecrit:
> > This package now FTBFS in bookworm:
> > 
> > Compiling resource ./magnifier.or
> > Linking ./vmg
> > /usr/bin/ld.bfd: cannot find -lgdk-x11-2.0: No such file or directory
> > 
> > Do we need a different bug for the FTBFS problem, or maybe raising this bug
> > to serious would be enough?
> 
> This particular issue rather seems to belong to fp-units-gtk2-3.2.2:
> fp-units-gtk2-3.2.0 used to have the libgtk2.0-dev dependency, but
> fp-units-gtk2-3.2.2 doesn't any more, but it should, it shouldn't be up
> to users of the gtk2 unit to know which C dependency it should take.

What Samuel says sounds right to me. GTK 2 being deprecated doesn't
directly affect other packages that still depend on it: the packages
and compiler/linker invocations involved remain the same. The effect of
deprecation is indirect: it won't get new features or non-critical bug
fixes, and might get removed (particularly if a critical bug is found
and can't easily be fixed).

smcv

Bug#965578: hasciicam: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Ying-Chun Liu (PaulLiu)]

Hi all,

low-bandwidth streaming could be a really useful stuff.
I'll fix the RC bugs and do NMU.

This is a simple one, bump debhelper version just fixes the problem.
Please see the debdiff attachment.

I'll wait for 10 days and upload to delay/10 queue.

Yours,
Paul
diff -Nru hasciicam-1.1.2/debian/changelog hasciicam-1.1.2/debian/changelog
--- hasciicam-1.1.2/debian/changelog2011-04-27 03:31:53.0 +0800
+++ hasciicam-1.1.2/debian/changelog2022-12-12 02:40:02.0 +0800
@@ -1,3 +1,10 @@
+hasciicam (1.1.2-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Bump debhelper compat to 9. (Closes: #965578)
+
+ -- Ying-Chun Liu (PaulLiu)   Mon, 12 Dec 2022 02:40:02 
+0800
+
 hasciicam (1.1.2-1) unstable; urgency=low
 
   * New upstream release
diff -Nru hasciicam-1.1.2/debian/compat hasciicam-1.1.2/debian/compat
--- hasciicam-1.1.2/debian/compat   2011-04-26 21:08:13.0 +0800
+++ hasciicam-1.1.2/debian/compat   2022-12-12 02:38:57.0 +0800
@@ -1 +1 @@
-5
+9
diff -Nru hasciicam-1.1.2/debian/control hasciicam-1.1.2/debian/control
--- hasciicam-1.1.2/debian/control  2011-04-26 21:27:52.0 +0800
+++ hasciicam-1.1.2/debian/control  2022-12-12 02:39:06.0 +0800
@@ -7,7 +7,7 @@
 Vcs-Git: git://code.dyne.org/hasciicam.git
 Vcs-Browser: http://code.dyne.org/?r=hasciicam
 Homepage: http://ascii.dyne.org/
-Build-Depends: cdbs, debhelper (>> 5.0.0), libaa1-dev, ftplib-dev
+Build-Depends: cdbs, debhelper (>= 9), libaa1-dev, ftplib-dev
 Standards-Version: 3.9.1
 
 Package: hasciicam


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023000: Processed: reopen 1023000: flaky test in dpdk

[Paul Gevers]

Control: close -1 22.11~rc2-1

Grmbll...

On 11-12-2022 20:09, Debian Bug Tracking System wrote:

# forgot "Control: " in the bug message
reopen 1023000

Bug #1023000 {Done: Luca Boccassi } [src:dpdk] dpdk: flaky 
autopkgtest on amd64 and ppc64el: pdump_autotest time out
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions dpdk/22.11~rc2-1.

found 1023000 21.11-5

Bug #1023000 [src:dpdk] dpdk: flaky autopkgtest on amd64 and ppc64el: 
pdump_autotest time out
Marked as found in versions dpdk/21.11-5.


And only upon receiving this reply from the bts I notice my mistake. 
Sorry for the noise, the bug was (only) fixed in experimental (that's 
why I am still seeing it).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025906: udisks2: multiple assertion failures in journal

[Lorenzo Iannuzzi]

Package: udisks2
Version: 2.9.2-2+deb11u1
Severity: minor

In journal I receive assertion failures messages from udisksd just after boot.
Those are the lines that seems to repeat some times:

udisksd[546]: g_variant_new_bytestring: assertion 'string != NULL' failed
udisksd[546]: g_variant_new_variant: assertion 'value != NULL' failed
udisksd[546]: g_variant_get_type: assertion 'value != NULL' failed
udisksd[546]: g_variant_type_is_subtype_of: assertion 'g_variant_type_check
(type)' failed
udisksd[546]: g_variant_builder_add_value: assertion
'!GVSB(builder)->expected_type || g_variant_is_of_type (value,
GVSB(builder)->expected_type)' failed
udisksd[546]: g_variant_builder_end: assertion 'GVSB(builder)->offset >=
GVSB(builder)->min_items' failed

Anyway system seems not affected at all.


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

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

Versions of packages udisks2 depends on:
ii  dbus   1.12.24-0+deb11u1
ii  libacl12.2.53-10
ii  libatasmart4   0.19-5
ii  libblockdev-fs22.25-2
ii  libblockdev-loop2  2.25-2
ii  libblockdev-part2  2.25-2
ii  libblockdev-swap2  2.25-2
ii  libblockdev-utils2 2.25-2
ii  libblockdev2   2.25-2
ii  libc6  2.34-7
ii  libglib2.0-0   2.73.3-3
ii  libgudev-1.0-0 234-1
ii  libmount1  2.36.1-8+deb11u1
ii  libpolkit-agent-1-00.105-31+deb11u1
ii  libpolkit-gobject-1-0  0.105-31+deb11u1
ii  libsystemd0247.3-7+deb11u1
ii  libudisks2-0   2.9.2-2+deb11u1
ii  libuuid1   2.36.1-8+deb11u1
ii  parted 3.4-1
ii  udev   247.3-7+deb11u1

Versions of packages udisks2 recommends:
ii  dosfstools   4.2-1
ii  e2fsprogs1.46.2-2
ii  eject2.36.1-8+deb11u1
ii  exfat-utils  1.3.0-2
ii  libblockdev-crypto2  2.25-2
ii  libpam-systemd   247.3-7+deb11u1
ii  ntfs-3g  1:2017.3.23AR.3-4+deb11u3
ii  policykit-1  0.105-31+deb11u1

Versions of packages udisks2 suggests:
pn  btrfs-progs  
pn  f2fs-tools   
pn  libblockdev-mdraid2  
pn  mdadm
pn  nilfs-tools  
pn  reiserfsprogs
pn  udftools 
pn  udisks2-bcache   
pn  udisks2-btrfs
pn  udisks2-lvm2 
pn  udisks2-zram 
pn  xfsprogs 

Bug#1025907: package-update-indicator no longer alerts user to available updates

[Dan Guild]

Package: package-update-indicator
Version: 8-1
The tray icon no longer changes when updates are available. In addition, 
the "Install Updates" menu selection remains greyed out thus preventing 
the package from initiating updates.

OS: Debian Sid (fully updated)
Kernel: Linux debian-mate-dlg 6.0.0-6-amd64 #1 SMP PREEMPT_DYNAMIC 
Debian 6.0.12-1 (2022-12-09) x86_64 GNU/Linux

Note the failure occurs on my pure Debian sid test system as well.
dpkg --status package-update-indicator output:
Package: package-update-indicator
Status: install ok installed
Priority: optional
Section: gnome
Installed-Size: 178
Maintainer: Matthias Klumpp 
Architecture: amd64
Version: 8-1
Depends: packagekit (>= 1.1.8), dconf-gsettings-backend | 
gsettings-backend, libayatana-appindicator3-1 (>= 0.4.90), libc6 (>= 
2.34), libglib2.0-0 (>= 2.43.2), libgtk-3-0 (>= 3.24), 
libpackagekit-glib2-18 (>= 0.9.4), libpolkit-gobject-1-0 (>= 0.99), 
libupower-glib3 (>= 0.99.0)

Recommends: gnome-packagekit
Conffiles:
 /etc/xdg/autostart/org.guido-berhoerster.code.package-update-indicator.desktop 
54e3fd9ad48b00bd136d1ff893f4ef74
Description: Notify about available software updates
 This small utility which regularly checks for software updates and 
notifies

 the user about available updates using desktop notifications and either
 a status notifier icon or a system tray icon.
 .
 It is primarily intended for desktops which do not already have this
 functionality built-in, such as Xfce.
Homepage: 
https://code.guido-berhoerster.org/projects/package-update-indicator/

Thank you for your assistance.
Dan Guild

Bug#1025788: transition: numpy

[Sandro Tosi]

On Sun, Dec 11, 2022 at 1:26 PM Sebastian Ramacher  wrote:
> Which packages would be needed to be rebuilt for this transition?

I'm not sure how to answer this question.

numpy provides 2 virtual packages, to track the ABI/API version as
advertised by the upstream project. Between unstable and experimental,
we did not bump the ABI package (which stays at `python3-numpy-abi9`)
while we bumped the API package (from `python3-numpy-api14` to
`python3-numpy-api16`).

In the past times we asked for a transition (f.e. #658289 or #616364),
we referred to the -abiXX package, but in this case we cannot rely on
it since it was not bumped.

Was i just too conservative in asking for a transition slow while i
should have uploaded to unstable (as done several other times) and
handle the autopkgtests one by one?

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1025908: systemd: flaky autopkgtest: test_resolved_domain_restricted_dns

[Paul Gevers]

Source: systemd
Version: 251.4-3
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed 
that it regularly fails. It seems that DNS either times out or isn't 
really reliable. I suggest to either increase the timeout (if that's the 
cause, skip the test, or make it retry at least once.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/data/autopkgtest/testing/i386/s/systemd/29214658/log.gz

==
ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
resolved: domain-restricted DNS servers
--
Traceback (most recent call last):
   File 
"/tmp/autopkgtest-lxc.45d4ds2y/downtmp/build.g5f/src/test/networkd-test.py", 
line 686, in test_resolved_domain_restricted_dns
 out = subprocess.check_output(['resolvectl', 'query', 
'search.example.com'])

   File "/usr/lib/python3.10/subprocess.py", line 421, in check_output
 return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
   File "/usr/lib/python3.10/subprocess.py", line 526, in run
 raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['resolvectl', 'query', 
'search.example.com']' returned non-zero exit status 1.


--


https://ci.debian.net/data/autopkgtest/testing/amd64/s/systemd/29160541/log.gz

==
ERROR: test_resolved_domain_restricted_dns (__main__.DnsmasqClientTest)
resolved: domain-restricted DNS servers
--
Traceback (most recent call last):
   File 
"/tmp/autopkgtest-lxc.65kf3irc/downtmp/build.HiP/src/test/networkd-test.py", 
line 686, in test_resolved_domain_restricted_dns
 out = subprocess.check_output(['resolvectl', 'query', 
'search.example.com'])

   File "/usr/lib/python3.10/subprocess.py", line 421, in check_output
 return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
   File "/usr/lib/python3.10/subprocess.py", line 526, in run
 raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['resolvectl', 'query', 
'search.example.com']' returned non-zero exit status 1.






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025909: systemd: "reboot" fails to boot into the grub-menu

[Martin Ziegler]

Package: systemd
Version: 252.3-1
Severity: normal
X-Debbugs-Cc: zieg...@uni-freiburg.de

Dear Maintainer,

"reboot" fails to boot into the grub-menu, as well as the command
"systemctl reboot". The least kernel in the grub menu is booted
instead.

"systemctl reboot --boot-loader-menu=5" gives an error

A reboot 1.12.2022 (with versions 252.1-1) worked as expected, the
next boot 7.12.2022 (still with versions 252.1-1) showed the
incriminated behaviour. With versions 252.2-1 and 252.3-1 still no
boot into the grub menu.

I looks as if another package is responsible for this change.
But I cannot guess which.



-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  libacl12.3.1-2
ii  libaudit1  1:3.0.7-1.1+b2
ii  libblkid1  2.38.1-4
ii  libc6  2.36-6
ii  libcap21:2.44-1
ii  libcryptsetup122:2.6.0-2
ii  libfdisk1  2.38.1-4
ii  libgcrypt201.10.1-3
ii  libkmod2   30+20220905-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.2.9-0.0
ii  libmount1  2.38.1-4
ii  libseccomp22.5.4-1+b2
ii  libselinux13.4-1+b3
ii  libssl33.0.7-1
ii  libsystemd-shared  252.3-1
ii  libsystemd0252.3-1
ii  libzstd1   1.5.2+dfsg-1
ii  mount  2.38.1-4

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.4-1
ii  systemd-timesyncd [time-daemon]  252.3-1

Versions of packages systemd suggests:
ii  libfido2-11.12.0-2
ii  libqrencode4  4.1.1-1
pn  libtss2-esys-3.0.2-0  
pn  libtss2-mu0   
pn  libtss2-rc0   
ii  policykit-1   122-1
ii  polkitd   122-1
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.4-1
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 252.3-1
ii  libpam-systemd 252.3-1
ii  udev   252.2-2

-- Configuration Files:
/etc/systemd/networkd.conf changed:
[Network]
[DHCPv4]
<<< networkd.conf
[DHCPv6]
===
[Login]
>>> logind.conf.dpkg-new


-- no debconf information

Bug#1012428: gnome-shell-common: drmModeAddFB2WithModifiers Failed

[Tim McConnell]

Hi Jeremy, 
I am not, I switched to Mate for a desktop and they have gone away. 
Thanks! 
Tim McConnell

On Sun, 2022-12-11 at 09:40 -0500, Jeremy Bicha wrote:
> Many things have changed in Debian in the past 6 months. Are you
> still
> experiencing this issue?
> 
> Thank you,
> Jeremy Bicha
> 
> On Mon, Jun 6, 2022 at 7:39 PM Tim McConnell
>  wrote:
> > Package: gnome-shell-common
> > Version: 42.1-1
> > Severity: grave
> > Justification: renders package unusable
> > X-Debbugs-Cc: tmcconnell...@gmail.com
> > 
> > Dear Maintainer,
> > 
> > What led up to the situation? Do not know, my logs are getting
> > multiple reports
> > of this error(?)
> > 
> > What exactly did you do (or not do) that was effective (or
> >  ineffective)? Unknown
> > 
> > What was the outcome of this action?
> > 11433 lines of:
> > gnome-shell[4883]: Failed to scan out client buffer:
> > drmModeAddFB2WithModifiers
> > failed: Invalid argument
> > 
> > What outcome did you expect instead?
> > Not getting all of those errors in one hour
> > 
> > 
> > 
> > -- System Information:
> > Debian Release: bookworm/sid
> >   APT prefers testing
> >   APT policy: (500, 'testing')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386

Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel

[Andreas Tille]

Am Sun, Dec 11, 2022 at 08:43:38AM -0500 schrieb Jeffrey Walton:
> > Isn't this just a matter of the autobuilders hardware?
> >
> > If not I do not see any other clue but removing the package for mipsel.
> 
> You might also see how many make jobs the build system is using. If
> it's more than 1, then halve the number of jobs.

I've simply set --no-parallel for mipsel[1] but it fails with the same
problem.

I do not see any better way to fix this issue than excluding mipsel
from the builds.

Kind regards
   Andreas.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=r-cran-glmmtmb&arch=mipsel&ver=1.1.5%2Bdfsg-3&stamp=1670783276&raw=0
 

-- 
http://fam-tille.de

Bug#965600: jack-tools: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Ying-Chun Liu (PaulLiu)]

Hi all,

Since nobody wants to fixes this. I'll do the NMU.

debdiff as attachment.

Will upload this to delay/10 queue after 10 days.

Yours,
Paul
diff -Nru jack-tools-20131226/debian/changelog 
jack-tools-20131226/debian/changelog
--- jack-tools-20131226/debian/changelog2014-10-15 21:54:35.0 
+0800
+++ jack-tools-20131226/debian/changelog2022-12-12 03:22:18.0 
+0800
@@ -1,3 +1,10 @@
+jack-tools (20131226-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Bump debhelper version to 10. (Closes: #965600)
+
+ -- Ying-Chun Liu (PaulLiu)   Mon, 12 Dec 2022 03:22:18 
+0800
+
 jack-tools (20131226-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru jack-tools-20131226/debian/clean jack-tools-20131226/debian/clean
--- jack-tools-20131226/debian/clean1970-01-01 08:00:00.0 +0800
+++ jack-tools-20131226/debian/clean2022-12-12 03:22:18.0 +0800
@@ -0,0 +1,10 @@
+jack-dl
+jack-osc
+jack-play
+jack-plumbing
+jack-record
+jack-scope
+jack-transport
+jack-udp
+c-common/*.o
+c-common/*.a
diff -Nru jack-tools-20131226/debian/compat jack-tools-20131226/debian/compat
--- jack-tools-20131226/debian/compat   2014-10-15 20:58:14.0 +0800
+++ jack-tools-20131226/debian/compat   2022-12-12 03:21:00.0 +0800
@@ -1 +1 @@
-6
+10
diff -Nru jack-tools-20131226/debian/control jack-tools-20131226/debian/control
--- jack-tools-20131226/debian/control  2014-10-15 21:53:24.0 +0800
+++ jack-tools-20131226/debian/control  2022-12-12 03:21:04.0 +0800
@@ -5,7 +5,7 @@
 Uploaders: Arnout Engelen ,
  Jonas Smedegaard 
 Build-Depends: cdbs,
- debhelper (>= 6),
+ debhelper (>= 10),
  bzip2,
  flex,
  freeglut3-dev,


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature