Bug#1025933: virtualbox: Failed to start LSB: VirtualBox Linux kernel module.

[alain]

Package: virtualbox
Version: 7.0.4-dfsg-4
Severity: important
Tags: ftbfs
X-Debbugs-Cc: compte.perso.de-al...@bbox.fr

it seems that since the switch to kernels 6 ,
virtualbox is unusable on sid .

according to the error messages of systemd ,
the kernel module does not exist.

is there any other solution than switching to gnome - boxes (machines) ?

alain@sid:~$ sudo systemctl status virtualbox
× virtualbox.service - LSB: VirtualBox Linux kernel module
 Loaded: loaded (/etc/init.d/virtualbox; generated)
 Active: failed (Result: exit-code) since Mon 2022-12-12 08:18:40 CET;
11min ago
   Docs: man:systemd-sysv-generator(8)
Process: 1853 ExecStart=/etc/init.d/virtualbox start (code=exited,
status=1/FAILURE)
CPU: 31ms

déc. 12 08:18:40 sid systemd[1]: Starting LSB: VirtualBox Linux kernel
module...
déc. 12 08:18:40 sid virtualbox[1853]: Loading VirtualBox kernel
modules...modprobe vboxdrv failed. Please use 'dmesg' to find out why ...
failed!
déc. 12 08:18:40 sid virtualbox[1853]:  failed!
déc. 12 08:18:40 sid systemd[1]: virtualbox.service: Control process exited,
code=exited, status=1/FAILURE
déc. 12 08:18:40 sid systemd[1]: virtualbox.service: Failed with result 'exit-
code'.
déc. 12 08:18:40 sid systemd[1]: Failed to start LSB: VirtualBox Linux kernel
module.

alain@sid:~$ sudo dpkg -l virtualbox*
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-
installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ NomVersion  Architecture Description
+++-==---
ii  virtualbox 7.0.4-dfsg-4 amd64x86 virtualization
solution - base binaries
un  virtualbox-2.0   (aucune
description n'est disponible)
un  virtualbox-2.1   (aucune
description n'est disponible)
un  virtualbox-2.2   (aucune
description n'est disponible)
un  virtualbox-3.0   (aucune
description n'est disponible)
un  virtualbox-3.1   (aucune
description n'est disponible)
un  virtualbox-3.2   (aucune
description n'est disponible)
un  virtualbox-4.0   (aucune
description n'est disponible)
un  virtualbox-4.1   (aucune
description n'est disponible)
un  virtualbox-4.2   (aucune
description n'est disponible)
un  virtualbox-4.3   (aucune
description n'est disponible)
un  virtualbox-5.0   (aucune
description n'est disponible)
un  virtualbox-5.1   (aucune
description n'est disponible)
un  virtualbox-5.2   (aucune
description n'est disponible)
un  virtualbox-6.0   (aucune
description n'est disponible)
un  virtualbox-6.1   (aucune
description n'est disponible)
un  virtualbox-7.0   (aucune
description n'est disponible)
ii  virtualbox-dkms7.0.4-dfsg-4 amd64x86 virtualization
solution - kernel module sources for dkms
rc  virtualbox-ext-pack6.1.40-1 all  extra capabilities
for VirtualBox, downloader.
ii  virtualbox-guest-additions-iso 7.0.4-1  all  guest additions
iso image for VirtualBox
un  virtualbox-guest-modules (aucune
description n'est disponible)
ii  virtualbox-guest-utils 7.0.4-dfsg-4 amd64x86 virtualization
solution - non-X11 guest utilities
ii  virtualbox-guest-x11   7.0.4-dfsg-4 amd64x86 virtualization
solution - X11 guest utilities
un  virtualbox-modules   (aucune
description n'est disponible)
ii  virtualbox-qt  7.0.4-dfsg-4 amd64x86 virtualization
solution - Qt based user interface
ii  virtualbox-source  7.0.4-dfsg-4 amd64x86 virtualization
solution - kernel module source

alain@sid:~$ sudo modprobe vboxdrv
modprobe: ERROR: could not insert 'vboxdrv': Operation not permitted

don't know what to do ? and where to look ?



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

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

Versions of packages virtualbox depends on:
ii  adduser   3.129
ii  iproute2  6.0.0-1+b1
ii  libc6 2.36-6
ii  libcurl3-gnutls   7.86.0-2

Bug#1025931: RM: openvdb [mipsel] -- ROM; FTBFS on mipsel

[Mathieu Malaterre]

Package: ftp.debian.org
Severity: normal

I'd like to request the removal of openvdb on mipsel. I've tried
multiple times to get the latest release to build on the mipsel buildd
machines without no luck so far.

The 13 attempts can be seen in the experimental section:

* https://buildd.debian.org/status/logs.php?pkg=openvdb=mipsel

debian-mips porters have remained silent about those repeated build
failures due to limited RAM on buildds.

* https://lists.debian.org/debian-mips/2022/12/msg3.html
* https://lists.debian.org/debian-mips/2022/12/msg0.html
* https://lists.debian.org/debian-mips/2022/11/msg0.html

Thanks

Bug#1024166: blist: dead upstream, no maintainer upload since 2015

[Helmut Grohne]

Control: clone -1 -2
Control: severity -2 normal
Control: retitle -2 RM: blist -- RoQA; no rdeps; dead upstream; use 
sortedcontainers
Control: reassign -2 ftp.debian.org

Hi,

On Wed, Nov 16, 2022 at 11:47:19AM +0100, Sébastien Delafond wrote:
> elastalert is maintained by Freexian, I'll see what can be done on that
> side.

I've uploaded elastalert to not depend on blist anymore. With that, the
last rdep is gone.

I'm asking for blist removal now:
 * No rdeps.
 * Dead upstream.
 * Use python3-sortedcontainers instead.

Maintainer Cced.

Helmut

Bug#1025930: transition: openvdb

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I'd like to request a transition slot for openvdb 10.0.

openvdb 10.0 is available in experimental (except mipsel):

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

I've built all reverse dependencies without issues. I'll request the
removal of mipsel binaries.

Thanks

Ben file:

Affected: .depends ~ /\b(libopenvdb10\.0|libopenvdb9\.1)\b/
Good: .depends ~ /\b(libopenvdb10\.0)\b/
Bad: .depends ~ /\b(libopenvdb9\.1)\b/

Bug#1025929: RFS: ghostscript/10.0.0~dfsg-9 [QA] [RC] -- interpreter for the PostScript language and for PDF

[Håvard F . Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : ghostscript
   Version  : 10.0.0~dfsg-9
   Upstream contact : Ghostscript development and discussion 

 * URL  : https://www.ghostscript.com/
 * License  : LGPL-2.1, Expat~SunSoft with SunSoft exception, ZLIB, 
MIT-Open-Group, BSD-3-Clause, GPL-2+, NTP~Lucent, NTP~WSU, BSD-3-Clause~Adobe, 
Apache-2.0, AGPL-3+ with font exception, public-domain, Expat~Ghostgum, 
AGPL-3+, AGPL-3+ and custom, ISC, GAP~configure, AGPL-3+ and FTL, none, GPL-1+, 
Expat, GPL-3+ with Autoconf exception, X11
 * Vcs  : https://salsa.debian.org/debian/ghostscript
   Section  : text

The source builds the following binary packages:

  ghostscript - interpreter for the PostScript language and for PDF
  ghostscript-doc - interpreter for the PostScript language and for PDF - 
Documentation
  libgs10 - interpreter for the PostScript language and for PDF - Library
  libgs-common - interpreter for the PostScript language and for PDF - ICC 
profiles
  libgs10-common - interpreter for the PostScript language and for PDF - common 
files
  libgs-dev - interpreter for the PostScript language and for PDF - Development 
Files
  ghostscript-x - transitional package for ghostscript
  libgs9-common - transitional package for libgs-common

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/ghostscript/ghostscript_10.0.0~dfsg-9.dsc

Changes since the last upload:

 ghostscript (10.0.0~dfsg-9) unstable; urgency=medium
 .
   * QA upload.
   * Build docs with sphinx. Closes: #1024896, #1024964

Regards,
Håvard

Bug#1025791: fsck.f2fs is unable to check mounted FS

[Michael Tokarev]

12.12.2022 05:23, Theodore Ts'o wrote:

On Sun, Dec 11, 2022 at 09:55:48AM +0300, Michael Tokarev wrote:

..

I don't mind updating f2fs to current version in debian.  It does not seem
to have this particular issue fixed though.


Yeah, I'm not surprised.  The f2fs file system was engineered
primarily for Android, and I'm not aware of a lot of people trying to
use f2fs as a root file system on a Linux desktop or server.  And
Android has a read-only root file system (which uses dm-verity to
cryptographically guarantee that it can't be modified), and so the
data partition can be fsck'ed before it is mounted.

So this is not likely to be something which would be fixed by the f2fs
upstream.  That's not something that they are interested in, since
their primary focus has always been for Android.


I see.

FWIW, I too prefer root fs to be read-only 99% of the time (I only
remount it rw when installing/upgrading something, usually following
by a reboot or at least restart the services who are using old libraries
still, and remount-ro again).  So my usage is quite similar to android's :)

And here, I decided to use f2fs not on a desktop, but on a special "server"
which runs either out of emmc flash or an sd card (or an usb flash device).
It is not a regular ssd or nvme media, it is much more restricted, slow
and less wear-resistant than a regular ssd. I used ext4fs there before,
but it *smells* f2fs is better suited for the task. The "servers" aren't
really servers per se, it's more routers with additional functions. One
of them is running an Intel Celeron N3050 CPU for example, out of a 8Gb
CF card on top of SDHCI interface. Cheap, and, most importantly, cold
and dust-free, and does much more than a usual "router" box.  Maybe
f2fs can also be used on stuff like Raspberry PI, on its internal EMMC
or CF storage, too, - again, it *looks* like f2fs should be a good
candidate for the task.


I've taken a quick look at the f2fs-tools sources, and fixing it to
support allow fsck.f2fs to operate on a mounted file system is going
to require massive surgery.


..which is not something the upstream is interested in, I see.

..

The maintainer is set to filesystems-de...@lists.alioth.debian.org,
and the uploaders are the folks who are primarily working on the
package.  For f2fs-tools, it's Vincent cheng (who hasn't done an
upload since 2018), and me (and my last upload was in January 2021).
I have tried to do things like clean up the debian/rules file, and
keep things up to date with Debian standards.


I pushed "mjt" branch yesterday to the repository (without pristine-tar
and upstream pieces so far) which updates f2fs to 1.15 and adds minor
cleanups to d/rules. Please take a look.


Probably the only place where the package is a bit unclean is that
upstream *regularly* breaks the ABI, which means that we effectively
had to bump the package version every single upstream release.
Because the ABI is completely unstable, the normal Debian rationale
for using shared library breaks down (at every single package upload,
we end up breaking the ABI, which means any packages depending on the
shared library ends up using the old, stale shared library anyway).
And I got tired of ftpmasters taking 6-9 months to process an upload
since there was always a new binary package (from the shared library
bump --- EVERY SINGLE D*MNED TIME).


This is a known issue. I've faced it a few times myself, though in
my case I didn't want to add more work for ftp-masters and tried to
avoid soname bump. In one of my famous cases, the upstream just
didn't understand how soname/soversion works and always bumped
soname on package version bump - thinking it's cool to have the
same version for the library as the package, and all my attempts
to teach them to use proper versioning (there were many) failed.
So in Debian I patched the source on every upload, to keep the
same libiscsi.so.7 (I picked it up at 7) as before.  (And  yes,
that package has many other issues).

So, let's process 1.15. I don't really care much about the lack
of shared library at this time.  Please take a look.  I'm not the
first-day Debian developer, but maybe there's something specific
to this package or your habits which I didn't think about.

Thanks!

/mjt

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

[Anton Gladky]

Hi Niels,

thanks for the note. Yes, I will take care of it.

Regards

Anton

Bug#1025915: skill: -p $pid seems broken

[Craig Small]

Hi Chris,
  Thanks for your bug report. skill is one of those programs that isn't
used or loved much, but still hangs around. That being said, it shouldn't
have bugs like this!
When the program was converted to use the new API, the bit of code that
actually checks there is a match against the pidlist wasn't transferred.

It's a simple two-liner to fix and will be in the next Debian and upstream
release. There's also a test explicitly for this use-case.

 - Craig

Bug#1021292: Fw: Re: Enabling branch protection on amd64 and arm64

[Wookey]

The debian-devel thread continued but most responses were not copied to the bug 
(I've just realised). Possibly this means that you (guillem) didn't see most of 
the conversation.

The bottom line is the security team were very unenthusiastic about
enabling this by default because it might produce unexpected changes
on security uploads, which is fair enough.

Another suggestion was that it should be turned on for x32 too.

I was expecting (after that discussion) the 'branch' functionality to be
included in the next dpkg upload, just not enabled by default, but it
was not included in 1.21.12

Do you disagree or did this just get forgotten?


- Forwarded message from Moritz Mühlenhoff  -

Date: Wed, 26 Oct 2022 20:20:48 +0200
From: Moritz Mühlenhoff 
To: debian-de...@lists.debian.org
Subject: Re: Enabling branch protection on amd64 and arm64
List-Id: 

Wookey wrote:
> So the immediate issue now is whether or not to enable this by default
> in bookworm?

The majority of packages will not be rebuilt until the release, so
if we add this now it means that packages pick up the change when
they are rebuilt in stable via a security update or point release.
That's not very appealing, independent of the supposed low risk
factor.

I think this should rather be applied early after the Bookworm
release (and ideally we can also finish off the necessary testing
and add -fstack-clash-protection at least for amd64 and other archs
which are ready for it (#918914)).

Cheers,
Moritz


- End forwarded message -
Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#1024889: ntcard: ftbfs with nthash 2.3.0

[Nilesh Patra]

Hi Andreas,

On 12 December 2022 12:17:37 am IST, Andreas Tille  wrote:
>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. 

I tend to differ. That new update was segfaulting for a number of months until 
Hamid and you had a discussion to build it with no optimisations. When seeing 
signs of a software getting _kind of_ unstable, extra care should be taken, 
atleast given the fact that we are close to release.

There's a tool called reverse-depends that's a part of the ubuntu-dev-tools 
package. Simply running "$ reverse-depends t-coffee" and "$ reverse-depends 
t-coffee -b" would give an idea of the impact.

>A lot of effort was done to fix its autopkgtest in
>advance.  I simply assumed that passing its test is sufficient for an
>upload.

Which we have seen is not the case.
Again, this is from the perspective of us being near freeze. Such breakages are 
unhealthy at this point in time.

Autopkgtests are a good indicator that the current package is working for a few 
cases. But it can never almost give an indication about updating current 
software will break something else.

>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.

Agreed. But here's the question: was this really the right time to do a broken 
upload? Was it really that necessary?

Couldn't we have taken small steps and waited until the next debian release 
(Trixie) freeze to see if we got the ocaml support?

>However, there is some hope that MCL upstream might find a solution.

For sure. But I'm not sure if this is going to happen before the soft freeze 
ends.

>> 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.

I request the policy to be made mandatory during freeze time, i.e. starting 
from "soft-freeze - 2 months" till "release"

>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.

There are also library packages that are being updated. And I completely and 
absolutely disagree that updating them randomly without checking reverse deps 
does not cause any harm.

Not all upstreams follow semantic versioning properly and then are un-noticed 
API breakages which we have seen in nthash already for instance. I don't think 
doing more of these unchecked updates is benefitting anyone using debian at all.

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

--
Best,
Nilesh

Bug#1025928: gcc-12: Missing changelog entry for 12.2.0-9.1

[Sean Whitton]

Source: gcc-12
Version: 12.2.0-9.1

Dear maintainer,

I noticed that the debian/changelog entry for the 12.2.0-9.1 upload is
missing from the 12.2.0-10 upload.  The rest of the NMU is incorporated.
Here is a patch:

diff --git a/debian/changelog b/debian/changelog
index 458cae9..ed22964 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,6 +14,13 @@ gcc-12 (12.2.0-10) unstable; urgency=medium

  -- Matthias Klose   Sun, 11 Dec 2022 18:52:56 +0100

+gcc-12 (12.2.0-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * libgccjit0: Depend on libc6-dev (Closes: #1024431).
+
+ -- Sean Whitton   Fri, 02 Dec 2022 18:28:07 -0700
+
 gcc-12 (12.2.0-9) unstable; urgency=medium

   * Update to git 20221103 from the gcc-12 branch.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1025791: fsck.f2fs is unable to check mounted FS

[Theodore Ts'o]

On Sun, Dec 11, 2022 at 09:55:48AM +0300, Michael Tokarev wrote:
> 
> Hmm.  I'm a bit afraid it will be similar to my experience with samba.
> I come across a (data corruption) bug, discovered it's been fixed upstream
> a few years ago, tried to push the fix to debian, and ended up becoming a
> single maintainer of samba package in debian, and basically repackaging
> everything (because the package has been maintained in "rob Beter to pay
> Paul" or "random tinkering at the margins" mode for a few years).
> 
> I don't mind updating f2fs to current version in debian.  It does not seem
> to have this particular issue fixed though.

Yeah, I'm not surprised.  The f2fs file system was engineered
primarily for Android, and I'm not aware of a lot of people trying to
use f2fs as a root file system on a Linux desktop or server.  And
Android has a read-only root file system (which uses dm-verity to
cryptographically guarantee that it can't be modified), and so the
data partition can be fsck'ed before it is mounted.

So this is not likely to be something which would be fixed by the f2fs
upstream.  That's not something that they are interested in, since
their primary focus has always been for Android.

I've taken a quick look at the f2fs-tools sources, and fixing it to
support allow fsck.f2fs to operate on a mounted file system is going
to require massive surgery.  The short version is you can tell that
f2fs was written originally by firmware engineers from Samsung.

The software abstractions are utterly lacking (libf2fs communicates
with the application binary using the global variable "c", of type
struct f2fs_configuration).  The block device is opened in
get_device_info(i), with the block device name passed in
c.devices[i].path.

For e2fsprogs, the logic to determine whether the block device is
mounted, and whether it is mounted as the root device can be found in
lib/ext2fs/is_mounted.c, and the logic to decide whether it is safe to
open the block device read-only is in e2fsck/unix.c (search for code
involving EXT2_MF_ISROOT and EXT2_MF_READONLY).

There is no easy or clean way I can see to shoehorn this logic into
f2fs-tools.  If were going to tackle it, the very first thing I would
do is completely restructure libf2fs so it has a clean interface, and
then add silly things like regression tests.  Basically, the code
needs to be rototilled and rewritten almost from scratch.  Take a look
at libext2fs, which has had a stable API for multiple decades, and
then look at libf2fs, and weep.

So probably the best you can do to address this bug is to prevent the
boot up errors, by doing something like /sbin/fsck.xfs and
/sbin/fsck.btrfs.  Unless, that is, you want work with upstream to do
some pretty major surgery to f2fs-tools (whether it's done in a super
ugly way, or by first restructing the code so it has some clean
abstractions).


> (I don't remember how to join a group in whatever debian development system
> is in use there, - it was alioth before, now it seems to be just the
> mailing list part of it).

The filesystems group is pretty informal.  There is the mailing list
on lists.alioth.debian.org, and the git tree on salsa.debian.org is
writable to any DD; we're not doing any group access control.  (We
could have, but file system packages are set up with the Salsa default
which is that they are located the top-level Debian folder -- and
changing the access requires moving the gitlab project, as I
understand things.)

The maintainer is set to filesystems-de...@lists.alioth.debian.org,
and the uploaders are the folks who are primarily working on the
package.  For f2fs-tools, it's Vincent cheng (who hasn't done an
upload since 2018), and me (and my last upload was in January 2021).
I have tried to do things like clean up the debian/rules file, and
keep things up to date with Debian standards.

Probably the only place where the package is a bit unclean is that
upstream *regularly* breaks the ABI, which means that we effectively
had to bump the package version every single upstream release.
Because the ABI is completely unstable, the normal Debian rationale
for using shared library breaks down (at every single package upload,
we end up breaking the ABI, which means any packages depending on the
shared library ends up using the old, stale shared library anyway).
And I got tired of ftpmasters taking 6-9 months to process an upload
since there was always a new binary package (from the shared library
bump --- EVERY SINGLE D*MNED TIME).

Besides, the only dependency on libf2fs-tools is android-sdk packages,
which is based on an ancient Android SDK (25, and 28, where Android
SDK 28 EOL'ed in January 2022), so it's kind of hopeless from a
security perspective *anyway*, and anyone seriously doing Android
development is going to be using AOSP git repos.

Anyway, this is technically a Debian policy violation, but I really
haven't been able to bring myself to care, since it really doesn't
make any practical difference from 

Bug#946179: [lxcfs] lxcfs tries to delete systemd cgroup folders, fails stopping lxc

[Mathias Gibbens]

Hi,

  This bug was initially filed against a version from Debian stretch,
which is now oldoldstable. Is this problem still occurring for you, or
has it been resolved at some point over the past three years?

  This evening I performed a minimal install of bullseye, and then
installed lxc and lxcfs. I was able to create both privileged and
unprivileged containers which appeared to operate correctly.

Mathias


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

Bug#802416: zemberek-ooo: NMU to fix RC bugs

[Ying-Chun Liu (PaulLiu)]

Hi all,

I plan to fix #802416 and #965924.

The debdiff is as attachment.

I'll wait for 5 days. And then upload it to delay queue.

Teşekkürler,
Paul
diff -Nru zemberek-ooo-1.0~rc2/debian/changelog 
zemberek-ooo-1.0~rc2/debian/changelog
--- zemberek-ooo-1.0~rc2/debian/changelog   2022-12-12 09:55:38.0 
+0800
+++ zemberek-ooo-1.0~rc2/debian/changelog   2022-12-12 09:47:05.0 
+0800
@@ -1,3 +1,11 @@
+zemberek-ooo (1.0~rc2-10.5) unstable; urgency=low
+
+  * Non-maintainer upload. (Closes: #1017942)
+  * Bump debhelper compat to 10. (Closes: #965924)
+  * Fix FTBFS due to missing ure-link (Closes: #802416)
+
+ -- Ying-Chun Liu (PaulLiu)   Mon, 12 Dec 2022 09:47:05 
+0800
+
 zemberek-ooo (1.0~rc2-10.4) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru zemberek-ooo-1.0~rc2/debian/compat zemberek-ooo-1.0~rc2/debian/compat
--- zemberek-ooo-1.0~rc2/debian/compat  2022-12-12 09:55:38.0 +0800
+++ zemberek-ooo-1.0~rc2/debian/compat  2022-12-12 08:36:14.0 +0800
@@ -1 +1 @@
-5
+10
diff -Nru zemberek-ooo-1.0~rc2/debian/control 
zemberek-ooo-1.0~rc2/debian/control
--- zemberek-ooo-1.0~rc2/debian/control 2022-12-12 09:55:38.0 +0800
+++ zemberek-ooo-1.0~rc2/debian/control 2022-12-12 09:46:55.0 +0800
@@ -2,8 +2,8 @@
 Section: text
 Priority: optional
 Maintainer: Rail Aliev 
-Build-Depends: cdbs, debhelper (>= 5), libreoffice-dev, quilt, ant
-Build-Depends-Indep: default-jdk, libreoffice-java-common, libzemberek-java, 
libzemberek-tr-java, unzip
+Build-Depends: cdbs, debhelper (>= 10), libreoffice-dev, quilt, ant
+Build-Depends-Indep: default-jdk, libreoffice-java-common, libzemberek-java, 
libzemberek-tr-java, unzip, ure-java
 Build-Conflicts: libreoffice-common (<< 1:3.5.0~)
 Standards-Version: 3.8.2
 Homepage: http://code.google.com/p/zemberek/
diff -Nru zemberek-ooo-1.0~rc2/debian/patches/build.xml.diff 
zemberek-ooo-1.0~rc2/debian/patches/build.xml.diff
--- zemberek-ooo-1.0~rc2/debian/patches/build.xml.diff  2022-12-12 
09:55:38.0 +0800
+++ zemberek-ooo-1.0~rc2/debian/patches/build.xml.diff  2022-12-12 
09:04:50.0 +0800
@@ -2,19 +2,35 @@
 # authour via email. Applied in trunk.
 # Upstream: http://code.google.com/p/zemberek/source/detail?r=414
 ===
+Index: zemberek-ooo-1.0~rc2/build.xml
+===
 --- zemberek-ooo-1.0~rc2.orig/build.xml
 +++ zemberek-ooo-1.0~rc2/build.xml
-@@ -45,11 +45,11 @@
+@@ -1,4 +1,4 @@
+-
++
+ 
+ 
+ 
+@@ -45,11 +45,7 @@



 -  
-+  
-   
-   
-   
+-  
+-  
+-  
 -  
 +  



+@@ -57,7 +53,7 @@
+ 
+   
+   
++  deprecation="${compile.deprecation}" debug="${compile.debug}" 
optimize="${compile.optimize}" encoding="utf-8">
+   
+   
+   
diff -Nru zemberek-ooo-1.0~rc2/debian/rules zemberek-ooo-1.0~rc2/debian/rules
--- zemberek-ooo-1.0~rc2/debian/rules   2022-12-12 09:55:38.0 +0800
+++ zemberek-ooo-1.0~rc2/debian/rules   2022-12-12 09:41:39.0 +0800
@@ -2,7 +2,6 @@
   
 include /usr/share/cdbs/1/class/ant.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
-include /usr/share/cdbs/1/rules/patchsys-quilt.mk
 
 JAVA_HOME  :=  /usr/lib/jvm/default-java
 DEB_JARS   := zemberek zemberek-tr
diff -Nru zemberek-ooo-1.0~rc2/debian/source/format 
zemberek-ooo-1.0~rc2/debian/source/format
--- zemberek-ooo-1.0~rc2/debian/source/format   1970-01-01 08:00:00.0 
+0800
+++ zemberek-ooo-1.0~rc2/debian/source/format   2022-12-12 08:35:40.0 
+0800
@@ -0,0 +1 @@
+3.0 (quilt)


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025927: FTBFS: removed definition of refreshed bool github monero-project/monero #8673

[C.J. Collier]

Package: cryptocoin
Version: 0.18.0.0+~0+20200826-1
Severity: normal

Dear Maintainer,

I was unable to build the package from source due to debian treating
warnings as errors.  I've asked upstream if they want the patch, and
they seem to be declining.

>From conversation on https://github.com/monero-project/monero/pull/8673

 It should not fail to build from source due to an unused variable,
unless you changed other things.

log=<
https://github.com/monero-project/monero/pull/8673
18:28 < cjac> hi folks, could I get a LGTM for
https://github.com/monero-project/monero/pull/8673 ?
18:29 < cjac> selsta: the FTBFS came from particularly strict gcc flags
18:29 < cjac> this is the debian policy, so it's keeping debian from
building.  I could commit this patch
  to debian, but I wanted to check with you folks first.
18:30 < cjac> https://paste.debian.net/1263691/
18:52 <+selsta> cjac: where did you add this GCC flag? and why does it
cause the compiler to get killed?
18:54 <+selsta> if you add some kind of "treat warnings as errors" flag it
wouldn't kill the compiler as
far as i'm aware
20:21 < jtgrassie> cjac: "this is the debian policy, so it's keeping debian
from building." <- package
   maintainers are free t use whatever compiler options
they like
20:22 < jtgrassie> you're only highlighting a warning, not an error
21:36 < cjac> jtgrassie, selsta: no problem.  I can patch the debian
package, but our policy is to try to
  offer upstream first.  If you don't want this patch, no
worries.
EOIRC

I tried removing the definition of the offending variable, but it is
used elsewhere, so instead I removed the definition.

This patch will merely remove the definition of the refreshed bool at
declaration time.

=== Patch begins ===
diff --git a/debian/patches/2002_privacy.patch
b/debian/patches/2002_privacy.patch
index a2725ba47..6d4f78ac5 100644
--- a/debian/patches/2002_privacy.patch
+++ b/debian/patches/2002_privacy.patch
@@ -6,7 +6,7 @@ Last-Update: 2022-07-31
 This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
 --- a/README.md
 +++ b/README.md
-@@ -10,7 +10,6 @@ Portions Copyright (c) 2012-2013 The Cryptonote
developers.
+@@ -10,7 +10,6 @@
- [Research](#research)
- [Announcements](#announcements)
- [Translations](#translations)
@@ -14,7 +14,7 @@ This patch header follows DEP-3:
http://dep.debian.net/deps/dep3/
- [Introduction](#introduction)
- [About this project](#about-this-project)
- [Supporting the project](#supporting-the-project)
-@@ -56,15 +55,6 @@ The CLI wallet is available in different languages. If
you want to help translat
+@@ -56,15 +55,6 @@

  If you need help/support/info about translations, contact the
localization workgroup. You can find the complete list of contacts on the
repository of the workgroup: [monero-translat
ions](https://github.com/monero-ecosystem/monero-translations#contacts).

@@ -30,7 +30,7 @@ This patch header follows DEP-3:
http://dep.debian.net/deps/dep3/
  ## Introduction

  Monero is a private, secure, untraceable, decentralised digital currency.
You are your bank, you control your funds, and nobody can trace your
transfers unless you allow them to do
so.
-@@ -101,11 +91,11 @@ The Bitcoin donation address is:
+@@ -101,11 +91,11 @@

  Core development funding and/or some supporting services are also
graciously provided by [sponsors](
https://www.getmonero.org/community/sponsorships/):

diff --git a/debian/patches/2003_refreshed_ftbfs_8673.patch
b/debian/patches/2003_refreshed_ftbfs_8673.patch
new file mode 100644
index 0..79a2d2390
--- /dev/null
+++ b/debian/patches/2003_refreshed_ftbfs_8673.patch
@@ -0,0 +1,19 @@
+removed definition of refreshed bool #8673
+
+https://github.com/monero-project/monero/pull/8673
+
+/usr/src/git/salsa/cryptocoin-team/monero/src/wallet/wallet2.cpp:3427:8:
warning: variable ‘refreshed’ set but not used [-Wunused-but-set-variable]
+3427 | bool refreshed = false;
+
+Fails to build from source.
+--- a/src/wallet/wallet2.cpp
 b/src/wallet/wallet2.cpp
+@@ -3424,7 +3424,7 @@
+   uint64_t blocks_start_height;
+   std::vector blocks;
+   std::vector parsed_blocks;
+-  bool refreshed = false;
++  bool refreshed;
+   std::shared_ptr, size_t>>
output_tracker_cache;
+   hw::device  = m_account.get_device();
+
diff --git a/debian/patches/series b/debian/patches/series
index f04e571a7..c4c103630 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 2001_system_shared_libs.patch
 2002_privacy.patch
+2003_refreshed_ftbfs_8673.patch
=== Patch ends ===

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

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

Bug#856393: lxcfs: error message from the kernel: cgroup: new mount options do not match the existing superblock, will be ignored

[Mathias Gibbens]

Hi,

  Is this behavior still seen in bullseye with lxcfs 4.0.7-1?

  I just performed a minimal install of bullseye, and then installed
lxcfs. I don't see any warnings/errors in either the kernel log or the
systemd journal for the process.

Mathias


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

Bug#1017942: RM: zemberek-ooo -- RoQA, unmainted, low popcorn, RC-buggy

[Ying-Chun Liu (PaulLiu)]

Hi all,

I fixed all of the RC bugs. Please allow me to NMU it.
And I've tested that it still works ok.

Thanks,
Paul


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021846: [programmer11...@programist.ru: Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem]

[Steve McIntyre]

On Sat, Dec 10, 2022 at 07:40:47AM +0300, программист некто wrote:
>Hello. Sorry for long wait.
>
>>программист некто: could you please try these changes and report back?
>
>I tried the first patch with grub 2.06-7. Result: grub-install works without 
>error.

Cool, thanks for confirming!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis

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

[Bernhard Übelacker]

Am 12.12.22 um 00:39 schrieb Dirk Eddelbuettel:


On 11 December 2022 at 17:05, Bernhard Übelacker wrote:
| 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.

Do you have a suggested patch, and with it a 'before' and 'after' run that
fail and pass, respectively?  It's been a while since I looked at this (you
replied to an email from two months ago ...) so I am a little out of context
now.

Best, Dirk
  
| 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 
| $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 
| $3 = (off_t *) 0x561a373e5d60 
| (gdb) print sizeof(tsamples)
| $4 = 8
| (gdb) frame 4
| #4  0x561a373b3332 in main (argc=4, argv=0x7fffcca27f88) at 

Bug#858488: dieharder segfaults when testing the XOR generator

[Dirk Eddelbuettel]

On 11 December 2022 at 22:39, Bernhard Übelacker wrote:
| just for convenience:
| https://github.com/eddelbuettel/rdieharder/issues/3

Yeah, but rather than piling up links to existing issue we could probably do
with a fix. Ah well...

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

[Dirk Eddelbuettel]

On 11 December 2022 at 17:05, Bernhard Übelacker wrote:
| 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.

Do you have a suggested patch, and with it a 'before' and 'after' run that
fail and pass, respectively?  It's been a while since I looked at this (you
replied to an email from two months ago ...) so I am a little out of context
now.

Best, Dirk
 
| 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 
| $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 
| $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

Bug#1025926: usrmerge: fails postinst on initial install on amd64

[Helmut Grohne]

Package: usrmerge
Version: 34
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

Installing usrmerge on amd64 (either via mmdebstrap or via upgrade from
an unmerged bullseye to unstable) fails:

| Unpacking usrmerge (34) ...
| Setting up usrmerge (34) ...
| ionice: ioprio_set failed: Operation not permitted
| chrt: failed to set pid 4638's policy: Operation not permitted
| cp: cannot create symbolic link '/usr/lib64/ld-linux-x86-64.so.2': No such 
file or directory
| 
| FATAL ERROR:
| cp --no-dereference --preserve=all --reflink=auto --sparse=always 
/lib64/ld-linux-x86-64.so.2 /usr/lib64/ld-linux-x86-64.so.2: rc=1
| 
| You can try correcting the errors reported and running again
| /usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
| Do not install or update other Debian packages until the program
| has been run successfully.
| 
| E: usrmerge failed.
| dpkg: error processing package usrmerge (--configure):
|  installed usrmerge package post-installation script subprocess returned 
error exit status 1
| Errors were encountered while processing:
|  usrmerge
| E: Sub-process /usr/bin/dpkg returned an error code (1)

Reproducers:

mmdebstrap unstable /dev/null

mmdebstrap --verbose --customize-hook='sed -i -e s/bullseye/unstable/ 
"$1/etc/apt/sources.list"' --customize-hook='chroot "$1" apt update' 
--customize-hook='chroot "$1" apt-get -y dist-upgrade' bullseye /dev/null

Helmut

Bug#1025862: ITP: templated-dictionary -- Dictionary with Jinja2 expansion

[Juri Grabowski]

Hi Mike,

it would be very nice. I have updated it now to new version, after
message from upstream:
https://pypi.org/project/templated-dictionary/#history
Thank you.

Best Regards,
Juri Grabowski

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

[Harlan Lieberman-Berg]

tags 1025891 +pending,+confirmed
thanks
On Sun, Dec 11, 2022 at 1:03 PM Mathias Ertl  wrote:
> 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.

Hello Mathias,

Thank you for reporting the issue!  I've prepared a stable upload and
have sent a request for approval to the stable release team
(#1025925).

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#1025925: bullseye-pu: package python-acme/1.12.0-2

[Harlan Lieberman-Berg]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: python-a...@packages.debian.org, hlieber...@debian.org
Control: affects -1 + src:python-acme

Hello SRMs!

A bug, #1025891, was recently reported about the certbot package failing to
produce certificates when run against certain strictly-RFC-complying instances
of the ACME API. A fix is present upstream in later versions, however, stable is
still affected.

This is a simple backport, changing only the version number (and its associated
test), taken from upstream.

I have tested the updated version of certbot against the Let's Encrypt test
instances directly, and through the apache and nginx plugins. All were
successful. Note: the Let's Encrypt API is not strictly-RFC-complying in this
regard, so this proves only that the package is not broken further. However,
considering the simplicity of the patch, I'm not concerned about testing against
a stricter endpoint.

A source debdiff is attached.  I await your thumbs-up before uploading.

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman
diff -Nru python-acme-1.12.0/debian/changelog 
python-acme-1.12.0/debian/changelog
--- python-acme-1.12.0/debian/changelog 2021-02-02 16:37:28.0 -0500
+++ python-acme-1.12.0/debian/changelog 2022-12-11 16:44:00.0 -0500
@@ -1,3 +1,10 @@
+python-acme (1.12.0-2+deb11u1) bullseye; urgency=medium
+
+  * Fix CSR version to prevent problems with strictly RFC-complying
+implementations of the ACME API (Closes: #1025891)
+
+ -- Harlan Lieberman-Berg   Sun, 11 Dec 2022 16:44:00 
-0500
+
 python-acme (1.12.0-2) unstable; urgency=medium
 
   * Commit missed changes to control file.
diff -Nru python-acme-1.12.0/debian/control python-acme-1.12.0/debian/control
--- python-acme-1.12.0/debian/control   2021-02-02 16:37:28.0 -0500
+++ python-acme-1.12.0/debian/control   2022-12-11 16:26:05.0 -0500
@@ -7,7 +7,6 @@
 Build-Depends: debhelper-compat (= 13),
dh-python,
python3,
-   python3-chardet,
python3-cryptography (>= 2.1.4),
python3-docutils,
python3-josepy,
@@ -18,6 +17,7 @@
python3-requests-toolbelt,
python3-rfc3339,
python3-setuptools (>= 11.3),
+   python3-six (>= 1.9),
python3-sphinx (>= 1.3.1-1~),
python3-sphinx-rtd-theme,
python3-tz
diff -Nru python-acme-1.12.0/debian/patches/fix-csr-version.patch 
python-acme-1.12.0/debian/patches/fix-csr-version.patch
--- python-acme-1.12.0/debian/patches/fix-csr-version.patch 1969-12-31 
19:00:00.0 -0500
+++ python-acme-1.12.0/debian/patches/fix-csr-version.patch 2022-12-11 
16:42:50.0 -0500
@@ -0,0 +1,40 @@
+Description: Fix incorrect CSR version
+  Certain strict implementations of the ACME API deny all version numbers 
except
+  that defined in the RFC (version 0). To accommodate, unilaterally set it to 
0.
+Author: Amir Omidi
+Origin: https://github.com/certbot/certbot/pull/9334/
+Bug-Debian: https://bugs.debian.org/1025891
+Acked-By: Harlan Lieberman-Berg 
+Index: python-acme/acme/crypto_util.py
+===
+--- python-acme.orig/acme/crypto_util.py
 python-acme/acme/crypto_util.py
+@@ -213,7 +213,8 @@ def make_csr(private_key_pem, domains, m
+ value=b"DER:30:03:02:01:05"))
+ csr.add_extensions(extensions)
+ csr.set_pubkey(private_key)
+-csr.set_version(2)
++# RFC 2986 Section 4.1 only defines version 0
++csr.set_version(0)
+ csr.sign(private_key, 'sha256')
+ return crypto.dump_certificate_request(
+ crypto.FILETYPE_PEM, csr)
+Index: python-acme/tests/crypto_util_test.py
+===
+--- python-acme.orig/tests/crypto_util_test.py
 python-acme/tests/crypto_util_test.py
+@@ -244,6 +244,14 @@ class MakeCSRTest(unittest.TestCase):
+ self.assertEqual(len(must_staple_exts), 1,
+ "Expected exactly one Must Staple extension")
+ 
++def test_make_csr_correct_version(self):
++csr_pem = self._call_with_key(["a.example"])
++csr = OpenSSL.crypto.load_certificate_request(
++OpenSSL.crypto.FILETYPE_PEM, csr_pem)
++
++self.assertEqual(csr.get_version(), 0,
++ "Expected CSR version to be v1 (encoded as 0), per 
RFC 2986, section 4")
++
+ 
+ class DumpPyopensslChainTest(unittest.TestCase):
+ """Test for dump_pyopenssl_chain."""
diff -Nru python-acme-1.12.0/debian/patches/series 
python-acme-1.12.0/debian/patches/series
--- python-acme-1.12.0/debian/patches/series2021-01-10 14:56:16.0 
-0500
+++ python-acme-1.12.0/debian/patches/series2022-12-11 16:38:15.0 
-0500
@@ -1 +1,2 @@
 disable-tls-alpn-test.patch
+fix-csr-version.patch

Bug#1025924: python-rx: Fails to build with Python 3.11 (AttributeError: module 'asyncio' has no attribute 'coroutine')

[Colin Watson]

Source: python-rx
Version: 3.2.0-2
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source

python-rx fails to build now that tests are being run on Python 3.11.
Here are the failures from pytest:

=== FAILURES 
===
__ TestFromFuture.test_future_cancel 
___

self = 

def test_future_cancel(self):
loop = asyncio.get_event_loop()
success = [True, False, True]

>   @asyncio.coroutine
E   AttributeError: module 'asyncio' has no attribute 'coroutine'

tests/test_observable/test_fromfuture.py:66: AttributeError
__ TestFromFuture.test_future_dispose 
__

self = 

def test_future_dispose(self):
loop = asyncio.get_event_loop()
success = [True, True, True]

>   @asyncio.coroutine
E   AttributeError: module 'asyncio' has no attribute 'coroutine'

tests/test_observable/test_fromfuture.py:90: AttributeError
__ TestFromFuture.test_future_failure 
__

self = 

def test_future_failure(self):
loop = asyncio.get_event_loop()
success = [True, False, True]

>   @asyncio.coroutine
E   AttributeError: module 'asyncio' has no attribute 'coroutine'

tests/test_observable/test_fromfuture.py:39: AttributeError
__ TestFromFuture.test_future_success 
__

self = 

def test_future_success(self):
loop = asyncio.get_event_loop()
success = [False, True, False]

>   @asyncio.coroutine
E   AttributeError: module 'asyncio' has no attribute 'coroutine'

tests/test_observable/test_fromfuture.py:14: AttributeError
__ TestStart.test_start_async 
__

self = 

def test_start_async(self):
loop = asyncio.get_event_loop()
success = [False]

>   @asyncio.coroutine
E   AttributeError: module 'asyncio' has no attribute 'coroutine'

tests/test_observable/test_start.py:23: AttributeError
___ TestStart.test_start_async_error 
___

self = 

def test_start_async_error(self):
loop = asyncio.get_event_loop()
success = [False]

>   @asyncio.coroutine
E   AttributeError: module 'asyncio' has no attribute 'coroutine'

tests/test_observable/test_start.py:43: AttributeError
__ TestAsyncIOScheduler.test_asyncio_schedule_action 
___

self = 


def test_asyncio_schedule_action(self):
loop = asyncio.get_event_loop()

>   @asyncio.coroutine
E   AttributeError: module 'asyncio' has no attribute 'coroutine'

tests/test_scheduler/test_eventloop/test_asyncioscheduler.py:33: 
AttributeError
___ TestAsyncIOScheduler.test_asyncio_schedule_action_cancel 
___

self = 


def test_asyncio_schedule_action_cancel(self):
loop = asyncio.get_event_loop()

>   @asyncio.coroutine
E   AttributeError: module 'asyncio' has no attribute 'coroutine'

tests/test_scheduler/test_eventloop/test_asyncioscheduler.py:80: 
AttributeError
 TestAsyncIOScheduler.test_asyncio_schedule_action_due 
_

self = 


def test_asyncio_schedule_action_due(self):
loop = asyncio.get_event_loop()

>   @asyncio.coroutine
E   AttributeError: module 'asyncio' has no attribute 'coroutine'

tests/test_scheduler/test_eventloop/test_asyncioscheduler.py:55: 
AttributeError
 TestAsyncIOThreadSafeScheduler.test_asyncio_threadsafe_schedule_action 


self = 


def test_asyncio_threadsafe_schedule_action(self):
loop = asyncio.get_event_loop()

>   @asyncio.coroutine
E   AttributeError: module 'asyncio' has no attribute 'coroutine'

tests/test_scheduler/test_eventloop/test_asynciothreadsafescheduler.py:34: 
AttributeError
_ 
TestAsyncIOThreadSafeScheduler.test_asyncio_threadsafe_schedule_action_cancel _

self = 


def test_asyncio_threadsafe_schedule_action_cancel(self):
loop = asyncio.get_event_loop()

>   @asyncio.coroutine
E   AttributeError: module 'asyncio' has no attribute 'coroutine'

tests/test_scheduler/test_eventloop/test_asynciothreadsafescheduler.py:87: 
AttributeError
_ 
TestAsyncIOThreadSafeScheduler.test_asyncio_threadsafe_schedule_action_cancel_same_loop
 _

self = 


def 

Bug#1025000: python-qtawesome: Includes non-source Font Awesome 5

[Bastian Germann]

finalcif's source has some fa5 prefixes, so the package might be affected.
Andrius, can you please comment on this?

Bug#1025862: ITP: templated-dictionary -- Dictionary with Jinja2 expansion

[Mike Gabriel]

Hi Juri,

On  Sa 10 Dez 2022 18:55:20 CET, Juri Grabowski wrote:


Package: wnpp
Severity: wishlist
Owner: Juri Grabowski 
X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@jugra.de

* Package name: templated-dictionary
  Version : 1.1
  Upstream Author : Miroslav Suchý 
* URL : https://pypi.org/project/templated-dictionary/
* License : GPLv2+
  Programming Lang: Python
  Description : Dictionary with Jinja2 expansion

  This module provides dictionary where every item is evaluated as a
  Jinja2 expression.

  needed by mock/3.5 and I need a sponsor for this package. See current
  packaging in
  https://salsa.debian.org/python-team/packages/templated-dictionary


I can take a close look tomorrow morning and upload (I took a quick  
glance just now and the pkg looks ok on Salsa).


Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpxBO9PKaKhO.pgp
Description: Digitale PGP-Signatur

Bug#1024980: Related to Debian changes to use trust-dns 0.21

[Duncan Findlay]

I tried reproducing this issue with several modified versions of
aardvark-dns to see if I could narrow down the cause.

I could not reproduce this with upstream source at head, nor with
upstream source at v1.0.3.

I did reproduce this issue both with the debian packaged version of
1.0.3, and with upstream source at head with the debian
trust-dns-0.21.patch applied and the corresponding dependency bump.

I was also able to get better logging by starting the container with:
$ podman --log-level=trace run -it --rm --name test1 --net test-net alpine

When I reproduce this, with an nslookup for test1 in this container
with trace logging, I see ~128k messages in syslog of the form:
2022-12-11T11:24:35.222884-08:00 salmon aardvark-dns[0]: reading A

The messages end when the query fails.

The log messages are different if I do an nslookup for a non-existent
name, but also show a tight loop; worse, the log messages continue
after the query fails until the container exits.

My guess is we're using trust-dns 0.21 wrong, and it's causing us to
loop repeatedly instead of returning a response?

Thanks
Duncan

Bug#858488: dieharder segfaults when testing the XOR generator

[Bernhard Übelacker]

just for convenience:
https://github.com/eddelbuettel/rdieharder/issues/3

Bug#1025923: python3-adios fails to install: update-alternatives: error: alternative path /usr/lib/python3/dist-packages/adios_openmpi/adios_mpi..so doesn't exist

[Helmut Grohne]

Package: python3-adios
Version: 1.13.1-30+b3
Severity: serious

python3-adios fails to install in unstable on amd64:

| Setting up python3-adios (1.13.1-30+b3) ...
| update-alternatives: error: alternative path 
/usr/lib/python3/dist-packages/adios_openmpi/adios_mpi..so doesn't exist
| dpkg: error processing package python3-adios (--configure):
|  installed python3-adios package post-installation script subprocess returned 
error exit status 2
| Processing triggers for libc-bin (2.36-5) ...
| Errors were encountered while processing:
|  python3-adios
| E: Sub-process /usr/bin/dpkg returned an error code (1)

Helmut

Bug#912284: nginx FTCBFS: multiple reasons

[Helmut Grohne]

Hi,

On Mon, Oct 29, 2018 at 09:34:00PM +0100, Helmut Grohne wrote:
> The attached patch fixes all of the issues above. After applying it,
> nginx fails finding accept4, struct in6_pktinfo and NGX_SYS_NERR.
> Likely, some checks are still broken. Still I think that the patch is an
> incremental step in the right direction. Please consider applying it and
> close this bug when doing so.

I've updated the patch to actually make nginx fully cross buildable.

Helmut
diff --minimal -Nru nginx-1.22.1/debian/changelog nginx-1.22.1/debian/changelog
--- nginx-1.22.1/debian/changelog   2022-12-08 14:15:15.0 +0100
+++ nginx-1.22.1/debian/changelog   2022-12-11 12:05:06.0 +0100
@@ -1,3 +1,19 @@
+nginx (1.22.1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #912284)
++ cross.patch: Accept a compiler without running binaries.
++ Pass a C compiler to configure.
++ cross.patch: Implement auto/cc/name without running.
++ Pass --crossbuild to configure.
++ cross.patch: When passing --crossbuild, set NGX_CROSSBUILD.
++ cross.patch: When NGX_CROSSBUILD, assume that gcc does atomics.
++ cross.patch: When NGX_CROSSBUILD, only build the MAP_ANON test.
++ B-D: perl-xs-dev.
++ debian/rules: Fix build vs host confusion.
+
+ -- Helmut Grohne   Sun, 11 Dec 2022 12:05:06 +0100
+
 nginx (1.22.1-4) unstable; urgency=medium
 
   * d/t/*-module-deps: updated, added curl timeout 300 seconds and
diff --minimal -Nru nginx-1.22.1/debian/control nginx-1.22.1/debian/control
--- nginx-1.22.1/debian/control 2022-12-08 14:15:15.0 +0100
+++ nginx-1.22.1/debian/control 2022-12-11 12:05:06.0 +0100
@@ -12,9 +12,9 @@
libmhash-dev,
libpam0g-dev,
libpcre3-dev,
-   libperl-dev,
libssl-dev,
libxslt1-dev,
+   perl-xs-dev,
po-debconf,
quilt,
zlib1g-dev
diff --minimal -Nru nginx-1.22.1/debian/patches/cross.patch 
nginx-1.22.1/debian/patches/cross.patch
--- nginx-1.22.1/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ nginx-1.22.1/debian/patches/cross.patch 2022-12-11 12:05:06.0 
+0100
@@ -0,0 +1,146 @@
+--- nginx-1.22.1.orig/auto/cc/name
 nginx-1.22.1/auto/cc/name
+@@ -7,7 +7,7 @@
+ 
+ ngx_feature="C compiler"
+ ngx_feature_name=
+-ngx_feature_run=yes
++ngx_feature_run=no
+ ngx_feature_incs=
+ ngx_feature_path=
+ ngx_feature_libs=
+--- nginx-1.22.1.orig/auto/types/sizeof
 nginx-1.22.1/auto/types/sizeof
+@@ -26,7 +26,7 @@
+ $NGX_INCLUDE_AUTO_CONFIG_H
+ 
+ int main(void) {
+-printf("%d", (int) sizeof($ngx_type));
++char canary[1 - 2 * (sizeof($ngx_type) != 8)];
+ return 0;
+ }
+ 
+@@ -38,20 +38,55 @@
+ 
+ eval "$ngx_test >> $NGX_AUTOCONF_ERR 2>&1"
+ 
++if [ -x $NGX_AUTOTEST ]; then
++ngx_size_is_8=yes
++else
++ngx_size_is_8=no
++fi
++
++rm -rf $NGX_AUTOTEST*
++
++cat << END > $NGX_AUTOTEST.c
++
++#include 
++#include 
++$NGX_INCLUDE_UNISTD_H
++#include 
++#include 
++#include 
++$NGX_INCLUDE_INTTYPES_H
++$NGX_INCLUDE_AUTO_CONFIG_H
++
++int main(void) {
++char canary[1 - 2 * (sizeof($ngx_type) != 4)];
++return 0;
++}
++
++END
++
++
++ngx_test="$CC $CC_TEST_FLAGS $CC_AUX_FLAGS \
++  -o $NGX_AUTOTEST $NGX_AUTOTEST.c $NGX_LD_OPT $ngx_feature_libs"
++
++eval "$ngx_test >> $NGX_AUTOCONF_ERR 2>&1"
+ 
+ if [ -x $NGX_AUTOTEST ]; then
+-ngx_size=`$NGX_AUTOTEST`
+-echo " $ngx_size bytes"
++ngx_size_is_4=yes
++else
++ngx_size_is_4=no
+ fi
+ 
++rm -rf $NGX_AUTOTEST*
+ 
+-case $ngx_size in
+-4)
++case $ngx_size_is_8:$ngx_size_is_4 in
++no:yes)
++  ngx_size=4
+ ngx_max_value=2147483647
+ ngx_max_len='(sizeof("-2147483648") - 1)'
+ ;;
+ 
+-8)
++yes:no)
++  ngx_size=8
+ ngx_max_value=9223372036854775807LL
+ ngx_max_len='(sizeof("-9223372036854775808") - 1)'
+ ;;
+@@ -66,11 +101,7 @@
+ echo $ngx_test   >> $NGX_AUTOCONF_ERR
+ echo "--">> $NGX_AUTOCONF_ERR
+ 
+-rm -rf $NGX_AUTOTEST*
+-
+ exit 1
+ esac
+ 
+-
+-rm -rf $NGX_AUTOTEST*
+-
++echo " $ngx_size bytes"
+--- nginx-1.22.1.orig/auto/cc/conf
 nginx-1.22.1/auto/cc/conf
+@@ -180,6 +180,9 @@
+ 
+ if [ "$NGX_CC_NAME" = "sunc" ]; then
+ echo "checking for gcc builtin atomic operations ... disabled"
++elif [ "$NGX_CC_NAME" = gcc ] && [ "$NGX_CROSSBUILD" = YES ]; then
++  echo "checking for gcc builtin atomic operations ... assumed available 
during cross build with gcc"
++have=NGX_HAVE_GCC_ATOMIC . auto/have
+ else
+ ngx_feature="gcc builtin atomic operations"
+ ngx_feature_name=NGX_HAVE_GCC_ATOMIC
+--- nginx-1.22.1.orig/auto/options
 nginx-1.22.1/auto/options
+@@ -34,6 +34,7 @@
+ NGX_TEST_BUILD_SOLARIS_SENDFILEV=NO
+ 
+ NGX_PLATFORM=
++NGX_CROSSBUILD=NO
+ NGX_WINE=
+ 
+ 

Bug#1025922: net-snmp FTCBFS: a number of remaining issues

[Helmut Grohne]

Source: net-snmp
Version: 5.9.3+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

This essentially is a follow-up on #944953. Thanks for integrating my
earlier changes from that bug. Last time, I didn't figure how to make
the perl extension build work. Now, I'm attaching a patch to fix that.
It also fixes a number of other issues relating to architecture
variables in debian/rules. This patch actually makes net-snmp cross
buildable. Please consider applying it.

Helmut
diff --minimal -Nru net-snmp-5.9.3+dfsg/debian/changelog 
net-snmp-5.9.3+dfsg/debian/changelog
--- net-snmp-5.9.3+dfsg/debian/changelog2022-07-18 13:28:38.0 
+0200
+++ net-snmp-5.9.3+dfsg/debian/changelog2022-12-10 15:39:34.0 
+0100
@@ -1,3 +1,15 @@
+net-snmp (5.9.3+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Initialize architecture variables.
++ Fix build vs host confusion.
++ Use the host architecture pkg-config.
++ export a PERL5LIB for cross building.
++ cross.patch: Pass PERL5LIB along.
+
+ -- Helmut Grohne   Sat, 10 Dec 2022 15:39:34 +0100
+
 net-snmp (5.9.3+dfsg-1) unstable; urgency=medium
 
   * New upstream source
diff --minimal -Nru net-snmp-5.9.3+dfsg/debian/patches/cross.patch 
net-snmp-5.9.3+dfsg/debian/patches/cross.patch
--- net-snmp-5.9.3+dfsg/debian/patches/cross.patch  2022-07-18 
13:28:38.0 +0200
+++ net-snmp-5.9.3+dfsg/debian/patches/cross.patch  2022-12-10 
15:39:34.0 +0100
@@ -34,3 +34,14 @@
  AC_SUBST(MYSQL_LIBS)
  AC_SUBST(MYSQL_INCLUDES)
  
+--- net-snmp-5.9.3+dfsg.orig/Makefile.in
 net-snmp-5.9.3+dfsg/Makefile.in
+@@ -186,7 +186,7 @@
+   if false; then  \
+   carp=-MCarp::Always;\
+   fi &&   \
+-  export PERL5LIB="$$dir/perl" && \
++  export PERL5LIB="$$dir/perl$${PERL5LIB:+:$$PERL5LIB}" &&\
+   $(PERL) $$carp Makefile.PL -NET-SNMP-IN-SOURCE=true \
+   -NET-SNMP-CONFIG="sh $$dir/net-snmp-config" $(PERLARGS)
+ 
diff --minimal -Nru net-snmp-5.9.3+dfsg/debian/rules 
net-snmp-5.9.3+dfsg/debian/rules
--- net-snmp-5.9.3+dfsg/debian/rules2022-07-18 13:28:38.0 +0200
+++ net-snmp-5.9.3+dfsg/debian/rules2022-12-10 15:39:33.0 +0100
@@ -2,7 +2,8 @@
 #export DH_VERBOSE=1
 
 export DEB_BUILD_MAINT_OPTIONS := hardening=+all
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+include /usr/share/dpkg/architecture.mk
+include /usr/share/dpkg/buildtools.mk
 
 LIB_VERSION = 40
 
@@ -11,22 +12,26 @@
 
 
MIBS_DIR="/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf"
 
-ifeq (linux,$(DEB_BUILD_ARCH_OS))
+ifeq (linux,$(DEB_HOST_ARCH_OS))
 MIB_MODULES += ucd-snmp/diskio ucd-snmp/lmsensorsMib 
etherlike-mib/dot3StatsTable
 DEB_DH_GENCONTROL_ARGS=-- -Vos-specific-dev="libsensors4-dev"
 else
-ifeq (kfreebsd,$(DEB_BUILD_ARCH_OS))
+ifeq (kfreebsd,$(DEB_HOST_ARCH_OS))
 DEB_DH_GENCONTROL_ARGS=-- -Vos-specific-dev="libkvm-dev"
-CFLAGS += $(shell pkg-config --cflags libbsd-overlay)
-LDFLAGS += $(shell pkg-config --libs libbsd-overlay)
+CFLAGS += $(shell $(PKG_CONFIG) --cflags libbsd-overlay)
+LDFLAGS += $(shell $(PKG_CONFIG) --libs libbsd-overlay)
 endif
 endif
-ifeq (hurd,$(DEB_BUILD_ARCH_OS))
+ifeq (hurd,$(DEB_HOST_ARCH_OS))
 EXCL_MIB_MODULES += mibII
 else
 MIB_MODULES += host
 endif
 
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+export PERL5LIB=/usr/lib/$(DEB_HOST_MULTIARCH)/perl/cross-config-$(shell perl 
-MConfig -e 'print $$Config{version}')
+endif
+
 %:
dh $@
 

Bug#1025000: python-qtawesome: Includes non-source Font Awesome 5

[Julian Gilbey]

forwarded https://github.com/spyder-ide/qtawesome/issues/220
thanks

On Fri, Dec 09, 2022 at 10:15:58AM +0100, Bastian Germann wrote:
> Am 09.12.22 um 07:49 schrieb Andrius Merkys:
> > I saw you have excluded the files in unreleased 1.2.1+dfsg-1 version of
> > the package. Are you planning to upload it soon, or are there any
> > blockers?
> 
> It has not built yet because the example.py is run via d/rules:
> https://salsa.debian.org/python-team/packages/python-qtawesome/-/jobs/3625869
> 
> Either we patch it or do not run it. I tried not running it but end up with a 
> stack trace in that case.
> I will investigate on the weekend.

I've found out from the Spyder developers that Spyder doesn't use
FontAwesome, so it's not a problem to remove it from my perspective.
See the GitHub issue noted above.

I'm also now looking into the Material Design Icon fonts; see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973617
I also now don't understand why there are two different MDI fonts in
this package.  But that's a separate issue.

Best wishes,

   Julian

Bug#1024427: reproducible segfault in bullseye mutt

[Salvatore Bonaccorso]

Hi Antonio,

On Sun, Dec 11, 2022 at 09:59:18PM +0100, Antonio Radici wrote:
> On Thu, Dec 01, 2022 at 10:05:14PM +0100, Salvatore Bonaccorso wrote:
> > Hi Antonio,
> > 
> > On Wed, Nov 30, 2022 at 09:38:39AM -0800, Kevin J. McCarthy wrote:
> > > Note this was fixed in Mutt 2.2.8.  See
> > > https://gitlab.com/muttmua/mutt/-/issues/428 for the Mutt bug report.
> > > 
> > > This important fix is at: 
> > > https://gitlab.com/muttmua/mutt/-/commit/48b6ea32e21db8b580cd3ca8c346c3e2c22756f6.patch
> > > 
> > > There are two related commits, that may be of interest in backporting too,
> > > but aren't the cause of this segfault:
> > > https://gitlab.com/muttmua/mutt/-/commit/f0eb3586480c301b66657c7326b6546ef086c7f4.patch
> > > https://gitlab.com/muttmua/mutt/-/commit/b254f2fb44f994c48e2491adaf03d97d3c628283.patch
> > 
> > There is an upcoming point release for bullseye on 17th of december,
> > can you pick those fixes for a stable update?
> > 
> > Thanks for your work on mutt!
> 
> Yes, I will have an updated package tomorrow evening (Mon Dec 12th)

note that the time did pass this weekend for having fixes included in
the next bullseye-point release. I went ahead earlier with #1025716
which got accepted the stable release managers.

Hope this NMU was fine with you to get the fixes in time into the next
bullseye point release.

Regards,
Salvatore

Bug#1024427: reproducible segfault in bullseye mutt

[Antonio Radici]

On Thu, Dec 01, 2022 at 10:05:14PM +0100, Salvatore Bonaccorso wrote:
> Hi Antonio,
> 
> On Wed, Nov 30, 2022 at 09:38:39AM -0800, Kevin J. McCarthy wrote:
> > Note this was fixed in Mutt 2.2.8.  See
> > https://gitlab.com/muttmua/mutt/-/issues/428 for the Mutt bug report.
> > 
> > This important fix is at: 
> > https://gitlab.com/muttmua/mutt/-/commit/48b6ea32e21db8b580cd3ca8c346c3e2c22756f6.patch
> > 
> > There are two related commits, that may be of interest in backporting too,
> > but aren't the cause of this segfault:
> > https://gitlab.com/muttmua/mutt/-/commit/f0eb3586480c301b66657c7326b6546ef086c7f4.patch
> > https://gitlab.com/muttmua/mutt/-/commit/b254f2fb44f994c48e2491adaf03d97d3c628283.patch
> 
> There is an upcoming point release for bullseye on 17th of december,
> can you pick those fixes for a stable update?
> 
> Thanks for your work on mutt!

Yes, I will have an updated package tomorrow evening (Mon Dec 12th)

Bug#1025921: usbguard-notifier: process 'data/usr/bin/usbguard-notifier' started with executable stack

[Christoph Anton Mitterer]

Package: usbguard-notifier
Version: 0.0.6-1+b1
Severity: normal


Hey.

I see this in the kernel logs when usbguard-notifier starts:
Dec 11 21:47:20 heisenberg kernel: process 'data/usr/bin/usbguard-notifier' 
started with executable stack


Could this be something with the build?


Cheers,
Chris.


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages usbguard-notifier depends on:
ii  init-system-helpers  1.64
ii  libc62.36-6
ii  libgcc-s112.2.0-9.1
ii  libglib2.0-0 2.74.2-1
ii  libnotify4   0.8.1-1
ii  librsvg2-2   2.54.5+dfsg-1
ii  libstdc++6   12.2.0-9.1
ii  libusbguard1 1.1.2+ds-3+b1

usbguard-notifier recommends no packages.

usbguard-notifier suggests no packages.

-- no debconf information

Bug#1025920: RM: simka [i386 s390x] -- ROM; Depends from package with restricted number of architectures

[Andreas Tille]

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

Hi,

since gatb-core should be restricted in the number of architectures
this package also needs to drop the architectures mentioned in
subject.

Kind regards and thanks for your work as ftpmaster
   Andreas.

Bug#1008136: lxcfs takes 2 or 3 CPU cores constantly

[Mathias Gibbens]

Hello Matthew,

  This may be best addressed to the upstream lxcfs project on github,
as Debian's packaging is pretty simple and doesn't modify the behavior
of lxcfs.

  I don't utilize containers at the scale that you do, so I haven't
been able to directly reproduce this. Have you tried the current
release of lxcfs (5.0.2)? I do host an unofficial backport of lxcfs for
bullseye in my personal repo [1] if you'd like to give it a try.

Mathias

[1] -- https://apt.calenhad.com/


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

Bug#1025919: RM: minia [i386 s390x] -- ROM; Depends from package with restricted number of architectures

[Andreas Tille]

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

Hi,

since gatb-core should be restricted in the number of architectures
this package also needs to drop the architectures mentioned in
subject.

Kind regards and thanks for your work as ftpmaster
   Andreas.

Bug#1025918: RM: minia [i386 s390x] -- ROM; Depends from package with restricted number of architectures

[Andreas Tille]

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

Hi,

since gatb-core should be restricted in the number of architectures
this package also needs to drop the architectures mentioned in
subject.

Kind regards and thanks for your work as ftpmaster
   Andreas.

Bug#974012: dgit: no rpush-source option

[Ian Jackson]

Wookey writes:
> locally push and push-source are provided, but when signing remotely
> there is only rpush: no rpush-source.

Indeed.

> It is possible to work-around this, but there seems to be no good
> reason to have this functionality missing when signing remotely, so it
> would be much appreciated if you could add it.

I have now implemented this and I will be uploading it shortly.

I have done this the same way `dgit push` has changed in dgit 10:
`dgit rpush`, like `dgit push`, is a configurable alias.  There are
`dgit rpush-built` and `dgit rpush-source` by analogy with `dgit
push-built` and `dgit push-source`.

If the new warning from `dgit rpush` is too annoying, it can be
overridden with a git global config option.

I hope to be uploading shortly.  You will be able to install the sid
buildd's dgit 10.x .deb directly on earlier releases - my policy is to
try make the new binaries installable on old releases.

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#1025917: rust-phf: please upgrade to v0.11

[Jonas Smedegaard]

Source: rust-phf
Version: 0.10.1-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to newer upstream branch v0.11.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmOWPS8ACgkQLHwxRsGg
ASGvZg/+I2AO0Cz/REEKAqequBiqNBZslz9MRlNtxtbP0GiMBaxfsYXJ2g7+RuXc
WJB60DI2DJPIKSUmnUO9QD5ne9Gj4bIARJv1zhzt3pKvy38Tni7kpX+1DB3GR5Rs
QipTGAcvmicPkxlwvaEuuFe6/x+YFmQPrmBK/EQWpke1qHm5NeQitM3ISOn4cGgQ
iZ7dV6tEL3eq79FWMSVBjaI1D5MLCbZEt1IEaMuaTQxmpqAMaMm8EKTtAK/zMcMi
H2BPywtRBZ5D65rMvuDkjoz5YjTksKmRe1a/c0V8P1Ufvpi6vWPeqTDkrbKajXuE
E74ag8RQeXlB8Ey4P7WUU4P/uTp2FwQYTzHQllRxagkQ5vv3+iCms/WiRYw9zY8i
i4OKcERSwClDwL8gP8iEAnQ6w6r83/51a3Wn6UVsufqAA0dRYW53IGEKVID48+bi
Uaia1yH4IDvKMcCevBiQ8mx9dzG9aR+tgFtK/8fsp7dIpMhwLCtF+zS04zRfUbQL
Y+HZlN0j0z8dIPvGbLblWbdNyuWYtmtw4G4gdRfFBZpPUhnrVkeC+SWO+JWIoFEh
V/5SFlKZS+3jCImMC+KXvDl+/ANtmbNrvX71PBu0bS3A9yrm42Rj15QJD7pjcu2c
Y8c5N1nlFtIjvZfDNGovMCeA1bZVdr7MeyAIyWYMSmGgy/+AxFI=
=Lj5d
-END PGP SIGNATURE-

Bug#1018964: ceph: sources(multiple js dependencies) are missing for ceph dashboard

[Shengjing Zhu]

On Sat, Sep 3, 2022 at 1:59 AM Shengjing Zhu  wrote:
>
> Source: ceph
> Version: 16.2.10+ds-2
> Severity: serious
>

I'm surprised to see my bug is downgraded to wishlist without any comment.

zigo, please explain why you think this is appreciated.

--
Shengjing Zhu

Bug#1025916: RM: mindthegap [i386 s390x] -- ROM; Depends from package with restricted number of architectures

[Andreas Tille]

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

Hi,

since gatb-core should be restricted in the number of architectures
this package also needs to drop the architectures mentioned in
subject.

Kind regards and thanks for your work as ftpmaster
   Andreas.

Bug#1025915: skill: -p $pid seems broken

[Chris Hofstaedtler]

Package: procps
Version: 2:4.0.2-2

Dear Maintainer,

skill's -p flag seems to have stopped working as a selector.

In version 2:3.3.17-5, this did what I expected:

% echo $$
3004161
% skill -n -p $$
3004161

In 2:4.0.2-2 in unstable:

% echo $$
50078
% skill -n -p $$
[list of ALL pids, including 50078]

Looks like -p pid has become a "match any" selector. That seems
unlikely to be the intended effect.

I believe in 2:3.3.17-7.1 this also still worked fine.

Thank you for maintaining procps.

Best,
Chris

Bug#1025914: RM: discosnp [i386 s390x] -- ROM; Depends from package with restricted number of architectures

[Andreas Tille]

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


Hi,

since gatb-core should be restricted in the number of architectures
this package also needs to drop the architectures mentioned in
subject.

Kind regards and thanks for your work as ftpmaster
   Andreas.

Bug#1025913: RM: bcalm [i386 s390x] -- ROM; Depends from package with restricted number of architectures

[Andreas Tille]

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

Hi,

since gatb-core should be restricted in the number of architectures
this package also needs to drop the architectures mentioned in
subject.

Kind regards and thanks for your work as ftpmaster
   Andreas.

Bug#1025912: rust-serde-yaml: please upgrade to v0.9

[Jonas Smedegaard]

Source: rust-serde-yaml
Version: 0.8.26-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to newer upstream branch v0.9.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmOWOYoACgkQLHwxRsGg
ASEvfg/+M7DkSAGfRr4fAay4uE9NTtP7HLSTTxuo0UQqdXOYMtO5u7TpfZlA0qSL
VKK3DSa4ccv8gE6IvnOIVcXKtwugu1g4T0D5HmPi/ooRbJrzz3hMbV46RU1HtI2U
6cElxPvsrjxDFdnSMk2uOH3cyKhUez2OUQzNQ2GPTES7gVMPpaTu4oNCPVjH3SgA
ePyNLG0utdN6cHFbJrEkg64pcUVpW6qwdnASUDjFo8cQP8CIVOxWLkQKYHVfyWGc
Tct30BU40bF1FxE/6vBXdVKbw2k8PnxudSOuJ8CppvmVsoFVmKIFB4Lfb/Dya7QO
Pc1ibF7BY4yFS4lpQt2SJD4aXuy813RMmn0Hpj+T9J3znTVYhO5KP2qZ7veLxdEV
lexCFZRNrxs9O4Q9ROZaNUJzO/c+/GfPxpej9IrOrCSqsn+OtCvfYRkkw1iTZwjC
fJcpz0aXqquwH74l9KMMVGb06PVDkgMEiO/z0Mh447Zy5s3BPHMIN97V40cblDlQ
XQGRI9Jjfrv8o/oJjWEeWndkwfx9kdVW2NWSg9qtfmoJ01gIgMxTR2EjOCi7zzVA
e3CSv1RkEJsqcnS7MGACG3vIT0LTiZtYHG0CyAsi58AWuOfNjr072VL1pt9MNv/l
/Q3VbWzoo4WZRAPpcUTahNRo/fOJLx7I0SIX8UrPNY9ZD0vIEFM=
=uBcL
-END PGP SIGNATURE-

Bug#1025714: octave-vrml: FTBFS randomly in sid (dpkg-gencontrol failure)

[Rafael Laboissière]

* Niels Thykier  [2022-12-09 16:45]:


Rafael Laboissière:


[snip]

The issue is caused by a bug in the dh_octave_substvar script, from 
the dh-octave package. I am looking at it. More to come soon.


Best,

Rafael Laboissière


I had hoped that debhelper's addsubstvar would catch an unescaped 
newline in the input bug already in the addsubstvar's call if it was 
done via `Dh_Lib`.  If you find that is not the case, please do file a 
bug against debhelper for that bit.


Your wording above is a bit harder to parse. Are you suggesting that 
addsubstvar should be tolerant to arguments (at least deppackage) with 
trailing newlines, or even trailing whitespace, more generally?


Best,

Rafael Laboissière

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

[Michael Biebl]

Am 11.12.22 um 20:51 schrieb 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.


The systemctl man page says that
   --boot-loader-entry=ID
"...Note that not all boot loaders support this functionality."

I'm not sure if grub supports this functionality or if you need 
systemd-boot. That said, if you claim that 252.1-1 was working with 
grub, it is possible, that there is a regression somewhere



(v252-stable)$ git log v252.1..v252.3 --oneline | grep boot
1c9e7fc8f2 boot: Only do full driver initialization in VMs
79b97ec652 boot: improve support for qemu (helpers only)
87add68b39 boot: Make sure all partitions drivers are connected
989f0c52e1 boot: Use EFI_BOOT_MANAGER_POLICY_PROTOCOL to connect console devices
b0b97848e8 bootspec: fix null-dereference-read
b39f2ab98f boot: Use xstr8_to_16 for path conversion
6387a74d2c boot: Use xstr8_to_16
ff7469af96 boot: Add xstrn8_to_16
2ddd7b5def bootctl: rework how we handle referenced but absent EFI boot entries
2daecc7179 bootctl: downgrade log message when firmware reports non-existent or 
invalid boot entry
9a7186e92a bootctl: make boot entry id logged in hex
c1dd021d16 boot: Silence driver reconnect errors
9b6f12262f udev: make sure auto-root logic also works in UKIs booted from 
XBOOTLDR
5c34bc9bc3 boot/measure: fix oom check
6189505d79 boot: Correctly handle @saved default patterns
aff1caf3fd boot: Replace firmware security hooks directly
f9d9a68ecc boot: Rework security arch override
c6d7b4014c boot: Manually convert filepaths if needed
c8c5b79fb6 boot: Do not require a loaded image path
5894d4bd79 boot: Fix memory leak
5c0b918c02 boot: Fix error message


As you see, there are some boot related changes between .1 and .3

Your best bet is probably to file this issue upstream at
https://github.com/systemd/systemd/issues/new


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025910: libcommons-net-java: CVE-2021-37533

[Salvatore Bonaccorso]

Source: libcommons-net-java
Version: 3.6-1
Severity: important
Tags: security upstream
Forwarded: https://issues.apache.org/jira/browse/NET-711
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libcommons-net-java.

CVE-2021-37533[0]:
| Prior to Apache Commons Net 3.9.0, Net's FTP client trusts the host
| from PASV response by default. A malicious server can redirect the
| Commons Net code to use a different host, but the user has to connect
| to the malicious server in the first place. This may lead to leakage
| of information about services running on the private network of the
| client. The default in version 3.9.0 is now false to ignore such
| hosts, as cURL does. See
| https://issues.apache.org/jira/browse/NET-711.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-37533
https://www.cve.org/CVERecord?id=CVE-2021-37533
[1] https://issues.apache.org/jira/browse/NET-711

Regards,
Salvatore

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

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=mipsel=1.1.5%2Bdfsg-3=1670783276=0
 

-- 
http://fam-tille.de

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#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#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#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#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#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#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#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#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#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#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#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#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#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#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
+++ 

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=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#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#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#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#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

[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#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#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#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#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#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#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#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#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#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=armhf=0.02-2=1658361396=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#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#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#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#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#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#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#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#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#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#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#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#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 
$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 
$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=amd64=3.31.1.3-1=1659884648=0

gcc -DHAVE_CONFIG_H -I. -I..  -I 

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#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: 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#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