date:20230731


You filed *8* different 'bugs' which (almost?) all are about a Dell Mobile
Precision M6700 ... and not once did you say what actual problem you
experienced?!?


That's wrong (at least if you put it this straight).
Before I posted some (not all) of the bug reports, the Dell laptop 
stopped booting properly rather early; the root cause is still unknown 
(though an intermediate cause is finally resolved now, and the 
corresponding bug report is already closed).  It took me a bit to get a 
working console, a mouse and network going so as to simply be able to 
start debugging.  Some other machines I manage had (and still have) 
other, less severe symptoms, e.g., Wayland and programs depending on 
Wayland (e.g., “foot”) failing to start after Debian upgrade.


If your computer doesn't boot properly, you go one by one through every 
suspicious message you find. The fact that some messages are shown as 
warnings and others as errors is clearly meant to warn whoever reads 
them (i.e., the admin) and make him/her concerned.  By the definition of 
the terms “warning” and “error”!  If these messages shouldn't make the 
admin concerned, well, then the journalctl shouldn't show these messages 
as warnings (AFAIK, yellow) and errors (red according to `man 
journalctl`).  Please don't try to unload on me because of this mess; 
I'm just an admin, and not even a developer.


Therefore, please restore the bug reports you closed.

Gratefully,

Alma

Bug#1041140: mass bug closing


You filed *8* different 'bugs' which (almost?) all are about a Dell Mobile
Precision M6700 ... and not once did you say what actual problem you
experienced?!?


That's wrong.
Before I posted some (not all) of the bug reports, the Dell laptop 
stopped booting properly rather early; the root cause is still unknown 
(though an intermediate cause is finally resolved now, the bug report is 
already closed).  It took me a bit to get a working console, a mouse and 
network going so as to simply be able to start debugging.  Some other 
machines I manage had (and still have) other, less severe symptoms, 
e.g., Wayland and programs depending on Wayland (e.g., “foot”) failing 
to start after Debian upgrade.


If your computer doesn't boot properly, you go one by one through every 
suspicious message you find. The fact that some messages are shown as 
warnings and others as errors is clearly meant to warn whoever reads 
them (i.e., the admin) and make him/her concerned.  By the definition of 
the terms “warning” and “error”!  If these messages shouldn't make the 
admin concerned, well, then the journalctl shouldn't show these messages 
as warnings (AFAIK, yellow) and errors (red according to `man 
journalctl`).  Please don't try to unload on me because of this mess; 
I'm just an admin, and not even a developer.


Therefore, please restore the bug reports you closed.

Gratefully,

Alma

Bug#1041141: kernel: pmd_set_huge: Cannot satisfy [mem 0x…-0x…] with a huge-page mapping due to MTRR override.


https://bugzilla.kernel.org/show_bug.cgi?id=118801 which links to
https://web.archive.org/web/20190904223631/http://my-fuzzy-logic.de/blog/
index.php?/archives/41-Solving-linux-MTRR-problems.html



Thank you, I will look into it!


and my own educated guess: Disable the ASPEED device and see what happens ...


Any hint on how to do it on the linux command line in grub?

Bug#1042767: xterm: wrong path to utmp file in manpage

2023-07-31 Thread Thomas Dickey

On Mon, Jul 31, 2023 at 05:56:59PM +0200, Sven Joachim wrote:
> Package: xterm
> Version: 384-1
> Severity: minor
> 
> The path to the utmp(5) file in the xterm manpage is wrong:
> 
> ,
> | $ man xterm | grep -A1 /utmp
> |/etc/utmp
> | the system log file, which records user logins.
> `
> 
> That should read /var/run/utmp rather than /etc/utmp.  The minstall
> script tries to detect the path to the utmp file and substitute the
> correct value, but in the build chroot /var/run/utmp has apparently been
> absent, as no-one has ever logged in there.

yes... /etc/utmp appears to be the convention on AIX and HPUX.
I could put that last, (along with /var/adm), since those are
systems where people actually log in -- odd, but perhaps the
default should be the system where the file is least likely to
exist :-)

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1041142: closed by Diederik de Haas (Re: Debian's BTS is not for regular user questions)


On 01.08.23 01:12, Debian Bug Tracking System wrote:

You filed *8* different 'bugs' which (almost?) all are about a Dell Mobile
Precision M6700 ... and not once did you say what actual problem you
experienced?!?


That's wrong.
Before I posted some (not all) of the bug reports, the Dell laptop 
stopped booting properly rather early; the root cause is still unknown 
(though an intermediate cause is finally resolved now, the bug report is 
already closed).  It took me a bit to get a working console, a mouse and 
network going so as to simply be able to start debugging.  Some other 
machines I manage had (and still have) other, less severe symptoms, 
e.g., Wayland and programs depending on Wayland (e.g., “foot”) failing 
to start after Debian upgrade.


If your computer doesn't boot properly, you go one by one through every 
suspicious message you find. The fact that some messages are shown as 
warnings and others as errors is clearly meant to warn whoever reads 
them (i.e., the admin) and make him/her concerned.  By the definition of 
the terms “warning” and “error”!  If these messages shouldn't make the 
admin concerned, well, then the journalctl shouldn't show these messages 
as warnings (AFAIK, yellow) and errors (red according to `man 
journalctl`).  Please don't try to unload on me because of this mess; 
I'm just an admin, and not even a developer.


Therefore, please restore the bug reports you closed.

Gratefully,

Alma

Bug#1042776: [R-pkg-team] Bug#1042776: r-bioc-deseq: still depends on obsolete r-api-bioc-3.16

2023-07-31 Thread Charles Plessy

Le Mon, Jul 31, 2023 at 09:46:48PM +0200, Andreas Beckmann a écrit :
> 
>   The following packages have unmet dependencies:
>r-bioc-deseq : Depends: r-api-bioc-3.16 but it is not installable

Dear Andreas,

thanks for the catch,

the DESeq Bioconductor package was removed from the 3.17 release
upstream.  I think that we can remove it from unstable and testing too.

I will fill a removal later today.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from home  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

Bug#1042800: RM: nant -- RoQA; low popcon


Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:nant
Control: block -1 by 1042799

Please remove nant. It has a low popcon and is abandoned upstream.
It missed bookworm because of a trivially RC-buggy build dependency.

Bug#1001286: kernel: i2c i2c-0: Systems with more than 4 memory slots not supported yet, not instantiating SPD


A common step in triaging (actual) problems entails asking "can you try this
or that?" (f.e. a patch) and to answer that you need to actually test it,
which means you actually need to have the hardware.
A proper time to report this issue if you actually have the hardware and
actually experience the issue. Not sooner.
So when more than 4 DIMM slots get occupied, would the admin really be 
expected to post a bug report and wait until (hopefully) someone bothers 
to provide and enter a kernel patch into the kernel repository, which 
then (hopefully) gets into the mainstream branch, which then (hopefully) 
also gets into Debian sid and then (hopefully) into Debian testing and 
then (hopefully) into the next Debian stable?  I understand this 
process, and this takes years and is therefore quite long. The 
motherboard model with 8 slots of my post exists, AFAIK, already since 
2017. (The topic starter has probably been waiting for a permanent fix 
for over 1.5 years already. If I were him, I wouldn't be able to wait 
and would switch to another OS or sell the machine because I don't 
rebuild kernels myself.)



And when you report an actual issue, provide *full* information and do not try
to pre-filter it. What you think may not be relevant, may actually be.
It's fine if you repeat the part you think is most important in your main
message, but also provide the full log (f.e. full dmesg output).


I can't do it because anonymizing requires concentration, and I cannot 
remain concentrated while going over 10K lines of a typical output of 
journalctl -b and heaven knows how many more lines of other logs. 
Still, whenever I am explicitly asked for data of a particular sort, I 
will do my best to provide them.  As for the dmesg you asked, it's now 
attached from the beginning till the offending message in the subject 
line. If you need more, please say so.


Gratefully,

Alma[0.00] microcode: microcode updated early to revision 0x5003501, date = 2022-12-21
[0.00] Linux version 6.1.0-10-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-2 (2023-07-27)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-10-amd64 root=UUID=AnonymousUUID ro video=DP-1:2560x1440R
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: Supporting XSAVE feature 0x020: 'AVX-512 opmask'
[0.00] x86/fpu: Supporting XSAVE feature 0x040: 'AVX-512 Hi256'
[0.00] x86/fpu: Supporting XSAVE feature 0x080: 'AVX-512 ZMM_Hi256'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
[0.00] x86/fpu: xstate_offset[5]:  960, xstate_sizes[5]:   64
[0.00] x86/fpu: xstate_offset[6]: 1024, xstate_sizes[6]:  512
[0.00] x86/fpu: xstate_offset[7]: 1536, xstate_sizes[7]: 1024
[0.00] x86/fpu: Enabled xstate features 0xff, context size is 2560 bytes, using 'compacted' format.
[0.00] signal: max sigframe size: 3632
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009] usable
[0.00] BIOS-e820: [mem 0x000a-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x4a0dbfff] usable
[0.00] BIOS-e820: [mem 0x4a0dc000-0x4bb2bfff] reserved
[0.00] BIOS-e820: [mem 0x4bb2c000-0x4bcadfff] ACPI data
[0.00] BIOS-e820: [mem 0x4bcae000-0x4cdc7fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x4cdc8000-0x4e378fff] reserved
[0.00] BIOS-e820: [mem 0x4e379000-0x4fff] usable
[0.00] BIOS-e820: [mem 0x5000-0x6fff] reserved
[0.00] BIOS-e820: [mem 0xfd00-0xfe010fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00089fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] e820: update [mem 0x40571018-0x40579057] usable ==> usable
[0.00] e820: update [mem 0x40571018-0x40579057] usable ==> usable
[0.00] e820: update [mem 0x4055f018-0x40570057] usable ==> usable
[0.00]

Bug#1042799: RM: ikvm -- RoQA; low popcon; RC-buggy


Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:ikvm

Please remove ikvm. It is RC-buggy for a long time and missed several 
releases.


On Mon, 12 Nov 2018 14:26:45 +0100 Emmanuel Bourg wrote at #894353:

IKVM has been abandoned upstream [1] and it looks unlikely to be ported
to Java 11+ in the near future.

ikvm has no reverse dependencies and a low popcon, maybe the package
should be removed?

Bug#1042798: rinse: wrong default for --cache

2023-07-31 Thread Marc Lehmann

Package: rinse
Version: 4.1
Severity: minor

Dear Maintainer,

the manpage of rinse claims the default for --cache is 1, but rinse does
not seem to cache any packages unless "--cache 1" is explicitly given so
it sems the default is actually 0.

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 6.1.42-schmorp (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 rinse depends on:
ii  cpio   2.13+dfsg-7.1
ii  libterm-size-perl  0.211-1+b2
ii  libwww-perl6.68-1
ii  perl   5.36.0-7
ii  rpm4.18.0+dfsg-1+b1
ii  rpm2cpio   4.18.0+dfsg-1+b1
ii  wget   1.21.3-1+b2

rinse recommends no packages.

rinse suggests no packages.

-- no debconf information

Bug#1042797: libplist: Upgrade to v2.3.0

2023-07-31 Thread Boyuan Yang

Source: libplist
Version: 2.2.0-6
Tags: sid
Severity: normal
X-Debbugs-CC: cor...@debian.org

Hi all,

I was looking into the transition of package libplist 2.3.0+ at
https://release.debian.org/transitions/html/auto-libplist.html .

The renamed binary packages are ready in Experimental. However,
uploading new libplist is currently blocked by at least
https://github.com/libimobiledevice/libimobiledevice/issues/1435
and probably also https://github.com/libimobiledevice/libimobiledevice-glue .
Documenting this condition as a blocking bug here.

Thanks,
Boyuan Yang


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

Bug#1042567: pygame: Should Debian migrate to pygame-ce

2023-07-31 Thread Vincent Cheng

On Sun, Jul 30, 2023 at 5:27 AM Niels Thykier  wrote:
>
> Package: pygame
> Severity: normal
> X-Debbugs-Cc: ni...@thykier.net
>
> Hi
>
> It seems like the pygame community got split after an internal
> controversy:
> https://old.reddit.com/r/pygame/comments/1112q10/pygame_community_edition_announcement/
>
> The question now is whether Debian to track the fork or the original or
> both.
>
> A quick look at this upstream projects suggests that pygame-ce (the
> fork) seems to have run with the majority of the active contributors.
>
> Either way, there is a newer version of pygame / pygame-ce, that I would
> like to see in Debian. So please upgrade (either way). :)

My take on this split as the package maintainer (not involved in
either upstream community) is that I'm inclined to follow what other
distributions are doing, and it appears that other distros (Fedora,
Arch, Gentoo) are sticking with the original pygame; I haven't seen
anyone package the forked version. I intend on uploading pygame 2.5.0
soon.

Regards,
Vincent

Bug#1038981: capping maximum frequency no longer works in kernel 6.1


I don't want to be an ass, but why didn't you do such elementary research
before filing a bug report?


I don't want to be an ass, too, but the fact that you searched for 
exactly "powersave frequency governor" and “Intel p-state” (and NOT 
something else) is elementary to YOU.  I saw the Archlinux page but was 
(and still am) unsure of how much of what is said there applies to 
Debian.  Heaven knows how differently you and them configure the kernels 
(and surely you and them don't take exactly the same kernels anyway).


As for 
https://www.kernel.org/doc/html/v6.1/admin-guide/pm/intel_pstate.html , 
it's dated 2017 (and no later year is mentioned!), whereas the processor 
in #1038981 is from Q2'20, and the kernel is from 2023 (6 years later 
than the document date).  So even if I had found that document myself, I 
might have dismissed it just based on date. (To compare, certain 
configuration files, such as /etc/lvm.conf or /etc/default/grub, get 
partially outdated with every upgrade of Debian stable.) Anyway, does 
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE still exist and, if so, is this 
configuration option off in Debian kernels?  That's what seems to be the 
case based on
https://www.google.com/search?q="CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE"+amd64+site%3Adebian.org 
, but I can't be sure …


The original, user-level and high-level bug was that I noticed that I 
couldn't provably limit the processor speed via tlp after an upgrade 
from Debian 11 to Debian 12.  It took me quite a while (many hours 
spread over a few days) to get from that high level to the level of 
#1038981, and, as you surely understand, at a certain point I have to 
declare the boundary of my current expertise.


Gratefully,
AlMa

Bug#1042796: gnome-text-editor: The keyboard focus is lost after making a word to uppercase

2023-07-31 Thread zezamoral

Package: gnome-text-editor
Version: 43.2-1
Severity: normal
X-Debbugs-Cc: sazamor...@gmail.com

Dear Maintainer,


   * What led up to the situation?

right-click menu option to convert a word to uppercase

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Word to uppercase works fine.

   * What was the outcome of this action?

Changing a word to uppercase in right-click menu make the keyboard
focus be lost, so you are not able to continue using keyboard ( or ctrl+s for
save ) until a new left-click over the editor it is done.

   * What outcome did you expect instead?

Being able to continue using the mouse and keyboard shortcuts in
conjunction without the need of re click the text editor everytime this action
occurs.


Thanks for help !
Regards.


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

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

Versions of packages gnome-text-editor depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libadwaita-1-0   1.2.2-1
ii  libc62.36-9+deb12u1
ii  libcairo21.16.0-7
ii  libeditorconfig0 0.12.6-0.1
ii  libenchant-2-2   2.3.3-2
ii  libglib2.0-0 2.74.6-2
ii  libgtk-4-1   4.8.3+ds-2
ii  libgtksourceview-5-0 5.6.2-1
ii  libicu72 72.1-3
ii  libpango-1.0-0   1.50.12+ds-1

gnome-text-editor recommends no packages.

gnome-text-editor suggests no packages.

-- no debconf information

Bug#1042795: bookworm-pu: package mgba/0.10.1+dfsg-1+deb12u1

2023-07-31 Thread Ryan Tandy

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu

I would like to update mgba in bookworm with the following changes. Both 
bugs were introduced in mgba 0.10.0 and are thus regressions in 
bookworm. The patches are cherry-picks from mgba 0.10.2.

  * Import upstream patch to fix broken audio in libretro core.
(Closes: #1036829)

The bug subject says "Audio stutters horribly and sounds distorted". On 
my system, I just get no audio at all, with either gnome-games-app or 
retroarch as frontend. In any case, the patch is the only change to 
libretro code in 0.10.2, and does make audio work properly for me.

The short explanation of the bug is that the libretro core is maintained 
downstream (in a fork owned by the libretro folks), changes are pulled 
back to mgba upstream from time to time, and they missed one hunk during 
a resync. The patch simply restores the missing hunk of code.

I asked the submitter to test the proposed package, but they didn't 
respond.

  * Import upstream patch to fix crash on hardware incapable of OpenGL 3.2.

I actually have hardware (Intel GM45) affected by this, so I was able to 
verify it. Depending on configuration, mgba crashes either on startup, 
or when starting emulation. The patch restores support for older OpenGL 
implementations.

  * debian/gbp.conf: Set debian-branch to bookworm.

Hopefully self-explanatory.

The package does not have automated tests. I verified each fix with the 
libretro core and mgba-qt, and did some additional smoke testing to 
check for obvious regressions.

Thank you,
Ryan
diff -Nru mgba-0.10.1+dfsg/debian/changelog mgba-0.10.1+dfsg/debian/changelog
--- mgba-0.10.1+dfsg/debian/changelog   2023-01-15 10:33:17.0 -0800
+++ mgba-0.10.1+dfsg/debian/changelog   2023-06-26 16:51:44.0 -0700
@@ -1,3 +1,12 @@
+mgba (0.10.1+dfsg-1+deb12u1) UNRELEASED; urgency=medium
+
+  * Import upstream patch to fix broken audio in libretro core.
+(Closes: #1036829)
+  * Import upstream patch to fix crash on hardware incapable of OpenGL 3.2.
+  * debian/gbp.conf: Set debian-branch to bookworm.
+
+ -- Ryan Tandy   Mon, 26 Jun 2023 16:51:44 -0700
+
 mgba (0.10.1+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru mgba-0.10.1+dfsg/debian/gbp.conf mgba-0.10.1+dfsg/debian/gbp.conf
--- mgba-0.10.1+dfsg/debian/gbp.conf2023-01-15 10:33:17.0 -0800
+++ mgba-0.10.1+dfsg/debian/gbp.conf2023-06-26 16:51:44.0 -0700
@@ -1,5 +1,6 @@
 [DEFAULT]
 pristine-tar = True
+debian-branch = bookworm
 
 [pq]
 patch-numbers = False
diff -Nru 
mgba-0.10.1+dfsg/debian/patches/Libretro-Add-back-missing-audio-overkill-fixes-2734.patch
 
mgba-0.10.1+dfsg/debian/patches/Libretro-Add-back-missing-audio-overkill-fixes-2734.patch
--- 
mgba-0.10.1+dfsg/debian/patches/Libretro-Add-back-missing-audio-overkill-fixes-2734.patch
   1969-12-31 16:00:00.0 -0800
+++ 
mgba-0.10.1+dfsg/debian/patches/Libretro-Add-back-missing-audio-overkill-fixes-2734.patch
   2023-06-26 16:51:44.0 -0700
@@ -0,0 +1,56 @@
+From 71d1f122f9ecc0e4d85bf64a9fead6cdfc11dbd8 Mon Sep 17 00:00:00 2001
+From: Vicki Pfau 
+Date: Tue, 29 Nov 2022 02:20:02 -0800
+Subject: [PATCH] Libretro: Add back missing audio overkill (fixes #2734)
+
+---
+ src/platform/libretro/libretro.c | 33 
+ 1 file changed, 33 insertions(+)
+
+diff --git a/src/platform/libretro/libretro.c 
b/src/platform/libretro/libretro.c
+index 9bbd55ae6..2c0184d99 100644
+--- a/src/platform/libretro/libretro.c
 b/src/platform/libretro/libretro.c
+@@ -617,6 +617,39 @@ void retro_run(void) {
+   core->desiredVideoDimensions(core, &width, &height);
+   videoCallback(outputBuffer, width, height, BYTES_PER_PIXEL * 256);
+ 
++#ifdef M_CORE_GBA
++  if (core->platform(core) == mPLATFORM_GBA) {
++  blip_t *audioChannelLeft  = core->getAudioChannel(core, 0);
++  blip_t *audioChannelRight = core->getAudioChannel(core, 1);
++  int samplesAvail  = 
blip_samples_avail(audioChannelLeft);
++  if (samplesAvail > 0) {
++  /* Update 'running average' of number of
++   * samples per frame.
++   * Note that this is not a true running
++   * average, but just a leaky-integrator/
++   * exponential moving average, used because
++   * it is simple and fast (i.e. requires no
++   * window of samples). */
++  audioSamplesPerFrameAvg = 
(SAMPLES_PER_FRAME_MOVING_AVG_ALPHA * (float)samplesAvail) +
++  ((1.0f - 
SAMPLES_PER_FRAME_MOVING_AVG_ALPHA) * audioSamplesPerFrameAvg);
++  size_t samplesToRead = 
(size_t)(audioSamplesPerFrameAvg);
++  /* Resize audio output buffer, if required */
++  if (audioSampleBuffer

Bug#1041141: kernel: pmd_set_huge: Cannot satisfy [mem 0x…-0x…] with a huge-page mapping due to MTRR override.

On Saturday, 22 July 2023 23:19:53 CEST Al Ma wrote:
> I stand corrected – the very last message as of a few minutes ago concerned
> a different machine: WS C422 PRO/SE with Intel® Xeon® W-2235 CPU @ 3.80GHz,
> 32 GB RAM, ASPEED AST2500 64MB built-in graphics chip, and NVIDIA GeForce
> GTX 1660 Ti PCIe graphics card.

I already had the tabs open which a simple search brought up, so I'll share 
that. There are no guarantees in life, so I suggest to just try things out. 
Which is rather common/normal in troubleshooting issues.
No guarantees, but there's little chance the device blows up or catches fire...

https://bugzilla.kernel.org/show_bug.cgi?id=118801 which links to 
https://web.archive.org/web/20190904223631/http://my-fuzzy-logic.de/blog/
index.php?/archives/41-Solving-linux-MTRR-problems.html

and my own educated guess: Disable the ASPEED device and see what happens ...

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

Bug#1042794: udisks2: autopkgtest depends on NBS libblockdev-crypto2

2023-07-31 Thread Jeremy Bícha

Source: udisks2
Version: 2.10.0-4

The udisks2 autopkgtest depends on libblockdev-crypto2 but that
package has been replaced by libblockdev-crypto3.

This wasn't detected by debci because debci doesn't support
isolation-machine yet, but it was seen on Ubuntu's autopkgtest
runners.

Thank you,
Jeremy Bícha

Bug#1042759:

Thank You Simon for Your support! I saw You re-addressed the bug to the
right package.

I've also found there is something wrong with nouveau driver itself.
Whenever I run my old 5.13 kernel I have three monitors active.
When I boot the 6.1 kernel from Bookworm distro, the nouveau output is
blank with a white screen.

When I've tried to swap nouveau driver with nvidia from nvidia-kernel-
dkms package - it worked, but the signal was only on the nvidia output
(1 monitor out of 3). The intel GPU outputs remained off.
 
But that's another story, to be addressed elsewhere. Perhaps to a
kernel developers.

Brgds
Mike

Bug#1042759: scim-gtk-immodule: assumes windowing system is X11, segfaults if not

2023-07-31 Thread Simon McVittie

Control: retitle -1 scim-gtk-immodule: assumes windowing system is X11, 
segfaults if not
Control: reassign -1 scim-gtk-immodule 1.4.18+git20211204-0.1
Control: affects -1 + src:gtk4
Control: severity -1 important

On Mon, 31 Jul 2023 at 20:57:25 +0200, Michał Byrecki wrote:
> > (org.gnome.Nautilus:51577): GLib-GObject-WARNING **: 20:53:04.844:
> > invalid cast from 'GdkWaylandToplevel' to 'GdkX11Surface'
> > 
> > (org.gnome.Nautilus:51577): GLib-GObject-WARNING **: 20:53:04.844:
> > invalid cast from 'GdkWaylandDisplay' to 'GdkX11Display'

These warnings indicate that a component is assuming that all windows
are X11 windows, and all displays are X11 displays; and that's also the
cause of the segfault, while calling XGetWindowAttributes on something
that is not a valid X11 window (probably a null pointer dereference).

> > #1  0x7070d467 in  () at 
> > /usr/lib/x86_64-linux-gnu/gtk-4.0/4.0.0/immodules/libim-scim.so

This component seems to be the one that is making that assumption.
The bug affects multiple GTK 4 apps because it's a module that has been
loaded into GTK 4.

Looking at scim-gtk-immodule's GTK 4 code in
,
it does things like this:

> #ifdef GDK_WINDOWING_X11
> GdkX11Display *display = NULL;
> 
> if (widget != NULL) {
> display = GDK_X11_DISPLAY (gtk_widget_get_display(widget));
> } else {
> display = GDK_X11_DISPLAY (gdk_display_get_default ());
> }

That's not correct code: just because the X11 windowing system is
compiled into GTK, that doesn't mean it is the one currently in use. The
GdkDisplay object might be a GdkX11Display, but equally it might be a
GdkWaylandDisplay. (That's why GDK_BACKEND=x11 is a workaround for this,
because when that environment variable is set, the X11 windowing system
*is* the one in use.)

I haven't checked what scim-gtk-immodule does for GTK 3, but if it has the
same pattern there, it would be equally problematic for GTK 3.

The correct pattern is more like this:

GdkDisplay *display;

if (widget != NULL) {
display = gtk_widget_get_display (widget));
} else {
display = gdk_display_get_default ();
}

#ifdef GDK_WINDOWING_X11
if (GDK_IS_X11_DISPLAY (display) {
GdkX11Display *x11_display = GDK_X11_DISPLAY (display);

/* ... do X11 things with x11_display ... */
}
#endif
#ifdef GDK_WINDOWING_WAYLAND
if (GDK_IS_WAYLAND_DISPLAY (display) {
GdkWaylandDisplay *wayland_display = GDK_WAYLAND_DISPLAY (display);

/* ... do Wayland things with wayland_display ... */
}
#endif

Until scim-gtk-immodule is fixed, the workaround would be to either set
GDK_BACKEND=x11, or use an X11 desktop environment or a desktop environment
in X11 mode (like the "GNOME (Xorg)" option for GNOME), or remove
scim-gtk-immodule and use a different input method framework such as ibus.

ibus is the input method framework recommended by GNOME upstream. I can't
read or write any of the languages supported by scim myself, but many of
the input methods available for scim seem to be available for ibus too,
for example ibus-anthy seems to be the ibus equivalent of scim-anthy.

smcv

Bug#1042793: tracker-…: Failed to create location for error reports: Keine Berechtigung

2023-07-31 Thread Al Ma

Package: tracker-extract
Version: 3.4.3-1
Control: affects -1 tracker-miner-fs
In the journal of the currently stable Debian 12 we find a yellow warning 
“tracker-extract[…]: Failed to create location for error reports: Keine 
Berechtigung”, where “Keine Berechtigung” is German for “no permission” or “no 
rights”.  A bit later, the same wording is reproduced by tracker-miner-fs: 
“tracker-miner-f[…]: Failed to create location for error reports: Keine 
Berechtigung”.  See the attached excerpt from the journal.  These warnings are 
produced at boot time, and “Failed to create location for error reports: Keine 
Berechtigung” are yellow in the output of journalctl -b.  There are some 
high-level problems that the computer faces which may or may not be related 
(e.g., #1040497, evince no longer saves the prior searches, really last-used 
files do not always show up in the list of the last used files, …; I plan to 
report the new issues separately).  If, for each occurrence of the offending 
message, the location that allegedly can't be created is so standard that it 
can be made public, we'd like to see it in the journal so that we can manually 
check whether it should be created at all (and if it should, whether the 
permissions are indeed insufficient).  So as for now we simply wish for a more 
verbose error message if possible. (Later, other, higher-level bug reports may 
follow.) I run gdm3+gnome.
(I manually anonymize the stuff I post, so the attached data are terse. If 
anyone asks for (more) lines of a particular log or file, I'll try to do my 
best.)
Gratefully,
AlMa
Jul 31 14:29:14 AnonymousPC systemd[1]: systemd-localed.service: Deactivated 
successfully.
Jul 31 14:29:15 AnonymousPC systemd[1]: systemd-hostnamed.service: Deactivated 
successfully.
Jul 31 14:29:45 AnonymousPC geoclue[1212]: Service not used for 60 seconds. 
Shutting down..
Jul 31 14:29:45 AnonymousPC systemd[1]: geoclue.service: Deactivated 
successfully.
Jul 31 14:29:47 AnonymousPC realmd[1628]: quitting realmd service after timeout
Jul 31 14:29:47 AnonymousPC realmd[1628]: stopping service
Jul 31 14:29:47 AnonymousPC systemd[1]: realmd.service: Deactivated 
successfully.
Jul 31 14:30:02 AnonymousPC CRON[1923]: pam_unix(cron:session): session opened 
for user root(uid=0) by (uid=0)
Jul 31 14:30:02 AnonymousPC CRON[1924]: (root) CMD ([ -x /etc/init.d/anacron ] 
&& if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start 
>/dev/null; fi)
Jul 31 14:30:02 AnonymousPC CRON[1923]: pam_unix(cron:session): session closed 
for user root
Jul 31 14:33:40 AnonymousPC anacron[802]: Job `cron.daily' started
Jul 31 14:33:40 AnonymousPC anacron[1930]: Updated timestamp for job 
`cron.daily' to 2023-07-31
Jul 31 14:33:40 AnonymousPC su[1954]: (to nobody) root on none
Jul 31 14:33:40 AnonymousPC su[1954]: pam_unix(su:session): session opened for 
user nobody(uid=65534) by (uid=0)
Jul 31 14:33:40 AnonymousPC systemd[1]: Created slice user-65534.slice - User 
Slice of UID 65534.
Jul 31 14:33:40 AnonymousPC systemd[1]: Starting user-runtime-dir@65534.service 
- User Runtime Directory /run/user/65534...
Jul 31 14:33:40 AnonymousPC systemd[1]: Finished user-runtime-dir@65534.service 
- User Runtime Directory /run/user/65534.
Jul 31 14:33:40 AnonymousPC systemd[1]: Starting user@65534.service - User 
Manager for UID 65534...
Jul 31 14:33:40 AnonymousPC (systemd)[1962]: pam_unix(systemd-user:session): 
session opened for user nobody(uid=65534) by (uid=0)
Jul 31 14:33:40 AnonymousPC systemd[1962]: Queued start job for default target 
default.target.
Jul 31 14:33:40 AnonymousPC systemd[1962]: Created slice app.slice - User 
Application Slice.
Jul 31 14:33:40 AnonymousPC systemd[1962]: Created slice session.slice - User 
Core Session Slice.
Jul 31 14:33:40 AnonymousPC systemd[1962]: Created slice background.slice - 
User Background Tasks Slice.
Jul 31 14:33:40 AnonymousPC systemd[1962]: Reached target paths.target - Paths.
Jul 31 14:33:40 AnonymousPC systemd[1962]: Reached target timers.target - 
Timers.
Jul 31 14:33:40 AnonymousPC systemd[1962]: Starting dbus.socket - D-Bus User 
Message Bus Socket...
Jul 31 14:33:40 AnonymousPC systemd[1962]: Listening on dirmngr.socket - GnuPG 
network certificate management daemon.
Jul 31 14:33:40 AnonymousPC systemd[1962]: Listening on gcr-ssh-agent.socket - 
GCR ssh-agent wrapper.
Jul 31 14:33:40 AnonymousPC systemd[1962]: Listening on 
gnome-keyring-daemon.socket - GNOME Keyring daemon.
Jul 31 14:33:40 AnonymousPC systemd[1962]: Listening on 
gpg-agent-browser.socket - GnuPG cryptographic agent and passphrase cache 
(access for web browsers).
Jul 31 14:33:40 AnonymousPC systemd[1962]: Listening on gpg-agent-extra.socket 
- GnuPG cryptographic agent and passphrase cache (restricted).
Jul 31 14:33:40 AnonymousPC systemd[1962]: Listening on gpg-agent-ssh.socket - 
GnuPG cryptographic agent (ssh-agent emulation).
Jul 31 14:33:40 AnonymousPC systemd[1962]: Listening on gpg-agent.socket - 
GnuPG cryptographic a

Bug#1042792: rust-futures-util: Please update to v0.3.28

Source: rust-futures-util
Version: 0.3.21-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.3.28.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTIMbUACgkQLHwxRsGg
ASE+Uw/9GCwbVN4rLxLgq+4KzLCpXq9mcGi8UD+YixtlvlY5aEYb2dgLVgUq9Kv4
/SlUX1Yu1GbZzM6IyywZzmY7UT/rPIUGYhZ3FtUA197qk0nRtK41lQkNKN5bA9Oj
Kzfpw6OIhVzQTP/yKeHPRgLGa++Y5OVRdD8OHcm37GrOsL8bnkAEeyJhP3NZQKWR
4XCc+i1Diy1dvh11PGMrTPHKxZMfFDPqrI6+FatB5V23Kq7+eb2MWPlws4f/w50z
GOFSGPCgxMHTyakh4Hv791sSe0uIaJYlpTilSNQi4KyKZnGewZGEyayEzGHBMuF0
zTJtUkTvMnnGE5TASYvHpNQGgSXXU3fQil0muZ6p+ity13kAlRHeoK4UF60hvDzJ
9WhH6FSUJG19mnorNE6k/PWBgibCLU9crsBup3Oq6zYRzekGz6OpWmAihDMnnr2K
ZqN3GEn8AYWkS+0cWyhifno8ShLxDvz+WwePdKMpB1p0DKUwwGczdrD3iPwCf/Gt
pJM54kBVA7jjakLMljk89Rgezd2LeJMwFSY0v2rg+fUDYuRxmHPJRz83phUM+2C5
qS38yBgRqpUFJ9Qq3msMBPCZxRW0ARUzi9PmBGjqkQIfzySjZdiJGNBsPXpDfGxf
Swuam3RjFg50GANBPQ6njKHFqmIIvdGlDmUSOdvbMnQyaATqBsY=
=Zhg3
-END PGP SIGNATURE-

Bug#1042791: rust-futures-task: Please update to v0.3.28

Source: rust-futures-task
Version: 0.3.21-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.3.28.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTIMZQACgkQLHwxRsGg
ASHQbw/+NYlnZ5zbSs2rW7sZZg9coTKYXwyuRlmso08vyU8AKvrTXomelU2sO7w4
1YSXyJeLfMAb2KT3O7kBRUeRE1oJyZUQl9TuqnutbgbFUDxsR3QHsF2adNZTFOlT
EBvBvVoYUrLUCDjizZvbFnN+g3dkrAT6jgpI+YwdvarvaYNk2ipWivHKlomXKYLr
1fTEfQI5GsvQEhf6FGx+vdvErquUqsM5MxxUziwSf3LbPKNwLV875+GQtf9J8TLR
q86c1WhhYwGKkh5cFXz6RkrxOJnzKD8r4LWlrrpLMf8QdcestbKOVnyxxTV6z3va
mq9CFoV/tR5bEn1KNI/NfGj4uwtFKx9DKpiFRfOgECZ7/W5bSQTbzZNJ0zVv0Ce9
vKmCR3FZIhCsafxOf/nNKdShI1Oo99hebyDysogWgfhCBtrm6fjv5Fhm/V3SnU00
RjgU8jo9H5yOHjJvepX4xkHyzQkZeQ+w/SV0tYaWUv6fMq1Sf7sDzYe0U2+5DrcP
fy8gaXXtRadJM8NlD/z4YzeFsaOPyI9QSrtWIUk5qdOoaVg3ujQ3EjqUHAw6vA2w
AO+IFJyTE9Gh6LlC5M7M/OyZp4ubLT/KXuWbDe9yCVJ8WHCfFGIQ/+eO0Wk2Tpc4
Jc6qgZWPUx9ZGjkFibeULxd7nOfdD5d6nP27ygJ6RnNzfxO1xWk=
=gjhc
-END PGP SIGNATURE-

Bug#1038981: capping maximum frequency no longer works in kernel 6.1

On Saturday, 24 June 2023 00:19:50 CEST Al Ma wrote:
> Below, I try to cap the frequency for each of my processor cores, but some
> cores resists: ...
> ...
> The governor is powersave everywhere.

If I put "powersave frequency governor" in a search engine, one of the first 
results points to arch wiki, so of course I check that first:
https://wiki.archlinux.org/title/CPU_frequency_scaling#Scaling_governors
which says "powersave   Run the CPU at the minimum frequency"
which indicates that you're trying to do the exact same thing as the governor 
already does. Why?!? (rhetorical question, don't answer it) ...

> For kernel 5 with Debian 11 (which I can no longer test), everything worked

Reverting back to Debian 11 userland is difficult (and likely irrelevant), but 
trying the 5.10 kernel should still be possible afaik.

> like a charm (or at least I always observed all-400-MHz back then). So
> either the new kernel is erroneous or my processor broke somehow (perhaps,
> during the upgrade). It has Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz. 

... That same wiki page has a purple box saying:
"Note: Each governor is compatible with any scaling driver, with the 
exceptions of intel_pstate and amd_pstate in active mode, which provide 
pseudo-governors in the form of powersave and performance. See #Autonomous 
frequency scaling below."

follow that link and you'll see
"Both Intel and AMD define a way to have the CPU decide its own speed"

You have an intel CPU, so I put "Intel p-state" in a search engine and one of 
the first results points to a document on kernel.org. Update version number to 
6.1: https://www.kernel.org/doc/html/v6.1/admin-guide/pm/intel_pstate.html

> Who is the culprit? What to do?

I literally put 2 questions in a search engine and the very first link I 
checked from each result (arch wiki + kernel.org) gave me the likely answer or 
enough information to do an actual deep dive.

I don't want to be an ass, but why didn't you do such elementary research 
before filing a bug report?

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

Bug#1042790: rust-futures-sink: Please update to v0.3.28

Source: rust-futures-sink
Version: 0.3.21-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.3.28.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTIMXAACgkQLHwxRsGg
ASEY2w//UGex1Jx7OQD5h8j5KDUFbBFZKGvI1TGQLwGbTmWriGTeuCPwUoee+Ycz
tb+AKmDEMl5FHphpYfM9/kT0MfdNwlKWnDf2ZQFgSp+BZhh1Ty+7ZDO/403yVgU7
oHrlNRZkeaD36rBPYbSBVrvD08RAh6pbf6RR7tVeqcs6M8Bw3hiuu5IqNuD7KyEN
ksEtvhFx2oUI1Tx6ZpAdVku6tEfoZ0p9j6cTbmOXclchezoH+F+4/okUruiS4PBV
UhCOoCif7BLC/lkt45Fg3aQEGn3SmwHrmtb0GTExDgjftO/Ry3k7Ztt+owjNooMb
Qg3hpeXPBwByuFf2CYEpHqUHbmExAVAshujnPfh9NeDN3YHI/Tor/s9B85l3E/Mu
itDKyYggzmts6uqpqyE0U436eeG9Boub4TOO/8susa5rdK25KplWarHJE7UX3T1v
2y58w3dI6y1S1+O3WVdMGJ5USmfLR6SWv29IPQZbV9wuj+sr5RuIG30QJvnGVgyl
/RObt+3Z3B30N+f5wse6/jOO+UNErVW6P6gB3j0BFyn42GqJTCd1mtGvpH/pkvHd
jzC025M/USv12yfqnFdfHOS2wppuCiTDEPR4lzOrijtbwmq2xZ/NmYFZUEA3wAEG
dJ0FyxYSEsFpk/VvDUxRsdijVEEajjgsLHkJSL/jztaJ98c3BE0=
=3sa5
-END PGP SIGNATURE-

Bug#1042789: rust-futures-macro: Please update to v0.3.28

Source: rust-futures-macro
Version: 0.3.21-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.3.28.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTIMUAACgkQLHwxRsGg
ASHnSA/8Cwmeke2dbC5TI+pU5/B28SZ7UgnNJOuCoePmQAceuM/gxf8PB6rfYlwC
W2IjUYV2/wKlEBQtbXR9HBM861XzkskmSdcH2ruUdJsnDJs/LXZncyqCpQ3a2ycI
v9B/OB0EuMVGFx5kickHXr6jQW2VKIXYSf1jCW/w4tZ7N89xx4QiWubZQOWFUkG6
sO+XjEsME3CALi/LqJnfD4+YJ4psc1beSp8WSDULAFNurFWZ+yqkM8YH8YDzy9Ve
kPcq/g5JgLs4ezWG83IAZLktCbzU7Dj5bQ8NDFqIpNltlfRpAZ6LfroLAehxQAjg
ozxoZIGUcQuz1gY9lS3h4LY3Cm+kLM5C3HkpyS4Jf4NSkRFRtQpldR9LEU6HrP2/
Gl5Iailii+w8EP/UvbvuTJbpUxLRyGN6vS+QckV+ahD5aY389mb8zPmdFUGKS/RZ
/q8tIP+MNbmDrrEC/WaYLo9DraYCeXaMF6AjggQfDbqWpCO2FCesVsw3yQV8VJwe
v3o6Mx2cejQScQg9oc2oFuQvF/y48/F0r5ErSpc0+5UiIu9vvVXJxnjS8MUyU1xW
fKcR3KL/Z9a3hw8WPGn36N7OqFrTPNH75G2IDH3ctIluQjITMCkit5es4M4h+7SC
Z618lzBSeG8n9zvT2WMFip75buyWJaEdbUwQJOMjm1QasZokHX8=
=a0K7
-END PGP SIGNATURE-

Bug#1042788: rust-futures-io: Please update to v0.3.28

Source: rust-futures-io
Version: 0.3.21-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.3.28.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTIMRgACgkQLHwxRsGg
ASFhNhAAiNwAzGAWmzkw+XhA5ctvtObZMd6zGc2qq2QYPFcYkyiHoKv6bLCMoKOX
F5JqIWlgwb4J2RCCYYrPeR14VCznWyf1Y2Ap7l/FXC8uKnroidp/CAA4ld8lbrRQ
uHZLpR8HbeS8D6ZTHseFyBxVwSy5YC7obzuP4v1Yjpy5xsw24N+gq5sUyVP09TJY
lPqo1WXlff1Dy/Oj0br59GMWK+7vVKmQAUHWRWiauYd7WOwhiXtZ2LN1SRWRLw8m
TdXoPK1pWc3Qd1BP0HDKSPDZjEKFMCBLV+x4HOBVDPjyusrG/u3lu9p0d7mmkM5q
wYGvDQsIQ7Cwp+rxNLk+D5N4rVjIOM1d7l8S85B+/qq8Zk5CrAjWmx9453Sx78eI
x7mkVWsJ4lLJKv29OQ/BRO9UrB8PGkgpI14E1eMXQk3rMAbHuh6mkLP9Z+4q5XfF
gyqOeDsCFEqYCce66z3CqoGjYXEXhLeHewbfanM/4FsSDhqk2IUHgjSAvFhZRMWs
mhrZddWnlaEFXry2eWHTGXFr2+/Lgkg3UplkYhe09QBvHgVgN55RIa/IrXbcV53C
6chVHMORhU1C3kmioljqF4U4xRebvhxbcNdd6H2vUJVGaa7kmFtco71ZvNJMpnQ+
Uuswt/b3Fb4++ug30hjSA+4e5VUtOFgAb2dbet3faR9VG0wFBbY=
=FYuE
-END PGP SIGNATURE-

Bug#1042786: rust-futures-core: Please update to v0.3.28

Source: rust-futures-core
Version: 0.3.21-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.3.28.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTIMM4ACgkQLHwxRsGg
ASGITQ/7Bqj5UseM1WsA2rDbPZ+MS4sTJBtUarq6qOAh83k0fBuhkFLyCl2R1zND
qarsmfDDOOZebghjWYH2s8dAWE0z1Dxp40XY7e9iX4/YV3WVgatFSEmvpNMyqaYm
LQKNveM4DssJ/cCz1KSj4axjTSo808oSUVW+oLvyPtDB9DMZmjjd1yBgBDenLWoJ
kX4WvQYjLzTrjEyF0IkcGexjUflTPPp2NFmXk1ertwqW2ED4IoCcuhyl13CACJZO
AVvHMvBg5+7S0Ku/AgRbg9uGNw2U1+79l7IGpv1a3A9gqW9LzHT24izwYoX0j1qt
xyFSR1hTubYDTmdx3hwUExSm+ccZJXDLLtz+UY66vQYzWPiweGYvQ35D5jgUts2B
ajRV38nF9SKuIoCQ00BZ5P7gIjFQHKt/42hHEDZfh0hgByL9TcdCR6OrMs0+tWFg
rPE6lS7mOtLKptnra8m7G1apRD8DjOTsy5lgNo+V1mpitEtSLrTFTFK4kNCwNBM4
RsU9MpgGh2huU7b9Tb7bLserOdsVpF9bzmY2R0neKK5IzK8tUqyhBzJzDeQRydZE
+n240torW5IVynpkFZAVeAkzTZ9r3XhS+I142QzK3xNiHaUPo/++JM//SBMbLiSw
Xct/lkrle4NyjKXx+dSJcupWktx3SHeFIsQuRxSMLEsZlxphIiM=
=QB+o
-END PGP SIGNATURE-

Bug#1042787: rust-futures-executor: Please update to v0.3.28

Source: rust-futures-executor
Version: 0.3.21-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.3.28.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTIMPQACgkQLHwxRsGg
ASEEvA//ffPxdXIimt5OyypW9tFYdzzWkKRRaCTaZp3gwJ5+MQHhzifebxqonWxv
IcvXJMFc/5/zRzJGo/SiMXqApGMJJhhUGmdOefFM/0kED5F9ZlVpl2Uj0l8Eg/y6
Zi86jAxEbq6Zju7HQwhk1URhkmR+8lyTVS5wKHZvsmVF3Vw7tEAJhai6EHm1IqGM
Xgo1y2k6KJM5WCCaUm2JdkdS/9bbINtWhK8uQjVnwC9eU1Idu/wGEKnc5uJzAQeU
DUJ4jk+4jccjoTCzBd04K26Ii80nQjyW+qob5qeLWbV1bcd4bKBI95Qbuph/+Oyh
d459Xc9gYLsU0YnwDqUBK899eFdnqGzcp7fWT6I1XgPbwiWzEj2YJR9IjZIEMySj
NnXrFhTU3Jp3hnOyu3hkasP6PCvuUQZCLBUgIc0Zc4I2GylEAlu85V83HANeWm0S
Ig3p/5Dnq78eEEL/kjUlQpicrYD7XsidVqu6svWpXlOSiCjbFHuWz5Mn/cpdihNj
wFTbUTxNDrhHVaZadAKqtWg/6j5M2lCbpr0lzgXVSpIv3gZ4AVNsemMqz2FQw/KJ
Ft8GjS+KQ3iAVnwsV3/isLOHAHtgZsXeT3Tam8X1D+rV9LARh9rftgVzUdwnLJlb
YWQTGiif4Q0wQwRvA4pMBr3ZE9Nx3zfqXjmLdiXnyzUw3/0qIhc=
=xpsx
-END PGP SIGNATURE-

Bug#1042785: rust-futures-channel: Please update to v0.3.28

Source: rust-futures-channel
Version: 0.3.21-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.3.28.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTIMI8ACgkQLHwxRsGg
ASHMzg/8Cj+rbCcsKM/nwgzP9034qf6FakX3jaBVqKvzv/1yYmN1ej+zmr0PZjlq
6nxlRT/qJiTpdnIILRO0S5y6ZRqcZrKHFNPlARc7/CAl5RuL6HxsBinn+skasUS7
YxkdygqksM4gxhZFNFz5vP7N5LKtoFo6TGBIBuyqnRSuHmTQJQBWvJQWPQ2Nz3H8
YzGR8STKx0l7Eo7vnIi0BY5lTsjWGFG3toAZspeMOQxfYB1l8j3vLoT8R07FG5WU
t92i9c7wLRUmUpC7Ae9ugvj8rB79brnp+iZf/HSBpNO9KM09WHXutnTYFbGBIyqI
nEWYZlALAuQ6ipTr7QGd/iecrxjJrrBU9A36889QSjcHKIDbzEzMb8VJDKTgBEn8
GCixkQ00iCFVhTXVo6CHWuvWLkI4Q/8dXVWYzEVHvlrevGF95duHttIgjrniW7sA
jtlJee/AKmnte4GgyndixE03cWGmKSHY6Cnfs6HgN+rNt7gxb6Ti+/u26voKdmhb
1acM3BSuVyGPEKHLJ3EMMRTbpmWYBVe6DrS5/6k1bt7MIlIMSlhhfzDlEGCIPQjK
RmMJXuAGKKVl9g9vz/oUS54TvJN9LPYqm8mQfe1jsfwFofQklpCXC3NaWAGRbn9j
iNE4YTaleFjeuFZb0/zNc41XDnYtUVroNiafnt8/SZMxkm65+ps=
=g9lz
-END PGP SIGNATURE-

Bug#1042784: rust-prost-types: Please update to v0.11.9

Source: rust-prost-types
Version: 0.11.6-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.11.9.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTILqIACgkQLHwxRsGg
ASH75Q/+P8ZThaJmNODdrUC0x4B4HOLyX4yt5jdyPEyZv7nC0FPPCXslG9k1TcuZ
0sthJIyaH7hRtGFMSQMpYIXAkdXQZR60fz9B+14BuTRxxcsDyr6bFOTuvrXlkXYV
wUCNRiYHetWI/DEGEjlqBBMhlhd5qb4/plVdxjFWbRcPGyA5HTDldXvhiGZO1qh+
VHmKl+BxVLxBd3/U0/pyWLDGAtz3Erv02th8qhZ4XXh54+QRGzVIuZPTDzBiF7Gl
uqpEAtmhuzBGWX5l/P4GZU/fiOj9k8jjii6AGH4vEU4a6cxv9Ecf+/fZpn/h7Apb
70fr4hALR87u1ifMKDrmsZx7oWM8Gn5wvrLipoBMMMCwkv7YkvndpBl9D9dMPO8O
qVAkevdV1w1uId8vAB/O3hdMhGwTACoRBkVu4nDcLHJayTBenvP3H0kLFeyg4slv
qKCAJuMRt25gl77rO5FKvX9R6gj3LIWpb23bDs5d8X3EQwfMTNLM8tAd9kbDFqvH
Em23gV2WBjXjO/GXmAyzdvQgcoEU5/EmngBI2H0cwKaLQ7/CeymSfEcAa654q8mu
nWSWtxC2ij0yAFjAytuo2UuLJw3dQlFhtVd1sPlEqkydtVKBZTjbukMR8R8662OA
dgkBZmWYiWjzk7OUDIcucRiGfqowWbbA5XogXtCdu70JDaysaB8=
=DsOR
-END PGP SIGNATURE-

Bug#1042783: rust-prost-build: Please update to v0.11.9

Source: rust-prost-build
Version: 0.11.6-3
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.11.9.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTILkkACgkQLHwxRsGg
ASGfVw/8DOfl9Z1HfMI+jIGEIMz7hF31oDjSrV3FK4mF5Da5EtwMszFt4XtLSr1N
IaLxDwK+c0HZ9Vfoi38l+X3jt0N3Ud9QV/FQaLB3hv1U/wcTHVpJ6px7+vY6Jix9
2AmWH46dxmGrL5PQfawc4OZvf9GulUkkMJdtttn2ZN7RkRPpjIEpfU/fJIfx5tPl
bt0Zf+wOH6QZP8GKH7u0meMUNchltQMFpo54or5KgSGvYQxOoampo4vtPWx6zRBH
q1Gb6CmsXUmhSHfTBOgrMo5kaXgMhIxG9hmvoKlqb9hPitrkg6dhvnYOpdvFXycx
+Rj5GTHK7w2tmZyPf4lzQAYEsYQ8NcTPAtH7WRoWK3U777l1iHnh87haMHYob9GA
NGv2uM0p3ozDGrfKEiae5/Y8NmvoU7lY+97ea/+VyOMLCGMY6iEZqkvlYzL1nndF
L0+vXdf+XWlI8W+oMjfD2LW/yaxTZtKmyh4HPnsGYI2lsGPTyKQHSH5GlU8NHWvK
0Nb8VQlf47h0/8e8Fv/bYiqm3AQCNppvDosKlPA1X9breuvv0iwqERPUyD0vnYzt
+Tn/gOZw4trQY3kSX5wfzgLTXlRKcyksxZ2qUQV38UToziXiVNilrbI18SgA5jhC
r8ZOqzhPGTikDC3VvenOXCCnp9UZftL4hu0q3cwF2ExPU8koVWk=
=eeCp
-END PGP SIGNATURE-

Bug#1042782: rust-prost-derive: Please update to v0.11.9

Source: rust-prost-derive
Version: 0.11.9-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.11.9.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTILUkACgkQLHwxRsGg
ASF2/A//Z7S7GUBnHLv73l/VMnLF7wLTRsN+mgfQCInkav3M/YVLAlt1/coCWA8A
QDYgYkXF906BokzACCNYT+rhbAwGKJymH7VeqKVL4YpGNkSguJqxjEc8taDB7no4
bpgk7pzWNmqkNzXLCUNKkEBCDjDshOWo9OqHRzKUey6zfOC7qrVGSCTQAolk5XVo
6KvSoj3g4fsYOBo1uVeq4553MWw6HzocEMZr9/YxlI+GJT9YpqYUhtVPcuR6kIRe
XLU8RUv4U1xQdzPagqIwpuLgoQmYQ76dQfbllUNwG/pohQ1jcg2HiQ/riDMdVkyQ
FDmdA4a+2W5mUXqDjrPr9cH9NDYaZIfamNpay0JhA/Pc68i2WpcjzFWuOF6axTyi
4CDvflz1VBNRSuXMCXpfT75dXT5DEQdB7Qhhp03NG13W4KywEbv3jm3tWrDR7viW
zoFg0lOxY1HeFyqvZr2eDGWZ/xYYUKhc4UJwv7HH8hRx09Ai2qqw4o+nXRW5WbFE
nWIaqgUTTegVy/YYRaIAWk7XAJqU8LbqnhCClvd4ssS3FxEGo+5kbMjC+cqQxSg5
pdXJPUkKczmaEpTTPscCQogoveEQ60Y8KMTdTFZyZ9f+IQpT3MUARwVkK37jGsAI
KtN72sXRIMfLXJqjcCj+ojTcMBtxqUHuCir7WzxdoQ40o+Mw9SY=
=yl8x
-END PGP SIGNATURE-

Bug#1042781: Please demote fwupd to Recommends

2023-07-31 Thread Michael Biebl

Package: gnome-control-center
Version: 1:44.3-2
Severity: normal

Hi,

given that gnome-control-center runs just fine without fwupd and there
are (unfortunately) a lot of systems which are not supported by fwupd
please consider downgrading fwupd to Recommends.
It probably makes sense to install it by default but leave the option
open for users to selectively not install it.

Michael



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

Kernel: Linux 6.4.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 gnome-control-center depends on:
ii  accountsservice   22.08.8-6
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6-2.2
ii  desktop-base  12.0.6+nmu1
ii  desktop-file-utils0.26-1
ii  fwupd 1.9.3-1
ii  gnome-control-center-data 1:44.3-2
ii  gnome-desktop3-data   44.0-2
ii  gnome-settings-daemon 44.1-2
ii  gsettings-desktop-schemas 44.0-2
ii  libaccountsservice0   22.08.8-6
ii  libadwaita-1-01.3.3-2
ii  libc6 2.37-6
ii  libcairo2 1.16.0-7
ii  libcolord-gtk4-1  0.3.0-4
ii  libcolord21.4.6-2.2
ii  libcups2  2.4.2-5
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.14.1-4
ii  libgcr-base-3-1   3.41.1-3
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.76.4-4
ii  libgnome-bg-4-2   44.0-2
ii  libgnome-bluetooth-ui-3.0-13  42.5-3
ii  libgnome-desktop-4-2  44.0-2
ii  libgnome-rr-4-2   44.0-2
ii  libgnutls30   3.7.9-2
ii  libgoa-1.0-0b 3.48.0-2
ii  libgoa-backend-1.0-1  3.48.0-2
ii  libgsound01.0.3-2
ii  libgtk-3-03.24.38-2
ii  libgtk-4-14.10.4+ds-2
ii  libgtop-2.0-112.40.0-2
ii  libgudev-1.0-0238-2
ii  libibus-1.0-5 1.5.28-6
ii  libkrb5-3 1.20.1-2
ii  libmalcontent-0-0 0.11.0-4
ii  libmm-glib0   1.20.6-2
ii  libnm01.42.8-1
ii  libnma-gtk4-0 1.10.6-1
ii  libpango-1.0-01.50.14+ds-1
ii  libpangocairo-1.0-0   1.50.14+ds-1
ii  libpolkit-gobject-1-0 122-4
ii  libpulse-mainloop-glib0   16.1+dfsg1-2+b1
ii  libpulse0 16.1+dfsg1-2+b1
ii  libpwquality1 1.4.5-1+b1
ii  libsecret-1-0 0.20.5-3
ii  libsmbclient  2:4.18.5+dfsg-1
ii  libsnapd-glib-2-1 1.63-5
ii  libudisks2-0  2.10.0-4
ii  libupower-glib3   1.90.2-3
ii  libwacom9 2.6.0-1
ii  libx11-6  2:1.8.6-1
ii  libxi62:1.8-1+b1
ii  libxml2   2.9.14+dfsg-1.3
ii  webp-pixbuf-loader0.2.1-1

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.6-5+b1
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.28.1-1
ii  gnome-bluetooth-sendto42.5-3
ii  gnome-online-accounts 3.48.0-2
ii  gnome-remote-desktop  43.4-1
ii  gnome-user-docs   44.3-2
ii  gnome-user-share  43.0-1
ii  iso-codes 4.15.0-1
ii  libcanberra-pulse 0.30-10
ii  libnss-myhostname 254~rc3-3
ii  libspa-0.2-bluetooth  0.3.74-1+b1
pn  malcontent-gui
ii  network-manager-gnome 1.32.0-2
ii  polkitd   122-4
ii  power-profiles-daemon 0.13-2
ii  realmd0.17.1-2
ii  rygel 0.42.3-2
ii  rygel-tracker 0.42.3-2
ii  system-config-printer-common  1.5.18-1

Versions of packages gnome-control-center suggests:
pn  gnome-software | gnome-packagekit  
ii  gstreamer1.0-pulseaudio1.22.4-1
ii  pkexec 122-4
ii  x11-xserver-utils  7.7+9+b1

-- no debconf information

Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)

2023-07-31 Thread Jonathan Wiltshire

On Tue, Jul 25, 2023 at 02:43:35PM -0700, Otto Kekäläinen wrote:
> I am ready to upload mariadb/1:10.11.4-0+deb12u2 as a source-only
> upload with the requested changes[1] but I guess the previous
> upload[2] needs to clear the NEW queue first, right?

No, don't worry about that. You have the wrong version there though.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1042780: ca-certificates-java: Segmentation fault during postinst

2023-07-31 Thread Ben Westover

Package: ca-certificates-java
X-Debbugs-Cc: m...@benthetechguy.net
Version: 20230710
Severity: important

Hello,

During a piuparts job in Salsa CI, there was a segmentation fault during
this package's postinst run.

   Processing triggers for ca-certificates-java (20230710) ...
 Segmentation fault (core dumped)
 dpkg: error processing package ca-certificates-java (--configure):
  installed ca-certificates-java package post-installation script 
subprocess returned error exit status 139

This caused the job to fail. Here's the full log:
https://salsa.debian.org/BenTheTechGuy/prismlauncher/-/jobs/4497300

--
Ben Westover


OpenPGP_signature.asc
Description: PGP signature

Bug#1042111: chromium: Web Environment Integrity

2023-07-31 Thread Andres Salomon

On Wed, 26 Jul 2023 16:12:13 -0400 Andres Salomon  
wrote:
> As Matt mentioned, this is something that we need to decide if we 
want

> disabled at build time (deleting base_feature_status from
> third_party/blink/renderer/platform/runtime_enabled_features.json5 ,
> which would turn it back into a blink field-trial option that's
> disabled by default), disabled at runtime (I'm not sure whether a
> command-line argument or something set in initial_preferences).

I think what we'll do is disable this with a patch to 
runtime_enabled_features.json5 for now. If we ever need to revisit that 
decision later, we can further discuss it then.

Bug#1042574: RM: theano -- RoM, broken by numpy 1.24, theano mostly abandoned upstream

2023-07-31 Thread Rebecca N. Palmer


Control: retitle -1 RM: theano -- RoM; broken, mostly abandoned

On 31/07/2023 13:49, Andrius Merkys wrote:
Maybe it is worth to keep src:keras for the time 
being, until keras 3 arrives?


Similar things have happened before - src:llvm-toolchain-9 was removed 
well before src:beignet, making src:beignet unbuildable.

Bug#1042779: developers-reference: overhaul of chapter about i18n / l10n

2023-07-31 Thread Holger Wansing

Package: developers-reference
Severity: normal


Hi,

yesterday I was a bit shocked when reading chapter 8 of the developers-ref:
https://www.debian.org/doc/manuals/developers-reference/l10n.en.html

That chapter has several wrong/bad sentences (or is heavily outdated, if that
things have been correct like that at some time).

I comment here on the different parts; a complete patch which integrates all
this proposals is attached to this mail.



"For program messages, the gettext infrastructure is used most of the time. 
Most of the time, the translation is handled upstream within projects like the 
Free Translation Project, the GNOME Translation Project or the KDE Localization 
project.


... is used most of the time. Most of the time, the translation ...

Please avoid this doubled use of "most of the time" in direct repeating.
(only cosmetic, yes.)



The only centralized resources within Debian are the Central Debian 
translation statistics, where you can find some statistics about the 
translation 
files found in the actual packages, but no real infrastructure to ease the 
translation process."


... where you can find some statistics ... but no real infrastructure to ease 
the 
translation process.

This is not true. The statistics page provides the possibility to directly
download the po files by one click! This is for sure much easier than
loading the whole source package, uncompress it and pick the po file out from
there! So, it's much more than just a statistics page, and it makes translators
work much easier!
(What was meant here is probably, that Debian has no own pootle or Weblate
server, where the translation can be done directly online?)




For debconf templates, maintainers should use the po-debconf package to ease 
the work of translators, who could use the DDTP to do their work (but the 
French and Brazilian teams don't). Some statistics can be found both on the 
DDTP site (about what is actually translated), and on the Central Debian 
translation statistics site (about what is integrated in the packages).


Here we have some wrong facts. The DDTP infrastructure is only for translating
the package descriptions!
It does not handle debconf template translations!
And the DDTP site does not have statistics about debconf template translations.
(Don't know, if this was different in the past, but this is the status quo.)



For package-specific documentation (man pages, info documents, other formats),
almost everything remains to be done.


This is also not true!
We have many translated manpages now for example, so we cannot say 
"nothing has been done on this".




For all other material (gettext files, man pages, or other documentation), the 
best solution is to put your text somewhere on the Internet, and ask on 
debian-i18n for a translation in different languages. Some translation team 
members are subscribed to this list, and they will take care of the translation 
and of the reviewing process. Once they are done, you will get your translated 
document from them in your mailbox.


... the best solution is to put your text somewhere on the Internet ...

This seems rather weird for me. Debian is such a huge community with much
infrastructure, we should not recommend to "put the text somewhere on the 
Internet". That sounds poor.


... Once they are done, you will get your translated document from them in 
your mailbox. ...

There is a big consensus, that translations are sent via wishlist bugreports.



Please find a patch attached (can be seen as a proposal, of course).


So long
Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/source/l10n.rst b/source/l10n.rst
index c66173d..8935907 100644
--- a/source/l10n.rst
+++ b/source/l10n.rst
@@ -42,7 +42,7 @@ manual task, and the process depends on the kind of text you want to see
 translated.
 
 For program messages, the gettext infrastructure is used most of the
-time. Most of the time, the translation is handled upstream within
+time. Often the translation is handled upstream within
 projects like the `Free Translation
 Project `__, the
 `GNOME Translation
@@ -51,7 +51,7 @@ Localization `__ project. The only centralized
 resources within Debian are the `Central Debian translation
 statistics `__, where you can find
 some statistics about the translation files found in the actual
-packages, but no real infrastructure to ease the translation process.
+packages and download those files.
 
 Package descriptions have translations since many years and Maintainers
 don't need to do anything special to support translated package
@@ -59,12 +59,9 @@ descriptions; translators should use the `Debian Description Translation
 Project (DDTP) `__.
 
 For ``debconf`` templates, maintainers should use the ``po-debconf``
-package to ease the work of translators, who could

Bug#1042753: nouveau: Screen remains black.

On Monday, 31 July 2023 21:52:44 CEST Olaf Skibbe wrote:
> > Yep, now we know it's a regression between 6.1.27-1 and 6.1.38-2.
> > 
> > https://wiki.debian.org/DebianKernel/GitBisect describes the best way as
> > it would identify the exact (upstream) commit which introduced the
> > problem. If you can do that, great.
> 
> I'd love to contribute here, but I am afraid this would be a bit beyond
> my capabilities. I now have only remote access to the computer in
> question (I have to ask somebody to verify whether the display is
> working) and I am not very experienced. Sorry.

That's ok, I (kind of) expected that a `git bisect` would be too difficult.

That's why I also described a simpler procedure which is specifically meant for 
people who aren't experienced. It will result in a new kernel being build, but 
all the complexity should be hidden for you.
It probably sounds daunting/scary, but it shouldn't be.

There is a subsequent step, but that is (far) more likely to succeed if we'd 
have more detailed data which the above procedure would provide.
So it would be great if you could try it.
If it turns out to be too difficult, don't worry about it :-)

Cheers,
  Diederik

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

Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager

2023-07-31 Thread Mateusz Łukasik


Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : fluxbox
   Version  : 1.3.7-1+nmu1
   Upstream contact : fluxbox maintainers
 * URL  :https://fluxbox.org
 * License  : CC-BY-SA-3, Expat
 * Vcs  : [fill in URL of packaging vcs]
   Section  : x11

The source builds the following binary packages:

  fluxbox - Highly configurable and low resource X11 Window manager

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

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

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

  dget 
-xhttps://mentors.debian.net/debian/pool/main/f/fluxbox/fluxbox_1.3.7-1+nmu1.dsc

Changes since the last upload:

 fluxbox (1.3.7-1+nmu1) unstable; urgency=medium
 .
   * Non-maintainer upload. (See #927477)
   * Upload to unstable, latest upstream version stuck in experimental for
 8 years. (Closes: #969440 #987223)
   * Merge my changes for NMU 1.3.5-2.1. (Closes: #943578)
   * Drop depends on deprecated GTK 2. No longer used. (Closes: #967345)
   * Add debian/patches/fix_ld_ftbfs.patch from upstream for fix FTBFS with
 build-system: fix "make check".
   * Bump dh version to 13.
   * Bump Standards-Version to 4.6.2.
   * Add debian/patches/replace_FbRootWindow_depth_with_maxDepth.patch for
 replace FbRootWindow::depth with maxDepth. (Closes: #1003798)

Regards,
--
  Mateusz Łukasik

Bug#1042777: RFS: vimb/3.7.0-1 [ITP] -- Light-weight webkit-based browser with vim keyboard bindings

2023-07-31 Thread Mateusz Łukasik


Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : vimb
   Version  : 3.7.0-1
   Upstream contact :https://github.com/fanglingsu/vimb/issues
 * URL  :https://fanglingsu.github.io/vimb/
 * License  : CC0-1.0, GPL-3+
 * Vcs  :https://github.com/mati75/vimb
   Section  : misc

The source builds the following binary packages:

  vimb - Light-weight webkit-based browser with vim keyboard bindings

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

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

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

  dget -xhttps://mentors.debian.net/debian/pool/main/v/vimb/vimb_3.7.0-1.dsc

Changes for the initial release:

 vimb (3.7.0-1) unstable; urgency=medium
 .
   * Initial release to Debian. (Closes: #982010)

Regards,
--
  Mateusz Łukasik

Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74

2023-07-31 Thread Adrian Bunk

On Mon, Jun 19, 2023 at 04:37:22PM +0300, Adrian Bunk wrote:
> On Tue, Jun 13, 2023 at 03:30:18PM -0500, Dirk Eddelbuettel wrote:
> > 
> > On 13 June 2023 at 13:15, Steve Langasek wrote:
> > | Control: reassign -1 r-cran-rstan r-cran-bh
> > | Control: found -1 r-cran-rstan/2.21.8-1
> > | 
> > | Unfortunately, at least in Ubuntu it appears the r-cran-rstan build still
> > | exhausts the 32-bit memory space even with boost 1.81.
> > | 
> > |   
> > https://launchpad.net/ubuntu/+source/r-cran-rstan/2.21.8-1/+build/26010118
> > 
> > :-/
> > 
> > Not sure that it is fair to point at BH / Boost though.  Anyway.
> > 
> > CRAN no longer checks / compiles 32 bit so upstream may not care, but they
> > are a good team (if busy).  You could ping Ben, he is at
> >Benjamin K Goodrich 
> >...
> 
> The patch below to r-base fixes the build of r-cran-rstan/i386 for me.
> 
> This will reduce debug info in the R ecosystem on 32bit to what is 
> required for backtraces, but I assume realistically R on 32bit is
> anyway only sparsely used these days.
> 
> > Dirk
> 
> cu
> Adrian
> 
> --- debian/rules.old  2023-06-18 19:45:14.437261923 +
> +++ debian/rules  2023-06-18 19:51:30.097179612 +
> @@ -90,6 +90,11 @@
>  export DEB_CFLAGS_MAINT_APPEND = -ffloat-store
>  endif
>  
> +## fewer debug info on 32bit to workaround 2-4 GB address space limitation
> +ifeq ($(DEB_HOST_ARCH_BITS), 32)
> +export DEB_CFLAGS_MAINT_APPEND += -g1
> +endif
> +
>...

These two entries ended up in the opposite order in the upload, and the 
-ffloat-store one did not have a += making the -g1 change a nop on i386.

Please apply also the patch below.

cu
Adrian

--- debian/rules.old2023-07-26 07:56:06.872438302 +
+++ debian/rules2023-07-26 07:56:27.340457680 +
@@ -92,7 +92,7 @@
 
 ## Adrian Bunk 20 Jan 2023  workaround excess precision of x87
 ifneq (,$(filter $(DEB_HOST_ARCH), i386))
-export DEB_CFLAGS_MAINT_APPEND = -ffloat-store
+export DEB_CFLAGS_MAINT_APPEND += -ffloat-store
 endif
 
 ## edd 31 Mar 2014

Bug#1040897: successor to trumpetti.atm.tut.fi

2023-07-31 Thread Julien Cristau

Hi Aleksi,

FTP Admins  can probably set you up with push
triggers.  Otherwise, the latest ftpsync versions come with a wrapper
script called ftpsync-cron, which is intended to be run out of cron
every hour or so (at a randomish offset).  The script monitors your
upstream mirror, and if there was an update triggers a full sync using
ftpsync.  You might want to give it a try.

Regarding HTTPS, feel free to set it up for non-debian.org names, that's
generally a good idea.

Thanks,
Julien

On Mon, Jul 17, 2023 at 01:31:53PM +0300, Debian Mirror at TREX wrote:
> Hi,
> 
> The Tampere University of Technology hosted ftp.fi.debian.org for a long
> time. I was also involved with it, but close to a decade ago the university
> decided to discontinue the service. I've been looking for somewhere to host
> its replacement, and this debian.web.trex.fi is finally it.
> 
> In other words, once the mirror is accepted, I'd like to ask you to point
> ftp.fi.debian.org at it. I've already configured the name as a ServerAlias.
> 
> Right now I'm running ftpsync every four hours, which I realise is
> suboptimal. Who do I contact for push trigger config? Someone at
> mirror.accum.se aka ftp.acc.umu.se?
> 
> What is the current HTTPS policy? Should I configure certbot to fetch Let's
> Encrypt certificates for the mirror's vhosts?
> 
> Best Regards,
> 
> -- 
>   +358 44 9756548 / http://www.trex.fi/
>   Aleksi Suhonen / TREX Regional Exchanges Oy
> 
>   You say "potato", I say "closest-exit."

Bug#1028953: mirror submission for deb.holownych.com

2023-07-31 Thread mike

The other one is actually the correct one. I couldn't find a way to cancel this entry.Thanks,MikeSent from Outlook for Android

Bug#1042753: nouveau: Screen remains black.

2023-07-31 Thread Olaf Skibbe


On Mon, 31 Jul 2023 at 20:28, Diederik de Haas wrote:


On Monday, 31 July 2023 18:20:12 CEST Olaf Skibbe wrote:


I installed 6.1.0-9-amd64 now from the standard repositories and
graphics works. Hope this is sufficient to narrow it down


Yep, now we know it's a regression between 6.1.27-1 and 6.1.38-2.

https://wiki.debian.org/DebianKernel/GitBisect describes the best way as it
would identify the exact (upstream) commit which introduced the problem.
If you can do that, great.


I'd love to contribute here, but I am afraid this would be a bit beyond 
my capabilities. I now have only remote access to the computer in 
question (I have to ask somebody to verify whether the display is 
working) and I am not very experienced. Sorry.


Cheers,
Olaf

Bug#1042759:



It seems to be kernel and my hardware related
My hardware setup is:

> > 00:02.0 VGA compatible controller: Intel Corporation CometLake-S
> > GT2
> > [UHD Graphics 630] (rev 05)
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GP108
> > [GeForce
> > GT 1030] (rev a1)
> > 
And I've been running kernel 5.13.0 which worked fine for me in
bullseye.

I haven't been switching to the 6.1 which comes with Bookworm, as I
preffered to stick to the kernel tailored to my needs.

I had the feeling that switching to the 6.1 that comes with distro may
bring some more perspective. And indeed, my NVidia monitor is dark., I
have to take care of the drivers (5.13.0 used nouveau module).

I've managed to run Debian on two screens with integrated GPU, and the
bug is gone. I suspect the problem lays somewhere in between the (old)
kernel drivers and the Debian libraries.

What I am gonna do is to setup NVidia driver for 6.1 kernel and get
back with the results.

Below is a full backtrace with symbols:


> > 00:02.0 VGA compatible controller: Intel Corporation CometLake-S
> > GT2
> > [UHD Graphics 630] (rev 05)
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GP108
> > [GeForce
> > GT 1030] (rev a1)
> > 
> > (gdb) bt
> > #0 0x767f50a4 in _XGetRequest
> >  (dpy=dpy@entry=0x55f9d780, type=type@entry=3 '\003',
> > len=len@entry=8)
> >  at ../../src/XlibInt.c:1805
> > #1 0x767d8872 in _XGetWindowAttributes
> >  (dpy=dpy@entry=0x55f9d780, w=w@entry=93825040931984,
> > attr=attr@entry=0x7fffb870) at ../../src/GetWAttrs.c:101
> > #2 0x767d8a59 in XGetWindowAttributes
> >  (dpy=dpy@entry=0x55f9d780, w=w@entry=93825040931984,
> > attr=attr@entry=0x7fffb870) at ../../src/GetWAttrs.c:150
> > #3 0x7312b467 in widget_get_origin
> >  (widget=, x=0x55eb0718, y=0x55eb071c)
> >  at
> > ./extras/immodules/client-gtk/gtk4/scim-bridge-client-imcontext-
> > gtk.c
> > :185
> > #4 0x775b9fb9 in gtk_im_multicontext_set_delegate
> >  (multicontext=multicontext@entry=0x55b83140
> > [GtkIMMulticontext], delegate=delegate@entry=0x55eb06a0
> > [ScimBridgeClientIMContext], finalizing=finalizing@entry=0) at
> > ../../../gtk/gtkimmulticontext.c:247
> > #5 0x775ba0ef in gtk_im_multicontext_get_delegate
> >  (multicontext=multicontext@entry=0x55b83140
> > [GtkIMMulticontext])
> >  at ../../../gtk/gtkimmulticontext.c:291
> > #6 0x775ba695 in gtk_im_multicontext_set_client_widget
> >  (context=, widget=0x55a528c0 [GtkText])
> >  at ../../../gtk/gtkimmulticontext.c:340
> > --Type  for more, q to quit, c to continue without paging--c
> > #7 0x77684416 in gtk_text_realize (widget=0x55a528c0
> > [GtkText])
> >  at ../../../gtk/gtktext.c:2200
> > #8 0x771d95a9 in _g_closure_invoke_va
> >  (closure=closure@entry=0x55823b80,
> > return_value=return_value@entry=0x0,
> > instance=instance@entry=0x55a528c0,
> > args=args@entry=0x7fffbbc0, n_params=0, param_types=0x0) at
> > ../../../gobject/gclosure.c:895
> > #9 0x771f2bbf in g_signal_emit_valist
> >  (instance=0x55a528c0, signal_id=144, detail=,
> > var_args=var_args@entry=0x7fffbbc0) at
> > ../../../gobject/gsignal.c:3456
> > #10 0x771f2dbf in g_signal_emit
> >  (instance=instance@entry=0x55a528c0, signal_id= > out>, detail=detail@entry=0) at ../../../gobject/gsignal.c:3606
> > #11 0x77710ff0 in gtk_widget_realize (widget=0x55a528c0
> > [GtkText])
> >  at ../../../gtk/gtkwidget.c:3411
> > #12 0x777111b8 in gtk_widget_map
> >  (widget=widget@entry=0x55a528c0 [GtkText])
> >  at ../../../gtk/gtkwidget.c:2826
> > #13 0x77711257 in gtk_widget_real_map (widget= > out>)
> >  at ../../../gtk/gtkwidget.c:7615
> > #14 0x771d94e0 in _g_closure_invoke_va
> >  (closure=closure@entry=0x55825d80,
> > return_value=return_value@entry=0x0,
> > instance=instance@entry=0x55b1c4d0,
> > args=args@entry=0x7fffbee0, n_params=0, param_types=0x0) at
> > ../../../gobject/gclosure.c:895
> > #15 0x771f2bbf in g_signal_emit_valist
> >  (instance=0x55b1c4d0, signal_id=142, detail=,
> > var_args=var_args@entry=0x7fffbee0) at
> > ../../../gobject/gsignal.c:3456
> > #16 0x771f2dbf in g_signal_emit
> >  (instance=instance@entry=0x55b1c4d0, signal_id= > out>, detail=detail@entry=0) at ../../../gobject/gsignal.c:3606
> > #17 0x77711136 in gtk_widget_map
> >  (widget=widget@entry=0x55b1c4d0 [NautilusQueryEditor])
> >  at ../../../gtk/gtkwidget.c:2828
> > #18 0x77711257 in gtk_widget_real_map (widget= > out>)
> >  at ../../../gtk/gtkwidget.c:7615
> > #19 0x771d95a9 in _g_closure_invoke_va
> >  (closure=closure@entry=0x55825d80,
> > return_value=return_value@entry=0x0,
> > instance=instance@entry=0x55957210,
> > args=args@entry=0x7fffc1e0, n_params=0, param_types=0x0) at
> > ../../../gobject/gclosure.c:895
> > #20 0x771f2bbf in g_signal_emit_valist
> >  (insta

Bug#1042776: r-bioc-deseq: still depends on obsolete r-api-bioc-3.16

2023-07-31 Thread Andreas Beckmann

Package: r-bioc-deseq
Version: 1.39.0-11
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

  The following packages have unmet dependencies:
   r-bioc-deseq : Depends: r-api-bioc-3.16 but it is not installable

Even after a rebuild in sid the package keeps the dependency on the
obsolete api.

./DESCRIPTION contains `git_branch: RELEASE_3_16` - is this the location
where the version is hardcoded?


Cheers,

Andreas

Bug#1041349: transition: linphone-stack

2023-07-31 Thread Sebastian Ramacher

On 2023-07-31 21:31:37 +0200, Bernhard Schmidt wrote:
> Am 31.07.23 um 21:25 schrieb Sebastian Ramacher:
> > Hi
> > 
> > On 2023-07-30 11:09:08 +0200, Bernhard Schmidt wrote:
> > > We need a rebuild of src:libosmo-abis against the new version of libortp 
> > > and
> > > trx will be removed, see Bug#1026042
> > 
> > Why is the rebuild of libosmo-abis required?
> 
> https://tracker.debian.org/pkg/ortp
> 
> migrating libortp16/1:5.2.0-2/amd64 to testing makes
> libosmotrau2/1.3.0-2+b1/amd64 uninstallable

Scheduled

> 
> linphone-stack upstream does not really support mixing the branches of the
> various libraries, so we don't use symbols and generate shlis dependencies
> like this
> 
> libortp16 (>= 1:5.1.64), libortp16 (<< 1:5.2.0)
> 
> and for the new version of libortp
> 
> libortp16 (>= 1:5.2.0-1), libortp16 (<< 1:5.3.0-1)
> 
> BTW, the RM bug for src:trx is Bug#1042534

Removal hint added for testing.

Cheers
-- 
Sebastian Ramacher

Bug#1042005: transition: mumps hypre2.28.0 superlu combblas

2023-07-31 Thread Sebastian Ramacher

Control: tags -1 confirmed

On 2023-07-25 16:48:02 +0200, Drew Parsons wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: mu...@packages.debian.org, debian-scie...@lists.debian.org
> Control: affects -1 + src:mumps
> 
> I'd like clear out some transitions in the numerical library stack:
> 
> combblas:  1.16.0 → 2.0.0
> superlu:5 → 6
> hypre: 2.26.0 → 2.28.0
> mumps:5.5 → 5.6

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1041349: transition: linphone-stack

2023-07-31 Thread Bernhard Schmidt


Am 31.07.23 um 21:25 schrieb Sebastian Ramacher:

Hi

On 2023-07-30 11:09:08 +0200, Bernhard Schmidt wrote:

We need a rebuild of src:libosmo-abis against the new version of libortp and
trx will be removed, see Bug#1026042


Why is the rebuild of libosmo-abis required?


https://tracker.debian.org/pkg/ortp

migrating libortp16/1:5.2.0-2/amd64 to testing makes 
libosmotrau2/1.3.0-2+b1/amd64 uninstallable


linphone-stack upstream does not really support mixing the branches of 
the various libraries, so we don't use symbols and generate shlis 
dependencies like this


libortp16 (>= 1:5.1.64), libortp16 (<< 1:5.2.0)

and for the new version of libortp

libortp16 (>= 1:5.2.0-1), libortp16 (<< 1:5.3.0-1)

BTW, the RM bug for src:trx is Bug#1042534

Bernhard

Bug#1041349: transition: linphone-stack

2023-07-31 Thread Sebastian Ramacher

Hi

On 2023-07-30 11:09:08 +0200, Bernhard Schmidt wrote:
> We need a rebuild of src:libosmo-abis against the new version of libortp and
> trx will be removed, see Bug#1026042

Why is the rebuild of libosmo-abis required?

Cheers
-- 
Sebastian Ramacher

Bug#967567: libayatana-appindicator: depends on deprecated GTK 2


I have uploaded libayatana-appindicator_0.5.92-1.1.debdiff as NMU to DELAYED/10.

Bug#1042374: linux-image-6.1.0-0.deb11.9-amd64: The module radeon is unstable, the system reboots often infinitively

2023-07-31 Thread rpnpif


Hi,
Some details.

I have never seen this issue starting after displaying the BIOS screen 
which is graphic with mouse. Then Debian works fine.


Linux Mint Live on a USB key works always fine.

It is the same, after a session of Linux Mint Live, I reboot the machine 
then Debian works fine.


I think that the Radeon GPU keeps some settings after the BIOS session 
or the Linux Mint session and work fine until a poweroff.


So i think that the module Radeon (or the firmware) has not the good 
parameters when it is launched directly by Debian. It is a simple guess.


modeset=0 works fine but with a very bad resolution not usable.
modeset=1 or auto has this bug since some weeks even I launches startx. 
This settings has been working well for years with Debian Bullseye.


What's strange is that the mouse doesn't work on the next startup after 
the last not wanted reboot. But the next succeeded reboot after a bad, 
the mouse works fine. It work as some register does not reset on boot 
but a poweroff.


--
Rpnpif

Bug#1042759: Backtrace with symbols



Indeed, running an application not stripped with symbols provides much
more info :)
Here's the backtrace from gdb, it crashes on clicking the magnifyier
icon:

> (gdb) run
> Starting program: /usr/bin/nautilus 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-
> gnu/libthread_db.so.1".
> [New Thread 0x72fe66c0 (LWP 51580)]
> [New Thread 0x727e56c0 (LWP 51581)]
> [New Thread 0x71fe46c0 (LWP 51583)]
> [New Thread 0x717656c0 (LWP 51584)]
> [New Thread 0x70f646c0 (LWP 51585)]
> [New Thread 0x7fffdbfff6c0 (LWP 51586)]
> ** Message: 20:53:02.808: Connecting to
> org.freedesktop.Tracker3.Miner.Files
> [New Thread 0x7fffdb7fe6c0 (LWP 51587)]
> [Detaching after vfork from child process 51588]
> [Thread 0x7fffdb7fe6c0 (LWP 51587) exited]
> [New Thread 0x7fffdb7fe6c0 (LWP 51590)]
> [New Thread 0x7fffdabb76c0 (LWP 51592)]
> [New Thread 0x7fffda3b66c0 (LWP 51593)]
> [Thread 0x7fffdabb76c0 (LWP 51592) exited]
> [Thread 0x7fffda3b66c0 (LWP 51593) exited]
> [New Thread 0x7fffda3b66c0 (LWP 51594)]
> [New Thread 0x7fffdabb76c0 (LWP 51595)]
> [New Thread 0x7fffd8a7e6c0 (LWP 51596)]
> [New Thread 0x7fffc4d486c0 (LWP 51597)]
> [New Thread 0x7fffaf96c6c0 (LWP 51598)]
> [New Thread 0x7fffaf16b6c0 (LWP 51599)]
> [New Thread 0x7fffae96a6c0 (LWP 51600)]
> [New Thread 0x7fffae1696c0 (LWP 51601)]
> [New Thread 0x7fffad9686c0 (LWP 51602)]
> [New Thread 0x7fffad1676c0 (LWP 51603)]
> [New Thread 0x7fffac9666c0 (LWP 51604)]
> [New Thread 0x7fff86c0 (LWP 51605)]
> [New Thread 0x7fff8f7fe6c0 (LWP 51606)]
> [New Thread 0x7fff8effd6c0 (LWP 51607)]
> [New Thread 0x7fff8e7fc6c0 (LWP 51608)]
> [New Thread 0x7fff8dffb6c0 (LWP 51609)]
> [New Thread 0x7fff8d7fa6c0 (LWP 51610)]
> [New Thread 0x7fff8cff96c0 (LWP 51611)]
> [New Thread 0x7fff6bfff6c0 (LWP 51616)]
> [New Thread 0x7fff6b7fe6c0 (LWP 51617)]
> [New Thread 0x7fff6affd6c0 (LWP 51618)]
> [New Thread 0x7fff6a7fc6c0 (LWP 51621)]
> [New Thread 0x7fff69ffb6c0 (LWP 51622)]
> [Thread 0x7fff6a7fc6c0 (LWP 51621) exited]
> [Thread 0x7fff69ffb6c0 (LWP 51622) exited]
> [Thread 0x70f646c0 (LWP 51585) exited]
> [Thread 0x7fffdbfff6c0 (LWP 51586) exited]
> [Thread 0x717656c0 (LWP 51584) exited]
> [Thread 0x7fff6affd6c0 (LWP 51618) exited]
> [Thread 0x7fff6b7fe6c0 (LWP 51617) exited]
> 
> (org.gnome.Nautilus:51577): GLib-GObject-WARNING **: 20:53:04.844:
> invalid cast from 'GdkWaylandToplevel' to 'GdkX11Surface'
> 
> (org.gnome.Nautilus:51577): GLib-GObject-WARNING **: 20:53:04.844:
> invalid cast from 'GdkWaylandDisplay' to 'GdkX11Display'
> 
> Thread 1 "nautilus" received signal SIGSEGV, Segmentation fault.
> 0x767dba49 in XGetWindowAttributes () from /lib/x86_64-linux-
> gnu/libX11.so.6
> (gdb) bt
> #0  0x767dba49 in XGetWindowAttributes () at /lib/x86_64-
> linux-gnu/libX11.so.6
> #1  0x7070d467 in  () at /usr/lib/x86_64-linux-gnu/gtk-
> 4.0/4.0.0/immodules/libim-scim.so
> #2  0x777b7fb9 in  () at /lib/x86_64-linux-gnu/libgtk-4.so.1
> #3  0x777b80ef in  () at /lib/x86_64-linux-gnu/libgtk-4.so.1
> #4  0x777b8695 in  () at /lib/x86_64-linux-gnu/libgtk-4.so.1
> #5  0x77882416 in  () at /lib/x86_64-linux-gnu/libgtk-4.so.1
> #6  0x7721a5a9 in  () at /lib/x86_64-linux-gnu/libgobject-
> 2.0.so.0
> #7  0x77233bbf in g_signal_emit_valist () at /lib/x86_64-
> linux-gnu/libgobject-2.0.so.0
> #8  0x77233dbf in g_signal_emit () at /lib/x86_64-linux-
> gnu/libgobject-2.0.so.0
> #9  0x7790eff0 in gtk_widget_realize () at /lib/x86_64-linux-
> gnu/libgtk-4.so.1
> #10 0x7790f1b8 in gtk_widget_map () at /lib/x86_64-linux-
> gnu/libgtk-4.so.1
> #11 0x7790f257 in  () at /lib/x86_64-linux-gnu/libgtk-4.so.1
> #12 0x7721a4e0 in  () at /lib/x86_64-linux-gnu/libgobject-
> 2.0.so.0
> #13 0x77233bbf in g_signal_emit_valist () at /lib/x86_64-
> linux-gnu/libgobject-2.0.so.0
> #14 0x77233dbf in g_signal_emit () at /lib/x86_64-linux-
> gnu/libgobject-2.0.so.0
> #15 0x7790f136 in gtk_widget_map () at /lib/x86_64-linux-
> gnu/libgtk-4.so.1
> #16 0x7790f257 in  () at /lib/x86_64-linux-gnu/libgtk-4.so.1
> #17 0x7721a5a9 in  () at /lib/x86_64-linux-gnu/libgobject-
> 2.0.so.0
> #18 0x77233bbf in g_signal_emit_valist () at /lib/x86_64-
> linux-gnu/libgobject-2.0.so.0
> #19 0x77233dbf in g_signal_emit () at /lib/x86_64-linux-
> gnu/libgobject-2.0.so.0
> #20 0x7790f136 in gtk_widget_map () at /lib/x86_64-linux-
> gnu/libgtk-4.so.1
> #21 0x7790f458 in gtk_widget_set_child_visible () at
> /lib/x86_64-linux-gnu/libgtk-4.so.1
> #22 0x7786c98b in  () at /lib/x86_64-linux-gnu/libgtk-4.so.1
> #23 0x7721a3b0 in g_closure_invoke () at /lib/x86_64-linux-
> gnu/libgobject-2.0.so.0
> #24 0x7722d076 in  () at /lib/x86_64-linux-gnu/libgobject-
> 2.0.so.0
> #25 0x77233bf5 in g_signal_emit_valist () at /lib/x86_64-
> linux-gnu/libgobject-2.0.so.0
> #26 0x7

Bug#1022034: Now fails to start on Debian 12

2023-07-31 Thread Henrik Riomar

Seems this was not fixed in time for Debian 12, and now it fails to start
on Debian12:

Jul 31 18:42:12 mailserv policyd-rate-limit[565]: Traceback (most recent
call last):
Jul 31 18:42:12 mailserv policyd-rate-limit[565]:   File
"/usr/bin/policyd-rate-limit", line 36, in 
Jul 31 18:42:12 mailserv policyd-rate-limit[565]: config.setup()
Jul 31 18:42:12 mailserv policyd-rate-limit[565]:   File
"/usr/lib/python3/dist-packages/policyd_rate_limit/utils.py", line 144, in
setup
Jul 31 18:42:12 mailserv policyd-rate-limit[565]: self._config =
Config(config_file)
Jul 31 18:42:12 mailserv policyd-rate-limit[565]:
   ^^^
Jul 31 18:42:12 mailserv policyd-rate-limit[565]:   File
"/usr/lib/python3/dist-packages/policyd_rate_limit/utils.py", line 88, in
__init__
Jul 31 18:42:12 mailserv policyd-rate-limit[565]: self._config =
yaml.load(f)
Jul 31 18:42:12 mailserv policyd-rate-limit[565]:
   
Jul 31 18:42:12 mailserv policyd-rate-limit[565]: TypeError: load() missing
1 required positional argument: 'Loader'
Jul 31 18:42:12 mailserv systemd[1]: policyd-rate-limit.service: Main
process exited, code=exited, status=1/FAILURE

Upstream fix commit:
https://github.com/nitmir/policyd-rate-limit/commit/6c155a633bf5e9986304b1ca009a4716846e66f9

Upstream bug report:
https://github.com/nitmir/policyd-rate-limit/issues/15

Bug#1042759: nautilus: Segfault on clicking at 'Find' button

2023-07-31 Thread Simon McVittie

Control: tags -1 + moreinfo

On Mon, 31 Jul 2023 at 15:02:28 +0200, Michal Byrecki wrote:
> (org.gnome.Nautilus:36400): GLib-GObject-WARNING **: 14:58:48.769: invalid 
> cast
> from 'GdkWaylandToplevel' to 'GdkX11Surface'

nautilus and gnome-calculator are working fine for me in a Wayland
environment, without a similar warning, and without needing
GDK_BACKEND=x11.

Do you have any LD_PRELOAD modules or other plugins that are injecting
additional code into processes in your session?

Please try running nautilus (or another affected program) with
G_DEBUG=fatal-warnings in the environment (which will turn this warning
into a crash that can be debugged), and use either gdb or systemd-coredump
to get a backtrace from that crash:
https://wiki.debian.org/HowToGetABacktrace

Thanks,
smcv

Bug#1042753: nouveau: Screen remains black.

On Monday, 31 July 2023 18:20:12 CEST Olaf Skibbe wrote:
> > If there is a 6.1 kernel that does work, then it helps if you can find the
> > latest 6.1 kernel which works and (thus) the first kernel version where it
> > stopped working.
> 
> I installed 6.1.0-9-amd64 now from the standard repositories and
> graphics works. Hope this is sufficient to narrow it down

Yep, now we know it's a regression between 6.1.27-1 and 6.1.38-2.

https://wiki.debian.org/DebianKernel/GitBisect describes the best way as it
would identify the exact (upstream) commit which introduced the problem.
If you can do that, great.

If not, we can try to make an educated guess
me@pc:~/dev/kernel.org/linux$ git log --oneline v6.1.27..v6.1.38 -- 
drivers/gpu/drm/nouveau/
62aecf23f3d1 drm/nouveau: add nv_encoder pointer check for NULL
fb725beca62d drm/nouveau/dp: check for NULL nv_connector->native_mode
90748be0f4f3 drm/nouveau: don't detect DSM for non-NVIDIA device
5a144bad3e75 nouveau: fix client work fence deletion race

This is the list of commits to the nouveau driver between those versions.
I've attached 4 patches created with `git revert `

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
describes a procedure for "Simple patching and building" and the idea is to
pass these 4 patches as argument to `test-patches`.
The idea is to build a new 6.1.38 kernel, but with the 4 above mentioned
commits reverted and then boot into your new kernel and see if that resolves
the issue (too). If that's the case, then it's 1 of those 4 commits that's
causing the problem. Ideally that would be reduced to 1 specific patch, but
there isn't one that jumps out for me.

@Ben/Salvatore (=actual Debian kernel maintainers):
Did I describe it correctly? And does `test-patches` need to be run when
booted into the 6.1.38 kernel or does that not matter?
Does 1 of those 4 patches/commits stand out for you as the most likely cause?

Cheers,
  Diederik>From ffd112759014915ce769cb37ed1ce6e3184dde2a Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Mon, 31 Jul 2023 19:55:33 +0200
Subject: [PATCH 1/4] Revert "drm/nouveau: add nv_encoder pointer check for
 NULL"

This reverts commit 62aecf23f3d12f0a1b170bfd2174fd58d0d1bf50.
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index f40310559d13..fd984733b8e6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -730,8 +730,7 @@ nouveau_connector_detect_lvds(struct drm_connector *connector, bool force)
 #endif
 
 	nouveau_connector_set_edid(nv_connector, edid);
-	if (nv_encoder)
-		nouveau_connector_set_encoder(connector, nv_encoder);
+	nouveau_connector_set_encoder(connector, nv_encoder);
 	return status;
 }
 
-- 
2.40.1

>From 47c0e938beef7335ffa179f1006754f9664c6c4d Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Mon, 31 Jul 2023 19:55:54 +0200
Subject: [PATCH 2/4] Revert "drm/nouveau/dp: check for NULL
 nv_connector->native_mode"

This reverts commit fb725beca62d175c02ca619c27037c14f7ab8e7c.
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index fd984733b8e6..1991bbb1d05c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -966,7 +966,7 @@ nouveau_connector_get_modes(struct drm_connector *connector)
 	/* Determine display colour depth for everything except LVDS now,
 	 * DP requires this before mode_valid() is called.
 	 */
-	if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS && nv_connector->native_mode)
+	if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS)
 		nouveau_connector_detect_depth(connector);
 
 	/* Find the native mode if this is a digital panel, if we didn't
@@ -987,7 +987,7 @@ nouveau_connector_get_modes(struct drm_connector *connector)
 	 * "native" mode as some VBIOS tables require us to use the
 	 * pixel clock as part of the lookup...
 	 */
-	if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS && nv_connector->native_mode)
+	if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS)
 		nouveau_connector_detect_depth(connector);
 
 	if (nv_encoder->dcb->type == DCB_OUTPUT_TV)
-- 
2.40.1

>From 07a2576f9fb4bb3ebb93593a4831b092105e622e Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Mon, 31 Jul 2023 19:56:12 +0200
Subject: [PATCH 3/4] Revert "drm/nouveau: don't detect DSM for non-NVIDIA
 device"

This reverts commit 90748be0f4f386ad3143cd7538ef37647e1f6260.
---
 drivers/gpu/drm/nouveau/nouveau_acpi.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index a2ae8c21e4dc..8cf096f841a9 100644
--- a/drivers/gpu/drm/nouveau/nouv

Bug#1042398: debhelper: should disable Python byte-compilation when building .deb with Meson

2023-07-31 Thread Adrian Bunk

On Fri, Jul 28, 2023 at 02:11:54PM +0200, Niels Thykier wrote:
> Jussi Pakkanen:
> > On Thu, 27 Jul 2023 at 17:45, Simon McVittie  wrote:
>...
> > > Is there a way this can be done, without making packages FTBFS if 
> > > debhelper
> > > is backported to an older suite but Meson is not? -Dpython.bytecompile=-1
> > > will cause `meson setup` to fail if Meson is an older version, and I'm not
> > > aware of a way to say "set this option if supported, ignore if not" 
> > > without
> > > parsing `meson --version` and comparing it with a threshold.
> > 
> > Is there ever a case where debhelper would be backported byt Meson is
> > not? Now an expert but Meson sees a fair number of backports so I'd
> > imagine it to be the more up to date of the two packages.
> > 
> 
> If we can rely on meson in stable(-backports) having the feature, a simple
> Breaks in debhelper + unconditional use in the parameter is how I would go
> about it if we need to change debhelper
>...

In this case Breaks would be required in both directions, otherwise a 
build dependency on a new meson might result in using new meson and old 
debhelper in backports.

> Best regards,
> Niels

cu
Adrian

Bug#1042775: r-cran-stringi: fails being loaded in R

2023-07-31 Thread Martin Weiser

Package: r-cran-stringi
Version: 1.7.12-1
Severity: important
X-Debbugs-Cc: martin.wei...@natur.cuni.cz

Dear Maintainer,

I cannot load package "r-cran-stringi" from my R session.
Within an R session, issue:
 library("stringi") 

The R responds: 
Error: package or namespace load failed for ‘stringi’ in dyn.load(file, DLLpath 
= DLLpath, ...):
 unable to load shared object 
'/usr/local/lib/R/site-library/stringi/libs/stringi.so':
  libicui18n.so.67: cannot open shared object file: No such file or directory

My R session info:

> sessionInfo()
R version 4.2.2 Patched (2022-11-10 r83330)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 12 (bookworm)

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.11.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.11.0

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C  
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C 
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C   

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 

loaded via a namespace (and not attached):
[1] compiler_4.2.2 tools_4.2.2   

My .libPaths():

[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"  
[3] "/usr/lib/R/library" 

With Bookworm, I have:
apt-file search libicui18n.so:

libicu-dev: /usr/lib/x86_64-linux-gnu/libicui18n.so
libicu72: /usr/lib/x86_64-linux-gnu/libicui18n.so.72
libicu72: /usr/lib/x86_64-linux-gnu/libicui18n.so.72.1

I installed all packages (both R and system) using apt.

Although I would be happy to help, I have not solved
 the problem (loading the "stringi" package) myself yet...
 
Thank you for your consideration.

With regards,

Martin Weiser

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

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

Versions of packages r-cran-stringi depends on:
ii  libc62.36-9+deb12u1
ii  libgcc-s112.2.0-14
ii  libicu72 72.1-3
ii  libstdc++6   12.2.0-14
ii  r-base-core [r-api-4.0]  4.2.2.20221110-2

r-cran-stringi recommends no packages.

r-cran-stringi suggests no packages.

-- no debconf information

Bug#1042774: ITP: python3-grequests -- asynchronous Web Scraping With Python

2023-07-31 Thread Guilherme de Paula Xavier Segundo

Package: wnpp
Severity: wishlist
Owner: Guilherme de Paula Xavier Segundo 
X-Debbugs-Cc: debian-de...@lists.debian.org,debian-pyt...@lists.debian.org, 
guilherme@gmail.com

* Package name: python3-grequests
  Version : 0.7.0
  Upstream Contact: Kenneth Reitz 
* URL : https://github.com/spyoungtech/grequests
* License : BSD
  Programming Lang: Python
  Description : asynchronous Web Scraping With Python

 This package allows you to use Requests with Gevent to make asynchronous HTTP
 Requests easily.
 .
 Simple but effective way to create multiple http requests in Python allowing
 to scrape faster.
 .
 The HTTP verb methods in grequests (e.g., grequests.get, grequests.post, etc.)
 accept all the same keyword arguments as in the requests library.

Bug#1042759: I've found a way to run nautilus

I've found a solution to run either nautilus or gnome calculator by
invoking:
GDK_BACKEND=x11 
Cheers
Mike

Bug#1042759: Yet another app with similar problem

Howdy,
I've just found another app with a same problem: gnome-calculator. 
At a first glance it looks like some library inconsistency...
Here's the strace output for gnome-calculator:
> futex(0x7f6e479b7fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> ioctl(2, TCGETS, {c_iflag=ICRNL|IXON|IUTF8,
> c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR,
> c_cflag=B38400|CS8|CREAD,
> c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
> getpid()= 43011
> openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 17
> newfstatat(17, "", {st_mode=S_IFREG|0644, st_size=2654, ...},
> AT_EMPTY_PATH) = 0
> newfstatat(17, "", {st_mode=S_IFREG|0644, st_size=2654, ...},
> AT_EMPTY_PATH) = 0
> read(17,
> "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\v\0\0\0\v\0\0\0\0"...,
> 4096) = 2654
> lseek(17, -1671, SEEK_CUR)  = 983
> read(17,
> "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\v\0\0\0\v\0\0\0\0"...,
> 4096) = 1671
> close(17)   = 0
> write(2, "\n(gnome-calculator:43011): GLib-"..., 144
> (gnome-calculator:43011): GLib-GObject-WARNING **: 19:49:21.756:
> invalid cast from 'GdkWaylandToplevel' to 'GdkX11Surface'
> ) = 144
> ioctl(2, TCGETS, {c_iflag=ICRNL|IXON|IUTF8,
> c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR,
> c_cflag=B38400|CS8|CREAD,
> c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}) = 0
> getpid()= 43011
> newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644,
> st_size=2654, ...}, 0) = 0
> write(2, "\n(gnome-calculator:43011): GLib-"..., 143
> (gnome-calculator:43011): GLib-GObject-WARNING **: 19:49:21.756:
> invalid cast from 'GdkWaylandDisplay' to 'GdkX11Display'
> ) = 143
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
> +++ killed by SIGSEGV +++
>

Bug#1042562: libc6: broken utmp handling in 32-bit programs with 64-bit time_t

2023-07-31 Thread Sven Joachim

Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=30701

On 2023-07-30 13:25 +0200, Sven Joachim wrote:

> Package: libc6
> Version: 2.37-6
> Tags: upstream
>
> The utmp(5) interface has broken its compatibility in 32-bit programs
> built with -D_TIME_BITS=64.  In bits/utmpx.h we see this:
>
> ,
> | /* The fields ut_session and ut_tv must be the same size when compiled
> |32- and 64-bit.  This allows files and shared memory to be shared
> |between 32- and 64-bit applications.  */
> | #if __WORDSIZE_TIME64_COMPAT32
> |   __int32_t ut_session; /* Session ID, used for windowing.  */
> |   struct
> |   {
> | __int32_t tv_sec;   /* Seconds.  */
> | __int32_t tv_usec;  /* Microseconds.  */
> |   } ut_tv;  /* Time entry was made.  */
> | #else
> |   long int ut_session;  /* Session ID, used for windowing.  */
> |   struct timeval ut_tv; /* Time entry was made.  */
> | #endif
> `
>
> The definition of __WORDSIZE_TIME64_COMPAT32 can be found in bits/wordsize.h:
>
> ,
> | #ifdef __x86_64__
> | # define __WORDSIZE_TIME64_COMPAT32 1
> | /* Both x86-64 and x32 use the 64-bit system call interface.  */
> | # define __SYSCALL_WORDSIZE 64
> | #else
> | # define __WORDSIZE_TIME64_COMPAT32 0
> | #endif
> `
>
> So on i386 (and I suppose on other 32-bit architectures except x32)
> ut_tv is of struct timeval, and ut_tv.tv_sec is of time_t, which is
> actually a 64-bit integer in programs built with -D_TIME_BITS=64.
>
> One example where this already has caused problems is the who(1) program
> which has opted in for -D_TIME_BITS=64, see #1027135.

I had brought the "who" problem to the attention of the coreutils
developers[1], and they have now reported the issue in the Sourceware
Bugzilla.

Cheers,
   Sven


1. https://debbugs.gnu.org/64937

Bug#1042773: util-linux: Please update package relationships with manpages-l10n

2023-07-31 Thread Helge Kreutzmann

Package: util-linux
Version: 2.39.1-3
Severity: minor

Unfortuntely it took me a few revisions to actually filter out all
localized manpages now in util-linux from manpages-l10n.

Hence please update the package relationsships with manpages-l10n to
4.19.0.7 (i.e. the Breaks: and Replaces:)

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


signature.asc
Description: PGP signature

Bug#1042772: O: pam-krb5-migrate -- PAM module for migrating to Heimdal Kerberos

2023-07-31 Thread Dominik George

Package: wnpp
Severity: normal
X-Debbugs-Cc: pam-krb5-migr...@packages.debian.org
Control: affects -1 + src:pam-krb5-migrate

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I intend to orphan the pam-krb5-migrate package.

The package description is:
 A stackable authentication module that takes a username and password from an
 earlier module in the stack and attempts to transparently add the user to a
 Kerberos realm using the Kerberos 5 kadmin service. The module can be used to
 ease the administrative burdens of migrating a large installed userbase from
 pre-existing authentication methods to a Kerberos-based setup.
 .
 This package allows updating the database of a remote Heimdal server.


As I do not rely on Kerberos anymore myself, it is hard for me to spot
issues with the module.
-BEGIN PGP SIGNATURE-

iMAEARYKAGgWIQSk6zxRYJYchegBkTEK5VTlRg4b3QUCZMfyMDEaaHR0cHM6Ly93
d3cuZG9taW5pay1nZW9yZ2UuZGUvZ3BnLXBvbGljeS50eHQuYXNjGBxuYXR1cmVz
aGFkb3dAZGViaWFuLm9yZwAKCRAK5VTlRg4b3YK9AP9Ks4Mh9kFp1TVf6EtRoxYD
eNWJysTXIBE6+IU56kKrwQD/Y1K6xwWEA3riziSm/KqDqhqn5XU0Q51rug0C18Ji
dQA=
=GqUh
-END PGP SIGNATURE-

Bug#1042771: O: gnome-pass-search-provider -- GNOME Shell search provider for the pass password manager

2023-07-31 Thread Dominik George

Package: wnpp
Severity: normal
X-Debbugs-Cc: gnome-pass-search-provi...@packages.debian.org
Control: affects -1 + src:gnome-pass-search-provider

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I intend to orphan the gnome-pass-search-provider package.

The package description is:
 This GNOME search provider integrates the pass utility into GNOME Shell.
 It can search password entries and copy passwords as well as arbitrary
 fields (username, pin, etc.) from the GNOME Shell search frontend. It
 also supports the OTP extension (from the pass-extension-otp package).


As I do not use GNOME anymore, it is hard for me to spot when this package
needs love.

-BEGIN PGP SIGNATURE-

iMAEARYKAGgWIQSk6zxRYJYchegBkTEK5VTlRg4b3QUCZMfw5TEaaHR0cHM6Ly93
d3cuZG9taW5pay1nZW9yZ2UuZGUvZ3BnLXBvbGljeS50eHQuYXNjGBxuYXR1cmVz
aGFkb3dAZGViaWFuLm9yZwAKCRAK5VTlRg4b3UN9AP9PXGhSdhTD39EVf5gpO3lR
x0ofjMVWBxqpImNE5Ue9dwD/SgNMGaikq0hVrAwmgPAyYI5yRI/qkrO8+yYP5+mh
wAM=
=IYSE
-END PGP SIGNATURE-

Bug#1042770: messagingmenu-sharp: depends on deprecated gtk-sharp2


Source: messagingmenu-sharp
Control: block 967477 by -1
Control: block -1 by 967750

This package build-depends on gtk-sharp2-gapi and libgtk2.0-cil-dev.
They are GTK 2 packages and should be removed from Debian.

Please consider removing messagingmenu-sharp which can be done easily 
after its last reverse dependency is gone (see blocking bugs).

Bug#1042755: patch: doesn't respect first EOF

2023-07-31 Thread наб

Control: tags -1 + patch

Trivially found with
(gdb) bt
#0  0x77ec807d in __GI___libc_read (fd=0, buf=0x555862a0, 
nbytes=8192) at ../sysdeps/unix/sysv/linux/read.c:26
#1  0x77e51130 in __GI__IO_file_xsgetn (fp=0x77fa2a80 
<_IO_2_1_stdin_>, data=, n=8192) at ./libio/libioP.h:947
#2  0x77e46625 in __GI__IO_fread (buf=0x555862a0, 
size=size@entry=1, count=8192, fp=fp@entry=0x77fa2a80 <_IO_2_1_stdin_>) at 
./libio/iofread.c:38
#3  0xe2ec in fread (__stream=, __n=, 
__size=1, __ptr=) at 
/usr/include/x86_64-linux-gnu/bits/stdio2.h:297
#4  open_patch_file (filename=) at pch.c:152
#5  0x8bcf in main (argc=, argv=) at 
patch.c:195

│  151  for (st.st_size = 0;   
│  >   152   (charsread = fread (buf, 1, bufsize, read_pfp)) != 0; 
│  153   st.st_size += charsread)  
│  154if (fwrite (buf, 1, charsread, pfp) != charsread)
│  155  write_fatal ();

which needs to check for !feof && (charsread = 

Attaching patch against 2.7.6-7, validated it works.

Best,
наб
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 patch (2.7.6-7) unstable; urgency=medium
 .
   * Backport upstream fixes:
 - avoid invalid memory access in context format diffs,
 - fix failed assertion 'outstate->after_newline'.
   * Update packaging bits.
   * Update Standards-Version to 4.5.1 .
Author: Laszlo Boszormenyi (GCS) 

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2023-07-31

--- patch-2.7.6.orig/src/pch.c
+++ patch-2.7.6/src/pch.c
@@ -149,7 +149,7 @@ open_patch_file (char const *filename)
if (! pfp)
  pfatal ("Can't open stream for file %s", quotearg (TMPPATNAME));
for (st.st_size = 0;
-(charsread = fread (buf, 1, bufsize, read_pfp)) != 0;
+!feof(read_pfp) && (charsread = fread (buf, 1, bufsize, read_pfp)) 
!= 0;
 st.st_size += charsread)
  if (fwrite (buf, 1, charsread, pfp) != charsread)
write_fatal ();


signature.asc
Description: PGP signature

Bug#1042769: provean: incompatible with cd-hit >= 4.8.1-4

2023-07-31 Thread Andrius Merkys


Package: provean
Version: 1.1.5+ds-2
Severity: serious

Hello,

Current provean package is broken: it segfaults while parsing the output 
of cd-hit. The most recent compatible version of cd-hit seems to be 
4.6.4-1. I hope to come up with a patch sooner or later.


Andrius

Bug#452721: [Pkg-xen-devel] Bug#452721: irt: Bug#452721 notes from explorations

2023-07-31 Thread zithro

On 31 Jul 2023 03:39, Elliott Mitchell wrote:

Presently I hope to convince the Xen core to allow full Python in domain
configuration files, but no news on that front so far. This would mean
/etc/default/xendomains would need to change to match Python syntax.

There was an answer today on xen-devel: the ability to use scripts in
domU cfg files has been explicitely removed for various reasons.
This does not prevent you from "source"-ing teh cfg files in your
script(s) if they are proper Python syntax. Or you could simply
parse/regex the values you want.
And as Marek suggested in his answer, you can also put any arbitrary
settings in the comments.

Although ...

My thinking for adding to domain configuration files would be something
along these lines:

init = {
'tool': 'xendomains-ng',
'version': 0,
'order': 9,
'startwait': 60,
'stopaction': 'save',
}

The problem with adding this to a domU config file is that it could
cause problems for (live) migrations. The start/stop order is "per
dom0", and may be different on another one.
Imagine two dom0s, one storing the domain files "locally", while the
other uses NFS. Only in the second case the domU should wait for the NFS
server/domain to be available.

To me, the start/stop logic should be in a dom0 config file.

'startwait' would tell the script to wait that long before starting
subsquent domains.

A time-based wait may be useful for when everything goes well, but what
about when there are problems ?
If you want to be sure a domain is up (ie. ready to serve), you would
need to peek at the related "service".
For example, to be sure a DNS domU is up, you would have to try a DNS
request, as a ping or "xl list" would not be enough.
Also, domains in xen/auto are started with a mix of serialization AND
parallelization, as "xl create" returns once the domain has started (ie.
in the Xen point of view, not the user's).

'stopaction' would allow different actions if the machine was to stop.
The 3 options which come to mind are 'stop' (shutdown), 'save' (save to
specified storage location), and 'migrate'.

Then, each time you do NOT want to follow the usual action, you'd have
to edit -each- domU cfg file ?

If full Python doesn't become available, this might take the format:
init = 'tool=xendomains-ng,version=0,order=9,startwait=60,stopaction=save'
Not needing to parse the string though does make one's life simpler.

Well, it makes -your- life easier, not the maintainers' one ;)

I'm basically certain writing a new xendomains script in Python is the
way to go. Now to get an answer as to whether full Python in domain
configuration files could be reenabled.

I'm not sure a Python script would solve anything, as (ba)sh variables
are imported from other files.
(see for example
https://salsa.debian.org/xen-team/debian-xen/-/blob/master/tools/hotplug/Linux/xendomains.in)

Everything considered, I'm not sure why Xen should provide such
functionnality.
I think custom scripts can handle all the various use cases, don't you
think ?
PS: as mentionned by diederik, the "dependency" logic is already handled
by Qubes since years, and it never made it to Xen (I don't know the
reasons though).

But I agree the shutdown sequence could be adapted to :
1. first shutdown the domains NOT in xen/auto
2. then shutdown the domains in xen/auto, in reverse order

For fine grained start/stop order, maybe having a dom0 config file
handling this could be added, like:

# START/STOP ORDER
# domains not in these lists will be started after and stopped
# before the ones here
start-order=(list of domU names)
stop-order=(list of domU names)

But then again, this only ensures "domains" start order, not "services
availability" in said domains.

--
zithro / Cyril

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

2023-07-31 Thread Sam Hartman

> "Luca" == Luca Boccassi  writes:

>> I consider this proposal to be premature. Policy should document
Luca> current
>> practice, and I do not think this proposal does that.

For what it's worth, I agree with Luca that we are ready for a change to
document that service units need to be included now, and I do not think
a change in this area is premature.
I have not (and probably will not get around to) reviewing the specific
text, but I do think it's time for this change now.

(Some of Simon's comments about the security implications of not being
able to depend on systemd for dbus service activation but instead still
needing to support dbus-daemon launching things itself make me think we
should consider even more sweeping changes soon.)

Bug#1042450: elpa-org: #+LANGUAGE: de-de is not working in LaTeX export

2023-07-31 Thread Nicholas D Steeves

Control: tag -1 moreinfo

Hello,

H.-Dirk Schmitt  writes:

> Package: elpa-org
> Version: 9.6.7+dfsg-1-c42-bpo-1
> Severity: normal
> X-Debbugs-Cc: none, H.-Dirk Schmitt 
>
> I use a backport from sid/trixie below bookworm.
> In difference to the 9.5 version the setting `#+LANGUAGE: de-de` is not 
> working any more.
> The option of the babel LaTeX package is in this case now empty.
>
> An easy mitigation is to use instead `de-de` the `de` language code.

Have you eliminated issues pertaining to the new
org-latex-language-alist?

https://orgmode.org/Changes.html
https://orgmode.org/manual/LaTeX-specific-export-settings.html
https://orgmode.org/worg/org-irc.html

> May somebody please check if this is a backport problem or reproducible in a 
> „clean“ trixie setup.

$ rmadison elpa-org
elpa-org   | 9.1.14+dfsg-3 | oldoldstable | all
elpa-org   | 9.4.0+dfsg-1  | oldstable| all
elpa-org   | 9.5.2+dfsh-5  | stable   | all
elpa-org   | 9.6.7+dfsg-1  | testing  | all
elpa-org   | 9.6.7+dfsg-1  | unstable | all

There are no other supported elpa-org versions in Debian.  Please
provide steps to reproduce (and/or an example file).

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1042768: Stop shipping scripts that don't work with irssi >= 1.4

2023-07-31 Thread Lee Garrett

Source: irssi-scripts
Version: 20220704
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

irssi 1.4 in bookworm ships with a new rendering system compared to 1.2.3 from
bullseye, breaking a few scripts in the process [0]. A list of affected scripts
is listed in the 1.4.1 news entry [1].

I propose to update to the latest irssi-scripts snapshot, and then remove any
remaining scripts still using Irssi::command('^format [...]), and add a news
entry for the next stable-update.

Regards,
Lee


[0] https://irssi.org/posts/#major-news-in-irssi-14-coming-from-irssi-123
grep for "The display system now renders formats on the fly"
[1] https://irssi.org/NEWS/#news-v1-4-1


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

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

Bug#951627: isc-dhcp-server: Can't stop the daemon

2023-07-31 Thread Juanjo Pablos

On Fri, 6 May 2022 16:05:09 +0200 Santiago Ruano 
=?iso-8859-1?Q?Rinc=F3n?=  wrote:

> Control: tags -1 + moreinfo
> Control: notfound -1 4.4.2-P1-1+b1
>
> On Wed, 19 Feb 2020 04:32:13 + Russell Coker 
 wrote:

> > Package: isc-dhcp-server
> > Version: 4.4.1-2.1
> > Severity: important
> >
> > In a fairly default configuration with systemd I can't stop the 
daemon in a

> > normal manner (this happens on Buster as well as Unstable).
> >
> > # /etc/init.d/isc-dhcp-server stop
> > Stopping isc-dhcp-server (via systemctl): isc-dhcp-server.service.
> > (sysadm_t:s0-s0:c0.c1023)root@unstable:/var/log# ps aux|grep dhcp
> > root 841 0.0 1.1 13520 9316 ? Ss 04:27 0:00 /usr/sbin/dhcpd -4 -q 
-cf /etc/dhcp/dhcpd.conf

> > # ls -l /run/dhcpd.pid
> > -rw-r--r--. 1 root root 4 Feb 19 04:27 /run/dhcpd.pid
> >
> > To stop it properly (so it can be restarted again) I have to 
manually kill the

> > process and rm the pid file.
>
> [...]
>
> Thanks for your bug report. However, I am unable to reproduce it
> (running on an lxc container with 4.4.2-P1-1+b1):
>
> root@sid:~# /etc/init.d/isc-dhcp-server start
> Starting isc-dhcp-server (via systemctl): isc-dhcp-server.service.
> root@sid:~# ps -ef | grep dhcpd
> root 1232 1 0 14:00 ? 00:00:00 /usr/sbin/dhcpd -4 -q -cf 
/etc/dhcp/dhcpd.conf eth1

> root 1244 355 0 14:00 pts/5 00:00:00 grep dhcpd
> root@sid:~# /etc/init.d/isc-dhcp-server stop
> Stopping isc-dhcp-server (via systemctl): isc-dhcp-server.service.
> root@sid:~# ps -ef | grep dhcpd
> root 1271 355 0 14:00 pts/5 00:00:00 grep dhcpd
>
> Could you please test the latest version in sid?
>
> Cheers,
>
> -- Santiago

I was hit by this bug.

And I had to add INTERFACES="br0" for the server to stop.

Check the variable

Bug#1042753: nouveau: Screen remains black.

2023-07-31 Thread Olaf Skibbe


On Mon, 31 Jul 2023 at 13:09, Diederik de Haas wrote:


On Monday, 31 July 2023 12:44:07 CEST Olaf Skibbe wrote:


After upgrading to bookworm on a Dell Latitude E6510 with a "NVIDIA 
Corporation GT218M" graphic card, the screen remains black. Also 
switching to a console (Strg-Alt-F2) shows a black screen. Access via 
ssh is possible. When booting to the old kernel, the screen works as 
before.


The old kernel is 5.10.X?


Yes, the kernel referred to as "old" is 5.10.x.

On https://snapshot.debian.org/binary/linux-image-amd64/ you can find 
a whole bunch of older 6.1 kernels. Can you try to see if one of them 
does work? If there is a 6.1 kernel that does work, then it helps if 
you can find the latest 6.1 kernel which works and (thus) the first 
kernel version where it stopped working.


I installed 6.1.0-9-amd64 now from the standard repositories and 
graphics works. Hope this is sufficient to narrow it down, otherwise I'd 
test more kernels. (Would there be a simple way to add the snapshots to 
the repositories?)


Thanks for taking care.

Cheers,
Olaf

Bug#1041307: xtrx-dkms: module fails to build for Linux 6.4: error: too many arguments to function 'class_create'

2023-07-31 Thread Ying-Chun Liu (PaulLiu)


Hi,

Thanks for reporting the bug.
I've made a patch to fix this bug. As attachment.

I plan to do the NMU.
I'll upload to delay/10 queue after 3 days if no one complains.

Yours,
Paul

diff -Nru xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/changelog 
xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/changelog
--- xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/changelog2023-06-24 
04:22:04.0 +0800
+++ xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/changelog2023-08-01 
00:08:42.0 +0800
@@ -1,3 +1,11 @@
+xtrx-dkms (0.0.1+git20190320.5ae3a3e-3.4) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix dkms build failure with kernel 6.4 (Closes: #1041307)
+- add debian/patches/0004-xtrx.c-fix-build-error-with-kernel-6.4.patch
+
+ -- Ying-Chun Liu (PaulLiu)   Tue, 01 Aug 2023 00:08:42 
+0800
+
 xtrx-dkms (0.0.1+git20190320.5ae3a3e-3.3) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru 
xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/0004-xtrx.c-fix-build-error-with-kernel-6.4.patch
 
xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/0004-xtrx.c-fix-build-error-with-kernel-6.4.patch
--- 
xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/0004-xtrx.c-fix-build-error-with-kernel-6.4.patch
1970-01-01 08:00:00.0 +0800
+++ 
xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/0004-xtrx.c-fix-build-error-with-kernel-6.4.patch
2023-08-01 00:08:42.0 +0800
@@ -0,0 +1,20 @@
+From: "Ying-Chun Liu (PaulLiu)" 
+Bug-Debian: http://bugs.debian.org/1041307
+Subject: [PATCH] xtrx.c: fix build error with kernel 6.4
+Last-Update: 2023-06-24
+Index: xtrx-dkms-0.0.1+git20190320.5ae3a3e/xtrx.c
+===
+--- xtrx-dkms-0.0.1+git20190320.5ae3a3e.orig/xtrx.c
 xtrx-dkms-0.0.1+git20190320.5ae3a3e/xtrx.c
+@@ -1532,7 +1532,11 @@ static int __init xtrx_init(void)
+   goto failed_chrdev;
+   }
+ 
++#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 4, 0)
+   xtrx_class = class_create(THIS_MODULE, CLASS_NAME);
++#else
++  xtrx_class = class_create(CLASS_NAME);
++#endif
+   if (IS_ERR(xtrx_class)) {
+   printk(KERN_NOTICE PFX "Unable to register xtrx class\n");
+   goto failed_setup_cdev;
diff -Nru xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/series 
xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/series
--- xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/series   2023-06-24 
04:21:41.0 +0800
+++ xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/series   2023-08-01 
00:08:42.0 +0800
@@ -1,3 +1,4 @@
 0001-xtrx-fix-PCI-DMA-allow-free-with-kernel-5.18.patch
 0002-xtrx.c-fix-build-error-with-kernel-6.1.patch
 0003-xtrx.c-fix-build-error-with-kernel-6.3.patch
+0004-xtrx.c-fix-build-error-with-kernel-6.4.patch
From: "Ying-Chun Liu (PaulLiu)" 
Bug-Debian: http://bugs.debian.org/1041307
Subject: [PATCH] xtrx.c: fix build error with kernel 6.4
Last-Update: 2023-06-24
Index: xtrx-dkms-0.0.1+git20190320.5ae3a3e/xtrx.c
===
--- xtrx-dkms-0.0.1+git20190320.5ae3a3e.orig/xtrx.c
+++ xtrx-dkms-0.0.1+git20190320.5ae3a3e/xtrx.c
@@ -1532,7 +1532,11 @@ static int __init xtrx_init(void)
 		goto failed_chrdev;
 	}
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 4, 0)
 	xtrx_class = class_create(THIS_MODULE, CLASS_NAME);
+#else
+	xtrx_class = class_create(CLASS_NAME);
+#endif
 	if (IS_ERR(xtrx_class)) {
 		printk(KERN_NOTICE PFX "Unable to register xtrx class\n");
 		goto failed_setup_cdev;


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028953: mirror submission for deb.holownych.com

2023-07-31 Thread Julien Cristau

Control: tag -1 moreinfo

On Sun, Jan 15, 2023 at 06:56:37AM +, Mike Holownych wrote:
> Site: deb.holownych.com

Hi,

How does this compare with your other submission (#1034123, for
debian.holownych.com)?

Thanks,
Julien

Bug#1042671: vorta: diff feature broken

2023-07-31 Thread Nicholas D Steeves

Control: retitle -1 vorta: diff feature broken
Control: tag -1 upstream fixed-upstream
Control: fixed -1 vorta/0.8.12-1

Thanks for the bug report, and I agree this is an important (and
expected) feature.  This happened because Vorta 1.2.4 was uploaded
during Bookworm's (Debian 12's) hard freeze, and I trust that the
release team will accommodate the targeted fix you've proposed.

You can find the package I intend to upload here:

  
https://drive.google.com/drive/folders/1xKyYKhVEByeo0-Jdp8Fvbheh28xSYNUk?usp=sharing

It's just a trivial cherry pick of the relevant commit, but metadata
(documenting metadata takes much longer).  Would you please confirm if
this is enough to resolve the bug?

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1042713: Workaround

2023-07-31 Thread Nick

In case it helps anyone else, this has so far fixed the problem
introduced by wireplumber:

# apt-get purge wireplumber
# apt-get autoremove --purge

Then I killed and restarted pulseaudio.
-- 
Nick
Asunción 11:55 PYT ►  29.7°C  ◆  cielo claro  ◆  9Km/h N  ◆  48% HR

Bug#1042767: xterm: wrong path to utmp file in manpage

2023-07-31 Thread Sven Joachim

Package: xterm
Version: 384-1
Severity: minor

The path to the utmp(5) file in the xterm manpage is wrong:

,
| $ man xterm | grep -A1 /utmp
|/etc/utmp
| the system log file, which records user logins.
`

That should read /var/run/utmp rather than /etc/utmp.  The minstall
script tries to detect the path to the utmp file and substitute the
correct value, but in the build chroot /var/run/utmp has apparently been
absent, as no-one has ever logged in there.

Bug#1041794: mrtrix3: build-depends on unmaintained GTK-2-related packages