Bug#1038811: Kernel 6.1 is buggy as hell

[Niccolò Paganini II]

I'm experiencing this exact bug. I'm running Debian testing (Trixie).
My laptop is an ASUS TUF DASH F15 (2022). You can read about it here:
https://wiki.archlinux.org/title/ASUS_TUF_DASH_F15_(2022)

While I was using Debian Bookworm (now Debian stable), I didn't experience
any problems/issues like these.

But it turns out that as soon as I upgraded to Debian Trixie, which brought
with it the 6.1 kernel, these bugs popped up.

Now the only way to turn off the computer is through the power button, that
is, I have to forcibly shut down my machine by interruption of power.

But there is another bug: when doing resume, after a suspend, the computer
freezes and blocks completely, which forces me to have to turn it off by
interruption of power.

Best regards,
Niccolò Paganini.

Bug#1040566: let logol be removed

[Andreas Tille]

Hi Olivier,

Am Mon, Jul 17, 2023 at 12:13:30PM +0200 schrieb olivier sallou:
> logol is not maintained anymore for quite some time now
> 
> effort to keep in line with swi-prolog updates (need to recompile on each
> ABI break of swi-prolog) AND biojava requires frequent work for an old
> software with low usage.
> 
> I would let it be removed

You introduced the package so you know its usage best.  I think any
removal should be announced on debian-med@l.d.o which I'm doing hereby.

IMHO if the fix would be "simple" (in terms of needs only less than
10min) keeping it might be worth it.  Otherwise its a good time in the
beginning of the release process to remove packages that just drain
developer resources and do not serve a mentionable amount of users.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1041410: libdogleg-dev: missing Breaks+Replaces: libdogleg-doc (<< 0.16-2)

[Dima Kogan]

Thank you very much for the report. I completely forgot about these.
Fixed just now.

Bug#1040629: Additional information

[Vladimir Petko]

I have encountered the same error when running tests locally, but only
seen it once and could not reproduce it.

But when running a test against against pillow 10.0.0-1 the following
error occurs[1]

==
FAIL: test_process_apk (__main__.UpdateTest.test_process_apk)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest.V6tBlg/build.2CL/real-tree/tests/update.TestCase",
line 949, in test_procesk
self.assertTrue(os.path.isfile(icon_path))
AssertionError: False is not true

It is already fixed upstream[2].

The attached patch contains the fix.

Thank you for considering the patch.

[1] 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic/mantic/amd64/f/fdroidserver/20230707_143232_ec734@/log.gz
[2] 
https://github.com/f-droid/fdroidserver/commit/132e953c8c9f7d709586442aee6ff474cfa8fa18
Description: do not use deprecated Image.ANTIALIAS attribute
 The ANTIALIAS alias was removed in Pillow 10.0.0:
 https://pillow.readthedocs.io/en/stable/deprecations.html
Author: Hans-Christoph Steiner 
Origin: upstream
Bug: https://github.com/f-droid/fdroidserver/commit/132e953c8c9f7d709586442aee6ff474cfa8fa18
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040629
Last-Update: 2023-07-19
--- a/fdroidserver/update.py
+++ b/fdroidserver/update.py
@@ -250,7 +250,7 @@
 
 if any(length > size for length in im.size):
 oldsize = im.size
-im.thumbnail((size, size), Image.ANTIALIAS)
+im.thumbnail((size, size), Image.Resampling.LANCZOS)
 logging.debug("%s was too large at %s - new size is %s" % (
 iconpath, oldsize, im.size))
 im.save(iconpath, "PNG", optimize=True,
@@ -1757,7 +1757,7 @@
 
 size = dpi_to_px(density)
 
-im.thumbnail((size, size), Image.ANTIALIAS)
+im.thumbnail((size, size), Image.Resampling.LANCZOS)
 im.save(icon_path, "PNG", optimize=True,
 pnginfo=BLANK_PNG_INFO, icc_profile=None)
 empty_densities.remove(density)

Bug#1041440: popularity-contest: Non Debian - non Deb packages should be able to be reported - packages missing from Debian

[Petter Reinholdtsen]

[Karl Schmidt]
> While popcon seems a good idea - it seems that data from repository
> downloads would do much the same job.

Due to the distributed nature of the mirroring setup, there are no such
data, so it can not be used like that.

> What would be even more important is gathering statistics on non
> Debian and even non Deb package software installed.

This has been discussed for a while.  You might find for example
https://bugs.debian.org/632438 > illuminating.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1041450: plasma-desktop: dependence issue: wrong version string of two recommends

[Moon]

Package: plasma-desktop
Version: 4:5.27.5-2
Severity: normal
X-Debbugs-Cc: zmy...@gmail.com

Dear Maintainer,


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


packages plasma-desktop recommends:(has a version epoch 4:)
plasma-firewall(>=4:5.27.5~)
plasma-welcome(>=4:5.27.5~)

exist package:(no version epoch)
plasma-firewall(5.27.5-2)
plasma-welcome(5.27.5-2)


When apt install plasma-desktop, rec package should be installed as
well. But the version string issue make them keep uninstalled.

Bug#1040947: perl: readline fails to detect updated file

[Eric Wong]

Niko Tyni  wrote:
> On Tue, Jul 18, 2023 at 01:23:51AM +, Eric Wong wrote:
> 
> > At this point (given Perl's maturity); it's less surprising if
> > it kept it's lack of error detection in all cases.
> 
> Thanks for caring, but please take your arguments upstream.

First off, my apologies to Ian that I made him feel uncomfortable.

I merely wanted to point out the severity of incompatible changes in
case someone from upstream sees my comments.

> It's them you need to convince if you want that change to be
> reverted or amended.

Unfortunately, upstream's use of a proprietary platform,
said platform's terms-of-service and JavaScript CAPTCHA are all
non-starters for somebody like me :<

Thanks.

Bug#1041449: shim-signed: dependence issue rec:secureboot-db is not exist

[Moon]

Package: shim-signed
Version: 1.39+15.7-1
Severity: normal
X-Debbugs-Cc: zmy...@gmail.com

Dear Maintainer,


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

Versions of packages shim-signed depends on:
pn  grub-efi-amd64-bin 
ii  grub2-common   2.06-13
pn  shim-helpers-amd64-signed  
pn  shim-signed-common 

Versions of packages shim-signed recommends:
pn  secureboot-db  

shim-signed suggests no packages.

Bug#1041448: breeze: package dependence issue: breeze has 'rec:kde-style-qtcurve' which don't exist

[Moon]

Package: breeze
Version: 4:5.27.5-2
Severity: normal
X-Debbugs-Cc: zmy...@gmail.com

Dear Maintainer,

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


Versions of packages breeze depends on:
pn  breeze-cursor-theme   
pn  breeze-icon-theme 
pn  kde-style-breeze  
pn  kwin-style-breeze 
ii  libc6 2.36-9
pn  libkf5configcore5 
pn  libkf5coreaddons5 
pn  libkf5i18n5   
pn  libkf5kcmutils5   
pn  libqt5core5a  
pn  libqt5gui5 | libqt5gui5-gles  
pn  libqt5widgets5

Versions of packages breeze recommends:
pn  kde-style-qtcurve  

Versions of packages breeze suggests:
pn  orion-gtk-theme  

Bug#1035669: gir1.2-harfbuzz-0.0: Can not recreate GIR information from gir1.2-harfbuzz-0.0.typelib

[أحمد المحمودي]

reassign 1035669 gobject-introspection
forwarded 1035669 
https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/469
done

According to the discussion on 
https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/469 , the 
issue is actually in g-ir-generate (or compiler), hence reassigning the 
issue

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#1037346: cyrus-imapd: Stable should have gone from Cyrus 3.2.6 to 3.2.10 first

[Yadd]

On 7/18/23 22:24, Gijs Hillenius wrote:

Package: cyrus-imapd
Version: 3.6.1-4
Followup-For: Bug #1037346

Dear Maintainers

The documentation

https://www.cyrusimap.org/3.6/imap/download/upgrade.html#versions-to-upgrade-from

tells me that we should have upgraded from Cyrus 3.2.6 to 3.2.10 before going to
3.6.x. Bullseye stable didn't take us that way, and perhaps neither did 
Bullseye-backports.

Perhaps a check should be made, and stop Cyrus 3.2 from being upgraded?

Best wishes,


Hi,

the patch needed to update to 3.6 is included in version 
3.2.6-2+deb11u2. So the doc should be updated to explain that "we should

have upgraded from Cyrus 3.2.6-2 to 3.2.6-2+deb11u2 before going to 3.6.x"

Regards,
Yadd

Bug#1041447: comitup: fails to install, remove, distupgrade, and install again

[Andreas Beckmann]

Package: comitup
Version: 1.38-1.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
(in 'bullseye'), remove (but not purge), distupgrade to 'bookworm',
and install again.
Before the second installation the package is in config-files-remaining
state. The configuration is remaining from the last version that was
successfully configured - which is from the previous release.

Like a plain failure on initial install this makes the package too buggy
for a release, thus the severity.

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

...
  Setting up comitup (1.15-1) ...
  comitup-no-wifi - No wifi devices found

  Comitup is a wifi device manager. 'sudo iw list' indicates that
  there are no devices to manage.

  Created symlink /etc/systemd/system/multi-user.target.wants/comitup.service → 
/lib/systemd/system/comitup.service.
...
  Removing comitup (1.15-1) ...
...
  Setting up comitup (1.38-1.1) ...
  Installing new version of config file /etc/comitup.conf ...
  [ESC][0;1;31mFailed to enable unit, unit /etc/systemd/system/comitup.service 
is masked.[ESC][0m
  dpkg: error processing package comitup (--configure):
   installed comitup package post-installation script subprocess returned error 
exit status 1
  Processing triggers for dbus (1.14.8-2~deb12u1) ...
  Errors were encountered while processing:
   comitup
...

cheers,

Andreas


comitup_1.38-1.1.log.gz
Description: application/gzip

Bug#1041348: RM: https-everywhere/stable -- ROM; obsolete;major browsers offer native support now;

[Markus Koschany]

I have uploaded a new revision of boxer-data and debian-parl to Bookworm now.
This update removes the dependency on webext-https-everywhere. Jonas agreed to
this change.

https://bugs.debian.org/1041350

AFAIK nothing else should prevent the removal of https-everywhere from
Bookworm.

Markus


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

Bug#1041367: src:emacs: Detect default GCC version instead of hard-coding.

[Manphiz]

retitle 1041367 Automate GCC version handling.
# tag with patch as a merge request is available.
tag 1041367 patch
thanks

Manphiz  writes:

> Sean Whitton  writes:
>
>> Hello,
>>
>> On Mon 17 Jul 2023 at 07:26pm -07, Xiyue Deng wrote:
>>
>>> Currently Emacs hard-codes the GCC version - more specifically the GCC
>>> JIT version - for the native compile feature.  As the default GCC
>>> version may change once in a while, it may be beneficial to avoid
>>> hard-coding the version and instead generate it using default GCC.  I
>>> have prepared a merge request on salsa[1], however as inexperienced as I
>>> am this will surely look crude, but may be an okay-ish start of
>>> discussion.  Thanks!
>>
>> Thank you for looking into this.  Unfortunately, I think it's unlikely
>> that we'd want to apply this change: typically things like this are done
>> manually in Debian.  It's similar to debhelper compat level bumps.
>
> Thanks Sean!  I understand.  Would it be acceptable to have things
> slightly automated while still make the GCC version hard-coded?  Like
> having a variable "default_gcc_version" which is manually changed and
> the rest auto-generated?

On further testing, it look like the automatic GCC version detection I
proposed is indeed problematic: as the file regeneration happens before
a buildd is involved, the generated version depends on the system that
the people tries to build it.  So as I'm currently using a stable
system, when I run `gbp buildpackage` it will detect the GCC version as
12 while on sid it's 13 which is a nightmare.

So, I've reworked the MR a bit now that it still hard-code the GCC
version but at a single location[1] and all versions at other places are
generated so that it's less like to make mistakes.  Please help take
another look.

Thanks!

[1] 
https://salsa.debian.org/rlb/deb-emacs/-/merge_requests/3/diffs#8756c63497c8dc39f7773438edf53b220c773f67_74_75

-- 
Manphiz

Bug#1041446: bookworm-pu: package boxer-data/10.9.12

[Markus Koschany]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: a...@debian.org


[ Reason ]

The https-everywhere browser addon is obsolete and boxer-data (and
thus debian-parl) still references it.

[ Impact ]

We have to update boxer-data in order to fix Debian bug #1041350 in
Bookworm.

[ Risks ]

https only mode is now a standard feature of all major browsers. Users
just don't need the https-everywhere addon anymore which is a good
thing.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable
diff -Nru boxer-data-10.9.12/bullseye/classes/Desktop/web/firefox/harden.yml 
boxer-data-10.9.12+deb12u1/bullseye/classes/Desktop/web/firefox/harden.yml
--- boxer-data-10.9.12/bullseye/classes/Desktop/web/firefox/harden.yml  
2020-11-10 13:20:34.0 +0100
+++ boxer-data-10.9.12+deb12u1/bullseye/classes/Desktop/web/firefox/harden.yml  
2023-07-19 00:04:50.0 +0200
@@ -6,6 +6,5 @@
   pkg:
 - include Firefox security plugins
   pkg:
-- webext-https-everywhere
 - webext-privacy-badger
 - webext-ublock-origin-firefox
diff -Nru boxer-data-10.9.12/CHANGELOG.md 
boxer-data-10.9.12+deb12u1/CHANGELOG.md
--- boxer-data-10.9.12/CHANGELOG.md 2022-08-07 18:31:29.0 +0200
+++ boxer-data-10.9.12+deb12u1/CHANGELOG.md 2023-07-19 00:04:50.0 
+0200
@@ -6,6 +6,11 @@
 
 ## [Unreleased]
 
+## [10.9.13] - 2023-07-19
+
+  * Fix class Desktop.web.firefox.harden. No longer install obsolete Firefox
+addon https-everywhere.
+
 ## [10.9.12] - 2022-08-07
 
 ### Fixed
diff -Nru boxer-data-10.9.12/debian/changelog 
boxer-data-10.9.12+deb12u1/debian/changelog
--- boxer-data-10.9.12/debian/changelog 2022-08-07 18:31:45.0 +0200
+++ boxer-data-10.9.12+deb12u1/debian/changelog 2023-07-19 00:04:50.0 
+0200
@@ -1,3 +1,11 @@
+boxer-data (10.9.12+deb12u1) bookworm; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix class Desktop.web.firefox.harden. No longer install obsolete Firefox
+addon https-everywhere.
+
+ -- Markus Koschany   Wed, 19 Jul 2023 00:04:50 +0200
+
 boxer-data (10.9.12) unstable; urgency=medium
 
   * add class l10n.mythes.pt.BR since bookworm

Bug#1041445: gitaly: New error in postinst

[Jakob Bohm]

Package: gitaly
Version: 16.0.7+ds1-2~bpo12+1
Severity: normal

Dear Maintainer,

When installing gitaly from bookworm-fasttrack, postinst fails with the
following messages:

(Note: This is a rerun, thus override.conf was created by a previous run)
  # dpkg --configure gitaly
  Setting up gitaly (16.0.7+ds1-2~bpo12+1) ...
  /etc/systemd/system/gitaly.service.d/override.conf already exist
  Starting gitaly...failed.
  invoke-rc.d: initscript gitaly, action "start" failed.
  dpkg: error processing package gitaly (--configure):
   installed gitaly package post-installation script subprocess returned error 
exit status 1
  Errors were encountered while processing:
   gitaly

The messages are not clear what went wrong, and reading /etc/init.d/gitaly
doesn't make it clear where any specific start errors can be found (There's
a quoted /usr/bin/logger invocation, but nothing can be easily found in the
system logs that are filled with noise from other bookworm breakage).

P.S.
  Looking in gitaly.postinst I see that the patch in bug
  #974159 Message #10 seems to already have been applied, so this is
  apparently different bug.


-- System Information:
Debian Release: 12.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'bookworm-fasttrack'), (100, 'bookworm-backports-staging')
Architecture: amd64 (x86_64)

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

Versions of packages gitaly depends on:
ii  gitlab-common  16.0.7+ds1-2~bpo12+1
ii  libc6  2.36-9
ii  libgit2-1.51.5.1+ds-1
ii  pipexec2.6.1-2
ii  procps 2:4.0.2-3

gitaly recommends no packages.

gitaly suggests no packages.

-- no debconf information

Bug#1040954: Info received (Bug#1040954: Acknowledgement (inspircd: PID and Logging have broken permissions))

[Victor Coss]

Hello, I have another update to provide. I was able to temporarily fix 
file logging until you can fix the package. I had to create a logs 
folder in /usr/lib/inspircd/ and change it's permissions accordingly and 
change ownership and group to irc:irc with read and write permissions so 
InspIRCd can write various log files in that directory. As stated before 
the correct location should be /var/log/inspircd/ for log files instead. 
You may need to have the package create this directory on install and 
give the proper permissions for the irc user to read and write to it.


Also as a side note so you are aware, any segfaults you see in dmesg, 
are not actually segmentation faults; this is caused by InspIRCd not 
using standard exit codes. This can be fixed in v3 of InspIRCd by adding 
-DINSPIRCD_BINARY_EXIT to CXXFLAGS in the environment to disable the 
custom exit codes that InspIRCd uses. In v4 (not released yet) this has 
been resolved completely and InspIRCd will use standard exit codes.


As stated previously, please feel free to check out 
https://docs.inspircd.org/packaging/ on how to best package InspIRCd and 
avoid these kinds of issues. Also feel free to join us anytime on IRC at 
irc.chatspike.net #inspircd. You will find me, along with the head 
developer of InspIRCd, Sadie. We are willing to answer any questions you 
may have.


I would greatly appreciate it if you can get this resolved and also 
appreciate it if you can ship the new upstream version 3.16.1. There are 
no breaking changes since 3.15.0. It would be nice to see this update 
for the upcoming Bookworm point release (12.1) that will take place on 
Saturday June 22.


Thank you,
Victor Coss

On 7/13/2023 9:51 AM, 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):
  Filippo Giunchedi 

If you wish to submit further information on this problem, please
send it to 1040...@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.

Bug#1041406: libimlib2: imlib_clone_image() no longer preserves the alpha channel flag

[Markus Koschany]

Control: forwarded -1 https://git.enlightenment.org/old/legacy-imlib2/issues/17

Thanks for the report!


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

Bug#1040806: cura-engine: ADT failure "Trying to retrieve setting with no value given: 'adhesion_extruder_nr'"

[Gregor Riepl]

I'm sorry Gregor, this is what happened, I mis-reported against 4.13.  I hope
it wasn't too much of a time waste.

Fixing 5.0.0 should be sufficient.  Thank you.


All right - I went ahead and marked the correct version.

It looks the next release is still on hold because of an old FPU 
rounding issue affecting i686. I hope I can get that fixed shortly.

Bug#1041444: gitaly: No manpage for gitaly binary

[Jakob Bohm]

Package: gitaly
Version: 16.0.7+ds1-2~bpo12+1
Severity: minor

Dear Maintainer,

In the gitaly package, the main daemon binary /usr/bin/gitaly apparently
has no manpage.  Such a manpage would ideally explain what the binary is
and what the daemon command line arguments are.  If there is a config
file, the daemon manpage should document it or refer to a dedicated
manpage for that file (in section 5).

Having manpages for all installed binaries, and especially those in
/usr/bin and /usr/sbin, has traditionally been a major Debian feature,
and is required by section 12.1 in the Debian policy manual.  This
applies even to binaries that are documented in other formats such as
html or texinfo.

For inspirational examples, see the man pages for git-daemon(1) and
nginx(8).

-- System Information:
Debian Release: 12.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'bookworm-fasttrack'), (100, 'bookworm-backports-staging')
Architecture: amd64 (x86_64)

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

Versions of packages gitaly depends on:
ii  gitlab-common  16.0.7+ds1-2~bpo12+1
ii  libc6  2.36-9
ii  libgit2-1.51.5.1+ds-1
ii  pipexec2.6.1-2
ii  procps 2:4.0.2-3

gitaly recommends no packages.

gitaly suggests no packages.

-- no debconf information

Bug#1041438: gdm3 dep8 failure & reenabling files provider

[Sergio Durigan Junior]

Control: tags -1 + patch

On Tuesday, July 18 2023, I wrote:

> Hi,
>
> The dep8 tests for gdm3 are currently failing with sssd 2.9.1-1 on
> Debian and Ubuntu:
>
>   https://ci.debian.net/data/autopkgtest/testing/amd64/g/gdm3/35903643/log.gz
[...]

Proposed patch:

https://salsa.debian.org/sssd-team/sssd/-/merge_requests/28

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1041443: pyfai_2023.5.0+dfsg1-3_all-buildd.changes REJECTED

[Aurelien Jarno]

Source: pyfai
Version: 2023.5.0+dfsg1-3
Severity: serious

On 2023-07-18 11:09, Debian FTP Masters wrote:
> pyfai_2023.5.0+dfsg1-3_all.deb: has 1 file(s) with a timestamp too far in the=
>  past:
>   usr/share/doc/pyfai/changelog.gz (Thu Jan  1 00:00:00 1970)
> 
> 
> 
> =3D=3D=3D
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#1041442: python-fabio_2023.6.0-1_ppc64el-buildd.changes REJECTED

[Aurelien Jarno]

Source: python-fabio
Version: 2023.6.0-1
Severity: serious

On 2023-07-18 19:24, Debian FTP Masters wrote:
> python3-fabio_2023.6.0-1_ppc64el.deb: has 1 file(s) with a timestamp too far =
> in the past:
>   usr/share/doc/python3-fabio/changelog.gz (Thu Jan  1 00:00:00 1970)
> 
> 
> 
> =3D=3D=3D
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#1038243: unbound: error log flooding when unbound is configured with a DNS over TLS upstream server

[Timo Sigurdsson]

tags 1038243 confirmed patch fixed-upstream
thanks

I can confirm this bug. I also stumbled over this after upgrading a machine 
from Bullseye to Bookworm. I can also confirm that the upstream fix (commit 
d7e77611) [1] on top of the unbound package currently found in Debian Bookworm, 
1.17.1-2, fixes the issue for me. I'm attaching the patch that I applied on the 
source package. It's the upstream patch except for the (upstream) documentation 
update (as that doesn't apply nicely on the version found in Bookworm and has 
no functional impact). If anyone wants to try my local binary build (at your 
own risk - no warranty whatsoever!), you can find the packages here [2]. The 
link expires Nov 15, 2023.

Dear Maintainer, it would be nice if you could apply the upstream fix and 
release a new unbound packages via proposed-updates.

Thanks and regards,

Timo

[1] 
https://github.com/NLnetLabs/unbound/commit/d7e776114114c16816570e48ab3a27eedc401a0e
[2] https://cloud.timo-sigurdsson.com/index.php/s/fRp5A99aHJK3Le6>From d7e776114114c16816570e48ab3a27eedc401a0e Mon Sep 17 00:00:00 2001
From: George Thessalonikefs 
Date: Fri, 17 Mar 2023 14:39:37 +0100
Subject: [PATCH] - Fix #812, fix #846, by using the
 SSL_OP_IGNORE_UNEXPECTED_EOF option   to ignore the unexpected eof while
 reading in openssl >= 3.

---
 util/net_help.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/util/net_help.c b/util/net_help.c
index 54fad6986..de2d771bd 100644
--- a/util/net_help.c
+++ b/util/net_help.c
@@ -1005,6 +1005,16 @@ listen_sslctx_setup(void* ctxt)
 			log_crypto_err("could not set cipher list with SSL_CTX_set_cipher_list");
 	}
 #endif
+#if defined(SSL_OP_IGNORE_UNEXPECTED_EOF)
+	/* ignore errors when peers do not send the mandatory close_notify
+	 * alert on shutdown.
+	 * Relevant for openssl >= 3 */
+	if((SSL_CTX_set_options(ctx, SSL_OP_IGNORE_UNEXPECTED_EOF) &
+		SSL_OP_IGNORE_UNEXPECTED_EOF) != SSL_OP_IGNORE_UNEXPECTED_EOF) {
+		log_crypto_err("could not set SSL_OP_IGNORE_UNEXPECTED_EOF");
+		return 0;
+	}
+#endif
 
 	if((SSL_CTX_set_options(ctx, SSL_OP_CIPHER_SERVER_PREFERENCE) &
 		SSL_OP_CIPHER_SERVER_PREFERENCE) !=
@@ -1233,6 +1243,17 @@ void* connect_sslctx_create(char* key, char* pem, char* verifypem, int wincert)
 		SSL_CTX_free(ctx);
 		return 0;
 	}
+#endif
+#if defined(SSL_OP_IGNORE_UNEXPECTED_EOF)
+	/* ignore errors when peers do not send the mandatory close_notify
+	 * alert on shutdown.
+	 * Relevant for openssl >= 3 */
+	if((SSL_CTX_set_options(ctx, SSL_OP_IGNORE_UNEXPECTED_EOF) &
+		SSL_OP_IGNORE_UNEXPECTED_EOF) != SSL_OP_IGNORE_UNEXPECTED_EOF) {
+		log_crypto_err("could not set SSL_OP_IGNORE_UNEXPECTED_EOF");
+		SSL_CTX_free(ctx);
+		return 0;
+	}
 #endif
 	if(key && key[0]) {
 		if(!SSL_CTX_use_certificate_chain_file(ctx, pem)) {

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Alexandru Mihail]

Hello again,
Public key is up:
https://keys.openpgp.org/vks/v1/by-fingerprint/CEC2B41FDE5A803B6B08C01471CA8C5A78AA77BB
I also imported your key into my gpg keyring.
Thanks a lot !
Alexandru Mihail


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

Bug#1018206: luatex loses or changes text when discretionaries with priorities are used

[Preuße]

Control: clone 1018206 -1
Control: reopen -1

On 06.07.2023 12:15, Peter Mueller wrote:

Hi,

Oh my gosh.  Losing formatting would indeed be not severe.  Distorting 
contents is IS severe, especially if this goes unnoticed.  Heaven knows 
how much text has already been and will be silently changed in all the 
years of Debian 12.  Therefore, a kind request: please push it into the 
next update of Debian (12.1) or at least one of the next updates.



Clone this bug to create a fix for bookworm.

H.
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033847: closed by Debian FTP Masters (reply to gabr...@debian.org (Gabriel F. T. Gomes)) (Bug#1033847: fixed in bash-completion 1:2.11-7)

[Gabriel F. T. Gomes]

Hi, Richy,

Erring on the side of caution, I just posted a comment [1] to the upstream 
project, asking if the plan to release 2.12 is still alive. If they say yes, 
then we might give them a hand with the remaining tasks to speed it up. 
Otherwise, I'll plan some debian-only update in the lines of what you mentioned 
before.

Best regards,
Gabriel

[1] 
https://github.com/scop/bash-completion/discussions/530#discussioncomment-6482817

Bug#1041439: zchunk: backport to bookworm

[Bastian Germann]

Am 18.07.23 um 23:24 schrieb Peter Pentchev:

However, would you be terribly upset if I did the backport myself?


I would actually prefer that. Thanks!

Bug#1041439: zchunk: backport to bookworm

[Peter Pentchev]

On Tue, Jul 18, 2023 at 11:05:53PM +0200, Bastian Germann wrote:
> Source: zchunk
> Version: 1.3.1+ds1-1
> Severity: wishlist
> X-Debbugs-Cc: r...@debian.org
> 
> Hi,
> 
> I would like to backport zchunk to bookworm. May I upload one?

Wait, bookworm-backports is open now? Argh... so I just went back and
reread the last couple of messages to d-b-changes and, wow, I did
misread a couple of bookworm uploads as bullseye ones...

Hm, thanks for reaching out and thanks a lot for volunteering.
However, would you be terribly upset if I did the backport myself?
Or I would at least like to keep it as part of pkg-rpm-team;
if you do feel strongly about maintaining the backport (and I am not
trying to gatekeep here, sorry if it sounds that way), would you
consider joining the team?

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1041440: popularity-contest: Non Debian - non Deb packages should be able to be reported - packages missing from Debian

[Karl Schmidt]

Package: popularity-contest
Version: 1.76
Severity: wishlist

While popcon seems a good idea - it seems that data from repository downloads 
would do much the same job. 
What would be even more important is gathering statistics on non Debian and 
even non Deb package software installed.

I would imagine a setting to identify locations of non Debian executables so 
such data could be collected.

There is a pseudo-package bug - wnpp - that almost no one uses, but I would 
think that statistics on what 
is missing from Debian would be quite important.


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

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

Versions of packages popularity-contest depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.21.22

Versions of packages popularity-contest recommends:
ii  cron [cron-daemon] 3.0pl1-162
ii  exim4-daemon-light [mail-transport-agent]  4.96-15
ii  gpg2.2.40-1.1

Versions of packages popularity-contest suggests:
ii  anacron   2.3-36
pn  tor   
pn  torsocks  

-- debconf information:
* popularity-contest/participate: true
  popularity-contest/submiturls:

Bug#1041439: zchunk: backport to bookworm

[Bastian Germann]

Source: zchunk
Version: 1.3.1+ds1-1
Severity: wishlist
X-Debbugs-Cc: r...@debian.org

Hi,

I would like to backport zchunk to bookworm. May I upload one?

Thanks,
Bastian

Bug#1041432: box64: unsatisfiable dependencies

[Jeremy Bícha]

On Tue, Jul 18, 2023 at 4:55 PM Johannes Schauer Marin Rodrigues
 wrote:
> $ apt-cache show crossbuild-essential-mips64el  | grep Depends:
> Depends: gcc-mips64el-linux-gnuabi64 (>= 4:10.2) | gcc:mips64el, 
> g++-mips64el-linux-gnuabi64 (>= 4:10.2) | g++:mips64el, dpkg-cross
>
> But other packages use the same thing. Why does it work there?

I guess you should ask the Release Team for help. I don't know.

Thank you,
Jeremy Bícha

Bug#1041432: box64: unsatisfiable dependencies

[Johannes Schauer Marin Rodrigues]

Quoting Jeremy Bícha (2023-07-18 22:29:58)
> On Tue, Jul 18, 2023 at 4:23 PM Johannes Schauer Marin Rodrigues
>  wrote:
> > Quoting Jeremy Bícha (2023-07-18 21:20:21)
> > > https://tracker.debian.org/pkg/box64 says that box64 is unable to migrate
> > > into Testing because it has unsatisfiable dependencies on amd64, arm64,
> > > ppc64el (and I guess riscv64)
> >
> > I saw that but it doesn't say which one is unsatisfiable. Do you have an 
> > idea
> > about what is going on?
> 
> I am guessing that britney (or whatever is checking) is not familiar
> with the :amd64 syntax even on amd64.

$ apt-cache show crossbuild-essential-mips64el  | grep Depends:
Depends: gcc-mips64el-linux-gnuabi64 (>= 4:10.2) | gcc:mips64el, 
g++-mips64el-linux-gnuabi64 (>= 4:10.2) | g++:mips64el, dpkg-cross

But other packages use the same thing. Why does it work there?

signature.asc
Description: signature

Bug#1040945: tiff: CVE-2023-3618

[Salvatore Bonaccorso]

Hi László

On Mon, Jul 17, 2023 at 06:36:37PM +0200, László Böszörményi (GCS) wrote:
> Hi Salvatore,
> 
> On Thu, Jul 13, 2023 at 8:42 PM Salvatore Bonaccorso  
> wrote:
> > On Wed, Jul 12, 2023 at 10:12:50PM +0200, László Böszörményi wrote:
> > > In short, it seems:
> > > - it's a non-dsa as only a crash in a CLI tool (which has end of life 
> > > now),
> > > - doesn't affect the library,
> > > - while 4.5.0-6 (and in fact, at least from 4.5.0-1) is vulnerable,
> > > 4.5.1-1 fixed this issue.
> > >
> > > But you may find it otherwise, I do not alter this report in the BTS.
> [...]
> > For about having the issue fixed: The problem I have is that upstream
> > has not yet closed the issue. Is it completely fixed and what is the
> > fixing commit? https://gitlab.com/libtiff/libtiff/-/issues/529 is
> > slight unhelpful on that front.
>  Reason is simple. Upstream was fixing issues and probably was doing
> as they wanted. That is, there's another SIGSEGV issue [1] and it's in
> tiffcrop as well. Upstream fixed it and was going on with other fixes.
> Then maybe they couldn't reproduce the mentioned CVE issue and went on
> releasing v4.5.1 with several other CVE fixes [2]. There Timothy
> Lyanguzov commented that bug#529 probably will get a CVE id too, but
> he couldn't reproduce it with that Git HEAD.
> Answer is simple, the other SIGSEGV issue [1] fix solved this issue as
> well. As upstream probably didn't recognize and couldn't reproduce
> this SIGSEGV (anymore), it remained open.
> 
> > Are you able to identify the fixing commit confirming it is done in
> > 4.5.1-1?
>  Indeed, it is fixed for 4.5.1 and the fixing commit is
> b5c7d4c4e0ac16b5cfb11acaaeaa493334f8 [3].

Many thanks, this outline was quite helpful. I have updated the
security-trcker metadata.

Regards,
Salvatore

Bug#1041432: box64: unsatisfiable dependencies

[Jeremy Bícha]

On Tue, Jul 18, 2023 at 4:23 PM Johannes Schauer Marin Rodrigues
 wrote:
> Quoting Jeremy Bícha (2023-07-18 21:20:21)
> > https://tracker.debian.org/pkg/box64 says that box64 is unable to migrate
> > into Testing because it has unsatisfiable dependencies on amd64, arm64,
> > ppc64el (and I guess riscv64)
>
> I saw that but it doesn't say which one is unsatisfiable. Do you have an idea
> about what is going on?

I am guessing that britney (or whatever is checking) is not familiar
with the :amd64 syntax even on amd64.

Thank you,
Jeremy Bícha

Bug#1041438: gdm3 dep8 failure & reenabling files provider

[Sergio Durigan Junior]

Source: sssd
Version: 2.9.1-1
Severity: important
Forwarded: https://github.com/SSSD/sssd/issues/6838

Hi,

The dep8 tests for gdm3 are currently failing with sssd 2.9.1-1 on
Debian and Ubuntu:

  https://ci.debian.net/data/autopkgtest/testing/amd64/g/gdm3/35903643/log.gz

The reason is because the sssd.conf crafted by the test doesn't
explicitly define a "domain" section, but relies on setting
"enable_files_domain = True", which in turn sets "id_provider = files".
sssd 2.9.0 has deprecated this option, which now should be explicitly
enabled during build time using "--with-files-provider":

  https://github.com/SSSD/sssd/releases/tag/2.9.0

Given that "files domain" has been disabled because of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888207, I'd like to
know if using "--with-files-provider" would be acceptable to fix this
bug.

According to upstream:

  https://github.com/SSSD/sssd/issues/6838

in order to support and test "smart card auth of local users", then we
need to use such build time option, at least until the next upstream
release comes out (which should support such scenario via "id_provider =
proxy").

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1041432: box64: unsatisfiable dependencies

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Jeremy Bícha (2023-07-18 21:20:21)
> https://tracker.debian.org/pkg/box64 says that box64 is unable to migrate
> into Testing because it has unsatisfiable dependencies on amd64, arm64,
> ppc64el (and I guess riscv64)

I saw that but it doesn't say which one is unsatisfiable. Do you have an idea
about what is going on?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1041437: [debian bookworm] [kernel 6.1.0-9-rt-armmp] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[Jean-Marc LACROIX]

Package:linux-image-6.1.0-9-rt-armm
Version: 6.1.0-9-rt-armmp
Severity: serious

Dear developer,

On Debian bookworm, target nanopir1, please find following issue


[ 3991.659348]  secondary_start_kernel from 0x40301ec0
[ 3991.659348]  secondary_start_kernel from 0x40301ec0
[ 3991.659348]  secondary_start_kernel from 0x40301ec0
[ 3991.878735] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[ 3991.878763] CPU: 3 PID: 1 Comm: systemd Tainted: G C   L 
6.1.0-9-rt-armmp #1  Debian 6.1.27-1

[ 3991.878777] Hardware name: Allwinner sun8i Family
[ 3991.878796]  unwind_backtrace from show_stack+0x18/0x1c
[ 3991.878839]  show_stack from dump_stack_lvl+0x40/0x4c
[ 3991.878867]  dump_stack_lvl from panic+0x114/0x37c
[ 3991.878892]  panic from make_task_dead+0x0/0x184
[ 3992.631427] CPU1: stopping
[ 3992.631448] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G C   L 
6.1.0-9-rt-armmp #1  Debian 6.1.27-1

[ 3992.631462] Hardware name: Allwinner sun8i Family
[ 3992.631474]  unwind_backtrace from show_stack+0x18/0x1c
[ 3992.631504]  show_stack from dump_stack_lvl+0x40/0x4c
[ 3992.631527]  dump_stack_lvl from do_handle_IPI+0x36c/0x3d8
[ 3992.631552]  do_handle_IPI from ipi_handler+0x20/0x28
[ 3992.631573]  ipi_handler from handle_percpu_devid_irq+0xac/0x278
[ 3992.631600]  handle_percpu_devid_irq from 
generic_handle_domain_irq+0x30/0x40

[ 3992.631620]  generic_handle_domain_irq from gic_handle_irq+0x90/0xb0
[ 3992.631639]  gic_handle_irq from generic_handle_arch_irq+0x58/0x78
[ 3992.631659]  generic_handle_arch_irq from call_with_stack+0x18/0x20
[ 3992.631688]  call_with_stack from __irq_svc+0x98/0xdc
[ 3992.631708] Exception stack(0xf0875f68 to 0xf0875fb0)
[ 3992.631721] 5f60:   0001 c1064990 0067b901 
c0321080 c158d340 0001
[ 3992.631732] 5f80: c140f89c c140f8fc 4020406a 410fc075  
 03126e98 f0875fb8

[ 3992.631740] 5fa0: c030a750 c030a754 60070013 
[ 3992.631746]  __irq_svc from arch_cpu_idle+0x40/0x44
[ 3992.631762]  arch_cpu_idle from default_idle_call+0x48/0x8c
[ 3992.631782]  default_idle_call from do_idle+0xbc/0x12c
[ 3992.631804]  do_idle from cpu_startup_entry+0x20/0x24
[ 3992.631824]  cpu_startup_entry from secondary_start_kernel+0x134/0x154
[ 3992.631847]  secondary_start_kernel from 0x40301ec0
[ 3992.631921] CPU0: stopping
[ 3992.631931] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C   L 
6.1.0-9-rt-armmp #1  Debian 6.1.27-1

[ 3992.631942] Hardware name: Allwinner sun8i Family
[ 3992.631948]  unwind_backtrace from show_stack+0x18/0x1c
[ 3992.631969]  show_stack from dump_stack_lvl+0x40/0x4c
[ 3992.631989]  dump_stack_lvl from do_handle_IPI+0x36c/0x3d8
[ 3992.632012]  do_handle_IPI from ipi_handler+0x20/0x28
[ 3992.632034]  ipi_handler from handle_percpu_devid_irq+0xac/0x278
[ 3992.632056]  handle_percpu_devid_irq from 
generic_handle_domain_irq+0x30/0x40

[ 3992.632074]  generic_handle_domain_irq from gic_handle_irq+0x90/0xb0
[ 3992.632090]  gic_handle_irq from generic_handle_arch_irq+0x58/0x78
[ 3992.632110]  generic_handle_arch_irq from __irq_svc+0x88/0xdc
[ 3992.632128] Exception stack(0xc1401f10 to 0xc1401f58)
[ 3992.632138] 1f00:  
c1064990 00999581 c0321080
[ 3992.632148] 1f20: c158d340  c140f89c c140f8fc  
 c9fff9f7 

[ 3992.632158] 1f40: 03126e98 c1401f60 c030a750 c030a754 60030013 
[ 3992.632164]  __irq_svc from arch_cpu_idle+0x40/0x44
[ 3992.632179]  arch_cpu_idle from default_idle_call+0x48/0x8c
[ 3992.632195]  default_idle_call from do_idle+0xbc/0x12c
[ 3992.632215]  do_idle from cpu_startup_entry+0x20/0x24
[ 3992.632234]  cpu_startup_entry from rest_init+0xd8/0xdc
[ 3992.632257]  rest_init from arch_post_acpi_subsys_init+0x0/0x18
[ 3992.632290] CPU2: stopping
[ 3992.632299] CPU: 2 PID: 240 Comm: systemd-journal Tainted: G C   L 
 6.1.0-9-rt-armmp #1  Debian 6.1.27-1


Best regards

--
  -- Jean-Marc LACROIX  (06 82 29 98 66) --
-- mailto : jeanmarc.lacr...@free.fr   --

Bug#1041373: toot: bug suppression must be thwarted

[debbug . 1041373]

Package: toot
Version: 0.27.0-1
Followup-For: Bug #1041373
X-Debbugs-Cc: debbug.1041...@sideload.33mail.com

> yet you wont receive any updates

There are countless factors in determining the version that best
serves any particular user. It is not for you to decide or control
what version a user runs. When you suggest that users upgrade their
whole system in order to run a more recent version of a social media
app to overcome a trivial flaw, this is reckless advice. You need to
understand that every package has dependencies. Those version
dependencies either support or break other packages. Every dist
upgrade results in gains /and losses/. You cannot competently
prescribe arbitrarily to all users that they “chase the shiny” at all
costs. It’s an absurdity to impose this on others most particularly
when they are still running officially supported versions.

> and instead you spam the debian bug tracking system with "reports"
> that are just noise (like this one, since it's fixed upstream).

You’ve misidentified the problem. The problem was not with the version
I was running; it’s that I did not check the release notes
first. Please re-read my message from the top. I admitted to that
error which AFAIK only involves bug 1041373, not the others.

Users can run a range of different officially supported versions and
the Debian BTS is rightfully designed to accommodate this.

> if i go in a bakery and scream "my chair broke, i want a new one!"
> it serves no one purpose.

The misunderstanding here is that you think I am an individual looking
for personalized support. The bugs I have reported are *community*
bugs. So the /fallacy of analogy/ here is that you say “my” chair
broke, when in fact it’s a community resource that broke. By
extension, community bug reports serve the community, not the
individual.

In fact the individual bug submitter finds workarounds because bugs
are not fixed overnight and a Debian user won’t often see the change
for years out. By the time the lifecycle of the bug runs its course,
any benefit to the original submitter is marginal since their
workaround or alternate workflow is already established. The
beneficiaries of fixes are future users.

> You need to submit the requests in the right place for the right
> people to act on.

The “right place” differs from one user to the next. It is walled
gardens who decide who may enter, not users who decide whether a
walled garden must serve them. Often there is no “right place” for a
given user. Some bugs go entirely unreported because of obnoxious
CAPTCHAs or surveillance capitalist MitMs. Yes it’s clear that you’re
a gmail pawn but try not to view everyone through the “surveillance
capitalism is fine for everyone” lens. That’s not for you to control.

Users will contribute bug reports wherever they /can/. It’s rightfully
their choice. Demanding that voluntary contributors bend to your needs
is quite obnoxious.

> yeah which you conveniently omitted to report the big `if` before
> hand: "If you file a bug in Debian, don't send a copy to the upstream
> software maintainers yourself"

I simply pointed you to the whole document. How can that be an
omission?  The only omission I see is in your cherry picked requoting
of the doc, which omitted:

  “If necessary, the maintainer of the package will forward the bug
   upstream.”

> -- what we are telling you

Speak for youself please.

> is to NOT file these bugs at all in the debian bts, but directly
> upstream.

On what authority do you believe you can override the bug reporting
procedure document?  Clearly the policy you were shown gives
contributors a choice. If you don’t like that, it’s on you to change
it. This is not the appropriate place for that.

> you dont like github?

Github doesn’t like me either. Red herring nonetheless. Who likes who
is irrelevent when the Debian procedure gives contributors a choice.

> If i were the maintainer of this package, i'd bulk close all your
> report and invalid and ask the BTS maintainer to temporarily ban you
> from submitting more.

Then you would be a reckless maintainer. Nothing is worse for quality
than a bug suppressing emotionally hot-headed maintainer.

Bug#1041436: [debian bookworm] brcmfmac mmc0:0001:1: firmware: failed to load brcm/brcmfmac43430-sdio.friendlyarm,nanopi-r1.bin (-2)

[Jean-Marc LACROIX]

Source: firmware-brcm80211
Version: 20230515-3
Severity: grave

Dear Debian team,

I  am trying  to install  firmware-brcm80211 on   nanopir1 SBC running
Debian 12,  because this target  contains one  internal WIFI  based on
Broadcom 43430 chip.

I have installed Debian kernel linux-image-rt-armmp from Debian.

Because there is also one another bug on DTS in kernel to support Wifi
chip, i  have installed  on  this target  Debian kernel from  "trixie"
release. With this release, DTS is more recent (!).

I have also installed firmware-brcm80211 from "trixie," so that Debian
firmwares are the most recent also.

The current configuration is ...

root@nanopi-r1:~# uname -a
Linux nanopi-r1 6.3.0-1-rt-armmp #1 SMP PREEMPT_RT Debian 6.3.7-1 
(2023-06-12) armv7l GNU/Linux


root@nanopi-r1:~# dpkg -l |grep firmware
ii  firmware-brcm80211 20230515-3all  Binary 
firmware for Broadcom/Cypress 802.11 wireless cards
ii  firmware-linux-free20200122-1all  Binary 
firmware for various drivers in the Linux kernel

root@nanopi-r1:~# dpkg -l |grep linux-image
ii  linux-image-6.3.0-1-rt-armmp   6.3.7-1   armhfLinux 
6.3 for ARMv7 multiplatform compatible SoCs, PREEMPT_RT
ii  linux-image-rt-armmp   6.3.7-1   armhfLinux 
for ARMv7 multiplatform compatible SoCs (meta-package)


root@nanopi-r1:~# apt policy
Package files:
 100 /var/lib/dpkg/status
 release a=now
  90 http://ftp.de.debian.org/debian trixie/non-free-firmware armhf 
Packages
 release 
o=Debian,a=testing,n=trixie,l=Debian,c=non-free-firmware,b=armhf

 origin ftp.de.debian.org
  90 http://ftp.de.debian.org/debian trixie/non-free armhf Packages
 release o=Debian,a=testing,n=trixie,l=Debian,c=non-free,b=armhf
 origin ftp.de.debian.org
  90 http://ftp.de.debian.org/debian trixie/contrib armhf Packages
 release o=Debian,a=testing,n=trixie,l=Debian,c=contrib,b=armhf
 origin ftp.de.debian.org
  90 http://ftp.de.debian.org/debian trixie/main armhf Packages
 release o=Debian,a=testing,n=trixie,l=Debian,c=main,b=armhf
 origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian bookworm/non-free-firmware armhf 
Packages
 release 
v=12.0,o=Debian,a=stable,n=bookworm,l=Debian,c=non-free-firmware,b=armhf

 origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian bookworm/non-free armhf Packages
 release 
v=12.0,o=Debian,a=stable,n=bookworm,l=Debian,c=non-free,b=armhf

 origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian bookworm/contrib armhf Packages
 release v=12.0,o=Debian,a=stable,n=bookworm,l=Debian,c=contrib,b=armhf
 origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian bookworm/main armhf Packages
 release v=12.0,o=Debian,a=stable,n=bookworm,l=Debian,c=main,b=armhf
 origin ftp.de.debian.org
Pinned packages:
 firmware-brcm80211 -> 20230515-3 with priority 980
 linux-image-rt-armmp -> 6.3.7-1 with priority 980
root@nanopi-r1:~#

With  this  configuration,   when inserting  wifi   module (brcmfmac),
following kernel message is ...

[ 2208.995544] usbcore: deregistering interface driver brcmfmac
[ 2243.459746] brcmfmac: brcmf_fw_alloc_request: using 
brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 2243.460057] brcmfmac mmc0:0001:1: firmware: failed to load 
brcm/brcmfmac43430-sdio.friendlyarm,nanopi-r1.bin (-2)
[ 2243.460155] brcmfmac mmc0:0001:1: firmware: failed to load 
brcm/brcmfmac43430-sdio.friendlyarm,nanopi-r1.bin (-2)
[ 2243.460166] brcmfmac mmc0:0001:1: Direct firmware load for 
brcm/brcmfmac43430-sdio.friendlyarm,nanopi-r1.bin failed with error -2
[ 2243.461611] brcmfmac mmc0:0001:1: firmware: direct-loading firmware 
brcm/brcmfmac43430-sdio.bin
[ 2243.462219] brcmfmac mmc0:0001:1: firmware: failed to load 
brcm/brcmfmac43430-sdio.friendlyarm,nanopi-r1.txt (-2)
[ 2243.462333] brcmfmac mmc0:0001:1: firmware: failed to load 
brcm/brcmfmac43430-sdio.friendlyarm,nanopi-r1.txt (-2)
[ 2243.462460] brcmfmac mmc0:0001:1: firmware: failed to load 
brcm/brcmfmac43430-sdio.txt (-2)
[ 2243.462549] brcmfmac mmc0:0001:1: firmware: failed to load 
brcm/brcmfmac43430-sdio.txt (-2)
[ 2243.462561] brcmfmac mmc0:0001:1: Direct firmware load for 
brcm/brcmfmac43430-sdio.txt failed with error -2

[ 2243.462567] usbcore: registered new interface driver brcmfmac

It seems SDIO  chip is correctly detected,  but at the same time,  not
possible to  insert firmware.   As  a  result,  there  is no   network
interface, because ...


root@nanopi-r1:~# ip link ls
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0:  mtu 1500 qdisc noop state DOWN mode 
DEFAULT group default qlen 1000

link/ether 02:81:9f:b8:31:a7 brd ff:ff:ff:ff:ff:ff
altname end0
3: eth1:  mtu 1500 qdisc fq_codel state 
UP mode DEFAULT group default qlen 1000

link/ether a2:a8:a0:49:74:4b brd ff:ff:ff:ff:ff:ff
root@nanopi-r1:~#

Bug#1035506: please update libliftoff

[Stephan Lachnit]

Thanks, uploaded

Bug#1041435: bitsnpicas: unusable, chokes with nullptr exception

[Nilesh Patra]

Package: bitsnpicas
Version: 2.0+ds-1
Severity: serious
X-Debbugs-Cc: t...@debian.org

Dear Maintainer,

bitsnpicas is currently unusable and chokes with:

$ bitsnpicas
Exception in thread "main" java.lang.NullPointerException
at java.base/java.io.Reader.(Reader.java:168)
at java.base/java.io.InputStreamReader.(InputStreamReader.java:76)
at java.base/java.util.Scanner.(Scanner.java:566)
at com.kreative.unicode.data.Encoding.(Encoding.java:26)
at com.kreative.unicode.data.EncodingList.(EncodingList.java:58)
at com.kreative.unicode.data.EncodingList.instance(EncodingList.java:20)
at 
com.kreative.bitsnpicas.edit.GlyphListModelList$GlyphListModelRootNode.(GlyphListModelList.java:93)
at 
com.kreative.bitsnpicas.edit.GlyphListModelList.(GlyphListModelList.java:29)
at 
com.kreative.bitsnpicas.edit.GlyphListPanel.(GlyphListPanel.java:34)
at 
com.kreative.bitsnpicas.edit.BitmapListFrame.(BitmapListFrame.java:19)
at com.kreative.bitsnpicas.edit.Main.openFont(Main.java:158)
at com.kreative.bitsnpicas.edit.Main.newBitmapFont(Main.java:71)
at com.kreative.bitsnpicas.edit.Main.main(Main.java:55)
at com.kreative.bitsnpicas.main.Main.main(Main.java:12)

This is because of the exclusion of following files w/o patching the
code properly

 main/java/BitsNPicas/src/com/kreative/unicode/mappings/Mac*.txt
 main/java/BitsNPicas/src/com/kreative/unicode/mappings/Windows*.txt
 main/java/BitsNPicas/src/com/kreative/unicode/mappings/IBM*.txt

I applied a patch trying to exclude unicodes and can get it to a usable state. 
The patch is
attached with this bug report. However, even after being able to launch
the menu, I see windows and IBM related unicode options in the menu. I
did not dive deep into the code, but it could be stemming from

main/java/BitsNPicas/src/com/kreative/unicode/data/unidata.ucd

In which case the unicode bin itself contains non-free content and needs
fixing accordingly.

Thanks,
Nilesh

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

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

Versions of packages bitsnpicas depends on:
ii  xdg-utils  1.1.3-4.1

bitsnpicas recommends no packages.

bitsnpicas suggests no packages.

-- no debconf information
diff --git a/main/java/BitsNPicas/Makefile b/main/java/BitsNPicas/Makefile
index d339248..3955afc 100644
--- a/main/java/BitsNPicas/Makefile
+++ b/main/java/BitsNPicas/Makefile
@@ -48,47 +48,16 @@ BitsNPicas.jar: bin
 	jar cmf dep/MANIFEST.MF BitsNPicas.jar -C bin com/kreative/unicode -C bin com/kreative/bitsnpicas
 	chmod +x BitsNPicas.jar
 
-BitsNPicas.app: BitsNPicas-Pre10.15.app BitsNPicas-MacOS10.15.app BitsNPicas-MacOS11.0.app
+BitsNPicas.app: BitsNPicas-Pre10.15.app
 
 BitsNPicas-Pre10.15.app: dep BitsNPicas.jar
-	mkdir -p BitsNPicas-Pre10.15.app/Contents/MacOS
 	mkdir -p BitsNPicas-Pre10.15.app/Contents/Resources/Java
 	cp -f dep/PkgInfo BitsNPicas-Pre10.15.app/Contents
 	cp -f dep/Info.plist BitsNPicas-Pre10.15.app/Contents
-	cp -f dep/universalJavaApplicationStub-Pre10.15 BitsNPicas-Pre10.15.app/Contents/MacOS/BitsNPicas
 	cp -f dep/kbnp*.icns dep/dmov*.icns dep/movr*.icns BitsNPicas-Pre10.15.app/Contents/Resources
 	cp -f dep/*.jar BitsNPicas-Pre10.15.app/Contents/Resources/Java
 	cp -f BitsNPicas.jar BitsNPicas-Pre10.15.app/Contents/Resources/Java
 
-BitsNPicas-MacOS10.15.app: dep BitsNPicas.jar
-	mkdir -p BitsNPicas-MacOS10.15.app/Contents/MacOS
-	mkdir -p BitsNPicas-MacOS10.15.app/Contents/Resources/Java
-	cp -f dep/PkgInfo BitsNPicas-MacOS10.15.app/Contents
-	cp -f dep/Info.plist BitsNPicas-MacOS10.15.app/Contents
-	cp -f dep/universalJavaApplicationStub-MacOS10.15 BitsNPicas-MacOS10.15.app/Contents/MacOS/BitsNPicas
-	cp -f dep/kbnp*.icns dep/dmov*.icns dep/movr*.icns BitsNPicas-MacOS10.15.app/Contents/Resources
-	cp -f dep/*.jar BitsNPicas-MacOS10.15.app/Contents/Resources/Java
-	cp -f BitsNPicas.jar BitsNPicas-MacOS10.15.app/Contents/Resources/Java
-
-BitsNPicas-MacOS11.0.app: dep BitsNPicas.jar
-	mkdir -p BitsNPicas-MacOS11.0.app/Contents/MacOS
-	mkdir -p BitsNPicas-MacOS11.0.app/Contents/Resources/Java
-	cp -f dep/PkgInfo BitsNPicas-MacOS11.0.app/Contents
-	cp -f dep/Info.plist BitsNPicas-MacOS11.0.app/Contents
-	cp -f dep/universalJavaApplicationStub-MacOS11.0 BitsNPicas-MacOS11.0.app/Contents/MacOS/BitsNPicas
-	cp -f dep/kbnp*.icns dep/dmov*.icns dep/movr*.icns BitsNPicas-MacOS11.0.app/Contents/Resources
-	cp -f dep/*.jar BitsNPicas-MacOS11.0.app/Contents/Resources/Java
-	cp -f BitsNPicas.jar BitsNPicas-MacOS11.0.app/Contents/Resources/Java
-
-BitsNPicas.dmg: BitsNPicas.app
-	mkdir -p dmgtmp
-	cp -R BitsNPicas-Pre10.15.app dmgtmp
-	cp 

Bug#1041434: ITP: rust-cranelift -- low-level retargetable code generator

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-cranelift
  Version : 0.97.1
  Upstream Contact: The Wasmtime Project Developers
* URL : https://github.com/bytecodealliance/wasmtime
* License : Apache-2.0 with LLVM exception
  Programming Lang: Rust
  Description : low-level retargetable code generator

 Cranelift is a low-level retargetable code generator.
 It translates a target-independent intermediate representation
 into executable machine code.

This package is needed by swc (bug#991761).
It will be maintained in the collaborative debian section of salsa at
https://salsa.debian.org/debian/rust-wasmtime
(wasmtime is a monorepo also containing Cranelift - if there is interest
and the needed dependencies get packaged, the package may in future be
extended to also provide wasmtime itself)

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS27GEACgkQLHwxRsGg
ASHqog//QFxRjTnYEPBqPbJjOwnL+9kRs5IQgdOZdnO1O+Aw1A0mRamKiznbjWnI
mBICExMTr4vvu29Z1NK63Ih28N1Yu4xo/bj2b5gDdNtnSs1uHsMeF3LWYhcS0AYd
DhQ+DiMHX9sA0fLoXLouNd2RSBqNOhHDqSV4ry0/W5ugNw2v5likDEjASPCxV0jr
67NWeOV7lA3oxv0/8guyHGTHiyswh9oWC+qljHTGZ82oofAQa90PEq9jB/orrzpR
Rr3y/haQLXz1NG2AwtIbKGtk8QGYkFKsWyoiA5bpg+anmJK+h67/h/mUu/0Lu2F/
y1+CF3Qx0BSmKP47EIOoghpwhi0l8SarXd1bzD1NWziONZCOV6pXSTHc6kWAIFBQ
CWRoFD8LbXQ3dCGD0ZFWRl0os6xdCpC9pTH2UDkGSlIOFhUZQKLXK2KtlzuixOZJ
j2GDXe2HfW4XFw6GyFJ+fIIuTHHkTD3XGy1oEKlylMnlokfmJLE2lI3IxElQANXS
FzCARK5mujqH2eEbASSZy5Y/J0uROKOGL5oQCfbAV0h54iep96S2rMC8PvhZpawI
3eiAoTVdiQXj7bSJUEC2ghZqgjfH6SDsQkGEoC/TVl5y7E1xGpJnUMjo/3xVMoIz
CYo+Dt3SmNDkWKqwrs87+WtsPGPjauc7pHXm1RKWFMbvqS+HdkY=
=CTzG
-END PGP SIGNATURE-

Bug#1041433: ITP: rust-id-arena -- simple id-based arena

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-id-arena
  Version : 2.2.1
  Upstream Contact: Nick Fitzgerald 
* URL : https://github.com/fitzgen/id-arena
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : simple id-based arena

 id-arena is a library
 to allocate objects and get an identifier for that object back,
 not a reference to the allocated object.
 Given an id, you can get a shared or exclusive reference
 to the allocated object from the arena.
 This id-based approach is useful
 for constructing mutable graph data structures.

This package is needed by swc (bug#991761).
It will be maintained in the collaborative debian section of salsa at
https://salsa.debian.org/debian/rust-id-arena

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS25kQACgkQLHwxRsGg
ASEEkhAAlbxqMawN2g8N0k39ooY+dMWMHpQqdkoqEmnYxbg1uYyRK6ioxyAXoiec
Jj5/E4lzU9KXQOiiOIdpOgTvunhC+E5uPScOGs1rYnwUgHzI4tniN0SPRhcucpa8
QDdI9PFTSvPxSAeX+xVjFt1r06/lbXMMhNixVDYOu3M9GEX4Q2w0RzaKLwxBdOrW
j6iviB6LtgB5pZaWrxsTy3XgB8gr43qgMnd/Mh+IY2ch8h+ge1N3/ti1/BPgxz3C
ioc0ahisl+DruBFAZf4v3u+mcLitcv1g1nrfmE0bSV+JiudE2m7PJibpUXzPBWoK
lCoEyBmA+jRzWynuiKqcZre1A6ckW/lQ2YkR+/IlHWHSLgQdCixUa4kiDE93hqcd
+g+vEbqFtzWJwTr7g1XCs9oPejPe/b2XUz2qrxsSHaqxgPOJVE5Vrcp0ROt5umTz
7E6iQUhq6PeAvZz7uGp3r4uJqntdQT93zvv9085iexeBJR2PaJThspMCMBJyNNne
gZrB8p1rlGXy/xft7VJPhF/7p+8uBEUXb6PYDFs4AcM3QeCBeRNqOlkX0J/fATis
ODjEOyjR9sHwSO5XSAiazBh/BH+VnFUOl2dSW3jbeowrioYCFy+6GJbfIZ41NMkr
YmFlGkjx+Eu9Cr1V/VsX7KOgBPACTXtODJ4HMU3sYPL2kj3/8lU=
=AWM3
-END PGP SIGNATURE-

Bug#1041432: box64: unsatisfiable dependencies

[Jeremy Bícha]

Source: box64
Version: 0.2.2+dfsg-2
Severity: serious

https://tracker.debian.org/pkg/box64 says that box64 is unable to
migrate into Testing because it has unsatisfiable dependencies on
amd64, arm64, ppc64el (and I guess riscv64)

Thank you,
Jeremy Bícha

Bug#1037346: cyrus-imapd: Stable should have gone from Cyrus 3.2.6 to 3.2.10 first

[Gijs Hillenius]

Package: cyrus-imapd
Version: 3.6.1-4
Followup-For: Bug #1037346

Dear Maintainers

The documentation 

https://www.cyrusimap.org/3.6/imap/download/upgrade.html#versions-to-upgrade-from

tells me that we should have upgraded from Cyrus 3.2.6 to 3.2.10 before going to
3.6.x. Bullseye stable didn't take us that way, and perhaps neither did 
Bullseye-backports.

Perhaps a check should be made, and stop Cyrus 3.2 from being upgraded?

Best wishes,




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

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

Versions of packages cyrus-imapd depends on:
ii  cyrus-common  3.6.1-4
ii  libc6 2.36-9
ii  libcom-err2   1.47.0-2
ii  libsasl2-22.1.28+dfsg-10
ii  libssl3   3.0.9-1
ii  libwrap0  7.6.q-32
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages cyrus-imapd recommends:
ii  rsync  3.2.7-1

cyrus-imapd suggests no packages.

-- no debconf information

Bug#1041431: ITP: rust-souper-ir -- library for manipulating Souper IR

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-souper-ir
  Version : 2.1.0
  Upstream Contact: Nick Fitzgerald 
* URL : https://github.com/fitzgen/souper-ir
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : library for manipulating Souper IR

 souper-ir provides AST types for parsing or generating Souper IR.
 It is a suitable building block
 either for writing a custom LHS extractor,
 or for translating learned optimizations
 into your own peephole optimizations pass.

This package is needed by swc (bug#991761).
It will be maintained in the collaborative debian section of salsan at
https://salsa.debian.org/debian/rust-souper-ir

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS24p4ACgkQLHwxRsGg
ASFoNg//X+yn+nyVrFlZQIqTuazhXwczwIV4e/PEE4YqsCY3Ms21cDe1X//s4mUZ
IRV5N4GUUkmcmqN4CUxpkYp3vTpin8izkpa1tmAh5gG3WKMkA/5QY5NcroOcHLcK
IoL/IUAVjB2w1/nItUEkKiNJnc+DqpRZEz66xUE7JuwK1VR3xc00kwwoJSCpQXJ2
LSDwR7xpct/t7Atua5/rzQlXsaW0fGORFuGFTvkaR1JuqnmKN8KgxbJ5KfHYel5B
AaGn7z23boQ69clJGXBKwBNeTP/sqE/q9byPJRqtNGuUtqZ9dxfwWuMhI82WZv9z
6G83lNDw9r2OeBviNGiWsmC/9OEoMXT26wm3F9zWPZgWRUi/Q+ZRcpVAX77xykyv
R7gzJ5oBSFoQJGq3bfkFhgiU/1/g1g/D3HN8uBZR/ODl50yTHnScAR9quc06SK7u
Lzesj6ON4F8ZDc6oYSVrakvwxcwsIRw+kko0BB6+euuMJutzAwX8BbDi17t50w0m
0WhaMc+i6nH//aHwQ1VgkhV3PMZ4VhC2cgux2Bcnr4NdPuG1XbhBLnJpSWtsUeVV
kEJd00cV6ZNddNHtoqz8TDfi5ukJM+YfgbWWrwCRdaM4YnT3HB++cBgL3Qzgqe+A
BRgok4h+4oi0opbS6xzyEDEbXGA2lIL2mxhSiixT4MkmlFzwwkw=
=Ul/b
-END PGP SIGNATURE-

Bug#1041429: restrictedpython: CVE-2023-37271

[Moritz Mühlenhoff]

Source: restrictedpython
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for restrictedpython.

CVE-2023-37271[0]:
| RestrictedPython is a tool that helps to define a subset of the
| Python language which allows users to provide a program input into a
| trusted environment. RestrictedPython does not check access to stack
| frames and their attributes. Stack frames are accessible within at
| least generators and generator expressions, which are allowed inside
| RestrictedPython. Prior to versions 6.1 and 5.3, an attacker with
| access to a RestrictedPython environment can write code that gets
| the current stack frame in a generator and then walk the stack all
| the way beyond the RestrictedPython invocation boundary, thus
| breaking out of the restricted sandbox and potentially allowing
| arbitrary code execution in the Python interpreter. All
| RestrictedPython deployments that allow untrusted users to write
| Python code in the RestrictedPython environment are at risk. In
| terms of Zope and Plone, this would mean deployments where the
| administrator allows untrusted users to create and/or edit objects
| of type `Script (Python)`, `DTML Method`, `DTML Document` or `Zope
| Page Template`. This is a non-default configuration and likely to be
| extremely rare. The problem has been fixed in versions 6.1 and 5.3.

https://github.com/zopefoundation/RestrictedPython/security/advisories/GHSA-wqc8-x2pr-7jqh
https://github.com/zopefoundation/RestrictedPython/commit/c8eca66ae49081f0016d2e1f094c3d72095ef531
 (master)
https://github.com/zopefoundation/RestrictedPython/commit/d8c5aa72c5d0ec8eceab635d93d6bc8321116002
 (5.3)
   

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-37271
https://www.cve.org/CVERecord?id=CVE-2023-37271

Please adjust the affected versions in the BTS as needed.

Bug#1034282: RFS: ukui-app-widget/1.0.1-1 [ITP] -- ukui app widget test

[Boyuan Yang]

Control: tags -1 +moreinfo

Hi,

On Thu, 13 Apr 2023 01:11:05 +0800 xibowen  wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ukui-app-widget":
>   https://mentors.debian.net/package/ukui-app-widget/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x https://mentors.debian.net/debian/pool/main/u/ukui-app-widget/ukui-
> app-widget_1.0.1-1.dsc

Several issues:

* Your package embeds multiple copies of QtSimpleApplication. This is not a good
practice at all. Can you work with upstream to only include one copy?

* All QtSimpleApplication source code files have executable permission. Please
consider fixing it upstream as well.

* Your debian/copyright file did not include copyright information for most
QtSimpleApplication source code files. Please fix it.

Thanks,
Boyuan Yang


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

Bug#1041428: sqlfluff: CVE-2023-36830

[Moritz Mühlenhoff]

Source: sqlfluff
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for sqlfluff.

CVE-2023-36830[0]:
| SQLFluff is a SQL linter. Prior to version 2.1.2, in environments
| where untrusted users have access to the config files, there is a
| potential security vulnerability where those users could use the
| `library_path` config value to allow arbitrary python code to be
| executed via macros. For many users who use SQLFluff in the context
| of an environment where all users already have fairly escalated
| privileges, this may not be an issue - however in larger user bases,
| or where SQLFluff is bundled into another tool where developers
| still wish to give users access to supply their on rule
| configuration, this may be an issue.  The 2.1.2 release offers the
| ability for the `library_path` argument to be overwritten on the
| command line by using the `--library-path` option. This overrides
| any values provided in the config files and effectively prevents
| this route of attack for users which have access to the config file,
| but not to the scripts which call the SQLFluff CLI directly. A
| similar option is provided for the Python API, where users also have
| a greater ability to further customise or override configuration as
| necessary. Unless `library_path` is explicitly required, SQLFluff
| maintainers recommend using the option `--library-path none` when
| invoking SQLFluff which will disable the `library-path` option
| entirely regardless of the options set in the configuration file or
| via inline config directives. As a workaround, limiting access to -
| or otherwise validating configuration files before they are ingested
| by SQLFluff will provides a similar effect and does not require
| upgrade.

https://github.com/sqlfluff/sqlfluff/security/advisories/GHSA-jqhc-m2j3-fjrx
https://github.com/sqlfluff/sqlfluff/pull/4925
  

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-36830
https://www.cve.org/CVERecord?id=CVE-2023-36830

Please adjust the affected versions in the BTS as needed.

Bug#1041430: ruby-sanitize: CVE-2023-36823

[Moritz Mühlenhoff]

Source: ruby-sanitize
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for ruby-sanitize.

CVE-2023-36823[0]:
| Sanitize is an allowlist-based HTML and CSS sanitizer. Using
| carefully crafted input, an attacker may be able to sneak arbitrary
| HTML and CSS through Sanitize starting with version 3.0.0 and prior
| to version 6.0.2 when Sanitize is configured to use the built-in
| "relaxed" config or when using a custom config that allows `style`
| elements and one or more CSS at-rules. This could result in cross-
| site scripting or other undesired behavior when the malicious HTML
| and CSS are rendered in a browser. Sanitize 6.0.2 performs
| additional escaping of CSS in `style` element content, which fixes
| this issue. Users who are unable to upgrade can prevent this issue
| by using a Sanitize config that doesn't allow `style` elements,
| using a Sanitize config that doesn't allow CSS at-rules, or by
| manually escaping the character sequence `https://github.com/rgrove/sanitize/commit/76ed46e6dc70820f38efe27de8dabd54dddb5220
 (v6.0.2)
https://github.com/rgrove/sanitize/security/advisories/GHSA-f5ww-cq3m-q3g7
  

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-36823
https://www.cve.org/CVERecord?id=CVE-2023-36823

Please adjust the affected versions in the BTS as needed.

Bug#1041427: bitcoin: CVE-2023-37192

[Moritz Mühlenhoff]

Source: bitcoin
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for bitcoin.

CVE-2023-37192[0]:
| Memory management and protection issues in Bitcoin Core v22 allows
| attackers to modify the stored sending address within the app's
| memory, potentially allowing them to redirect Bitcoin transactions
| to wallets of their own choosing.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-37192
https://www.cve.org/CVERecord?id=CVE-2023-37192

Please adjust the affected versions in the BTS as needed.

Bug#1041424: gradle: CVE-2023-35946 CVE-2023-35947

[Moritz Mühlenhoff]

Source: gradle
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for gradle. Not sure if
the rather old version of Gradle in Debian is affected, please have
a look:

CVE-2023-35946[0]:
| Gradle is a build tool with a focus on build automation and support
| for multi-language development. When Gradle writes a dependency into
| its dependency cache, it uses the dependency's coordinates to
| compute a file location. With specially crafted dependency
| coordinates, Gradle can be made to write files into an unintended
| location. The file may be written outside the dependency cache or
| over another file in the dependency cache. This vulnerability could
| be used to poison the dependency cache or overwrite important files
| elsewhere on the filesystem where the Gradle process has write
| permissions. Exploiting this vulnerability requires an attacker to
| have control over a dependency repository used by the Gradle build
| or have the ability to modify the build's configuration. It is
| unlikely that this would go unnoticed. A fix has been released in
| Gradle 7.6.2 and 8.2 to protect against this vulnerability. Gradle
| will refuse to cache dependencies that have path traversal elements
| in their dependency coordinates. It is recommended that users
| upgrade to a patched version. If you are unable to upgrade to Gradle
| 7.6.2 or 8.2, `dependency verification` will make this vulnerability
| more difficult to exploit.

https://github.com/gradle/gradle/security/advisories/GHSA-2h6c-rv6q-494v
https://github.com/gradle/gradle/commit/859eae2b2acf751ae7db3c9ffefe275aa5da0d5d
 (v8.2.0-RC3)
https://github.com/gradle/gradle/commit/b07e528feb3a5ffa66bdcc358549edd73e4c8a12
 (v8.2.0-RC3)
   
CVE-2023-35947[1]:
| Gradle is a build tool with a focus on build automation and support
| for multi-language development. In affected versions when unpacking
| Tar archives, Gradle did not check that files could be written
| outside of the unpack location. This could lead to important files
| being overwritten anywhere the Gradle process has write permissions.
| For a build reading Tar entries from a Tar archive, this issue could
| allow Gradle to disclose information from sensitive files through an
| arbitrary file read. To exploit this behavior, an attacker needs to
| either control the source of an archive already used by the build or
| modify the build to interact with a malicious archive. It is
| unlikely that this would go unnoticed. A fix has been released in
| Gradle 7.6.2 and 8.2 to protect against this vulnerability. Starting
| from these versions, Gradle will refuse to handle Tar archives which
| contain path traversal elements in a Tar entry name. Users are
| advised to upgrade. There are no known workarounds for this
| vulnerability.### Impact  This is a path traversal vulnerability
| when Gradle deals with Tar archives, often referenced as TarSlip, a
| variant of ZipSlip.  * When unpacking Tar archives, Gradle did not
| check that files could be written outside of the unpack location.
| This could lead to important files being overwritten anywhere the
| Gradle process has write permissions. * For a build reading Tar
| entries from a Tar archive, this issue could allow Gradle to
| disclose information from sensitive files through an arbitrary file
| read.  To exploit this behavior, an attacker needs to either control
| the source of an archive already used by the build or modify the
| build to interact with a malicious archive. It is unlikely that this
| would go unnoticed.  Gradle uses Tar archives for its [Build
| Cache](https://docs.gradle.org/current/userguide/build_cache.html).
| These archives are safe when created by Gradle. But if an attacker
| had control of a remote build cache server, they could inject
| malicious build cache entries that leverage this vulnerability. This
| attack vector could also be exploited if a man-in-the-middle can be
| performed between the remote cache and the build.  ### Patches  A
| fix has been released in Gradle 7.6.2 and 8.2 to protect against
| this vulnerability. Starting from these versions, Gradle will refuse
| to handle Tar archives which contain path traversal elements in a
| Tar entry name.  It is recommended that users upgrade to a patched
| version.  ### Workarounds  There is no workaround.  * If your build
| deals with Tar archives that you do not fully trust, you need to
| inspect them to confirm they do not attempt to leverage this
| vulnerability. * If you use the Gradle remote build cache, make sure
| only trusted parties have write access to it and that connections to
| the remote cache are properly secured.  ### References  * [CWE-22:
| Improper Limitation of a Pathname to a Restricted Directory ('Path
| Traversal')](https://cwe.mitre.org/data/definitions/22.html) *
| [Gradle Build
| Cache](https://docs.gradle.org/current/userguide/build_cache.html) *
| 

Bug#1041425: pacparser: CVE-2023-37360

[Moritz Mühlenhoff]

Source: pacparser
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for pacparser.

CVE-2023-37360[0]:
| pacparser_find_proxy in Pacparser before 1.4.2 allows JavaScript
| injection, and possibly privilege escalation, when the attacker
| controls the URL (which may be realistic within enterprise security
| products).

https://github.com/manugarg/pacparser/security/advisories/GHSA-62q6-v997-f7v9
https://github.com/manugarg/pacparser/commit/0bf0636de624996fe202b51eec8a58abd774269e
 (v1.4.2)
  

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-37360
https://www.cve.org/CVERecord?id=CVE-2023-37360

Please adjust the affected versions in the BTS as needed.

Bug#1041423: cjose: CVE-2023-37464

[Moritz Mühlenhoff]

Source: cjose
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for cjose.

CVE-2023-37464[0]:
| OpenIDC/cjose is a C library implementing the Javascript Object
| Signing and Encryption (JOSE). The AES GCM decryption routine
| incorrectly uses the Tag length from the actual Authentication Tag
| provided in the JWE. The spec  says that a fixed length of 16 octets
| must be applied. Therefore this bug allows an attacker to provide a
| truncated Authentication Tag and to modify the JWE accordingly.
| Users should upgrade to a version >= 0.6.2.2. Users unable to
| upgrade should avoid using AES GCM encryption and replace it with
| another encryption algorithm (e.g. AES CBC).

https://github.com/OpenIDC/cjose/security/advisories/GHSA-3rhg-3gf2-6xgj
https://github.com/OpenIDC/cjose/commit/7325e9a5e71e2fc0e350487ecac7d84acdf0ed5e
 (v0.6.2.2)
  

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-37464
https://www.cve.org/CVERecord?id=CVE-2023-37464

Please adjust the affected versions in the BTS as needed.

Bug#1041426: hnswlib: CVE-2023-37365

[Moritz Mühlenhoff]

Source: hnswlib
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for hnswlib.

CVE-2023-37365[0]:
| Hnswlib 0.7.0 has a double free in init_index when the M argument is
| a large integer.

https://github.com/nmslib/hnswlib/issues/467
 

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-37365
https://www.cve.org/CVERecord?id=CVE-2023-37365

Please adjust the affected versions in the BTS as needed.

Bug#1041418: ITP: rust-slice-group-by -- iterators over groups in slices and strs

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2023-07-18 19:57:46)
> This package is needed by swc (bug#991761).
> It will be maintained in the collaborative debian section of salsan at
> https://salsa.debian.org/debian/rust-slice-by-group

Correction, it is at https://salsa.debian.org/debian/rust-slice-group-by
(I accidentally flipped the last two words).

 - Jonas

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

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

signature.asc
Description: signature

Bug#1041422: openrefine: CVE-2023-37476

[Moritz Mühlenhoff]

Source: openrefine
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for openrefine.

CVE-2023-37476[0]:
| OpenRefine is a free, open source tool for data processing. A
| carefully crafted malicious OpenRefine project tar file can be used
| to trigger arbitrary code execution in the context of the OpenRefine
| process if a user can be convinced to import it. The vulnerability
| exists in all versions of OpenRefine up to and including 3.7.3.
| Users should update to OpenRefine 3.7.4 as soon as possible. Users
| unable to upgrade should only import OpenRefine projects from
| trusted sources.

https://github.com/OpenRefine/OpenRefine/security/advisories/GHSA-m88m-crr9-jvqq
https://github.com/OpenRefine/OpenRefine/commit/e9c1e65d58b47aec8cd676bd5c07d97b002f205e

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-37476
https://www.cve.org/CVERecord?id=CVE-2023-37476

Please adjust the affected versions in the BTS as needed.

Bug#1041421: zabbix: CVE-2023-3523 CVE-2023-37174 CVE-2023-37765 CVE-2023-37766 CVE-2023-37767

[Moritz Mühlenhoff]

Source: zabbix
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for zabbix.

CVE-2023-3523[0]:
| Out-of-bounds Read in GitHub repository gpac/gpac prior to 2.2.2.

https://huntr.dev/bounties/57e0be03-8484-415e-8b5c-c1fe4546eaac/
https://github.com/gpac/gpac/commit/64201a26476c12a7dbd7ffb5757743af6954db96
 

CVE-2023-37174[1]:
| GPAC v2.3-DEV-rev381-g817a848f6-master was discovered to contain a
| segmentation violation in the dump_isom_scene function at
| /mp4box/filedump.c.

https://github.com/gpac/gpac/issues/2505
https://github.com/gpac/gpac/commit/549ff4484246f2bc4d5fec6760332b43774db483
  

CVE-2023-37765[2]:
| GPAC v2.3-DEV-rev381-g817a848f6-master was discovered to contain a
| segmentation violation in the gf_dump_vrml_sffield function at
| /lib/libgpac.so.

https://github.com/gpac/gpac/issues/2515
https://github.com/gpac/gpac/commit/36e1b9900ff638576cb88636bbbe2116ed06dfdc


CVE-2023-37766[3]:
| GPAC v2.3-DEV-rev381-g817a848f6-master was discovered to contain a
| segmentation violation in the gf_isom_remove_user_data function at
| /lib/libgpac.so.

https://github.com/gpac/gpac/issues/2516
https://github.com/gpac/gpac/commit/a64c60ef0983be6db8ab1e4a663e0ce83ff7bf2c


CVE-2023-37767[4]:
| GPAC v2.3-DEV-rev381-g817a848f6-master was discovered to contain a
| segmentation violation in the BM_ParseIndexValueReplace function at
| /lib/libgpac.so.

https://github.com/gpac/gpac/issues/2514
https://github.com/gpac/gpac/commit/d414df635c773b21bbb3a9fbf17b101b1e8ea345


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-3523
https://www.cve.org/CVERecord?id=CVE-2023-3523
[1] https://security-tracker.debian.org/tracker/CVE-2023-37174
https://www.cve.org/CVERecord?id=CVE-2023-37174
[2] https://security-tracker.debian.org/tracker/CVE-2023-37765
https://www.cve.org/CVERecord?id=CVE-2023-37765
[3] https://security-tracker.debian.org/tracker/CVE-2023-37766
https://www.cve.org/CVERecord?id=CVE-2023-37766
[4] https://security-tracker.debian.org/tracker/CVE-2023-37767
https://www.cve.org/CVERecord?id=CVE-2023-37767

Please adjust the affected versions in the BTS as needed.

Bug#1041420: ITS: xdiskusage

[Boyuan Yang]

Source: xdiskusage
Version: 1.48-10.1
Severity: important
X-Debbugs-CC: randrianiri...@gmail.com

Dear Debian xdiskusage package maintainer,

After looking into the package you maintain (xdiskusage, 
https://tracker.debian.org/pkg/xdiskusage), I found that this package
received no maintainer updates in the past 13 years and was not in good
shape. As a result, I am filing an ITS (Intent to Salvage) request
against your package according to section 5.12 in Debian's Developers'
Reference [1].

My current plan is to package the latest upstream release,
clean up packaging and review/fix all Debian RC bug reports.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(Aug 08, 2023) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#1038641: RM: ganv -- RoQA; depends on gtk2

[Bastian Germann]

Control: tags -1 - sid trixie
Control: severity -1 normal
Control: reassign -1 ftp.debian.org

On Mon, 19 Jun 2023 15:29:40 +0200 Bastian Germann wrote:

ganv does not have any reverse dependencies anymore. I suggest to remove it.


The Multimedia Team has not answered this request within a month so I file the 
RM bug.

Bug#1041419: ca-certrificates-java: circular dependencies

[tomas]

Package: ca-certrificates-java
Severity: normal
X-Debbugs-Cc: foren...@wi.rr.com

How do I solve this:

dpkg: error processing package ca-certificates-java (--configure):
 installed ca-certificates-java package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of 
openjdk-17-jre-headless:amd64:
 openjdk-17-jre-headless:amd64 depends on ca-certificates-java (>= 20190405~); 
however:
  Package ca-certificates-java is not configured yet.

dpkg: error processing package openjdk-17-jre-headless:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of openjdk-17-jre:amd64:
 openjdk-17-jre:amd64 depends on openjdk-17-jre-headless (= 
17.0.7+7-1~deb12u1); however:
  Package openjdk-17-jre-headless:amd64 is not configured yet.

dpkg: error processing package openjdk-17-jre:amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of default-jre:
 default-jre depends on openjdk-17-jre; however:
  Package openjdk-17-jre:amd64 is not configured yet.

dpkg: error processing package default-jre (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 ca-certificates-java
 openjdk-17-jre-headless:amd64
 openjdk-17-jre:amd64
 default-jre
E: Sub-process /usr/bin/dpkg returned an error code (1)





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

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

Bug#929685: ca-certificates-java: What is the resolution to this bug

[tomas]

Package: ca-certificates-java
Followup-For: Bug #929685
X-Debbugs-Cc: foren...@wi.rr.com

What is tyhe resolution to this bug?


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_DIE
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 ca-certificates-java depends on:
ii  ca-certificates   20230311
ii  default-jre-headless [java8-runtime-headless] 2:1.17-74
iu  openjdk-17-jre-headless [java8-runtime-headless]  17.0.7+7-1~deb12u1

ca-certificates-java recommends no packages.

ca-certificates-java suggests no packages.

-- Configuration Files:
/etc/default/cacerts [Errno 13] Permission denied: '/etc/default/cacerts'

-- no debconf information

Bug#1041418: ITP: rust-slice-group-by -- iterators over groups in slices and strs

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-slice-group-by
  Version : 0.3.1
  Upstream Contact: Clément Renault (Kerollmops) 
* URL : https://github.com/kerollmops/slice-group-by
* License : Expat
  Programming Lang: Rust
  Description : iterators over groups in slices and strs

 slice-group-by is an implementation of the groupBy Haskell function,
 providing tools for efficiently iterating over `slice` and `str`
 by groups defined by a function
 that specifies if two elements are in the same group.

This package is needed by swc (bug#991761).
It will be maintained in the collaborative debian section of salsan at
https://salsa.debian.org/debian/rust-slice-by-group

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS20pYACgkQLHwxRsGg
ASEZnw//c5aQ3rBSG7lO+TAqSI36Z9s0X6Qm0igXKDtQS8Z3I38kDuMGB6nIFXh3
omM52+RT1RmrftP+/ijmx9qjjK3e99/XkWezzyKOQ/w6VV2nRgpKbwjo7joohspP
548xlwKDt8mi83OhbvF5yhPVSOVA4Cnw874KHanvJ2b1WMNGyShjMlD3x3k7f9q1
kUnL+V998+IUxITCXKHD/kVbowDYk5IagcGfKKWrGM+ZdjRD1pfYqmIY3XuEHX6t
kIbgCHsa3qxtJcXF5GIBz5+B/Pt/CwGYzrDqjrqwMZfiu+5ChiYLIG3sdN7a1+aQ
5t2R7xS1TKFSza4TDlNH3+HZVm4eQ1C8acN/ZafyuapkL9V4lbRbQGiRKO/73bEi
Lj+nHvtDIVTopD350vypEdOyGslq//jq7rInwfTe+x6ZYsSP3xqaGS+iOGfiFpKP
3dCzxVmZm8YqR2OMlRNsx0uvqTTGrEVwT/haWJ8uNXp5ovg/VeT7rOrTo74YVcG9
7H+UCjXMDOLsbotTf2FqCKWL673HjNEUt9FbAQ1lqyqHFk6QTtktIRpz4hh7Zx3Q
WSZ/hcfUORXyDSu4nBJ0HkKUPAKs3wy90crU3J+XrttE7laAxmXVXzG6bA8PIw4a
cE/v1/4uCpH8w1fZgQw8e2qGhr7lRPJsxQS0SoAlJ0r6etUP9OU=
=RiOT
-END PGP SIGNATURE-

Bug#1038400: /usr/share/perl/.../Pod/Man.pm: String C+: use '\s+2' not '\s0'

[Russ Allbery]

Russ Allbery  writes:
> Bjarni Ingi Gislason  writes:

>>   wrong type size is created with, for example in gcc(1),

>> .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'

>> combined with

>> \s-1ISO \*(C+\s0

>> #

>> Do not use "\s0" in a string definition but an absolute number,
>> as the size of the string could be changed.
>> Then a situation of "\s-X...\s-Y...\s0...\s0" could emerge.
>> Type size changes have an effect in "groff", but not in "nroff".

> I believe this is fixed in Perl 5.8, currently in experimental,

Sorry, that was supposed to be Perl 5.38.

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

Bug#1039605: perltoc.1: weird formatted text in chapter "Portability"

[Russ Allbery]

Bjarni Ingi Gislason  writes:

>   Part of the text needs correct formatting.

>   The formatted text in chapter

> Portability
> Alphabetical Listening of Perl Functions

>   begins so (with column width of 100):

>Portability
>Alphabetical Listing of Perl Functions
>-X FILEHANDLE

>, -X EXPR, -X DIRHANDLE, -X, abs VALUE  , abs, accept 
> NEWSOCKET,GENERICSOCKET ,
>alarm SECONDS , alarm, atan2 Y,X, bind SOCKET,NAME , 
> binmode FILEHANDLE, LAYER
> , binmode FILEHANDLE, bless REF,CLASSNAME , bless REF, break, 
> caller EXPR,
>caller, chdir EXPR   , chdir FILEHANDLE, chdir DIRHANDLE, 
> chdir, chmod LIST   ,
>chomp VARIABLE , chomp( LIST ), chomp, chop VARIABLE , 
> chop( LIST ), chop,
>chown LIST
>   , chr NUMBER , chr, chroot FILENAME  , chroot, close 
> FILEHANDLE , close,
>closedir DIRHANDLE , connect SOCKET,NAME , continue BLOCK , 
> continue, cos EXPR
>   , cos, crypt PLAINTEXT,SALT

>  , dbmclose HASH , dbmopen HASH,DBNAME,MASK , defined EXPR
>  , defined, delete EXPR , die LIST
> , do BLOCK , do EXPR , dump LABEL   , dump EXPR, dump, 
> each HASH  , each
>ARRAY , eof FILEHANDLE   , eof (), eof, eval EXPR

This appears to be an upstream bug.  Upstream is making extensive use of
the X<> escape, which expands to the empty string and is used just to add
an index entry to formatters that support indexing, but they have
surrounded each of those X<> escapes with whitespace.  This is incorrect;
the whitespace is then preserved and results in the weird formatting you
see, with spaces before commas.  There should never be whitespace around
an X<> escape.

I think whoever is maintaining this documentation may not understand what
X<> is for, since its use of X<> doesn't make any sense to me.  This is a
list of available documentation that doesn't contain any documentation
itself, so the index entries for everything mentioned seem spurious.  You
would not want to follow an index reference and have it lead to nothing
but a list of all available topics.

perlpodspec:

"X" -- an index entry
See the brief discussion in "Formatting Codes" in perlpod.

This code is unusual in that most formatters completely discard this
code and its content. Other formatters will render it with invisible
codes that can be used in building an index of the current document.

perlpod:

"X" -- an index entry
This is ignored by most formatters, but some may use it for building
indexes. It always renders as empty-string. Example: "X"

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

Bug#1038400: /usr/share/perl/.../Pod/Man.pm: String C+: use '\s+2' not '\s0'

[Russ Allbery]

Bjarni Ingi Gislason  writes:

> Dear Maintainer,

>   wrong type size is created with, for example in gcc(1),

> .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'

> combined with

> \s-1ISO \*(C+\s0

> #

> Do not use "\s0" in a string definition but an absolute number,
> as the size of the string could be changed.
> Then a situation of "\s-X...\s-Y...\s0...\s0" could emerge.
> Type size changes have an effect in "groff", but not in "nroff".

I believe this is fixed in Perl 5.8, currently in experimental, which I
believe includes the latest podlators.  All of this size manipulation
code, and the C++ macro, have been removed in podlators 5.00, which drops
all of the troff-specific guesswork formatting.  It has proven much to
difficult to maintain and has created lots problems for fairly minor
formatting benefits.

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

Bug#1041417: ITP: rust-regalloc2 -- backtracking register allocator

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-regalloc2
  Version : 0.9.1
  Upstream Contact: Chris Fallin 
* URL : https://github.com/bytecodealliance/regalloc2
* License : Apache-2.0 with LLVM exception
  Programming Lang: Rust
  Description : backtracking register allocator

 regalloc2 is a register allocator
 that started life as, and is about 50% still,
 a port of IonMonkey's backtracking register allocator to Rust.
 In many regards, it has been generalized, optimized, and improved
 since the initial port.
 .
 In addition,
 it contains substantial amounts of testing infrastructure
 (fuzzing harnesses and checkers)
 that does not exist in the original IonMonkey allocator.

This package is needed by swc (bug#991761).
It will be maintained in the collaborative debian section of salsan at
https://salsa.debian.org/debian/rust-regalloc2

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS2zHcACgkQLHwxRsGg
ASFRAA/7B0A4+Zm3LFQoPFLfv/uaqfkELXs1Fuf2eKgK/IwzR99U+ne2dNB4S1aF
V0ZhF33WbidD63Em/WwNwENGYmeqUa/WUnxFrvEq45E/VyYUd0a3V+jYaGAsxEOA
dZ/N7oLrdFcWaG4eF+K2+Xm5nQe7S7vNafVR2+WT69So9dLlht6gkvDYdM2QWS1u
QxQ08vGgPD9qYWW3IVcvG/mTzL7MnU2PkN4CD17Lowz3pVqxqioEZoHNjxjsJdXC
dhGfTE4a7B9CY8sq/8mBkaJqtOSL6VFKa26rCheMYfwg85XZQ0xS9G5ZiumFU7w9
yM1FPMR9s9YRrGm350wnWzhnKbjGbiyPqMZL79In9vVXak0AXkmUe/07Eii9budI
vzaq8oPMDOfFV3R809q7I8qh3Riy27LrjPxXzB30/r2L0fGs7l6csqGuPll5NZ6O
N0087VphdJoGUJw9Sro+4Dvs+vqqsmNKQ26H+5d8BWeQsfmu1MTD/iyBu4w+3GG1
3nbrMFpBR16eQ6gV4rYxBjTcocqGBPJU+BwgGs5wcQtwplIN25T0pGwoIz2ZhPUQ
pl+5EQw4dMCPMWJlmS9HWcbz5bD2s/t1cHDGpw87Nh66JjV1n6sAMkqNkFtxirCD
WTBN6RMFscwLD/7wrgS0Q/bSwNWe9IzbuuJZDUu1+INW7w+fPrk=
=nXER
-END PGP SIGNATURE-

Bug#1041415: emacs: fails to install: post-installation script subprocess returned error exit status 1

[Holger Levsen]

Package: emacs
Version: 1:28.2+1-15
Severity: serious

Dear Maintainer,

in a sid chroot:

root@debian:~# apt install emacs
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  emacs-bin-common emacs-common emacs-el emacs-gtk fonts-noto-color-emoji 
libgccjit0 libm17n-0 libotf1 m17n-db
Suggested packages:
  emacs-common-non-dfsg ncurses-term m17n-docs
The following NEW packages will be installed:
  emacs emacs-bin-common emacs-common emacs-el emacs-gtk fonts-noto-color-emoji 
libgccjit0 libm17n-0 libotf1 m17n-db
0 upgraded, 10 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/57.4 MB of archives.
After this operation, 179 MB of additional disk space will be used.
Do you want to continue? [Y/n]
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)
Selecting previously unselected package emacs-el.
(Reading database ... 243178 files and directories currently installed.)
Preparing to unpack .../0-emacs-el_1%3a28.2+1-15_all.deb ...
Unpacking emacs-el (1:28.2+1-15) ...
Selecting previously unselected package emacs-common.
Preparing to unpack .../1-emacs-common_1%3a28.2+1-15_all.deb ...
Unpacking emacs-common (1:28.2+1-15) ...
Selecting previously unselected package emacs-bin-common.
Preparing to unpack .../2-emacs-bin-common_1%3a28.2+1-15_amd64.deb ...
Unpacking emacs-bin-common (1:28.2+1-15) ...
Selecting previously unselected package libgccjit0:amd64.
Preparing to unpack .../3-libgccjit0_13.1.0-8_amd64.deb ...
Unpacking libgccjit0:amd64 (13.1.0-8) ...
Selecting previously unselected package m17n-db.
Preparing to unpack .../4-m17n-db_1.8.2-1_all.deb ...
Unpacking m17n-db (1.8.2-1) ...
Selecting previously unselected package libotf1:amd64.
Preparing to unpack .../5-libotf1_0.9.16-4_amd64.deb ...
Unpacking libotf1:amd64 (0.9.16-4) ...
Selecting previously unselected package libm17n-0:amd64.
Preparing to unpack .../6-libm17n-0_1.8.2-1_amd64.deb ...
Unpacking libm17n-0:amd64 (1.8.2-1) ...
Selecting previously unselected package emacs-gtk.
Preparing to unpack .../7-emacs-gtk_1%3a28.2+1-15_amd64.deb ...
Unpacking emacs-gtk (1:28.2+1-15) ...
Selecting previously unselected package emacs.
Preparing to unpack .../8-emacs_1%3a28.2+1-15_all.deb ...
Unpacking emacs (1:28.2+1-15) ...
Selecting previously unselected package fonts-noto-color-emoji.
Preparing to unpack .../9-fonts-noto-color-emoji_2.038-1_all.deb ...
Unpacking fonts-noto-color-emoji (2.038-1) ...
Setting up libotf1:amd64 (0.9.16-4) ...
Setting up fonts-noto-color-emoji (2.038-1) ...
Setting up m17n-db (1.8.2-1) ...
Setting up libm17n-0:amd64 (1.8.2-1) ...
Setting up libgccjit0:amd64 (13.1.0-8) ...
Setting up emacs-el (1:28.2+1-15) ...
Setting up emacs-common (1:28.2+1-15) ...
Setting up emacs-bin-common (1:28.2+1-15) ...
update-alternatives: using /usr/bin/ctags.emacs to provide /usr/bin/ctags 
(ctags) in auto mode
update-alternatives: using /usr/bin/ebrowse.emacs to provide /usr/bin/ebrowse 
(ebrowse) in auto mode
update-alternatives: using /usr/bin/emacsclient.emacs to provide 
/usr/bin/emacsclient (emacsclient) in auto mode
update-alternatives: using /usr/bin/etags.emacs to provide /usr/bin/etags 
(etags) in auto mode
Setting up emacs-gtk (1:28.2+1-15) ...
update-alternatives: using /usr/bin/emacs-gtk to provide /usr/bin/emacs (emacs) 
in auto mode
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
>>Error occurred processing /usr/share/emacs/site-lisp/debian-startup.el: File 
>>error (("Doing chmod" "Operation not supported" 
>>"/usr/share/emacs/site-lisp/debian-startup.elcxkbhIA"))
ERROR: install script from emacsen-common package failed
dpkg: error processing package emacs-gtk (--configure):
 installed emacs-gtk package post-installation script subprocess returned error 
exit status 1
dpkg: dependency problems prevent configuration of emacs:
 emacs depends on emacs-gtk (>= 1:27.1) | emacs-lucid (>= 1:27.1) | emacs-nox 
(>= 1:27.1); however:
  Package emacs-gtk is not configured yet.
  Package emacs-lucid is not installed.
  Package emacs-nox is not installed.

dpkg: error processing package emacs (--configure):
 dependency problems - leaving unconfigured
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for libc-bin (2.37-6) ...
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for install-info (7.0.3-2) ...
Processing triggers for mailcap (3.70+nmu1) ...
Processing triggers for fontconfig (2.14.1-4) ...
Errors were encountered while processing:
 emacs-gtk
 emacs
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@debian:~#


-- 
cheers,
Holger

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

A ship is always safe at shore, but that is not what it's built for.
(Albert Einstein)


signature.asc
Description: PGP signature

Bug#1041211: libsdl-perl: FTBFS and autopkgtest failure with sdl12-compat, especially on 32-bit

[Simon McVittie]

Control: tags -1 + upstream
Control: clone -1 -2
Control: reassign -1 src:libsdl-perl 2.548-3
Control: forwarded -1 https://github.com/PerlGameDev/SDL/issues/305
Control: severity -2 wishlist
Control: retitle -2 sdl12-compat: could work around libsdl-perl incorrectly 
freeing SDL_SetVideoMode() result

On Tue, 18 Jul 2023 at 02:07:39 +0100, Simon McVittie wrote:
> On Mon, 17 Jul 2023 at 10:35:14 +0100, Simon McVittie wrote:
> > I can reproduce a use-after-free on amd64. The test doesn't crash on amd64
> > for whatever reason, but it's visible when using valgrind, or when
> > recompiling sdl12-compat and libsdl2 with -fsanitize=address.
> 
> I was able to reduce the Perl test to a small C reproducer, which I've
> sent upstream to sdl12-compat (see URL above). As far as I can tell,
> it's most likely to be a sdl12-compat bug, but I don't understand the
> memory management for these surfaces well enough to fix it.

SDL upstream have clarified that what libsdl-perl is doing here was
never correct, so actually, this is more a libsdl-perl bug than a
sdl12-compat bug. The result of SDL_SetVideoMode() is never meant to be
freed by a library user, only internally by SDL itself.

I've sent a possible fix to https://github.com/PerlGameDev/SDL/pull/306,
but I'm intentionally not tagging this bug +patch, because it badly needs
reviewing by someone who has written XS bindings before (I'd never tried
writing XS before today).

> A brute-force workaround would be to intentionally leak every surface
> object that was previously the video surface, by adding a flag that
> would make SDL_FreeSurface ignore it, but I hope upstream will be able
> to suggest something less bad than that.

Let's use #1041211 for the RC bug in libsdl-perl (FTBFS and autopkgtest
failure triggered by the new version of libsdl1.2debian), and use its new
clone -2 to represent a possible workaround in sdl12-compat.

sdl12-compat aims for bug-for-bug compatibility with classic SDL 1.2,
so they are hoping to be able to avoid the crash. If they can, I'll
downgrade #1041211 to be non-RC after that workaround is uploaded.

smcv

Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

[Andreas Metzler]

On 2023-07-17 Simon Josefsson  wrote:
> Jonathan McDowell 
[...]

>> I haven't seen dkg or Eric weigh in on this thread, but they've had a
>> few months to object and given gnupg lives under the debian/ tree in
>> salsa I'd take that as an indication that an upload to experimental
>> would be acceptable.

> Eric, dpkg, what do you think?

> I'm not familiar with what Debian policies suggest in this situation
> (I'm not so sure the location of the git repository on Salsa is a clear
> indication of anything - pointers?), but I offer to help with these
> packages going forward.
[...]

Hello,

well, putting the repo in the debian/ salsa group allows *commits* by any
Debian member. (No merge request or coordination required) [1]

OTOH Daniel is listed on https://wiki.debian.org/LowThresholdNmu which
would make NMUs for targeted bugfixes of reported bugs OK.

Afaik there is no real policy outside of that, except for adopting or
rescuing packages.

I personally think that uploading to experimental would be fine with
Daniel if there was a long term commitment behind it.

cu Andreas

[1] 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1041414: lxc failed to delete default_pvid from veth linux bridge

[Valery Kuryshin]

Package: lxc
Version: 5.0.2-1

Code in network.c, lines 468-472 failed to delete default_pvid when is zero.

If bridge created by systemd.netdev like this:
[Bridge]
DefaultPVID=none

and lxc config contains:
lxc.net.0.veth.vlan.id = vlan_ID

LXC trying to delete zero PVID from veth interface before set actual value
from config file and fail.

Manually added exception (default_pvid != 0) for this variant works as
expected, but may have side effect, or not.

Best regards,
Valery Kuryshin

Bug#1041409: thunderbird: OpenPGP features in v115 requires librnp0 >= 0.17.0 not in archive

[Carsten Schoenert]

Hi Alper,

Am 18.07.23 um 17:20 schrieb Alper Nebi Yasak:

I decided to upgrade Thunderbird to the version in experimental, and
noticed that its OpenPGP functionality is completely broken: the Key
Manager is empty, and it doesn't even attempt to decrypt/verify
encrypted/signed messages (at least over external gnupg).


ha, by accident I noticed the described behavior just a few hour ago too!
Thanks for trying out Thunderbird from experimental, I expect we will 
find a few more glitches like that.



The "Troubleshooting Information" page says the expected minimum version
for the RNP library is 0.17.0, where I had 0.16.3-1 installed as
currently in unstable.


Unfortunately the Thunderbird build system does not do a really good job 
on detecting required versions for libraries or equal. And it's mostly 
difficult to detect such version bumps by reviewing manually changes 
after importing a new version.



Seeing a 0.17.0~git20220428-1 version for librnp0 in experimental, I
tried installing that. But that doesn't work either, apparently its
source is older than 0.16.1? (Also see bug #1031363).

So I think Thunderbird needs to depend on librnp0 >= 0.17.0 (currently
unversioned), but no such version is in Debian yet. I got it to work by
sloppily packaging the newer source. (The proper package may take a bit,
has a new dependency apparently in NEW -- I'm CC-ing the maintainer.)


Your analysis is correct, Thunderbird will need a version constrain on 
librnp0. But this requires the package to be available at least in 
experimental.


I'll do some work around this and change the build system while 
preparing the next upload so it is using the internal shipped librnp 
version until Daniel has uploaded a newer version.


--
Regards
Carsten

Bug#1041311: closed by Debian FTP Masters (reply to Lukas Märdian ) (Bug#1041311: fixed in netplan.io 0.106.1-6)

[Andreas Beckmann]

Control: reopen -1
Control: fixed 1041310 0.106.1-6

On 18/07/2023 19.09, Debian Bug Tracking System wrote:

  netplan.io (0.106.1-6) unstable; urgency=medium
  .
* Fix ethernets,vlans,scenarios autopkgtests on systemd 254, Closes: 
#1041311


You probably wanted to close #1041310 instead

Andreas

Bug#1041336: fenix-plugins: build improvements

[Thomas Uhle]

Dear maintainers,

yesterday I forgot to attach a patch that let autopkgtest run the tests 
just on the 32-bit architectures for which the packages fenix-plugins, 
fenix-plugins-system and fenix-plugin-mpeg are built to avoid the current 
test failures on the 64-bit architectures [1].


Best regards,

Thomas Uhle


[1] https://ci.debian.net/packages/f/fenix-plugins

fenix-plugins-tests-control.diff.gz
Description: GNU Zip compressed data

Bug#1041411: [Debian-on-mobile-maintainers] Bug#1041411: libfeedback-dev: Documentation not registered with doc-base

[Evangelos Ribeiro Tzaras]

Control: close -1 0.2.0-3
Control: tags pending

On Tue, 2023-07-18 at 18:02 +0200, Evangelos Ribeiro Tzaras wrote:
> Package: libfeedback-dev
> Version: 0.2.0-2
> Severity: wishlist
> Tags: patch
> X-Debbugs-Cc: Evangelos Ribeiro Tzaras 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> libfeedback-dev ships documentation but it is not registered with doc-base.

MR on salsa has been accepted:
https://salsa.debian.org/DebianOnMobile-team/feedbackd/-/merge_requests/20


-- 
Cheers,

Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19


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

Bug#1041413: Package: distrobox; Missing dependency: uidmap

[Doug Baggett]

Package: distrobox
Version: 1.4.2.1
Severity: important

Dear Maintainer,

I am reporting a missing dependency issue with distrobox on Debian 12. The
uidmap package is required but not listed as a dependency. This causes
problems when trying to use distrobox, as it cannot function properly
without it.

Please add it as a dependency for distrobox to resolve this issue.

Thank you for your attention to this matter!

Best regards,
Doug B

Bug#1036621: still present. fix by putting alternative link ?

[Siward de Groot]

 Hello maintainers, 



 On Debian 12 this file is still referred to in manpage, and the file still 
does not exist. 

 But if found a nice page on the web that describes regionset : 



 https://www.hecticgeek.com/dvd-region-code-changer-ubuntu-linux/ 


 maybe you could simply replace that reference to nonexistent file with this 
link ? 





 On Tue, 23 May 2023 13:12:08 +0200 Philipp Klaus Krause  wrote: 
 > Package: regioset 
 > Version: regionset 
 > Severity: normal 
 > X-Debbugs-Cc: p...@spth.de 
 > 
 > Dear Maintainer, 
 > 
 > The manpage says "This program is documented fully in 
 > /usr/share/doc/regionset/README." There is no 
 > /usr/share/doc/regionset/README. 
 > 
 > 
 > -- System Information: 
 > Debian Release: 12.0 
 > APT prefers unstable 
 > APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') 
 > Architecture: amd64 (x86_64) 
 > Foreign Architectures: i386 
 > 
 > Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) 
 > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
 > set 
 > Shell: /bin/sh linked to /usr/bin/dash 
 > Init: systemd (via /run/systemd/system) 
 > LSM: AppArmor: enabled 
 > 
 > 

Bug#1037040: util-linux: Please coordinate upload of 2.39 with manpages-l10n

[Helge Kreutzmann]

Hello Chris,
On Fri, Jun 02, 2023 at 03:33:33PM +0200, Helge Kreutzmann wrote:
> once bookworm is released, I assume that you intend to package the latest
> version, i.e. 2.39.
> 
> This version comes with translated man pages, which were (up to
> now) shipped by manpages-l10n.
> 
> To allow a smooth transition, both packages need to declare
> appropriate package relations:
> https://wiki.debian.org/PackageTransition
> 
> So please let me know about the upload and the relevant version
> (probably 2.39.0-1?).
> 
> Until I hear something from your side, manpages-l10n will continue
> shipping the translated man pages.

The most convenient time for me would be around the end of August,
when manpages-l10n releases the next version. Then I could deal with
this quite nicely. Do you think this is a sensible date for you as
well?

Greetings

   Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1041412: golang-1.21-src: missing Breaks+Replaces: golang-1.21-go (<< 1.21~rc3)

[Andreas Beckmann]

Package: golang-1.21-src
Version: 1.21~rc3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../golang-1.21-src_1.21~rc3-1_all.deb ...
  Unpacking golang-1.21-src (1.21~rc3-1) over (1.21~rc2-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/golang-1.21-src_1.21~rc3-1_all.deb (--unpack):
   trying to overwrite '/usr/share/go-1.21/src/internal/platform/zosarch.go', 
which is also in package golang-1.21-go 1.21~rc2-2
  Errors were encountered while processing:
   /var/cache/apt/archives/golang-1.21-src_1.21~rc3-1_all.deb


cheers,

Andreas


golang-1.21-go=1.21~rc2-2_golang-1.21-src=1.21~rc3-1.log.gz
Description: application/gzip

Bug#328529: reproducible, not really a bug

[Siward de Groot]

 Hello maintainers, 

 i tried doing same as Dan Jacobson, and got same result. 

 However, if i do "regionset /dev/sr0", then it works fine. 

 I think this is because there is no /cdrom on my system. 



 There is a /dev/cdrom though, and "regionset /dev/cdrom" works perfectly well. 







 On Fri, 16 Sep 2005 03:16:56 +0800 Dan Jacobson  wrote: 


 > Package: regionset 
 > Version: 0.1-1 
 > Severity: wishlist 
 > 
 > Your message makes it look like one need only just insert a CDROM: 
 > # regionset 
 > regionset version 0.1 -- reads/sets region code on DVD drives 
 > ERROR: Could not open disc "(null)"! 
 > Ensure that there is any readable CD or DVD in the drive. 
 > # mount /cdrom/ 
 > # df /cdrom/ 
 > Filesystem 1K-blocks Used Available Use% Mounted on 
 > /dev/hdc 708576 708576 0 100% /cdrom 
 > # regionset /cdrom/ 
 > regionset version 0.1 -- reads/sets region code on DVD drives 
 > ERROR: Could not open disc "/cdrom/"! 
 > Ensure that there is any readable CD or DVD in the drive. 
 > 
 > I have a combo cdrom/dvd player, but no dvds on hand. 
 > 
 > 

Bug#1041411: libfeedback-dev: Documentation not registered with doc-base

[Evangelos Ribeiro Tzaras]

Package: libfeedback-dev
Version: 0.2.0-2
Severity: wishlist
Tags: patch
X-Debbugs-Cc: Evangelos Ribeiro Tzaras 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libfeedback-dev ships documentation but it is not registered with doc-base.
>From d286cc983c0b24eb05f4c546d32d1cd1e614e1eb Mon Sep 17 00:00:00 2001
From: Evangelos Ribeiro Tzaras 
Date: Tue, 18 Jul 2023 17:59:03 +0200
Subject: [PATCH] lfb-dev: Register documentation with doc-base

---
 debian/libfeedback-dev.doc-base | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 debian/libfeedback-dev.doc-base

diff --git a/debian/libfeedback-dev.doc-base b/debian/libfeedback-dev.doc-base
new file mode 100644
index 000..a8d9780
--- /dev/null
+++ b/debian/libfeedback-dev.doc-base
@@ -0,0 +1,12 @@
+Document: libfeedback
+Title: libfeedback Reference Manual
+Author: Guido Günther
+Abstract: A library to trigger feedback (such as haptic feedback)
+ from your application. This document covers the C API,
+ but it also useful for GObject introspection bindings
+ of your favourite programming language.
+Section: Programming
+
+Format: HTML
+Index: /usr/share/doc/libfeedback-dev/libfeedback-0/index.html
+Files: /usr/share/doc/libfeedback-dev/libfeedback-0/*.html
-- 
2.40.1


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

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

Versions of packages libfeedback-dev depends on:
ii  gir1.2-lfb-0.0 0.2.0-2
ii  libfeedback-0.0-0  0.2.0-2
ii  libglib2.0-dev 2.74.6-2

libfeedback-dev recommends no packages.

libfeedback-dev suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuThlVLfdJmvLjimpkPDJsYprShkFAmS2tjYACgkQkPDJsYpr
ShlUfhAAiYUeATLrAdIlzgyE4fo4/6JbsAPeTXCVrkYl/mBm62R2GUxnv5umjCgO
giDs1egFVafLwn+rGsBYwpPpsHhSjLz8TEuboWuiOwCW+GU12F0HP+8JI3Fo7B/v
vADL1wsDeSeiirmh7ENOcV5LH5Jw7UIucvVgK8a8/42Fj7aURVe82OFokB5sXqZ7
qp7b586k0E8LOW6ZL0T9woIOPQKYS1ZJrC3uc7fk6p5w4heaMSDj33keuq2iVkmr
4HmLNrDCM4SQW7iHEcUuobHUboG5i7jJT5V64FEkV5vVrABOc2zIvF0uCO3OqUOz
WkhQ/zHhMxdgCE7raX3G3F4Rlagsl7XtcJNDFeJlOJOiNCmrTnbdwVUBsZn/rR0g
kFFnt0/8rTs6AoVGhMbbwh2BqRj8bwHTzLsaGse9JSyc4fTO1209PKU7B2PrgbwV
K+czXeVmE+BZ+La8B0YoKzP+AWofeSPHjTWnz677Hh0fn0OXkVyhSSv8Z1UBKb/G
aCbuskKoEMyYwxy3AGHqMbChOV3x0b0ankWpWbMdj8idq+E5hwG+D9n6AIyYDTtN
fkRYMJlhJM2pyJTMgbHVbDcaIjqtXSHl3Fd4pyDUkYrYI2m5HQGpwh9zUU/HZm3s
8KuSiVIY7Wp5VQPjOFLjA0IG7Y6lfYBcDNNEwtccfb2NOMqEcl4=
=X8K6
-END PGP SIGNATURE-

Bug#335083: thus bug is not present in Debian 12

[Siward de Groot]

 In Debian 12 , this bug no  longer exists. 

 Now it's output is : 

$ regionset /dev/cdrom 
Current drive parameters for /dev/cdrom: 
 RPC Type: Phase II (Hardware) 
 RPC Status: no region code set (bitmask=0xFF) 
 Vendor may reset the RPC 4 times 
 User is allowed change the region setting 5 times 
Would you like to change the region setting for this drive? [y/n]: n





 On Sat, 22 Oct 2005 02:59:11 +0800 Dan Jacobson  wrote: 
 > Package: regionset 
 > Severity: wishlist 
 > Tags: upstream 
 > 
 > Does this mean no region? say it clearer: 
 > # regionset /dev/cdrom 
 > regionset version 0.1 -- reads/sets region code on DVD drives 
 > Current Region Code settings: 
 > RPC Phase: II 
 > type: NONE 
 > vendor resets available: 4 
 > user controlled changes resets available: 5 
 > drive plays discs from region(s):, mask=0xFF 
 > 
 > I suppose ":," means no/all regions. 
 > Perhaps spell out what RPC, and "type" and mask mean, unless --quiet 
 > or if --verbose is used. 
 > 
 > Would you like to change the region setting of your drive? [y/n]:n 
 > "[y/N]" would make clearer what will happen if one just hits RET. 
 > however I didn't try it so can't guess what will happen. 
 > 
 > 
 = 

Bug#1041410: libdogleg-dev: missing Breaks+Replaces: libdogleg-doc (<< 0.16-2)

[Andreas Beckmann]

Package: libdogleg-dev
Version: 0.16-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../libdogleg-dev_0.16-2_amd64.deb ...
  Unpacking libdogleg-dev:amd64 (0.16-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libdogleg-dev_0.16-2_amd64.deb (--unpack):
   trying to overwrite '/usr/share/man/man3/libdogleg.3.gz', which is also in 
package libdogleg-doc 0.15.4-2
  Errors were encountered while processing:
   /var/cache/apt/archives/libdogleg-dev_0.16-2_amd64.deb


And you still have a Depends on the no longer built libdogleg-doc


cheers,

Andreas

Bug#1041373: toot: release notes overlooked

[Sandro Tosi]

> Most importantly: oldstable is still officially supported for another
> year¹ from now.

yet you wont receive any updates and instead you spam the debian bug
tracking system with "reports" that are just noise (like this one,
since it's fixed upstream).

> Bug reports are essential for QA. It’s better to advocate for bug
> reports, not push for their suppression.

if i go in a bakery and scream "my chair broke, i want a new one!" it
serves no one purpose. You need to submit the requests in the right
place for the right people to act on.

> > that do not belong to the debian tracking system (as mentioned
> > before already).
>
> Please read the “Don't file bugs upstream” section of the bug
> reporting procedure².

yeah which you conveniently omitted to report the big `if` before
hand: "If you file a bug in Debian, don't send a copy to the upstream
software maintainers yourself" -- what we are telling you is to NOT
file these bugs at all in the debian bts, but directly upstream. you
dont like github? it's sucks for you, it doesnt mean we are happy to
accept your dubious quality reports.

If i were the maintainer of this package, i'd bulk close all your
report and invalid and ask the BTS maintainer to temporarily ban you
from submitting more.


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

Bug#1039910: r-cran-exactextractr_0.9.1-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Sun, Jul 16, 2023 at 12:00:09PM + schrieb Thorsten Alteholz:
> according to the file header and DESCRIPTION, the only copyright holder is 
> ISciences, LLC., so I don't think Daniel Baston should be mentioned.
> But please mention Martin Moene.

Both fixed in new upload.

Thanks for thorough checking
  Andreas. 

-- 
http://fam-tille.de

Bug#982062: Please mention API issues in README.Debian

[Daniel Serpell]

Hi!

Recently I was hit by this bug, a nice workaround is in this Stackoverflow
answer:  https://stackoverflow.com/a/67459416

The procedure in Debian could be to create a file /etc/chromium.d/enable-sync
with the following content:

  # Set OAUTH2 flags to enable sync with google services:
  # 
https://stackoverflow.com/questions/67459316/enabling-chromium-to-sync-with-google-account

  export CHROMIUM_FLAGS="$CHROMIUM_FLAGS
--oauth2-client-id=77185425430.apps.googleusercontent.com"
  export CHROMIUM_FLAGS="$CHROMIUM_FLAGS
--oauth2-client-secret=OTJgUOQcT7lO7GsGZq2G4IlT"


This could be added to the README.Debian file.

Have Fun!
Daniel.

Bug#1022006: Acknowledgement (New version fixes a warning)

[Bjarni Ingi Gislason]

On Sun, Mar 05, 2023 at 06:14:25PM -0500, Thomas Dickey wrote:
> - Original Message -
> | From: "Bjarni Ingi Gislason" 
> | To: 1022...@bugs.debian.org
> | Cc: "Bjarni Ingi Gislason" 
> | Sent: Sunday, March 5, 2023 4:24:44 PM
> | Subject: Bug#1022006: Acknowledgement (New version fixes a warning)
> 
> | The new version did not fix the observed behaviour.
> 
> For the given bug-report, I don't recall any relevant changes.
> 
  The indication of a bug disappeared after updating the following:

Start-Date: 2023-07-18  10:50:11
Commandline: apt-get upgrade
Upgrade:
libnftnl11:amd64 (1.2.5-1, 1.2.6-1),
libctf-nobfd0:amd64 (2.40.90.20230705-1, 2.40.90.20230714-2),
libbinutils:amd64 (2.40.90.20230705-1, 2.40.90.20230714-2),
libfreetype6:amd64 (2.12.1+dfsg-5, 2.13.0+dfsg-1),
binutils-x86-64-linux-gnu:amd64 (2.40.90.20230705-1, 2.40.90.20230714-2),
binutils-doc:amd64 (2.40.90.20230705-1, 2.40.90.20230714-2),
libctf0:amd64 (2.40.90.20230705-1, 2.40.90.20230714-2),
rsyslog:amd64 (8.2306.0-1, 8.2306.0-2),
binutils-common:amd64 (2.40.90.20230705-1, 2.40.90.20230714-2),
libsframe1:amd64 (2.40.90.20230705-1, 2.40.90.20230714-2),
libgprofng0:amd64 (2.40.90.20230705-1, 2.40.90.20230714-2),
libharfbuzz0b:amd64 (6.0.0+dfsg-3, 8.0.1-1),
xterm:amd64 (383-1, 384-1),
binutils:amd64 (2.40.90.20230705-1, 2.40.90.20230714-2)
End-Date: 2023-07-18  10:51:01

Bug#1041398: guix: systemd complains about service definitions

[Vagrant Cascadian]

Control: forwarded 1041398 https://issues.guix.gnu.org/48323

On 2023-07-18, Dave Love wrote:
> 2023-07-18T12:51:34.291579+01:00 *** systemd[1]: 
> /lib/systemd/system/guix-publish.service:15: Standard output type syslog is 
> obsolete, automatically updating to journal. Please update your unit file, 
> and consider removing the setting altogether.
> 2023-07-18T12:51:34.291772+01:00 *** systemd[1]: 
> /lib/systemd/system/guix-daemon.service:12: Standard output type syslog is 
> obsolete, automatically updating to journal. Please update your unit file, 
> and consider removing the setting altogether.

I had asked upstream about this a while ago, and they suggested to just
test switching to "journal" ... if that works, I can push a fix upstream
and to Debian as well.

Thanks for the reminder!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1040853: python-lockfile autopkg test fail with setuptools 68

[Dan Bungert]

Just wanted to quickly confirm that the same fix proposed at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1040854;filename=python-tinyrpc_0.6-4ubuntu1.debdiff;msg=10

works well for python-lockfile.

-Dan

Bug#1041409: thunderbird: OpenPGP features in v115 requires librnp0 >= 0.17.0 not in archive

[Alper Nebi Yasak]

Package: thunderbird
Version: 1:115.0-1
Severity: important
X-Debbugs-CC: d...@fifthhorseman.net

Dear Maintainer,

I decided to upgrade Thunderbird to the version in experimental, and
noticed that its OpenPGP functionality is completely broken: the Key
Manager is empty, and it doesn't even attempt to decrypt/verify
encrypted/signed messages (at least over external gnupg).

The "Troubleshooting Information" page says the expected minimum version
for the RNP library is 0.17.0, where I had 0.16.3-1 installed as
currently in unstable.

Seeing a 0.17.0~git20220428-1 version for librnp0 in experimental, I
tried installing that. But that doesn't work either, apparently its
source is older than 0.16.1? (Also see bug #1031363).

So I think Thunderbird needs to depend on librnp0 >= 0.17.0 (currently
unversioned), but no such version is in Debian yet. I got it to work by
sloppily packaging the newer source. (The proper package may take a bit,
has a new dependency apparently in NEW -- I'm CC-ing the maintainer.)

Thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, armhf, armel, i386

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

Versions of packages thunderbird depends on:
ii  debianutils  5.8-1
ii  fontconfig   2.14.1-4
ii  libasound2   1.2.9-1
ii  libatk1.0-0  2.48.3-1
ii  libc62.37-6
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.8-2
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.13.0+dfsg-1
ii  libgcc-s113.1.0-8
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.91-1
ii  libotr5  4.1.1-5
ii  libpango-1.0-0   1.50.14+ds-1
ii  librnp0  0.17.0-1~1.gbp1d03e6
ii  libstdc++6   13.1.0-8
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.6-1
ii  libx11-xcb1  2:1.8.6-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1+b1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.6-1
ii  x11-utils7.7+5
ii  zenity   3.44.0-3
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-gb [hunspell-dictionary]  1:7.5.0-1
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2

Versions of packages thunderbird suggests:
ii  apparmor  3.0.8-3
ii  fonts-lyx 2.3.7-1
ii  libgssapi-krb5-2  1.20.1-2

-- no debconf information

Bug#1040386: libdata-swap-perl: FTBFS with Perl 5.38: undefined reference to `Perl_hv_backreferences_p'

[Niko Tyni]

Control: tag -1 patch

On Wed, Jul 05, 2023 at 01:21:15PM +0300, Niko Tyni wrote:
> Source: libdata-swap-perl
> Version: 0.08-2
> Severity: important
> Tags: ftbfs trixie sid
> Forwarded: https://rt.cpan.org/Ticket/Display.html?id=144619
> User: debian-p...@lists.debian.org
> Usertags: perl-5.38-transition
> 
> This package fails to build from source with Perl 5.38 (currently in
> experimental):
> 
>   x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
> -Wl,-z,now  -shared -L/usr/local/lib -fstack-protector-strong  Swap.o  -o 
> blib/arch/auto/Data/Swap/Swap.so  \
> \
> 
>   /usr/bin/ld: Swap.o: in function `extract_backrefs':
>   ././Swap.c:63: undefined reference to `Perl_hv_backreferences_p'
>   /usr/bin/ld: Swap.o: in function `install_backrefs':
>   ././Swap.c:88: undefined reference to `Perl_hv_backreferences_p'
>   /usr/bin/ld: blib/arch/auto/Data/Swap/Swap.so: hidden symbol 
> `Perl_hv_backreferences_p' isn't defined
>   /usr/bin/ld: final link failed: bad value
>   collect2: error: ld returned 1 exit status
>   make[1]: *** [Makefile:474: blib/arch/auto/Data/Swap/Swap.so] Error 1

This is because 5.38 hides internal C API functions with with 
__attribute__((hidden)).
Perl_hv_backreferences_p was never part of the official API.

That said, the attached patch works around this by duplicating the
functionality from the core function. It's not a proper solution but I
guess it could buy some time. The module is clearly abandoned upstream
so I suppose we should aim for its eventual removal from Debian?

I've no idea how bad form this is but it seems to work for me on perls
at least from 5.20 up to 5.38.

Tentatively adding the patch tag...
-- 
Niko Tyni   nt...@debian.org
>From c41631c7d037b455053a235b507ff925db4dd0ba Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Tue, 18 Jul 2023 15:41:50 +0100
Subject: [PATCH] Work around Perl_hv_backreferences_p hidden in 5.38

Bug-Debian: https://bugs.debian.org/1040386
Bug: https://rt.cpan.org/Ticket/Display.html?id=144619
---
 Swap.xs | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/Swap.xs b/Swap.xs
index 36edc0a..8730499 100644
--- a/Swap.xs
+++ b/Swap.xs
@@ -55,12 +55,23 @@
 
 #define DA_DEREF_ERR "Can't deref string (\"%.32s\")"
 
+/* copied (and slightly simplified) from core because Perl_hv_backreferences_p
+   is hidden on all platforms since 5.38 */
+
+STATIC AV **my_backreferences_p(pTHX_ HV *hv) {
+	if (!SvOOK(hv)) {
+		hv_iterinit(hv);
+	}
+	struct xpvhv_aux * const iter = HvAUX(hv);
+	return &(iter->xhv_backreferences);
+}
+
 STATIC AV *extract_backrefs(pTHX_ SV *sv) {
 	AV *av = NULL;
 
 #if BACKREFS_IN_HV
 	if (SvTYPE(sv) == SVt_PVHV && SvOOK(sv)) {
-		AV **const avp = Perl_hv_backreferences_p(aTHX_ (HV *) sv);
+		AV **const avp = my_backreferences_p(aTHX_ (HV *) sv);
 		av = *avp;
 		*avp = NULL;
 	}
@@ -85,7 +96,7 @@ STATIC void install_backrefs(pTHX_ SV *sv, AV *backrefs) {
 
 #if BACKREFS_IN_HV
 	if (SvTYPE(sv) == SVt_PVHV) {
-		AV **const avp = Perl_hv_backreferences_p(aTHX_ (HV *) sv);
+		AV **const avp = my_backreferences_p(aTHX_ (HV *) sv);
 		*avp = backrefs;
 		return;
 	}
-- 
2.39.1

Bug#1041404: weechat-matrix: Incompatible with python-matrix-nio >= 0.20

[Simon Chopin]

Source: weechat-matrix
Followup-For: Bug #1041404
X-Debbugs-Cc: scho...@ubuntu.com

Fix posted upstream and at

https://salsa.debian.org/debian/weechat-matrix/-/merge_requests/3


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

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

Bug#1040223: libimage-imlib2-perl: Creates empty package on bookworm upwards (maybe because of libimlib2-dev?)

[Niko Tyni]

Control: tag -1 patch

On Mon, Jul 03, 2023 at 06:00:44PM +0200, gregor herrmann wrote:
> Source: libimage-imlib2-perl
> Version: 2.03-1.1
> Severity: grave
> Tags: bookworm trixie sid
> Justification: renders package unusable

> While looking at Niko's and Dom's first rebuilds for perl 5.38, I
> noticed that libimage-imlib2-perl "successfully" builds but creates
> a basically empty package:
> 
> http://perl.debian.net/rebuild-logs/perl-5.38/libimage-imlib2-perl_2.03-1.1/libimage-imlib2-perl_2.03-1.1.buildlog
> 
>  dh_auto_configure -a
>   dh_auto_configure: warning: Compatibility levels before 10 are deprecated 
> (level 8 in use)
>   /usr/bin/perl -I. Build.PL --installdirs vendor
>   You must install the imlib2 library before you can install
>   Image::Imlib2. You can obtain imlib2 from
>   http://sourceforge.net/projects/enlightenment/

[...]

> I've started to work on patch which uses pkg-config instead of
> imlib2-config; good news: The package builds (as in: actually builds
> code :)) in oldstable+stable+testing+sid and the
> perl-5.38-rebuild-repo; but the tests only pass in oldstable,
> starting with stable/bookworm (aka libimlib2-dev >= 1.10) they fail
> with:
 
>   #   Failed test at t/simple.t line 68.
>   #  got: '0'
>   # expected: '1'

Hi, thanks for looking at this.

FWIW I found some prior art in NetBSD for the pkg-config part:

  
https://github.com/NetBSD/pkgsrc/blob/trunk/graphics/p5-Image-Imlib2/patches/patch-Build.PL

but yours looks good to me as well :)

I think the failing test is a bug in imlib2 1.10.0 and I've just filed #1041406 
about it.

I'm attaching a workaround that might be appropriate at least until imlib2 is 
fixed.
-- 
Niko Tyni   nt...@debian.org
>From c2d646b9fa925ac2a91cb6cfb3fe6dad430c7927 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Tue, 18 Jul 2023 15:16:21 +0100
Subject: [PATCH] Work around an imlib2 bug with alpha channel cloning

As discussed in https://bugs.debian.org/1041406 imlib2 1.10.0 introduced
a bug where imlib_clone_image() no longer copies the alpha flag. This
breaks test 12 of t/simple.t :

  #   Failed test at t/simple.t line 68.
  #  got: '0'
  # expected: '1'

Work around this on our side by checking for any difference after
cloning and copying the alpha flag if necessary.

Bug-Debian: https://bugs.debian.org/1040223
---
 lib/Image/Imlib2.xs | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/lib/Image/Imlib2.xs b/lib/Image/Imlib2.xs
index f48d4ec..cc54d2b 100644
--- a/lib/Image/Imlib2.xs
+++ b/lib/Image/Imlib2.xs
@@ -931,9 +931,20 @@ Imlib2_clone(image)
 CODE:
 	{
 		Imlib_Image cloned;
+		char alpha_orig;
+		char alpha_cloned;
 		
 		imlib_context_set_image(image);
 		cloned = imlib_clone_image();
+
+		/* imlib2 no longer clones the alpha flag since 1.10 */
+		alpha_orig = imlib_image_has_alpha();
+		imlib_context_set_image(cloned);
+		alpha_cloned = imlib_image_has_alpha();
+		if (alpha_orig != alpha_cloned) {
+			imlib_image_set_has_alpha(alpha_orig);
+		}
+		imlib_context_set_image(image);
 		
 		RETVAL = cloned;
 	}
-- 
2.39.1

Bug#1041407: (EE) modeset(0): Failed to set CTM property: -13. (EE) modeset(0): failed to set mode: No such file or directory.

[AlMa]

Package: gdm3
Version: 43.0-3
Control: affects -1 xorg

In the journal I discovered the following errors (EE) that had been 
issued during boot:


/usr/libexec/gdm-x-session[992]: (EE) modeset(0): Failed to set CTM 
property: -13
/usr/libexec/gdm-x-session[992]: (EE) modeset(0): failed to set mode: No 
such file or directory


The parts “(EE) modeset(0): Failed to set CTM property: -13” and “(EE) 
modeset(0): failed to set mode: No such file or directory” are shown in 
yellow. Here's what immediately preceded the error:


…
Jul 18 14:52:50 AnonymizedMachineName gdm-password][2074]: gkr-pam: 
unlocked login keyring
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Successfully 
made thread 2129 of process 2129 owned by '1000' high priority at nice 
level -11.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Supervising 7 
threads of 4 processes of 2 users.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Successfully 
made thread 2132 of process 2132 owned by '1000' high priority at nice 
level -11.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Supervising 8 
threads of 5 processes of 2 users.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Successfully 
made thread 2127 of process 2127 owned by '1000' high priority at nice 
level -11.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Supervising 9 
threads of 6 processes of 2 users.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Supervising 9 
threads of 6 processes of 2 users.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Supervising 9 
threads of 6 processes of 2 users.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Supervising 9 
threads of 6 processes of 2 users.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Supervising 9 
threads of 6 processes of 2 users.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Successfully 
made thread 2180 of process 2129 owned by '1000' RT at priority 20.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Supervising 10 
threads of 6 processes of 2 users.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Supervising 10 
threads of 6 processes of 2 users.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Supervising 10 
threads of 6 processes of 2 users.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Successfully 
made thread 2182 of process 2127 owned by '1000' RT at priority 20.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Supervising 11 
threads of 6 processes of 2 users.
Jul 18 14:52:50 AnonymizedMachineName wireplumber[2129]: Failed to set 
scheduler settings: Die Operation ist nicht erlaubt
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Successfully 
made thread 2184 of process 2132 owned by '1000' RT at priority 20.
Jul 18 14:52:50 AnonymizedMachineName rtkit-daemon[997]: Supervising 12 
threads of 6 processes of 2 users.
Jul 18 14:52:50 AnonymizedMachineName wireplumber[2129]: SPA handle 
'api.libcamera.enum.manager' could not be loaded; is it installed?
Jul 18 14:52:50 AnonymizedMachineName wireplumber[2129]: PipeWire's 
libcamera SPA missing or broken. libcamera not supported.
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(**) Option "fd" "28"
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(II) event5  - Power Button: device removed
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(**) Option "fd" "31"
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(II) event4  - Power Button: device removed
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(**) Option "fd" "32"
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(II) event3  - Sleep Button: device removed
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(**) Option "fd" "33"
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(II) event1  - Microsoft Natural® Ergonomic Keyboard 4000: device removed
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(**) Option "fd" "34"
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(**) Option "fd" "35"
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(II) event8  - USB2.0 FHD UVC WebCam: USB2.0 F: device removed
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(**) Option "fd" "36"
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(II) event9  - USB2.0 FHD UVC WebCam: IR Camer: device removed
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(**) Option "fd" "37"
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(II) event0  - USB Optical Mouse: device removed
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(**) Option "fd" "38"
Jul 18 14:52:51 AnonymizedMachineName /usr/libexec/gdm-x-session[992]: 
(II) event7  - 

Bug#1041406: libimlib2: imlib_clone_image() no longer preserves the alpha channel flag

[Niko Tyni]

Package: libimlib2
Version: 1.10.0-4
Control: affects -1 libimage-imlib2-perl

As per subject, the imlib_clone_image() function no longer preserves
the alpha channel value since imlib2 1.10.0.

The attached test program fails test 3 on bookworm and sid but passes
on bullseye and older.

I've bisected this to upstream change

  
https://git.enlightenment.org/old/legacy-imlib2/commit/b39d33c80020aaa63bc865d640cb4cfa5eb7332a

and it looks to me like an oversight where other functions were adapted
to the new alpha channel implementation, but imlib_clone_image() remains
unchanged and only copies the flags and not the new alpha byte.

I found this while debugging #1040223 in libimage-imlib2-perl, which
currently relies on the old behaviour. It's easy enough to work around
so this is not quite critical, but it does look like an unintentional
API change.

Thanks for your work on Debian,
-- 
Niko Tyni   nt...@debian.org
#include 
#include 

int main(int argc, char **argv)
{
Imlib_Image orig, clone;

printf("1..3\n");
orig = imlib_create_image(300, 400);
if (orig) {
	printf("ok 1 - created image\n");
} else {
	printf("not ok 1 - failed to create image\n");
	return 1;
}

imlib_context_set_image(orig);
imlib_image_set_has_alpha(1);
if (imlib_image_has_alpha()) {
	printf("ok 2 - alpha should be set in the original image\n");
} else {
	printf("not ok 2 - alpha should be set in the original image\n");
}

clone = imlib_clone_image();
imlib_context_set_image(clone);
if (imlib_image_has_alpha()) {
	printf("ok 3 - alpha should be set in the cloned image\n");
} else {
	printf("not ok 3 - alpha should be set in the cloned image\n");
	return 1;
}

return 0;
}

Bug#1041405: snac2: fails to install package when TEMPDIR is only writable by user

[Jonas Smedegaard]

Package: snac2
Version: 2.25-3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Attempting to install snac2 failed like this:

Setting up snac2 (2.25-3) ...
mktemp: failed to create directory via template '/tmp/user/0/tmp.XX': 
Permission denied
dpkg: error processing package snac2 (--configure):
 installed snac2 package post-installation script subprocess returned error 
exit status 1
Errors were encountered while processing:
 snac2

The system has the package libpam-tmpdir installed, which restricts
$TEMPDIR to only be writable by the user.  That seems to trigger this
failure, but I would argue that the problem is the postinst script, not
the restrictive setup of TEMPDIR.

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS2mwAACgkQLHwxRsGg
ASESLhAAkxNkUHjhjde07tOIvoA+ZJOGQ5CpztnLhc/EYYJe49nKdGcg5oHIUzgp
Mpg8fOLtD+Nbh3x5xHrEenMId3rQztBcv96TbMCKG00ZIsYTZ/lUNZmyU+kYGa7+
HlS/Xcq2U9/39mDp0LNY2WCX6rsWVsqp8ZQeB2MTAFec5jaXI2LVb52CAEpFAITq
ta2Q0TkjHNFS7F7tdL65KrH8pMbKX46G+fwl0JHLLg/1RiV+2RMcMJpNRXKykM3a
F/0psJdJs3OTcRlvbGT6S8HkildTVNAHTC+BVqxE/Hq7QbnYT27HD2rqn0qqaBFY
aoTUIcIuhJ/iLFYGZTAqgtTa9LadnimYSRHp35adrVl80RwXtgT69RL3ix66khb3
wI1qWvcI1filtTg4SCcPQFIz5InLRs9ca3DrW0abWqfnJ+TbPUehzh7ZAvJCSqOg
Wr6HlCzN8Tvc8A4A/QZaHbGVxNZL5MTozrykRDZpfA1MZ8q/HyGOnNscdtrFD4sx
IuPk7OzXLH4pBO2ICeqAVhaxn4BA9eyjpZ2oOCsM/JzTLbSs7NNuPHDCNseS7Hr5
CsO668MwE2/BMXBAzHihlCmbVQcO3oCC2ygezMVfsBH7rMnysYYP+cJOh2m1qJqi
7sQpqnBeudr2rH7P/y307O27C34bEA+bw4WBc9TaeVCKD4tQpII=
=H/3p
-END PGP SIGNATURE-

Bug#923908: new upstream version available (9.2)

[David Bremner]

Bastien  writes:

> Hi Nicholas,
>
> thanks for your answer.
>
> Nicholas D Steeves  writes:
>
>> Thank you for the notification, and sorry for the unfortunate state of
>> Org mode in Debian 12 (bookworm).  A variety of factors intersected to
>> generate this outcome, and I wish we, as a team, had been able to do
>> better.
>
> No problem at all.  While I'm at it: any idea on how many persons are
> using the Debian Org package? I suspect there are less and less users,
> because Org comes with Emacs and is easily installable as an Emacs
> package, but perhaps I'm wrong.
>

In the end the state of org-mode in bookworm is fine: users get the
version from emacs as the separate elpa-org package is a dummy package.

It is hard to know what popcon numbers mean in absolute terms, but the
number of installs is overall trending upward:

   
https://qa.debian.org/popcon-graph.php?packages=elpa-org_installed=on_legend=on_ticks=on_fmt=%25Y-%25m=1

The question whether it is worth packaging org in Debian is essentially
the same as for any other package in GNU ELPA. Some users prefer a more
"upstream" approach as it generally gives newer software, while others
find value in the integration and testing provided by Debian.

Bug#1041373: toot: release notes overlooked

[debbug . 1041373]

Package: toot
Version: 0.27.0-1
Followup-For: Bug #1041373
X-Debbugs-Cc: debbug.1041...@sideload.33mail.com

Ivan Habunek said:

> This has been fixed in 0.28.1 (2022-11-12).
> 
> -- Ivan

Thanks Ivan. I searched for this bug both in Github and in the Debian
BTS and found nothing prior to filing the report, but I did not review
the release notes. Sorry about that.  In attempt to improve my own
procedure, I found the Debian release notes here:

  
https://metadata.ftp-master.debian.org/changelogs//main/t/toot/toot_0.34.1-1_changelog

They neglect to mention the fix, which is documented here:

  https://github.com/ihabunek/toot/releases?page=2

In the future, I will try to remember to check both sets of release
notes (Debian & upstream) before filing.

Since the upstream release notes are made available, the Debian policy
suggests that maintainers to include them in the distro release notes.
So I have submitted a separate (downstream) bug report for this but it
has not yet been assigned a number.

--

Sandro Tosi said:

> this is the version in oldstable, it's probably time to upgrade to
> something newer,

Perhaps eventually. I appreciate the information. But it’s important
to realize that upgrading a whole Debian system is not to be taken
lightly. People like myself keep various quite fragile pkgs on
life-support which are easily broken in upgrades. I’ve seen the havoc
and catastrophe dist upgrade can cause. Risks often far outweight the
benefits particularly in this case. It also requires having high-speed
unlimited broadband access. Sometimes either a hot site or cold site,
backups, roll-back contingencies, etc. It’s a big deal. The
undertaking would a crazy remedy to the bug herein, or for anything
toot related for that matter.

Most importantly: oldstable is still officially supported for another
year¹ from now.

> which hopefully will stop this stream of bug reports

Bug reports are essential for QA. It’s better to advocate for bug
reports, not push for their suppression.

> that do not belong to the debian tracking system (as mentioned
> before already).

Please read the “Don't file bugs upstream” section of the bug
reporting procedure².

Footnotes:

① https://wiki.debian.org/DebianReleases
② https://www.debian.org/Bugs/Reporting#filedalready

Bug#1036631: bugfix is available upstream

[Manuel Traut]

Hi,

I added the following two patches to procps:2:4.0.2-3 in bookworm.

This resolved this issue.

Since this bug is also available in bookworm, can you please provide a 
update for stable?


Thanks
ManuelFrom 35dc38cb7fcfb71b151a020abb16197b88370337 Mon Sep 17 00:00:00 2001
From: Jim Warner 
Date: Wed, 24 May 2023 00:00:00 -0500
Subject: [PATCH 1/2] ps: address missing or corrupted fields with -m option

Coincidentally, a Debian bug report and a gitlab issue
were raised at nearly the same time and are referenced
below. They both dealt with that '-m' (thread) option.

That option forces tasks and their threads to be shown
on separate lines. Also, information may be suppressed
between that main process and any lightweight process.

The bottom line was sometimes a required pids_item may
not have been requested from the library before trying
to display a result. For the best case, some incorrect
results might be shown. However, in the worst case (as
with PIDS_WCHAN_NAME) a segmentation fault is created.

[ After addressing the '-m' option problems, another ]
[ issue was found with that '-F' (extra full format) ]
[ option. The PSR (processor) field was always zero. ]
[ It was addressed in a similar manner to the above. ]

Reference(s):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036631
https://gitlab.com/procps-ng/procps/-/issues/279

Signed-off-by: Jim Warner 
---
 src/ps/display.c | 7 +++
 1 file changed, 7 insertions(+)

Index: procps-4.0.2/src/ps/display.c
===
--- procps-4.0.2.orig/src/ps/display.c
+++ procps-4.0.2/src/ps/display.c
@@ -596,6 +596,13 @@ static void finalize_stacks (void)
   // special items with 'extra' used as former pcpu
   chkREL(extra)
   chkREL(noop)
+  // lastly, any remaining needs ...
+  if (format_flags & FF_Uf)
+chkREL(PROCESSOR);
+  if (thread_flags & TF_U_m) {
+chkREL(PRIORITY);
+chkREL(WCHAN_NAME);
+  }
 
   // now accommodate any results not yet satisfied
   f_node = format_list;
From 93b7f05e54293af4919498fceedb236a523336df Mon Sep 17 00:00:00 2001
From: Jim Warner 
Date: Fri, 26 May 2023 00:00:00 -0500
Subject: [PATCH 2/2] ps: trade previous fix for final solution to -m option

Well as luck would have it I found yet another missing
field (SCHED_CLASS) that's needed by that '-m' option.
And, while it could just be added to the previous test
of thread_flags and TF_U_m, here is a much better fix.

[ The problem lies with the lists_and_needs function ]
[ where a new format list was created and some print ]
[ functions changed to pr_nop which displays a dash! ]

[ So, by calling the finalize_stacks function before ]
[ calling lists_and_needs, the former will see those ]
[ format nodes before any print function is changed. ]

Reference(s):
May, 2023 - missing fields with -m option
commit 35dc38cb7fcfb71b151a020abb16197b88370337

Signed-off-by: Jim Warner 
---
 src/ps/display.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

Index: procps-4.0.2/src/ps/display.c
===
--- procps-4.0.2.orig/src/ps/display.c
+++ procps-4.0.2/src/ps/display.c
@@ -596,13 +596,6 @@ static void finalize_stacks (void)
   // special items with 'extra' used as former pcpu
   chkREL(extra)
   chkREL(noop)
-  // lastly, any remaining needs ...
-  if (format_flags & FF_Uf)
-chkREL(PROCESSOR);
-  if (thread_flags & TF_U_m) {
-chkREL(PRIORITY);
-chkREL(WCHAN_NAME);
-  }
 
   // now accommodate any results not yet satisfied
   f_node = format_list;
@@ -672,8 +665,8 @@ int main(int argc, char *argv[]){
 
   init_output(); /* must be between parser and output */
 
-  lists_and_needs();
   finalize_stacks();
+  lists_and_needs();
 
   if(forest_type || sort_list) fancy_spew(); /* sort or forest */
   else simple_spew(); /* no sort, no forest */