Bug#1029534: libreoffice-common: breaks libreoffice-core from the same version

[Rene Engelhard]

Hi,

Am 23.01.23 um 23:04 schrieb Sven Joachim:

The Breaks in libreoffice-common need to be adjusted for the recent
epoch bumps.  Among others, libreoffice-common Breaks
libreoffice-core (>= 1:7.5~), making libreoffice-core 4:7.4.4-7
not installable.

Yeah, that one I noticed yesterday already.

Good luck figuring out what other relationships need to be changed, and
take your time.


Thanks :) Just doing a build and we will see... :)


Regards,


Rene

Bug#1029544: ITP: libtest2-harness-perl -- new and improved test harness with better Test2 integration

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest2-harness-perl
  Version : 1.000141
  Upstream Author : Chad Granum 
* URL : https://metacpan.org/release/Test2-Harness
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : new and improved test harness with better Test2 integration

Test2::Harness is the backend code that handles running/processing the tests.
In general a user will not use it directly, instead you should probably be
looking at App::Yath which is the UI layer built around Test2::Harness.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1029538: RM: coq-theories -- NBS; cruft

[Stéphane Glondu]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: c...@packages.debian.org, debian-ocaml-ma...@lists.debian.org
Control: affects -1 + src:coq

Dear FTP Team,

Please remove all coq-theories (binary) packages from unstable. They
correspond to an old coq source package, but coq has stopped building
them for 4 months. Their presence makes noise in the permanent OCaml
transition tracker [1].

[1] https://release.debian.org/transitions/html/ocaml.html


Cheers,

-- 
Stéphane

Bug#1027943: regina-normal FTBFS with Python 3.11 as default version

[Simon Quigley]

Hi Benjamin, thanks for responding so quickly.

I will cancel the upload in Debian, but it's worth noting that I did upload this to Ubuntu already. (Your version will 
automatically sync over once you upload it.)


Best wishes,
--
Simon Quigley
si...@tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


OpenPGP_signature
Description: OpenPGP digital signature

Bug#991788: xfce4-settings: black screen after suspend when laptop lid is closed and re-opened

[Kurt H Maier]

This bug also causes the desktop to be accessible for a split second
before the lock screen kicks in when resuming from suspend, c.f
https://askubuntu.com/questions/1383379/xubuntu-desktop-visible-after-suspend-before-lock-screen/

I know disabling upower-glib support was frowned upon in the past but
modern upower does not handle suspend/resume or lid events (that
happens via other systemd components now) and xfce4-settings doesn't
need upower for xfce4-power-manager to work properly.

Recompiling wihtout upower-glib closes what is essentially a security
bug, since the expectation is that resumed systems are locked, and this
problem presents a second or two of unrestricted access to the desktop
before locking kicks in.  

I've tested this on a Thinkpad X1 Yoga Titanium and a Thinkpad X1 Yoga
Generation 3 (both with Intel graphics) and a Dell Precision 7820 with
an AMD WX 5100 card, so I don't think it's nVIDIA specific.

Please reconsider --enable-upower-glib.

Thanks,
khm

Bug#1029496: wiki.debian.org: wiki.debian.org/Sound gives wrong advice regarding audio group

[Paul Wise]

On Mon, 2023-01-23 at 12:31 +0100, Christoph Hagemann wrote:

> on the page wiki.debian.org/Sound in section Troubeshooting advice is
> given to add user to the audio group.
> This is no longer true with systemd. In fact, it breaks audio
> switching for multi-user configurations.

Please register an account and edit the page to fix the issue.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#60377: "reset" broken for dumb terminals

[Ben Wong]

On Sat, Jan 21, 2023 at 08:55:26AM +0100, Sven Joachim wrote:
> It does not happen very often that somebody replies to an over 20 years
> old bug, and this seems to have escaped both my and upstream's
> attention.

Thank you, Sven. I realize this is unusual and I hope you do not mind. As a
user, I greatly appreciate that Debian took a "universal" view of this bug
and did not close it for simply being "old", as so many commercial products
do.


On Sat, 21 Jan 2023 17:18:18 -0500, Thomas Dickey wrote:
> Given the size of the patch, it's going to take some time to investigate.
> - Most of the items in question date back to the mid-1990s.

I do apologize for the large patch. It is mostly due to removing all the
undocumented settings.

I tried to find the point in time when the code diverged from the
documentation to see if any reasoning was given, but had no success. I did,
however, manage to figure out why those particular termios options were
chosen: it looks like it was an attempt to set _everything._ The Linux
manpage for termios(3),
https://manpages.debian.org/sid/manpages-dev/termios.3.en.html, contains
the same list in the same order, albeit with a few newer additions. That's
not to say that `reset` was based on the Linux manpage, as they both could
have been derived from some other source. It merely indicates that the
purpose of the code was to be exhaustive.

> - There's also the consideration of compatbility with other systems.

A good question. If such a compatibility issue does turn up, I suggest
that, at a baseline, the code ought to agree with the documentation. If
compatibility problems are minor, it might be possible to accept that this
change would break systems that (unwisely) relied on undocumented features.
On the other hand, if the code cannot change, then the documentation must.
Unfortunately, that looks to be more of a chore as every option that is
kept in the code would need documentation of how reset will change it and
(ideally) why.

--Ben

Bug#1029540: RM: gr-iio -- RoM; RC-buggy;

[A. Maitland Bottoms]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP masters,

Please RM the gr-iio source package.

The current and future versions of gnuradio now directly support IIO
hardware. This branch of development has ended upstream.

This package is obsolete, not going to be part of the python 3.11
migration, not part of the bookworm release.

Thanks,
-Maitland

Bug#1029539: RM: gr-fcdproplus -- RoM; RC-buggy;

[A. Maitland Bottoms]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP masters,

Please RM the gr-fcdproplus source package.

The current and future versions of gnuradio no longer handle the FunCube
Dongle hardware in the way gr-fcdproplus did. (Switching from swig
bindings to pybind11 for the Pythonic interface.)
The same hardware is supported via the gr-osmosdr package, upstream
development of this path has ceased.

This package is obsolete, not going to be part of the python 3.11
migration, not part of the bookworm release.

Thanks,
-Maitland

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[fabian]

Hi Roland,

Am 23.01.2023 18:23, schrieb Roland Rosenfeld:

Now we only have to solve the lintian error
license-problem-font-adobe-copyrighted-fragment-no-credit issue...


wow, the information given here is not really helpful. What can/should 
we do?


https://wiki.debian.org/qa.debian.org/type1nondfsg

 - Fabian

Bug#1029543: hw-detect: clarify use cases about searching for firmware packages on external media

[Cyril Brulebois]

Package: hw-detect
Severity: important
X-Debbugs-Cc: debian-...@lists.debian.org

Hi,

[debian-arm@ in copy for the question regarding concatenateable
images near the end.]

I'm filing this as important for the time being, but this can be made
serious if required. Reminder: doing so might or might not block the
12.0 release (it could be usertagged can-defer).


Firmware support has long been a very difficult topic to navigate, for
mere users but also for more advanced users who might try and include
firmware files and/or packages onto external media, then wonder what
they did wrong because that still doesn't work.

With the 2022 General Resolution about non-free firmware, and with
non-free-firmware packages being allowed on official installation
images, Steve and I were hoping[1] to limit ourselves to a much more
streamlined process: use whatever's available on the official image, and
stop pretending to support loading firmware material from elsewhere.

 1. https://lists.debian.org/debian-boot/2022/10/msg00044.html

Since then, the received feedback and my own testing triggered mixed
feelings:
 - In that thread, some reason was given suggesting to retain the
   ability to load firmware packages from external media;
 - On IRC, while I was rubberducking firmare support in hw-detect,
   the same person mentioned that the current implementation doesn't
   suit their needs anyway, due to the way the search for firmware is
   performed.
 - My own tests show that the “Detect network hardware” step can be
   stuck for a long time (e.g. 15+ seconds without anything on the
   screen but a title, probably depends on the storage). While I initially
   suspected a problem with my ongoing work, it turned out that both
   “mountmedia” and “mountmedia driver” calls were responsible for most of
   that time's being wasted.

The first call (“mountmedia”):
 - tries to find “loose firmware files” under /media as mounted by
   mountmedia, to copy them in the installer's context;
 - lets those files be propagated to /target later on.

The second call (“mountmedia driver”):
 - uses the same check_firmware function that's already called on
   /firmware and /cdrom/firmware (where official installation images for
   Bookworm will find non-free-firmware packages); this means packages
   are unpacked in the installer environment, and queued for later
   installation into /target;
 - looks under both /media and /media/firmware (with /media having been
   mounted by “mountmedia driver”).


Some use cases:
 - Users might require some firmware packages that aren't available in
   Debian yet;
 - Users might want to stash a higher version of a firmware package that
   is available in Debian already;
 - 

Some problems:
 - Delays for users that have everything on their official installation
   images.
 - Insufficient lookup (something about stopping at the first partition
   that's found or something, but I don't know the specifics, and I'm
   not diving into what “mountmedia driver” does or should be doing).
 - What happens in the “higher version” case? Currently we do not have
   anything to detect/process multiple versions of a package, so we might
   end up deploying a firmware package found on the installation image,
   then deploying a different version of the same firmware package found
   on external media; but then both are queued and which one gets
   installed first and which one second depends on the order in which
   their filenames come up in the for loop around `in-target dpkg -i`…
   If we wanted to support that, we would need more code to only keep the
   higher version.


I'm also not sure what our plan for e.g. ARM images (concatenateable
images) would be; I don't think we'll pull any firmware packages during a
d-i build, so they wouldn't end up under [2], but maybe it'd be feasible
to just concatenate some file/image containing non-free-firmware packages
(along with the associated metadata if relevant) as published by debian-cd
or something? Or would those concatenateable images need to load firmware
from external media anyway?

 2. 
https://deb.debian.org/debian/dists/bookworm/main/installer-arm64/current/images/netboot/SD-card-images/

In any case, we could probably try and accommodate architecture-specific
issues… by wrapping required calls inside proper conditions, so that
special needs (on release archs or non-release archs) don't negatively
impact regular users.


In the meanwhile, I'll disable both mountmedia calls in the upcoming
upload:
 - to reduce delays when official installation images are just
   self-sufficient (that's why we had that GR in the first place!);
 - to gather feedback/complaints from users for which those calls are
   actually important, so that we can better assess the needs, and the
   possible shortcomings in the historical implementation.


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

Bug#1029447: unmuting audio breaks video playing in browsers

[Marco d'Itri]

On Jan 23, Dylan Aïssi  wrote:

> With wireplumber installed and after a reboot what is the output of
> "pactl info"?
Identical:

Server String: /run/user/1000/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 16
Tile Size: 65472
User Name: md
Host Name: bongo.bofh.it
Server Name: pulseaudio
Server Version: 16.1
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-_33_00.6.analog-stereo
Default Source: 
alsa_input.pci-_33_00.5-platform-acp_yc_mach.0.stereo-fallback
Cookie: bf7b:46f0

> And what audio backend uses firefox (in "about:support" then in the
> "Audio section" )?
Always "pulse-rust".

> Do you have both  wireplumber.service and pipewire-pulse.service running?
I did not have pipewire-pulse installed.
Installing it and starting the daemon with "systemctl status --user 
pipewire-pulse.service" fixed the video issue, but there was no audio 
from the browser.
Actually restarting the gnome session restored the audio too.

While this is not a serious issue, I think that the failure mode is 
non-obvious enough that something should be changed to prevent this 
situation.

Are there any other non-obvious packages that should be installed?
E.g. I see that pipewire-pulse recommends pipewire-alsa, but I have no 
idea of what I would need it for.

BTW, after installing wireplumber now something emits an annoying beep 
when I raise/lower the volume with the keyboard volume keys: how can 
I disable it?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1029541: Error: /undefinedfilename in (/usr/bin/ps2epsi.ps)

[Rumile Czyborra]

Package: ghostscript
Version: 9.53.3~dfsg-7+deb11u2
Severity: normal
X-Debbugs-Cc: czybo...@gmail.com

To be able to use ps2espi, I had to
czyborra@penguin:~$ sudo ln /usr/share/ghostscript/9.53.3/lib/ps2epsi.ps 
/usr/bin

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

Kernel: Linux 5.10.147-20159-g06a9a2b12b31 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ghostscript depends on:
ii  libc6   2.31-13+deb11u5
ii  libgs9  9.53.3~dfsg-7+deb11u2

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
pn  ghostscript-x  

-- no debconf information

Bug#1029481: fixed with version 3.1.0-2

[Paul Wise]

On Mon, 2023-01-23 at 11:21 +0100, Christoph Martin wrote:

> The other lines reported with
> 
> dgrep -A5 'auto-generated' debmake
> 
> are false-positives since they are files from the debmake package and
> not from yq.

That was just an illustration of where the yq package description that
was containing "auto-generated" was copied from, not a demonstration of
the problematic parts of the yq package, which was the first command.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#882640: Following up on this Thread

[Tommy McGee]

Hello,

I come from the group that builds and maintains dm-zoned-tools. I can
maintain this package as needed, however while prepping to submit a new
RFS I ran across this thread in the Wnnp.

Is there anything we can do to help get this in the archive.

Thank you 
v/r
Tommy McGee 

Bug#1028197: plasmashell: Program terminated with signal SIGSEGV

[piorunz]

On 24/01/2023 00:05, Bernhard Übelacker wrote:

Am 24.01.23 um 00:30 schrieb piorunz:

On 23/01/2023 22:46, Bernhard Übelacker wrote:

https://bugs.debian.org/1028197

On Mon, 23 Jan 2023 21:48:23 + piorunz  wrote:

On 23/01/2023 13:35, Bernhard Übelacker wrote:
  journalctl --user --since="2023-01-08 12:10" --until="2023-01-08 
12:12"

-- No entries --


Then please try something like this:

   journalctl --user --since="2023-01-08 11:08" --until="2023-01-08 
11:12"


That worked! Attached.




Jan 08 11:11:06 ryzen systemd-coredump[1987371]: Process 1341349 (kded5) 
of user 1000 dumped core.

...
  #3  0x7faafb991f90 
n/a (libc.so.6 + 0x3bf90)
  #4  0x7faa7b2e8ba4 
_ZNK10PackageKit11Transaction4roleEv (libpackagekitqt5.so.1 + 0x1aba4)
  #5  0x7faa7b3a4aae 
n/a (kded_apperd.so + 0xeaae)
  #6  0x7faa7b3a4b99 
n/a (kded_apperd.so + 0xeb99)
  #7  0x7faafb6e8fcf 
n/a (libQt5Core.so.5 + 0x2e8fcf)
  #8  0x7faa7b2dc095 
_ZN10PackageKit6Daemon22transactionListChangedERK11QStringList 
(libpackagekitqt5.so.1 + 0xe095)
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: 
XRandR::setConfig
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: 
Requested screen size is QSize(7680, 2160)
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: 
Needed CRTCs:  2
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: 
Actions to perform:
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]:  Primary 
Output: false
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: 
kscreen.xrandr: Change Screen Size: false
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: 
kscreen.xrandr: Disable outputs: false
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: 
kscreen.xrandr: Change outputs: false
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: 
kscreen.xrandr: Enable outputs: false
Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: 
XRandR::setConfig done!
Jan 08 11:11:07 ryzen plasmashell[5575]: QFont::setPointSizeF: Point 
size <= 0 (0.00), must be greater than 0

Jan 08 11:11:07 ryzen plasmashell[5575]: 25 -- exe=/usr/bin/plasmashell
Jan 08 11:11:07 ryzen plasmashell[5575]: KCrash: crashing... 
crashRecursionCounter = 2



Here was also just before such a kded5 crash right before.
Either this or the startup of the new kded5 might trigger this,
as it looks like setting up some screen parameters (xrandr).
And while doing this plasmashell wrote
this "QFont::setPointSizeF" message.

Those two upstream bugs appear, but both got closed,
because upstream could not reproduce them:
   https://bugs.kde.org/show_bug.cgi?id=453712
   https://bugs.kde.org/show_bug.cgi?id=462098

I don't know which package management you use,
but until there is a fix for Debian #1026062,
you could experiment with another package manager
like synaptic and uninstall apper for now, as a workaround.

Kind regards,
Bernhard



I use apt + nala to upgrade my system, install and uninstall packages.
Very rarely I ever launch KDE's Discover program. Discover has came with 
Debian's KDE, I did not asked for it to be installed.
apper, about which I didn't know anything until this issue, also came 
with KDE uninvited. Just found this in apt logs:


Start-Date: 2023-01-08  15:03:28
Commandline: apt purge apper
Requested-By: pioruns (1000)
Purge: apper:amd64 (1.0.0-3)
End-Date: 2023-01-08  15:03:30

I uninstalled apper after I reported this bug it seems, thanks to advice 
from Debian KDE mailing list. This particular bug has not returned since 
then. Today I had another desktop crash, but that's probably unrelated. 
I can install apper again if you want me to try and reproduce some more 
of it.


--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Bug#1025375: hydrogen-doc: documentation binary package is almost empty, should it be dropped entirely?

[Nicholas D Steeves]

Control: forwarded -1 https://github.com/hydrogen-music/documentation/issues/73

Dear Francesco,

I've enjoyed reading and learning from your analyses on debian-legal,
and I'm happy it was you who noticed this issue and filed this bug!
[edit: sorry for the delay, it seems I forgot to send this draft 22 Dec
2022]

There is hope, and GPL2+ licensed docs are pending, but upstream may not
be able to meet our deadlines.  I suspect a statement of yours upstream
may expedite the process ;) tldr: It looks to me like the remaining two
old contributors contributed documentation under GPL2+ and that there
isn't any need to rubber-stamp the new documentation subproject, because
their contributions remain inherently GPL2+ licensed, because that
license could not have been legally stripped by moving their work from
the GPL2+ Hydrogen project to the accidentally license-less period of the
Hydrogen/Documentation subproject.

In terms of strategy/plan, a near-empty bin:hydrogen-doc in src:hydrogen
keeps the door open for this: In the event upstream is too slow, we
populate src:hydrogen's bin:hydrogen-doc with the new documentation from
the upstream "Hydrogen/Documentation" subproject during the freeze.  If
upstream moves quickly enough then it may be possible to for a
src:hydrogen-documentation upload to experimental that takes over
bin:hydrogen-docs to clear the NEW queue; after that, it would be
possible to drop bin:hydrogen-docs from src:hydrogen package in
unstable.

To be honest, I'm not sure if there will be enough time for an ideal
solution, and I'm not convinced that a separate NEW
src:hydrogen-documentation package would be ideal, but I preemptively
filed an RFP (with context) in case someone preferred[s] this solution
and wanted[s] to start work on it:

  https://bugs.debian.org/1020936

I'd be totally OK with you (or someone else) taking up the baton for
these two interrelated bugs. (1025375 and 1020936)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#1029542: ITP: libtest2-plugin-uuid-perl -- mechanism to use real UUIDs in the Test2 suite

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest2-plugin-uuid-perl
  Version : 0.002001
  Upstream Author : Chad Granum 
* URL : https://metacpan.org/release/Test2-Plugin-UUID
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : mechanism to use real UUIDs in the Test2 suite

Test2 normally uses unique IDs generated by appending pid, thread-id, and an
incrementing integer. These work fine most of the time, but are not
sufficient if you want to keep a database of events, in that case a real UUID
is much more useful.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1029543: hw-detect: clarify use cases about searching for firmware packages on external media

[Cyril Brulebois]

Cyril Brulebois  (2023-01-24):
> In the meanwhile, I'll disable both mountmedia calls in the upcoming
> upload:
>  - to reduce delays when official installation images are just
>self-sufficient (that's why we had that GR in the first place!);

I thought about this a few hours/days ago but forgot to mention it: we
have a list of requested files, and a list of requesting modules. We
could maintain a list of modules for which a matching package has been
found and installed, and decide to skip mountmedia call(s) if a package
has been installed for each and every requesting module.

This wouldn't help in the “what about a possible higher version of an
existing package” use case, but it would be better for users of
exotic¹ hardware than axing the mountmedia call(s) altogether.

  [¹] as in: not supported by non-free-firmware packages.


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


signature.asc
Description: PGP signature

Bug#1025985: glosstext: FTBFS: LaTeX Error: File `pdftexcmds.sty' not found.

[Hilmar Preuße]

Control: affects -1 src:glosstex

Bug#1029497: ftp.debian.org: weird non-free-firmware/dep11 structure in bookworm

[Colin Watson]

Package: ftp.debian.org
Severity: normal

The dep11 structure in sid (and its InRelease file) looks like this:

  {main,contrib,non-free,non-free-firmware}/dep11/{Components,icons}-*

But in bookworm it looks like this:

  {main,contrib,non-free}/dep11/{Components,icons}-*
  
non-free-firmware/dep11/{bookworm,bullseye,bullseye-backports,...}/{main,contrib,non-free}/{Components,icons}-*

This looks very weird and broken - shouldn't the
dists/bookworm/non-free-firmware/dep11/ structure look like the other
components, and also like dists/sid/non-free-firmware/dep11/?

This causes a crash in the version of debmirror used as part of the
arrangements for auto-syncing Debian into Ubuntu, which is how I noticed
this; but it looks like a bug on the ftp.d.o side.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1004070: linux-image-4.19.0-18-amd64: kernel crashes when accessing files via nfs

[Friedrich Beckmann]

Hi Salvatore,

thanks for asking! If I remember correctly later kernels did not work at the 
time when I tested this. But have not tried more recent 4.19.x kernel. At the 
moment I do not have that much time but I will share the results here once I 
test that.

Regards

Friedrich

> Am 21.01.2023 um 20:47 schrieb Salvatore Bonaccorso :
> 
> Control: tags -1 + moreinfo
> 
> Hi Friedrich,
> 
> On Thu, Jan 20, 2022 at 11:08:35AM +0100, Friedrich Beckmann wrote:
>> Package: src:linux
>> Version: 4.19.208-1
>> Severity: important
>> 
>> Dear Maintainer,
>> 
>> after dist-upgrading to debian 10 the kernel crashes when accessing
>> files on nfs mounted filesystems. The bug can be reproduced by writing
>> between 100 and 1000 files á 50MByte to the mounted filesystem. The system
>> crashes completely, i.e. you cannot ping and ssh is dead. I have
>> to powercycle via ipmi to come back.
>> 
>> The bug is not there when I boot the previous 4.9.0-16-amd64 kernel.
>> 
>> This is a headless system with 4 nvidia gpus running with the proprietary
>> nvidia driver version 470.82.01. I do not think that this is related as
>> the bug happens even when nothing is happening on the gpus. The bios is from 
>> 2015 but I
>> load the intel-microcode.
>> 
>> Looking upstream, maybe this bug is related to
>> 
>> Bug 203827 - NFS v4.1 and v4.2 still unstable - 
>> https://bugzilla.kernel.org/show_bug.cgi?id=203827
>> Bug 200145 - kernel: FS-Cache: Duplicate cookie detected - 
>> https://bugzilla.kernel.org/show_bug.cgi?id=200145
>> 
>> Regards
>> 
>> Friedrich
>> 
>> I can reproduce the bug with the following script:
>> 
>> === killer script
>> #! /bin/bash -xe
>> cnt=1
>> for (( ; ; ))
>> do
>>echo "Run: $cnt"
>>((cnt++))
>>dd if=/dev/urandom of=~/sf bs=1M count=50
>>   rm ~/sf  
>> done
>> ===
>> 
>> 
>> == kern.log
>> Jan 20 09:51:50 breakout kernel: [  133.957968] FS-Cache: Duplicate cookie 
>> detected
>> Jan 20 09:51:50 breakout kernel: [  133.959815] FS-Cache: O-cookie 
>> c=0d1e4bca [p=6521ae05 fl=212 nc=0 na=0]
>> Jan 20 09:51:50 breakout kernel: [  133.961667] FS-Cache: O-cookie d=
>>   (null) n=  (null)
>> Jan 20 09:51:50 breakout kernel: [  133.963553] FS-Cache: O-key=[16] 
>> '0400010002000801c0a8505a'
>> Jan 20 09:51:50 breakout kernel: [  133.965407] FS-Cache: N-cookie 
>> c=883b7c78 [p=6521ae05 fl=2 nc=0 na=1]
>> Jan 20 09:51:50 breakout kernel: [  133.967273] FS-Cache: N-cookie 
>> d=dc94612b n=2d9b546b
>> Jan 20 09:51:50 breakout kernel: [  133.968059] FS-Cache: N-key=[16] 
>> '0400010002000801c0a8505a'
>> Jan 20 09:51:58 breakout kernel: [  141.528246] FS-Cache: Duplicate cookie 
>> detected
>> Jan 20 09:51:58 breakout kernel: [  141.529925] FS-Cache: O-cookie 
>> c=ab5caa2d [p=6521ae05 fl=212 nc=0 na=0]
>> Jan 20 09:51:58 breakout kernel: [  141.531542] FS-Cache: O-cookie d=
>>   (null) n=  (null)
>> Jan 20 09:51:58 breakout kernel: [  141.533136] FS-Cache: O-key=[16] 
>> '0400010002000801c0a8505a'
>> Jan 20 09:51:58 breakout kernel: [  141.534743] FS-Cache: N-cookie 
>> c=65656ae5 [p=6521ae05 fl=2 nc=0 na=1]
>> Jan 20 09:51:58 breakout kernel: [  141.536340] FS-Cache: N-cookie 
>> d=dc94612b n=49e94c35
>> Jan 20 09:51:58 breakout kernel: [  141.537919] FS-Cache: N-key=[16] 
>> '0400010002000801c0a8505a'
>> Jan 20 09:52:27 breakout kernel: [  170.456631] general protection fault: 
>>  [#1] SMP PTI
>> Jan 20 09:52:27 breakout kernel: [  170.458602] CPU: 5 PID: 13651 Comm: dd 
>> Tainted: P   OE 4.19.0-18-amd64 #1 Debian 4.19.208-1
>> Jan 20 09:52:27 breakout kernel: [  170.460511] Hardware name: Supermicro 
>> SYS-7048GR-TR/X10DRG-Q, BIOS 2.0 12/31/2015
>> Jan 20 09:52:27 breakout kernel: [  170.462416] RIP: 
>> 0010:__kmalloc+0xaa/0x220
>> Jan 20 09:52:27 breakout kernel: [  170.464307] Code: 08 65 4c 03 05 cf 2e 
>> fe 78 49 83 78 10 00 49 8b 28 0f 84 0c 01 00 00 48 85 ed 0f 84 03 01 00 00 
>> 41 8b 47 20 49 8b 3f 48 01 e8 <48> 8b 18 48 89 c1 49 33 9f 38 01 00 00 48 89 
>> e8 48 0f c9 48 31 cb
>> Jan 20 09:52:27 breakout kernel: [  170.466332] RSP: 0018:9dfda84cf5b8 
>> EFLAGS: 00010282
>> Jan 20 09:52:27 breakout kernel: [  170.468343] RAX: bf0892e61936d294 RBX: 
>>  RCX: 2a674397
>> Jan 20 09:52:27 breakout kernel: [  170.470390] RDX: b080 RSI: 
>> 006000c0 RDI: 00025540
>> Jan 20 09:52:27 breakout kernel: [  170.472401] RBP: bf0892e61936d294 R08: 
>> 8cbaff965540 R09: 8cbaff407300
>> Jan 20 09:52:27 breakout kernel: [  170.474421] R10: 8cbaf2bed684 R11: 
>> 8cbae401a940 R12: 006000c0
>> Jan 20 09:52:27 breakout kernel: [  170.476444] R13: 0029 R14: 
>> 8cbaff407780 R15: 8cbaff407780
>> Jan 20 09:52:27 breakout kernel: [  170.478471] FS:  7f0afeeeb580() 
>> GS:8cbaff94() 

Bug#964607: Massive update necessary

[Pirate Praveen]

On Thu, 25 Nov 2021 18:54:24 +0100 Daniel Leidert  
wrote:
> This gem is out-of-date. Upstream is at 3.2.2, which requires 
packaging for
> google-cloud-translate-v2 and google-cloud-translate-v3 and updating 
google-

> cloud-core to >= 1.6. The tests require packageing google-style.

This is a leaf package, likely packaged for loomio. I think we can 
ignore this for bookworm. May be we should use a usertag to mark such 
packages which can ignore rc bugs for bookworm (it could be useful in 
future if loomio packaging is revived, since upstream is still active, 
we can probably keep it in unstable).

Bug#1029504: bat: /usr/bin/bat vs. /usr/sbin/bat in bacula-console-qt

[Andreas Beckmann]

Package: bat
Version: 0.22.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Undoing the bat/batcat rename was not a good idea: while src:bacula no
longer ships the (transitional) /usr/bin/bat -> /usr/sbin/bat symlink in
bacula-console-qt, it still has the /usr/sbin/bat binary (and its
bat.1.gz manpage which is now causing a file conflict) and thus src:bat
may not use the /usr/bin/bat filename.

(bacula-console-qt should probably better move the manpage to section 8
if the binary resides in sbin, but that is not the point here.)


Andreas

Bug#1020641: dhcpcd5: dhcpcd fails to chroot during start

[Martin-Éric Racine]

On Sun, Jan 22, 2023 at 9:17 PM Martin-Éric Racine
 wrote:
>
> On Sun, 22 Jan 2023 17:22:35 +0100  wrote:
>
> > This is kind of a continuation from 1014277, where I have mentioned that
> > it still logs some chroot related issues.
> > Now I have the time to create a proper patch and attach it to this bug.
> > It would be great if it could make it to bookworm, as the freeze is
> > coming :)
>
> Thanks! The fix seems simple enough. However, I'm a bit worried about
> introducing it so close to the freeze.

Merged in Salsa Git.

> > Reporting that to upstream does not make sense right now, as the systemd
> > unit files are debian specific additions.
>
> Agreed, although it would make sense for upstream to ship those
> systemd units as well. However, this would probably require fixing
> outstanding issues outlined in bug #1020641 first.

Which still needs a permanent fix.

Martin-Éric

Bug#1029506: ITP: libtest2-tools-explain-perl -- Perl module with explain tools for Perl's Test2 framework

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest2-tools-explain-perl
  Version : 0.02
  Upstream Author : Andy Lester 
* URL : https://metacpan.org/release/Test2-Tools-Explain
* License : Artistic-2.0
  Programming Lang: Perl
  Description : Perl module with explain tools for Perl's Test2 framework

Test2::Tools::Explain -- Provides explain tools for Perl's Test2 framework.

Test2::Suite dropped the explain() function that had been part of Test::More.
For those who miss it in Test2, you can use Test2::Tools::Explain.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1029490: ldd.fakechroot: emits broken Ldsodir on ppc64el and s390x (and probably more)

[Helmut Grohne]

Package: fakechroot
Version: 2.20.1+ds-8
Severity: important
File: /usr/bin/ldd.fakechroot
Control: affects -1 + initramfs-tools-core debvm

Running ldd.fakechroot on ppc64el yields:

ld64.so.2 => /lib/powerpc64le-linux-gnu/ld64.so.2 (0x)

Instead, it should be saying /lib64/ld64.so.2.

I recommend reviewing https://wiki.debian.org/ArchitectureSpecificsMemo
and adding all the ld.so paths.

This happens to break update-initamfs when run under fakechroot as it
fails to include /lib64/ld64.so.2 in the initramfs and thus fails to run
anything. This happens to break debvm autopkgtests.

Helmut

Bug#1029310: [Help] Re: Bug#1029310: src:r-cran-bayesplot: fails to migrate to testing for too long: autopkgtest regression

[Andreas Tille]

Am Sat, Jan 21, 2023 at 10:17:06PM +0530 schrieb Nilesh Patra:
> On 1/21/23 21:59, Andreas Tille wrote:
> > Am Sat, Jan 21, 2023 at 09:46:07PM +0530 schrieb Nilesh Patra:
> > > On 1/21/23 16:56, Andreas Tille wrote:
> > > > as per DebCI there are 15 autopkgtest failures which seem to be
> > > > connected to ggplot2 API somehow.[1]  Interestingly Salsa CI[2] does not
> > > > show this autopkgtest error neither can I reproduce the problem on my 
> > > > local
> > > > pbuilder.
> > > > 
> > > > Has anyone some idea what might be wrong?  If not I might ask bug 
> > > > reporter
> > > > for more info.
> > > 
> > > I can't repro it either.
> > 
> > Relieving to know that I did not missed any basic thing here. ;-)
> > 
> > > But the log you point to is a fresh failure (today).
> > > Did not dig deeper, but did you take a look at the `diff` between log 
> > > that passes and the one
> > > which does not?
> > 
> > Not yet.  Where can I find those old logs?
> 
> You can take a diff betweek ci log you pointed to and the log on salsa 
> CI/local system.
> The debci runs with package versions in testing, so there might be a bump in 
> some dependency.

I did a diff between the r-cran-* packages in the failing log and the
successful log: 


--- debci (with dependencies from testing which fails 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-bayesplot/30584842/log.gz
+++ salsa (with dependencies from unstable which works)
@@ -2,8 +2,8 @@
@@ -153,12 +153,13 @@

-r-base-core_4.2.2.20221110-1+b1_amd64.deb
+r-base-core_4.2.2.20221110-1_amd64.deb

-r-cran-bayesplot_1.9.0-1_all.deb
+r-cran-bayesplot.deb

-r-cran-cli_3.6.0-1_amd64.deb
+r-cran-cli_3.5.0-1_amd64.deb

-r-cran-ggplot2_3.4.0+dfsg-2_all.deb
+r-cran-ggplot2_3.4.0+dfsg-1_all.deb

-r-cran-htmlwidgets_1.6.1+dfsg-1_all.deb
-r-cran-httpuv_1.6.8+dfsg-1_amd64.deb
+r-cran-htmlwidgets_1.6.0+dfsg-1_all.deb
+r-cran-httpuv_1.6.7+dfsg-1_amd64.deb

-r-cran-purrr_0.3.5-1_amd64.deb
+r-cran-purrr_1.0.0-1_amd64.deb

-r-cran-rcppparallel_5.1.6+dfsg-1_amd64.deb
+r-cran-rcppparallel_5.1.5+dfsg-3_amd64.deb

-r-cran-statmod_1.5.0-1_amd64.deb
-r-cran-stringi_1.7.12-1_amd64.deb
-r-cran-stringr_1.4.1-1_all.deb
+r-cran-statmod_1.4.37-1_amd64.deb
+r-cran-stringi_1.7.8-1+b1_amd64.deb
+r-cran-stringr_1.5.0-1_all.deb

-r-cran-xts_0.12.1-1_amd64.deb
+r-cran-xts_0.12.2-1_amd64.deb


to me those diffs are locking not really spectacular regarding to
the actual issue.  I also checked the debci history[1] where the
first failure of this kind is

1.9.0-1 2022-11-11 23:59:45 UTC 
r-cran-ggplot2/3.4.0+dfsg-1 diffoscop...
src:r-cran-ggplot2 from unstable
src:diffoscope from unstable
src:r-base from unstable
src:r-cran-vctrs from unstable 

where I can find inside the test log[2]

This might correlate to

r-cran-ggplot2 (3.4.0+dfsg-1) unstable; urgency=medium

  * New upstream version
...
 -- Andreas Tille   Fri, 11 Nov 2022 08:24:21 +0100



I admit I'm running out of ideas but for the moment my last resort
is to skip the 8 affected test, let the packages migrate to testing
and revert skipping the tests afterwards.

Kind regards
Andreas.



[1] https://ci.debian.net/packages/r/r-cran-bayesplot/testing/amd64/
[2] 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-bayesplot/28139180/log.gz

-- 
http://fam-tille.de

Bug#1029479: lintian: reject packages with debmake default description

[Axel Beckert]

Control: tag -1 + confirmed

Hi Paul,

Paul Wise wrote:
> yq was just accepted into Debian with a completely bogus description
> that is the default from the debmake automatic package generator.

Right, noticed that, too. Writing a bug report about that was on my
TODO list. So thanks for filing https://bugs.debian.org/1029481 :-)

> Please add a lintian tag and add it to the ftp-master auto-rejects.

Definitely a good addition. No promises that this will be added before
Bookworm, though.

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

Bug#1029493: r8168-dkms: Debian 11 KDE UI freeing eno1: esd_flag = 0x7bff ; eno1: cmd = 0xff, should be 0x07

[user]

Package: r8168-dkms
Version: 8.048.03-3
Severity: important

Dear Maintainer,

   * What led up to the situation? Enabling kernel module r8169
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Disabling kernel module "modprobe -r r8169" stopped freezing


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

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

Versions of packages r8168-dkms depends on:
ii  dkms  2.8.4-3

r8168-dkms recommends no packages.

r8168-dkms suggests no packages.

Bug#1029496: wiki.debian.org: wiki.debian.org/Sound gives wrong advice regarding audio group

[Christoph Hagemann]

Package: wiki.debian.org
Severity: normal
X-Debbugs-Cc: christoph_hagem...@gmx.de

Dear Maintainers,

on the page wiki.debian.org/Sound in section Troubeshooting advice is
given to add user to the audio group.
This is no longer true with systemd. In fact, it breaks audio switching
for multi-user configurations.
Please refer here: https://wiki.ubuntu.com/Audio/TheAudioGroup.

So the advice should change to: Check, that no user is in the audio
group.

Thanks,
Christoph Hagemann

Bug#1028479: bpfcc-tools: insecure use of /tmp

[Ritesh Raj Sarraf]

Control: tag -1 pending


Hello Jakub,

Thank you for your bug report. I have prepared a fix and tested it
locally. Will be uploading it soon today.


rrs@chutzpah:/var/tmp$ cat /tmp/kheaders-6.1.0-2-amd64/include/linux/kconfig.h  
  
#error this header is malicious
17:19 ♒♒♒☹  => 1  


rrs@chutzpah:/var/tmp$ sudo opensnoop-bpfcc 
modprobe: FATAL: Module kheaders not found in directory 
/lib/modules/6.1.0-2-amd64
Unable to find kernel headers. Try rebuilding kernel with CONFIG_IKHEADERS=m 
(module) or installing the kernel development package for your running kernel 
version.
chdir(/lib/modules/6.1.0-2-amd64/build): No such file or directory
Traceback (most recent call last):
  File "/usr/sbin/opensnoop-bpfcc", line 261, in 
b = BPF(text='')

  File "/usr/lib/python3/dist-packages/bcc/__init__.py", line 476, in __init__
raise Exception("Failed to compile BPF module %s" % (src_file or ""))
Exception: Failed to compile BPF module 
17:19 ♒♒♒☹  => 1  

rrs@chutzpah:/var/tmp$ sudo apt install linux-headers-amd64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  linux-headers-6.1.0-2-amd64 linux-headers-6.1.0-2-common
The following NEW packages will be installed:
  linux-headers-6.1.0-2-amd64 linux-headers-6.1.0-2-common linux-headers-amd64
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.8 MB/10.8 MB of archives.
After this operation, 60.9 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://deb.debian.org/debian unstable/main amd64 
linux-headers-6.1.0-2-common all 6.1.7-1 [9,717 kB]
Get:2 http://deb.debian.org/debian unstable/main amd64 
linux-headers-6.1.0-2-amd64 amd64 6.1.7-1 [1,099 kB]
Fetched 10.8 MB in 0s (25.6 MB/s)  
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package linux-headers-6.1.0-2-common.
(Reading database ... 328518 files and directories currently installed.)
Preparing to unpack .../linux-headers-6.1.0-2-common_6.1.7-1_all.deb ...
Unpacking linux-headers-6.1.0-2-common (6.1.7-1) ...
Selecting previously unselected package linux-headers-6.1.0-2-amd64.
Preparing to unpack .../linux-headers-6.1.0-2-amd64_6.1.7-1_amd64.deb ...
Unpacking linux-headers-6.1.0-2-amd64 (6.1.7-1) ...
Selecting previously unselected package linux-headers-amd64.
Preparing to unpack .../linux-headers-amd64_6.1.7-1_amd64.deb ...
Unpacking linux-headers-amd64 (6.1.7-1) ...
Setting up linux-headers-6.1.0-2-common (6.1.7-1) ...
Setting up linux-headers-6.1.0-2-amd64 (6.1.7-1) ...
Setting up linux-headers-amd64 (6.1.7-1) ...
17:20 ♒♒♒   ☺



rrs@chutzpah:/var/tmp$ sudo opensnoop-bpfcc 
  
PIDCOMM   FD ERR PATH
1629   ksystemstats   22   0 /proc/diskstats 
1629   KIO::WorkerThre24   0 /proc/self/mountinfo
1629   KIO::WorkerThre24   0 /dev/disk/by-label
1629   KIO::WorkerThre22   0 /proc/self/mountinfo
1629   KIO::WorkerThre22   0 /dev/disk/by-label
1629   KIO::WorkerThre22   0 /proc/self/mountinfo

... snipped ...


On Wed, 2023-01-11 at 19:09 +0100, Jakub Wilk wrote:
> Package: bpfcc-tools
> Version: 0.25.0+ds-1
> Tags: security
> 
> If kernel headers are not installed in the usual place, the BPF tools
> try to look them up in /tmp/kheaders-$(uname -r)/, even when this 
> directory is owned by another user.
> 
> This can be exploited for denial of service, or likely something
> worse.
> 
> To reproduce, run this as a normal user:
> 
>     $ mkdir /tmp/kheaders-$(uname -r)/
>     $ mkdir -p /tmp/kheaders-$(uname -r)/include/linux/
>     $ echo "#error this header is malicious" > /tmp/kheaders-$(uname
> -r)/include/linux/kconfig.h
> 
> Then run this as root:
> 
>     # opensnoop-bpfcc
>     In file included from :1:
>     ././include/linux/kconfig.h:1:2: error: this header is malicious
>     #error this header is malicious
>  ^
>     In file included from :2:
>     /virtual/include/bcc/bpf.h:12:10: fatal error: 'linux/types.h'
> file not found
>     #include 
>  ^~~
>     2 errors generated.
>     Traceback (most recent call last):
>   File "/usr/sbin/opensnoop-bpfcc", line 261, in 
>     b = BPF(text='')
>     
>   File "/usr/lib/python3/dist-packages/bcc/__init__.py", line
> 476, in __init__
>     raise Exception("Failed to compile BPF module %s" % (src_file
> or ""))
>     Exception: Failed to compile BPF module 
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>    APT prefers unstable
>    APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.0-1-amd64 (SMP w/1 CPU thread; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via 

Bug#1029281: [Pkg-openssl-devel] Bug#1029281: openssl: loongarch64 is little endian

[Han Gao]

In [1], section 2.1.6

LoongArch is always little-endian.

[1]: 
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#endian


On Mon, Jan 23, 2023 at 4:01 AM Sebastian Andrzej Siewior
 wrote:
>
> On 2023-01-21 00:05:53 [+0800], Han Gao wrote:
> >   Loongarch64 is little endian. So [1] should be removed.
>
> Are you sure? I applied exactly what I received in #1024414. Please test
> the patches that you send.
>
> > [1]: 
> > https://salsa.debian.org/debian/openssl/-/blob/debian/openssl-3.0.7-2/debian/patches/debian-targets.patch#L65
>
> This is hppa and makes no sense. As a challange, please send a patch.
>
> Sebastian


remove-loong64-big-endian.patch
Description: Binary data

Bug#1029500: ITP: python3-fitipy -- automatic synchronization of a Python data type with a file

[Scarlett Moore]

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

* Package name: python3-fitipy
  Version : 1.0.0
  Upstream Author : Matthew Scholefield 
* URL : https://github.com/MatthewScholefield/fitipy
* License : Apache 2.0
  Programming Lang: Python
  Description : automatic synchronization of a Python data type with a file

This small python module used for automatic synchronization of a Python data 
type with a file. 
Typically, this is useful in places where a small amount of data is stored.

This is a dependency of mycroft-precise.
This will be maintained by the Mycroft team.

Bug#1014456: unbound: Please enable cachedb and redis support

[Shaft]

Hi, 

> What does cachedb/redis bring us, how these can be used?

Unbound documentation is always a good read :)


It states [1]:

"If this module is enabled and configured, the specified backend database works 
as a second level cache; when Unbound cannot find an answer to a query in its 
built-in in-memory cache, it consults the specified backend. If it finds a 
valid answer in the backend, Unbound uses it to respond to the query without 
performing iterative DNS resolution. If Unbound cannot even find an answer in 
the backend, it resolves the query as usual, and stores the answer in the 
backend."

It's also used when Unbound is also configured to serve stale answers (RFC 8767)

> Should apparmor profile be updated for it to work?

Unbound can use 2 backends: the default is a in-memory backend (named 
'testframe' so not really useful) and redis. Unbound connects to redis using 
TCP. No needs to be able to access redis' pidfile. Therefore my guess is that 
the currect apparmor profile should work. Of course, it needs to be tested.

Regards,
Shaft

[1]: 
https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#cache-db-module-options

Bug#1029501: ITP: libtest-mockfile-perl -- Perl module that allows tests to validate code, without requiring a file system.

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest-mockfile-perl
  Version : 0.034
  Upstream Author : Todd Rinaldo 
* URL : https://metacpan.org/release/Test-MockFile
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module that allows tests to validate code, without 
requiring a file system.

Test::MockFile intercepts file system calls for specific files so unit testing
can take place without any files being altered on disk. This is useful for
small tests where file interaction is discouraged.

A strict mode is even provided (and turned on by default) which can throw a
die when files are accessed during your tests!

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[Roland Rosenfeld]

Hi fabian!

On Mon, 23 Jan 2023, fab...@greffrath.com wrote:

> I'd still agree, though, to replace the compatiblity symlinks with
> patched and fixed variants.

Okay, I created another test branch:
https://salsa.debian.org/roland/fonts-urw-base35/-/tree/fixedpfb
that keeps the unchanged .t1 fonts in usr/share/fonts/type1/urw-base35
and places files with added section headers to
/usr/share/fonts/X11/Type1 (instead of the former symlinks).

This still doesn't solve the lintian error complaining about
license-problem-font-adobe-copyrighted-fragment-no-credit in the .pfb
files, because "startlock get exec" can be found in the t1disasm
output.

Greetings
Roland

Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

[Cyril Brulebois]

Hi lintian maintainers,

Cyril Brulebois  (2022-04-13):
> Sean Whitton  (2021-08-12):
> > On Tue 27 Jul 2021 at 04:08AM +02, Cyril Brulebois wrote:
> > 
> > > Whatever happens on the debian-policy front (if anything), I'd prefer if
> > > lintian would stop emitting those errors on its own. It doesn't have to
> > > follow the letter of Policy, does it?
> > 
> > No, it doesn't.  While the Lintian maintainers could decide to change
> > that, it's not been how the project has viewed Lintian in the past.
> 
> Thanks Sean for the confirmation.
> 
> Lintian maintainers, can we please drop this? It's annoying and
> distracting to see those errors/warnings all the time when working on
> the installer.

Can we please finally drop those checks? You'll find above the green
light from Sean regarding lintian's possibly moving ahead of changes in
Policy; since December, 5.6.11 even ends with:

udebs and source packages that only produce udebs do not use
Standards-Version.

lintian's insistance on this topic led to wrong changes getting
committed to dozens of repositories… :(


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


signature.asc
Description: PGP signature

Bug#1028208: plasma-discover: Program terminated with signal SIGSEGV

[Bernhard Übelacker]

(gdb) bt
#0  0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x7fbffe79dbe1 in KCrash::defaultCrashHandler(int) () from 
/lib/x86_64-linux-gnu/libKF5Crash.so.5
#3  
#4  0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#5  0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#6  
#7  0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#9  0x7fbffad3c3b0 in g_closure_invoke () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x7fbffad4f1a5 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0



Hello Piotr,
this raise might indicate that libgobject wanted
to stop the process for some reason.
This reason it might have written to stdout/stderr.

Therefore probably you can still retrieve this logging.
From the "Sun 2023-01-08 13:36:08 GMT" I assume it happend at 14:36
your local time? Then following might possibly show related output.
If there is some could you provide the related parts?

journalctl --user --since="2023-01-08 14:34" --until="2023-01-08 14:38"

Unfortunately there might also be some programs writing to ~/.xsession-errors,
there the lines are not prefixed with the date and time ...
So it might be difficult to find them there.

Was this just a "one-time" crash, or do you get that regularly?

Kind regards,
Bernhard

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[fabian]

Hi Roland,

Am 23.01.2023 14:18, schrieb Roland Rosenfeld:

Okay, I created another test branch:


that'd be fine with me, thanks!

Would it make sense to disassemble and reassemble the newly created 
files as some sort of additional smoke test?


Cheers,
 - Fabian

Bug#1029473: gnome-session: Automatic Suspend should not be enabled by default

[vmxevilstar]

Hello,

Humbly I would suggest to install the "espresso" extension 
https://extensions.gnome.org/extension/4135/espresso/


On Mon, 2023-01-23 at 10:24 +, Simon McVittie wrote:
> Control: retitle -1 gnome-settings-daemon: automatic suspend after 20
> minutes is undesired by some users
> Control: reassign -1 gnome-settings-daemon
> Control: affects -1 + gnome-session
> Control: tags -1 + upstream wontfix
> 
> On Mon, 23 Jan 2023 at 01:19:44 +, Witold Baryluk wrote:
> > It appears in Power settings, Automatic Suspend is On by default
> > (with 20
> > minutes delay).
> 
> This is intentional and has been true for about 5 years (in
> particular,
> this was already the case in Debian 11, and most likely Debian 10 as
> well).
> The automatic suspend became the default in upstream commit
> <
> https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/2fdb48fa
> >
> which mentions that this behaviour is required by national
> regulations
> for personal computers sold in the EU and USA (with no distinction
> made
> between laptop and desktop systems).
> 
> Obviously Debian doesn't sell computers with Debian and GNOME
> preinstalled, but it would seem inconsistent with our
> social/environmental
> responsibilities if we disabled a power-saving feature like this by
> default, particularly when that would make it illegal for third
> parties
> to sell computers with our OS preinstalled in the countries where a
> lot
> of our contributors are based, and doubly so during an ongoing
> worldwide
> climate crisis and a Europe-wide energy shortage.
> 
> > I am on a desktop PC, always on, and have programs in a background
> > that
> > must run non stop or for many hours (i.e. data acquisition /
> > monitoring,
> > long running scripts, simulations, etc).
> 
> I would suggest using the system's built-in facilities to delay
> suspend
> while running these tasks. If you wrap a long-running command like
> this:
> 
>     systemd-inhibit ./my-long-running-script
> 
> then that should prevent the system from suspending to RAM during
> these
> long-running tasks. This is available in a default installation or on
> live media (because it's part of our default init system).
> 
> > I also do not understand why Screen Blank in Power Saving Options
> > is
> > "Never". A default should be few minutes.
> 
> Blanking the screen is redundant with the default suspend-to-RAM: the
> screen is always blanked and locked before suspending anyway. Of
> course,
> if you adjust the settings to disable suspend-to-RAM, then it will be
> necessary to change adjacent settings to match.
> 
> > suspend to RAM is often broken on computers I use
> 
> There is probably a kernel command-line option that can be used to
> disable the ability to suspend-to-RAM, as a workaround for hardware
> where
> the ability to suspend is present but non-functional, but I don't
> know it.
> 
>     smcv
> 

Bug#967970: activedefrag

[Jamie Murphy]

I have also been bitten by this.

Since activedefrag cannot currently be enabled in the debain build, redis
will eventually consume all system memory (or reach its configured
maxmemory) and eventually crash.

activedefrag allows redis to cleanup its memory usage, without
activedefrag it will eventually just crash or cause an OOM event if the
internal maxmemory var config isnt set.

redis activedefrag notes:
https://cloud.google.com/memorystore/docs/redis/memory-management-best-practices#active_defragmentation

The issue mainly appears when redis keys are being refreshed often with
small quantities of data, for example counters being refreshed every few ms
within a month we have seen redis memory usage bloom to 15gb for a dataset
that when exported or saved is only a few hundred mb, the fragmentation is
quite large and is not being cleaned up.

Jamie

Bug#1029234: lyx: Graphic problems editing a lyx file

[Stefano Simonucci]

With the driver nouveau instead of nvidia lyx is working also in the 
mate (or gnome) environment.


Stefano

On 22/01/23 20:04, Dr. Tobias Quathamer wrote:

control: tag -1 unreproducible
control: severity -1 important

Am 20.01.23 um 15:21 schrieb Stefano Simonucci:

I get the following messages:

sudo apt build-dep lyx
[sudo] password di stefano:
Lettura elenco dei pacchetti... Fatto
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze... Fatto
Lettura informazioni sullo stato... Fatto
Alcuni pacchetti non possono essere installati. Questo può voler dire
che è stata richiesta una situazione impossibile oppure, se si sta
usando una distribuzione in sviluppo, che alcuni pacchetti richiesti
non sono ancora stati creati o sono stati rimossi da Incoming.
Le seguenti informazioni possono aiutare a risolvere la situazione:

I seguenti pacchetti hanno dipendenze non soddisfatte:
  libboost-iostreams1.74-dev : Dipende: libboost1.74-dev (= 1.74.0-9) 
ma la versione 1.74.0-18.1 sta per essere installata
   Dipende: libboost-regex1.74-dev (= 
1.74.0-9) ma la versione 1.74.0-18.1 sta per essere installata
   Dipende: libboost-iostreams1.74.0 (= 
1.74.0-9) ma la versione 1.74.0-18.1 sta per essere installata
  libenchant-2-dev : Dipende: libenchant-2-2 (= 2.2.15-1) ma la 
versione 2.3.3-2 sta per essere installata

 Dipende: libglib2.0-dev ma non è installabile
  libmagic-dev : Dipende: libmagic1 (= 1:5.39-3) ma la versione 
1:5.41-4 sta per essere installata
  libmythes-dev : Dipende: libmythes-1.2-0 (= 2:1.2.4-3+b1) ma la 
versione 2:1.2.5-1 sta per essere installata
E: Impossibile correggere i problemi, ci sono pacchetti danneggiati 
bloccati.



Maybe I must downgrade also these packages!

Stefano


Hi Stefano,

unfortunately, I'm not able to reproduce the error you're seeing. 
Therefore, I'm downgrading the bug's severity to important, to avoid 
LyX being removed from the next Debian stable release.


I suspect that the error you're experiencing comes from another 
package, which has to do with the graphic environment you're using. I 
have no idea, which package that might be, though.


Sorry that I cannot provide any more useful ideas to narrow down this 
bug.


Regards,
Tobias

Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game

[James Addison]

Package: wnpp
Followup-For: Bug #1026277

On Sat, 17 Dec 2022 at 17:31:36 +, James Addison wrote:

> * License : GPLv3

Please note:

During the packaging process I've learned that the licensing terms for games
derived from Doom3 are an extension/modification of GPLv3 that include
additional terms specified by the authors, iD Software.

Those licensing terms are included in the work-in-progress package that is
pending sponsorship[1] and mentoring.

[1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029409

Bug#1029499: php-guzzlehttp-psr7: Build killed with signal TERM after 150 minutes of inactivity

[Santiago Vila]

Package: src:php-guzzlehttp-psr7
Version: 2.4.3-1
Severity: important

Dear maintainer:

During a rebuild of all packages in bookworm, your package "almost" failed to 
build:


[...]
 debian/rules binary-indep
dh binary-indep
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
phpabtpl --basedir src composer.json > debian/autoload.php.tpl
phpab \
--output src/autoload.php \
--template debian/autoload.php.tpl \
src
phpab %development% - Copyright (C) 2009 - 2022 by Arne Blankerts and 
Contributors

Scanning directory src

Autoload file src/autoload.php generated.

mkdir --parents vendor GuzzleHttp
phpabtpl \
--require guzzlehttp/psr7 \
--require http-interop/http-factory-tests \
> debian/autoload.tests.php.tpl
Proceeding without a composer.json file.phpab \
--output vendor/autoload.php \
--template debian/autoload.tests.php.tpl \
tests
phpab %development% - Copyright (C) 2009 - 2022 by Arne Blankerts and 
Contributors

Scanning directory tests

Autoload file vendor/autoload.php generated.

ln -s ../src GuzzleHttp/Psr7
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
php -S 127.0.0.1:10002 tests/Integration/server.php &
TEST_SERVER=127.0.0.1:10002 phpunit -v
[Mon Jan 23 10:13:36 2023] PHP 8.2.1 Development Server 
(http://127.0.0.1:10002) started
PHPUnit 9.5.28 by Sebastian Bergmann and contributors.

Runtime:   PHP 8.2.1
Configuration: /<>/phpunit.xml.dist
Warning:   Your XML configuration validates against a deprecated schema.
Suggestion:Migrate your XML configuration using "--migrate-configuration"!

...S...S...  63 / 993 (  6%)
... 126 / 993 ( 12%)
.S. 189 / 993 ( 19%)
... 252 / 993 ( 25%)
... 315 / 993 ( 31%)
..S 378 / 993 ( 38%)
... 441 / 993 ( 44%)
... 504 / 993 ( 50%)
... 567 / 993 ( 57%)
... 630 / 993 ( 63%)
... 693 / 993 ( 69%)
... 756 / 993 ( 76%)
... 819 / 993 ( 82%)
... 882 / 993 ( 88%)
[Mon Jan 23 
10:13:36 2023] 127.0.0.1:59062 Accepted
[Mon Jan 23 10:13:36 2023] 127.0.0.1:59062 Closing
... 945 / 993 ( 95%)
993 / 993 (100%)

Time: 00:00.158, Memory: 14.00 MB

There were 4 skipped tests:

1) 
GuzzleHttp\Tests\Psr7\AppendStreamTest::testCatchesExceptionsWhenCastingToString
PHP < 7.4 is required.

/<>/tests/AppendStreamTest.php:180
/<>/tests/AppendStreamTest.php:180

2) 
GuzzleHttp\Tests\Psr7\FnStreamTest::testThatConvertingStreamToStringWillTriggerErrorAndWillReturnEmptyString
PHP < 7.4 is required.

/<>/tests/FnStreamTest.php:104
/<>/tests/FnStreamTest.php:104

3) 
GuzzleHttp\Tests\Psr7\PumpStreamTest::testThatConvertingStreamToStringWillTriggerErrorAndWillReturnEmptyString
PHP < 7.4 is required.

/<>/tests/PumpStreamTest.php:83
/<>/tests/PumpStreamTest.php:83

4) 
GuzzleHttp\Tests\Psr7\StreamDecoratorTraitTest::testCatchesExceptionsWhenCastingToString
PHP < 7.4 is required.

/<>/tests/StreamDecoratorTraitTest.php:42
/<>/tests/StreamDecoratorTraitTest.php:42

OK, but incomplete, skipped, or risky tests!
Tests: 993, Assertions: 2206, Skipped: 4.
make[1]: Leaving directory '/<>'
   create-stamp debian/debhelper-build-stamp
   dh_prep -i
   dh_auto_install --destdir=debian/php-guzzlehttp-psr7/ -i
   dh_install -i
   dh_installdocs -i
   dh_installchangelogs -i
   dh_perl -i
   dh_phpcomposer -i
OR-ed versions are not supported require:php (^7.2.5 || ^8.0) in file 
"/<>/composer.json".
OR-ed versions are not supported require-dev:phpunit/phpunit (^8.5.29 || ^9.5.23) in file 
"/<>/composer.json".
Ignoring line, too short: "
" in file "/usr/share/pkg-php-tools/overrides/php-timer".
Override: require:ralouphie/getallheaders (>= 3.0, < 4~~) -> 
require:__override__/php-getallheaders (>= 3.0, < 4~~).
Override: require-dev:phpunit/phpunit -> require-dev:__override__/phpunit.
   dh_link -i
   dh_strip_nondeterminism -i
   dh_compress -i
   

Bug#1028324: RM: cduce -- RoQA, unmaintained, FTBFS, zero popcon

[Stéphane Glondu]

Control: reassign -1 ftp.debian.org

Le 09/01/2023 à 16:37, Tobias Frost a écrit :

This makes me wonder if we should retire this package.


Yes, absolutely.


If you also think that it shoulw be removed, just reassign it to the
ftp.debian.org pseudo package.



Cheers,

--
Stéphane

Bug#1029502: ftp.debian.org: changelog of libreoffice is unavailable

[Vincent Lefevre]

Package: ftp.debian.org
Severity: normal

The changelog of libreoffice is unavailable:

zira% apt changelog libreoffice
Err:1 https://metadata.ftp-master.debian.org libreoffice 2:7.4.4-5 Changelog
  Changelog unavailable for libreoffice=2:7.4.4-5 (404  Not Found [IP: 
151.101.122.132 443])
E: Failed to fetch 
https://metadata.ftp-master.debian.org/changelogs/main/libr/libreoffice/libreoffice_7.4.4-5_changelog
  Changelog unavailable for libreoffice=2:7.4.4-5 (404  Not Found [IP: 
151.101.122.132 443])

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

Bug#1029502: ftp.debian.org: changelog of libreoffice is unavailable

[Vincent Lefevre]

On 2023-01-23 13:50:11 +0100, Vincent Lefevre wrote:
> zira% apt changelog libreoffice
> Err:1 https://metadata.ftp-master.debian.org libreoffice 2:7.4.4-5 Changelog
>   Changelog unavailable for libreoffice=2:7.4.4-5 (404  Not Found [IP: 
> 151.101.122.132 443])
> E: Failed to fetch 
> https://metadata.ftp-master.debian.org/changelogs/main/libr/libreoffice/libreoffice_7.4.4-5_changelog
>   Changelog unavailable for libreoffice=2:7.4.4-5 (404  Not Found [IP: 
> 151.101.122.132 443])

Note: this is after doing an "apt update". So the version is
up-to-date.

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

Bug#1004534: Please promote version 1.38.0-1 to unstable

[Shengjing Zhu]

On Mon, Jan 23, 2023 at 4:12 AM Thomas Uhle  wrote:
>
> Dear maintainers of the Debian Go Packaging Team,
>
> I would like to second Eric's wish to upload the version in experimental
> (or perhaps a newer one) to unstable too, so that it can make its way to
> bookworm before the freeze.  Or is there any reason (that of course I
> don't know) why it has to be a version like 1.33.3 instead?
>

It's too late. By bumping to 1.33.3 already takes a lot of time for me.

Please be aware that a library like grpc-go is very essential in the
Go ecosystem. Updating the version not only means just packaging the
new version. You need to take care of the reverse dependencies.

I'm not holding others to update the version. But no one shows the
plan to ensure a smooth transition.

-- 
Shengjing Zhu

Bug#1022001: libwebp: Please package new upstream release 1.2.4

[Anthony Fok]

On Tue, Oct 18, 2022 at 1:15 PM Boyuan Yang  wrote:
> Also, the package libavif I maintain has libsharpyuv as a new build-
> dependency, which is provided by src:libwebp in the new release. Please also
> consider providing the libsharpyuv library. Thanks!

(This has already been communicated to Boyuan, but for the record on
Debian BTS...)

It turns out that libsharpyuv is not yet an installable standalone
library in libwebp v1.2.4.  From the git log for commit
29cc95ce4cfeae88de13f44c43d8e73ffb782f79 leading up to v1.2.3:

It's self contained apart from a dependency on src/webp/types.hand
src/dsp/cpu.h
For now it's only set up as an internal library, not an installable one.
Webp doesn't depend on it yet, the code is only duplicated.

libsharpyuv.so as an installable library appears in libwebp 1.3.0, but
which I'm not packaging for bookmark, just to be safe; maybe we'll get
it to bookmark-backports in the future:

- 12/16/2022: version 1.3.0
  This is a binary compatible release.
  * add libsharpyuv, which exposes -sharp_yuv/config.use_sharp_yuv
functionality to other libraries; libwebp now depends on this library
  * major updates to the container and lossless bitstream docs (#448, #546,
#551)
  * miscellaneous warning, bug & build fixes (#576, #583, #584):

Cheers,

Anthony

Bug#1029505: python3-minimal installs recommend package python3

[Ricardo Fraile]

Package: python3-minimal
Version: 3.11.1-1
Severity: normal
X-Debbugs-Cc: r...@rfmoz.eu

Dear Maintainer,

The execution of apt installs the full python package:

# apt install python3-minimal
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libmpdec3 libpython3.10-minimal libpython3.10-stdlib media-types python3.10 
python3.10-minimal
Suggested packages:
  python3.10-venv python3.10-doc binfmt-support
The following NEW packages will be installed:
  libmpdec3 libpython3.10-minimal libpython3.10-stdlib media-types 
python3-minimal python3.10 python3.10-minimal
0 upgraded, 7 newly installed, 0 to remove and 5 not upgraded.
Need to get 5076 kB of archives.
After this operation, 20.4 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

If you hold it "apt-mark hold python3.10". The python3-minimal is installed as 
usual.

The full python package is a recommended package, not a requirement for 
python3-minimal.


Thanks,


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages python3-minimal depends on:
ii  dpkg1.21.12
ii  python3.11-minimal  3.11.1-2

python3-minimal recommends no packages.

python3-minimal suggests no packages.

-- no debconf information

Bug#1029505: python3-minimal installs recommend package python3

[Ricardo F]

Sorry, the request here is about the review of the change from 
recommended to suggested to avoid the auto install.



Thanks,

Bug#1029505: python3-minimal installs recommend package python3

[Ricardo F]

Sorry, the request here is about the review of the change from 
recommended to suggested to avoid the auto install.


Thanks,

Bug#1029509: yq: /usr/bin/xq is already shipped by the xq package

[Andreas Beckmann]

Package: yq
Version: 3.1.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Selecting previously unselected package yq.
  Preparing to unpack .../13-yq_3.1.0-1_all.deb ...
  Unpacking yq (3.1.0-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-SyyrYV/13-yq_3.1.0-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/xq', which is also in package xq 1.0.0-2+b1
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-SyyrYV/13-yq_3.1.0-1_all.deb


cheers,

Andreas


xq=1.0.0-2+b1_yq=3.1.0-1.log.gz
Description: application/gzip

Bug#1029502: ftp.debian.org: changelog of libreoffice is unavailable

[Vincent Lefevre]

On 2023-01-23 14:01:21 +0100, Vincent Lefevre wrote:
> On 2023-01-23 13:50:11 +0100, Vincent Lefevre wrote:
> > zira% apt changelog libreoffice
> > Err:1 https://metadata.ftp-master.debian.org libreoffice 2:7.4.4-5 Changelog
> >   Changelog unavailable for libreoffice=2:7.4.4-5 (404  Not Found [IP: 
> > 151.101.122.132 443])
> > E: Failed to fetch 
> > https://metadata.ftp-master.debian.org/changelogs/main/libr/libreoffice/libreoffice_7.4.4-5_changelog
> >   Changelog unavailable for libreoffice=2:7.4.4-5 (404  Not Found [IP: 
> > 151.101.122.132 443])
> 
> Note: this is after doing an "apt update". So the version is
> up-to-date.

I can notice that
/var/lib/apt/lists/ftp.debian.org_debian_dists_unstable_main_source_Sources
has an entry

Package: libreoffice
[...]
Version: 4:7.4.4-7

(among other libreoffice ones), while
/var/lib/apt/lists/ftp.debian.org_debian_dists_unstable_main_binary-amd64_Packages
only has

Package: libreoffice
Version: 2:7.4.4-5

Perhaps apt should consider the version of the source package
like what https://packages.debian.org/en/sid/libreoffice seems
to do. At this page:

Package: libreoffice (2:7.4.4-5 and others)

but the "Debian Changelog" link is

https://metadata.ftp-master.debian.org/changelogs//main/libr/libreoffice/libreoffice_7.4.4-7_changelog

which is valid.

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

Bug#1029503: spirv-cross: new upstream release breaks API

[Timo Röhling]

Source: spirv-cross
Version: 2021.01.15+1.3.236.0-1
Severity: serious
Tags: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear co-maintainers,

the recent upload of spirv-cross 2021.01.15+1.3.236.0-1 has incompatible
API changes which break reverse dependencies, notably src:filament.

This type of change is no longer appropriate since the 2023-01-12 transition 
freeze.
Please keep this bug at a RC-critical severity to prevent migration to
testing.


Relevant excerpt from a filament rebuild:

[...]
[ 50%] Built target test_utils
/<>/libs/filamat/src/GLSLPostProcessor.cpp:349:75: error: too few 
arguments to function call, expected 3, have 2
glslCompiler.remap_ext_framebuffer_fetch(i.first, i.second);
  ^
/usr/include/spirv_cross/spirv_glsl.hpp:203:7: note: 
'remap_ext_framebuffer_fetch' declared here
void remap_ext_framebuffer_fetch(uint32_t input_attachment_index, 
uint32_t color_location, bool coherent);
 ^
1 error generated.
make[3]: *** [libs/filamat/CMakeFiles/filamat.dir/build.make:331: 
libs/filamat/CMakeFiles/filamat.dir/src/GLSLPostProcessor.cpp.o] Error 1
[...]


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmPOhI8ACgkQ+C8H+466
LVmO/QwAnyuW2b78PW1dGWP/S0uOn10R4Khg1vtayd6dG+d4DItcDYtiXQcB4p4a
1f9zJwnkB3PT2nvpXT29frqvOO9rz4JQ/fT68bEpjluRL3255MNRTjseTSiZRIFA
rBkmyflC1+5agaJhuQSH4FR7PkuSpnCKA4uTAuvQf4gYQEmeUGb8Exca2YKXVeK1
8iPTIDyvd8LUVJBhnp0O7d8j1XJXibzewuyEzivGoTGbNJ+PVoeBLSxx1BzOKT5C
2QEpy6Ji9tG9UIzm7AjqNdTwnQOejSXKWthQsyFx4QAgoIOv+ppv2PpZiQWSzgFY
CVy8ngQdS2k1uwCokAFperRS9XuoUT0EaR43jALpZ1ryfmSzmZrkGDMyZXaUFV9l
ubYMQpp/JBe9YfMV6M02kV45ihbXqHSUdK9QrwVnWGLZIwnoeLJbs+K0Jm/jpfY+
Qq7pVAtEt2Kr+LU0xkssuskKbyMeFvkLJcAXFJ3vI55/e8XgaiHMUJuwzzbnH9aj
NOfNqANT
=/4Kr
-END PGP SIGNATURE-

Bug#1029495: ITP: libdevel-cover-report-clover-perl -- backend for Clover reporting of coverage statistics

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libdevel-cover-report-clover-perl
  Version : 1.01
  Upstream Author : David Bartle 
* URL : https://metacpan.org/release/Devel-Cover-Report-Clover
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : backend for Clover reporting of coverage statistics

Devel::Cover::Report::Clover generates a Clover compatible coverage xml file
which can be used in a variety of continuous integration software offerings.

It is designed to be called from the 'cover' program distributed with
Devel::Cover.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1029498: gem2deb should simplify the copy and symlink of assets

[Pirate Praveen]

Package: gem2deb
Severity: wishlist

Currently for many ruby packages (rails engines) that ships a 
javascript asset, we have to manually copy the asset before build and 
replace it with a symlink after install. It'd be nice if gem2deb can 
automate these manual steps with a mapping file. This will create a 
much cleaner rules file and avoid repetition.


How about debian/ruby-foo.assets, which will have relative paths for 
source and destination, an example below


jquery-atwho/jquery.atwho.js 
lib/assets/javascripts/jquery.atwho/jquery.atwho.js


Source can be relative to /usr/share/javascript/ or absolute path and 
destination can be relative to package directory.


Currently in rules I have,

execute_before_dh_auto_build:
cp /usr/share/javascript/jquery-atwho/jquery.atwho.js 
$(CURDIR)/lib/assets/javascripts/jquery.atwho/jquery.atwho.js
cp /usr/share/javascript/caret.js/jquery.caret.js 
$(CURDIR)/lib/assets/javascripts/jquery.atwho/jquery.caret.js


execute_after_dh_install:
debian/symlink-js

and
cat debian/symlink-js
#!/bin/sh
version=$(dpkg-parsechangelog -S version |cut -d'+' -f1)
ln -sf /usr/share/javascript/jquery-atwho/jquery.atwho.js 
debian/ruby-jquery-atwho-rails/usr/share/rubygems-integration/all/gems/jquery-atwho-rails-${version}/lib/assets/javascripts/jquery.atwho/jquery.atwho.js
ln -sf /usr/share/javascript/caret.js/jquery.caret.js 
debian/ruby-jquery-atwho-rails/usr/share/rubygems-integration/all/gems/jquery-atwho-rails-${version}/lib/assets/javascripts/jquery.atwho/jquery.caret.js

Bug#987156: Info received (Bug#987156: Acknowledgement (mod_ssl depends on mod_setenvif while it does not))

[MichaIng]

I opened a merge request to solve this: 
https://salsa.debian.org/apache-team/apache2/-/merge_requests/36


Best regards,

Micha

Bug#1028834: Pluma no longer reopens a saved file at last cursor position

[Alf]

After yesterday's big update for Debian-Bookworm automagically this bug 
disappeared.
However said upgrade did not contain anything that refers to pluma - mysterious.

Bug#1029507: linux-image-6.1.0-1-amd64 isn't installable

[Stefano Simonucci]

Package: src:linux
Version: 6.1.4-1
Severity: normal
X-Debbugs-Cc: stefanosimonucci@alice.it

Dear Maintainer,

The package linux-image-6.1.0-1-amd64 with linux-headers-6.1.0-1-amd64 can't be 
configured on my system. I must boot the previous kernel. 

I get:
stefano@debsim:~$ sudo apt install linux-headers-6.1.0-1-amd64 
linux-image-6.1.0-1-amd64  
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze... Fatto
Lettura informazioni sullo stato... Fatto   
Pacchetti suggeriti:
  linux-doc-6.1 debian-kernel-handbook
I seguenti pacchetti NUOVI saranno installati:
  linux-headers-6.1.0-1-amd64 linux-image-6.1.0-1-amd64
0 aggiornati, 2 installati, 0 da rimuovere e 26 non aggiornati.
È necessario scaricare 0 B/76,5 MB di archivi.
Dopo quest'operazione, verranno occupati 509 MB di spazio su disco.
Selezionato il pacchetto linux-headers-6.1.0-1-amd64 non precedentemente selezio
nato.
(Lettura del database... 1189678 file e directory attualmente installati.)
Preparativi per estrarre .../linux-headers-6.1.0-1-amd64_6.1.4-1_amd64.deb...
Estrazione di linux-headers-6.1.0-1-amd64 (6.1.4-1)...
Selezionato il pacchetto linux-image-6.1.0-1-amd64 non precedentemente seleziona
to.
Preparativi per estrarre .../linux-image-6.1.0-1-amd64_6.1.4-1_amd64.deb...
Estrazione di linux-image-6.1.0-1-amd64 (6.1.4-1)...
Configurazione di linux-image-6.1.0-1-amd64 (6.1.4-1)...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.0.0-4-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-6.0.0-4-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.0-1-amd64
I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-1-amd64
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-1-amd64:Sign command: /
usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j8 KERNELRELEASE=6.1.0-1-amd64 all KERNEL_SRC=/lib/modules/6.1.0-1-amd64/b
uild...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.1.0-1-amd64 (x86_64)
Consult /var/lib/dkms/anbox-ashmem/1/build/make.log for more information.
Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j8 KERNELRELEASE=6.1.0-1-amd64 all KERNEL_SRC=/lib/modules/6.1.0-1-amd64/b
uild...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.1.0-1-amd64 (x86_64)
Consult /var/lib/dkms/anbox-binder/1/build/make.log for more information.
Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j8 KERNELRELEASE=6.1.0-1-amd64 all KVERSION=...
Signing module /var/lib/dkms/v4l2loopback_dc/0.0.1/build/v4l2loopback-dc.ko
Cleaning build area...

v4l2loopback-dc.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/6.1.0-1-amd64/updates/dkms/
depmod...
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
dpkg: errore nell'elaborare il pacchetto linux-image-6.1.0-1-amd64 (--configure)
:
 il sottoprocesso installato pacchetto linux-image-6.1.0-1-amd64 script post-ins
tallation ha restituito lo stato di errore 1
Configurazione di linux-headers-6.1.0-1-amd64 (6.1.4-1)...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-1-amd64:Sign command: /
usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j8 KERNELRELEASE=6.1.0-1-amd64 all KERNEL_SRC=/lib/modules/6.1.0-1-amd64/b
uild...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.1.0-1-amd64 (x86_64)
Consult /var/lib/dkms/anbox-ashmem/1/build/make.log for more information.
Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j8 KERNELRELEASE=6.1.0-1-amd64 all KERNEL_SRC=/lib/modules/6.1.0-1-amd64/b
uild...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.1.0-1-amd64 (x86_64)
Consult /var/lib/dkms/anbox-binder/1/build/make.log for more information.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
 failed!
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 11
Failed to process /etc/kernel/header_postinst.d at /var/lib/dpkg/info/linux-head
ers-6.1.0-1-amd64.postinst line 11.
dpkg: errore nell'elaborare il pacchetto linux-headers-6.1.0-1-amd64 

Bug#1029508: pnc: missing Breaks+Replaces: pn

[Andreas Beckmann]

Package: pnc
Version: 0.9.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
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 .../archives/pnc_0.9.4-1_amd64.deb ...
  Unpacking pnc (0.9.4-1) ...
  dpkg: error processing archive /var/cache/apt/archives/pnc_0.9.4-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/gawk/gawkpn.so', which is 
also in package pn 0.9.0-1+b3
  Errors were encountered while processing:
   /var/cache/apt/archives/pnc_0.9.4-1_amd64.deb

Since pnc is taking over pn, the Breaks+Replaces can be unversioned.

Please also file a RM bug for src:pn


cheers,

Andreas


pn=0.9.0-1+b3_pnc=0.9.4-1.log.gz
Description: application/gzip

Bug#1029487: Please respect NAME if DEBFULLNAME not set

[Josh Triplett]

Package: devscripts
Version: 2.22.2
Severity: wishlist
File: /usr/bin/bts
X-Debbugs-Cc: j...@joshtriplett.org

Most tools that check DEBFULLNAME seem to fall back to NAME. bts,
however, looks at DEBFULLNAME and if not set it falls back to the passwd
database via getpwuid.

Please consider including a fallback checking NAME if DEBFULLNAME isn't
set.


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
BTS_SMTP_HELO=joshtriplett.org
BTS_SMTP_HOST=reportbug.debian.org:587
BTS_SUPPRESS_ACKS=yes
DEBUILD_DPKG_BUILDPACKAGE_OPTS="--no-sign"
DEBUILD_PREPEND_PATH=/usr/lib/ccache
DEBUILD_LINTIAN_OPTS='-i -I'

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.18
ii  fakeroot  1.30.1-1.1
ii  file  1:5.44-2
ii  gnupg 2.2.40-1
ii  gpgv  2.2.40-1
ii  libc6 2.36-8
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.67-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-7
ii  python3   3.11.1-1
ii  sensible-utils0.0.17+nmu1
ii  wdiff 1.2.2-4

Versions of packages devscripts recommends:
ii  apt 2.5.5
ii  curl7.87.0-2
ii  dctrl-tools 2.24-3+b1
pn  debian-keyring  
pn  dput | dupload  
ii  equivs  2.3.1
pn  libdistro-info-perl 
ii  libdpkg-perl1.21.18
ii  libencode-locale-perl   1.05-3
pn  libgit-wrapper-perl 
pn  libgitlab-api-v4-perl   
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-2
pn  libstring-shellquote-perl   
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.17-1
pn  licensecheck
ii  lintian 2.116.0
ii  man-db  2.11.2-1
ii  patch   2.7.6-7
pn  pristine-tar
ii  python3-apt 2.5.1
ii  python3-debian  0.1.49
pn  python3-magic   
ii  python3-requests2.28.1+dfsg-1
pn  python3-unidiff 
ii  python3-xdg 0.28-2
ii  strace  5.10-1
ii  unzip   6.0-27
ii  wget1.21.3-1+b2
ii  xz-utils5.4.1-0.0

Versions of packages devscripts suggests:
pn  adequate 
pn  at   
pn  autopkgtest  
pn  bls-standalone   
pn  bsd-mailx | mailx
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.11.4
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  elpa-devscripts  
pn  faketime 
pn  gnuplot  
pn  how-can-i-help   
pn  libauthen-sasl-perl  
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-3
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
pn  libyaml-syck-perl
ii  mmdebstrap   1.3.1-2
pn  mozilla-devscripts   
ii  mutt 2.2.9-1
ii  openssh-client [ssh-client]  1:9.1p1-2
pn  piuparts 
pn  postgresql-client
pn  pristine-lfs 
pn  quilt
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information

Bug#1029489: RM: php8.1 -- ROM; replaced by src:php8.2

[Ondřej Surý]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

now that php8.2 transition is complete, the src:php8.1 can be safely removed.

Thanks,
Ondrej

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmPOSGdfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcLttA/7B9jOmXZDJbrzOUaYJMSWlhhtA/ispGeBKtN4Jfl1Y/lV5zcmPSF1w1kV
5bjCQmyOFl0C4A/0hkAddfMHN3o9i3ArA4fOxZmmnocyT2Etv98bFDohOP89XQUT
DJkmoWAyuK2O/ViQzESPDonoMnId4WrlNM2pNRrYhlVv5Tu1oVtymTh1c+6VudSV
HA5ktM/u9zvZdUvD/nofBOXI9d0RNxANg2mQAuKwS9C6mGdVS9vxmjH46/mGJBVm
/MNcQHfJZ0V6xyXe7DbLQYjSaANMWf1uCfa/BatXBk1I8mzCzTC94ObMouAfnqme
hY1H9T55RABUFENevyqclDUQzKBwwsZSOxALhVqO8iWDPh1a5gabbaspoorKzO5y
fuIjCcVecnE7Dgt+c627OJkO6pHGZotA2spzKEQ3vsNUT6z36vsL9/XzMorDebjD
GFe2QbCzUiaM94Qa8+3vH6iR5t2aBwXohaDNK3ADBhz+Sa1LpMzquMMbnkXcv/zN
oyKRBGMS6sS9i4VxAkll8zNMgxww2r8lDi9477nJU3k/uIvf6Z4apH0vf5gbyZbB
4kuHJUm3zbe1mvqKC2hIHDu5knpVpvkUHIqVpQep8JEH5HeJSfpTkbgpcVgN+OcT
sv3QQtLPxElt5HT0ZZeT+PvrpujVGbZwXQpVMmPGTOD6yCUIzpg=
=MXoO
-END PGP SIGNATURE-

Bug#1021211: remmina: switch to libsoup3

[Andre Heider]

Can we please have spice back?

It's been half a year, and my patch with an alternative solution still 
works fine with 1.4.29 (which is what I'm using for that period on a 
daily basis):


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015147#27

Thanks,
Andre

Bug#1029494: twine man page is broken

[Salvo "LtWorf" Tomaselli]

Package: twine
Version: 4.0.2-1
Severity: normal
X-Debbugs-Cc: tipos...@tiscali.it

Dear Maintainer,

man twine shows the entire changelog, and then the python API.

I'd like the man page in the command section to display the documentation of 
the command.

For programming API documentation there is an appropriate section in the man 
pages.

best

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

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

Versions of packages twine depends on:
ii  libjs-sphinxdoc 5.3.0-3
ii  python3 3.11.1-1
ii  python3-importlib-metadata  4.12.0-1
ii  python3-keyring 23.9.3-2
ii  python3-pkginfo 1.8.2-2
ii  python3-readme-renderer 37.3-2
ii  python3-requests2.28.1+dfsg-1
ii  python3-requests-toolbelt   0.10.1-1
ii  python3-rfc3986 1.5.0-2
ii  python3-rich13.2.0-2
ii  python3-urllib3 1.26.12-1
ii  sphinx-rtd-theme-common 1.2.0~rc1+dfsg-1

twine recommends no packages.

twine suggests no packages.

-- no debconf information

Bug#1029488: ITP: python-collections-extended -- Extra Python Collections - bags, setlists, RangeMap and IndexedDict

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 995352 by -1

* Package name: python-collections-extended
  Version : 2.0.2
  Upstream Author : Michael Lenzen
* URL : https://github.com/mlenzen/collections-extended
* License : Apache-2.0
  Programming Lang: Python
  Description : Extra Python Collections - bags, setlists, RangeMap 
and IndexedDict


collections_extended is a pure Python module with no dependencies providing:

  * a bag class, also known as multiset,
  * a setlist class, which is a unique list or ordered set,
  * a bijection class, RangeMap which is a mapping from ranges to values,
  * a IndexedDict class, which is an ordered mapping whose elements can 
be accessed using index, in addition to key.


 There are also frozen (hashable) varieties of bags and setlists.

collections-extended is a dependency of tahoe-lafs. As of 2.0.2, the 
package is not compatible with Python 3.11 [1] which is a blocker to get 
it into Debian.


Remark: This package is to be maintained with Debian Python Team at

https://salsa.debian.org/python-team/packages/python-collections-extended

[1] https://github.com/mlenzen/collections-extended/issues/198

Bug#1029033: RFS: ruby-mdl/0.12.0-2 -- Markdown lint tool

[Norwid Behrnd]

Sorry, this was a misunderstanding on my side.  In upload #3, with reference
to the documentation, the adjustment of the changelog and provision of the new
tag now are the only two intentional changes to the data.

Bug#1029491: unblock: steam-installer/1:1.0.0.75+ds-4

[Simon McVittie]

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

Please hint src:steam-installer into testing when its age reaches
an appropriate point, despite britney thinking it is uninstallable.
This replaces all binary packages of src:steam (which I suppose is
technically a tiny transition, but it's self-contained and is effectively
a continuation of src:steam). src:steam has now been removed from testing
as a result of its disappearance from unstable.

[ Reason ]
The proprietary parts of Steam require both amd64 and i386 libraries,
most notably glibc and Mesa, and will not work correctly on either a
pure amd64 system or a pure i386 system. The older steam:i386 package
was i386-only, resulting in a long-standing bug that it was installable
on a pure i386 system but wouldn't actually work correctly (#992533) and
also not pulling in its correct dependencies on amd64 systems (although
in practice amd64 desktops would typically have most of them anyway).

steam-installer:amd64 correctly has both amd64 and i386 dependencies,
using the standard workaround of going via a Multi-Arch: foreign package
that is only built on i386 (the same technique as nvidia-graphics-drivers
and older versions of nss-mdns). However, britney evaluates installability
by looking at each architecture in isolation, and therefore thinks that
the steam:i386 and steam-installer:amd64 packages are uninstallable.

The old steam:i386 is also not visible in Appstream-based UIs like GNOME
Software and KDE Discover, and fixing that required a trip through NEW
for multiarch reasons. I took the opportunity to make it a pure installer
package in contrib (which downloads the proprietary launcher on-demand,
with strong validation against a hard-coded sha256), instead of directly
shipping a proprietary binary and being in non-free as a result.

[ Impact ]
If steam-installer is not allowed to migrate to testing, users of Debian 12
who want to install Steam will have to install it via Flatpak (which is
unsupported by Valve and has technical limitations due to its sandboxing)
or from Valve's third-party apt repository (which requires trusting
Valve-supplied code to be run as root, and for historical reasons uses
Recommends for some dependencies that should really be Depends).

[ Tests ]
Installed successfully on a bookworm VM system as a new installation,
and on unstable + real hardware as an upgrade.

[ Risks ]
This is low-risk: it's a leaf package containing very little code (the
actual proprietary Steam client has always been external to Debian and
self-updating, both src:steam-installer and the old src:steam are just
installers/launchers).

I am likely to continue to monitor Steam closely during the lifetime of
Debian 12 as a result of some consultancy work (and also wanting to play
games on a Debian system!) so I will be on the lookout for regressions.

Thanks,
smcv

Bug#1028638: Gajim crashes. Upstream denies responsability and bans users.

[bert]

Niccolo,

I usually don't engage with stuff like this, but your behaviour is what 
makes open source development harder and often not fun.


I hope you know that all posts in the Gajim MUC are public:
https://conference.gajim.org:5281/muc_log/gajim/2023-01-19

You barged in there requesting help because you're "loosing money", and 
Gajim devs + other people immediately tried to help you.
They very clearly explained that this is a libproxy bug and told you 
that downgrading libproxy works as a temporary workaround, which you 
don't want to do because of "dependency issues", which is your choice.
The devs and maintainers in the MUC then very clearly explained to you 
why the Gajim devs can't do anything about this problem.
You then continue to mix up "upstream", "Debian developers" and "Gajim 
developers" and finally (because you have nothing more to add and out 
of frustration) you start lamenting about Gajim being a resource hog 
because it's written in Python.


They (understandably imho) ban you from their MUC and you end up here 
writing things like


> That's speak volumes about the Gajim team. They not only suppress 
freedom
> of choice but thay are also recurring to low level methods in order 
to hide
> Gajim issues and bugs. I felt compelled to report this incident 
downstream.


which is absolutely ridiculous and unjustified.

Also:
> I'm running Debian testing.

Well, yeah.

Bug#1028083: plasma-discover: Discover tray app crashes kded5, causing other system tray icons to vanish

[Bernhard Übelacker]

Am 22.01.23 um 14:19 schrieb Gregor Riepl:
FYI: My kded core dumps also contained something about a closed DBus 
connection in a different thread's stack trace. Perhaps this is related?


I am not able to exclude it to be related, maybe it is the start of the 
row of events. When debugging through it I got the impression that this 
Transaction object with RoleUnknown gets "marked for deletion" kind of 
unconditionally. But I am not much experienced with this source code.


Kind regards,
Bernhard

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[fabian]

Am 22.01.2023 14:43, schrieb Roland Rosenfeld:

So the current .t1 fonts are not really conservative...


No, they are not really conservative, but they are exactly what was 
given by us from Artifex to use with Ghostscript. And I wouldn't want to 
put this tight relation between ghostscript and the fonts at risk in the 
course of fixing the fonts for less related software.


I'd still agree, though, to replace the compatiblity symlinks with 
patched and fixed variants.


 - Fabian

Bug#1012615: Please provide PHP 8.1 as a backport

[Ondřej Surý]

Package: php8.1
Version: 8.1.14-2+0~20230113.32+debian11~1.gbp6a972c
Followup-For: Bug #1012615

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

FTR I do not plan to provide the backports of neither PHP 8.1 nor PHP 8.2 to any
Debian release.  There's already a comprehensive backport outside of Debian, and
I would not object anybody just pulling that into Debian Backports, but I do not
have time and energy to maintain yet another place where you can get the 
different
version of PHP.

Cheers,
Ondrej

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmPOSt9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcLtpw/+NzJgzvHpnQxqVVu1v66sBgFM6XHD/7s4tGOBoxBfdg3mSb2enhjB8WS2
TVqdHD14DlblKIC5w9xdijKtRoXVshMoukR38Fnmoen+w2WSntSaLfwtcSVF/u58
mCCrgWAyscti8PPyV+WCsFO/+hLhA5NKHWcmeWDmvNqw2cHdc3kBgvLqYnx0L24G
Kq4gBmM1VSDB9RLraX0JzJP+6PhIS9u3E9/+VeqpfMcHNgdboHNniakjyx6AIT+Z
hk5In96sySq1AxEo1hxArFhZioMMyLhLbzY0g1GgRLIDMvAO4m3VN+jsVJa/ls6Q
ghuQ4u/D2hO4f+tjzQ7JES7O1qlcbANFPSkTkydACxx/Cq5syat0qb39HpPXySLN
zktVibWn3Vgo82G2FHkNrg7OB447v0ppVklf+0Pe3LQzRMBuj12V5njewSRAtWps
PbZWtRmMQ91XYlFMLjqL624XK+LUcdkAChXKQY3KemjOM2QJEWTugbtCzvvCNsc6
b9oytTAcymxtmPUGxfEZPtvWcQdt7763agNAb3hnw8q2z2/8GB1xdUyH/Zt20hdx
B/DTKrng6a66Ux+NA4IfC5wJSZnr4JcMgi+1B7lkoo9yP40i388pIFtsw20lUw5J
fk43LFH77AsYN8aV9pTXV43teIJY6cM1xN1NU6t4e0rGlq2pciU=
=4LkZ
-END PGP SIGNATURE-

Bug#1029310: [Help] Re: Bug#1029310: src:r-cran-bayesplot: fails to migrate to testing for too long: autopkgtest regression

[Nilesh Patra]

On 23 January 2023 3:06:58 pm IST, Andreas Tille  wrote:
>Am Sat, Jan 21, 2023 at 10:17:06PM +0530 schrieb Nilesh Patra:
>> On 1/21/23 21:59, Andreas Tille wrote:
>> > Am Sat, Jan 21, 2023 at 09:46:07PM +0530 schrieb Nilesh Patra:
>> > > On 1/21/23 16:56, Andreas Tille wrote:
>> > > > as per DebCI there are 15 autopkgtest failures which seem to be
>> > > > connected to ggplot2 API somehow.[1]  Interestingly Salsa CI[2] does 
>> > > > not
>> > > > show this autopkgtest error neither can I reproduce the problem on my 
>> > > > local
>> > > > pbuilder.
>> > > > 
>> > > > Has anyone some idea what might be wrong?  If not I might ask bug 
>> > > > reporter
>> > > > for more info.
>> > > 
>> > > I can't repro it either.
>> > 
>> > Relieving to know that I did not missed any basic thing here. ;-)
>> > 
>> > > But the log you point to is a fresh failure (today).
>> > > Did not dig deeper, but did you take a look at the `diff` between log 
>> > > that passes and the one
>> > > which does not?
>> > 
>> > Not yet.  Where can I find those old logs?
>> 
>> You can take a diff betweek ci log you pointed to and the log on salsa 
>> CI/local system.
>> The debci runs with package versions in testing, so there might be a bump in 
>> some dependency.
>
>I did a diff between the r-cran-* packages in the failing log and the
>successful log: 
> [...]
>
>to me those diffs are locking not really spectacular regarding to
>the actual issue.

Right.

>I admit I'm running out of ideas but for the moment my last resort
>is to skip the 8 affected test, let the packages migrate to testing
>and revert skipping the tests afterwards.

I did find an issue[3] which states ggplot2 breaks bayesplot 1.9.0 and spews 
the exact same errors we observe in debci.
There's also an upstream issue with bayesplot installation (similar stuff 
again) where it works for some people but not for others, see[4].
But then I'm not sure as to why it works for me, you and salsa CI. For now I'll 
have to dismiss it by calling it black magic.

Your approach sounds fair. Maybe you should do what you wrote (disable tests, 
let it migrate, enable tests again)

>[1] https://ci.debian.net/packages/r/r-cran-bayesplot/testing/amd64/
>[2] 
>https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-bayesplot/28139180/log.gz
[3]: https://github.com/tidyverse/ggplot2/blob/main/revdep/problems.md#bayesplot
[4]: 
https://github.com/stan-dev/bayesplot/issues/297
--
Best,
Nilesh

Bug#1029473: gnome-session: Automatic Suspend should not be enabled by default

[Simon McVittie]

Control: retitle -1 gnome-settings-daemon: automatic suspend after 20 minutes 
is undesired by some users
Control: reassign -1 gnome-settings-daemon
Control: affects -1 + gnome-session
Control: tags -1 + upstream wontfix

On Mon, 23 Jan 2023 at 01:19:44 +, Witold Baryluk wrote:
> It appears in Power settings, Automatic Suspend is On by default (with 20
> minutes delay).

This is intentional and has been true for about 5 years (in particular,
this was already the case in Debian 11, and most likely Debian 10 as well).
The automatic suspend became the default in upstream commit

which mentions that this behaviour is required by national regulations
for personal computers sold in the EU and USA (with no distinction made
between laptop and desktop systems).

Obviously Debian doesn't sell computers with Debian and GNOME
preinstalled, but it would seem inconsistent with our social/environmental
responsibilities if we disabled a power-saving feature like this by
default, particularly when that would make it illegal for third parties
to sell computers with our OS preinstalled in the countries where a lot
of our contributors are based, and doubly so during an ongoing worldwide
climate crisis and a Europe-wide energy shortage.

> I am on a desktop PC, always on, and have programs in a background that
> must run non stop or for many hours (i.e. data acquisition / monitoring,
> long running scripts, simulations, etc).

I would suggest using the system's built-in facilities to delay suspend
while running these tasks. If you wrap a long-running command like this:

systemd-inhibit ./my-long-running-script

then that should prevent the system from suspending to RAM during these
long-running tasks. This is available in a default installation or on
live media (because it's part of our default init system).

> I also do not understand why Screen Blank in Power Saving Options is
> "Never". A default should be few minutes.

Blanking the screen is redundant with the default suspend-to-RAM: the
screen is always blanked and locked before suspending anyway. Of course,
if you adjust the settings to disable suspend-to-RAM, then it will be
necessary to change adjacent settings to match.

> suspend to RAM is often broken on computers I use

There is probably a kernel command-line option that can be used to
disable the ability to suspend-to-RAM, as a workaround for hardware where
the ability to suspend is present but non-functional, but I don't know it.

smcv

Bug#967941: Bug appeared again

[Bernhard Übelacker]

On Sat, 14 Jan 2023 18:07:08 + Stephan =?ISO-8859-1?Q?Verb=FCcheln?= 
 wrote:

This bug appears back some time ago. For some months, video thumbnails
failed to generate on multiple of my machines. Since then, I was trying
to figure out the cause.

It only seemed to affect h264, but not all videos were affected. I even
had multiple videos saved from Youtube, some were generating
thumbnails, others were not. I could not find any difference in the
codec parameters.

Adding the -l option in /usr/share/thumbnailers/totem.thumbnailer
worked to prevent this bug. Does this option have any downsides?

Regards



Hello,
it looks like this option makes it not setting the process limits [1] [2].

Simon wrote it that way before:
  totem-video-thumbnailer sets a resource limit ... to avoid a runaway
  thumbnailing process consuming disproportionate system resources.

Kind regards,
Bernhard

[1] 
https://sources.debian.org/src/totem/43.0-2/src/totem-video-thumbnailer.c/#L587
587 { "no-limit", 'l', G_OPTION_FLAG_REVERSE, G_OPTION_ARG_NONE, _limit, 
"Don't limit the thumbnailing time to 30 seconds", NULL },

[2] 
https://sources.debian.org/src/totem/43.0-2/src/totem-resources.c/?hl=111#L111

Bug#1029486: adduser: french translation of adduser messages

[Guillonneau Jean-Paul]

Package: adduser
Version: 3.130
Severity: wishlist

Dear Maintainer,

Please find attached the french update of the translation of the messages of
adduser, proofread by the debian-l10n-french mailing list contributors
(adduser/po/fr.po).

Regards.


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

Kernel: Linux 6.1.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_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

Versions of packages adduser depends on:
ii  passwd  1:4.13+dfsg1-1

adduser recommends no packages.

Versions of packages adduser suggests:
ii  cron3.0pl1-156
ii  liblocale-gettext-perl  1.07-5
ii  perl5.36.0-7
pn  quota   

-- debconf information:
  adduser/homedir-permission: true
  adduser/title:
# adduser's manpages translation to French
# Copyright (C) 2004 Software in the Public Interest
# This file is distributed under the same license as the adduser package
#
# Translators:
# Jean-Baka Domelevo Entfellner , 2009, 2010.
# Jean-Paul Guillonneau , 2023
msgid ""
msgstr ""
"Project-Id-Version: adduser 3.112+nmu2\n"
"Report-Msgid-Bugs-To: addu...@packages.debian.org\n"
"POT-Creation-Date: 2022-12-28 08:34+0100\n"
"PO-Revision-Date: 2023-01-23 09:10+0100\n"
"Last-Translator: Jean-Paul Guillonneau \n"
"Language-Team: Debian French Team \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Poedit-Country: FRANCE\n"

# type: Plain text
#. everyone can issue "--help" and "--version", but only root can go on
#: ../adduser:161
msgid "Only root may add a user or group to the system.\n"
msgstr ""
"Seul le superutilisateur est autorisé à ajouter un utilisateur ou un groupe "
"au système.\n"

#: ../adduser:191 ../deluser:145
msgid "Only one or two names allowed.\n"
msgstr "Un ou deux noms maximum.\n"

#: ../adduser:197
msgid "Specify only one name in this mode.\n"
msgstr "Ne fournir qu'un nom dans ce mode.\n"

#: ../adduser:200
msgid "addgroup with two arguments is an unspecified operation.\n"
msgstr "addgroup avec deux arguments est une opération non prévue.\n"

#: ../adduser:224
msgid "The --group, --ingroup, and --gid options are mutually exclusive.\n"
msgstr "Les options --group, --ingroup et --gid s'excluent mutuellement.\n"

#: ../adduser:229
msgid "The home dir must be an absolute path.\n"
msgstr "Le répertoire personnel doit être un chemin absolu.\n"

#: ../adduser:233
#, perl-format
msgid "Warning: The home dir %s you specified already exists.\n"
msgstr ""
"Attention ! Le répertoire personnel que vous avez indiqué (%s) existe déjà.\n"

#: ../adduser:235
#, perl-format
msgid "Warning: The home dir %s you specified can't be accessed: %s\n"
msgstr ""
"Attention ! Impossible d'accéder au répertoire personnel que vous avez "
"indiqué (%s) : %s.\n"

#: ../adduser:305
#, perl-format
msgid "The group `%s' already exists as a system group. Exiting.\n"
msgstr "Le groupe « %s » existe déjà en tant que groupe système. Abandon.\n"

#: ../adduser:310
#, perl-format
msgid "The group `%s' already exists and is not a system group. Exiting.\n"
msgstr "Le groupe « %s » existe déjà, sans être un groupe système. Abandon.\n"

#: ../adduser:315
#, perl-format
msgid "The group `%s' already exists, but has a different GID. Exiting.\n"
msgstr ""
"Le groupe « %s » existe déjà, mais avec un identifiant différent. Abandon.\n"

#: ../adduser:320 ../adduser:354
#, perl-format
msgid "The GID `%s' is already in use.\n"
msgstr "Le GID « %s » est déjà utilisé.\n"

#: ../adduser:330
#, perl-format
msgid ""
"No GID is available in the range %d-%d (FIRST_SYS_GID - LAST_SYS_GID).\n"
msgstr ""
"Aucun GID n'est disponible dans la plage %d‑%d "
"(FIRST_SYS_GID‑LAST_SYS_GID).\n"

#: ../adduser:331 ../adduser:372
#, perl-format
msgid "The group `%s' was not created.\n"
msgstr "Le groupe « %s » n'a pas été créé.\n"

#: ../adduser:336 ../adduser:376
#, perl-format
msgid "Adding group `%s' (GID %d) ...\n"
msgstr "Ajout du groupe « %s » (GID %d)...\n"

#: ../adduser:340 ../adduser:380 ../adduser:404 ../deluser:366 ../deluser:400
#: ../deluser:440
msgid "Done.\n"
msgstr "Fait.\n"

# type: Plain text
#: ../adduser:351 ../adduser:991
#, perl-format
msgid "The group `%s' already exists.\n"
msgstr "Le groupe « %s » existe déjà.\n"

#: ../adduser:371
#, perl-format
msgid "No GID is available in the range %d-%d (FIRST_GID - LAST_GID).\n"
msgstr "Aucun GID n'est disponible dans la plage %d‑%d (FIRST_GID‑LAST_GID).\n"

#: ../adduser:390 ../deluser:235 ../deluser:408
#, perl-format
msgid "The user `%s' does not exist.\n"
msgstr "L'utilisateur « %s » n'existe pas.\n"

# type: Plain text
#: ../adduser:391 ../adduser:784 ../adduser:997 ../deluser:373 

Bug#1023752: visidata: New upstream version: v2.10.2 (Oct 8, 2022)

[Martin]

On 2023-01-22 22:12, Anja wrote:
> Oh! Ty! What's your personal deadline so you have time to review?

Let's calculate: Freeze date, 2023-02-12, minus five days for testing
migration, 2023-02-07, minus one weekend: 2023-02-03 more or less.

> I will talk with the author, Saul. Nothing is coming up that is a dealbreaker 
> for 2.11, so as far as I understand it that is the one we are going to go 
> with. Either
> that or 2.10.2. 

I suggest to go for 2.10.2 right now, and if we still can get 2.11
into the release afterwards, the better!

Cheers

Bug#1029492: tzdata: [INTL:tr] turkish debconf translation update

[Atila KOÇ]

Package: tzdata
Severity: wishlist
Tags: l10n patch

Hello,

Attached is the updated Turkish translation of the tzdata debconf template.
It has been submitted for review to the debian-l10n-turkish mailing list.
Please include it in your next upload.

Regards,
Atila KOÇ

--- YASAL UYARI ---
Bu iletinin gövdesi ve ekleri gizli bilgi içerebilir. Bu ileti yalnızca 
gönderilen kişilere özeldir. Eğer size yanlışlıkla ulaşmışsa, lütfen hemen 
siliniz ve göndereni bilgilendiriniz. Bu iletideki içerik gönderene ait olup 
Artı Endüstriyel Elektronik A.Ş. resmi görüşü olmak zorunda değildir. Bu 
iletinin gönderilmeden önce virüs ve diğer zararlı bileşenlere karşı 
denetimleri yapılmıştır. Buna karşın, e-posta iletiminin güvenli ve hatasız 
olduğu garanti edilemediğinden, iletiniz size ulaşana kadar değişmiş ve 
bozulmuş olabilir. Bu ileti nedeni ile göreceğiniz zararlardan Artı Endüstriyel 
Elektronik A.Ş. sorumlu tutulamaz.

# Turkish translation of tzdata.
# This file is distributed under the same license as the tzdata package.
# Mert Dirik , 2008.
# Hace Ibrahim OZBAL , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: tzdata\n"
"Report-Msgid-Bugs-To: tzd...@packages.debian.org\n"
"POT-Creation-Date: 2023-01-02 11:15+0100\n"
"PO-Revision-Date: 2023-01-04 09:56+0300\n"
"Last-Translator: Atila KOÇ \n"
"Language: tr\n"
"Language-Team: Debian L10n Turkish \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Africa"
msgstr "Afrika"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "America"
msgstr "Amerika"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Antarctica"
msgstr "Antarktika"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Australia"
msgstr "Avustralya"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Arctic"
msgstr "Kuzey Kutbu"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Asia"
msgstr "Asya"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Atlantic"
msgstr "Atlantik"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Europe"
msgstr "Avrupa"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Indian"
msgstr "Hindistan"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:1001 ../tzdata.templates:12001
msgid "Pacific"
msgstr "Pasifik"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "US"
msgstr "ABD"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#: ../tzdata.templates:1001
msgid "Etc"
msgstr "Diğer"

#. Type: select
#. Description
#: ../tzdata.templates:1002
msgid "Geographic area:"
msgstr "Coğrafi bölge:"

#. Type: select
#. Description
#: ../tzdata.templates:1002
msgid ""
"Please select the geographic area in which you live. Subsequent "
"configuration questions will narrow this down by presenting a list of "
"cities, representing the time zones in which they are located."
msgstr ""
"Yaşadığınız coğrafi bölgeyi seçin. Sonraki yapılandırma soruları "
"konumlandıkları saat dilimlerini temsil eden şehirlerin listesini sunarak bu "
"seçiminizi daraltacak."

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Abidjan"
msgstr "Abidjan"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid "Accra"
msgstr "Akra"

#. Type: select
#. Choices
#. Translators: do not translate underscores. You can use spaces instead.
#: ../tzdata.templates:2001
msgid 

Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

[Cyril Brulebois]

Hi Santiago,

Santiago Ruano Rincón  (2023-01-23):
> Thanks everybody for the inputs. I've applied Paul's solution, and the
> generated .deb can be downloaded from here:
> 
> https://salsa.debian.org/debian/ifupdown/-/jobs/3841392/artifacts/raw/debian/output/ifupdown_0.8.41~1.gbp3a6fae+salsaci+20230123+42_amd64.deb
> 
> Would it be possible for you (Oleg, Paul, Jeff, kibi et al.) to give it
> a try?

(Reading your mail with s/Paul/Pascal/g in mind.)

Tests yesterday seem to indicate successful results, but again I've only
tested a few combinations in a VM (to keep the feedback loop short).

From the installer team point of view, I'd welcome a swift upload with
this patch, possibly with urgency=high so that the fix reaches testing
soon. This will another blocker out of the way for the next D-I release!

Thanks!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1023472: Fix for double Window Manager in LXQt

[Roland Clobus]

Hello Holger,

On 22/01/2023 21:02, Holger Wansing wrote:

Am 22. Januar 2023 18:27:18 MEZ schrieb Roland Clobus :
In sddm's control I see:
... snip ...
So a Recommends.


Sorry. I was reading the information on 
https://packages.debian.org/sid/sddm-theme-debian-elarun incorrectly.

Indeed, it is a recommends relationship.


In the default case of generating a live image (only depend and recommend is 
followed), this is sufficient to fulfil the recommends 
(sddm-theme-debian-breeze | sddm-theme) in sddm with sddm-theme-debian-elarun, 
which is mentioned earlier and therefore the second part of the or-statement 
will be met.


My tests in a freshly installed bookworm system showed,
that sddm is indeed installed by sddm-theme-debian-elarun
installation (and that matches the Recommends),
so don't know, what is right.


I see this issue in openQA for two separate test cases:
1) Running the Debian installer with the LXQt desktop enabled
   Latest result: 
https://openqa.debian.net/tests/117521#step/_graphical_wait_login/13

2) Starting the live image for LXQt
   Latest result: https://openqa.debian.net/tests/117381#step/bootwalk_0/7

The issue isn't the sddm-theme-debian-elarun is not installed, but the 
additionally sddm-theme-debian-breeze gets installed too. And 
sddm-theme-debian-breeze additionally brings in kwin.


With kind regards,
Roland


OpenPGP_signature
Description: OpenPGP digital signature

Bug#985258: closed by c.bu...@posteo.jp ()

[Francesco Potortì]

Hm.  This is what I got on my Debian testing where I just upgraded 
backintime-qt to unstable:

# backintime-qt

Back In Time
Version: 1.3.3-dev

Back In Time comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type `backintime --license' for details.

INFO: user-callback returned '- GUI started'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
INFO: user-callback returned '- Mounting drives
Mounting /backup'
INFO: user-callback returned '- Unmounting drives
Unmounting /backup'
INFO: user-callback returned '- GUI closed'
Segmentation fault


The segmentation fault on exit may be harmless, and may have been there for a 
long time, as I usually call it from the graphics menu.

Bug#1029517: ITP: libgoto-file-perl -- Perl module that allows swapping the currently compiling file for a new one

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libgoto-file-perl
  Version : 0.005
  Upstream Author : Chad Granum 
* URL : https://metacpan.org/release/goto-file
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module that allows swapping the currently compiling 
file for a new one

goto::file allows Test2::Harness to swap out the main script for the new
file without adding a stack frame.

It is rare, but there are times where you want to swap out the currently
compiling file for a different one. This module does that. From the point
you 'use' the module perl will be parsing the new file instead of the
original.

This module was created specifically for Test2::Harness which can preload
modules and fork to run each test. The problem was that using 'do' to execute
the test files post-fork was resuling in extra frames in the stack trace...
in other words there are a lot of tests that assume the test file is the
bottom of the stack. This happens all the time, specially if stack traces
need to be verified.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1029518: git: "git bundle create" results in segfault

[Ansgar]

Package: git
Version: 1:2.39.0-1
Severity: minor
File: /usr/bin/git
Tags: upstream

Running "git bundle create" (without further arguments) results in a
segmentation fault:

+---
| $ $ git bundle create
| Segmentation fault (core dumped)
+---

It works fine if I add the other required arguments, but I expected an
error message telling me what the other arguments are and in which
order "git bundle create" expects them.

Ansgar

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

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

Versions of packages git depends on:
ii  git-man  1:2.39.0-1
ii  libc62.36-8
ii  libcurl3-gnutls  7.87.0-2
ii  liberror-perl0.17029-2
ii  libexpat12.5.0-1
ii  libpcre2-8-0 10.40-3
ii  perl 5.36.0-7
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages git recommends:
ii  ca-certificates  20211016
ii  less 590-1.1
ii  openssh-client [ssh-client]  1:9.1p1-2
ii  patch2.7.6-7

Versions of packages git suggests:
ii  gettext-base  0.21-10
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-email 
ii  git-gui   1:2.39.0-1
pn  git-mediawiki 
pn  git-svn   
ii  gitk  1:2.39.0-1
pn  gitweb

-- no debconf information

Bug#1029520: new releases are available

[Marco d'Itri]

Source: spampd
Version: 2.53-1.2
Severity: wishlist

Are you still maintaining this package? New releases have been available 
for a long time: https://github.com/mpaperno/spampd/releases .

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1023752: visidata: New upstream version: v2.10.2 (Oct 8, 2022)

[Anja]

Yeah, let's try! Thanks, Martin. =)

On Mon, 23 Jan 2023 at 01:29, Martin  wrote:

> On 2023-01-22 22:12, Anja wrote:
> > Oh! Ty! What's your personal deadline so you have time to review?
>
> Let's calculate: Freeze date, 2023-02-12, minus five days for testing
> migration, 2023-02-07, minus one weekend: 2023-02-03 more or less.
>
> > I will talk with the author, Saul. Nothing is coming up that is a
> dealbreaker for 2.11, so as far as I understand it that is the one we are
> going to go with. Either
> > that or 2.10.2.
>
> I suggest to go for 2.10.2 right now, and if we still can get 2.11
> into the release afterwards, the better!
>
> Cheers
>

Bug#1029459: hp-plugin crashes when trying to download plugin with error NameError: name 'get_distro_std_name' is not defined. Did you mean: 'get_distro_name'?

[Brian Potkin]

On Mon 23 Jan 2023 at 01:39:46 +0530, Pirate Praveen wrote:

> Package: hplip
> Version: 3.22.10+dfsg0-1
> Severity: grave
> Justification: makes it unusable
> 
> $ hp-plugin
> 
> HP Linux Imaging and Printing System (ver. 3.22.10)
> Plugin Download and Install Utility ver. 2.1
> 
> Copyright (c) 2001-18 HP Development Company, LP
> This software comes with ABSOLUTELY NO WARRANTY.
> This is free software, and you are welcome to distribute it
> under certain conditions. See COPYING file for more details.
> 
> 
> HP Linux Imaging and Printing System (ver. 3.22.10)
> Plugin Download and Install Utility ver. 2.1
> 
> Copyright (c) 2001-18 HP Development Company, LP
> This software comes with ABSOLUTELY NO WARRANTY.
> This is free software, and you are welcome to distribute it
> under certain conditions. See COPYING file for more details.
> 
> QSocketNotifier: Can only be used with threads started with QThread
> Checking for network connection...
> Downloading plug-in from:
> Traceback (most recent call last):
>   File "/usr/share/hplip/ui5/plugindialog.py", line 248, in
> NextButton_clicked
> status, download_plugin_file, error_str =
> self.pluginObj.download(self.plugin_path,self.plugin_download_callback)
> 
> ^^^
>   File "/usr/share/hplip/installer/pluginhandler.py", line 257, in download
> core = core_install.CoreInstall()
>^^
>   File "/usr/share/hplip/installer/core_install.py", line 240, in __init__
> self.passwordObj = password.Password(ui_mode)
>^^
>   File "/usr/share/hplip/base/password.py", line 94, in __init__
> self.__readAuthType()  # self.__authType
> ^
>   File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
> distro_name = get_distro_std_name(os_name)
>   ^^^
> NameError: name 'get_distro_std_name' is not defined. Did you mean:
> 'get_distro_name'?
> Aborted

Thank you for you report, Pirate Praveen.

My attempt with

  sh -i hplip-3.22.10-plugin.run

failed over an ssh link. This is an upstream issue.
get_distro_std_name is not used in hplip-3.22.6.
Please report at

  https://bugs.launchpad.net/hplip/+bugs

I would query the severity of grave rather than
imortant. Plugin files can be installed with

  sh hplip--plugin.run --tar vxf
  python3 installPlugin.py

Regards,

Brian.

  
 

Bug#991533: lintian: please forget about required-field Standards-Version for udeb packages

[Cyril Brulebois]

Control: tag -1 patch

Cyril Brulebois  (2023-01-23):
> Can we please finally drop those checks? You'll find above the green
> light from Sean regarding lintian's possibly moving ahead of changes in
> Policy; since December, 5.6.11 even ends with:
> 
> udebs and source packages that only produce udebs do not use
> Standards-Version.
> 
> lintian's insistance on this topic led to wrong changes getting
> committed to dozens of repositories… :(

This seems to work for me:
  https://salsa.debian.org/lintian/lintian/-/merge_requests/448


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


signature.asc
Description: PGP signature

Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

[Santiago Ruano Rincón]

El 23/01/23 a las 00:24, Pascal Hambourg escribió:
> Oleg A. Arkhangelsky wrote:
> > Note that we have to use '--ignore-errors'. Otherwise if we have real
> > hotplug interface that is not present at the moment of restart, `ifup`
> > returns non-zero and systemd unit fail.
> 
> "--ignore-errors" marks missing interfaces as configured, so ifup will not
> configure them when invoked by udev. In order to not fail the systemd unit
> start on ifup error, you can prefix the command with "-".
> 
> On 22/01/2023 at 20:58, Cyril Brulebois wrote:
> > 
> > with an extra ens3 declared as auto, the following seems to work fine
> > for boot-up, stop and start, and restart:
> > 
> >  [Service]
> >  Type=oneshot
> >  EnvironmentFile=-/etc/default/networking
> >  ExecStart=/sbin/ifup -a --read-environment
> >  ExecStart=/bin/sh -c 'if [ -f /run/network/restart-hotplug ]; then 
> > /sbin/ifup -a --read-environment --allow=hotplug; fi'
> >  ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
> >  ExecStopPost=/usr/bin/touch /run/network/restart-hotplug
> >  RemainAfterExit=true
> >  TimeoutStartSec=5min
> 
> That seems needlessly convoluted. What about this:
> 
> [Service]
> Type=oneshot
> EnvironmentFile=-/etc/default/networking
> ExecStart=/sbin/ifup -a --read-environment
> ExecStart=-/sbin/ifup -a --read-environment --allow=hotplug
> ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
> RemainAfterExit=true
> TimeoutStartSec=5min
> 
> "start" and "restart" configure all existing "auto" and "allow-hotplug"
> interfaces.
> Missing "allow-hotplug" interfaces do not be marked as configured (so that
> they can be configured by udev) and do not make "start" or "restart" fail.

Thanks everybody for the inputs. I've applied Paul's solution, and the
generated .deb can be downloaded from here:

https://salsa.debian.org/debian/ifupdown/-/jobs/3841392/artifacts/raw/debian/output/ifupdown_0.8.41~1.gbp3a6fae+salsaci+20230123+42_amd64.deb

Would it be possible for you (Oleg, Paul, Jeff, kibi et al.) to give it
a try?

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#1029507: linux-image-6.1.0-1-amd64 isn't installable

[Diederik de Haas]

Control: reassign -1 dkms
Control: forcemerge 1029063 -1

On Monday, 23 January 2023 14:53:18 CET Stefano Simonucci wrote:
> Building module:
> Cleaning build area...
> make -j8 KERNELRELEASE=6.1.0-1-amd64 all
> KERNEL_SRC=/lib/modules/6.1.0-1-amd64/b uild...(bad exit status: 2)
> Error! Bad return status for module build on kernel: 6.1.0-1-amd64 (x86_64)
> Consult /var/lib/dkms/anbox-binder/1/build/make.log for more information.

This isn't a kernel issue, but an issue with anbox-binder which apparently is 
incompatible with kernel 6.1. Reassigning/merging accordingly.

It could be https://github.com/anbox/anbox-modules/issues/104 or if you're 
using https://github.com/Barronli/anbox_binder then it already says in the 
README.md: "Note it is already out of sync from Linux kernel tree, but it is 
still useful in certain situations."

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

Bug#1029515: gdb: An attempt to debug a mono application gives: Assertion `jiter->jiter_data != nullptr' failed.

[Bernhard Übelacker]

Package: gdb
Version: 12.1-4+b1
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org



Dear Maintainer,
I tried to debug a mono application in another Debian bug.

There I received the assertion below, with just trying to run
the application inside gdb.

I found this gdb upstream bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=29277

And a gdb package built with the proposed patch from comment 1
does no longer hit this assertion.

Might be just an issue with debug information
separated to external files (mono-runtime-dbg package).

Kind regards,
Bernhard



# with this packages installed: cowbell cowbell-dbgsym mono-dbg mono-runtime-dbg

benutzer@debian:~$ gdb -q --args /usr/bin/mono /usr/lib/cowbell/cowbell.exe
Reading symbols from /usr/bin/mono...
Reading symbols from /usr/lib/debug//usr/bin/mono-sgen...
Mono support loaded.
Mono support loaded.
(gdb) run
Starting program: /usr/bin/mono /usr/lib/cowbell/cowbell.exe
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
/build/gdb-JNEVqL/gdb-12.1/gdb/jit.c:1252: internal-error: jit_event_handler: 
Assertion `jiter->jiter_data != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
- Backtrace -
0x55c034f2b21e gdb_internal_backtrace_1
/build/gdb-JNEVqL/gdb-12.1/gdb/bt-utils.c:122
0x55c034f2b21e _Z22gdb_internal_backtracev
/build/gdb-JNEVqL/gdb-12.1/gdb/bt-utils.c:168
0x55c035259d54 internal_vproblem
/build/gdb-JNEVqL/gdb-12.1/gdb/utils.c:394
0x55c035259f7a _Z15internal_verrorPKciS0_P13__va_list_tag
/build/gdb-JNEVqL/gdb-12.1/gdb/utils.c:471
0x55c035398e81 _Z14internal_errorPKciS0_z
/build/gdb-JNEVqL/gdb-12.1/gdbsupport/errors.cc:55
0x55c03509585c _Z17jit_event_handlerP7gdbarchP7objfile
/build/gdb-JNEVqL/gdb-12.1/gdb/jit.c:1252
0x55c034f0d0b8 handle_jit_event
/build/gdb-JNEVqL/gdb-12.1/gdb/breakpoint.c:5552
0x55c034f0d0b8 _Z20bpstat_run_callbacksP6bpstat
/build/gdb-JNEVqL/gdb-12.1/gdb/breakpoint.c:5753
0x55c035088266 process_event_stop_test
/build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:6452
0x55c03508c888 handle_stop_requested
/build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:4465
0x55c03508c888 handle_stop_requested
/build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:4460
0x55c03508c888 handle_inferior_event
/build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:5695
0x55c03508e479 _Z20fetch_inferior_eventv
/build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:4085
0x55c035399405 gdb_wait_for_event
/build/gdb-JNEVqL/gdb-12.1/gdbsupport/event-loop.cc:725
0x55c0353999f6 _Z16gdb_do_one_eventv
/build/gdb-JNEVqL/gdb-12.1/gdbsupport/event-loop.cc:212
0x55c0350cedec start_event_loop
/build/gdb-JNEVqL/gdb-12.1/gdb/main.c:421
0x55c0350cedec captured_command_loop
/build/gdb-JNEVqL/gdb-12.1/gdb/main.c:481
0x55c0350d0a64 captured_main
/build/gdb-JNEVqL/gdb-12.1/gdb/main.c:1351
0x55c0350d0a64 _Z8gdb_mainP18captured_main_args
/build/gdb-JNEVqL/gdb-12.1/gdb/main.c:1366
0x55c034e96219 main
/build/gdb-JNEVqL/gdb-12.1/gdb/gdb.c:32
-

1: *jit_bp_sym.objfile = {original_name = "/usr/lib/debug//usr/bin/mono-sgen" 
...
2: *jit_bp_sym.objfile->separate_debug_objfile_backlink = {original_name = 
"/usr/bin/mono" ...



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

Kernel: Linux 6.1.0-2-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

Versions of packages gdb depends on:
ii  libbabeltrace1  1.5.11-1+b1
ii  libc6   2.36-8
ii  libdebuginfod1  0.188-2.1
ii  libexpat1   2.5.0-1
ii  libgcc-s1   12.2.0-14
ii  libgmp102:6.2.1+dfsg1-1.1
ii  libipt2 2.0.5-1
ii  liblzma55.4.1-0.0
ii  libmpfr64.2.0-1
ii  libncursesw66.4-1
ii  libpython3.11   3.11.1-2
ii  libreadline88.2-1.3
ii  libsource-highlight4v5  3.1.9-4.2+b2
ii  libstdc++6  12.2.0-14
ii  libtinfo6   6.4-1
ii  libxxhash0  0.8.1-1
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.36-8

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information
Thank you for using reportbug

Bug#1029516: phppgadmin: postgresql-15 not supported

[Georg]

Package: phppgadmin
Version: 7.13.0+dfsg-2
Severity: important
Tags: upstream
X-Debbugs-Cc: ge...@schorsch-tech.de

Dear Maintainer,

   * What led up to the situation?
Debian/bookwork includes postgresql-15.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
phppgadmin 7.13.0 does not support postgresql-15. So i downloaded a fork from
https://github.com/ReimuHakurei/phpPgAdmin and activated in on my database
server.

   * What was the outcome of this action?
Problem solved. Can now connect to the postgresql-15 server.

   * What outcome did you expect instead?
Problem solved. Can now connect to the postgresql-15 server.



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: amd64

Kernel: Linux 6.1.0-1-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages phppgadmin depends on:
ii  libapache2-mod-php  2:8.2+93
ii  libapache2-mod-php8.2 [libapache2-mod-php]  8.2.1-1
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
pn  libphp-adodb
ii  php-common  2:93
ii  php-mbstring2:8.2+93
ii  php-pgsql   2:8.2+93
ii  php8.2-mbstring [php-mbstring]  8.2.1-1
ii  php8.2-pgsql [php-pgsql]8.2.1-1

Versions of packages phppgadmin recommends:
ii  apache2 [httpd]  2.4.55-1

Versions of packages phppgadmin suggests:
pn  postgresql  
pn  postgresql-doc  
pn  slony1-bin  

Bug#1029510: ITP: liboverload-filecheck-perl -- Perl module that provides a hook system to mock Perl filecheck operations

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: liboverload-filecheck-perl
  Version : 0.013
  Upstream Author : Nicolas R 
* URL : https://metacpan.org/release/Overload-FileCheck
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module that provides a hook system to mock Perl 
filecheck operations

Overload::FileCheck provides a way to mock one or more file checks. It is also
possible to mock stat/lstat functions using "mock_all_from_stat" and let
Overload::FileCheck mock for you for any other -X checks.

By using mock_all_file_checks you can set a hook function to reply any -X
check. You can provide your own pure perl code when performing file checks
using one of the -X ops: -e, -f, -z.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1006130: ITP: sioyek -- Sioyek is a PDF viewer designed for reading research papers and technical books

[Antoine Beaupré]

Yeah, I have to say many thanks. This is by *far* the best PDF reader I
have seen out there. That it can also read EPUB just absolutely blows my
mind as well.

Good job!
-- 
Quidquid latine dictum sit, altum sonatur.
Whatever is said in Latin sounds profound.

Bug#1029512: cdrdao: Getting gcdmaster by including cdrdao 1.2.5 in Bookworm

[Gervase]

Package: cdrdao
Version: 1:1.2.4-3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

For a long time, gcdmaster has not been part of cdrdao because of what I
believe are problems compiling against GTK2 library.  gcdmaster now compiles
against GTK3 library in the up-coming cdrdao 1.2.5.  1.2.5 possibly comes out in
1 weeks time.

Can somebody confirm if cdrdao 1.2.5 misses being included in Bookworm because
other packages are dependent on cdrdao (i.e. 12th January 2023 deadline has been
missed) or is it that the 12th February 2023 freeze is more pertinent for
cdrdao?

Sorry for the newbie question.

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

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

Bug#1029513: xss-lock: crashes with core dump on activation

[Stuart Freeman]

Package: xss-lock
Version: 0.3.0+git20220214.adafe4-2
Severity: grave
Justification: renders package unusable

Calling `xdg-screensaver activate` causes xss-lock to dump core.

Output of `systemctl --user status xss-lock:

× xss-lock.service - X Session Lock
 Loaded: loaded (/home/stuart/.config/systemd/user/xss-lock.service; 
enabled; preset: enabled)
 Active: failed (Result: core-dump) since Mon 2023-01-23 09:53:05 EST; 
3min 55s ago
   Duration: 17.084s
Process: 8434 ExecStart=xss-lock -s ${XDG_SESSION_ID} -n 
/usr/libexec/xsecurelock/dimmer -l -- xsecurelock (code=dumped, signal=ABRT)
   Main PID: 8434 (code=dumped, signal=ABRT)
CPU: 114ms

Jan 23 09:52:48 gamera systemd[1481]: Started X Session Lock.
Jan 23 09:52:48 gamera xss-lock[8434]: Error getting session: 
GDBus.Error:org.freedesktop.login1.NoSessionForPID: Caller does not belong to 
any known session.
Jan 23 09:53:05 gamera xss-lock[8434]: xss-lock: ./src/xss-lock.c:469: 
logind_session_set_locked_hint: Assertion `logind_session' failed.
Jan 23 09:53:05 gamera systemd-coredump[8576]: [] Process 8434 (xss-lock) 
of user 1000 dumped core.

   Stack trace of thread 8434:
   #0  0x7f615a9d5ccc 
__pthread_kill_implementation (libc.so.6 + 0x8accc)
   #1  0x7f615a986ef2 
__GI_raise (libc.so.6 + 0x3bef2)
   #2  0x7f615a971472 
__GI_abort (libc.so.6 + 0x26472)
   #3  0x7f615a971395 
__assert_fail_base (libc.so.6 + 0x26395)
   #4  0x7f615a97fdf2 
__GI___assert_fail (libc.so.6 + 0x34df2)
   #5  0x55967f985ff7 n/a 
(xss-lock + 0x3ff7)
   #6  0x55967f9866cc n/a 
(xss-lock + 0x46cc)
   #7  0x55967f9868ee n/a 
(xss-lock + 0x48ee)
   #8  0x7f615abc767f 
g_main_context_dispatch (libglib-2.0.so.0 + 0x5467f)
   #9  0x7f615abc7a38 n/a 
(libglib-2.0.so.0 + 0x54a38)
   #10 0x7f615abc7cef 
g_main_loop_run (libglib-2.0.so.0 + 0x54cef)
   #11 0x55967f9857e2 main 
(xss-lock + 0x37e2)
   #12 0x7f615a97218a 
__libc_start_call_main (libc.so.6 + 0x2718a)
   #13 0x7f615a972245 
__libc_start_main_impl (libc.so.6 + 0x27245)
   #14 0x55967f985af1 
_start (xss-lock + 0x3af1)

   Stack trace of thread 8438:
   #0  0x7f615aa470af 
__GI___poll (libc.so.6 + 0xfc0af)
   #1  0x7f615abc79ae n/a 
(libglib-2.0.so.0 + 0x549ae)
   #2  0x7f615abc7acc 
g_main_context_iteration (libglib-2.0.so.0 + 0x54acc)
   #3  0x7f615abc7b11 n/a 
(libglib-2.0.so.0 + 0x54b11)
   #4  0x7f615abf1cfd n/a 
(libglib-2.0.so.0 + 0x7ecfd)
   #5  0x7f615a9d3fd4 
start_thread (libc.so.6 + 0x88fd4)
   #6  0x7f615aa5466c 
__clone3 (libc.so.6 + 0x10966c)
 Warning: The unit file, source configuration file 
or drop-ins of xss-lock.service changed on disk. Run 'systemctl --user 
daemon-reload' to reload units.

   Stack trace of thread 8440:
   #0  0x7f615aa470af 
__GI___poll (libc.so.6 + 0xfc0af)
   #1  0x7f615abc79ae n/a 
(libglib-2.0.so.0 + 0x549ae)
   #2  0x7f615abc7cef 
g_main_loop_run (libglib-2.0.so.0 + 0x54cef)
   #3  0x7f615ae23996 n/a 
(libgio-2.0.so.0 + 0x118996)
   #4  0x7f615abf1cfd n/a 
(libglib-2.0.so.0 + 0x7ecfd)
   #5  0x7f615a9d3fd4 
start_thread (libc.so.6 + 0x88fd4)
   #6  0x7f615aa5466c 
__clone3 (libc.so.6 + 0x10966c)
   ELF object binary 
architecture: AMD x86-64
Jan 23 09:53:05 gamera systemd[1481]: xss-lock.service: Main process 

Bug#1028197: plasmashell: Program terminated with signal SIGSEGV

[Bernhard Übelacker]

(gdb) bt
...
#4  
#5  0x7f54b82563fb in QQuickItem::~QQuickItem() () from 
/lib/x86_64-linux-gnu/libQt5Quick.so.5
#6  0x7f54b83d0045 in ?? () from /lib/x86_64-linux-gnu/libQt5Quick.so.5
#7  0x7f54b66dd53f in QObject::event(QEvent*) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7f54b7362f5e in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9  0x7f54b66b17c8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x7f54b66b4761 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7f54b670a1d3 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7f54b46657a9 in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7f54b4665a38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x7f54b4665acc in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x7f54b67098b6 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x7f54b66b024b in 
QEventLoop::exec(QFlags) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x7f54b66b83b6 in QCoreApplication::exec() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x55937ecd0c6c in ?? ()
#19 0x7f54b624618a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#20 0x7f54b6246245 in __libc_start_main () from 
/lib/x86_64-linux-gnu/libc.so.6


Hello Piotr,
I fear that backtrace is not that distinctive.
Upstream I found [1] a few bugs, but they also do
not give helpful pointers.

So here it might also be helpful to see what might be contained
in journalctl or in .xsession-errors:

  journalctl --user --since="2023-01-08 12:10" --until="2023-01-08 12:12"

Can you please give a rough estimate how often it does crash?

Kind regards,
Bernhard

[1]
  https://bugs.kde.org/show_bug.cgi?id=461464
  https://bugs.kde.org/show_bug.cgi?id=460477

Bug#1029514: ITP: kotlinx-atomicfu -- AtomicFU - Idiomatic way to use atomic operations in Kotlin

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org

* Package name: kotlinx-atomicfu
  Version : 0.11.12
  Upstream Contact: JetBrains
* URL : https://github.com/Kotlin/kotlinx-atomicfu
* License : Apache-2.0
  Programming Lang: Kotlin
  Description : AtomicFU - Idiomatic way to use atomic operations in Kotlin

Atomicfu is a multiplatform library that provides the idiomatic and effective
way of using atomic operations in Kotlin:
 * Code it like a boxed value, but run it in production efficiently:
   - as java.util.concurrent.atomic.AtomicXxxFieldUpdater on Kotlin/JVM
   - as a plain unboxed value on Kotlin/JS
 * Multiplatform: write common Kotlin code with atomics that compiles
   for Kotlin JVM, JS, and Native backends:
   - Compile-only dependency for JVM and JS (no runtime dependencies)
   - Compile and runtime dependency for Kotlin/Native
 * Use Kotlin-specific extensions (e.g. inline loop, update, updateAndGet
   functions).
 * Use atomic arrays, user-defined extensions on atomics and locks.
 * Tracing operations for debugging.



AtomicFU was initially integrated into the kotlin package to make its
bootstrapping easier. Now that kotlin has been uploaded to unstable,
AtomicFU can be packaged separately.

This package will be maintained by the Java Team.

Bug#1029352: netcfg: broken ifupdown support for wireless interfaces

[Cyril Brulebois]

Control: tag -1 pending

Cyril Brulebois  (2023-01-21):
> I've pushed three commits in the pu/ifupdown+wireless branch:
>   
> https://salsa.debian.org/installer-team/netcfg/-/commits/pu/ifupdown+wireless

Updated branch:
  
https://salsa.debian.org/installer-team/netcfg/-/commits/pu/ifupdown+wireless-v2

> Commit links:
>  1. 
> https://salsa.debian.org/installer-team/netcfg/-/commit/9494d7ec02b32538db842d88c105db1ab2a6201b
>  2. 
> https://salsa.debian.org/installer-team/netcfg/-/commit/247056dbb22e6eacbea6348c5c9a6951eab948bd
>  3. 
> https://salsa.debian.org/installer-team/netcfg/-/commit/5ca665c6c26346e3c9c37c2df6366e8e5d718238

Updated commits, with changelog entries this time (no code change):
 1. 
https://salsa.debian.org/installer-team/netcfg/-/commit/aa62245f2960363f8b16f1f30d666936cc88bc83
 2. 
https://salsa.debian.org/installer-team/netcfg/-/commit/815cdfccaa5567fdf53594d47545d97c235de68e

Please note the third commit got moved to another branch:
  
https://salsa.debian.org/installer-team/netcfg/-/tree/pu/disable-hotplug-detection
  
https://salsa.debian.org/installer-team/netcfg/-/commit/9000be355b5e35134958c2655ec35bc75ba1b7e7

I suppose we can postpone wondering what to do about hotplug support
(netcfg currently believes everything is hotpluggable…) to a later time
(after bookworkm) given the broken “allow-hotplug” support at boot-up
(third issue) was an ifupdown regression in the end: #1022843.


My current plan includes more work on hw-detect; I'll upload netcfg with
commits from the ifupdown+wireless-v2 branch once I'm done (probably in
a few hours). Feedback regarding the netcfg commits is still very much
welcome (even after the upload, we can still tweak things before the
release).


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


signature.asc
Description: PGP signature

Bug#1027799: openvpn-dco-dkms: ovpn-dco branch "genl" compiles on 6.2 kernels

[xevilstar]

Package: openvpn-dco-dkms
Version: 0.0+git20221022-1
Followup-For: Bug #1027799
X-Debbugs-Cc: vmxevils...@gmail.com

Dear Maintainer,

I had fun talking upstream in order to find a solution and I can confirm that
branch "genl" compiles and modprobes on 6.2 kernels

please see https://github.com/OpenVPN/ovpn-dco/issues/20

Thanks for your time


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

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

Versions of packages openvpn-dco-dkms depends on:
ii  dkms  3.0.10-1

openvpn-dco-dkms recommends no packages.

openvpn-dco-dkms suggests no packages.

-- no debconf information