Bug#1050155: power-profiles-daemon: Missing runtime dependency python3-gi

2023-08-20 Thread exceptbees
Package: power-profiles-daemon
Version: 0.12-1+b1
Severity: normal
X-Debbugs-Cc: exceptb...@proton.me

Dear Maintainer,

The power-profiles-daemon package doesn't depend on python3-gi.

After installing power-profiles-daemon manually,
running powerprofilesctl on a system where python3-gi is not installed
leads to the following error:

user@localhost:~$ powerprofilesctl
 Traceback (most recent call last):
  File "/usr/bin/powerprofilesctl", line 6, in 
from gi.repository import Gio, GLib
 ModuleNotFoundError: No module named 'gi'

Manually installing python3-gi resolves the issue.

Cheers,
exceptbees


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

Kernel: Linux 6.1.0-11-amd64 (SMP w/4 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 power-profiles-daemon depends on:
ii  libc6  2.36-9+deb12u1
ii  libglib2.0-0   2.74.6-2
ii  libgudev-1.0-0 237-2
ii  libpolkit-gobject-1-0  122-3

power-profiles-daemon recommends no packages.

power-profiles-daemon suggests no packages.

-- no debconf information



Bug#1041282: jtreg6 - okay to upload upstream version 6.2+1?

2023-08-20 Thread Vladimir Petko
Hi,

Thank you!!!

Yes, the patch is cumulative and contains all the relevant changes.

 Existing jtreg6 version (6.1+2-1~deb10u1) in buster is sufficient to
rebuild openjdk-11 and -17 with a number of failing tests. If we
update to 6.2, those tests should start passing, but the update is not
mandatory. I have seen some pull requests[1] that backport jtreg 7
compatibility to openjdk-17, so we might need to switch to it at some
point and this will also require testng 7.

Best Regards,
 Vladimir.

[1] https://github.com/openjdk/jdk17u-dev/pull/1672




On Mon, Aug 21, 2023 at 3:58 PM tony mancill  wrote:
>
> On Mon, Aug 21, 2023 at 09:49:01AM +1200, Vladimir Petko wrote:
> > Hi,
> >
> >  Upgrading to 6.2 does not introduce any jtreg regressions in
> > openjdk-11 and -17.
>
> Hi Vladimir,
>
> Thank you for your response.  The upload is ready, but I want to check
> once more with the list whether there are any concerns.  The build-dep
> on libtestng7-java in this upload will require introducing testng7 [1]
> to old-old-stable (buster) if we need the updated jtreg6 there.
>
> Also, I believe the patch you provided addresses of Debian #1036065 and
> #1036066 [2,3] too.  Can you confirm?
>
> Thank you,
> tony
>
> [1] https://tracker.debian.org/pkg/testng7
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036065
> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036066
>
> > On Sat, Aug 19, 2023 at 7:06 AM tony mancill  wrote:
> > >
> > > On Wed, Aug 16, 2023 at 09:28:39AM +1200, Vladimir Petko wrote:
> > > > Hi,
> > > >
> > > >  The build.xml is not supported by the upstream, so I have updated the
> > > > patch to include rule changes to use the provided Makefile[1].
> > > >
> > > > Changes:
> > > >   * Use Makefile to build jtreg (LP: #2031041).
> > > > - Use --release option in Makefile compile options.
> > > > - d/p/*: drop build.xml patches.
> > > > - d/control: add libguice-java, zip.
> > >
> > > Hello Vladimir, hi Emmanuel:
> > >
> > > Vladimir, thank you for this patch (and others).  I applied it to the
> > > current source repo and rebuild all of the build r-deps before I
> > > realized that the source repo contains 6.2+1 [1] (not 6.1+2), which
> > > hasn't been uploaded.
> > >
> > > Are there any considerations or concerns about going ahead with an
> > > upload of 6.2+1?  As I said, I was able to build openjdk-11, -17, and
> > > -19 with that version.
> > >
> > > Thanks,
> > > tony
> > >
> > > [1] 
> > > https://salsa.debian.org/java-team/jtreg/-/commit/18fe40fc470b04bc735b425bba250db61340fcb3



Bug#1041282: jtreg6 - okay to upload upstream version 6.2+1?

2023-08-20 Thread tony mancill
On Mon, Aug 21, 2023 at 09:49:01AM +1200, Vladimir Petko wrote:
> Hi,
> 
>  Upgrading to 6.2 does not introduce any jtreg regressions in
> openjdk-11 and -17.

Hi Vladimir,

Thank you for your response.  The upload is ready, but I want to check
once more with the list whether there are any concerns.  The build-dep
on libtestng7-java in this upload will require introducing testng7 [1]
to old-old-stable (buster) if we need the updated jtreg6 there.

Also, I believe the patch you provided addresses of Debian #1036065 and
#1036066 [2,3] too.  Can you confirm?

Thank you,
tony

[1] https://tracker.debian.org/pkg/testng7
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036065
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036066

> On Sat, Aug 19, 2023 at 7:06 AM tony mancill  wrote:
> >
> > On Wed, Aug 16, 2023 at 09:28:39AM +1200, Vladimir Petko wrote:
> > > Hi,
> > >
> > >  The build.xml is not supported by the upstream, so I have updated the
> > > patch to include rule changes to use the provided Makefile[1].
> > >
> > > Changes:
> > >   * Use Makefile to build jtreg (LP: #2031041).
> > > - Use --release option in Makefile compile options.
> > > - d/p/*: drop build.xml patches.
> > > - d/control: add libguice-java, zip.
> >
> > Hello Vladimir, hi Emmanuel:
> >
> > Vladimir, thank you for this patch (and others).  I applied it to the
> > current source repo and rebuild all of the build r-deps before I
> > realized that the source repo contains 6.2+1 [1] (not 6.1+2), which
> > hasn't been uploaded.
> >
> > Are there any considerations or concerns about going ahead with an
> > upload of 6.2+1?  As I said, I was able to build openjdk-11, -17, and
> > -19 with that version.
> >
> > Thanks,
> > tony
> >
> > [1] 
> > https://salsa.debian.org/java-team/jtreg/-/commit/18fe40fc470b04bc735b425bba250db61340fcb3


signature.asc
Description: PGP signature


Bug#1050154: dmidecode:Please add loong64 to architecture list.

2023-08-20 Thread JiaLing Zhang
Package: dmidecode
Version: 3.5-2
Severity: normal
X-Debbugs-Cc: zhangjial...@loongson.cn

Dear Maintainer,
Please add loong64 to architecture list .



Bug#1050068: add loong64 Architectrue

2023-08-20 Thread 张家岭
|looks like we only add loong64 for gddccontrol,how about the ddccontrol 
and libddcontrol-dev and so on .

|


Bug#1048073: mah-jong upgrade to gtk3

2023-08-20 Thread 肖盛文

Hi Julian Bradfield,

    mah-jong is a good game software.

But it depend on gtk2 now, would you update it to depend on gtk3?

If don't do so, this software will remove from Debian.

Please see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1048073


To Bastian:
Could you orphaned mah-jong at first? I would ITA.

The homepage of this software is still exist:
http://mahjong.julianbradfield.org/

The latest version 1.16 is upload on 2020-06-26:
http://mahjong.julianbradfield.org/Linux/

mah-jong is used very popular in east asia country.


To ftpmaster:
Please don't remove this package now.
Thanks!

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1050153: O: bookworm -- Simple, focused eBook Reader

2023-08-20 Thread Boyuan Yang
Package: wnpp
Control: affects -1 src:bookworm

I am orphaning package bookworm ( https://tracker.debian.org/pkg/bookworm ) due
to lack of time and that upstream is not meaningfully active for a long time.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: bookworm
Binary: bookworm
Version: 1.1.2+git20210715-2
Maintainer: Boyuan Yang 
Build-Depends: debhelper-compat (= 13), dh-sequence-python3, python3:any, 
gettext, libgee-0.8-dev, libgranite-dev (>= 0.5), libgtk-3-dev (>= 3.10), 
libpoppler-glib-dev,
libsqlite3-dev, libwebkit2gtk-4.0-dev, libxml2, libxml2-dev, meson, valac (>= 
0.28.0), help2man
Architecture: any
Standards-Version: 4.6.0
Format: 3.0 (quilt)
Files:
 76ae1327910333e2940600d91116d722 2133 bookworm_1.1.2+git20210715-2.dsc
 c0ab5a996a8e4fb8491e2c194e4d42a2 2244403 bookworm_1.1.2+git20210715.orig.tar.gz
 00d06c37f35c074aa3984eb340286069 4044 
bookworm_1.1.2+git20210715-2.debian.tar.xz
Vcs-Browser: https://salsa.debian.org/debian/bookworm
Vcs-Git: https://salsa.debian.org/debian/bookworm.git
Checksums-Sha256:
 4d844f3826cfa7b40023040454e74e48a149fd33743de103c1bb73da095b63d6 2133 
bookworm_1.1.2+git20210715-2.dsc
 fc49a212393999fa68cfdfed34d4adf3782139314054d8c25e72e509e4b4a535 2244403 
bookworm_1.1.2+git20210715.orig.tar.gz
 3fa49e13e713dacfc0e0a462ece2f3f4668ac9733182993d977e39cf4bd1544b 4044 
bookworm_1.1.2+git20210715-2.debian.tar.xz
Homepage: https://babluboy.github.io/bookworm/
Package-List: 
 bookworm deb text optional arch=any
Directory: pool/main/b/bookworm
Priority: extra
Section: misc

Package: bookworm
Version: 1.1.2+git20210715-2
Installed-Size: 4118
Maintainer: Boyuan Yang 
Architecture: amd64
Replaces: com.github.babluboy.bookworm
Provides: com.github.babluboy.bookworm
Depends: html2text, poppler-utils, unar, unzip, dconf-gsettings-backend | 
gsettings-backend, libc6 (>= 2.14), libgdk-pixbuf-2.0-0 (>= 2.25.2), 
libgee-0.8-2 (>= 0.20.0),
libglib2.0-0 (>= 2.43.92), libgranite6 (>= 6.0.0), libgtk-3-0 (>= 3.17.9), 
libpango-1.0-0 (>= 1.14.0), libpoppler-glib8 (>= 0.22.1), libsoup2.4-1 (>= 
2.4.0), libsqlite3-0 (>=
3.5.9), libwebkit2gtk-4.0-37 (>= 2.17.3), libxml2 (>= 2.7.4), python3:any
Conflicts: com.github.babluboy.bookworm
Description-en: Simple, focused eBook Reader
 The bookworm tool helps you to read eBooks of different
 formats, including epub, pdf, mobi, cbr, etc. It provides
 an easy, simple layout to read books irrespective of the
 ebook format.
Description-md5: d3fcf1bedbe443d8f0db72117c80cd22
Homepage: https://babluboy.github.io/bookworm/
Tag: uitoolkit::gtk
Section: text
Priority: optional
Filename: pool/main/b/bookworm/bookworm_1.1.2+git20210715-2_amd64.deb
Size: 1636940
MD5sum: 05f55d7966c9dddc4633a3acaccaef6a
SHA256: 7c62be75f542c422a295b3279a7b9bdc594f661f6a67534fabb6c84358d2ba8e


-- 
Thanks,
Boyuan Yang


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


Bug#1050152: rxvt-unicode: prompt starts in the middle of the screen

2023-08-20 Thread Nick K.
Package: rxvt-unicode
Version: 9.31-1
Severity: normal
Tags: upstream

Dear Maintainer,

When opening terminal, prompt appears in the middle of the screen. I
disabled .profile, .bashrc and .xresources to no effect, so I assume,
it's not configuration issue.

Putting "clear" in .bashrc "solves" the issue. Issue disappears on
downgrading to 9.30-2+b4 from "stable" branch.

Also there is a discussion of this bug: 
https://bugs.archlinux.org/task/77062 


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

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

Versions of packages rxvt-unicode depends on:
ii  base-passwd   3.6.1
ii  libc6 2.37-7
ii  libfontconfig12.14.2-3
ii  libgcc-s1 13.2.0-2
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.77.2-1
ii  libperl5.36   5.36.0-7
ii  libptytty02.0-1+b1
ii  libstartup-notification0  0.12-6+b1
ii  libx11-6  2:1.8.6-1
ii  libxext6  2:1.3.4-1+b1
ii  libxft2   2.3.6-1
ii  libxmu6   2:1.1.3-3
ii  libxrender1   1:0.9.10-1.1
ii  ncurses-base  6.4+20230625-2
ii  ncurses-term  6.4+20230625-2

Versions of packages rxvt-unicode recommends:
ii  fonts-dejavu2.37-8
pn  fonts-vlgothic | fonts-japanese-gothic  

Versions of packages rxvt-unicode suggests:
ii  sensible-utils  0.0.20

-- no debconf information



Bug#1050151: RM: gnome-shell-extension-sound-device-chooser -- ROM; unmaintained, not compatible with GNOME 43+

2023-08-20 Thread Fabio A. De Muzio Tobich

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: 1018...@bugs.debian.org, ftob...@debian.org

--
⢀⣴⠾⠻⢶⣦
⣾⠁⢠⠒⠀⣿⡁   Fabio Augusto De Muzio Tobich
⢿⡄⠘⠷⠚⠋⠀   9730 4066 E5AE FAC2 2683  D03D 4FB3 B4D3 7EF6 3B2E
⠈⠳⣄


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1024501: Can we close this bug report?

2023-08-20 Thread Roberto C . Sánchez
Since it is evident that the Code of Conduct does not apply to the
content of packages in this way (nor can it), and absent a clear policy
permitting the removal of a package based on its content not being
agreeable, can we close this bug report?

Regards,

-Roberto
-- 
Roberto C. Sánchez



Bug#1050150: gnome-shell-extension-gsconnect: new upstream version 55

2023-08-20 Thread Simon McVittie
Source: gnome-shell-extension-gsconnect
Version: 54-2
Severity: wishlist
Tags: trixie sid

I've just uploaded mutter version 44 to experimental, starting transition
#1043144. This means gnome-shell-extension-gsconnect 55 (in experimental)
can now be uploaded to unstable; please close this bug with that upload.

Thanks,
smcv



Bug#1050149: budgie-desktop: Please upload a version compatible with mutter 44 to unstable

2023-08-20 Thread Simon McVittie
Source: budgie-desktop
Version: 10.7.1-1
Severity: serious
Tags: trixie sid
Justification: transition #1043144

I've just uploaded mutter version 44 to experimental, starting transition
#1043144. Please upload a compatible version of budgie-desktop to
unstable, and close this bug with that upload. The newer upstream version
currently in experimental seems suitable.

Thanks,
smcv



Bug#1041580: gnome-shell-extension-tiling-assistant: needs update for GNOME Shell 44

2023-08-20 Thread Simon McVittie
Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:38:49 +0100, Simon McVittie wrote:
> The version of gnome-shell-extension-tiling-assistant in unstable is
> not marked as compatible with GNOME Shell 44, but the version in
> experimental is.

I've just uploaded gnome-shell 44 to unstable. Please upload the
experimental version of this extension to unstable whenever is convenient,
and close this bug in that upload.

Thanks,
smcv



Bug#1050148: linux-image-6.1.0-11-amd64: When Ryzen2(4800H) system resume from sleep, mouse and keyboard become sluggish and unusable.

2023-08-20 Thread Z J

Package: src:linux
Version: 6.1.38-4
Severity: important

Dear Maintainer,

This happens every time back from sleep. Keyboard input in remote ssh 
session works OK.

Older version 6.1.0-9/10 is usable but can still see this issue.

Thanks,

Jiandong Zheng

-- Package-specific info:
** Version:
Linux version 6.1.0-11-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-4 (2023-08-08)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-11-amd64 
root=UUID=fceb24e4-1a93-4cbb-baee-ba8f6a7111f4 ro quiet


** Not tainted

** Kernel log:
[ 4326.678606] microcode: CPU9: patch_level=0x08600103
[ 4326.681343] ACPI: \_SB_.PLTF.P009: Found 3 idle states
[ 4326.681351] ACPI: FW issue: working around C-state latencies out of order
[ 4326.682787] CPU9 is up
[ 4326.682821] smpboot: Booting Node 0 Processor 10 APIC 0xa
[ 4326.681170] microcode: CPU10: patch_level=0x08600103
[ 4326.683598] ACPI: \_SB_.PLTF.P00A: Found 3 idle states
[ 4326.683609] ACPI: FW issue: working around C-state latencies out of order
[ 4326.685940] CPU10 is up
[ 4326.685976] smpboot: Booting Node 0 Processor 11 APIC 0xb
[ 4326.683252] microcode: CPU11: patch_level=0x08600103
[ 4326.686423] ACPI: \_SB_.PLTF.P00B: Found 3 idle states
[ 4326.686430] ACPI: FW issue: working around C-state latencies out of order
[ 4326.688184] CPU11 is up
[ 4326.688231] smpboot: Booting Node 0 Processor 12 APIC 0xc
[ 4326.686237] microcode: CPU12: patch_level=0x08600103
[ 4326.689093] ACPI: \_SB_.PLTF.P00C: Found 3 idle states
[ 4326.689102] ACPI: FW issue: working around C-state latencies out of order
[ 4326.690978] CPU12 is up
[ 4326.691015] smpboot: Booting Node 0 Processor 13 APIC 0xd
[ 4326.688690] microcode: CPU13: patch_level=0x08600103
[ 4326.691454] ACPI: \_SB_.PLTF.P00D: Found 3 idle states
[ 4326.691460] ACPI: FW issue: working around C-state latencies out of order
[ 4326.693493] CPU13 is up
[ 4326.693527] smpboot: Booting Node 0 Processor 14 APIC 0xe
[ 4326.691278] microcode: CPU14: patch_level=0x08600103
[ 4326.694211] ACPI: \_SB_.PLTF.P00E: Found 3 idle states
[ 4326.694220] ACPI: FW issue: working around C-state latencies out of order
[ 4326.696372] CPU14 is up
[ 4326.696413] smpboot: Booting Node 0 Processor 15 APIC 0xf
[ 4326.693945] microcode: CPU15: patch_level=0x08600103
[ 4326.696877] ACPI: \_SB_.PLTF.P00F: Found 3 idle states
[ 4326.696884] ACPI: FW issue: working around C-state latencies out of order
[ 4326.699160] CPU15 is up
[ 4326.700676] ACPI: PM: Waking up from system sleep state S3
[ 4326.705395] pci :00:00.2: can't derive routing for PCI INT A
[ 4326.705400] pci :00:00.2: PCI INT A: no GSI
[ 4326.705606] [drm] PCIE GART of 1024M enabled.
[ 4326.705608] [drm] PTB located at 0x00F41FC0
[ 4326.705620] [drm] PSP is resuming...
[ 4326.713348] nvme nvme0: 16/0/0 default/read/poll queues
[ 4326.725459] [drm] reserve 0x40 from 0xf41f80 for PSP TMR
[ 4326.802889] amdgpu :04:00.0: amdgpu: RAS: optional ras ta ucode 
is not available
[ 4326.810528] amdgpu :04:00.0: amdgpu: RAP: optional rap ta ucode 
is not available
[ 4326.814629] [drm] psp gfx command LOAD_TA(0x1) failed and response 
status is (0x7)
[ 4326.814744] [drm] psp gfx command INVOKE_CMD(0x3) failed and response 
status is (0x4)

[ 4326.814746] amdgpu :04:00.0: amdgpu: Secure display: Generic Failure.
[ 4326.814747] amdgpu :04:00.0: amdgpu: SECUREDISPLAY: query 
securedisplay TA failed. ret 0x0

[ 4326.814751] amdgpu :04:00.0: amdgpu: SMU is resuming...
[ 4326.814791] amdgpu :04:00.0: amdgpu: dpm has been disabled
[ 4326.815563] amdgpu :04:00.0: amdgpu: SMU is resumed successfully!
[ 4326.816243] [drm] DMUB hardware initialized: version=0x01010026
[ 4326.847559] [drm] kiq ring mec 2 pipe 1 q 0
[ 4326.850727] [drm] VCN decode and encode initialized 
successfully(under DPG Mode).

[ 4326.850769] [drm] JPEG decode initialized successfully.
[ 4326.850777] amdgpu :04:00.0: amdgpu: ring gfx uses VM inv eng 0 
on hub 0
[ 4326.850779] amdgpu :04:00.0: amdgpu: ring comp_1.0.0 uses VM inv 
eng 1 on hub 0
[ 4326.850781] amdgpu :04:00.0: amdgpu: ring comp_1.1.0 uses VM inv 
eng 4 on hub 0
[ 4326.850782] amdgpu :04:00.0: amdgpu: ring comp_1.2.0 uses VM inv 
eng 5 on hub 0
[ 4326.850784] amdgpu :04:00.0: amdgpu: ring comp_1.3.0 uses VM inv 
eng 6 on hub 0
[ 4326.850786] amdgpu :04:00.0: amdgpu: ring comp_1.0.1 uses VM inv 
eng 7 on hub 0
[ 4326.850787] amdgpu :04:00.0: amdgpu: ring comp_1.1.1 uses VM inv 
eng 8 on hub 0
[ 4326.850789] amdgpu :04:00.0: amdgpu: ring comp_1.2.1 uses VM inv 
eng 9 on hub 0
[ 4326.850790] amdgpu :04:00.0: amdgpu: ring comp_1.3.1 uses VM inv 
eng 10 on hub 0
[ 4326.850792] amdgpu :04:00.0: amdgpu: ring kiq_2.1.0 uses VM inv 
eng 11 on hub 0
[ 4326.850793] amdgpu :04:00.0: amdgpu: ring sdma0 uses VM inv eng 0 
on hub 1
[ 4326.850795] amdgpu :04:00.0: amdgpu: ring vcn_dec uses VM inv 

Bug#1041582: gnome-shell-extension-vertical-overview: needs update for GNOME Shell 44

2023-08-20 Thread Simon McVittie
Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:39:33 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv



Bug#1038412: gnome-shell-extension-weather: Update to 121 to support GNOME 44

2023-08-20 Thread Simon McVittie
Control: severity -1 serious

On Sat, 17 Jun 2023 at 23:06:51 +0200, Amr Ibrahim wrote:
> Please update to 121 to support GNOME 44.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv



Bug#1041577: gnome-shell-extension-panel-osd: needs update for GNOME Shell 44

2023-08-20 Thread Simon McVittie
Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:34:18 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv



Bug#1041575: gnome-shell-extension-impatience: needs update for GNOME Shell 44

2023-08-20 Thread Simon McVittie
Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:29:56 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv



Bug#1041574: gnome-shell-extension-hamster: needs update for GNOME Shell 44

2023-08-20 Thread Simon McVittie
Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:29:30 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv



Bug#1041572: gnome-shell-extension-freon: needs update for GNOME Shell 44

2023-08-20 Thread Simon McVittie
Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:28:26 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv



Bug#1041573: gnome-shell-extension-gamemode: needs update for GNOME Shell 44

2023-08-20 Thread Simon McVittie
Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:28:48 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv



Bug#1041571: gnome-shell-extension-flypie: needs update for GNOME Shell 44

2023-08-20 Thread Simon McVittie
Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:28:09 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv



Bug#1041569: gnome-shell-extension-easyscreencast: needs update for GNOME Shell 44

2023-08-20 Thread Simon McVittie
Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:27:25 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv



Bug#1033100: Update gnome-shell-extension-dashtodock to 84 to support GNOME 44

2023-08-20 Thread Simon McVittie
Control: severity -1 serious
Control: tags -1 + pending

On Thu, 22 Jun 2023 at 17:37:21 +, Amr Ibrahim wrote:
> Please update to 84 to support gnome-shell 44.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready (it seems to be staged
in the git repository but not yet uploaded).

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv



Bug#1041567: gnome-shell-extension-arc-menu: needs update for GNOME Shell 44

2023-08-20 Thread Simon McVittie
Control: severity -1 serious
Control: tags -1 + fixed-upstream

On Thu, 20 Jul 2023 at 23:24:52 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when available.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

On Sun, 30 Jul 2023 at 10:50:39 +0300, Jeremy Bícha wrote:
> It looks like the new upstream repo for this extension is
> https://gitlab.com/arcmenu/ArcMenu

The latest version in that repository seems to declare compatibility
with Shell 44. It appears that code changes were required.

smcv



Bug#1050147: sbuild: Allow hiding output sections (e.g., Changes, Buildinfo)

2023-08-20 Thread Gioele Barabucci

Package: sbuild
Version: 0.85.2
Severity: wishlist

Dear sbuild developers,

could you please add an option to skip outputting the content of certain 
sections?


For example, during the development of a package, the output of dh 
(section "Build") is useful, but sections like "Changes", "Buildinfo" 
and "Summary" only clutter the terminal and provide no useful information.


In this context it would make sense to run sbuild with something like 
`--hide=changes,buildinfo,summary`.


--
Gioele Barabucci



Bug#1043144: transition: mutter/gnome-shell 44

2023-08-20 Thread Simon McVittie
On Sun, 20 Aug 2023 at 19:52:50 +, Graham Inggs wrote:
> I added your combined ben file to the tracker with some minor changes:
> https://release.debian.org/transitions/html/gnome-shell-44.html

Thanks!

> Please go ahead.

Initial round of builds in progress.

smcv



Bug#1041282: jtreg6 - okay to upload upstream version 6.2+1?

2023-08-20 Thread Vladimir Petko
Hi,

 Upgrading to 6.2 does not introduce any jtreg regressions in
openjdk-11 and -17.

Best Regards,
  Vladimir.

On Sat, Aug 19, 2023 at 7:06 AM tony mancill  wrote:
>
> On Wed, Aug 16, 2023 at 09:28:39AM +1200, Vladimir Petko wrote:
> > Hi,
> >
> >  The build.xml is not supported by the upstream, so I have updated the
> > patch to include rule changes to use the provided Makefile[1].
> >
> > Changes:
> >   * Use Makefile to build jtreg (LP: #2031041).
> > - Use --release option in Makefile compile options.
> > - d/p/*: drop build.xml patches.
> > - d/control: add libguice-java, zip.
>
> Hello Vladimir, hi Emmanuel:
>
> Vladimir, thank you for this patch (and others).  I applied it to the
> current source repo and rebuild all of the build r-deps before I
> realized that the source repo contains 6.2+1 [1] (not 6.1+2), which
> hasn't been uploaded.
>
> Are there any considerations or concerns about going ahead with an
> upload of 6.2+1?  As I said, I was able to build openjdk-11, -17, and
> -19 with that version.
>
> Thanks,
> tony
>
> [1] 
> https://salsa.debian.org/java-team/jtreg/-/commit/18fe40fc470b04bc735b425bba250db61340fcb3



Bug#1050146: RM: mps-youtube -- RoQA; RC-buggy; active fork available

2023-08-20 Thread Bastian Germann

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

Please remove mps-youtube. It is RC-buggy and did not make it into 
bookworm. See #952583 for a status statement about mps-youtube:


On Tue, 21 Feb 2023 09:08:02 +0200 jim_p  wrote:

Speaking of progress from upstream, and only 2 days after my comment here, a
new version was released from upstream!
https://github.com/mps-youtube/yewtube/releases/tag/v2.9.4

The project was renamed to yewtube and its versioning scheme is continued from
the forked project above. If anyone is willing to package it, please do, else
remove it from the repo.




Bug#1028897: fontconfig: wrong name for the Noto monospace font

2023-08-20 Thread Raphaël Halimi

Le 20/08/2023 à 22:15, Gunnar Hjalmarsson a écrit :

Thus, the default font for the "Monospace" alias will depend on the
installed packages.


That's always the case, isn't it? The output of "fc-match" or "fc-match 
mono" depends on a combo of available fonts and the font configuration.


Yes, but what I meant was that it's a change from before 2.14, when 
configuration and dependencies made sure that everyone had the same 
default (DejaVu Sans Mono).


Regards,

--
Raphaël Halimi



Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

2023-08-20 Thread Philip Hands
Philip Hands  writes:
...
> However, I am now wondering whether we might not be better off using
> `archdetect` to see if we're on an efi system, and then make the attempt
> to call mountvirtfs for the efivarfs conditional on that.

After a diversion[1], I had a look at the archdetect option, and have
discovered that this simple patch:

  
https://salsa.debian.org/philh/grub-installer/-/commit/6f33bd183d7d0ced76958440534407dc9d0ad141

fixes the UEFI boot, without breaking the BIOS boot (on amd64 at least,
while doing a minimal install):

  
https://openqa.debian.net/tests/overview?version=testing=--20230820_1958_salsa=debian

I hope/assume that all the arches that need this have the good grace to
return `efi` as their subarch. If there's any risk that's not the case,
we could also apply the previous patch.

If you want to do your own tests, the mini.iso can be downloaded via:

https://salsa.debian.org/philh/grub-installer/-/jobs/4582667/artifacts/file/debian/output/debian-202306XX+salsaci+20230820+228-amd64-gtkmini.iso

BTW that's in the artifacts of the `mini-ISO` job, which can be found by
looking at the pipeline linked from the commit above[2], and looking to
the right for the Downstream pipelines -- further right you can find
links to the openQA jobs above.

Cheers, Phil.

[1] rewriting branch2repo so that it doesn't need a state repo. for
many use-cases, which will hopefully allow anyone to run these D-I tests
on salsa, without any special setup.

[2] https://salsa.debian.org/philh/grub-installer/-/pipelines/567684
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature


Bug#1049966:

2023-08-20 Thread Michał Byrecki
Further to the bug, here's the evtest output:
> Input driver version is 1.0.1
> Input device ID: bus 0x3 vendor 0x24ae product 0x2010 version 0x110
> Input device name: "RAPOO Rapoo 2.4G Wireless Device"
> Supported events:
>   Event type 0 (EV_SYN)
>   Event type 1 (EV_KEY)
> Event code 272 (BTN_LEFT)
> Event code 273 (BTN_RIGHT)
> Event code 274 (BTN_MIDDLE)
> Event code 275 (BTN_SIDE)
> Event code 276 (BTN_EXTRA)
>   Event type 2 (EV_REL)
> Event code 0 (REL_X)
> Event code 1 (REL_Y)
> Event code 8 (REL_WHEEL)
> Event code 11 (REL_WHEEL_HI_RES)
>   Event type 4 (EV_MSC)
> Event code 4 (MSC_SCAN)
> Properties:
> Testing ... (interrupt to exit)
> 

>From what I see, the driver is correctly processing the left and mid
button:

Event: time 1692563194.319720, -- SYN_REPORT 
Event: time 1692563194.407719, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90001
Event: time 1692563194.407719, type 1 (EV_KEY), code 272 (BTN_LEFT), value 0
Event: time 1692563194.407719, -- SYN_REPORT 
Event: time 1692563199.591686, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
Event: time 1692563199.591686, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1

...but unfortunately the driver remains dead silent of the right click.
I guess it's the kernel input driver then...

Brgds Mike



Bug#1039737: reportbug: lxc-copy --ephemeral always fails

2023-08-20 Thread Mathias Gibbens
Control: retitle -1 lxc: lxc-copy --ephemeral always fails
Control: tags -1 + confirmed

  I've reproduced this locally, and come up with the following patch
which I've also forwarded upstream:

> diff --git a/src/lxc/conf.c b/src/lxc/conf.c
> index 9158713..f956f89 100644
> --- a/src/lxc/conf.c
> +++ b/src/lxc/conf.c
> @@ -512,6 +512,8 @@ int lxc_storage_prepare(struct lxc_conf *conf)
> return log_error(-1, "Failed to mount rootfs \"%s\" onto 
> \"%s\" with options \"%s\"",
>  rootfs->path, rootfs->mount,
>  rootfs->mnt_opts.raw_options ? 
> rootfs->mnt_opts.raw_options : "(null)");
> +   if (!rootfs->bdev_type)
> +   rootfs->bdev_type = strdup(rootfs->storage->type);
>  
> return 0;
>  }

Mathias


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


Bug#1050145: RFS: qpsmtpd/0.94-6 [ITA] -- Flexible SMTP daemon for network-level spam detection

2023-08-20 Thread Peter J. Holzer
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : qpsmtpd
   Version  : 0.94-6
 * URL  : https://github.com/smtpd/qpsmtpd
   Section  : mail

The source builds the following binary packages:

  qpsmtpd - Flexible SMTP daemon for network-level spam detection

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/q/qpsmtpd/qpsmtpd_0.94-6.dsc

Changes since the last upload:

 qpsmtpd (0.94-6) unstable; urgency=medium
 .
   * Fix #933679

The qpsmtpd package has been orphaned for 5+ years now. There have been
3 upstream releases during that time. So I'm interested in adopting the
package to get a current version into Debian again. This upload however
only fixes a small but very annoying bug.

Regards,
hjp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature


Bug#1041889: Please close bug - issue resolved with linux-image-6.4.0-3-amd64

2023-08-20 Thread Alvin Cheung
Dear all,

I have just tested linux-image-6.4.0-3-amd64, and can confirm that that
version resolves this issue.  Please mark this bug as closed.

Many thanks.

-- 
PGP key fingerprint: FD48 6B30 2A79 7F2E 4261 1FE6 304E CC56 4C4D 918D


Bug#1050089: bootstrap tries to search for gnulib PO files in spite of '--skip-po'

2023-08-20 Thread Colin Watson
Control: tag -1 fixed-upstream

On Sat, Aug 19, 2023 at 03:52:35PM +, Bjarni Ingi Gislason wrote:
> bootstrapping with --no-git --gnulib-srcdir=/home/bg/git/gnulib --skip-po 
> --bootstrap-sync

In general, this is an "if it breaks, you get to keep both pieces" set
of options.

However, it probably does make sense to provide a way to suppress the
downloads performed by gnulib-tool here, so I've done that for the next
upstream release:

  https://gitlab.com/man-db/man-db/-/commit/b403f6d413

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



Bug#1036450: This has been reported upstream

2023-08-20 Thread Joachim Zobel


See https://github.com/eclipse/mosquitto/issues/2878



Bug#1050144: emperor: FTBFS with pandas 2.0

2023-08-20 Thread Rebecca N. Palmer

Package: src:emperor
Version: 1.0.3+ds-7
Control: block 1043240 by -1

emperor fails to build with pandas 2.0, currently in experimental.

Build log:
https://launchpadlibrarian.net/682917876/buildlog_ubuntu-mantic-amd64.emperor_1.0.3+ds-7_BUILDING.txt.gz

A common source of failures is that pandas.util.testing has been renamed
to pandas.testing.  Both names were available in all 1.x versions (and
hence in Debian stable and oldstable), so Debian packages that were
using this can immediately switch unconditionally.



Bug#1028897: fontconfig: wrong name for the Noto monospace font

2023-08-20 Thread Gunnar Hjalmarsson

On 2023-08-20 21:34, Raphaël Halimi wrote:

As I understand it, this will make fontconfig select DejaVu Sans Mono
on most desktop installations (since libreoffice depends on both
sets), and Noto Mono on a handful of installations, namely, minimal
installations which will have only fonts-noto-{core,mono} installed,
and not fonts-dejavu-{core,mono}.


That's my understanding too.


Thus, the default font for the "Monospace" alias will depend on the
installed packages.


That's always the case, isn't it? The output of "fc-match" or "fc-match 
mono" depends on a combo of available fonts and the font configuration.


As an example, and since I work with Ubuntu as well, Ubuntu 23.04 also 
has fontconfig 2.14, but most users haven't noticed since 
fonts-noto-core is not installed by default (neither is the libreoffice 
binary, which explains the difference to Debian in this respect). Ubuntu 
23.10 will include fonts-noto-core, though, so there is an ongoing work 
with deciding both the set of pre-installed font packages and possible 
adjustments of the configuration.



I'm okay with that.


Good. :)


Thanks for fixing it :)


N.p.


Yes, let's see what users think of the change. I have good hope that
most people will be satisfied.


Let's keep our fingers crossed.

/ Gunnar



Bug#1050143: dgit: support uploading to security-master

2023-08-20 Thread Ian Jackson
Control: block -1 by 862105

Sean Whitton writes ("Bug#1050143: dgit: support uploading to security-master"):
> I recently joined the LTS Security Team and found that I had to relearn
> how to build source packages with dpkg-buildpackage in order to upload.

Isn't it annoying ?  Unfortunately because security uploads can be
embargoed, this isn't something we can just do here.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1043144: transition: mutter/gnome-shell 44

2023-08-20 Thread Graham Inggs
Control: tags -1 confirmed

Hi Simon

I added your combined ben file to the tracker with some minor changes:
https://release.debian.org/transitions/html/gnome-shell-44.html

On Tue, 15 Aug 2023 at 17:18, Simon McVittie  wrote:
> I think this is ready to go. Repeating the list of packages needing
> sourceful uploads from experimental into unstable in approximately this
> order, for the release team's convenience:
>
> * mutter
> * gnome-shell
> * gnome-shell-extensions
> * gnome-remote-desktop
> * budgie-desktop
> * gnome-shell-extension-bluetooth-quick-connect
> * gnome-shell-extension-gsconnect
> * gnome-shell-extension-tiling-assistant
>
> And then any remaining extensions in
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org=gnome-shell-44
> will need temporarily removing from testing to let the transition through.
>
> The release team has traditionally been relatively trigger-happy about
> removing broken Shell extensions, since they are clearly less important
> than GNOME itself. When the transition is otherwise ready to migrate,
> I'll provide a full list of packages needing removal.

Please go ahead.

Regards
Graham



Bug#1050143: dgit: support uploading to security-master

2023-08-20 Thread Sean Whitton
Package: dgit
Version: 10.7

Dear maintainer,

I recently joined the LTS Security Team and found that I had to relearn
how to build source packages with dpkg-buildpackage in order to upload.

It would be nice to have dgit support uploads to security master, in
particular because dgit could work out whether or not to include the
orig.tar.

The most convenient thing would be to upload to security-master when the
suite name ends in '-security'.  So, perhaps some sort of mapping of
upload targets to upload hosts.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#982430: grig: Communication of /dev/ttyS* timed out

2023-08-20 Thread Christoph Berg
Re: Michael Vorleiter
> Package: grig
> Version: 0.8.1-2
> Severity: important
> 
> Dear Maintainer,
> 
> I am describing in seven points the situation; from the error message to the 
> hardware.
> 
> 1. Error message: 
> 2020/04/22 08:45:06;;GRIG;;2;;rig_daemon_start: Öffnen des Anlagen-Ports 
> fehlgeschlagen /dev/ttyS1: Communication timed out (Berechtigungen?)

Hi Michael,

this is a message from hamlib, so likely not a problem in grig.
If you still experience the problem, try using rigctl instead.

I'm closing the bug now, if there is a problem with grig, we can
reopen.

73,
Christoph DF7CB



Bug#1028897: fontconfig: wrong name for the Noto monospace font

2023-08-20 Thread Raphaël Halimi

Le 20/08/2023 à 12:33, Gunnar Hjalmarsson a écrit :

So, I just downloaded NotoSansMono-Regular.ttf from its new home [1]
(the old repository in the Debian copyright file has been archived),
opened it in font-viewer and... Sadly, the spacing is still
"Proportional" and not "Monospace" :(


Thanks for doing that. So we will probably need to live with it for the 
foreseeable future. And yes, it's a bit sad.


No problem :)

Anyway, I'm now convinced that the status of Noto Sans Moto motivates a 
change of the default monospace font in Debian. Well, you and I haven't 
agreed on what to put there instead, so how about a compromise where we 
pick both? :)


https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/6fae069d


As I understand it, this will make fontconfig select DejaVu Sans Mono on 
most desktop installations (since libreoffice depends on both sets), and 
Noto Mono on a handful of installations, namely, minimal installations 
which will have only fonts-noto-{core,mono} installed, and not 
fonts-dejavu-{core,mono}.


Thus, the default font for the "Monospace" alias will depend on the 
installed packages. At least, since Noto Sans Mono is listed after Noto 
Mono, and since they're both shipped by the same package, the latter 
will never be selected, which will fix the core of the problem - huge 
and hard-to-read terminals.


I'm okay with that. Thanks for fixing it :)

While I still hesitate, since the change affects so many users, I have 
decided to act. After all we are in the beginning of the trixie 
development cycle, so there is plenty of time to change it later. By 
making the change in unstable and testing, we expose it to the users. 
Many will probably not even notice and some will like it. And if some 
users disapprove of the change, the broader discussion we haven't had 
may happen later.


Yes, let's see what users think of the change. I have good hope that 
most people will be satisfied.



Thanks for your perseverance!


You're welcome :)

Regards,

--
Raphaël Halimi



Bug#1043425: libmethod-signatures-perl: FTBFS with Perl 5.38: Smartmatch is deprecated

2023-08-20 Thread Niko Tyni
Control: tag -1 patch

On Thu, Aug 10, 2023 at 09:20:42PM +0300, Niko Tyni wrote:
> Source: libmethod-signatures-perl
> Version: 20170211-3
> Severity: important
> Tags: ftbfs trixie sid
> User: debian-p...@lists.debian.org
> Usertags: perl-5.38-transition
> 
> This package fails to build from source with Perl 5.38 (currently in
> experimental.)
> 
>   
> http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/libmethod-signatures-perl_20170211-3/libmethod-signatures-perl_20170211-3_amd64-2023-08-04T06:11:02Z.build
> 
> #   Failed test 'no warnings for using smartmatch'
> #   at t/where.t line 21.
> # found warning: Smartmatch is deprecated at (eval 34) line 1.
> # didn't expect to find a warning

Here's a patch for this issue.
-- 
Niko Tyni   nt...@debian.org
>From 958378982f9a046708cdd69b1c5e1189700f5273 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sun, 20 Aug 2023 20:19:59 +0100
Subject: [PATCH] Skip smartmatch warnings test for newer perls

Bug-Debian: http://bugs.debian.org/1043425
---
 t/where.t | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/t/where.t b/t/where.t
index 09f027d..511860c 100644
--- a/t/where.t
+++ b/t/where.t
@@ -18,8 +18,10 @@ use Method::Signatures;
 
 
 my $where_func = q{ func silly_test ($x where { $_ == 3 }) {} };
-warning_is { eval $where_func } undef, 'no warnings for using smartmatch';
-
+SKIP: {
+skip "Smartmatch should warn for Perl >= 5.37.10", 1 if $] >= 5.037010;
+warning_is { eval $where_func } undef, 'no warnings for using smartmatch';
+}
 
 subtest 'where { block() }' => sub {
 plan tests => 3;
@@ -152,15 +154,15 @@ subtest 'where with placeholders' => sub {
 ok eval { constrained_placeholder(2) }, 'constrained_placeholder() called as expected'
 or note $@;
 
-# line 155
+# line 157
 throws_ok { constrained_placeholder() }
-required_placeholder_error('main', 0, 'constrained_placeholder', LINE => 156),
+required_placeholder_error('main', 0, 'constrained_placeholder', LINE => 158),
 'missing requierd constrained placeholder';
 throws_ok { constrained_placeholder('foo') }
-placeholder_badval_error('main', 0, 'Int' => 'foo', 'constrained_placeholder', LINE => 159),
+placeholder_badval_error('main', 0, 'Int' => 'foo', 'constrained_placeholder', LINE => 161),
 'placeholder value wrong type';
 throws_ok { constrained_placeholder(99) }
-placeholder_failed_constraint_error('main', 0, 99 => '{$_<10}', 'constrained_placeholder', LINE => 162),
+placeholder_failed_constraint_error('main', 0, 99 => '{$_<10}', 'constrained_placeholder', LINE => 164),
 'placeholder value wrong type';
 };
 
-- 
2.39.1



Bug#1050142: qemu: CVE-2023-4135

2023-08-20 Thread Salvatore Bonaccorso
Source: qemu
Version: 1:8.0.4+dfsg-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for qemu.

CVE-2023-4135[0]:
| A heap out-of-bounds memory read flaw was found in the virtual nvme
| device in QEMU. The QEMU process does not validate an offset
| provided by the guest before computing a host heap pointer, which is
| used for copying data back to the guest. Arbitrary heap memory
| relative to an allocated buffer can be disclosed.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-4135
https://www.cve.org/CVERecord?id=CVE-2023-4135
[1] https://www.zerodayinitiative.com/advisories/ZDI-CAN-21521
[2] 
https://gitlab.com/qemu-project/qemu/-/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf

Regards,
Salvatore



Bug#1050141: ITS: opensc

2023-08-20 Thread Bastian Germann

Source: opensc
Severity: important

I have maintained opensc via NMUs for some time because Eric who is the 
only member of the OpenSC Maintainers did not respond. I intend to 
salvage the package as requests to join the team were not answered either.




Bug#1050140: qemu: CVE-2023-40360

2023-08-20 Thread Salvatore Bonaccorso
Source: qemu
Version: 1:8.0.4+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.com/qemu-project/qemu/-/issues/1815
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for qemu.

CVE-2023-40360[0]:
| QEMU through 8.0.4 accesses a NULL pointer in nvme_directive_receive
| in hw/nvme/ctrl.c because there is no check for whether an endurance
| group is configured before checking whether Flexible Data Placement
| is enabled.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-40360
https://www.cve.org/CVERecord?id=CVE-2023-40360
[1] https://gitlab.com/qemu-project/qemu/-/issues/1815
[2] 
https://gitlab.com/qemu-project/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98

Regards,
Salvatore



Bug#1050139: pam-p11: New upstream versions

2023-08-20 Thread Bastian Germann

Source: pam-p11
Version: 0.3.1-1.2
Severity: important

Please import the current version which is 0.5.0 currently.



Bug#1050138: rust-wasmer-enumset-derive should not be in trixie

2023-08-20 Thread Peter Michael Green

Package: rust-wasmer-enumset-derive
Version: 0.5.0-2
Severity: serious
Tags: trixie, sid

rust-wasmer-enumset-derive and it's reverse dependency 
rust-wasmer-enumset are an abandoned fork of rust-enumset-dervive and 
rust-enumset, no applications use them anymore so there is no reason to 
keep them around creating more busywork for the rust team to prevent 
them blocking semver transitions.




Bug#894892: libkscreenlocker5: unable to unlock locked screen ("unlocking failed")

2023-08-20 Thread Patrick Franz
Hi Hans,

On Tue, 15 Aug 2023 16:53:52 +0200 "Hans-J. Ullrich" 
 wrote:
[...]
> I hope, this might help though, although it is not much usefull
> information in this report.

Unless you can find some error message in e.g. your syslog, there isn't 
really much a maintainer can do.

The best thing would probably be to report the bug upstream at
https://bugs.kde.org/ if that hasn't been done yet. They know much 
better how to debug this error. I'm sorry that I cannot do more than 
that.


-- 
Med vänliga hälsningar

Patrick Franz



Bug#1040655: liblmdb-file-perl: FTBFS with Perl 5.38: undefined reference to `Perl_do_vecget'

2023-08-20 Thread Niko Tyni
Control: tag -1 patch

On Sat, Jul 08, 2023 at 07:17:23PM +0300, Niko Tyni wrote:
> Source: liblmdb-file-perl
> Version: 0.12-4
> Severity: important
> Tags: ftbfs trixie sid upstream
> Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=148421
> User: debian-p...@lists.debian.org
> Usertags: perl-5.38-transition
> 
> This package fails to build with Perl 5.38 (currently in experimental).

>   /usr/bin/ld: LMDB.o: in function `XS_LMDB_File__cmp':
>   ././LMDB.c:2731: undefined reference to `Perl_do_vecget'

Here's a patch I just sent upstream that works around this by copying
a simplified version of Perl_do_vecget into this module.
-- 
Niko Tyni   nt...@debian.org
>From 1469c3d13a99f401ac2457b37564bc7aedcf050a Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sat, 19 Aug 2023 21:08:33 +0100
Subject: [PATCH] Lift vecget function from Perl core for 5.38 compatibility
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

As suggested by Petr Písař.

Simplified to only handle size <= 8 as the module only needs size==2.

Bug: https://rt.cpan.org/Ticket/Display.html?id=148421
Bug-Debian: https://bugs.debian.org/1040655
---
 LMDB.xs | 45 -
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/LMDB.xs b/LMDB.xs
index f474abb..647e463 100644
--- a/LMDB.xs
+++ b/LMDB.xs
@@ -110,6 +110,49 @@ S_mySvPVutf8(pTHX_ SV *sv, STRLEN *const len) {
 
 typedef IV MyInt;
 
+/* lifted from Perl core and simplified [rt.cpan.org #148421] */
+STATIC UV
+my_do_vecget(pTHX_ SV *sv, STRLEN offset, int size)
+{
+STRLEN srclen;
+const I32 svpv_flags = ((PL_op->op_flags & OPf_MOD || LVRET)
+  ? SV_UNDEF_RETURNS_NULL : 0);
+unsigned char *s = (unsigned char *)
+SvPV_flags(sv, srclen, (svpv_flags|SV_GMAGIC));
+UV retnum = 0;
+
+if (!s) {
+  s = (unsigned char *)"";
+}
+
+/* aka. PERL_ARGS_ASSERT_DO_VECGET */
+assert(sv);
+/* sanity checks to make sure the premises for our simplifications still hold */
+assert(LMDB_OFLAGN <= 8);
+if (size != LMDB_OFLAGN)
+Perl_croak(aTHX_ "This is a crippled version of vecget that supports size==%d (LMDB_OFLAGN)", LMDB_OFLAGN);
+
+if (SvUTF8(sv)) {
+if (Perl_sv_utf8_downgrade_flags(aTHX_ sv, TRUE, 0)) {
+/* PVX may have changed */
+s = (unsigned char *) SvPV_flags(sv, srclen, svpv_flags);
+}
+else {
+Perl_croak(aTHX_ "Use of strings with code points over 0xFF"
+ " as arguments to vec is forbidden");
+}
+}
+
+STRLEN bitoffs = ((offset % 8) * size) % 8;
+STRLEN uoffset = offset / (8 / size);
+
+if (uoffset >= srclen)
+return 0;
+
+retnum = (s[uoffset] >> bitoffs) & nBIT_MASK(size);
+return retnum;
+}
+
 static void
 populateStat(pTHX_ HV** hashptr, int res, MDB_stat *stat)
 {
@@ -152,7 +195,7 @@ typedef struct {
 
 START_MY_CXT
 
-#define LMDB_OFLAGS TOHIWORD(Perl_do_vecget(aTHX_ MY_CXT.OFlags, dbi, LMDB_OFLAGN))
+#define LMDB_OFLAGS TOHIWORD(my_do_vecget(aTHX_ MY_CXT.OFlags, dbi, LMDB_OFLAGN))
 #define MY_CMP   *av_fetch(MY_CXT.Cmps, MY_CXT.curdb, 1)
 #define MY_DCMP	 *av_fetch(MY_CXT.DCmps, MY_CXT.curdb, 1)
 
-- 
2.39.1



Bug#1013165: No longer interested

2023-08-20 Thread Ben Westover
Control: retitle -1 RFP: python-certbot-dns-freenom -- Freenom DNS01 plugin for 
certbot
Control: noowner -1

I don't use Freenom anymore, so I'm not interested in this package now.
If anyone is, my existing work is available at [1] for anyone to pick
up. Note that Freenom users can simply use the standard ACME DNS setup
now that Freenom doesn't bug out setting the DNS record for it, so this
hook is pretty much obsolete.

--
Ben Westover

[1] https://salsa.debian.org/letsencrypt-team/certbot/certbot-dns-freenom


OpenPGP_signature.asc
Description: PGP signature


Bug#1037557: Acknowledgement (plasma-workspace: krunner crash almost everytime when start typing)

2023-08-20 Thread Patrick Franz
Hi,

FYI, I've requested plasma-workspace to be updated in Debian Stable and 
will upload the fix to bookworm once the request is approved.


-- 
Med vänliga hälsningar

Patrick Franz



Bug#1050137: gparted: New upstream version v1.5.0 available

2023-08-20 Thread Michael Prokop
Package: gparted
Version: 1.3.1-1
Severity: wishlist

Hi,

https://gparted.org/news.php reports v1.5.0-1 as latest stable
release, available since 2023-02-22 (and the v1.4.0 releases is
available since 2022-03-28).

regards
-mika-



Bug#1050136: librust-darling-dev is no longer installable

2023-08-20 Thread Adrian Bunk
Package: librust-darling-dev
Version: 0.14.1-1
Severity: serious
Tags: trixie sid

The following packages have unmet dependencies:
 librust-darling-dev : Depends: librust-darling-core-0.14.1+default-dev
   Depends: librust-darling-macro-0.14.1+default-dev



Bug#963151: rebuild helps

2023-08-20 Thread Nicolai Lissner
This bug comes from the system wherever the package is built
it must have some stale older version of libztd or something.

When built on a CLEAN debian-stable, the result is a 
binary that used the header of the libzstd version actually available
in debian-stable → it doesn't have this problem.

So. the problem is not the build-scripts, it's not the tor sources
it's the system that used the build scripts. 

DO NOT ASK torproject to hide this. fix the issue.

Which is as simple as use a plain debian stable to build, with
the libzstd-dev from stable and it's fine. 

Thanks! 

-- 



Bug#1049434: gtk4: FTBFS on riscv64: SIGSEGV in gtk:gtk / templates test

2023-08-20 Thread Jeremy Bícha
On Tue, Aug 15, 2023 at 4:36 PM Aurelien Jarno  wrote:
> | 262/722 gtk:gtk / templates 
> ERROR 8.58s   killed by signal 5 SIGTRAP
> >
>
> I am also able to reproduce the issue on amd64 (although mostly with
> SIGTRAP, only rarely SIGSEGV), when not using a separate $HOME directory
> like done in debian/run-tests.sh.

I have personally experienced the gtk4 templates build test failure
consistently in my local sbuild since at least January.

Thank you,
Jeremy Bícha



Bug#1026335: Squashing the last carl9170fw issues: ready for sponsorship

2023-08-20 Thread John Scott
On Wed, 2023-08-16 at 12:28 +0800, Paul Wise wrote:
> On Sun, 2023-08-13 at 11:51 +, John Scott wrote:
> 
> > Because carl9170 is largely under the GPL and we're obligated to distribute complete sources for our binaries, I've set Static-Built- Using on both gcc (because of libgcc) and Newlib.
> 
> FYI, that wasn't the correct thing to do.
> Built-Using is for license compliance cases:
> [https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using](https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using)
> Static-Built-Using is for other static linking or embedding cases.
> The static linking wiki page needs updates for Static-Built-Using and the predecessors of it used by the Rust and Golang packages.
> [https://wiki.debian.org/StaticLinking](https://wiki.debian.org/StaticLinking)

Apologies for my delayed response on this, it looks like you are absolutely right Paul. Good eye! This isn't an obvious thing, so I will do my part to make sure the dpkg manual page gets clarified. Just to be clear, preparing a second version of a package and uploading to NEW is okay to fix an important issue, right? While I'm at it, I have been informed by the Debian Installer folks that I can remove the udeb: existing practice is that firmware packages are tiny enough already that they don't bother making udebs for the Debian Installer, that's what the d-i folks say.

I'm preparing a fixed package based on a new upstream snapshot, [have uploaded to mentors.debian.net](https://mentors.debian.net/debian/pool/main/c/carl9170fw/carl9170fw_1.9.9-450-gad1c721-1.dsc), and it's in Git too for whoever here is able and willing to nab it.

Thanks everyone

--  
Homepage: [johnscott.me](https://johnscott.me)  
Contact info: [as a vCard](https://johnscott.me/me/me.vcf) and [as an LDAP directory entry](ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me)



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


Bug#1050134: rust-leptonica-plumbing - autopkgtest depends on non-existent virtual package.

2023-08-20 Thread Peter Michael Green

Package: rust-leptonica-plumbing
Version: 1.0.1-4
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-leptonica-plumbing/36970458/log.gz


118s The following packages have unmet dependencies:
118s  autopkgtest-satdep : Depends: librust-leptonica-plumbing-1.0+default-dev 
but it is not installable
118s E: Unable to correct problems, you have held broken packages.
118s autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt 
install on test deps directly for further data about failing dependencies in 
test logs

librust-leptonica-plumbing-dev provides 
|librust-leptonica-plumbing-1+default-dev and||
librust-leptonica-plumbing-1.0-dev but not 
|librust-leptonica-plumbing-1.0+default-dev


Bug#1015974: Should gnat-gps be removed?

2023-08-20 Thread Bastian Germann
On Sat, 30 Jul 2022 12:59:43 +0200 Ludovic Brenta 
 wrote:

Upstream has finally migrated gnat-gps to python 3 but too late for
Debian 11.

We will package the new upstream version as part of the next Ada
transition (to gnat-12 or gnat-13).  In the mean time, this package will
remain in unstable.


It is now a year and both gnat tansitions have happend.
Would you please consider updating?



Bug#1050133: xserver-xorg-video-nouveau: coredump on start after upgrade to bookworm

2023-08-20 Thread Jens Harbott
Package: xserver-xorg-video-nouveau
Version: 1:1.0.17-2
Severity: important
X-Debbugs-Cc: m...@jayr.de

Dear Maintainer,

after upgrading from bullseye to bookworm, X fails to start, showing this 
backtrace:

[   303.231] (EE) Backtrace:
[   303.231] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x555767c1cd29]
[   303.231] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) 
[0x7fddc125afd0]
[   303.232] (EE) 2: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x4406c) [0x7fddbf56c2fc]
[   303.232] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x1e4c9) [0x7fddbf546759]
[   303.232] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x266) [0x7fddbf5284f6]
[   303.232] (EE) unw_get_proc_name failed: no unwind info found [-10]
[   303.232] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so (?+0x0) 
[0x7fddbecaaf76]
[   303.232] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(__driDriverGetExtensions_d3d12+0x61dab4) [0x7fddbf2c8ff4]
[   303.232] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(__driDriverGetExtensions_d3d12+0x1a93) [0x7fddbecacfd3]
[   303.232] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(__driDriverGetExtensions_d3d12+0xa1a5) [0x7fddbecb56e5]
[   303.233] (EE) 9: /lib/x86_64-linux-gnu/libgbm.so.1 
(gbm_format_get_name+0xf2e) [0x7fddc0bdbeae]
[   303.233] (EE) 10: /lib/x86_64-linux-gnu/libgbm.so.1 
(gbm_format_get_name+0x16f8) [0x7fddc0bdc678]
[   303.233] (EE) unw_get_proc_name failed: no unwind info found [-10]
[   303.233] (EE) 11: /lib/x86_64-linux-gnu/libgbm.so.1 (?+0x0) [0x7fddc0bda74c]
[   303.233] (EE) 12: /lib/x86_64-linux-gnu/libgbm.so.1 
(gbm_create_device+0x44) [0x7fddc0bda884]
[   303.234] (EE) 13: /usr/lib/xorg/modules/libglamoregl.so 
(glamor_egl_init+0x61) [0x7fddc08ab3c1]
[   303.234] (EE) unw_get_proc_name failed: no unwind info found [-10]
[   303.234] (EE) 14: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) 
[0x7fddc08e4733]
[   303.234] (EE) 15: /usr/lib/xorg/Xorg (InitOutput+0x952) [0x555767aec4c2]
[   303.234] (EE) 16: /usr/lib/xorg/Xorg (InitFonts+0x1ce) [0x555767aad4de]
[   303.234] (EE) 17: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) 
[0x7fddc12461ca]
[   303.235] (EE) 18: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) 
[0x7fddc1246285]
[   303.235] (EE) 19: /usr/lib/xorg/Xorg (_start+0x21) [0x555767a96b71]
[   303.235] (EE) 
[   303.235] (EE) Segmentation fault at address 0x20

For crosschecking I installed the nvidia-driver pkg, with this the X server is
working without issues again so far.


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/powerpc64le-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of 

Bug#1050132: rust-hyper-rustls - debian/tests/control still references rustls 0.20

2023-08-20 Thread Peter Michael Green

Package: rust-hyper-rustls
Version: 0.24.1-2
Severity: minor

debian/tests/control in rust-hyper-rustls still refers to rustls 0.20, 
even though

the package itself is now using rustls 0.21.



Bug#1040433: Interest in maintaining the package

2023-08-20 Thread Mae Miller
Hi! I saw your bug report requesting a new maintainer for the anki
package and while I'm new to maintaince, this project seems like it
could be a good one to sink my teeth into since I have interest in a
working anki package for my university work.



Bug#1050130: RFS: filezilla/3.63.0-1+deb12u2 -- Full-featured graphical FTP/FTPS/SFTP client

2023-08-20 Thread Phil Wyett
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : filezilla
   Version  : 3.63.0-1+deb12u2
   Upstream contact : Tim Kosse 
 * URL  : https://filezilla-project.org/
 * License  : GPL-2+, MIT, permissive, BSD-like, CC0-1.0
 * Vcs  : https://salsa.debian.org/debian/filezilla
   Section  : net

The source builds the following binary packages:

  filezilla - Full-featured graphical FTP/FTPS/SFTP client
  filezilla-common - Architecture independent files for filezilla

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.63.0-1+deb12u2.dsc

Changes since the last upload:

 filezilla (3.63.0-1+deb12u2) bookworm; urgency=medium
 .
   * Add patch: 0003-crash-when-removing-filetypes-from-list.patch
(Closes: #1043556)

Regards

Phil

-- 
Playing the game for the games sake.

* Debian Maintainer

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org

Social:

* Twitter: kathenasorg
* Instagram: kathenasorg




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


Bug#1029814: RM: ixp4xx-microcode -- RoQA; ixp4xx support dropped in 2014

2023-08-20 Thread Bastian Germann

Control: retitle -1 RM: ixp4xx-microcode -- RoQA; ixp4xx support dropped in 2014
Control: reassign -1 ftp.debian.org
Control: severity -1 normal

Please remove ixp4xx-microcode. It is no longer useful for Debian as it targets long-unsupported 
hardware.




Bug#1028643: fontconfig: default latin fonts changed from DejaVu to Noto

2023-08-20 Thread Gunnar Hjalmarsson

I think this change:

https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/6fae069d

is relevant to this discussion.

--
Cheers,
Gunnar Hjalmarsson



Bug#1044293: fontconfig: Fails to build source after successful build

2023-08-20 Thread Gunnar Hjalmarsson

Control: tags -1 + pending

Fixed in repo:

https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/409318ef



Bug#1049862: bookworm-pu: package efibootguard/0.13-2+deb12u1

2023-08-20 Thread Jonathan Wiltshire
Control: tag -1 confirmed

On Wed, Aug 16, 2023 at 11:41:00AM +0200, Bastian Germann wrote:
> [ Reason ]
> This backports the fix for CVE-2023-39950 to bookworm.
> The Security Team told us to go the stable-pu route.

Please go ahead.

>   [x] the issue is verified as fixed in unstable

It would have been helpful to mention this issue and/or the CVE identifier
in the unstable upload if possible, so that this is easier to verify.
I realise it may not have had a CVE or been explicitly mentioned upstream
at the time it was uploaded though.

Thanks,

-- 
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#1049336: bookworm-pu: package filezilla/3.63.0-1+deb12u2

2023-08-20 Thread Jonathan Wiltshire
Control: tag -1 confirmed

On Mon, Aug 14, 2023 at 12:49:47PM +0100, Phil Wyett wrote:
> [ Reason ]
> Crash when removing file types from list in packages configuration.

Please go ahead.

Thanks,


-- 
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#1049379: freedombox 23.6.2+deb12u1 flagged for acceptance

2023-08-20 Thread Jonathan Wiltshire
package release.debian.org
tags 1049379 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: freedombox
Version: 23.6.2+deb12u1

Explanation: use n= in apt preferences for smooth upgrades



Bug#1050034: [Debian-med-packaging] Bug#1050034: RM: tnseq-transit [s390x] -- ROM; wrong results on big endian systems caught by build-time tests

2023-08-20 Thread Graham Inggs
Hi Étienne

On Fri, 18 Aug 2023 at 16:45, Étienne Mollier  wrote:
> Please remove tnseq-transit for the s390x architecture in
> unstable, as the newer version fails its test suite on intricate
> computational errors on big endian systems, as seen in the build
> log[1].  This package has no reverse dependencies.
>
> [1]: 
> https://buildd.debian.org/status/fetch.php?pkg=tnseq-transit=s390x=3.3.0-1=1691922911=1

The s390x build succeeded when given back [2].  Are the tests just flaky?

Regards
Graham


[2] 
https://buildd.debian.org/status/fetch.php?pkg=tnseq-transit=s390x=3.3.0-1=1692537365=0



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

2023-08-20 Thread Jonathan Wiltshire
| diff -Nru mariadb-10.11.3/debian/changelog mariadb-10.11.4/debian/changelog
| --- mariadb-10.11.3/debian/changelog  2023-05-28 06:16:42.0 +
| +++ mariadb-10.11.4/debian/changelog  2023-08-03 03:08:31.0 +
| @@ -1,3 +1,18 @@
| +mariadb (1:10.11.4-1~deb12u1) bookworm; urgency=medium
| +
| +  [ Otto Kekäläinen ]
| +  * New upstream version 10.11.4. Includes fixes for several severe 
regressions,
| +see details at https://mariadb.com/kb/en/mariadb-10-11-4-release-notes/
| +  * Duplicate selected Lintian overrides in old Lintian syntax for NEW queue
| +(this might strictly not be needed for bookworm but does not hurt either)
| +  * Extend the transitional package metadata referenced below
| +  * Bump revision to 'u2' to satisfy Debian FTP queue requirements

That last line seems wrong but in the interests of expediency it can be
fixed in retrospect next upload.



-- 
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#1037107: mariadb 10.11.4-1~deb12u1 flagged for acceptance

2023-08-20 Thread Jonathan Wiltshire
package release.debian.org
tags 1037107 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: mariadb
Version: 10.11.4-1~deb12u1

Explanation: new upstream bugfix release



Bug#1050085: RFS: vnstat/2.11-1 -- console-based network traffic monitor

2023-08-20 Thread Christian Göttsche
Control: tags -1 -moreinfo

On Sat, 19 Aug 2023 at 18:51, Jeroen Ploemen  wrote:
>
> one minor issue:
> * copyright: years outdated for upstream only
>
>
> Please remove the moreinfo tag (and CC me directly) once you have an
> updated package ready.

Done.
Also added a patch regarding a Lintian issue about a groff warning.



Bug#1050118: 7zip-standalone/experimental: undeclared file conflict with 7zip/bookworm+trixie+unstable

2023-08-20 Thread Helmut Grohne
On Sun, Aug 20, 2023 at 06:41:20PM +0900, yokota wrote:
> > 7zip-standalone and 7zip both ship /usr/bin/7zip, but they do not
> > declare any Conflicts, Replaces or diversions to alleviate that
> > situation. As a consequence, an unpack error may result when attempting
> > to install both.
> >
> > Given the changelog entry saying "split", I think you meant to move
> > files between packages. In this case, please ensure that you set both
> > Breaks and Replaces.
> 
> 7zip and 7zip-standalone dose not provides /usr/bin/7zip.

I'm sorry. I failed at copy and pasting. The conflicting file is
/usr/bin/7zz.

> They provides:
>   7zip: 7z, 7za, 7zr, p7zip
>   7zip-standalone: 7zz

This is true for experimental. In older versions, 7zip contains 7zz. The
problem arises from unpacking an old version of 7zip concurrently with a
current version of 7zip-standalone.

> And 7zip-standalone requires "7zip (= ${binary:Version})" and 7zip
> breaks/conflicts/replaces "p7zip (<= 16.02+dfsg-8)".

The dependency you mention here removes the need to issue Breaks, but
you can still unpack those packages together even when their
dependencies are unsatisfied. You still need to declare "Replaces: 7zip
(<< 23.01+dfsg-4~)".

> I think it works at least on my machine.

Please try dpkg --unpack 7zip-standalone_23.01+dfsg-4~exp1_amd64.deb
7zip_23.01+dfsg-3_amd64.deb.

Helmut



Bug#1017577: sqlcipher: new upstream version available

2023-08-20 Thread Petter Reinholdtsen
I would also like a newer versoin of sqlcipher with encryption support,
as described on 
https://www.yoranbrondsema.com/post/the-guide-to-extracting-statistics-from-your-signal-conversations/#2-decrypt-and-convert-the-sqlite-database-to-csv
 >.

-- 
Happy hacking
Petter Reinholdtsen



Bug#1050128: gnome-tweaks: Cursor theme is searched in .icons folder instead of .local/share/icons

2023-08-20 Thread Vladimir
Package: gnome-tweaks
Version: 42~beta-4
Severity: minor
X-Debbugs-Cc: awesome149...@gmail.com

Dear Maintainer,

So, I'm using gnome DE and I wanted to have custom cursor theme.
Using google all I found is that to install cursor theme (as user) I need to
put it in .local/share/icons folder.
Theme also can be installed in /usr/share/icons, but I find that method less
suitable for me.

After moving cursor theme to .local/share/icons and launching gnome tweaks I
found the theme in Appearance/Themes/Cursor.
Then I selected installed theme and restarted gnome shell (Alt-F2, typed "r").
I found that cursor theme was still default Adwaita, but, as you can imagine, I
expected custom theme to be applied.

After more searching I discovered that .icons folder can be used instead
(https://www.reddit.com/r/debian/comments/14tykuk/cursor_themes_placed_under_localshareicons_does/).
I symlinked .icons to .local/share/icons and it worked, actually.
The fact that cursor theme is recognized when put in .local/share/icons, but
can't be really applied was somewhat confusing.


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

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

Versions of packages gnome-tweaks depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-gnomedesktop-3.0  43.2-2
ii  gir1.2-gtk-3.0   3.24.37-2
ii  gir1.2-handy-1   1.8.1-1
ii  gir1.2-notify-0.70.8.1-1
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gnome-settings-daemon43.0-4
ii  gnome-shell-common   43.6-1~deb12u1
ii  gsettings-desktop-schemas43.0-1
ii  mutter-common43.6-1~deb12u1
ii  python3  3.11.2-1+b1
ii  python3-gi   3.42.2-3+b1

gnome-tweaks recommends no packages.

Versions of packages gnome-tweaks suggests:
ii  gnome-shell-extension-prefs  43.6-1~deb12u1

-- no debconf information



Bug#1050127: crack-attack: Missing Sound files

2023-08-20 Thread Mr. T
Package: crack-attack
Version: 1.1.14-9.1+b2
Severity: important
X-Debbugs-Cc: t...@treaki.tk

Dear Maintainer,

i installed crack attack using the package provided in my debian system,
but it lookes like there are some soundfiles missing:

$ crack-attack --solo --name MrT
Crack Attack! v1.1.14

WARNING *** Unable to open countdown.wav
WARNING *** Unable to open block_fallen.wav
WARNING *** Unable to open block_awaking.wav
WARNING *** Unable to open block_dying.wav
WARNING *** Unable to open garbage_fallen.wav
WARNING *** Unable to open garbage_shattering.wav
freeglut  ERROR:  Function  called without first calling 
'glutInit'.


please fix that so that the software is able to find the files (possible
missed some cp before package creation or so)

thanks and keep up the good work

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

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

Versions of packages crack-attack depends on:
ii  freeglut3   2.8.1-6
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.31-13+deb11u6
ii  libcairo2   1.16.0-5
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1+deb11u1
ii  libgcc-s1 [libgcc1] 10.2.1-6
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libgl1  1.3.2-1
ii  libglib2.0-02.66.8-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libgtk2.0-0 2.24.33-2
ii  libice6 2:1.0.10-1
ii  libpango-1.0-0  1.46.2-3
ii  libpangocairo-1.0-0 1.46.2-3
ii  libpangoft2-1.0-0   1.46.2-3
ii  libsdl-mixer1.2 1.2.12-16+b1
ii  libsdl1.2debian 1.2.15+dfsg2-6
ii  libsm6  2:1.2.3-1
ii  libstdc++6  10.2.1-6
ii  libx11-62:1.7.2-1+deb11u1
ii  libxi6  2:1.7.10-1
ii  libxmu6 2:1.1.2-2+b3

crack-attack recommends no packages.

crack-attack suggests no packages.

-- no debconf information



Bug#1050069: RM: llvm-toolchain-14 -- ROM; Too many version of llvm

2023-08-20 Thread Ilias Tsitsimpis
Hi Sylvestre,

Can we please keep llvm-toolchain-14 in unstable? GHC 9.4.6 (which is
the latest version used in stackage LTS, see https://www.stackage.org/)
uses LLVM-14. I tried using LLVM-16 and it failed (see version
9.4.6-1~exp2 in experimental).

I plan to upload GHC 9.4.6 in unstable over the next days.

Thanks,

-- 
Ilias



Bug#1050126: bookworm-pu: package marco/1.26.1-3+deb12u2

2023-08-20 Thread Mike Gabriel
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ma...@packages.debian.org
Control: affects -1 + src:marco

In MATE's window manager marco an annoying issue was introduced with
marco's version in Debian bullseye (iirc). If compositing was
enabled in gsettings, there would be nice shadows around windows
on local displays, but black frames (instead of the shadows)
around windows when MATE was run in an X2Go session.

Mihai Moldovan now worked on a fix for this and we'd like to bring
his patches to marco in Debian bookworm (so the X2Go user experience
is without black shadows around windows).

As a side note: to hide (work-around) this flaw in Debian 12, the default
setting for compositing in MATE had been switched to off.

[ Reason ]
Make MATE well usable in X2Go without the need of disabling compositing
in its WM. So, local sessions can run with compositing enabled while
it gets switch to off automatically when running in a remote session
(e.g. X2Go) that does not support compositing.

[ Impact ]
When using MATE with compositing enabled, black frames around windows
appear when using MATE over X2Go.

[ Tests ]
Manual tests (local, remote MATE session).

[ Risks ]
Minimal, regressions can be possible. The patches have also already been
accepted by MATE upstream.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

+  * debian/patches:
++ Add 0001_check-availability-of-compositing-1.patch and
+  0002_check-availability-of-compositing-2.patch. Check that compositing
+  is not only requested, but also available.
+
+  Enabling code that is supposed to be used in compositing conditions is
+  harmful if compositing is not actually available. Just checking the
+  preference is not enough to make sure that compositing is available -
+  the X server might be missing crucial extensions for compositing to
+  work, which in turn correctly disables the internal compositor.
+
+  The end result is graphical issues like black borders around windows in
+  such situations.
+
+  Make sure that compositing is both requested AND available to fix this
+  bug.
+
+  This resolves an annoying issue when running MATE desktop in X2Go
+  sessions with the x2goagent (nx-libs) Xserver backend.

-> these are the patches that fix marco in X2Go sessions...

+  * debian/:
++ Drop black-frame-in-X2Go-sessions-workaround, re-enable compositing by
+  default again. This drops the gsettings override
+  20_marco-debian.gschema.override.

This removes the work-around that we introduced in Debian 12. Dropping
this gsettings override reinstates marco's compositing settings as
present in Debian 11.


[ Other info ]
This change will be helpful to MATE in Debian Edu where we use X2Go for
thinclients that connect to remote sessions running MATE or Xfce. As a
side note, for Xfce we also have a patch fixing a similar issue in xfwm.
diff -Nru marco-1.26.1/debian/20_marco-debian.gschema.override 
marco-1.26.1/debian/20_marco-debian.gschema.override
--- marco-1.26.1/debian/20_marco-debian.gschema.override2023-04-25 
16:04:32.0 +0200
+++ marco-1.26.1/debian/20_marco-debian.gschema.override1970-01-01 
01:00:00.0 +0100
@@ -1,2 +0,0 @@
-[org.mate.Marco.general]
-compositing-manager=false
diff -Nru marco-1.26.1/debian/changelog marco-1.26.1/debian/changelog
--- marco-1.26.1/debian/changelog   2023-07-10 06:47:02.0 +0200
+++ marco-1.26.1/debian/changelog   2023-08-19 21:31:53.0 +0200
@@ -1,3 +1,31 @@
+marco (1.26.1-3+deb12u2) bookworm; urgency=medium
+
+  * debian/patches:
++ Add 0001_check-availability-of-compositing-1.patch and
+  0002_check-availability-of-compositing-2.patch. Check that compositing
+  is not only requested, but also available.
+
+  Enabling code that is supposed to be used in compositing conditions is
+  harmful if compositing is not actually available. Just checking the
+  preference is not enough to make sure that compositing is available -
+  the X server might be missing crucial extensions for compositing to
+  work, which in turn correctly disables the internal compositor.
+
+  The end result is graphical issues like black borders around windows in
+  such situations.
+
+  Make sure that compositing is both requested AND available to fix this
+  bug.
+
+  This resolves an annoying issue when running MATE desktop in X2Go
+  sessions with the x2goagent (nx-libs) Xserver backend.
+  * debian/:
++ Drop black-frame-in-X2Go-sessions-workaround, re-enable compositing by
+  default again. This drops the gsettings override
+  20_marco-debian.gschema.override.
+
+ -- Mike Gabriel   Sat, 19 Aug 2023 

Bug#1017663: ghc: Please upgrade to llvm-toolchain-14

2023-08-20 Thread Ilias Tsitsimpis
Control: retitle -1 Please upgrade to llvm-toolchain-14

I propose we keep this bug (which is also marked as Serious), to track
the migration to llvm-toolchain-14 (since llvm-toolchain-13 does no
longer build in unstable).

I tried using llvm-toolchain-16 with GHC 9.4.6-1~exp2 but it failed
(build logs at [1]). The plan is to use llvm-toolchain-14 in GHC 9.4.6.
Please open a new bug report to track the migration to llvm-toolchain-16.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=ghc=armel=9.4.6-1%7Eexp2=1692531678=0

Thanks,

-- 
Ilias



Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)

2023-08-20 Thread Graham Inggs
Hi Andreas

On Wed, 16 Aug 2023 at 11:24, Andreas Tille  wrote:
> Am Tue, Aug 01, 2023 at 01:06:41PM + schrieb Graham Inggs:
> > At least the following packages are failing their own autopkgtests in
> > unstable (list not complete):
> > r-bioc-cummerbund
> > r-bioc-decoupler
> > r-bioc-monocle
> > r-bioc-scran
> > r-bioc-singler
>
> Most of those packages have autopkgtests marked as
>Failed (not a regression)
> Am I correct that we do not need to take any action regarding the
> transition?

Well, it means those autopkgtests already regressed in testing, but
they do not block migration.
Now that r-bioc-biocgenerics has migrated, you can see that at least
r-bioc-cummerbund, r-bioc-scran and r-bioc-singler are still blocked
by other packages which need attention.

> > r-bioc-dupradar has regressed from passing to neutral, apparently due
> > to the use of 'skip-not-installable'.  Please don't use this
> > restriction on all the autopkgtests in a package, otherwise there are
> > no tests which are not superficial, and regressions can migrate to
> > testing.
>
> Could you please be more verbose about this hint (may be suggesting a
> patch that implements your suggestion since I'm afraid I do not
> understand this correctly)

--- a/debian/tests/autopkgtest-pkg-r.conf
+++ b/debian/tests/autopkgtest-pkg-r.conf
@@ -2,4 +2,3 @@
   r-cran-knitr, \
   r-cran-rmarkdown, \
   r-bioc-annotationhub
-extra_restrictions=skip-not-installable

In general, skip-not-installable is no good as it does not catch when
packages are non-installable, and during that time, it can hide other
regressions and allow them to migrate.  It may have some special use
cases; e.g. a test depending on a package that is only available in
unstable (virtualbox or openjdk-8), but skip-not-installable should
not be applied to a package's only autopkgtest, or all of them, only
the one that actually requires it.

On Fri, 18 Aug 2023 at 10:40, Andreas Tille  wrote:
> I've fixed r-bioc-decoupler manually to remove this blocker quickly
> (instead of working around invalid version specifications by detecting
> these in dh-r)

Thanks!  elbrus marked r-bioc-decoupler urgent, and rather than being
blocked by the autopkgtest regression of r-bioc-metagenomeseq, I
removed 1.40.0-1 from testing (previously removed on 2023-07-16, but
somehow migrated again) to allow r-bioc-biocgenerics to migrate.

> Do you see any other blocker?

Besides those packages mentioned above, there are others still needing
attention.  These can be seen on the team's DDPO page [1], just search
for 'Excuse' there.

Regards
Graham


[1] 
https://qa.debian.org/developer.php?email=r-pkg-team%40alioth-lists.debian.net



Bug#1049919: #1049919 installation-guide: add information about how to append boot parameters to the installer?

2023-08-20 Thread Holger Wansing
Control: reassign -1 installation-guide
-- 
Sent from /e/ OS on Fairphone3



Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken

2023-08-20 Thread Ansgar
Hi,

On Sat, 2023-08-19 at 11:17 +0200, Vincent Lefevre wrote:
> First, I initially wasn't aware that this was assuming usrmerge:
> there was no announce at all. Moreover, doing partial upgrades
> is not breaking the system. This is perfectly allowed. That's why
> there is a dependency system, and here, no Depends or Recommends
> was broken.

No, packages in testing/unstable will expect essential packages to come
from stable or later without explicit versioned dependencies.

If you mix oldstable + unstable packages, you create an unsupportable
system state ("Frankendebian").  If something then breaks, you get to
fix it yourself; don't expect others to support such a setup.

Ansgar



Bug#1050124: bookworm-pu: package vte2.91/0.70.6-2~deb12u1

2023-08-20 Thread Simon McVittie
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: vte2...@packages.debian.org
Control: affects -1 + src:vte2.91

I've uploaded another proposed vte2.91 update for bookworm. Please consider
this for 12.2.

[ Reason ]
#1040049

[ Impact ]
If not fixed, there is a crash with an assertion failure that occurs
frequently in some user workflows (I've never been able to reproduce it
myself, but the bug reporter Luca Boccassi saw it frequently).

[ Tests ]
Luca has been running a prerelease version of this update (identical except
for version number) for several weeks, and has not seen the bug again.
Available from: https://people.debian.org/~smcv/12.2/pool/main/v/vte2.91/

A functionally equivalent version was in testing for about 1 week before
being superseded by a newer upstream release, with no regression reports.
The version proposed here is a straightforward rebuild of that version
for bookworm.

[ Risks ]
Low risk: targeted fix from upstream which just invalidates caches more
often.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
All changes are for #1040049, no extraneous diff present.
diffstat for vte2.91-0.70.6 vte2.91-0.70.6

 debian/changelog  |   17 ++
 debian/patches/series |1 
 debian/patches/widget-Invalidate-ringview-when-the-invalidating.patch |   69 
++
 src/vte.cc|   13 +
 4 files changed, 100 insertions(+)

diff -Nru vte2.91-0.70.6/debian/changelog vte2.91-0.70.6/debian/changelog
--- vte2.91-0.70.6/debian/changelog 2023-06-14 12:17:06.0 +0100
+++ vte2.91-0.70.6/debian/changelog 2023-08-09 13:01:27.0 +0100
@@ -1,3 +1,20 @@
+vte2.91 (0.70.6-2~deb12u1) bookworm; urgency=medium
+
+  * Team upload
+  * Rebuild for bookworm (Closes: #1040049)
+
+ -- Simon McVittie   Wed, 09 Aug 2023 13:01:27 +0100
+
+vte2.91 (0.70.6-2) unstable; urgency=medium
+
+  * Team upload
+  * d/p/widget-Invalidate-ringview-when-the-invalidating.patch:
+Add patch from upstream git to invalidate ring view more often when
+necessary, fixing various assertion failures during event handling
+(Closes: #1040049)
+
+ -- Simon McVittie   Fri, 14 Jul 2023 11:31:40 +0100
+
 vte2.91 (0.70.6-1~deb12u1) bookworm; urgency=medium
 
   * Team upload
diff -Nru vte2.91-0.70.6/debian/patches/series 
vte2.91-0.70.6/debian/patches/series
--- vte2.91-0.70.6/debian/patches/series2023-06-14 12:17:06.0 
+0100
+++ vte2.91-0.70.6/debian/patches/series2023-08-09 13:01:27.0 
+0100
@@ -1 +1,2 @@
+widget-Invalidate-ringview-when-the-invalidating.patch
 Allow-background-color-and-color-on-VteTerminal-widgets-t.patch
diff -Nru 
vte2.91-0.70.6/debian/patches/widget-Invalidate-ringview-when-the-invalidating.patch
 
vte2.91-0.70.6/debian/patches/widget-Invalidate-ringview-when-the-invalidating.patch
--- 
vte2.91-0.70.6/debian/patches/widget-Invalidate-ringview-when-the-invalidating.patch
1970-01-01 01:00:00.0 +0100
+++ 
vte2.91-0.70.6/debian/patches/widget-Invalidate-ringview-when-the-invalidating.patch
2023-08-09 13:01:27.0 +0100
@@ -0,0 +1,69 @@
+From: Egmont Koblinger 
+Date: Thu, 13 Jul 2023 21:59:29 +0200
+Subject: widget: Invalidate ringview when the invalidating
+
+When the ringview is not invalidated when the ring has changed leads to
+failed assertion aborts when handling events, e.g. vte#2636, vte#2637,
+vte#2632, vte#2577.
+
+Bug: https://gitlab.gnome.org/GNOME/vte/-/issues/2636
+Bug: https://gitlab.gnome.org/GNOME/vte/-/issues/2637
+Bug-Debian: https://bugs.debian.org/1040049
+Applied-upstream: 0.73.0, commit:461bc3e43c819fa0e3b62d0cf40ef533a69cc7f7
+---
+ src/vte.cc | 13 +
+ 1 file changed, 13 insertions(+)
+
+diff --git a/src/vte.cc b/src/vte.cc
+index b8e15d7..561cc42 100644
+--- a/src/vte.cc
 b/src/vte.cc
+@@ -2050,6 +2050,7 @@ Terminal::queue_adjustment_value_changed(double v)
+ _vte_debug_print(VTE_DEBUG_ADJ,
+  "Scrolling by %f\n", dy);
+ 
++m_ringview.invalidate();
+ invalidate_all();
+ match_contents_clear();
+ emit_text_scrolled(dy);
+@@ -2899,6 +2900,9 @@ Terminal::drop_scrollback()
+ if (m_screen == _normal_screen) {
+ queue_adjustment_value_changed(m_normal_screen.insert_delta);
+ adjust_adjustments_full();
++m_ringview.invalidate();
++invalidate_all();
++match_contents_clear();
+ }
+ }
+ 
+@@ -7548,6 +7552,9 @@ Terminal::set_size(long columns,
+   gtk_widget_queue_resize(m_widget); // FIXMEgtk4?
+ #endif
+ 
++

Bug#1050113: unblock: rust-rustls-webpki/0.101.3-1.1

2023-08-20 Thread Graham Inggs
Hi

On Sat, 19 Aug 2023 at 23:57, plugwash  wrote:
> The package is blocked by autopkgtest failures on ppc64el and s390x. The 
> reason
> for these failures is that the package (which is arch all) is not installable
> on these architectures because it depends on the ring crate which is not
> currently portable. Please can you override these failures and allow the
> package to migrate to testing.

I added a hint, but rust-rustls-webpki/0.101.3-1.1 was superseded by 0.101.3-2.
I'll look again later.

Regards
Graham



Bug#1049919: #1049919 d-i: pressing ESC in graphical installer does nothing, unable to preseed installation

2023-08-20 Thread Holger Wansing
Control: retitle -1 installation-guide: add information about how to append 
boot parameters to the installer?


Ernesto Alfonso  wrote:
> The docs for preseeding debian recommend pressing ESC after entering
> the graphical installer menu:
> 
> 
> > Loading the preseeding file from a webserver
> > Most install methods you can interrupt early on and add a URL to a preseed 
> > file, for an almost fully automated installations. Here exemplified with 
> > the graphical installer:
> > 
> > When the graphical installer boot menu appears, press ESC
> > 
> > (Type "help" if you want view generic help)
> > Type "auto url=http://webserver/path/preseed.cfg;, replacing the URL with 
> > the address to your preseed configuration file
> > 
> 
> But when pressing ESC after selecting the debian bookworm graphical 
> installer, nothing happens.
> 
> I am using the amd64 DVD-1 ISO image: debian-12.0.0-amd64-DVD-1.iso

I found that you refer to the Debian Wiki at
https://wiki.debian.org/DebianInstaller/Preseed
when you talk about "docs for preseeding debian" above.

Please note, that the Wiki is not the "official" documentation for our 
installer.
That would be the installation-guide, see 
https://www.debian.org/releases/stable/installmanual
A chapter about preseeding installation is at
https://www.debian.org/releases/stable/amd64/apb.en.html

That being said, I see that the information on the Wiki page you mentioned 
is outdated and thus no longer working.
I have updated it now in that regard.




Moreover, I notice that we probably have some deficit in the installation-guide,
when it comes to information about how to append boot parameters to the 
installer
(at least for some architectures).

For amd64 and ii386 that is mentioned in chapter "5.1.5. The Boot Screen"
see https://www.debian.org/releases/stable/amd64/ch05s01.en.html#boot-screen

and s390x has it in "5.1.2. S/390 Boot Parameters"
https://www.debian.org/releases/stable/s390x/ch05s01.en.html

But for all other archs I cannot find any such information.

Would it make sense to add that?
(OTOH, nobody has complained about that for years, so maybe it's not necessary?)


Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076



Bug#1034356: gnome-shell: Frozen UI and massive log flodding

2023-08-20 Thread Simon McVittie
Control: tags -1 + moreinfo

On Thu, 17 Aug 2023 at 09:58:42 +0100, Simon McVittie wrote:
> The key change in gjs seems to be the second commit of
>  so I'll try to
> build a package with that change for testing.

Please could you try installing the libgjs0g from here:

and then do whatever is necessary to reproduce the issue?

The result I'm hoping for from that change is that you will still get
a message like

> Apr 13 14:50:39 schroeder gnome-shell[6317]: Attempting to call back into 
> JSAPI during the sweeping phase of GC. This is most likely caused by not 
> destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, 
> but can also be caused by using the destroy(), dispose(), or remove() vfuncs. 
> Because it would crash the application, it has been blocked and the JS 
> callback not invoked.

but only once (or a small number of times), and the log flooding /
infinite loop will not occur.

If that change is tested successfully then it can be included in a
Debian 12 stable update.

smcv



Bug#1050123: libssh FTBFS on hppa

2023-08-20 Thread Helge Deller

Package: libssh
Tags: ftbfs, hppa
Version: 0.10.5-3

The package sometimes fails to build from source, because it
runs into the "ctest timeout", e.g.:
https://buildd.debian.org/status/fetch.php?pkg=libssh=hppa=0.10.5-3=1692499006=0

The following tests FAILED:
  7 - torture_misc (Timeout)
  9 - torture_options (Timeout)
 11 - torture_knownhosts_parsing (Timeout)
 21 - torture_pki (Timeout)
 22 - torture_pki_rsa (Timeout)
 23 - torture_pki_ed25519 (Timeout)
 25 - torture_bind_config (Timeout)
 27 - torture_pki_ecdsa (Timeout)
 32 - torture_threads_pki_rsa (Timeout)

Default timeout is 1500 sec.
I manually increased it to 4000 and then all tests succeeded.

Can you please increase the timeout on the ctest?
The hppa buildds are sometimes pretty loaded by parallel makes, so
it's not uncommon that the tests fail.

Sadly I don't know how to increase that timeout value, otherwise
I would have added a patch proposal here...

Thanks,
Helge



Bug#1050122: smokeping: CGI script hogs CPU and OOMs on fping graphs with pings=2000

2023-08-20 Thread Marcin Owsiany
Package: smokeping
Version: 2.7.3-4.1
Severity: normal

Dear Maintainer,

I changed the configuration to add an FPing probe flavor with pings=2000
(and step=2100) specified, and a few targets using that probe.

The motication for this is that my ISP considers the number of packets
lost within a 2000-ping sample to be a canonical metric for reliability.
So I would like to collect statistics using this metric in order to have
have data for any complaints in the future.

The backend smokeping process seems to work just fine. The data is being
collected, and the 3 and 30 hour graphs are rendered in reasonable time
(~2s).

However when I go to the 10 day (or longer) graph URL for such target,
the CGI script hogs CPU and eats all available RAM (8GB) until it is
terminated by the OOM-killer after four minutes or so, resulting in a
503 or 504 response from Apache. The longest period I was able to graph
successfully was about 4 days.

Note that the above is with about 18 hours worth of data. The RRD files
for targets with default configuration are about 2.9MB, and the ones for
2000 pings are 248MB.


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

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

Versions of packages smokeping depends on:
ii  adduser3.134
ii  exim4-daemon-light [mail-transport-agent]  4.96-15+deb12u1
ii  fping  5.1-1
ii  init-system-helpers1.65.2
ii  libcgi-fast-perl   1:2.15-1
ii  libconfig-grammar-perl 1.13-5
ii  libdigest-hmac-perl1.04+dfsg-2
ii  libjs-cropper  1.2.2-1.1
ii  libjs-prototype1.7.3-1
ii  libjs-scriptaculous1.9.0-3
ii  librrds-perl   1.7.2-4+b8
ii  libsnmp-session-perl   1.14~git20221124T101957-1
ii  liburi-perl5.17-1
ii  libwww-perl6.68-1
ii  lsb-base   11.6
ii  perl   5.36.0-7
ii  sysvinit-utils [lsb-base]  3.06-4
ii  ucf3.0043+nmu1

Versions of packages smokeping recommends:
ii  apache2 [httpd-cgi]2.4.57-2
ii  bind9-dnsutils [dnsutils]  1:9.18.16-1~deb12u1
ii  dnsutils   1:9.18.16-1~deb12u1
pn  echoping   
ii  libsocket6-perl0.29-3

Versions of packages smokeping suggests:
ii  curl   7.88.1-10+deb12u1
pn  libauthen-radius-perl  
ii  libio-socket-ssl-perl  2.081-2
ii  libnet-dns-perl1.36-1
pn  libnet-ldap-perl   
pn  libnet-telnet-perl 
ii  openssh-client 1:9.2p1-2

-- Configuration Files:
/etc/smokeping/config.d/Probes changed [not included]
/etc/smokeping/config.d/Targets changed [not included]
/etc/smokeping/smokeping_secrets [Errno 13] Brak dostępu: 
'/etc/smokeping/smokeping_secrets'

-- no debconf information


Bug#1028897: fontconfig: wrong name for the Noto monospace font

2023-08-20 Thread Gunnar Hjalmarsson

Control: owner -1 gunna...@debian.org
Control: tags -1 + pending

On 2023-08-19 17:01, Raphaël Halimi wrote:

Le 19/08/2023 à 16:04, Gunnar Hjalmarsson a écrit :

It's worth mentioning that the fonts-noto packages in Debian ship
almost 3 years old fonts. An update to latest upstream would be
highly desirable. Possibly Noto Sans Mono has improved.


I didn't know that. Thanks for mentioning it.

So, I just downloaded NotoSansMono-Regular.ttf from its new home [1]
(the old repository in the Debian copyright file has been archived),
opened it in font-viewer and... Sadly, the spacing is still
"Proportional" and not "Monospace" :(


Thanks for doing that. So we will probably need to live with it for the 
foreseeable future. And yes, it's a bit sad.


Anyway, I'm now convinced that the status of Noto Sans Moto motivates a 
change of the default monospace font in Debian. Well, you and I haven't 
agreed on what to put there instead, so how about a compromise where we 
pick both? :)


https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/6fae069d

While I still hesitate, since the change affects so many users, I have 
decided to act. After all we are in the beginning of the trixie 
development cycle, so there is plenty of time to change it later. By 
making the change in unstable and testing, we expose it to the users. 
Many will probably not even notice and some will like it. And if some 
users disapprove of the change, the broader discussion we haven't had 
may happen later.


Thanks for your perseverance!

--
Cheers,
Gunnar



Bug#1050091: hostname: VCS URLs should be specified in d/control

2023-08-20 Thread Daijohn . Bester
Package: hostname
Followup-For: Bug #1050091

A new release is definitely not needed. Changelog in VCS should however mention 
the NMU. The package itself should also have a link in control to the VCS.



Bug#1049984: debuild: please export CC=gcc CXX=g++ for buildpackage instead of just clearing

2023-08-20 Thread наб
Control: tags -1 + patch

https://salsa.debian.org/debian/devscripts/-/merge_requests/362
From ed55d6a12db3ccebeb435b1b29ad7fb9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Sun, 20 Aug 2023 12:02:21 +0200
Subject: [PATCH] debuild: provide CC=gcc CXX=g++ by default (Closes: #1049984)
X-Mutt-PGP: OS

GNU Make defaults to CC=cc CXX=g++ if these are unset, and currently
these are always cleared by default. Thus, if cc is a compiler that some
other stage of the build system doesn't like (in my case, clang trunk
which generates DWARF5 debuginfo by default, which dwz always
hard-errors on), every build is broken by default, and the supplied
compiler pair is mismatched (system clang trunk cc, bookworm g++).

Unless explicitly specified, set CC=gcc CXX=g++ as well. This makes the
implied default explicit, and fixes builds on machines where they're
currently broken, without affecting builds on ones that work.
---
 scripts/debuild.1  | 5 +++--
 scripts/debuild.pl | 3 +++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/scripts/debuild.1 b/scripts/debuild.1
index 2232c732..fe26ebc2 100644
--- a/scripts/debuild.1
+++ b/scripts/debuild.1
@@ -93,8 +93,9 @@ .SH ENVIRONMENT VARIABLES
 \fBDBUS_SESSION_BUS_ADDRESS\fR, \fBFAKEROOTKEY\fR, \fBDEBEMAIL\fR,
 \fBDEB_\fI*\fR, the (\fBC\fR, \fBCPP\fR, \fBCXX\fR, \fBLD\fR and
 \fBF\fR)\fBFLAGS\fR variables and their \fB_APPEND\fR counterparts and the
-locale variables \fBLANG\fR and \fBLC_\fI*\fR.  \fBTERM\fR is set to `dumb'
-if it is unset, and \fBPATH\fR is set to "/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11".
+locale variables \fBLANG\fR and \fBLC_\fI*\fR.  \fBTERM\fR is set to `dumb',
+\fBCC\fR to `gcc', and \fBCXX\fR to `g++' if they are unset,
+and \fBPATH\fR is set to "/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11".
 .PP
 If a particular environment variable is required to be passed through
 untouched to the build process, this may be specified by using a
diff --git a/scripts/debuild.pl b/scripts/debuild.pl
index 7396dc12..910bb816 100755
--- a/scripts/debuild.pl
+++ b/scripts/debuild.pl
@@ -665,6 +665,9 @@ unless ($preserve_env) {
 }
 }
 
+$ENV{'CC'}  = 'gcc' unless exists $ENV{'CC'};
+$ENV{'CXX'} = 'g++' unless exists $ENV{'CXX'};
+
 umask 022;
 
 # Start by duping STDOUT and STDERR
-- 
2.39.2



signature.asc
Description: PGP signature


Bug#1050121: bullseye-pu: package cryptmount/5.3.3-1+deb11u1

2023-08-20 Thread RW Penney
Package: release.debian.org
Version: 5.3.3-1
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: rwpen...@users.sourceforge.net
Control: affects -1 + src:cryptmount

[ Reason ]
When cryptmount is passed invalid command-line arguments, it is likely
to crash with a SEGV error due to inappropriately zeroed memory passed
to getopt_long().

[ Impact ]
The absence of error-messages when invalid command-line arguments are supplied
affects usability. The use of uninitialized memory with a setuid binary is,
potentially, a security risk.

[ Tests ]
The fix involves a single-line change to replace a call to malloc()
with one to calloc(). This has been tested manually on invalid command-line
arguments,
and the upstream "mudslinger" test-suite has been used for regression tests
across a wide range of usage scenarios.

[ Risks ]
The proposed change has very little risk of side-effects.

[ Checklist ]
  [x] *all* changes are documents in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in bullseye
  [x] the issue is verified as fixed in unstable

[ Changes ]
A call to malloc() prior to using getopt_long() has been replaced by
a similar call to calloc().
diff -Nru cryptmount-5.3.3/debian/changelog cryptmount-5.3.3/debian/changelog
--- cryptmount-5.3.3/debian/changelog   2021-01-01 14:34:20.0 +
+++ cryptmount-5.3.3/debian/changelog   2023-07-20 11:30:00.0 +0100
@@ -1,3 +1,12 @@
+cryptmount (5.3.3-1+deb11u1) bullseye; urgency=low
+
+  * Fix for memory-initialization in command-line parser (bug#1038384)
+- one-line change to source-code, replacing malloc() with calloc()
+- reduces risk of SEGV crashes when handling unrecognized
+  command-line options
+
+ -- RW Penney   Sun, 20 Jul 2023 10:30:00 +
+
 cryptmount (5.3.3-1) unstable; urgency=low
 
   * New upstream release
diff -Nru cryptmount-5.3.3/debian/patches/docfiles-pathnames.patch 
cryptmount-5.3.3/debian/patches/docfiles-pathnames.patch
--- cryptmount-5.3.3/debian/patches/docfiles-pathnames.patch2021-01-01 
15:19:51.0 +
+++ cryptmount-5.3.3/debian/patches/docfiles-pathnames.patch2023-07-20 
11:30:00.0 +0100
@@ -1,4 +1,7 @@
-Correct installation pathnames in documentation
+Description: Correct installation pathnames in documentation
+ Some documentation files not installed except in Debian packaging
+Author: RW Penney 
+Forwarded: not-needed
 --- a/README
 +++ b/README
 @@ -64,7 +64,7 @@
diff -Nru cryptmount-5.3.3/debian/patches/getopt-initialization.patch 
cryptmount-5.3.3/debian/patches/getopt-initialization.patch
--- cryptmount-5.3.3/debian/patches/getopt-initialization.patch 1970-01-01 
01:00:00.0 +0100
+++ cryptmount-5.3.3/debian/patches/getopt-initialization.patch 2023-07-01 
08:05:21.0 +0100
@@ -0,0 +1,14 @@
+Description: Fix memory initialization error in command-line parser
+Author: RW Penney 
+Forwarded: not-needed
+--- a/cryptmount.c
 b/cryptmount.c
+@@ -1372,7 +1372,7 @@
+ #ifdef _GNU_SOURCE
+ struct option *longopts;
+ 
+-longopts = (struct option*)malloc((n_options + 1) * sizeof(struct 
option));
++longopts = (struct option*)calloc(n_options + 1, sizeof(struct option));
+ for (i=0; i

Bug#1045316: snakemake: clean broken

2023-08-20 Thread Rebecca N. Palmer

Control: tags -1 pending

Fixed in Salsa, but please do NOT upload that version as-is (it FTBFS 
for an unrelated reason).




Bug#1050118: 7zip-standalone/experimental: undeclared file conflict with 7zip/bookworm+trixie+unstable

2023-08-20 Thread yokota
Hello, Helmut

> 7zip-standalone and 7zip both ship /usr/bin/7zip, but they do not
> declare any Conflicts, Replaces or diversions to alleviate that
> situation. As a consequence, an unpack error may result when attempting
> to install both.
>
> Given the changelog entry saying "split", I think you meant to move
> files between packages. In this case, please ensure that you set both
> Breaks and Replaces.

7zip and 7zip-standalone dose not provides /usr/bin/7zip.
They provides:
  7zip: 7z, 7za, 7zr, p7zip
  7zip-standalone: 7zz

And 7zip-standalone requires "7zip (= ${binary:Version})" and 7zip
breaks/conflicts/replaces "p7zip (<= 16.02+dfsg-8)".
I think it works at least on my machine.

Current package control file is here:
  
https://salsa.debian.org/debian/7zip/-/blob/debian/23.01+dfsg-4_exp1/debian/control

--
YOKOTA Hiroshi



Bug#1037097: shotwell: problem with sendto and thunderbird : there is no attachment file since the dropping of nautilus sendto in version 0.3.15 (it works with other mailers)

2023-08-20 Thread Jörg Frings-Fürst
Hello Romain,

can you please collaborate a bit in the upstream - bug[1]? 

CU
Jörg

[1] https://gitlab.gnome.org/GNOME/shotwell/-/issues/5054


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://git.jff.email/cgit/

Skype:jff-skype@jff.email
Jami: joergfringsfuerst
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.






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


Bug#1042376: digikam crashes with "Illegal instruction"

2023-08-20 Thread Detlef Matthiessen



On 19.08.23 22:00, Steven Robbins wrote:

1. Test a build without SSE4.


  I built 8.1.0-2 from sources (which took 70 minutes on my machine,
btw), removed the version from "sid" that I had installed the other day
and then did:
root@fluke:~# dpkg -i digikam_8.1.0-2_amd64.deb
digikam-data_8.1.0-2_all.deb digikam-private-libs_8.1.0-2_amd64.deb

  Lo and behold! It works flawlessly and is even able to show videos
(something that the 8.2.0 AppImage from KDE, that I had been using in
the meantime
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042376#25), failed at).


2. Dig further with the debugger to understand what the illegal instruction
is.  I may be completely wrong in assuming it is an SSE4 instruction --
particularly given the fact that the test code we discussed August 13/14
builds the same with/without the -msse4.1 flag.  If you are handy with gdb you
can probably dig into the assembly and figure out what the instruction is.


  Now that I'm in the possession of working packages for digikam, I
could volunteer to assist you in finding out the root cause of the crash
(which I assume probably affects only a small number of users anyway).
However, it has been literally decades that I've done any serious
programming in C/C++. Any hints on how to use gdb in this regard and
what to look for would be highly appreciated.

  Kind regards,

Detlef



Bug#996815: rxvt-unicode: Terminal text rendering too wide after upgrade to FreeType 2.11.0+dfsg-1

2023-08-20 Thread jim_p
Package: rxvt-unicode
Version: 9.31-1
Followup-For: Bug #996815
X-Debbugs-Cc: pitsior...@outlook.com

I think it is time to close this. Fontconfig's update to 2.14.2 on August 16th
(that is when it reached testing) made urxvt's font spacing return to normal,
so the letterspace parameter in .Xdefaults is no longer needed. In fact, it
makes the text harder to read because it is denser. Removing it made it look
like it used to, so please verify it yourselves.

Ugly screenshots and configs upon request.


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

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

Versions of packages rxvt-unicode depends on:
ii  base-passwd   3.6.1
ii  libc6 2.37-7
ii  libfontconfig12.14.2-3
ii  libgcc-s1 13.2.0-2
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.77.2-1
ii  libperl5.36   5.36.0-7
ii  libptytty02.0-1+b1
ii  libstartup-notification0  0.12-6+b1
ii  libx11-6  2:1.8.6-1
ii  libxext6  2:1.3.4-1+b1
ii  libxft2   2.3.6-1
ii  libxmu6   2:1.1.3-3
ii  libxrender1   1:0.9.10-1.1
ii  ncurses-base  6.4+20230625-2
ii  ncurses-term  6.4+20230625-2

Versions of packages rxvt-unicode recommends:
pn  fonts-dejavu
pn  fonts-vlgothic | fonts-japanese-gothic  

Versions of packages rxvt-unicode suggests:
ii  sensible-utils  0.0.20

-- no debconf information



  1   2   >