Bug#1035914: cron(8) says system administrator should not use /etc/cron.d/

[Daniel Lewart]

Package: cron
Version: 3.0pl1-137
Severity: minor

Georges,

cron(8) says:
In general, the system administrator should not use /etc/cron.d/,
but use the standard system crontab /etc/crontab.

I don't understand the reasoning behind this, except perhaps to
avoid a collision with a future package named "local".

If cron(8) was changed to:
The system administrator may create cron jobs in /etc/cron.d/
with file names like "local" or "local-foo".
then package changes to /etc/crontab would not require user interaction
during upgrades.

Thank you!
Daniel Lewart
Urbana, Illinois

Bug#1035913: doc-debian 11.0 changed /usr/share/doc-base/ paths

[Johannes Schauer Marin Rodrigues]

Package: doc-debian
Version: 11.0
Severity: normal

Hi,

On Mon, 8 May 2023 07:46:09 +0200 Joost van =?utf-8?Q?Baal-Ili=C4=87?= 
 wrote:
> [ Risks ] None.  The doc-debian package is a key package due to Priority:
> standard.  It acts as a leaf package: Its only true reverse depends is the
> live-task-standard package.[reverse-depends]

you are forgetting packages using doc-debian in their autopkgtests.

> [ Other info ] I made a mistake uploading doc-debian 11.0 to unstable; that
> got accepted.  The version 11.1 is now available from
> http://mdcc.cx/tmp/doc-debian/ .  I've incorporated some small cosmetic
> changes next to the much needed document updates.  Attached is a 161 kB
> doc-debian_6.5-11.1.dsc-debdiff , as well as a summarizing 13kB
> doc-debian_6.5-11.1.dsc-debdiff-tldr .

Before your upload of 11.0, doc-debian contained:

/usr/share/doc-base/debian-constitution-text
/usr/share/doc-base/debian-mailing-lists
/usr/share/doc-base/debian-manifesto
/usr/share/doc-base/debian-reporting-bugs
/usr/share/doc-base/debian-social-contract

Then with 11.0 this became:

/usr/share/doc-base/doc-debian.debian-constitution-text
/usr/share/doc-base/doc-debian.debian-mailing-lists
/usr/share/doc-base/doc-debian.debian-manifesto
/usr/share/doc-base/doc-debian.debian-reporting-bugs
/usr/share/doc-base/doc-debian.debian-social-contract

This broke the autopkgtest of mmdebstrap which you can also see on the excuses
page for doc-debian: https://qa.debian.org/excuses.php?package=doc-debian

Since I noticed this breakage, I uploaded a new version of mmdebstrap that
works around this problem, assuming that this change was intentional. In
hindsight, I probably should've contacted you instead because when
investigating http://mdcc.cx/tmp/doc-debian/doc-debian_11.1_all.deb and
comparing it to the version from unstable I see:

diff -u <(curl --silent 
http://ftp.de.debian.org/debian/pool/main/d/doc-debian/doc-debian_11.0_all.deb 
| dpkg-deb -c - | awk '{print $6}' | sort) <(curl --silent 
http://mdcc.cx/tmp/doc-debian/doc-debian_11.1_all.deb | dpkg-deb -c - | awk 
'{print $6}' | sort)
--- /dev/fd/63  2023-05-11 08:18:34.782823397 +0200
+++ /dev/fd/62  2023-05-11 08:18:34.782823397 +0200
@@ -3,11 +3,11 @@
 ./usr/share/
 ./usr/share/doc/
 ./usr/share/doc-base/
-./usr/share/doc-base/doc-debian.debian-constitution-text
-./usr/share/doc-base/doc-debian.debian-mailing-lists
-./usr/share/doc-base/doc-debian.debian-manifesto
-./usr/share/doc-base/doc-debian.debian-reporting-bugs
-./usr/share/doc-base/doc-debian.debian-social-contract
+./usr/share/doc-base/debian-constitution-text
+./usr/share/doc-base/debian-mailing-lists
+./usr/share/doc-base/debian-manifesto
+./usr/share/doc-base/debian-reporting-bugs
+./usr/share/doc-base/debian-social-contract
 ./usr/share/doc/debian/
 ./usr/share/doc/debian/bug-log-access.txt
 ./usr/share/doc/debian/bug-log-mailserver.txt.gz

What are the intended paths. Should I revert my changes to mmdebstrap or not?

Also, these changes of paths in /usr/share/doc-base/ forth and back are not
recorded in debian/changelog. If the change was intended, please document it.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1035895: Please add ast_dri.so

[Timo Aaltonen]

Al Ma kirjoitti 10.5.2023 klo 23.11:

Package: libgl1-mesa-dri

Version: 20.3.5-1



My journal log shows, among other weird stuff, the following error message:

Mai 10 21:01:20 AnonymizedComputerName gnome-shell[1026]: Running GNOME 
Shell (using mutter 42.3) as a Wayland display server


Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Device 
'/dev/dri/card0' prefers shadow buffer


Mai 10 21:01:21 AnonymizedComputerName goa-daemon[1048]: goa-daemon 
version 3.38.0 starting


Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Added device 
'/dev/dri/card0' (ast) using atomic mode setting.


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session 
uid=119 pid=962] Activating service name='org.gnome.Identity' requested 
by ':1.15' (uid=119 pid=1048 comm="/usr/libexec/goa-daemon ")


Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Device 
'/dev/dri/card1' prefers shadow buffer


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session 
uid=119 pid=962] Successfully activated service 'org.gnome.OnlineAccounts'


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session 
uid=119 pid=962] Successfully activated service 'org.gnome.Identity'


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session 
uid=119 pid=962] Successfully activated service 
'org.gtk.vfs.GoaVolumeMonitor'


Mai 10 21:01:21 AnonymizedComputerName systemd[920]: Started Virtual 
filesystem service - GNOME Online Accounts monitor.


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session 
uid=119 pid=962] Activating via systemd: service 
name='org.gtk.vfs.GPhoto2VolumeMonitor' 
unit='gvfs-gphoto2-volume-monitor.service' requested by ':1.3' (uid=119 
pid=955 comm="/usr/libexec/tracker-miner-fs ")


Mai 10 21:01:21 AnonymizedComputerName systemd[920]: Starting Virtual 
filesystem service - digital camera monitor...


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session 
uid=119 pid=962] Successfully activated service 
'org.gtk.vfs.GPhoto2VolumeMonitor'


Mai 10 21:01:21 AnonymizedComputerName systemd[920]: Started Virtual 
filesystem service - digital camera monitor.


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[778]: [system] 
Activating via systemd: service name='org.freedesktop.UPower' 
unit='upower.service' requested by ':1.37' (uid=119 pid=955 
comm="/usr/libexec/tracker-miner-fs ")


Mai 10 21:01:21 AnonymizedComputerName systemd[1]: Starting Daemon for 
power management...


Mai 10 21:01:21 AnonymizedComputerName systemd[1]: Started Console Mouse 
manager.


Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Added device 
'/dev/dri/card1' (nouveau) using non-atomic mode setting.


Mai 10 21:01:21 AnonymizedComputerName org.gnome.Shell.desktop[1026]: 
pci id for fd 9: 1a03:2000, driver (null)


Mai 10 21:01:21 AnonymizedComputerName org.gnome.Shell.desktop[1026]: 
MESA-LOADER: failed to open ast: /usr/lib/dri/ast_dri.so: Kann die 
Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden 
(search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)


Mai 10 21:01:21 AnonymizedComputerName org.gnome.Shell.desktop[1026]: 
failed to load driver: ast




So MESA-LOADER complains that /usr/lib/dri/ast_dri.so is not found.  
This is correct because on my machine, /usr/lib/dri doesn't exist and 
ast_dri.so doesn't exist elsewhere. Does my Aspeed chip have no driver?  
Should I ever need it a VGA output, don't I get it?  My request is to 
deal with this error message, ideally, by introducing ast_dri.so into to 
Debian (or making MESA-LOADER work without it).


There is no such driver.

--
t

Bug#1035802: RM: repsnapper -- RoQA; gtkglextmm dependency

[PaulLiu]

Hi Bastian,

I tried to build this package without gtkglextmm  but it failed. Looking
into the code, it really uses gtkglextmm. For example, it uses Gtk::GL and
Gdk::GL.
Why should this package be removed? Any replacement for using GL with GTK
by a C++ wrapper or C++-style?
I know I might rewrite all of this by gdk_gl_* and gtk_gl_* but it is C not
C++.
If there's no replacement then RM repsnapper might be the only option.

Yours,
Paul


On Tue, May 9, 2023 at 7:30 PM Bastian Germann  wrote:

> Source: repsnapper
> Control: block 967492 by -1
>
> Please consider filing a remove bug for repsnapper.
> It is one of the two last dependencies of gtkglextmm, which should be
> removed. Maybe you can even build without it.
>

Bug#1035912: debci-worker cron job fails unless lxc is installed

[Helmut Grohne]

Package: debci-worker
Version: 3.6
Severity: minor

Hi Paul and Antonio,

I am reporting a minor oddity here. If you install debci-worker without
installing recommends (and thus miss lxc), the debci-worker cronjob will
still try to run debci setup with the lxc backend by default and fail.
This incurs a daily cron mail. This feels slightly odd.

Related to that, it tries to create a testbed for unstable amd64 using
lxc by default (same thing actually) during postinst. It would be nice
to be able to opt out of this behaviour (e.g. when you are not targeting
unstable). I note that kali's setup has code that specifically gets rid
of this unstable testbed and it seems like it would be nicer to just not
create it.

If you have ideas for how this should work, I can turn them into
patches. If you feel like this works as intended and I should just
delete that testbed and cronjob, then close this bug instead.

Helmut

Bug#1035839: closed by Debian FTP Masters (reply to Rafael Laboissière ) (Bug#1035839: fixed in jed 1:0.99.20~pre.178+dfsg-4)

[Rafael Laboissière]

Great, thanks for your help!

* Axel Beckert  [2023-05-10 13:20]:


Hi Rafael,

Debian Bug Tracking System wrote:

 jed (1:0.99.20~pre.178+dfsg-4) unstable; urgency=medium
 .
   * d/jed-common.preinst: Avoid non-fatal abortion of the script.
 Thanks to Axel Beckert for the fix (Closes: #1035839)


Thanks! Just wanted to confirm that I could now upgrade jed and 
jed-common without issues from 1:0.99.20~pre.178+dfsg-1 to 
1:0.99.20~pre.178+dfsg-4.


Regards, Axel

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

Bug#1035857: texlive-fonts-extra: broken font symlinks for junicode

[Norbert Preining]

> If you say the broken symlinks are not really a problem for bookworm (and

Broken symlinks in the TEXMF dirs are not a problem, since kpathsea will
ignore them.

So the worst thing is that some font is not available, that is hardly a
problem since the fonts are not generally used.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Mercari Inc. + IFMGA Guide + TU Wien + TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#1034424: buildd.debian.org: Please use predictible build paths

[Johannes Schauer Marin Rodrigues]

Quoting Vagrant Cascadian (2023-04-18 00:33:58)
> > Do you have other short suggestions? Do we want to show it has been built
> > on a debian buildd? In that case /build/debian-buildd might do it.
> 
> Well, then a verification build using reproducible builds will be
> "lying" that it is built on a buildd. :)

I don't think it would be lying. It would be saying: "I'm trying to verify
something that was built on a buildd by reproducing its environment."

> Or just go with "reproducible-path" as it is not tragically long if it seems
> unlikely to match inappropriately. :)
> 
> Is sbuild replacing the string mandatory; could we do without that feature?
> What would we loose? Might require patching sbuild...

It is not madatory. Log filtering can be switched off via the LOG_FILTER
configuration option.

I think the main purpose for the log filtering is to make log files easily
grep-able despite the build path having random components.

But if that is the only reason, then with a fixed build path log filtering is
not required anymore, as anybody interested could just grep for
/build/0ad-0.0.26-3_i386 and be done.

Dropping log filtering would also make build logs not "lie" anymore and output
stuff like:

make[1]: Leaving directory '/<>'

But instead output the truth:

make[1]: Leaving directory '/build/0ad-0.0.26-3_i386'

So maybe fixed build paths combined with disabled log filtering can actually
improve the readability of log files?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1035840: nfs-utils: nfs-idmapd startup race condition due to missing systemd dependency

[Salvatore Bonaccorso]

HI Aram,

On Wed, May 10, 2023 at 04:39:34PM -0700, Aram Akhavan wrote:
> Yes. The issue still exists with nfs-common 2.6.2 (and the new libnfsidmap1
> dependency). Not surprising since systemd unit in question is the same. The
> fix for nfs-idmapd.service is a trivial two-line addition:
> 
> Wants=network-online.target
> After=network-online.target
> 
> I recall a comment somewhere mentioning that other distros already implement
> this fix. I can dig up which particular one, if it's helpful.
> 
> Please let me know how to proceed!

We have diverged already too much in past with nfs-utils from
upstream, leading to Debian having for a very long time ancient
nfs-utils versions. So the way to go here is to make sure the fix is
integrated upstream in the service files. Then we can pick up the fix
in anvance and drop it again once we rebase the version.

Does this helps?

Regards,
Salvatore

Bug#1034424: buildd.debian.org: Please use predictible build paths

[Vagrant Cascadian]

On 2023-04-17, Vagrant Cascadian wrote:
> On 2023-04-17, Aurelien Jarno wrote:
>> On 2023-04-16 15:16, Vagrant Cascadian wrote:
>>> On 2023-04-16, Aurelien Jarno wrote:
>>> > I have tried adding a simple .sbuildrc defining $build_path to '/build'
>>> > to zandonai.d.o. Unfortunately while it more or less does what you want
>>> > for the build path, it completely clutter the logs, as any text matching
>>> > "build" is now replaced by "<>":
>>> >
>>> > https://buildd.debian.org/status/fetch.php?pkg=gnome-keyring&arch=s390x&ver=42.1-1%2Bb2&stamp=1681671508&raw=0
>>> 
>>> >
>>> > I guess one option is to use a build path unlikely to match any string
>>> > from a build log, like with the randomized directory. Something like
>>> > "/build/reproducible-path/"?
>>> 
>>> Just for clarity, then the the PKGBUILDIR would end up being
>>> /build/reproducible-path/PACKAGE-VERSION ? That works! Or something even
>>> shorter ... e.g. /build/path/PACKAGE-VERSION or
>>> /build/debian/PACKAGE-VERSION ? Really, the 2nd directory matters
>>> little, as long as it is predictible. :)
>>
>> Yes, setting $build_path to '/build/debian' indeed means that
>> PKGBUILDDIR is /build/debian/PACKAGE-VERSION.
>>
>> Unfortunately the string 'build/debian' appears in a few build logs:
>> 0ad
> ...
>> xtables-addons
>>
>> Do you have other short suggestions? Do we want to show it has been
>> built on a debian buildd? In that case /build/debian-buildd might do it.
>
> Well, then a verification build using reproducible builds will be
> "lying" that it is built on a buildd. :)
>
> Hrm. "DeBiAn" ? Kind of hard on the eyes. Less ugly, "/build/Debian"?
> Still somewhat likely to to have inappropriate matches? "fixedpath"?

To keep the conversation alive ... here is a somewhat opaque one:

  /build/816a1be80d5f70ba783aadc45020dd41/

...but an explainable one: the md5sum of "debian-reproducible"

Or "reproducible-builds" as:

  /build/eb1c522c4243d55a168f5c37d9f238ff/

...in other words (or picking just about any other words), a hash of
something not terribly likely to appear in a build log ... :)

A shorter hash might be perfectly reasonable too ... it just has to be
unlikely to appear in a build log?

Obviously, a hash is non-obvious to the reader what the heck this magic
hash is... but that is what documentation is for?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1031410: Closing p-u requests for fixes included in 11.7

[Sebastiaan Couwenberg]

> Should I file another bug report for this?

Yes.

On unstable:

gis=# SELECT 
ST_AsGeoJSON(ST_Transform(ST_SetSRID('010120110F04F0844A1349264120ED527FE9DD5841'::geometry, 
3857), 31466));
 st_asgeojson 


---

{"type":"Point","crs":{"type":"name","properties":{"name":"EPSG:31466"}},"coordinates":[2539841.861857439,5586869.519378289]}
(1 row)

On bullseye:

bagv2=# SELECT 
ST_AsGeoJSON(ST_Transform(ST_SetSRID('010120110F04F0844A1349264120ED527FE9DD5841'::geometry, 
3857), 31466));

 st_asgeojson
---

{"type":"Point","crs":{"type":"name","properties":{"name":"EPSG:31466"}},"coordinates":[5586869.519378289,2539841.861857439]}
(1 row)

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1035805: node-source-map: copyright file missing after upgrade (policy 12.5)

[Yadd]

On 5/10/23 20:25, Andreas Beckmann wrote:

Control: tag -1 - moreinfo

On 10/05/2023 17.54, Yadd wrote:
node-source-map depends on libjs-source-map, so the link isn't broken 
in normal installation.


After a fresh installation in bookworm, the link is
   /usr/share/doc/node-source-map -> libjs-source-map
and everything is fine, but after an upgrade from bullseye the link is
   /usr/share/doc/node-source-map -> ../libjs-source-map
which does not work.

node-source-map.maintscript has the corresponding error:

dir_to_symlink /usr/share/doc/node-source-map ../libjs-source-map 
0.7.0++dfsg2+really.0.6.1-9~


Simply reinstalling the package fixes the link (the package
already ships the correct link and dpkg-maintscript-helper does
not touch it again in this case.
So there is no need for a manual cleanup of this mess.

All that needs to be done is an upload with the fixed path
(removing '../') in node-source-map.maintscript.


Done thanks !

Bug#1035906: closed by Sandro Tosi (Re: Bug#1035906: reportbug fails to load a couple of Gtk modules)

[Sandro Tosi]

go to https://www.debian.org/support . end of story.


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

Bug#1035911: [pre-approval] unblock: dpkg/1.21.22

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: d...@packages.debian.org
Control: affects -1 + src:dpkg

Hi!

Please pre-approve the dpkg 1.21.22 upload.

[ Reason ]

I got a report for a segfault privately (as the reporter was unsure
whether this constituted a security issue, which IMO it does not),
which is rather easy to trigger for packages that are known to dpkg,
but are not installed, such as virtual packages or references from
Recommends or Suggests.

I've also cherry picked a translation addition that was already in git
HEAD (targeting 1.22.x).

[ Impact ]

An easy to trigger segfault, which also affects dpkg 1.20.x (for which
I'll be preparing a stable release request).

[ Tests ]

The test suite has been updated to cover this case. And it's also easy
to reproduce with dpkg-query, for example on a minimal chroot, with:

  $ dpkg-query -f '${source:Upstream-Version}\n' -W firefox-esr
  Segmentation fault (core dumped)

[ Risks ]

The fix is trivial, so the risk seems low to me.

[ Checklist ]

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

[ Other info ]

(I had in mind also including an addition for the riscv32 port, but
given that there's no consensus among the porters about its ABI or
even its mere existence, and time is running out, I'll postpone that,
and might include it instead in a future stable release if necessary.)

Attached the unfiltered debdiff, you might want to filterdiff with:

  xzcat dpkg-1.21.21-1.21.22.debdiff.xz |
filterdiff --exclude '*.po' --exclude '*.pot' \
   --exclude '*/man/*/*.pod' \
   --exclude '*/testsuite' --exclude '*/at/*.m4' \
   --exclude '*/configure'

unblock dpkg/1.21.22

Thanks,
Guillem


dpkg-1.21.21-1.21.22.debdiff.xz
Description: application/xz

Bug#1035906: closed by Sandro Tosi (Re: Bug#1035906: reportbug fails to load a couple of Gtk modules)

[Christopher Witkowski]

No. Just no.

I am not the writer of reportbug, I am just trying to use it.

The error messages come out of reportbug. I don't know why it even uses
Gtk since it uses a command line interface. Or maybe it's some kind of
dependencies problem with way the package is set up. Regardless, these
don't look like error messages I should be seeing coming out reportbug
so I reported them. At my end it's a reportbug problem, the internals
are for you to sort out at your end. If it turns out to actually be a
Gtk problem then you reassign the problem. But closing it and saying
"this is not the right venue" is a totally inappropriate response.

On 2023-05-10 18:51, Debian Bug Tracking System wrote:

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

#1035906: reportbug fails to load a couple of Gtk modules

It has been closed by Sandro Tosi .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Sandro Tosi 
 by
replying to this email.

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Sean Whitton]

Hello,

On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote:

> Dear ctte, please consider overruling the dpkg maintainer to include
> the patch from #994388[1].

Currently dpkg contains code to emit the merged-/usr warning, that's
dead code on Debian, but which becomes active when packages from the
Debian archive are copied unmodified into derivatives.

The heart of the issue is how dpkg is a native package.  What we're
talking about is not the Debian system, but the Debian archive as it
exists independently of the Debian system.

dpkg has an upstream existence that's independent of Debian, and it's
perfectly legitimate for that version of dpkg to emit the warning.  The
problem here might be caused by how the Debian archive is implicitly
being used to distribute upstream dpkg.

This is not in itself a problem -- we distribute a lot of stuff in
source packages that does not form part of the Debian system.  But in
this case, this distribution that's occurring might conflict with how
Debian is seeking to provide a product not just to end users, but also
to those building derivatives.

One simple solution is for dpkg to become a non-native package, carrying
Debian-specific patches to do things like remove the warning code.

Guillem & the other dpkg maintainers: would that change be something you
are willing to consider?  It might forestall this and similar issues
from becoming contentious.  Having dpkg as a non-native package would
reflect the reality, that we can celebrate, that dpkg has an upstream
existence independent of Debian.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Sean Whitton]

Hello,

On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote:

> Cool, then let's ask tech-ctte.
>
> Dear ctte, please consider overruling the dpkg maintainer to include
> the patch from #994388[1].
>
> Thanks,
> Ansgar
>
>   [1]: https://bugs.debian.org/994388#397

This would require a new, maintainer-overruling vote.
Our existing decisions do not apply, so far as I can tell.

I have written a separate message to the bug and to debian-dpkg with a
proposal to avoid having to have such a vote.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1034756: dpkg: please add support for riscv32

[Guillem Jover]

Hi!

On Sun, 2023-04-30 at 10:12:01 +0800, Bo YU wrote:
> If you talk about the baseline ABI according to hardware, yeah, this
> is still open.

> Thanks for more background here. I thought this might lead to a wider
> discussion before solid ABI as pabs' suggestion.

Given the ongoing discussion, where the ABI does not seem clear, and
there is even concerns about the existence of the port at all, I'll
defer this one for now, so that I can submit the current pending
unblock request. Once things are more clear from the RISC-V porters
side, then I'm happy to include this in git HEAD, and even propose
updating dpkg in stable release branches to add it there if necessary.

Thanks,
Guillem

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[Andres Salomon]

On Sat, 11 Mar 2023 11:04:15 + James Addison  
wrote:

> Package: nodejs
> Followup-For: Bug #1030284
> X-Debbugs-Cc: t...@debian.org
>
> Guidance received from the V8 project (a vendored dependency in the 
upstream
> NodeJS codebase) on the v8-dev mailing list is, in 
summary/interpretation:

>
>   * It is not yet safe to increase the stack size limit on ARM64 
systems.

[...]
> Sidenotes:
>
> A patch for 32-bit architectures could apparently be acceptable, 
although may
> be best offered to NodeJS rather than V8.  For what it's worth: 
NodeJS seems
> to have a policy of not accepting patches to their vendored 
dependencies.

>

In reading Jakob's response 
(https://groups.google.com/g/v8-dev/c/7ZI3vxtabcU/m/c9qvHkOBBAAJ), I'm 
interpreting it slightly differently-


He says that raising the stack limit *is* safe for 32-bit ARM, even 
inside of the V8 upstream source tree.


For ARM64, he says that raising the stack limit is not safe for v8 
*embedded inside WebView*, and therefore not appropriate for upstream 
v8. But then he says it could/should be safe for v8 *embedded inside 
NodeJS*.


Based on that, I suggest patching Debian's NodeJS with the patch to 
adjust armhf/arm64 stack limit size to 984kb. With the caveat that the 
javascript code that is triggering this bug should really be fixed to 
not be so stack-intensive, of course. Perhaps this bug cloned at a 
lower severity, filed against those packages that this bug is affecting?


(As chromium maintainer, which also embeds v8, I haven't heard of any 
issues and hadn't planned on touching stacks limits. It sure would be 
nice to have just one copy of V8 in the archive, though..)

Bug#1035910: caja: process gdk-pixbuf-thumbnailer uses excessive, >600MiB, of memory

[Christopher Witkowski]

Package: caja
Version: 1.24.0-1
Severity: normal
X-Debbugs-Cc: cw...@z46860.e4ward.com

Dear Maintainer,

After looking through a few directories gdk-pixbuf-thumbnailer
sucks up a lot of memory. The directories I was looking at are
in the co-existing Windows XP SP3 Home Edition installation.
I don't know which, or which types of files, could be triggering
this behaviour.

This is on a "small" machine, an msi U120 notebook/netbook with
1GB memory hardwired (i.e. can't be increased), so, a process
using this much memory causes everything to bog down. The memory
usage of this process varies over time and getting a screen shot
at the maximum usage was impossible. But, 540MiB is still well
up there. Since reportbug doesn't allow for attachments I've
placed the screen shot at:

   http://chrisw.freeshell.org/caja/Screenshot%20at%202023-05-10%2014-00-27.png

top shows 1GiB of virtual memory for gdk-pixbuf-thumbnailer and
if all that is in actual use, resident or swap, then it is that
much worse.

I turned off thumbnails in caja and rebooted and the process and
problem were gone.

The thumbnails option should be turned off by default and there
should be a warning asscociated with this option until this is
fixed. 


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

Kernel: Linux 5.10.0-22-686-pae (SMP w/2 CPU threads)
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 caja depends on:
ii  caja-common   1.24.0-1
ii  desktop-file-utils0.26-1
ii  gvfs  1.46.2-1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.31-13+deb11u6
ii  libcairo-gobject2 1.16.0-5
ii  libcairo2 1.16.0-5
ii  libcaja-extension11.24.0-1
ii  libexempi82.5.2-1
ii  libexif12 0.6.22-3
ii  libgail-3-0   3.24.24-4+deb11u3
ii  libgdk-pixbuf2.0-02.40.2-2
ii  libglib2.0-0  2.66.8-1
ii  libglib2.0-bin2.66.8-1
ii  libglib2.0-data   2.66.8-1
ii  libgtk-3-03.24.24-4+deb11u3
ii  libice6   2:1.0.10-1
ii  libmate-desktop-2-17  1.24.1-2
ii  libnotify40.7.9-3
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libselinux1   3.1-3
ii  libsm62:1.2.3-1
ii  libx11-6  2:1.7.2-1
ii  libxml2   2.9.10+dfsg-6.7+deb11u4
ii  mate-desktop  1.24.1-2
ii  shared-mime-info  2.0-1

Versions of packages caja recommends:
ii  gvfs-backends  1.46.2-1

Versions of packages caja suggests:
ii  engrampa1.24.1-1
pn  gstreamer1.0-tools  
pn  meld

-- no debconf information

Bug#1035909: nfs-utils: startup race with DNS resolution causes id mapping to (silently) use a bogus domain

[Aram Akhavan]

Package: libnfsidmap1
Version: 1:2.6.2-4
Severity: important
Tags: upstream
X-Debbugs-Cc: deb...@aram.nubmail.ca

Dear Maintainer,

If no default "Domain" is specified in /etc/idmapd.conf, idmapd, via
libnfsidmap will use "the domain part of the DNS domain". From the
excerpt below, libnfsidmap queries the DNS server for the hostname and
uses the part after the first '.' in the h_name ("official name of
host"). (See code snippet #1 below). I'm not sure why exactly this is done,
but my best guess is its to ensure the name used by the DNS server is used,
resolving any aliases, and/or a non-FQDN hostname.

If DNS resolution is not up, however, it quietly falls back to
IDMAPD_DEFAULT_DOMAIN, which is usually "localdomain", breaking id
mapping. This is related to Bug#1035840, in which the nfs-idmapd systemd
service does not by default wait for the network to be up.

Even when that is addressed, though, it seems DNS resolution is not
quite up and the gethostbyname() call fails. In my setup, adding a few
hundred ms delay in the service startup adresses the issue.

There is a message when this happens (see code snippet #2), but with a
log level of 1, it's not shown unless -v is passed. At the very least, I
think this error message needs to be log level 0.

To me, though, this scenario constitutes a failure. I would prefer that the
daemon fail to start rather than fall back to a hardcoded domain.

The second issue is the race against DNS resolution. I'm not sure why
the gethostbyname() call fails even when the interface is up (at least
according to ifup/systemd), but I think a better, or at least a first
fallback approach should be to use the domain part of the hostname, if
it exists. I'm guessing in many cases, mine included, this would
suffice.

These problems exist upstream, and they also exist in the libnfsidmap2
package used by Debian 11.

I sent an email about this to the nfs mailing list with more info about
the race overall as well as the context, but got no responses (see 
https://marc.info/?l=linux-nfs&m=167834665013860&w=2).
I'm hoping someone on the Debian team can point me in the right direction in 
terms of whether this fix is
appropriate and how to submit a patch upstream.

Thanks,

Aram


Code Snippet #1:
support/nfsidmap/libnfsidmap.c

 215 static int domain_from_dns(char **domain)
 216 {
 217 struct hostent *he;
 218 char hname[64], *c;
 219
 220 if (gethostname(hname, sizeof(hname)) == -1)
 221 return -1;
 222 if ((he = gethostbyname(hname)) == NULL)
 223 return -1;
 224 if ((c = strchr(he->h_name, '.')) == NULL || *++c == '\0')
 225 return -1;
 226 /*
 227  * Query DNS to see if the _nfsv4idmapdomain TXT record exists
 228  * If so use it...
 229  */
 230 if (dns_txt_query(c, domain) < 0)
 231 *domain = strdup(c);
 232
 233 return 0;
 234 }

Code Snippet #2:
support/nfsidmap/libnfsidmap.c
 388 ret = domain_from_dns(&default_domain);
 389 if (ret) {
 390 IDMAP_LOG(1, ("libnfsidmap: Unable to determine "
 391   "the NFSv4 domain; Using '%s' as the 
NFSv4 domain "
 392   "which means UIDs will be mapped to the 
'Nobody-User' "
 393   "user defined in %s",
 394   IDMAPD_DEFAULT_DOMAIN, PATH_IDMAPDCONF));
 395 default_domain = IDMAPD_DEFAULT_DOMAIN;
 396 }

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libnfsidmap1 depends on:
ii  libc6  2.36-9
ii  libldap-2.5-0  2.5.13+dfsg-5

libnfsidmap1 recommends no packages.

libnfsidmap1 suggests no packages.

-- no debconf information

Bug#1035840: nfs-utils: nfs-idmapd startup race condition due to missing systemd dependency

[Aram Akhavan]

Yes. The issue still exists with nfs-common 2.6.2 (and the new 
libnfsidmap1 dependency). Not surprising since systemd unit in question 
is the same. The fix for nfs-idmapd.service is a trivial two-line addition:


Wants=network-online.target
After=network-online.target

I recall a comment somewhere mentioning that other distros already 
implement this fix. I can dig up which particular one, if it's helpful.


Please let me know how to proceed!

On 5/10/2023 12:46 AM, Diederik de Haas wrote:

On Wednesday, 10 May 2023 04:29:10 CEST Aram Akhavan wrote:

Package: nfs-common
Version: 1:1.3.4-6

We're currently at version 2.6.2 (or .3 in experimental) and I doubt that
upstream cares about version 1.3.4.
Can you reproduce the issue with version 2.6.2 (or higher)?

Bug#1035908: Bullseye regression: NFS4 referals appear not to work

[Sam Hartman]

package: nfs-utils
severity: important
justification: regression from bullseye with silent failure
version: 1:2.6.2-4

Hi.
I've noticed that since upgrading to  bookworm the refer option in
/etc/exports appears to be entirely ignored.

Looking through the sources to exportd and support/export/cache.c, it
looks like perhaps referals support in exports is keyed on
--enable-junctions.  I'm not entirely sure of that, but
it looks like write_fsloc is only called in dump_to_cache  if
HAVE_JUNCTION_SUPPORT is enabled.

I *think* write_fsloc is what writes out the referal location as well as
any junction location.
So, I *think* that as part of adding the junction support upstream has
broken referals unless you enable junction support.

That's kind of unfortunate for us because junction support comes with
dependencies like libxml2 which are kind of a lot to swallow in
nfs-utils.

I'd appreciate help confirming my conclusions.

* Are referals actually broken

* Is there an easy way to get them back without junction support

* how willing to turn on junction support are we in bookworm?  In a
  bookworm backport?
  


signature.asc
Description: PGP signature

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 09 May 2023 00:31:20 +0100 Luca Boccassi 
wrote:
> On Mon, 08 May 2023 14:14:30 -0700 Russ Allbery 
wrote:
> > Guillem Jover  writes:
> > > On Mon, 2023-05-08 at 08:48:49 -0700, Russ Allbery wrote:
> > 
> > >> […] I suspect Policy should say something stronger and more
> general,
> > >> namely that no package in Debian should divert a file from
another
> > >> package unless this is arranged cooperatively between the
packages
> to
> > >> solve some specific (unusual) problem.
> > 
> > > ,--- §3.9 ---
> > > You should not use "dpkg-divert" on a file belonging to another
> > > package without consulting the maintainer of that package first.
> When
> > > adding or removing diversions, package maintainer scripts must
> provide
> > > the "--package" flag to "dpkg-divert" and must not use "--local".
> > > `---
> > 
> > Oh, thank you!  I had completely forgotten that we said something
> about
> > this under maintainer scripts.
> > 
> > That doesn't entirely cover this case (because systemd and udev may
> not be
> > "that package" in this sense), but it covers much of the general
> case.
> 
> Would you like me to reword/move the new snippet?

Gentle ping. Any suggestion on how to reword/change the proposal?

-- 
Kind regards,
Luca Boccassi


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

Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Ansgar]

On Wed, 2023-05-10 at 23:47 +0200, Ansgar wrote:
> Cool, then let's ask tech-ctte.
> 
> Dear ctte, please consider overruling the dpkg maintainer to include
> the patch from #994388[1].
> 
> Thanks,
> Ansgar
> 
>   [1]: https://bugs.debian.org/994388#397

For derivatives based on Debian stable it might be worth having this
included in the next stable release; this would need a fairly quick
decision on this issue.

Ansgar

Bug#1035907: reportbug does not have provision for attachments

[Christopher Witkowski]

Package: reportbug
Version: 7.10.3+deb11u1
Severity: normal
X-Debbugs-Cc: cw...@z46860.e4ward.com

Dear Maintainer,

Nowhere in the reportbug process is there a request for
any files you would like attached to the problem report.

I am mainly thinking of screen captures, but, other files,
e.g. large log files, would also be candidates.


-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /home/chrisw/.reportbugrc:
reportbug_version "7.10.3+deb11u1"
mode standard
ui text
email "cw...@z46860.e4ward.com"
no-cc
list-cc-me
smtphost reportbug.debian.org

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

Kernel: Linux 5.10.0-22-686-pae (SMP w/2 CPU threads)
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 reportbug depends on:
ii  apt2.2.4
ii  python33.9.2-3
ii  python3-reportbug  7.10.3+deb11u1
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
pn  debconf-utils 
pn  debsums   
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.39-3
ii  gnupg 2.2.27-2+deb11u2
pn  python3-urwid 
pn  reportbug-gtk 
ii  xdg-utils 1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.2.4
ii  file   1:5.39-3
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information

Bug#1035906: reportbug fails to load a couple of Gtk modules

[Christopher Witkowski]

Package: reportbug
Version: 7.10.3+deb11u1
Severity: normal
X-Debbugs-Cc: cw...@z46860.e4ward.com

Dear Maintainer,

chrisw@msiu120:~$ reportbug
Gtk-Message: 18:15:32.339: Failed to load module "colorreload-gtk-module"
Gtk-Message: 18:15:32.340: Failed to load module "window-decorations-gtk-module"
Please enter the name of the package in which you have found a problem, or type
'other' to report a more general problem. If you don't know what package the
bug is in, please contact debian-u...@lists.debian.org for assistance.
>

-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /home/chrisw/.reportbugrc:
reportbug_version "7.10.3+deb11u1"
mode standard
ui text
email "cw...@z46860.e4ward.com"
no-cc
list-cc-me
smtphost reportbug.debian.org

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

Kernel: Linux 5.10.0-22-686-pae (SMP w/2 CPU threads)
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 reportbug depends on:
ii  apt2.2.4
ii  python33.9.2-3
ii  python3-reportbug  7.10.3+deb11u1
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
pn  debconf-utils 
pn  debsums   
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.39-3
ii  gnupg 2.2.27-2+deb11u2
pn  python3-urwid 
pn  reportbug-gtk 
ii  xdg-utils 1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.2.4
ii  file   1:5.39-3
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information

Bug#1035905: grub2: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: grub2
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update the Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and tested with
msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Ansgar]

Package: tech-ctte
X-Debbugs-Cc: Russ Allbery , Sean Whitton 
, Helmut Grohne , Luca Boccassi 
, debian-d...@lists.debian.org, debian-de...@lists.debian.org

On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> Ansgar  writes:
> > Debian going out of its way to tell derivative users to switch back from
> > merged-/usr to split-/usr is the *opposite* of trying to make things as
> > smooth for them as possible.
> 
> Yes, I agree with that part and I think I objected to that at the time.
> Nonetheless, one bad decision doesn't mean that it is Debian policy that
> we don't care about derivatives or their users.  I think we made a mistake
> there which is not in alignment with our ideals or our goals.  We should
> try to reverse that mistake, not double down on it.

Cool, then let's ask tech-ctte.

Dear ctte, please consider overruling the dpkg maintainer to include
the patch from #994388[1].

Thanks,
Ansgar

  [1]: https://bugs.debian.org/994388#397

Bug#918812: failure to mount persists since bookworm

[Alex Bennée]

Hi,

Just a quick note that the failure mode still exists after upgrading to
bookworm (testing). If anyone has any pointers on how to diagnose mount
failures during initrd I'd happily run some experiments.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Bug#1035857: texlive-fonts-extra: broken font symlinks for junicode

[Preuße]

Control: tags -1 + bookworm-ignore

On 10.05.2023 22:47, Andreas Beckmann wrote:

On 10/05/2023 22.24, Preuße, Hilmar wrote:


Hi,


42a992dff6dd2b54ce0ffc10367a29913e062c0b, else there would be no upgrade
path from bullseye to bookworm. I have to delay the fix to post-bookworm.



42f75ab3ead843b6b04edc6f4aed7498cb53101f . This could be reverted before
bookworm, I'd need to build a new orig.tar.gz as the font files are
black listed. Is it really that urgent?


You have some nice non-trivial packages here ;-)


Well, yes.


If you say the broken symlinks are not really a problem for bookworm
(and hard to fix), feel free to downgrade the severity and


People trying to use that font, would need to install a package from
unstable. Until now there was no complaint (except you). Best thing we
could do is to fix the issue in fonts-alegreya-sans. I tried so by
reporting to upstream, but currently there is not much move.


postpone a fix for it to trixie.


"trixie"? First release for years, not starting with "b". I started
already confusing the code names. ;-)

H.
--
--
sigfault

Bug#1035903: tracker: datetime build tests failing on 32-bit

[Jeremy Bícha]

Source: tracker
Version: 3.5.0-1
Severity: serious
Tags: ftbfs
Forwarded: https://gitlab.gnome.org/GNOME/tracker/-/issues/398

Tracker build tests are failing on 32-bit architectures. See the
upstream issue for more details.

Thank you,
Jeremy Bícha

Bug#1035902: obs-studio: NVENC codec fails unless I use ffmpeg to encode a video first

[Rishi Cutchin]

Package: obs-studio
Version: 29.0.2+dfsg-1+b1
Severity: normal
X-Debbugs-Cc: rishincutc...@gmail.com

Dear Maintainer,


   Run obs-studio, and attempted to record a video with NVENC selected as
   the encoder.

   Fails with this error:
   rishi@tripodhost:~$ [h264_nvenc @ 0x56294719dfc0] dl_fn->cuda_dl->cuInit(0) 
failed -> CUDA_ERROR_U_SNKNOWN: unknown error
warning: [NVENC encoder] nvenc_create_internal failed, trying again without 
Psycho Visual Tuning
info: -
info: [FFmpeg NVENC encoder: 'advanced_video_recording'] settings:
encoder:  NVIDIA NVENC H.264 (FFmpeg)
rate_control: CBR
bitrate:  2500
cqp:  0
keyint:   250
preset:   p5
tuning:   hq
multipass:qres
profile:  high
width:1920
height:   1080
b-frames: 2
psycho-aq:0
GPU:  0

[h264_nvenc @ 0x5629471a2c80] dl_fn->cuda_dl->cuInit(0) failed -> 
CUDA_ERROR_UNKNOWN: unknown error

But after encoding a video with ffmpeg on the command line with nvenc:
 $ffmpeg -i output.mp4 -c:v h264_nvenc -b:v 1M outputtwo.mp4
Subsequent attempts to use NVENC on obs succeed.

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

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

Versions of packages obs-studio depends on:
ii  libavcodec59   7:5.1.3-1
ii  libavdevice59  7:5.1.3-1
ii  libavformat59  7:5.1.3-1
ii  libavutil577:5.1.3-1
ii  libc6  2.36-9
ii  libcurl3-gnutls7.88.1-9
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-5
ii  libgcc-s1  12.2.0-14
ii  libjansson42.14-2
ii  libluajit-5.1-22.1.0~beta3+git20220320+dfsg-4.1
ii  libmbedcrypto7 2.28.3-1
ii  libmbedtls14   2.28.3-1
ii  libmbedx509-1  2.28.3-1
ii  libobs029.0.2+dfsg-1+b1
ii  libpci31:3.9.0-4
ii  libpulse0  16.1+dfsg1-2+b1
ii  libpython3.11  3.11.2-6
ii  libqt5core5a   5.15.8+dfsg-7
ii  libqt5gui5 5.15.8+dfsg-7
ii  libqt5network5 5.15.8+dfsg-7
ii  libqt5svg5 5.15.8-2
ii  libqt5widgets5 5.15.8+dfsg-7
ii  libqt5xml5 5.15.8+dfsg-7
ii  librist4   0.2.7+dfsg-1
ii  libspeexdsp1   1.2.1-1
ii  libsrt1.5-openssl  1.5.1-1
ii  libstdc++6 12.2.0-14
ii  libswscale67:5.1.3-1
ii  libudev1   252.6-1
ii  libv4l-0   1.22.1-5+b2
ii  libva-drm2 2.17.0-1
ii  libva2 2.17.0-1
ii  libx11-6   2:1.8.4-2
ii  libx264-1642:0.164.3095+gitbaee400-3
ii  libxcb-composite0  1.15-1
ii  libxcb-randr0  1.15-1
ii  libxcb-shm01.15-1
ii  libxcb-xfixes0 1.15-1
ii  libxcb-xinerama0   1.15-1
ii  libxcb11.15-1
ii  python33.11.2-1+b1
ii  python3.11 3.11.2-6

Versions of packages obs-studio recommends:
ii  obs-plugins  29.0.2+dfsg-1+b1

Versions of packages obs-studio suggests:
ii  pkexec 122-3
ii  policykit-1122-3
pn  v4l2loopback-dkms  

-- no debconf information

Bug#1035901: Pipewire & wireplumber: Inappropriate IOCTL for device

[Al Ma]

Package: pipewire
Version: 0.3.56-1
In my journal I get an error message about an inappropriate IOCTL for a device:
Mai 10 22:44:01 AnonymizedComputerName kernel: cx23885: cx23885[0]: registered 
device video0 [v4l2]
Mai 10 22:44:01 AnonymizedComputerName kernel: cx23885: cx23885[0]: registered 
device vbi0
Mai 10 22:44:01 AnonymizedComputerName kernel: cx23885: cx23885[0]: alsa: 
registered ALSA audio device
Mai 10 22:44:01 AnonymizedComputerName kernel: cx23885: cx23885_dvb_register() 
allocating 1 frontend(s)
Mai 10 22:44:01 AnonymizedComputerName kernel: cx23885: cx23885[0]: cx23885 
based dvb card
…
Mai 10 22:44:01 AnonymizedComputerName systemd[936]: Listening on PipeWire 
Multimedia System Socket.
…
Mai 10 22:44:01 AnonymizedComputerName systemd[936]: Started PipeWire 
Multimedia Service.
…
Mai 10 22:44:01 AnonymizedComputerName dbus-daemon[781]: [system] Activating 
via systemd: service name='org.freedesktop.RealtimeKit1' 
unit='rtkit-daemon.service' requested by ':1.29' (uid=119 pid=967 
comm="/usr/bin/pipewire ")
…
Mai 10 22:44:01 AnonymizedComputerName wireplumber[971]: SPA handle 
'api.bluez5.enum.dbus' could not be loaded; is it installed?
Mai 10 22:44:01 AnonymizedComputerName wireplumber[971]: PipeWire's BlueZ SPA 
missing or broken. Bluetooth not supported.
…
Mai 10 22:44:02 AnonymizedComputerName pulseaudio[968]: Failed to load module 
"module-alsa-card" (argument: "device_id="1" name="pci-_65_00.1" 
card_name="alsa_card.pci-_65_00.1" namereg_fail=false tsched=yes 
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes 
avoid_resampling=no card_properties="module-udev-detect.discovered=1""): 
initialization failed.
Mai 10 22:44:02 AnonymizedComputerName dbus-daemon[781]: [system] Activating 
via systemd: service name='org.bluez' unit='dbus-org.bluez.service' requested 
by ':1.39' (uid=119 pid=968 comm="/usr/bin/pulseaudio --daemonize=no 
--log-target=jo")
Mai 10 22:44:02 AnonymizedComputerName systemd[1]: Condition check resulted in 
Bluetooth service being skipped.
Mai 10 22:44:02 AnonymizedComputerName rtkit-daemon[1003]: Supervising 4 
threads of 2 processes of 1 users.
Mai 10 22:44:02 AnonymizedComputerName rtkit-daemon[1003]: Successfully made 
thread 1132 of process 968 owned by '119' RT at priority 5.
Mai 10 22:44:02 AnonymizedComputerName rtkit-daemon[1003]: Supervising 5 
threads of 2 processes of 1 users.
Mai 10 22:44:02 AnonymizedComputerName systemd[936]: Started Sound Service.
Mai 10 22:44:02 AnonymizedComputerName systemd[936]: Reached target Main User 
Target.
Mai 10 22:44:02 AnonymizedComputerName systemd[936]: Startup finished in 1.324s.
Mai 10 22:44:02 AnonymizedComputerName pulseaudio[968]: Failed to load module 
"module-alsa-card" (argument: "device_id="0" name="pci-_00_1f.3" 
card_name="alsa_card.pci-_00_1f.3" namereg_fail=false tsched=yes 
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes 
avoid_resampling=no card_properties="module-udev-detect.discovered=1""): 
initialization failed.
Mai 10 22:44:02 AnonymizedComputerName pulseaudio[968]: Failed to load module 
"module-alsa-card" (argument: "device_id="1" name="pci-_65_00.1" 
card_name="alsa_card.pci-_65_00.1" namereg_fail=false tsched=yes 
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes 
avoid_resampling=no card_properties="module-udev-detect.discovered=1""): 
initialization failed.
Mai 10 22:44:02 AnonymizedComputerName pulseaudio[968]: Failed to load module 
"module-alsa-card" (argument: "device_id="0" name="pci-_00_1f.3" 
card_name="alsa_card.pci-_00_1f.3" namereg_fail=false tsched=yes 
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes 
avoid_resampling=no card_properties="module-udev-detect.discovered=1""): 
initialization failed.
Mai 10 22:44:02 AnonymizedComputerName pipewire[967]: spa.v4l2: '/dev/video0' 
VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control) für das Gerät
The last lines above are all shown red, so I excercise, ergo, caution.  In 
plain English, how should this message about wrong control worry me (besides 
from other issues with the computer which may be related or not)?
The package wireplumber 0.4.2-5 is installed. The package 
pipewire-media-session has been uninstalled a long time ago and purged a boot 
ago. I run
$ uname -a
Linux AnonymizedComputerName 5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 
(2023-04-22) x86_64 GNU/Linux
Any remedy? Any bugfix?
Gratefully,
Alma

Bug#1035897: reportbug says it is out of date, but, apt says otherwise

[Christopher Witkowski]

reportbug says:


chrisw@msiu120:~$ reportrbug
bash: reportrbug: command not found
chrisw@msiu120:~$ reportbug
Gtk-Message: 15:50:34.262: Failed to load module "colorreload-gtk-module"
Gtk-Message: 15:50:34.263: Failed to load module
"window-decorations-gtk-module"
Please enter the name of the package in which you have found a problem,
or type
'other' to report a more general problem. If you don't know what package the
bug is in, please contact debian-u...@lists.debian.org for assistance.
> reportbug
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of
the submitter).
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'Christopher Witkowski ' as your from
address.
Getting status for reportbug...
Checking for newer versions at madison...

Your version (7.10.3+deb11u1) of reportbug appears to be out of date.
The following newer release(s) are available in the Debian archive:
  testing: 12.0.0
  unstable: 12.0.0
Please try to verify if the bug you are about to report is already
addressed by these releases.  Do you still want to file a report [y|N|q|?]?


but apt says:


root@msiu120:/home/chrisw# apt upgrade reportbug
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
reportbug is already the newest version (7.10.3+deb11u1).
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@msiu120:/home/chrisw#


root@msiu120:/home/chrisw# apt policy reportbug
reportbug:
  Installed: 7.10.3+deb11u1
  Candidate: 7.10.3+deb11u1
  Version table:
 *** 7.10.3+deb11u1 500
    500 cdrom://[Debian GNU/Linux 11.6.0 _Bullseye_ - Official i386
STICK16GB Binary-1 20221217-10:39] bullseye/main i386 Packages
    500 http://debian.mirror.iweb.ca/debian bullseye/main i386 Packages
    100 /var/lib/dpkg/status

Bug#1035857: texlive-fonts-extra: broken font symlinks for junicode

[Andreas Beckmann]

On 10/05/2023 22.24, Preuße, Hilmar wrote:


42a992dff6dd2b54ce0ffc10367a29913e062c0b, else there would be no upgrade
path from bullseye to bookworm. I have to delay the fix to post-bookworm.



42f75ab3ead843b6b04edc6f4aed7498cb53101f . This could be reverted before
bookworm, I'd need to build a new orig.tar.gz as the font files are
black listed. Is it really that urgent?


You have some nice non-trivial packages here ;-)

If you say the broken symlinks are not really a problem for bookworm 
(and hard to fix), feel free to downgrade the severity and postpone a 
fix for it to trixie.


Andreas

Bug#1035900: signond uses 100% cpu when used with Google account/drive

[Sten Heinze]

Package: signond
Version: 8.61-1
Severity: normal
X-Debbugs-Cc: s...@gmx.de

Dear Maintainer,

I've set up my Google account in Plasma systemsettings/online accounts, to be 
able to access my files in Google Drive from Dolphin. It seems that after a 
while Dolphin doesn't display those files anymore and signond goes to 100% cpu
use. My current workaround is to kill signond, which is restarted 
automatically and files are displayed again, until the issue occurs again.

I would expect files to be displayed continously without having to kill 
signond and without it using 100% cpu.

Not sure at the moment how much of an effect sending the computer to sleep 
has.

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages signond depends on:
ii  libc6  2.36-9
ii  libdbus-1-31.14.6-1
ii  libproxy1v50.4.18-1.2
ii  libqt5core5a   5.15.8+dfsg-3
ii  libqt5dbus55.15.8+dfsg-3
ii  libqt5network5 5.15.8+dfsg-3
ii  libqt5sql5 5.15.8+dfsg-3
ii  libqt5sql5-sqlite  5.15.8+dfsg-3
ii  libsignon-extension1   8.61-1
ii  libsignon-plugins-common1  8.61-1
ii  libstdc++6 12.2.0-14

Versions of packages signond recommends:
pn  signon-ui  

signond suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "",
LC_ALL = (unset),
LC_TIME = "en_DE.UTF-8",
LC_MEASUREMENT = "en_DE.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#1035899: org.gnome.Shell.desktop[…]: Unrecognized option: -initfd

[Al Ma]

Package: gnome-shell
Version: 42.3.1-2
In my journal log I see, among other weird stuff, the information that the 
option -initfd has not been recognized:
Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Boot VGA GPU 
/dev/dri/card1 selected as primary
Mai 10 21:01:21 AnonymizedComputerName pulseaudio[953]: Failed to load module 
"module-alsa-card" (argument: "device_id="1" name="pci-_65_00.1" 
card_name="alsa_card.pci-_65_00.1" namereg_fail=false tsched=yes 
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes 
avoid_resampling=no card_properties="module-udev-detect.discovered=1""): 
initialization failed.
Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[778]: [system] Activating 
via systemd: service name='org.bluez' unit='dbus-org.bluez.service' requested 
by ':1.39' (uid=119 pid=953 comm="/usr/bin/pulseaudio --daemonize=no 
--log-target=jo")
Mai 10 21:01:21 AnonymizedComputerName rtkit-daemon[972]: Supervising 4 threads 
of 2 processes of 1 users.
Mai 10 21:01:21 AnonymizedComputerName rtkit-daemon[972]: Successfully made 
thread 1123 of process 953 owned by '119' RT at priority 5.
Mai 10 21:01:21 AnonymizedComputerName rtkit-daemon[972]: Supervising 5 threads 
of 2 processes of 1 users.
Mai 10 21:01:21 AnonymizedComputerName systemd[920]: Started Sound Service.
Mai 10 21:01:21 AnonymizedComputerName systemd[920]: Reached target Main User 
Target.
Mai 10 21:01:21 AnonymizedComputerName systemd[920]: Startup finished in 1.360s.
Mai 10 21:01:21 AnonymizedComputerName pulseaudio[953]: Failed to load module 
"module-alsa-card" (argument: "device_id="0" name="pci-_00_1f.3" 
card_name="alsa_card.pci-_00_1f.3" namereg_fail=false tsched=yes 
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes 
avoid_resampling=no card_properties="module-udev-detect.discovered=1""): 
initialization failed.
Mai 10 21:01:21 AnonymizedComputerName pulseaudio[953]: Failed to load module 
"module-alsa-card" (argument: "device_id="1" name="pci-_65_00.1" 
card_name="alsa_card.pci-_65_00.1" namereg_fail=false tsched=yes 
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes 
avoid_resampling=no card_properties="module-udev-detect.discovered=1""): 
initialization failed.
Mai 10 21:01:21 AnonymizedComputerName pulseaudio[953]: Failed to load module 
"module-alsa-card" (argument: "device_id="0" name="pci-_00_1f.3" 
card_name="alsa_card.pci-_00_1f.3" namereg_fail=false tsched=yes 
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes 
avoid_resampling=no card_properties="module-udev-detect.discovered=1""): 
initialization failed.
Mai 10 21:01:21 AnonymizedComputerName pipewire[952]: spa.v4l2: '/dev/video0' 
VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control) für das Gerät
Mai 10 21:01:21 AnonymizedComputerName pulseaudio[953]: Failed to load module 
"module-alsa-card" (argument: "device_id="1" name="pci-_65_00.1" 
card_name="alsa_card.pci-_65_00.1" namereg_fail=false tsched=yes 
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes 
avoid_resampling=no card_properties="module-udev-detect.discovered=1""): 
initialization failed.
Mai 10 21:01:21 AnonymizedComputerName pipewire[952]: spa.v4l2: '/dev/video0' 
VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control) für das Gerät
Mai 10 21:01:21 AnonymizedComputerName pulseaudio[953]: Failed to load module 
"module-alsa-card" (argument: "device_id="0" name="pci-_00_1f.3" 
card_name="alsa_card.pci-_00_1f.3" namereg_fail=false tsched=yes 
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes 
avoid_resampling=no card_properties="module-udev-detect.discovered=1""): 
initialization failed.
Mai 10 21:01:21 AnonymizedComputerName pulseaudio[953]: Failed to load module 
"module-alsa-card" (argument: "device_id="0" name="pci-_00_1f.3" 
card_name="alsa_card.pci-_00_1f.3" namereg_fail=false tsched=yes 
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes 
avoid_resampling=no card_properties="module-udev-detect.discovered=1""): 
initialization failed.
Mai 10 21:01:21 AnonymizedComputerName pulseaudio[953]: Failed to load module 
"module-alsa-card" (argument: "device_id="1" name="pci-_65_00.1" 
card_name="alsa_card.pci-_65_00.1" namereg_fail=false tsched=yes 
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes 
avoid_resampling=no card_properties="module-udev-detect.discovered=1""): 
initialization failed.
Mai 10 21:01:21 AnonymizedComputerName /usr/libexec/gdm-wayland-session[969]: 
dbus-daemon[969]: [session uid=119 pid=969] Activating service 
name='org.a11y.Bus' requested by ':1.4' (uid=119 pid=1026 
comm="/usr/bin/gnome-shell ")
Mai 10 21:01:21 AnonymizedComputerName /usr/libexec/gdm-wayland-session[969]: 
dbus-daemon[969]: [session uid=119 pid=969] Successfully activated service 
'org.a11y.Bus'
Mai 10 21:01:22 AnonymizedComputerName gnome-shell[1026]: Using public X11 
display :1024, (using :1025 for managed

Bug#1035898: unblock: chrony/4.3-2+deb12u1

[Vincent Blut]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: chr...@packages.debian.org
Control: affects -1 + src:chrony

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Please unblock package chrony

[ Reason ]
This softens a rule in the AppArmor profile. Currently, the profile is way too
strict about allowed gpsd socket names.

[ Impact ]
Users may need to override the AppArmor profile (or put the profile in complain 
mode) so that chronyd can consume time information from gpsd using sockets.
Overriding an AppArmor profile is acceptable when dealing with some exotic
configurations, but here even trying to feed chronyd with something as common
as PPS samples would be denied by the profile.

[ Tests ]
I checked that chronyd was able to receive PPS samples from gpsd through a
Unix socket driver using the '/run/chrony.pps0.sock' path. This is no longer
denied with chrony 4.3-2+deb12u1.

[ Risks ]
None that I know of.

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

[ Other info ]
I must admit that the version number is atypical for an upload to unstable but
chrony 4.3-3 is already in experimental.

unblock chrony/4.3-2+deb12u1


-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZFv+fQAKCRAQn1qAt/bg
ATptAQDKB1vG2CXDXkwW1dGb9l3GFwua+oeoc1qOm3LNhqNfSgD/ZBld8s8e1XSD
QXFm/ZXjxKXIkU+1m8TaS5JL5oRWDwk=
=uMJh
-END PGP SIGNATURE-
diff -Nru chrony-4.3/debian/changelog chrony-4.3/debian/changelog
--- chrony-4.3/debian/changelog 2023-01-27 22:51:17.0 +0100
+++ chrony-4.3/debian/changelog 2023-05-08 22:05:00.0 +0200
@@ -1,3 +1,13 @@
+chrony (4.3-2+deb12u1) unstable; urgency=medium
+
+  * debian/usr.sbin.chronyd:
+- Modify the AppArmor profile to allow more gpsd socket names. This will
+avoid the need for users to override the profile to let chronyd consume PPS
+samples or serial time supplied by gpsd over a Unix-domain socket.
+Thanks to Ryan Govostes for the report. (Closes: #1034519)
+
+ -- Vincent Blut   Mon, 08 May 2023 22:05:00 +0200
+
 chrony (4.3-2) unstable; urgency=medium
 
   * debian/control:
diff -Nru chrony-4.3/debian/usr.sbin.chronyd chrony-4.3/debian/usr.sbin.chronyd
--- chrony-4.3/debian/usr.sbin.chronyd  2023-01-27 22:51:17.0 +0100
+++ chrony-4.3/debian/usr.sbin.chronyd  2023-05-08 22:05:00.0 +0200
@@ -59,7 +59,7 @@
   # Configs using a 'chrony.' prefix like the tempcomp config file example
   /etc/chrony.* r,
   # Example gpsd socket is outside @{run}/chrony/
-  @{run}/chrony.tty{,*}.sock rw,
+  @{run}/chrony.*.sock rw,
   # To sign replies to MS-SNTP clients by the smbd daemon
   /var/lib/samba/ntp_signd/socket rw,
 

Bug#1035897: reportbug says it is out of date, but, apt says otherwise

[Christopher Witkowski]

Package: reportbug
Version: 7.10.3+deb11u1
Severity: normal
X-Debbugs-Cc: cw...@z46860.e4ward.com

Dear Maintainer,

I am trying to report a bug in reportbug using reportbug.

I got to the part where it asks me to select a text editor,
so, I selected vim.tiny, but, now, the text I need to copy
and paste here is hidden by the text editor display. And I
can't scroll up (Mate Terminal or vim.tiny problem or just
the way it is or has to be?).

I'm sure it won't be hard to work around it, but, it's just
such a dumb thing to have happen.


-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /home/chrisw/.reportbugrc:
reportbug_version "7.10.3+deb11u1"
mode standard
ui text
email "cw...@z46860.e4ward.com"
no-cc
list-cc-me
smtphost reportbug.debian.org

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

Kernel: Linux 5.10.0-22-686-pae (SMP w/2 CPU threads)
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 reportbug depends on:
ii  apt2.2.4
ii  python33.9.2-3
ii  python3-reportbug  7.10.3+deb11u1
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
pn  debconf-utils 
pn  debsums   
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.39-3
ii  gnupg 2.2.27-2+deb11u2
pn  python3-urwid 
pn  reportbug-gtk 
ii  xdg-utils 1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.2.4
ii  file   1:5.39-3
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information

Bug#1035896: tor: Stack trace

[Tim McConnell]

Package: tor
Version: 0.4.7.13-1
Severity: normal

 Module /home/tmick/.local/share/torbrowser/tbb/x86_64/tor-
browser/Browser/libplc4.so from deb systemd-252.6-1.amd64
 Module libsystemd.so.0
from deb systemd-252.6-1.amd64
 Stack trace of thread
1458911:
 #0  0x7f2a3faa8ccc
__pthread_kill_implementation (libc.so.6 + 0x8accc)
 #1  0x7f2a3fa59ef2
__GI_raise (libc.so.6 + 0x3bef2)
 #2  0x7f2a38935991 n/a
(/home/tmick/.local/share/torbrowser/tbb/x86_64/tor-browser/Browser/libxul.so +
0x3f35991)
 ELF object binary
architecture: AMD x86-64
May 10 15:21:37 DebianTim systemd[1]: systemd-coredump@1-1459324-0.service:
Deactivated successfully.

Let me know if there is anything I can get for you and how to get it.


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

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

Versions of packages tor depends on:
ii  adduser3.132
ii  libc6  2.36-9
ii  libcap21:2.66-3
ii  libevent-2.1-7 2.1.12-stable-8
ii  liblzma5   5.4.1-0.2
ii  libseccomp22.5.4-1+b3
ii  libssl33.0.8-1
ii  libsystemd0252.6-1
ii  libzstd1   1.5.4+dfsg2-5
ii  lsb-base   11.6
ii  runit-helper   2.15.2
ii  sysvinit-utils [lsb-base]  3.06-4
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages tor recommends:
ii  logrotate3.21.0-1
ii  tor-geoipdb  0.4.7.13-1
ii  torsocks 2.4.0-1

Versions of packages tor suggests:
ii  apparmor-utils   3.0.8-3
pn  mixmaster
ii  nyx  2.1.0-2.2
ii  obfs4proxy   0.0.14-1+b4
ii  socat1.7.4.4-2
ii  torbrowser-launcher  0.3.6-2

-- no debconf information

Bug#1035857: texlive-fonts-extra: broken font symlinks for junicode

[Preuße]

On 10.05.2023 11:18, Andreas Beckmann wrote:

Hello,


during a test with piuparts I noticed your package ships (or creates)
broken symlinks:

3m10.3s ERROR: FAIL: Broken symlinks:
   /usr/share/texlive/texmf-dist/fonts/truetype/public/junicode/Junicod -> 
../../../../../../fonts/truetype/junicode/Junicode-BoldItalic.ttf 
(texlive-fonts-extra-links)
   /usr/share/texlive/texmf-dist/fonts/truetype/public/junicode/Junicode-Bold 
-> ../../../../../../fonts/truetype/junicode/Junicode-Bold.ttf 
(texlive-fonts-extra-links)
   /usr/share/texlive/texmf-dist/fonts/truetype/public/junicode/Junicode-It -> 
../../../../../../fonts/truetype/junicode/Junicode-Italic.ttf 
(texlive-fonts-extra-links)
   /usr/share/texlive/texmf-dist/fonts/truetype/public/junicode/Junicode.ttf -> 
../../../../../../fonts/truetype/junicode/Junicode.ttf (texlive-fonts-extra-links)

fonts-junicode nowadays only ships *.otf, no more *.ttf.


I planned to fix that in the past (move files from t-f-e-links to
t-f-e), see commit 7fc1a4238a23a5bc0a7c76fd6465906d48601a0a .
Unfortunately at the same time I moved that some files into the other
direction, so I had to revert that step in
42a992dff6dd2b54ce0ffc10367a29913e062c0b, else there would be no upgrade
path from bullseye to bookworm. I have to delay the fix to post-bookworm.



The Junicode link names also look broken to me, like they got truncated
somehow, and missing the file extension.
Especially the first one: "Junicod".


Yes, this is definitely a Typo, but correcting them does not solve an issue.


fonts-alegreya-sans will not be in bookworm (and hasn't been in
bullseye), thus
   /usr/share/texlive/texmf-dist/fonts/opentype/huerta/alegreya
also contains broken symlinks.


Was introduced in 5a1a62fe981bf67e743592ba689c2f18853a8886.
Unfortunately I noticed to late that fonts-alegreya-sans is RC buggy and
I downgraded the Dep to recommend:
42f75ab3ead843b6b04edc6f4aed7498cb53101f . This could be reverted before
bookworm, I'd need to build a new orig.tar.gz as the font files are
black listed. Is it really that urgent?

Hilmar
--
sigfault

Bug#1035895: Please add ast_dri.so

[Al Ma]

Package: libgl1-mesa-dri
Version: 20.3.5-1
My journal log shows, among other weird stuff, the following error message:
Mai 10 21:01:20 AnonymizedComputerName gnome-shell[1026]: Running GNOME Shell 
(using mutter 42.3) as a Wayland display server
Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Device 
'/dev/dri/card0' prefers shadow buffer
Mai 10 21:01:21 AnonymizedComputerName goa-daemon[1048]: goa-daemon version 
3.38.0 starting
Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Added device 
'/dev/dri/card0' (ast) using atomic mode setting.
Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session uid=119 
pid=962] Activating service name='org.gnome.Identity' requested by ':1.15' 
(uid=119 pid=1048 comm="/usr/libexec/goa-daemon ")
Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Device 
'/dev/dri/card1' prefers shadow buffer
Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session uid=119 
pid=962] Successfully activated service 'org.gnome.OnlineAccounts'
Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session uid=119 
pid=962] Successfully activated service 'org.gnome.Identity'
Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session uid=119 
pid=962] Successfully activated service 'org.gtk.vfs.GoaVolumeMonitor'
Mai 10 21:01:21 AnonymizedComputerName systemd[920]: Started Virtual filesystem 
service - GNOME Online Accounts monitor.
Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session uid=119 
pid=962] Activating via systemd: service 
name='org.gtk.vfs.GPhoto2VolumeMonitor' 
unit='gvfs-gphoto2-volume-monitor.service' requested by ':1.3' (uid=119 pid=955 
comm="/usr/libexec/tracker-miner-fs ")
Mai 10 21:01:21 AnonymizedComputerName systemd[920]: Starting Virtual 
filesystem service - digital camera monitor...
Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session uid=119 
pid=962] Successfully activated service 'org.gtk.vfs.GPhoto2VolumeMonitor'
Mai 10 21:01:21 AnonymizedComputerName systemd[920]: Started Virtual filesystem 
service - digital camera monitor.
Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[778]: [system] Activating 
via systemd: service name='org.freedesktop.UPower' unit='upower.service' 
requested by ':1.37' (uid=119 pid=955 comm="/usr/libexec/tracker-miner-fs ")
Mai 10 21:01:21 AnonymizedComputerName systemd[1]: Starting Daemon for power 
management...
Mai 10 21:01:21 AnonymizedComputerName systemd[1]: Started Console Mouse 
manager.
Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Added device 
'/dev/dri/card1' (nouveau) using non-atomic mode setting.
Mai 10 21:01:21 AnonymizedComputerName org.gnome.Shell.desktop[1026]: pci id 
for fd 9: 1a03:2000, driver (null)
Mai 10 21:01:21 AnonymizedComputerName org.gnome.Shell.desktop[1026]: 
MESA-LOADER: failed to open ast: /usr/lib/dri/ast_dri.so: Kann die 
Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden (search 
paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
Mai 10 21:01:21 AnonymizedComputerName org.gnome.Shell.desktop[1026]: failed to 
load driver: ast
So MESA-LOADER complains that /usr/lib/dri/ast_dri.so is not found.  This is 
correct because on my machine, /usr/lib/dri doesn't exist and ast_dri.so 
doesn't exist elsewhere. Does my Aspeed chip have no driver?  Should I ever 
need it a VGA output, don't I get it?  My request is to deal with this error 
message, ideally, by introducing ast_dri.so into to Debian (or making 
MESA-LOADER work without it).

Bug#1035808: Info received (Bug#1035808: (libvirt-clients: Cannot run virsh: /usr/local/lib/x86_64-linux-gnu/libvirt.so.0: version `LIBVIRT_PRIVATE_9.0.0' not found (required by virsh)))

[Sean Whalen]

On 5/10/2023 4:00 PM, Debian Bug Tracking System wrote:

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian Libvirt Maintainers 

If you wish to submit further information on this problem, please
send it to 1035...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
1035808: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035808
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
Respectfully,
Sean Whalen



signature.asc
Description: OpenPGP digital signature

Bug#1035808: (libvirt-clients: Cannot run virsh: /usr/local/lib/x86_64-linux-gnu/libvirt.so.0: version `LIBVIRT_PRIVATE_9.0.0' not found (required by virsh))

[Sean Whalen]

Never mind. There were leftover files when I tried installing and 
removing my own version of libvirt via checkinstall.


On 5/9/2023 8:42 AM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1035808: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035808.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
   sea...@pm.me
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
  Debian Libvirt Maintainers 

If you wish to submit further information on this problem, please
send it to 10

35...@bugs.debian.org.


Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
1035808: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035808
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
Respectfully,
Sean Whalen



signature.asc
Description: OpenPGP digital signature

Bug#1035894: unblock: desktop-base/12.0.6

[Aurélien COUDERC]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: desktop-b...@packages.debian.org, debian-desk...@lists.debian.org
Control: affects -1 + src:desktop-base

Dear Release Team,

please unblock package desktop-base.

[ Reason ]
It fixes a bug where Pymouth messages and prompts don’t get displayed
for some screen size and ratio combinations.

[ Impact ]
- Users won’t see the password prompt for LUKS encrypted volumes on boot
  in certain screen configurations. (#1032412)
- The « remove media press enter to reboot » message isn’t shown after
  initial installation.

[ Tests ]
I tested that there are no regression on single screen use cases and
both the original reporter and a second person confirmed the fix on
their multi-screen / multi-ratio configurations.

[ Risks ]
No risk identified, the patch is small and localised the new code
underwent more tests in more configurations that the one currently in
testing.

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

[ Other info ]
Thanks for your work on the release !

unblock desktop-base/12.0.6
diff -Nru desktop-base-12.0.5/debian/changelog 
desktop-base-12.0.6/debian/changelog
--- desktop-base-12.0.5/debian/changelog2023-03-01 23:22:32.0 
+0100
+++ desktop-base-12.0.6/debian/changelog2023-04-13 21:58:23.0 
+0200
@@ -1,3 +1,10 @@
+desktop-base (12.0.6) unstable; urgency=medium
+
+  * Fix LUKS password not being shown in multi-screen setup with mixed aspect
+ratios.
+
+ -- Aurélien COUDERC   Thu, 13 Apr 2023 21:58:23 +0200
+
 desktop-base (12.0.5) unstable; urgency=medium
 
   * Make the GDM Debian footer slightly smaller.
diff -Nru desktop-base-12.0.5/emerald-theme/plymouth/emerald.script 
desktop-base-12.0.6/emerald-theme/plymouth/emerald.script
--- desktop-base-12.0.5/emerald-theme/plymouth/emerald.script   2023-03-01 
23:01:49.0 +0100
+++ desktop-base-12.0.6/emerald-theme/plymouth/emerald.script   2023-04-13 
21:58:23.0 +0200
@@ -119,7 +119,8 @@
 #Debug("y = " + y);
 
 text_height = first_line_height * 7.5;
-min_height = window_max.height - 2 * first_line_height;
+# subtract Window.GetY() to show info also at smallest of dual srceens
+min_height = window_max.height - 2 * first_line_height - Window.GetY();
 #Debug("text_height=" + text_height + "; min_height=" + min_height);
 
 if (y + text_height > min_height)
@@ -131,8 +132,8 @@
 
 #- Screen/window setup ---
 # Compute screen/image ratio and scale the background accordingly
-window_max.width = Window.GetX() * 2 + Window.GetWidth();
-window_max.height = Window.GetY() * 2 + Window.GetHeight();
+window_max.width = Window.GetWidth();
+window_max.height = Window.GetHeight();
 screen_ratio = window_max.width / window_max.height;
 small_dimension = Math.Min(window_max.width, window_max.height);
 #Debug("Window.GetX():" + Window.GetX() + ", Window.GetY():" + Window.GetY());

Bug#1035893: No sound and «pulseaudio[…]: Failed to load module "module-alsa-card"»

[Al Ma]

Package: pulseaudio
Version: 14.2-2
My machine runs Debian stable with several upgraded packages but has no sound 
ouput. It's a software issue (because in another operating system in dual boot 
mode I get sound output).  Here's a (hopefully, relevant) part of the journal 
log:
Mai 10 21:01:20 AnonymizedComputerName kernel: cx23885: cx23885[0]: alsa: 
registered ALSA audio device Mai 10 21:01:20 AnonymizedComputerName kernel: 
cx23885: cx23885_dvb_register() allocating 1 frontend(s) Mai 10 21:01:20 
AnonymizedComputerName kernel: cx23885: cx23885[0]: cx23885 based dvb card Mai 
10 21:01:20 AnonymizedComputerName kernel: i2c i2c-20: Added multiplexed i2c 
bus 23 Mai 10 21:01:20 AnonymizedComputerName kernel: a8293 20-000b: Allegro 
A8293 SEC successfully attached Mai 10 21:01:20 AnonymizedComputerName 
systemd[1]: Started Disk Manager. Mai 10 21:01:20 AnonymizedComputerName 
udisksd[798]: Acquired the name org.freedesktop.UDisks2 on the system message 
bus Mai 10 21:01:20 AnonymizedComputerName NetworkManager[779]:  
[1683745280.5666] device (wlp179s0): set-hw-addr: set MAC address to 
AnonymizedMACAddress (scanning) Mai 10 21:01:20 AnonymizedComputerName 
audit[874]: AVC apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" 
pid=874 comm="cupsd" capability=12 capname="net_admin" Mai 10 21:01:20 
AnonymizedComputerName systemd[1]: Started CUPS Scheduler. Mai 10 21:01:20 
AnonymizedComputerName systemd[1]: Reached target Printer. Mai 10 21:01:20 
AnonymizedComputerName systemd[1]: Started Make remote CUPS printers available 
locally. Mai 10 21:01:20 AnonymizedComputerName kernel: m88rs6000t 23-0021: 
chip_id=64 Mai 10 21:01:20 AnonymizedComputerName colord-sane[940]: 
io/hpmud/musb.c 2101: Invalid usb_open: Permission denied Mai 10 21:01:20 
AnonymizedComputerName systemd[920]: Queued start job for default target Main 
User Target. Mai 10 21:01:20 AnonymizedComputerName systemd[920]: Created slice 
User Application Slice. Mai 10 21:01:20 AnonymizedComputerName kernel: 
m88rs6000t 23-0021: Montage M88RS6000 internal tuner successfully identified 
Mai 10 21:01:20 AnonymizedComputerName kernel: dvbdev: DVB: registering new 
adapter (cx23885[0]) Mai 10 21:01:20 AnonymizedComputerName kernel: cx23885 
:08:00.0: DVB: registering adapter 0 frontend 0 (Montage Technology 
M88RS6000)... Mai 10 21:01:20 AnonymizedComputerName kernel: cx23885: 
cx23885_dvb_register() allocating 1 frontend(s) Mai 10 21:01:20 
AnonymizedComputerName kernel: cx23885: cx23885[0]: cx23885 based dvb card Mai 
10 21:01:20 AnonymizedComputerName systemd[920]: Created slice User Core 
Session Slice. Mai 10 21:01:20 AnonymizedComputerName systemd[920]: Reached 
target Paths. Mai 10 21:01:20 AnonymizedComputerName systemd[920]: Reached 
target Timers. Mai 10 21:01:20 AnonymizedComputerName systemd[920]: Starting 
D-Bus User Message Bus Socket. Mai 10 21:01:20 AnonymizedComputerName 
systemd[920]: Listening on GnuPG network certificate management daemon. Mai 10 
21:01:20 AnonymizedComputerName systemd[920]: Listening on GNOME Keyring 
daemon. Mai 10 21:01:20 AnonymizedComputerName systemd[920]: Listening on GnuPG 
cryptographic agent and passphrase cache (access for web browsers). Mai 10 
21:01:20 AnonymizedComputerName systemd[920]: Listening on GnuPG cryptographic 
agent and passphrase cache (restricted). Mai 10 21:01:20 AnonymizedComputerName 
systemd[920]: Listening on GnuPG cryptographic agent (ssh-agent emulation). Mai 
10 21:01:20 AnonymizedComputerName systemd[920]: Listening on GnuPG 
cryptographic agent and passphrase cache. Mai 10 21:01:20 
AnonymizedComputerName systemd[920]: Listening on PipeWire Multimedia System 
Socket. Mai 10 21:01:20 AnonymizedComputerName systemd[920]: Listening on 
debconf communication socket. Mai 10 21:01:20 AnonymizedComputerName 
systemd[920]: Listening on Sound System. Mai 10 21:01:20 AnonymizedComputerName 
systemd[920]: Listening on D-Bus User Message Bus Socket. Mai 10 21:01:20 
AnonymizedComputerName systemd[920]: Reached target Sockets. Mai 10 21:01:20 
AnonymizedComputerName systemd[920]: Reached target Basic System. Mai 10 
21:01:20 AnonymizedComputerName systemd[1]: Started User Manager for UID 119. 
Mai 10 21:01:20 AnonymizedComputerName systemd[920]: Started PipeWire 
Multimedia Service. Mai 10 21:01:20 AnonymizedComputerName systemd[1]: Started 
Session c1 of user Debian-gdm. Mai 10 21:01:20 AnonymizedComputerName 
systemd[920]: Starting Sound Service... Mai 10 21:01:20 AnonymizedComputerName 
kernel: i2c i2c-20: Added multiplexed i2c bus 24 Mai 10 21:01:20 
AnonymizedComputerName kernel: si2168 20-0064: Silicon Labs Si2168-B40 
successfully identified Mai 10 21:01:20 AnonymizedComputerName kernel: si2168 
20-0064: firmware version: B 4.0.2 Mai 10 21:01:20 AnonymizedComputerName 
systemd[920]: Starting Tracker metadata extractor... Mai 10 21:01:20 
AnonymizedComputerName systemd[920]: Starting Tracker file system data miner... 
Mai 10 21:01:20 AnonymizedComputerName kernel: si2157 

Bug#1035891: openjdk-17-jre-headless: Crashes when ulimit -v is in effect

[David Lee Lambert]

Package: openjdk-17-jre-headless
Version: 17.0.6+10-1~deb11u1
Severity: important
Tags: upstream

Dear Maintainer,

On a certain multi-user system, I have the following lines in /etc/profile ...

ulimit -d 99
ulimit -v 389

In other words, almost 4G virtual memory per process, of which 1G data segment. 
 (Physical RAM is currently 16G.)

But with those settings, and the Java runtime default memory alocation, Java 
does not start. Even "java -help"
or "java -version" fails with a memory error!

$ java -version
Error occurred during initialization of VM
Could not allocate compressed class space: 1073741824 bytes

Now, I can pass an argument to limit Java heap size, and it works:

$ java -Xmx1500m -version
openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment (build 17.0.6+10-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.6+10-Debian-1deb11u1, mixed mode, sharing)

But there's a point where it gets weird:

$ java -Xmx1750m -version
openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment (build 17.0.6+10-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.6+10-Debian-1deb11u1, mixed mode, sharing)

$ java -Xmx1800m -version
[0.019s][warning][os,thread] Failed to start thread "Unknown thread" - 
pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, 
detached.
Error occurred during initialization of VM

$ java -Xmx1900m -version
Error occurred during initialization of VM
Could not allocate compressed class space: 1073741824 bytes

Or if I adjust the "ulimit -v" limit downward, the safe-start point of the Java 
VM goes down, but not one-for-one...

$ ulimit -v 369
$ java -Xmx1750m -version
Error occurred during initialization of VM
Could not allocate compressed class space: 1073741824 bytes

$ java -Xmx1650m -version
openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment (build 17.0.6+10-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.6+10-Debian-1deb11u1, mixed mode, sharing)

Upstream bug https://bugs.openjdk.org/browse/JDK-8071445 .  Last comment:

> This is not critical for JDK 7. As the filer stated, there is an obvious 
> workaround to lower the maximum heap size. However, when we decide the 
> default maximum heap, it would be good to look at the ulimit and set a lower 
> maximum heap size if that limit is set. 

But the "obvious workaround" is not always straightforward when using 
applications or tools built on Java (e.g., Eclipse or Gradle).

The JDK already checks whether it's in a Docker container and adjusts its 
memory allocation strategy accordingly,
see 
https://www.oracle.com/java/technologies/javase/8u191-relnotes.html#JDK-8146115 
.

If no memory-tuning arguents are passed in and "ulimit -v" is in effect 
(getrlimit(RLIMIT_AS, ...) ),
the JDK should find a memory structure that fits within the available memory, 
or give a friendlier 
error-message if it can't.  

(If -Xms and -Xmx both set, and the initial allocation would succeed but the 
maximum allocation would fail,
maybe Java should print a warning.)


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

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

Versions of packages openjdk-17-jre-headless depends on:
ii  ca-certificates-java  20190909
ii  java-common   0.72
ii  libasound21.2.4-1.1
ii  libc6 2.31-13+deb11u6
ii  libcups2  2.3.3op2-3+deb11u2
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.4+dfsg-1+deb11u1
ii  libgcc-s1 10.2.1-6
ii  libharfbuzz0b 2.7.4-1
ii  libjpeg62-turbo   1:2.0.6-4
ii  liblcms2-22.12~rc1-2
ii  libnss3   2:3.61-1+deb11u3
ii  libpcsclite1  1.9.1-1
ii  libstdc++610.2.1-6
ii  util-linux2.36.1-8+deb11u1
ii  zlib1g1:1.2.11.dfsg-2+deb11u2

openjdk-17-jre-headless recommends no packages.

Versions of packages openjdk-17-jre-headless suggests:
ii  fonts-dejavu-extra2.37-2
pn  fonts-indic   
ii  fonts-ipafont-gothic  00303-21
ii  fonts-ipafont-mincho  00303-21
ii  fonts-wqy-microhei0.2.0-beta-3.1
ii  fonts-wqy-zenhei  0.9.45-8
ii  libnss-mdns   0.14.1-2

-- no debconf information

Bug#1035890: NetworkManager[…]: […] sup-iface[…,0,wlp179s0]: call-p2p-cancel: failed with P2P cancel failed

[Al Ma]

Package: network-manager
Version: 1.30.6-1+deb11u1
While going though the journal log, I found, amoing other weird stuff, that 
P2P, whatever it might be, has failed:
Mai 10 21:01:20 AnonymizedComputerName gnome-session[973]: 
gnome-session-binary[973]: GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error 
== NULL || *error == NULL' failed
Mai 10 21:01:20 AnonymizedComputerName gnome-session[973]: 
gnome-session-binary[973]: GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error 
== NULL || *error == NULL' failed
Mai 10 21:01:20 AnonymizedComputerName gnome-session-binary[973]: 
GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' 
failed
Mai 10 21:01:20 AnonymizedComputerName gnome-session-binary[973]: 
GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' 
failed
Mai 10 21:01:20 AnonymizedComputerName wireplumber[956]: SPA handle 
'api.bluez5.enum.dbus' could not be loaded; is it installed?
Mai 10 21:01:20 AnonymizedComputerName wireplumber[956]: PipeWire's BlueZ SPA 
missing or broken. Bluetooth not supported.
Mai 10 21:01:20 AnonymizedComputerName dbus-daemon[962]: [session uid=119 
pid=962] Successfully activated service 'org.gtk.vfs.UDisks2VolumeMonitor'
Mai 10 21:01:20 AnonymizedComputerName systemd[920]: Started Virtual filesystem 
service - disk device monitor.
Mai 10 21:01:20 AnonymizedComputerName dbus-daemon[962]: [session uid=119 
pid=962] Activating via systemd: service name='org.gtk.vfs.AfcVolumeMonitor' 
unit='gvfs-afc-volume-monitor.service' requested by ':1.3' (uid=119 pid=955 
comm="/usr/libexec/tracker-miner-fs ")
Mai 10 21:01:20 AnonymizedComputerName systemd[920]: Starting Virtual 
filesystem service - Apple File Conduit monitor...
Mai 10 21:01:20 AnonymizedComputerName NetworkManager[779]:  
[1683745280.8952] device (wlp179s0): supplicant interface state: 
internal-starting -> disconnected
Mai 10 21:01:20 AnonymizedComputerName NetworkManager[779]:  
[1683745280.8954] Wi-Fi P2P device controlled by interface wlp179s0 created
Mai 10 21:01:20 AnonymizedComputerName NetworkManager[779]:  
[1683745280.8962] manager: (p2p-dev-wlp179s0): new 802.11 Wi-Fi P2P device 
(/org/freedesktop/NetworkManager/Devices/5)
Mai 10 21:01:20 AnonymizedComputerName NetworkManager[779]:  
[1683745280.8970] device (p2p-dev-wlp179s0): state change: unmanaged -> 
unavailable (reason 'managed', sys-iface-state: 'external')
Mai 10 21:01:20 AnonymizedComputerName NetworkManager[779]:  
[1683745280.8985] device (wlp179s0): state change: unavailable -> disconnected 
(reason 'supplicant-available', sys-iface-state: 'managed')
Mai 10 21:01:20 AnonymizedComputerName NetworkManager[779]:  
[1683745280.9002] device (p2p-dev-wlp179s0): state change: unavailable -> 
disconnected (reason 'none', sys-iface-state: 'managed')
Mai 10 21:01:20 AnonymizedComputerName NetworkManager[779]:  
[1683745280.9007] sup-iface[64aeaff5d52037a3,0,wlp179s0]: call-p2p-cancel: 
failed with P2P cancel failed
The last line is yellow. The output of nmcli says, in red:
p2p-dev-wlp179s0: nicht verbunden
"p2p-dev-wlp179s0"
wifi-p2p, hw
As this is a warning I feel, ergo, warned.  What is it, in plain English, that 
I am warned about?  I use Wi-Fi on wlp179s0 (the connection had its issues, but 
they seem to be mitigated now, so that I can send and receive e-mails such as 
this one) but hate to be warned about non-issues. Or, if the warning shows a 
real issue (about the stuff I'm not using or not knowing to be using), it 
should be fixed.  Any remedy?  Any bugfix?
Gratefully,
AlMa

Bug#1035889: [Pkg-utopia-maintainers] Bug#1035889: nm-dispatcher[…]: /etc/NetworkManager/dispatcher.d/99tlp-rdw-nm: 14: .: cannot open /usr/share/tlp/tlp-func-base: No such file

[Al Ma]

You are right, tlp-rdw was removed but not purged, as it turned out. After 
puring tlp-rdw, the two error messages are gone. Thanks!
Alma

Bug#1034694: gnome-core: Cannot install due to pipewire-audio dependency

[Witold Baryluk]

Package: gnome-core
Followup-For: Bug #1034694
X-Debbugs-Cc: witold.bary...@gmail.com

Hi Jochen.

I am so sorry for wasting your time.

I must have set it very long time ago, probably about a year ago, where I
had some issues with pipewire, and completly forgot this.

Indeed the iso build script has this:

```
# Put some packages on hold, so they are not installed via suggests or 
recommends.
save "${BUILDDIR}/config/hooks/live/0025_hold_bad_packages.hook.chroot" << "EOF"
#!/bin/bash

set -e

apt-mark hold xtrx-dkms
apt-mark hold langford-dkms
# apt-mark hold raspi-firmware  # Do not hold raspi-firmware, as we later want 
to remove it, and this would interfere.
if dpkg -l raspi-firmware; then
  apt-mark purge raspi-firmware || true # Schedule for removal.
fi
# apt-mark hold nvidia-tesla-kernel-support  # Do not install. Something pulls 
this somehow.
apt-mark hold pipewire-alsa
apt-mark hold pipewire-audio
EOF
```




I will fix this on my side.

Thanks a lot for guidance and help!

Please close this issue.


Regards,
Witold

Bug#1035889: [Pkg-utopia-maintainers] Bug#1035889: nm-dispatcher[…]: /etc/NetworkManager/dispatcher.d/99tlp-rdw-nm: 14: .: cannot open /usr/share/tlp/tlp-func-base: No such file

[Michael Biebl]

Control: reassign -1 tlp-rdw
Am 10.05.23 um 20:42 schrieb Al Ma:

Notice two error messages: “cannot open /usr/share/tlp/tlp-func-base: No 
such file” and “failed with Script 
'/etc/NetworkManager/dispatcher.d/99tlp-rdw-nm' exited with error status 
2”.  However, I intentionally uninstalled and purged this package a boot 
or two ago, so tlp-related files should not be searched for.  Any 
remedy, any bugfix?




/etc/NetworkManager/dispatcher.d/99tlp-rdw-nm is not shipped by the 
network-manager but by tlp-rdw


What most likely happened is, that you removed, but not purged the 
tlp-rdw package. Which means, the files in /etc stay around, but the 
files in /usr have been removed.


The best way to fix this if tlp-rdw ships the network-manager hook 
script in /usr/lib/NetworkManager/dispatcher.d/. This way, the hook 
scrip is removed when the package and thus /usr/share/tlp/tlp-func-base 
is removed.

Reassigning accordingly.

Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035889: nm-dispatcher[…]: /etc/NetworkManager/dispatcher.d/99tlp-rdw-nm: 14: .: cannot open /usr/share/tlp/tlp-func-base: No such file

[Al Ma]

Package: network-manager
Version: 1.30.6-1+deb11u1
In my journal jog I find, among other weird stuff, this:
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3651] hostname: hostname: using hostnamed
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3651] hostname: hostname changed from (none) to 
"AnonymizedMachineName"
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3658] dns-mgr[0x55c99fe0b170]: init: dns=default,systemd-resolved 
rc-manager=symlink (auto)
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3670] rfkill0: found Wi-Fi radio killswitch (at 
/sys/devices/pci:b2/:b2:00.0/:b3:00.0/ieee80211/phy0/rfkill0) 
(driver iwlwifi)
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3672] manager[0x55c99fe1a030]: rfkill: Wi-Fi hardware radio set 
enabled
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3672] manager[0x55c99fe1a030]: rfkill: WWAN hardware radio set 
enabled
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3731] Loaded device plugin: NMWwanFactory 
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.30.6/libnm-device-plugin-wwan.so)
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3755] Loaded device plugin: NMTeamFactory 
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.30.6/libnm-device-plugin-team.so)
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3768] Loaded device plugin: NMWifiFactory 
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.30.6/libnm-device-plugin-wifi.so)
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3789] Loaded device plugin: NMBluezManager 
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.30.6/libnm-device-plugin-bluetooth.so)
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3797] Loaded device plugin: NMAtmManager 
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.30.6/libnm-device-plugin-adsl.so)
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3803] manager: rfkill: Wi-Fi enabled by radio killswitch; enabled 
by state file
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3806] manager: rfkill: WWAN enabled by radio killswitch; enabled by 
state file
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3808] manager: Networking is enabled by state file
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3811] dhcp-init: Using DHCP client 'internal'
Mai 10 20:28:27 AnonymizedMachineName dbus-daemon[780]: [system] Activating via 
systemd: service name='org.freedesktop.nm_dispatcher' 
unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.6' (uid=0 
pid=784 comm="/usr/sbin/NetworkManager --no-daemon ")
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3821] settings: Loaded settings plugin: ifupdown 
("/usr/lib/x86_64-linux-gnu/NetworkManager/1.30.6/libnm-settings-plugin-ifupdown.so")
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3822] settings: Loaded settings plugin: keyfile (internal)
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3822] ifupdown: management mode: unmanaged
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3822] ifupdown: interface-parser: parsing file 
/etc/network/interfaces
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3823] ifupdown: interface-parser: source line includes interfaces 
file(s) /etc/network/interfaces.d/*
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3824] ifupdown: interface-parser: parsing file 
/etc/network/interfaces.d/setup
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3824] ifupdown: interface-parser: finished parsing file 
/etc/network/interfaces.d/setup
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3825] ifupdown: interface-parser: finished parsing file 
/etc/network/interfaces
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3832] ifupdown: guessed connection type (enp6s0) = 802-3-ethernet
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3844] ifupdown: guessed connection type (enp7s0) = 802-3-ethernet
Mai 10 20:28:27 AnonymizedMachineName systemd[1]: Starting Network Manager 
Script Dispatcher Service...
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3949] device (lo): carrier: link connected
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3956] manager: (lo): new Generic device 
(/org/freedesktop/NetworkManager/Devices/1)
Mai 10 20:28:27 AnonymizedMachineName dbus-daemon[780]: [system] Successfully 
activated service 'org.freedesktop.nm_dispatcher'
Mai 10 20:28:27 AnonymizedMachineName NetworkManager[784]:  
[1683743307.3984] manager: (enp6s0): new Ethernet device 
(/org/freedesk

Bug#1035888: ITP: dh-builtusing -- debhelper tool generating the Built-Using field for Debian packages

[Nicolas Boulenguez]

Package: wnpp
Severity: wishlist
Owner: Nicolas Boulenguez 
X-Debbugs-Cc: debian-de...@lists.debian.org, 689...@bugs.debian.org, 
990...@bugs.debian.org

* Package name: dh-builtusing
  Upstream: native Debian package, I am the author
  Version : 0.0.1
* URL : https://salsa.debian.org/debian/dh-builtusing
* License : GPL-3+
  Programming Lang: Perl
  Description : debhelper tool generating the Built-Using field for Debian 
packages

This tool may help maintainers of Debian packages by generating parts
of the Built-Using dependencies at build time.
.
It searches the Built-Using and Static-Built-Using fields in a source
control file for substitutions of variables names like
dh-builtusing:x, looks for x in build-dependencies, then defines the
variable with the source package and version for x.
.
In other words, it replaces the call to dpgk-query that each package
or debhelper tool has to duplicate for the Built-Using field.


The dh_builtusing.pod manual page contains a full description.
The log for #689062 contains the original discussion.

Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement

[Diederik de Haas]

Control: reassign -1 src:linux 6.1.25-1
Control: tag -1 upstream
Control: forwarded -1 
https://lore.kernel.org/all/20230127-rpi-cursor-corruption-v2-1-1f97bd00d...@cerno.tech/

On Wednesday, 10 May 2023 19:04:55 CEST James Addison wrote:
> Followup-For: Bug #1035878
> Control: reassign -1 linux-image-6.1.0-8-arm64
> 
> The RPi team suggested that this is likely to be a Linux kernel issue, and
> I've tested an updated v6.1.21 kernel build of theirs (including the likely
> fix[1]) that does resolve the problem.
> 
> [1] -
> https://github.com/raspberrypi/linux/commit/013f247b89b6fa55724cb73a820cadc
> ae745d1ee

It seems it was proposed upstream, but hasn't had any response thus far.

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

Bug#1035887: gnome-session-binary[…]: GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' failed

[Al Ma]

Package: gnome-session-bin
Version: 42.0-1
In the journal log I discovered (among other crazy stuff) this:
Mai 10 16:47:36 AnonymizedComputerName tracker-miner-f[1232]: Unable to get XDG 
user directory path for special directory &DOCUMENTS. Ignoring this location.
Mai 10 16:47:36 AnonymizedComputerName tracker-miner-f[1232]: Unable to get XDG 
user directory path for special directory &MUSIC. Ignoring this location.
Mai 10 16:47:36 AnonymizedComputerName tracker-miner-f[1232]: Unable to get XDG 
user directory path for special directory &PICTURES. Ignoring this location.
Mai 10 16:47:36 AnonymizedComputerName tracker-miner-f[1232]: Unable to get XDG 
user directory path for special directory &VIDEOS. Ignoring this location.
Mai 10 16:47:36 AnonymizedComputerName tracker-miner-f[1232]: Unable to get XDG 
user directory path for special directory &DOWNLOAD. Ignoring this location.
Mai 10 16:47:36 AnonymizedComputerName tracker-miner-f[1232]: Unable to get XDG 
user directory path for special directory &DOCUMENTS. Ignoring this location.
Mai 10 16:47:36 AnonymizedComputerName tracker-miner-f[1232]: Unable to get XDG 
user directory path for special directory &MUSIC. Ignoring this location.
Mai 10 16:47:36 AnonymizedComputerName tracker-miner-f[1232]: Unable to get XDG 
user directory path for special directory &PICTURES. Ignoring this location.
Mai 10 16:47:36 AnonymizedComputerName tracker-miner-f[1232]: Unable to get XDG 
user directory path for special directory &VIDEOS. Ignoring this location.
Mai 10 16:47:36 AnonymizedComputerName rtkit-daemon[1267]: Successfully made 
thread 1229 of process 1229 owned by '119' high priority at nice level -11.
Mai 10 16:47:36 AnonymizedComputerName rtkit-daemon[1267]: Supervising 1 
threads of 1 processes of 1 users.
Mai 10 16:47:36 AnonymizedComputerName dbus-daemon[1236]: [session uid=119 
pid=1236] Activating via systemd: service 
name='org.gtk.vfs.UDisks2VolumeMonitor' 
unit='gvfs-udisks2-volume-monitor.service' requested by ':1.2' (uid=119 
pid=1232 comm="/usr/libexec/tracker-miner-fs ")
Mai 10 16:47:36 AnonymizedComputerName rtkit-daemon[1267]: Successfully made 
thread 1230 of process 1230 owned by '119' high priority at nice level -11.
Mai 10 16:47:36 AnonymizedComputerName rtkit-daemon[1267]: Supervising 2 
threads of 2 processes of 1 users.
Mai 10 16:47:36 AnonymizedComputerName rtkit-daemon[1267]: Supervising 2 
threads of 2 processes of 1 users.
Mai 10 16:47:36 AnonymizedComputerName systemd[1206]: Starting Virtual 
filesystem service - disk device monitor...
Mai 10 16:47:36 AnonymizedComputerName rtkit-daemon[1267]: Supervising 2 
threads of 2 processes of 1 users.
Mai 10 16:47:36 AnonymizedComputerName rtkit-daemon[1267]: Successfully made 
thread 1279 of process 1229 owned by '119' RT at priority 20.
Mai 10 16:47:36 AnonymizedComputerName rtkit-daemon[1267]: Supervising 3 
threads of 2 processes of 1 users.
Mai 10 16:47:36 AnonymizedComputerName wireplumber[1233]: SPA handle 
'api.bluez5.enum.dbus' could not be loaded; is it installed?
Mai 10 16:47:36 AnonymizedComputerName wireplumber[1233]: PipeWire's BlueZ SPA 
missing or broken. Bluetooth not supported.
Mai 10 16:47:36 AnonymizedComputerName gnome-session-binary[1248]: 
GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' 
failed
Mai 10 16:47:36 AnonymizedComputerName gnome-session[1248]: 
gnome-session-binary[1248]: GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error 
== NULL || *error == NULL' failed
Mai 10 16:47:36 AnonymizedComputerName gnome-session[1248]: 
gnome-session-binary[1248]: GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error 
== NULL || *error == NULL' failed
Mai 10 16:47:36 AnonymizedComputerName gnome-session-binary[1248]: 
GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' 
failed
In general, failing assertions are not good.  Besides this and in plain 
English, what does the message “GLib-GIO-CRITICAL: g_bus_get_sync: assertion 
'error == NULL || *error == NULL' failed” tell us?  Who is the culprit and what 
to do?  Versions of the packages outputting into the log just before the error 
occurred:
tracker-miner-fs 2.3.5-2.1, rtkit 0.13-4, dbus 1.12.24-0+deb11u1, systemd 
247.3-7+deb11u2, wireplumber 0.4.2-5, gnome-session-bin 42.0-1, gnome-session 
42.0-1.
(The machine has many issues, which might or might not be related to this. 
Among them, e.g., no sound output in gnome through loudspeakers connected via a 
standard 3-pole 3.5 mm audio jack.)
Gratefully,
AlMa

Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement

[James Addison]

Followup-For: Bug #1035878
Control: reassign -1 linux-image-6.1.0-8-arm64

The RPi team suggested that this is likely to be a Linux kernel issue, and I've
tested an updated v6.1.21 kernel build of theirs (including the likely fix[1])
that does resolve the problem.

[1] - 
https://github.com/raspberrypi/linux/commit/013f247b89b6fa55724cb73a820cadcae745d1ee

Bug#1035886: libopencv-core406: please add Breaks: libopencv-core4.5 (<< 4.6)

[Andreas Beckmann]

Package: libopencv-core406
Version: 4.6.0+dfsg-11
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

while analyzing piuparts bullseye -> bookworm upgrade logs I found
several cases where apt chose a suboptimal solution that involved
keeping some upgradable package at the bullseye version in order to keep
some obsolete library from bullseye installed.
Many of these problematic upgrade paths involve packages from src:opencv
and src:onetbb where the library stacks from bullseye and bookworm are
not co-installable due to long transitive dependency chains.
We can easily hint apt into doing the right thing by adding Breaks
against the highest scoring package from the old library stack to the
highest scoring library from the new library stack, in this case
these are libopencv-core406 in bookworm and libopencv-core4.5 in
bullseye.
Please consider applying the attached patch.


Andreas

PS: a similar change is needed for src:onetbb

PPS: for the curious: apt problemresolver debug output from a randomly
selected opencv binary package (may not be the best example)

...
  Starting 2 pkgProblemResolver with broken count: 2
  Investigating (0) libtbbmalloc2:amd64 < none -> 2021.8.0-1 @un uN Ib >
  Broken libtbbmalloc2:amd64 Breaks on libtbb2:amd64 < 2020.3-1 @ii mK > (< 
2020.3-1ubuntu2)
Considering libtbb2:amd64 2 as a solution to libtbbmalloc2:amd64 1
Holding Back libtbbmalloc2:amd64 rather than change libtbb2:amd64
  Investigating (0) libsemanage1:amd64 < 3.1-1+b2 @ii mK Ib >
  Broken libsemanage1:amd64 Depends on libsemanage-common:amd64 < 3.1-1 -> 
3.4-1 @ii umU > (= 3.1-1)
Considering libsemanage-common:amd64 1 as a solution to libsemanage1:amd64 
-2
Removing libsemanage1:amd64 rather than change libsemanage-common:amd64
  Investigating (1) libtbb12:amd64 < none -> 2021.8.0-1 @un uN Ib >
  Broken libtbb12:amd64 Depends on libtbbmalloc2:amd64 < none | 2021.8.0-1 @un 
uH > (= 2021.8.0-1)
Considering libtbbmalloc2:amd64 1 as a solution to libtbb12:amd64 8
Holding Back libtbb12:amd64 rather than change libtbbmalloc2:amd64
  Investigating (1) libtbb-dev:amd64 < 2020.3-1 -> 2021.8.0-1 @ii umU Ib >
  Broken libtbb-dev:amd64 Depends on libtbb12:amd64 < none | 2021.8.0-1 @un uH 
> (= 2021.8.0-1)
Considering libtbb12:amd64 8 as a solution to libtbb-dev:amd64 2
Holding Back libtbb-dev:amd64 rather than change libtbb12:amd64
  Investigating (2) libopencv-core406:amd64 < none -> 4.6.0+dfsg-11 @un uN Ib >
  Broken libopencv-core406:amd64 Depends on libtbb12:amd64 < none | 2021.8.0-1 
@un uH > (>= 2021.4.0)
Considering libtbb12:amd64 8 as a solution to libopencv-core406:amd64 12
Holding Back libopencv-core406:amd64 rather than change libtbb12:amd64
  Investigating (2) libopencv-imgproc406:amd64 < none -> 4.6.0+dfsg-11 @un uN 
Ib >
  Broken libopencv-imgproc406:amd64 Depends on libopencv-core406:amd64 < none | 
4.6.0+dfsg-11 @un uH > (>= 4.6.0+dfsg)
Considering libopencv-core406:amd64 12 as a solution to 
libopencv-imgproc406:amd64 5
Holding Back libopencv-imgproc406:amd64 rather than change 
libopencv-core406:amd64
  Investigating (2) libopencv-core-dev:amd64 < 4.5.1+dfsg-5 -> 4.6.0+dfsg-11 
@ii umU Ib >
  Broken libopencv-core-dev:amd64 Depends on libopencv-core406:amd64 < none | 
4.6.0+dfsg-11 @un uH > (= 4.6.0+dfsg-11)
Considering libopencv-core406:amd64 12 as a solution to 
libopencv-core-dev:amd64 2
Holding Back libopencv-core-dev:amd64 rather than change 
libopencv-core406:amd64
   Try to Re-Instate (2) libtbb-dev:amd64
  Investigating (2) libopencv-imgproc-dev:amd64 < 4.5.1+dfsg-5 -> 4.6.0+dfsg-11 
@ii umU Ib >
  Broken libopencv-imgproc-dev:amd64 Depends on libopencv-core-dev:amd64 < 
4.5.1+dfsg-5 | 4.6.0+dfsg-11 @ii umH > (= 4.6.0+dfsg-11)
Considering libopencv-core-dev:amd64 2 as a solution to 
libopencv-imgproc-dev:amd64 1
Holding Back libopencv-imgproc-dev:amd64 rather than change 
libopencv-core-dev:amd64
  Investigating (2) libopencv-flann406:amd64 < none -> 4.6.0+dfsg-11 @un uN Ib >
  Broken libopencv-flann406:amd64 Depends on libopencv-core406:amd64 < none | 
4.6.0+dfsg-11 @un uH > (>= 4.6.0+dfsg)
Considering libopencv-core406:amd64 12 as a solution to 
libopencv-flann406:amd64 1
Holding Back libopencv-flann406:amd64 rather than change 
libopencv-core406:amd64
  Investigating (2) libopencv-video406:amd64 < none -> 4.6.0+dfsg-11 @un uN Ib >
  Broken libopencv-video406:amd64 Depends on libopencv-core406:amd64 < none | 
4.6.0+dfsg-11 @un uH > (>= 4.6.0+dfsg)
Considering libopencv-core406:amd64 12 as a solution to 
libopencv-video406:amd64 0
Holding Back libopencv-video406:amd64 rather than change 
libopencv-core406:amd64
  Investigating (2) libopencv-calib3d406:amd64 < none -> 4.6.0+dfsg-11 @un uN 
Ib >
  Broken libopencv-calib3d406:amd64 Depends on libopencv-core406:amd64 < none | 
4.6.0+dfsg-11 @un uH > (>= 4.6.0+dfsg)
Considering libopencv-core406:amd64 12 as a solution to 
libopencv-calib3d40

Bug#1035627: libpcsclite-dev: Multiarch doesn't work for libpcsclite-dev (needed by current wine git)

[Patrick Hibbs]

--no-install-recommends does work. I was able to get both i386 and 
x86_64 versions of libpcsclite-dev installed.


Thanks.

On 5/8/23 12:34, Ludovic Rousseau wrote:

Le 08/05/2023 à 13:27, Patrick Hibbs a écrit :

Hello,

Yes, I have. That works for wine's 64bit build, but wine's 32bit 
build will not recognize it.


I just installed a new Debian 11 (stable) system amd64 with multiarch 
for i386.

I have no problem installing libpcsclite-dev for both amd64 and i386.

$ LANG=C dpkg -l libpcsc*
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---===> 

ii  libpcsclite-dev:amd64 1.9.1-1  amd64    Middleware to 
access a smar>
ii  libpcsclite-dev:i386  1.9.1-1  i386 Middleware to 
access a smar>
ii  libpcsclite1:amd64    1.9.1-1  amd64    Middleware to 
access a smar>
ii  libpcsclite1:i386 1.9.1-1  i386 Middleware to 
access a smar>


I am also able to build a sample PC/SC code for i386 on this system:
$ /usr/bin/i586-linux-gnu-gcc `pkg-config libpcsclite --cflags` 
sample.c  `pkg-config libpcsclite --libs` -o sample


$ file sample
sample: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux.so.2, 
BuildID[sha1]=435a71bbacb507f1e61c30ca3943da130490796c, for GNU/Linux 
3.2.0, not stripped


$ ldd sample
linux-gate.so.1 (0xf7fa2000)
libpcsclite.so.1 => /lib/i386-linux-gnu/libpcsclite.so.1 (0xf7f83000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7d9b000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7d79000)
/lib/ld-linux.so.2 (0xf7fa4000)

I guess the problem is because libpcsclite-dev declares:
Recommends: python3

Use:
$ apt install --no-install-recommends libpcsclite-dev:i386

Bye

Bug#1035885: iwlwifi: api flags index 2 larger than supported by driver

[Al Ma]

Package: firmware-iwlwifi
Version: 20210315-3
In the journal log of a machine with the card
AX3000 Dual Band
PCE-AX3000
Wi-Fi 6 PCI-E Adapter
I see this:
Mai 10 16:47:33 AnonymizedMachineName kernel: RAPL PMU: API unit is 2^-32 
Joules, 1 fixed counters, 655360 ms ovfl timer
Mai 10 16:47:33 AnonymizedMachineName kernel: RAPL PMU: hw unit of domain 
package 2^-14 Joules
Mai 10 16:47:33 AnonymizedMachineName kernel: Intel(R) Wireless WiFi driver for 
Linux
Mai 10 16:47:33 AnonymizedMachineName kernel: iwlwifi :b3:00.0: enabling 
device (0100 -> 0102)
Mai 10 16:47:33 AnonymizedMachineName kernel: cryptd: max_cpu_qlen set to 1000
Mai 10 16:47:33 AnonymizedMachineName kernel: AVX2 version of gcm_enc/dec 
engaged.
Mai 10 16:47:33 AnonymizedMachineName kernel: AES CTR mode by8 optimization 
enabled
Mai 10 16:47:33 AnonymizedMachineName kernel: cx23885: cx23885 driver version 
0.0.4 loaded
Mai 10 16:47:33 AnonymizedMachineName kernel: cx23885 :08:00.0: enabling 
device ( -> 0002)
Mai 10 16:47:33 AnonymizedMachineName kernel: cx23885: CORE cx23885[0]: 
subsystem: 0070:f038, board: Hauppauge WinTV-HVR5525 [card=52,autodetected]
Mai 10 16:47:33 AnonymizedMachineName kernel: iwlwifi :b3:00.0: firmware: 
direct-loading firmware iwlwifi-cc-a0-59.ucode
Mai 10 16:47:33 AnonymizedMachineName kernel: iwlwifi :b3:00.0: api flags 
index 2 larger than supported by driver
Mai 10 16:47:33 AnonymizedMachineName kernel: iwlwifi :b3:00.0: 
TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.22
Mai 10 16:47:33 AnonymizedMachineName kernel: iwlwifi :b3:00.0: loaded 
firmware version 59.601f3a66.0 cc-a0-59.ucode op_mode iwlmvm
Mai 10 16:47:33 AnonymizedMachineName kernel: iwlwifi :b3:00.0: firmware: 
failed to load iwl-debug-yoyo.bin (-2)
Mai 10 16:47:33 AnonymizedMachineName kernel: firmware_class: See 
https://wiki.debian.org/Firmware for information about missing firmware
What does “api flags index 2 larger than supported by driver” tell us?  Is this 
something I should be worried about?  If so, what to do?  I had 
WiFi-connectivity issues in the past, so I wonder whether this could be a 
source of these issues or at least contribute to them.

Bug#1035805: node-source-map: copyright file missing after upgrade (policy 12.5)

[Andreas Beckmann]

Control: tag -1 - moreinfo

On 10/05/2023 17.54, Yadd wrote:
node-source-map depends on libjs-source-map, so the link isn't broken in 
normal installation.


After a fresh installation in bookworm, the link is
  /usr/share/doc/node-source-map -> libjs-source-map
and everything is fine, but after an upgrade from bullseye the link is
  /usr/share/doc/node-source-map -> ../libjs-source-map
which does not work.

node-source-map.maintscript has the corresponding error:

dir_to_symlink /usr/share/doc/node-source-map ../libjs-source-map 
0.7.0++dfsg2+really.0.6.1-9~

Simply reinstalling the package fixes the link (the package
already ships the correct link and dpkg-maintscript-helper does
not touch it again in this case.
So there is no need for a manual cleanup of this mess.

All that needs to be done is an upload with the fixed path
(removing '../') in node-source-map.maintscript.


Andreas

Bug#886087: alarm-clock-applet: raising severity of gconf dependency bug

[Bastian Germann]

Control: tags -1 - bullseye buster sid

alarm-clock-applet is the last package dependending on gconf.
Please consider building without gconf after bookworm is released.

Bug#1035854: Bookworm netboot image fails in VM

[Cyril Brulebois]

Samuel Thibault  (2023-05-10):
> I usually test the netinst image. I'm surprised that netboot use more
> memory, since it's supposed to fetch only what it really needs. And PXE
> is supposed not to change much since in the end it's supposed to be the
> same vmlinuz/initrd as non-pxe.

Oh right, I meant to include some disclaimer about my not knowing anything
about the inner workings of PXE/TFTP-booting, and my not being able to
judge whether it is possible/plausible this could be a factor here.

Given my todo list until Bookworm, it seems unlikely I'll be able to play
with that in the upcoming weeks. Knowing the installer works when bumping
the VM's memory is kind of reassuring at least: it's not completely broken
when started this way.


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


signature.asc
Description: PGP signature

Bug#1035854: Bookworm netboot image fails in VM

[Samuel Thibault]

Cyril Brulebois, le mer. 10 mai 2023 17:34:53 +0200, a ecrit:
> Moritz Muehlenhoff  (2023-05-10):
> > This turned out to be redux of #932149: Bumping the memory of the
> > netboot-installed VM to 1536M RAM fixed it. There was anectotal
> > evidence of non-netboot installations still succeeding with 1024M, so
> > should we reassign to installation-guide to bump the documented
> > minimum RAM at least for netboot?
> 
> Both netboot and netboot-gtk's mini.iso, booted as a CD, are just fine
> with 1G RAM (modulo cryptsetup OOMKs for a little while, #1028250), and
> have been for years. That's how all my VM testing has been done for
> years. :)
> 
> If numbers are updated for netboot, maybe make it clear it's for PXE
> booting?
> 
> > When debugging the issue is also noticed that
> > rootskel/src/lib/debian-installer/menu currently checks how much RAM
> > is present and if it's less than 250M it exports
> > DEBCONF_DROP_TRANSLATIONS=1 to cdebconf.
> > 
> > Given that we already document 780MB as the minimum requirement for
> > Bullseye that seems obsolete, happy to create MRs to remove it from
> > rootskel and cdebconf to clean this up.
> 
> Looping in Samuel who has been bumping requirements on a regular basis,
> and who is likely to have good ideas in this area.

I usually test the netinst image. I'm surprised that netboot use more
memory, since it's supposed to fetch only what it really needs. And PXE
is supposed not to change much since in the end it's supposed to be the
same vmlinuz/initrd as non-pxe.

I didn't know about rootskel setting DEBCONF_DROP_TRANSLATIONS, that
should probably be coordinated with lowmem's management of low-memory
heuristics.

And at any rate, 1536M RAM looks really a *lot* to me, it really looks to
me like some bug somewhere.

Samuel

Bug#1035805: node-source-map: copyright file missing after upgrade (policy 12.5)

[Yadd]

Control: tags -1 + moreinfo

On 5/9/23 16:13, Andreas Beckmann wrote:

Package: node-source-map
Version: 0.7.0++dfsg2+really.0.6.1-13
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

a test with piuparts revealed that your package misses the copyright
file after an upgrade, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.

This was observed on the following upgrade paths:

   bullseye -> bookworm

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

0m39.3s ERROR: WARN: Inadequate results from running adequate!
   node-source-map: broken-symlink /usr/share/doc/node-source-map -> 
../libjs-source-map
   node-source-map: missing-copyright-file 
/usr/share/doc/node-source-map/copyright


Hi,

node-source-map depends on libjs-source-map, so the link isn't broken in 
normal installation.


Regards,
Yadd


   MISSING COPYRIGHT FILE: /usr/share/doc/node-source-map/copyright
   # ls -lad /usr/share/doc/node-source-map
   lrwxrwxrwx 1 root root 19 May  3 22:16 /usr/share/doc/node-source-map -> 
../libjs-source-map
   # ls -la /usr/share/doc/node-source-map/
   ls: cannot access '/usr/share/doc/node-source-map/': No such file or 
directory


Additional info may be available here:
https://wiki.debian.org/MissingCopyrightFile

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


cheers,

Andreas

Bug#1031410: Closing p-u requests for fixes included in 11.7

[Stephan Großberndt]

Hi,

after further investigation this looks more like a bug in the backport.

At first I thought the change was about flipping x and y for all 
coordinate systems except those containing "lat/lon", which did not make 
much sense to me, but I would have been willing to accept this.


But apparently this flip is only in this PostGIS 3.1.1+dfsg-1+deb11u1 
version, earlier and later PostGIS versions correctly return x as x and 
y as y.


For this query:

SELECT 
ST_AsGeoJSON(ST_Transform(ST_SetSRID('010120110F04F0844A1349264120ED527FE9DD5841'::geometry, 
3857), 31466));


the following versions correctly return x=2539841,y=5586869:

- PostgresQL 11 with PostGIS 2.5.1+dfsg-1 from Debian Sources
- PostgresQL 11 with PostGIS 2.5.5+dfsg-1.pgdg100+2 from PostgreSQL Sources
- PostgresQL 13 with PostGIS 3.1.1+dfsg-1 from Debian Sources
- PostgresQL 13 with PostGIS 3.3.2+dfsg-1.pgdg110+1 from Debian Sources


Only

- PostgresQL 13 with PostGIS 3.1.1+dfsg-1+deb11u1 from Debian Sources

incorrectly returns x=5586869,y=2539841

Should I file another bug report for this?

Regards,
Stephan Großberndt

Bug#1035781: emacs-common: needs Breaks against incompatible elpa packages from bullseye

[Andreas Beckmann]

On 10/05/2023 03.22, Rob Browning wrote:

Right, I'm actually working on a release for this.  I think I should be
able to upload today or tomorrow, and not sure if we need to wait for
preapproval aince we'd want this in any other future migrations from


I don't think there is need for pre-approval as long as there are only 
targeted fixes.



Andreas

Bug#1034941: emacs-common: missing Breaks+Replaces for emacs-bin-common when upgrading from bullseye

[Andreas Beckmann]

Followup-For: Bug #1034941
Control: tag -1 patch

I attach the patch that I used for testing emacs bullseye->bookworm
upgrade paths in order to find additional packages requiring Breaks
(#1035781).


Andreas
>From 0aaea9d208ffc82cd279e4ce7c13ee282e52705d Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Wed, 10 May 2023 17:25:04 +0200
Subject: [PATCH] emacs-common: Add Breaks+Replaces: emacs-bin-common (<< 1:28)

Closes: #1034941
---
 debian/control | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/control b/debian/control
index 6f038e735b5..d4df3906221 100644
--- a/debian/control
+++ b/debian/control
@@ -160,6 +160,9 @@ Breaks:
  emacs25,
  emacs25-lucid,
  emacs25-nox,
+ emacs-bin-common (<< 1:28),
+Replaces:
+ emacs-bin-common (<< 1:28),
 Description: GNU Emacs editor's shared, architecture independent infrastructure
  GNU Emacs is the extensible self-documenting text editor.
  This package contains the architecture independent infrastructure
-- 
2.20.1

Bug#1035781: emacs-common: needs Breaks against incompatible elpa packages from bullseye

[Andreas Beckmann]

Control: tag -1 patch

On 10/05/2023 03.22, Rob Browning wrote:

Andreas Beckmann  writes:


There are some elpa packages from bullseye that won't be in bookworm and
that are incompatible with emacs 28, i.e. upgrading emacs will fail if
these packages are still installed.
Therefore emacs-common needs to add Breaks against them s.t. they get
removed during the upgrade to bookworm.


Right, I'm actually working on a release for this.  I think I should be
able to upload today or tomorrow, and not sure if we need to wait for
preapproval aince we'd want this in any other future migrations from
unstable to testing/bullseye.


Actually there seems to be only one package needing a Breaks: elpa-cider
All other failures have cleared after I tested with a fixed emacs-common.

For bookworm+1 we should consider cleaning up the list of 
Breaks/Replaces. Everything that has been part of 2 (or more) stable 
releases can go away (I prefer to keep B+R for 2 stable releases to 
simplify backporting)



AndreasFrom ef142e9800abceda3382146e0dfc018c41c6813c Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Wed, 10 May 2023 17:27:31 +0200
Subject: [PATCH] Add Breaks against known incompatible package elpa-cider

Closes: #1035781
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index d4df3906221..a9a1b3d45e3 100644
--- a/debian/control
+++ b/debian/control
@@ -142,6 +142,7 @@ Breaks:
  apel (<< 10.8+0.20120427-4),
  edb (<< 1.32),
  egg (<< 4.2.0-2),
+ elpa-cider (<< 0.19.0+dfsg-4~),
  emacs (<< 1:25),
  emacs-gtk (<< 1:25),
  emacs-lucid (<< 1:25),
-- 
2.20.1

Bug#1035854: Bookworm netboot image fails in VM

[Cyril Brulebois]

Moritz Muehlenhoff  (2023-05-10):
> This turned out to be redux of #932149: Bumping the memory of the
> netboot-installed VM to 1536M RAM fixed it. There was anectotal
> evidence of non-netboot installations still succeeding with 1024M, so
> should we reassign to installation-guide to bump the documented
> minimum RAM at least for netboot?

Both netboot and netboot-gtk's mini.iso, booted as a CD, are just fine
with 1G RAM (modulo cryptsetup OOMKs for a little while, #1028250), and
have been for years. That's how all my VM testing has been done for
years. :)

If numbers are updated for netboot, maybe make it clear it's for PXE
booting?

> When debugging the issue is also noticed that
> rootskel/src/lib/debian-installer/menu currently checks how much RAM
> is present and if it's less than 250M it exports
> DEBCONF_DROP_TRANSLATIONS=1 to cdebconf.
> 
> Given that we already document 780MB as the minimum requirement for
> Bullseye that seems obsolete, happy to create MRs to remove it from
> rootskel and cdebconf to clean this up.

Looping in Samuel who has been bumping requirements on a regular basis,
and who is likely to have good ideas in this area.


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


signature.asc
Description: PGP signature

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

[Axel Beckert]

Control: tag -1 + patch pending

Hi Andreas,

Axel Beckert wrote:
> Looking through upstream's commits, I suspect cherrypicking this
> upstream commit might fix it:
> 
> https://github.com/aabc/ipt-netflow/commit/0901f028617acca350132a65293ab80a480bf233

Yep, cherry-picking that one fixed it. Looks like  a regression
introduced by 6a55739a ("Fix build on v5.15 (ct_event)") which I
cherry-picked in 2.6-3.

So thanks again for the report. Upload should happen in the next few
hours.

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

Bug#1034771: simple-cdd: generate_firmware_patterns failed: 512 at ./tmp/debian-cd/tools/make_disc_trees.pl line 1257

[wieser]

It works after you copy Components-amd64.yml.gz ( wget 
https://debian.mirror.ate.info/dists/bookworm/main/dep11/Components-amd64.yml.gz) 
to the folder mirror/dists/bullseye/main/dep11/

Bug#1035757: unblock: org-mode/9.5.2+dfsh-5

[Sean Whitton]

control: tag -1 - moreinfo

Hello,

Thanks for looking.

On Mon 08 May 2023 at 09:33PM +02, Paul Gevers wrote:

> What's the plan for the future? Is this a one-off exercise or do you
> intent to pull this trick more often?

We don't have a real plan for the future, aside from trying to keep
these packages up-to-date.  It would be good to have a script that we
could run right after uploading new versions of Emacs, that would find
addons that are now behind.
So, we'd like it to be one-off, but due to limited manpower on the team,
I can't pretend that it couldn't happen again.

Ultimately I think that the correct fix is for Emacs to learn to load
the version of the package that has the highest version number.
So, I think this is, at bottom, an upstream limitation.  But I might be
wrong about that.

> IIRC other ecosystems (like ruby) have the main package also
> (versioned) Provides these add-ons, such that when packages Depend on
> it, the main package can provide it without needing the add-on. That
> way, you could prevent shipping the package in a stable release when
> it's behind and have a newer version if it's available. Has such a
> scheme been considered? If yes, what's the drawback?

We haven't considered it.  It would be a case of writing a script to
generate the required Provides values from the Emacs source.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1035884: maven-debian-helper: mh_make cannot resolve parent POM when `${revision}` is used

[Stanislav Dimov]

Package: maven-debian-helper
X-Debbugs-Cc: stanislav.vdi...@gmail.com
Version: 2.6
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 I tried to create a deb package for a maven project I am working on
using
`mh_make`.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I invoked `mh_make` and started filling in the required information.
When
I got to the module resolution I was greeted by an error:

```
Analysing model/pom.xml...
May 10, 2023 3:33:12 PM org.debian.maven.packager.DependenciesSolver
resolveDependencies
SEVERE: Error while resolving ./model/pom.xml: Dependency not found
com.mycompany.proj:project_name:pom:${revision}
May 10, 2023 3:33:12 PM org.debian.maven.packager.DependenciesSolver
resolveDependencies
SEVERE:
org.debian.maven.repo.DependencyNotFoundException: Dependency not found
com.mycompany.proj:project_name:pom:${revision}
at org.debian.maven.repo.Repository.registerPom(Repository.java:419)
at
org.debian.maven.packager.DependenciesSolver.resolveDependencies(DependenciesSolver.java:320)
at
org.debian.maven.packager.DependenciesSolver.resolveDependencies(DependenciesSolver.java:420)
at
org.debian.maven.packager.DependenciesSolver.solveDependencies(DependenciesSolver.java:260)
at
org.debian.maven.packager.DependenciesSolver.main(DependenciesSolver.java:922)
```

The way it is set up is that all subprojects use the `${revision}`
placeholder
to resolve the parent POM's version. I believe this was introduced in maven
3.5.
The project builds normally when `mvn package` is invoked.

   * What was the outcome of this action?
   `mh_make` crashed

   * What outcome did you expect instead?
   `mh_make` to resolve the dependency with the parent pom and continue with
the setup.


-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500,
'jammy'), (100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages maven-debian-helper depends on:
ii  default-jdk 2:1.11-72build2
ii  default-jdk-headless2:1.11-72build2
ii  libmaven-clean-plugin-java  3.1.0-1
ii  libmaven-compiler-plugin-java   3.8.1-4
ii  libmaven-jar-plugin-java3.1.2-1
ii  libmaven-resources-plugin-java  3.1.0-1
ii  libmaven-site-plugin-java   3.6-4
ii  libplexus-velocity-java 1.2-3.1
ii  libsurefire-java2.22.3-1
ii  libxml2-utils   2.9.13+dfsg-1ubuntu0.3
ii  maven   3.6.3-5
ii  maven-repo-helper   1.10
ii  unzip   6.0-26ubuntu3.1
ii  velocity1.7-6

maven-debian-helper recommends no packages.

Versions of packages maven-debian-helper suggests:
ii  apt-file  3.2.2
ii  libmaven-javadoc-plugin-java  3.0.1-4
ii  licensecheck  3.2.14-2
pn  subversion

-- no debconf information

Bug#1035854: Bookworm netboot image fails in VM

[Moritz Muehlenhoff]

On Wed, May 10, 2023 at 11:35:14AM +0200, Cyril Brulebois wrote:
> Hallo Moritz,
> 
> And thanks for the report…
> 
> Moritz Mühlenhoff  (2023-05-10):
> > Moritz Muehlenhoff wrote:
> > > call. $MENU is set to '/usr/bin/main-menu' and in fact running
> > > 
> > > "debconf -o d-i /usr/bin/main-menu" tries to emit some output (I can see 
> > > the cursor
> > > moving), but drops back to the shell right away.
> > > 
> > > I'm not familiar with cdebconf, if there's some suggested steps to narrow 
> > > down the
> > > failure further, I'm happy to try them.
> > 
> > Looking at dmesg, there's actually a log entry about steal-ctty segfaulting:
> > 
> > [1.945968] steal-ctty[139]: segfault at 0 ip 7f3c073b9fa0 sp 
> > 7fff38 0)b70 error 4 in libc.so.6[7f3c0730b000+155000] likely on CPU 0 
> > (core 0, socket
> > [1.946977] Code: 2e 04 00 0f 1f 80 00 00 00 00 55 48 89 e5 41 57 41 56 
> > 41 5f 84 47 01 00 00 49 89 f4 be 2f 00 00 00 48 89 fb 49 89 45 c8 31 c0 
> > <80> 3f 00 0f
> 
> … and that follow-up. For those not following IRC, I'm wondering whether
> this could be a redux of #932149; that'd be consistent with PXE-booting
> being successful on baremetal, but not with a 1G VM. Moritz will try
> bumping that and will let us know later on.

This turned out to be redux of #932149: Bumping the memory of the 
netboot-installed
VM to 1536M RAM fixed it. There was anectotal evidence of non-netboot 
installations
still succeeding with 1024M, so should we reassign to installation-guide to 
bump the
documented minimum RAM at least for netboot?

When debugging the issue is also noticed that 
rootskel/src/lib/debian-installer/menu
currently checks how much RAM is present and if it's less than 250M it exports
DEBCONF_DROP_TRANSLATIONS=1 to cdebconf.

Given that we already document 780MB as the minimum requirement for Bullseye 
that
seems obsolete, happy to create MRs to remove it from rootskel and cdebconf to 
clean
this up.

Cheers,
Moritz

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

[Axel Beckert]

Hi Andreas,

Andreas Beckmann wrote:
> On 10/05/2023 16.32, Axel Beckert wrote:
> > BUILD_EXCLUSIVE_* would be my currently slightly preferred approach as
> > it's likely much simpler to implement and its impact is more clear,
> > but not necessarily "smaller". Currently trying to figure out how it
> > actually works.
> 
> its a regex, like (untested):
> # 6.1+
> BUILD_EXCLUSIVE_KERNEL="([7-9]|6\.[1-9]|6\.[1-9][0-9])\..*"

Thanks for the prompt and helpful reply!

> > > this will be easier from bookworm+1 onwards).
> > 
> > Ok. Well, I'll see.
> 
> BUILD_EXCLUSIVE_KERNEL_MIN="6.1"

Indeed easier. :-)

> My preference would be to fix the module to build with the bullseye
> kernel,

Thanks for that comment as well.

> Whenever that breaks again after an update to the kernel in
> bullseye, it probably breaks the module in bullseye, too.

Chances are there, but at least this breakage doesn't seem to have
happend in Bullseye.

Looking through upstream's commits, I suspect cherrypicking this
upstream commit might fix it:

https://github.com/aabc/ipt-netflow/commit/0901f028617acca350132a65293ab80a480bf233

commit 0901f028617acca350132a65293ab80a480bf233
Author: Vadim Fedorenko 
Date:   Mon Mar 28 21:59:10 2022 +0300

fix building on old kernels

Link: https://github.com/aabc/ipt-netflow/pull/196

diff --git a/compat.h b/compat.h
index 6be9d6b..847117f 100644
--- a/compat.h
+++ b/compat.h
@@ -782,7 +782,14 @@ struct module *find_module(const char *name)
 #endif
 
 #ifndef HAVE_NF_CT_EVENT_NOTIFIER_CT_EVENT
+/*
+ * nat event callback parameter is constified in 5.15+
+ * but it prevents module building with previous kernel versions
+ */
+# define NF_CT_EVENT struct nf_ct_event
 # define ct_event fcn
+#else
+# define NF_CT_EVENT const struct nf_ct_event
 #endif
 
 #endif /* COMPAT_NETFLOW_H */
diff --git a/ipt_NETFLOW.c b/ipt_NETFLOW.c
index e042fe6..82805bc 100644
--- a/ipt_NETFLOW.c
+++ b/ipt_NETFLOW.c
@@ -4597,7 +4597,7 @@ static void rate_timer_calc(
 #ifdef CONFIG_NF_NAT_NEEDED
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,31)
 static struct nf_ct_event_notifier *saved_event_cb __read_mostly = NULL;
-static int netflow_conntrack_event(const unsigned int events, const struct 
nf_ct_event *item)
+static int netflow_conntrack_event(const unsigned int events, NF_CT_EVENT 
*item)
 #else
 static int netflow_conntrack_event(struct notifier_block *this, unsigned long 
events, void *ptr)
 #endif

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

Bug#1035883: general: TMOUT and autologout are set to 3600, but logout occurs much earlier

[Jim Anderson]

Package: general
Severity: minor

Dear Maintainer,

This bug report is a rather minor issue, but it is an inconvenience for me.

I realize that auto logout is a general security feature, but in my
case, I have a secrure environment where only my wife and I have access to
my computer. I strong prefer to NOT have my computer auto logout for 10 hours,
allowing me to leave my computer in the evening and return to it in the
morning without haveing to log on.

I have the enrivonment variables TMOUT and autologout both set to 36000,
or 10 hours, but these are not honored by the system.

Thank you.

Jim Anderson


-- System Information:
Distributor ID: Bunsenlabs
Description:BunsenLabs GNU/Linux 10.5 (Lithium)
Release:10.5
Codename:   buster
Architecture: x86_64

Kernel: Linux 4.19.0-23-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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

[Andreas Beckmann]

On 10/05/2023 16.32, Axel Beckert wrote:

BUILD_EXCLUSIVE_* would be my currently slightly preferred approach as
it's likely much simpler to implement and its impact is more clear,
but not necessarily "smaller". Currently trying to figure out how it
actually works.


its a regex, like (untested):
# 6.1+
BUILD_EXCLUSIVE_KERNEL="([7-9]|6\.[1-9]|6\.[1-9][0-9])\..*"


this will be easier from bookworm+1 onwards).


Ok. Well, I'll see.


BUILD_EXCLUSIVE_KERNEL_MIN="6.1"


My preference would be to fix the module to build with the bullseye 
kernel, too. Whenever that breaks again after an update to the kernel in 
bullseye, it probably breaks the module in bullseye, too.



Andreas

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

[Axel Beckert]

Hi Andreas,

thanks for the bug report. Actually I do have a Bookworm system
already running with iptables-netflow-dkms, but it was a fresh
installation on new hardware.

Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'bullseye'.
> It installed fine in 'bullseye' (with linux-headers-amd64
> installed),

Just for clarification: "It" means that the version from bullseye
installed fine on bullseye. From the log you attached:

  Unpacking iptables-netflow-dkms (2.6-3.1) over (2.5.1-2) ...

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

This is probably because of some backported fixes to kernel security
updates in bullseye which ipt_NETFLOW upstream didn't expect to
already see in that seemingly older kernel version. Happened in the
past and will likely happen again over time. :-/

Generally I see two ways to fix this, with both having pros and cons:

* Restrict module to kernel ≥ 6.1. Disadvantage: Will refuse to work
  with older, locally compiled kernels even if it would work.

  Advantage: Will still work for late upgrades even if the Bullseye
  kernel gets another backported fix which then will make the upgrade
  fail in the same way again.

* Fix the build by probably updating versions in some of the #ifdefs
  in the code which try to decide on the right kernel API.

  Advantage: Will also work for those who need older kernels (even if
  only for a while).

  Disadvantage: Might break again on future backported kernel fixes in
  Bullseye.

> As during the upgrade phase it is very likely that both the old and new
> kernel and their headers are installed, the dkms module should be able
> to build for both kernel versions (or use some BUILD_EXCLUSIVE_*
> settings to exclude unsupported versions,

BUILD_EXCLUSIVE_* would be my currently slightly preferred approach as
it's likely much simpler to implement and its impact is more clear,
but not necessarily "smaller". Currently trying to figure out how it
actually works.

> this will be easier from bookworm+1 onwards).

Ok. Well, I'll see.

> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: In function 'nf_seq_show':
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:762:39: warning: format 
> '%lu' expects argument of type 'long unsigned int', but argument 3 has type 
> 's64' {aka 'long long int'} [-Wformat=]
>   762 |seq_printf(seq, " Flows selected %lu, discarded %lu.",
>   | ~~^
>   |   |
>   |   long unsigned int
>   | %llu
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:762:54: warning: format 
> '%lu' expects argument of type 'long unsigned int', but argument 4 has type 
> 's64' {aka 'long long int'} [-Wformat=]
>   762 |seq_printf(seq, " Flows selected %lu, discarded %lu.",
>   |~~^
>   |  |
>   |  long unsigned int
>   |%llu
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:766:39: warning: format 
> '%lu' expects argument of type 'long unsigned int', but argument 3 has type 
> 's64' {aka 'long long int'} [-Wformat=]
>   766 |seq_printf(seq, " Flows selected %lu.", 
> atomic64_read(&flows_selected));
>   | ~~^
>   |   |
>   |   long unsigned int
>   | %llu

At least these warnings look familiar. I think I also saw them when I
tried to compile it against kernel 6.3.1 in experimental (which also
failed).

Anyway, working on it now. Not yet sure which way I'll go, but
restricting it to only Bookworm's kernel (or newer) seems to be the
safest way to reduce the amount of fallout with older kernels as well
as the probably easier way.

(I deliberately didn't write "with less impact" as the impact IMHO
isn't comparable that well: It either _immediately_ affects quite a
large set of non-bookworm kernels, or it _may_ affect some future
kernels at some point in the future and _might_ cause a very similar
issue for late upgraders again. Not sure if any of that makes any of
the two solutions "the better one", but

Bug#1035882: nmu: pvpgn_1.8.5-3

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 1034224 by -1

nmu pvpgn_1.8.5-3 . ANY . unstable . -m "Rebuild with fixed debhelper 
installing pvpgn.service to the correct place"


Files in second .deb but not in first
-
-rw-r--r--  root/root   /lib/systemd/system/pvpgn.service
-rwxr-xr-x  root/root   DEBIAN/preinst

Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/lib/systemd/system/pvpgn.service


See #1034224 for background.

Bug#986821: freecad: Garbled menu makes freecad unusable

[Werner Mayer]

Hi tobi,


It is still garbled when running it with QT_SCALE_FACTOR=0.9

Setting a value < 1 doesn't only cause problems with FreeCAD but with
other Qt applications, too.

For example, Qt Designer's user interface is completely garbled, not
only the menus. For other Qt based applications (assistant, linguist,
cmake-gui, vlc) it doesn't look much better.

So, there are two causes to get a garbled user interface:

* Changing the DPI value of the system. This is fixed with the
suggestion of my last mail.
Alternatively, this can be tested by setting the environment variable
QT_FONT_DPI (e.g. QT_FONT_DPI=80)

* Setting a value < 1 for QT_SCALE_FACTOR. This is not specific to
FreeCAD but is a general Qt issue that affects many other applications.

BR,
Werner

Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement

[James Addison]

Followup-For: Bug #1035878
Control: forwarded -1 https://github.com/raspberrypi/linux/issues/5462

Bug#1035880: radeon: radeon driver only partial support of pipelines

[Christian Kiss]

Package: firmware-amd-graphics
Version: 20210315-3
Severity: normal
File: radeon
Tags: upstream
X-Debbugs-Cc: christianpeterk...@yahoo.com

Dear Maintainer,


kernel.log reports that radeon: 1 quad pipes, 2 z pipes initialized.
the gpu an rv530 has atleast double to 4 of these each.

the rudimentary partial support of the hardware features includes oddity clock
at
85.5Mhz

instead 500 / 1100ram

while the bit width 128seems to becorrect


additionally to this the realtime kernel scheduling seems to break the gpu/ non
optimised coordination cpu gpu scheduling of cpucycles


allthebest
Christian Kiss




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

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

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


-- System Information:
Debian Release: 11.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'proposed-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-22-rt-686-pae (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.140

Bug#1035879: unblock: mozjs102/102.10.0-1

[Jeremy Bícha]

Package: release.debian.org
Control: affects -1 + src:mozjs102
X-Debbugs-Cc: mozjs...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mozjs102 and reduce the days required to reach Testing.

[ Reason ]
The new mozjs102 stable point release includes multiple security fixes.

- CVE-2023-32211: Content process crash due to invalid wasm code
- CVE-2023-32215: Memory safety bugs

I included more in debian/changelog but those affected Firefox ESR,
not mozjs specifically. Sorry.

[ Impact ]
mozjs102 is only used by gjs which in turn is used by GNOME Shell and
several GNOME apps written in JavaScript.

[ Tests ]
The build tests have passed successfully and the gjs autopkgtests
triggered by this upload have passed too. (mozjs102 itself
does not have autopkgtests yet).

I also completed the manual test cases from
https://wiki.ubuntu.com/DesktopTeam/TestPlans/gjs
on Debian Testing.

[ Risks ]

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

[ Other info ]
mozjs102 is the SpiderMonkey JavaScript engine from the current
Firefox ESR stable branch. There are monthly releases until the end of August.

https://whattrainisitnow.com/calendar/

I am unaware of anyone using Firefox vulnerabilities to attack GNOME
Shell, but I think it's good to be prudent and apply available
security updates. I don't think the Debian Security Team has done
security uploads for mozjs*, in part because Mozilla's lifecycle is so
short that it's difficult for an upstream supported mozjs to be in a
Debian stable release.

For more info about the commits, see the Github mirror:
https://github.com/mozilla/gecko-dev/commits/esr102/js

unblock mozjs102/102.11.0-1

Thank you,
Jeremy Bicha


mozjs-102.11.debdiff
Description: Binary data

Bug#1035878: rpi400: visual speckling on 'faulty' HDMI port during mouse movement

[James Addison]

Package: raspi-firmware
Severity: normal

Dear Maintainer,

I've installed a RPi 400 system using a regular build of Debian Installer
(bookworm RC2), and have begun using the official RPi firmware (as distributed
in the 'raspi-firmware' bookworm package - including bootcode.bin) to start the
the kernel.

During an X-based LXDE session, I see visual 'speckling' (static-like noise
that blits across the lower half-or-so of the display, mostly with dark
greenish and dark bluish pixels) when moving the mouse pointer.


NOTE: There are _two_ micro-HDMI ports on the RPi 400.  This problem only
occurs when the HDMI cable is connected to the port closest to the keyboard
indicator lights (capslock, numlock).  The problem _does not_ occur when the
HDMI cable is connected to the port closest to the USB-C power supply port.


Repro details:

Moving the pointer through particular areas of the display seem to cause the
flickering/speckling more repeatably.  The lower 40-or-so pixels of the screen
in particular (where the LXDE menubar appears by defaul) seems to be a boundary
that causes the problem fairly reliably.

Note that when pointer/cursor movement _stops_, the visual corruption also
stops occurring.  In other words: the condition appears on-screen temporarily
during the mouse pointer movement.


Additional details:

  * The system is running Debian kernel 6.1.0-8 from linux-image-arm64
6.1.25-1

  * The problem is also replicable using the latest '*.{elf,dat,bin}' files
from the upstream raspberrypi/firmware version 1.20230405 release.

  * The devicetree 'compatible' entry for the gpu is:

  $ cat /proc/device-tree/gpu/compatible
  brcm,bcm2711-vc5

  * The vc4 video driver appears to initialize fine according to dmesg (I don't
see any errors).

  * The vc4 driver is in use as a framebuffer device, I think.

  $ dmesg --notime | grep -i vc4 | tail -n 2
  [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 1
  vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device

  * I've attempted to use the 'config_hdmi_boost'[1] setting from the upstream
firmware to resolve the problem, since it mentions speckling (in fact, it's
where I learned the term 'speckling') specifically, but this has not had
any effect.  The documentation there does mention that the option is
ignored on RPi4, and it seems possible that that may also apply to RPi400.

  * Reducing the resolution of the desktop does not reduce or eliminate the
speckling.


Thank you for any help / suggestions,
James

[1] - 
https://www.raspberrypi.com/documentation/computers/config_txt.html#config_hdmi_boost

Bug#1035877: webkit2gtk-driver: Encryption based porting error to non-sse2 systems fail website processes

[Christian Kiss]

Package: webkit2gtk-driver
Version: 2.40.1-1~deb11u1
Severity: normal
Tags: ipv6, ported versions
X-Debbugs-Cc: christianpeterk...@yahoo.com

Dear Maintainer,

specific websites do not work around encryption like password generation in
yahoo or gmx login cookiesettings on.

It is an overexcerted cpu on webkit but in firefox-esr these processes work.

Webkit seems quicker leaner but has likely a porting version error or
insufficiency in this specific part
which makes it useless to main websites common websites

allthebest
Christian Kiss



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

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

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


-- System Information:
Debian Release: 11.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'proposed-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-22-rt-686-pae (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages webkit2gtk-driver depends on:
ii  libc6 2.31-13+deb11u6
ii  libgcc-s1 10.2.1-6
ii  libglib2.0-0  2.66.8-1
ii  libicu67  67.1-7
ii  libsoup2.4-1  2.72.0-2
ii  libstdc++610.2.1-6
ii  libsystemd0   247.3-7+deb11u2
ii  libwebkit2gtk-4.0-37  2.40.1-1~deb11u1

webkit2gtk-driver recommends no packages.

webkit2gtk-driver suggests no packages.

Bug#1020237: pokerth-data: depends on gsfonts-x11 should be replaced by fonts-urw-base35

[Andreas Beckmann]

Followup-For: Bug #1020237
Control: severity -1 serious
Control: tag -1 sid bookworm

Raising the severity since there are some broken symlinks aka missing
fonts with the transitional gsfonts-x11 package (which does not have the
"numerical" font names):

0m22.1s ERROR: FAIL: Broken symlinks:
  /usr/share/games/pokerth/fonts/c059013l.pfb -> 
../../../fonts/X11/Type1/c059013l.pfb (pokerth-data)
  /usr/share/games/pokerth/fonts/n019003l.pfb -> 
../../../fonts/X11/Type1/n019003l.pfb (pokerth-data)


Andreas

Bug#1031410: Closing p-u requests for fixes included in 11.7

[Stephan Großberndt]

Hi,

at our company we were quite surprised by this seemingly minor update 
3.1.1+dfsg-1+deb11u1, because it completely broke an application: Due to 
the change the x and y axis are now inverted when converting coordinates 
to EPSG 31466:


Before (this output is from 11.19, but was like this on 13 before as well):

SELECT geometry,ST_AsGeoJSON(ST_Transform(ST_SetSRID(geometry, 3857), 
31466)) FROM osm_car_sharing_node LIMIT 1;
  geometry  | 
 st_asgeojson

+
 010120110F04F0844A1349264120ED527FE9DD5841 | 
{"type":"Point","coordinates":[2539841.86185744,5586869.51937972]}

(1 row)


Now:

SELECT geometry, ST_AsGeoJSON(ST_Transform(ST_SetSRID(geometry, 3857), 
31466)) FROM osm_car_sharing_node LIMIT 1;
-[ RECORD 1 
]+--

geometry | 010120110F04F0844A1349264120ED527FE9DD5841
st_asgeojson | 
{"type":"Point","crs":{"type":"name","properties":{"name":"EPSG:31466"}},"coordinates":[5586869.519378289,2539841.861857439]}


I understand the rationale for the change in general, but in my opinion 
such a major change really should not be part of such a minor update.


Is there an option to fix this apart from changing all queries?

Regards,
Stephan Großberndt

Bug#1035876: libcegui-mk2-data: broken symlink: /usr/share/cegui-0.8.7/fonts/Junicode.ttf -> ../../fonts/truetype/junicode/Junicode.ttf

[Andreas Beckmann]

Package: libcegui-mk2-data
Version: 0.8.7+git20220615-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

0m26.8s ERROR: FAIL: Broken symlinks:
  /usr/share/cegui-0.8.7/fonts/Junicode.ttf -> 
../../fonts/truetype/junicode/Junicode.ttf (libcegui-mk2-data)


fonts-junicode does no longer ship *.ttf, only *.otf.


cheers,

Andreas

Bug#1035875: Arbitrary code execution vulnerability in versions < 2.3

[Lee Garrett]

Package: osslsigncode
Version: 2.1-1
Severity: grave
Tags: security
X-Debbugs-Cc: secur...@debian.org, deb...@rocketjump.eu, Debian Security Team 


It was reported through IRC that the current stable version of osslsigncode
contains an unpatched security vulnerability:

https://github.com/mtrojnar/osslsigncode/releases/tag/2.3

Unfortunately, upstream has not assigned a CVE, and a quick glance at the closed
bug reports didn't reveal any further details.

Regards,
Lee


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

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

Versions of packages osslsigncode depends on:
ii  libc6 2.36-9
ii  libcurl4  7.88.1-9
ii  libssl3   3.0.8-1

osslsigncode recommends no packages.

osslsigncode suggests no packages.

Bug#1035874: manaplus-data: broken symlinks: /usr/share/manaplus/data/fonts/mplus-1p-*.ttf -> ../../../fonts/truetype/mplus/mplus-1p-*.ttf

[Andreas Beckmann]

Package: manaplus-data
Version: 2.1.3.17-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

0m44.4s ERROR: FAIL: Broken symlinks:
  /usr/share/manaplus/data/fonts/mplus-1p-bold.ttf -> 
../../../fonts/truetype/mplus/mplus-1p-bold.ttf (manaplus-data)
  /usr/share/manaplus/data/fonts/mplus-1p-regular.ttf -> 
../../../fonts/truetype/mplus/mplus-1p-regular.ttf (manaplus-data)


fonts-mplus does no longer ship *.ttf, only *.otf


cheers,

Andreas

Bug#1035873: openboard-common: broken symlink: /usr/share/openboard/customizations/fonts/AndBasR.ttf -> ../../../fonts/truetype/andika/Andika-R.ttf

[Andreas Beckmann]

Package: openboard-common
Version: 1.6.4+dfsg-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

0m14.3s ERROR: FAIL: Broken symlinks:
  /usr/share/openboard/customizations/fonts/AndBasR.ttf -> 
../../../fonts/truetype/andika/Andika-R.ttf (openboard-common)

/usr/share/fonts/truetype/andika/Andika-Regular.ttf might be an
alternative target. (May need a versioned fonts-sil-andika dependency.)



cheers,

Andreas

Bug#1035872: tuxmath-data: broken symlink: /usr/share/tuxmath/fonts/AndikaDesRevG.ttf -> ../../fonts/truetype/andika/Andika-R.ttf

[Andreas Beckmann]

Package: tuxmath-data
Version: 2.0.3-8
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

0m19.3s ERROR: FAIL: Broken symlinks:
  /usr/share/tuxmath/fonts/AndikaDesRevG.ttf -> 
../../fonts/truetype/andika/Andika-R.ttf (tuxmath-data)

/usr/share/fonts/truetype/andika/Andika-Regular.ttf might be an
alternative target. (May need a versioned fonts-sil-andika dependency.) 


cheers,

Andreas

Bug#1035849: opam: `opam init` fails. Missing ca-certificates dependency, only listed as recommended

[Stéphane Glondu]

Le 10/05/2023 à 11:15, Cuihtlauac Alvarado a écrit :

I agree you have a valid point, your reasoning makes sense. However,
it seems to me that by the same reasoning bubblewrap should be turned
into a recommended dependency too. Your command

opam init --bare --disable-sandboxing default /path/to/repository

also works if bubblewrap is forcefully removed (and the dependencies
broken, for the sake of the example). Therefore, there exists a way to
use opam without bubblewrap, it could be recommended only.


I agree, and I am more willing to demote bubblewrap to Recommends than 
promote ca-certificates to Depends.



Cheers,

--
Stéphane

Bug#1035871: flare-engine: broken symlink: /usr/share/games/flare/mods/default/fonts/unifont-10.0.06.ttf -> ../../../../../fonts/truetype/unifont/unifont.ttf

[Andreas Beckmann]

Package: flare-engine
Version: 1.14-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

0m55.5s ERROR: FAIL: Broken symlinks:
  /usr/share/games/flare/mods/default/fonts/unifont-10.0.06.ttf -> 
../../../../../fonts/truetype/unifont/unifont.ttf (flare-engine)

fonts-unifont does no longer ship unifont.ttf or other *.ttf.
There are only the *.otf variants left in most cases.


cheers,

Andreas

Bug#1035870: libgnunet-dev: missing Depends: gnunet (= ${binary:Version})

[Andreas Beckmann]

Package: libgnunet-dev
Version: 0.19.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
broken symlinks:

0m44.3s ERROR: FAIL: Broken symlinks:
  /usr/lib/x86_64-linux-gnu/libgnunetats.so -> libgnunetats.so.4.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetblock.so -> libgnunetblock.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetblockgroup.so -> 
libgnunetblockgroup.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetcadet.so -> libgnunetcadet.so.7.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetconsensus.so -> 
libgnunetconsensus.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetconversation.so -> 
libgnunetconversation.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetcore.so -> libgnunetcore.so.0.0.1 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetdatacache.so -> 
libgnunetdatacache.so.0.0.1 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetdatastore.so -> 
libgnunetdatastore.so.1.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetdht.so -> libgnunetdht.so.4.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetdid.so -> libgnunetdid.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetdns.so -> libgnunetdns.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetfragmentation.so -> 
libgnunetfragmentation.so.2.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetfriends.so -> libgnunetfriends.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetfs.so -> libgnunetfs.so.2.1.1 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetgns.so -> libgnunetgns.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetgnsrecord.so -> 
libgnunetgnsrecord.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetgnsrecordjson.so -> 
libgnunetgnsrecordjson.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunethello.so -> libgnunethello.so.0.1.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetidentity.so -> libgnunetidentity.so.1.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetmessenger.so -> 
libgnunetmessenger.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetmicrophone.so -> 
libgnunetmicrophone.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetnamecache.so -> 
libgnunetnamecache.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetnamestore.so -> 
libgnunetnamestore.so.0.0.1 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetnatauto.so -> libgnunetnatauto.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetnatnew.so -> libgnunetnatnew.so.2.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetnse.so -> libgnunetnse.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetnt.so -> libgnunetnt.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetpeerinfo.so -> libgnunetpeerinfo.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetpeerstore.so -> 
libgnunetpeerstore.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetpq.so -> libgnunetpq.so.3.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetreclaim.so -> libgnunetreclaim.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetregex.so -> libgnunetregex.so.3.0.1 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetregexblock.so -> 
libgnunetregexblock.so.1.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetrest.so -> libgnunetrest.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetrevocation.so -> 
libgnunetrevocation.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetscalarproduct.so -> 
libgnunetscalarproduct.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetsecretsharing.so -> 
libgnunetsecretsharing.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetset.so -> libgnunetset.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetseti.so -> libgnunetseti.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetsetu.so -> libgnunetsetu.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetspeaker.so -> libgnunetspeaker.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunetstatistics.so -> 
libgnunetstatistics.so.2.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunettestbed.so -> libgnunettestbed.so.0.0.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunettestbedlogger.so -> 
libgnunettestbedlogger.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunettesting.so -> libgnunettesting.so.1.1.0 
(libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunettestingdhtu.so -> 
libgnunettestingdhtu.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunettransport.so -> 
libgnunettransport.so.2.2.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunettransportapplication.so -> 
libgnunettransportapplication.so.0.0.0 (libgnunet-dev)
  /usr/lib/x86_64-linux-gnu/libgnunettransportcommunicator.so -> 
libgnunettransportcommunicator.so.0.0.

Bug#1030743: help is welcome about the 'source-is-missing' error with the cherrytree packaging

[Andrius Merkys]

Hello,

Maintainer of cherrytree here.

On 2023-05-08 20:48, Patrice Duroux wrote:

Following #1030720, the maintainer reported #1030743 and now I am trying
to package a new upstream version (0.99.55).


This is still an issue. I attempted to override lintian error with 
adding the following to debian/source/lintian-overrides:


cherrytree source: source-is-missing [tests/data_данные/test.export.html]

However, it seems that lintian is unable to match these two Unicode 
containing strings, thus this override is reported as mismatched. I 
think this is a bug in lintian, either the same as #1030743 or a 
different one.



I am still facing the same lintian error and tried to understand the
job of SourceMissing.pm.
So my question is why this test data file
(test//data_данные//test.export.html) is considered by lintian? And
would it be also the case (not reported) with some other .html files
in the same sudir?


[file list cut for brevity]

Lintian considers all files in the source distribution. In case of this 
particular file it is most likely a very long line length triggers 
lintian into thinking this is not a source file. As this file is used 
for testing, lintian error is false-positive and should normally be 
overridden.



The 'tests' subdir is only used to run a test after the built.
This file is considered by lintian but is not intended to be and is
not part of the produced .deb package.


Right, but source distribution should not contain non-source files. This 
is due to "preferable form of modification" requirement in Debian policy.


Best,
Andrius

Bug#1035839: closed by Debian FTP Masters (reply to Rafael Laboissière ) (Bug#1035839: fixed in jed 1:0.99.20~pre.178+dfsg-4)

[Axel Beckert]

Hi Rafael,

Debian Bug Tracking System wrote:
>  jed (1:0.99.20~pre.178+dfsg-4) unstable; urgency=medium
>  .
>* d/jed-common.preinst: Avoid non-fatal abortion of the script.
>  Thanks to Axel Beckert for the fix (Closes: #1035839)

Thanks! Just wanted to confirm that I could now upgrade jed and
jed-common without issues from 1:0.99.20~pre.178+dfsg-1 to
1:0.99.20~pre.178+dfsg-4.

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

Bug#697821: dependencies

[matthias . geiger1024]

ffmpeg could also be an issue since upstream embeds an ancient version and 
won't switch to a newer one [1]. Maybe we can steal this patch [2] utilizing 
ffmpeg 5.  Another issue is ppsspp directly referencing absolute header paths, 
which will require extensive patching.

grepping the source code lists the following external headers referenced (i.e 
patching/packaging needed):

- jpge.h and jpgd.h -> 6) 
- zip.h -> in debian, libzip-dev
- vk_mem_allocator ->3),  in new
- vulkan.h -> in debian, libvulkan-dev
- miniwget.h, miniupnpc.h, upnpcommands.h -> in debian, libminiupnpc-dev
- basisu_transcoder.h and basisu_file_headers.h -> needs packaging from 
scratch, [3]
- xxhash.h -> in debian, libxxhash-dev
- xbrz.h -> contained in the source of https://tracker.debian.org/pkg/xbrzscale 
, needs to split into an extra package maybe ? 
- ShaderLang.h -> in debian, glslang-dev
- gason, udis86 and cityhash -> 1) needs some cleanup
- libkirk

I think we might get away by providing all the headers and hope it compiles 
then :/


[1] https://github.com/hrydgard/ppsspp/issues/15308

[2] 
https://build.opensuse.org/package/view_file/home:X0F:branches:Emulators/ppsspp/ppsspp-support_ffmpeg5.patch?expand=1

[3] https://github.com/BinomialLLC/basis_universal

regards,

---
Matthias Geiger (werdahias)

-BEGIN PGP PUBLIC KEY BLOCK-

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

Bug#1034736: Hello my dear

[Mrs Rebecca Jackson]

-- 
Hi,

I wish to donate some funds to you for charity and to help the poor and the
needy in society. I have taken this step because of my present deteriorated
health condition. I will explain more as soon as I receive your response
thanks.

*Mrs Rebecca Jackson*
jacksonrebecca...@gmail.com