Bug#1029435: The describes bug is fixed

2023-08-12 Thread Salvatore Bonaccorso
Source: linux
Source-Version: 6.3.11-1

Hi,

On Fri, Aug 11, 2023 at 03:11:31PM +0200, Jan Ries wrote:
> Dear Maintainers,
> 
> the aformentioned bug is fixed as of linux-image-amd64  6.1.38-1.
> 
> Thanks a lot!

Can you confirm that this is as well fixed in 6.3.11-1 or later? I'm
already assuming so and updating the metadata, but if you find the
issue to be still present in testing and unstable then let's revert
that.

Regards,
Salvatore



Bug#1043564: linux: Please Re-enable DC states for drm/i915

2023-08-12 Thread Salvatore Bonaccorso
Control: tags -1 + confirmed upstream fixed-upstream pending

Hi,

On Sat, Aug 12, 2023 at 10:40:09PM -0400, Jesse Rhodes wrote:
> Source: linux
> Severity: important
> Tags: patch
> X-Debbugs-Cc: je...@sney.ca
> 
> Dear debian kernel team,
> 
> The upstream commit "drm/i915: Disable DC states for all commits" [1] breaks 
> my
> Asus C204M Chromebook's ability to wake the screen after power management 
> shuts
> it off. This also produces a kernel stack trace, attached. It's likely that it
> has the same effect on other Intel Gemini Lake hardware or UHD 600 video
> devices.
> 
> I discovered this commit by bisecting between 6.1.0-7 (6.1.20-2) and
> 6.1.0-8 (6.1.25-1), and confirmed that the current 6.1.0-10 (6.1.38-2) does 
> not
> have the issue if intel_display.c is rolled back to its previous state.
> 
> Attached is also the lspci output for the affected machine.
> 
> I hope that "Tags: patch" is allowed as a tag when the fix is to revert a
> specific commit, and I apologize if this was already reported and I couldn't
> find it in the list.
> 
> Please let me know if you need any more information, as I would be happy to
> keep debugging!

Thanks for the report. The commit was found indeed to cause issues and
was for now reverted upstream in the 6.1.y series and released in
6.1.45.

The fix will be contained in the next bookworm point release update,
have just added the bugcloser for this issue as well in the current
rebase work:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/803/diffs?commit_id=050b84b3c21f5a5b5e15b562da2ffc9f0edfda3a

Regards,
Salvatore



Bug#1043571: /usr/bin/build-simple-cdd on debian 12 generates image that fails installation

2023-08-12 Thread Todd D. Taft
Package: simple-cdd
Version: 0.6.9
Severity: normal
File: /usr/bin/build-simple-cdd

Dear Maintainer,

Runing build-simple-cdd with no options in an empty directory is generating an
iso file that fails to install.
The iso file fails while attempting to install the zstd package.  The
installation log indicates that this package is required by another package,
but this package has no installation candidate and is not available.
Issue occurs when both the system where build-simple-cdd is run and the system
where installation is being attempted are (different) VMWare guests.


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

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

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-3+b1
ii  debian-cd   3.2.1
ii  lsb-release 12.0-1
ii  python3 3.11.2-1+b1
ii  python3-simple-cdd  0.6.9
ii  reprepro5.3.1-1
ii  rsync   3.2.7-1
ii  wget1.21.3-1+b2

Versions of packages simple-cdd recommends:
ii  dose-distcheck  7.0.0-1+b2

Versions of packages simple-cdd suggests:
pn  qemu-system | qemu-kvm  

-- no debconf information



Bug#1043570: RM: ruby-haml-contrib -- ROM; FTBFS; dead upstream; no-rdeps; low popcon

2023-08-12 Thread HIGUCHI Daisuke (VDR dai)
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ruby-haml-cont...@packages.debian.org
Control: affects -1 + src:ruby-haml-contrib

ruby-haml-contrib is affected by RC bug #1026893 that it FTBFS with ruby3.1 and
newer, and is not in stable/testing.  No new upstream release since 2013.
No rdeps and low popcon.  It has been declared in
https://lists.debian.org/debian-ruby/2023/02/msg00010.html.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature


Bug#1043569: RM: ruby-test-spec -- ROM; FTBFS; dead upstream; no-rdeps; low popcon

2023-08-12 Thread HIGUCHI Daisuke (VDR dai)
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ruby-test-s...@packages.debian.org
Control: affects -1 + src:ruby-test-spec

ruby-test-spec is affected by RC bug #1019671 that it FTBFS with ruby3.1 and
newer, and is not in stable/testing.  Dead upstream since 2009.  No rdeps and
low popcon.  It has been declared in
https://lists.debian.org/debian-ruby/2023/02/msg00010.html.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature


Bug#1043568: RM: rhc -- ROM; deprecated in upstream; no-rdeps; low popcon

2023-08-12 Thread HIGUCHI Daisuke (VDR dai)
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: r...@packages.debian.org
Control: affects -1 + src:rhc

rhc is deprecated in upstream and archived since 2018.  No rdeps and
low popcon.  It is not in stable/testing.  It has been declared in
https://lists.debian.org/debian-ruby/2023/02/msg00010.html.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature


Bug#1043565: RM: test-kitchen -- ROM; FTBFS; unmaintained; no-rdeps; low popcon

2023-08-12 Thread dai
Control: retitle -1 RM: test-kitchen -- ROM; FTBFS; unmaintained; low popcon

Sorry for my mistake, test-kitchen has 2 rdeps ruby-kitchen-docker and
ruby-kitchen-salt.  But I will file them with RM too.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature


Bug#1043567: RM: ruby-kitchen-salt -- ROM; unmaintained; no-rdeps; low popcon

2023-08-12 Thread HIGUCHI Daisuke (VDR dai)
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ruby-kitchen-s...@packages.debian.org
Control: affects -1 + src:ruby-kitchen-salt

ruby-kitchen-salt is unmaintained, not in stable/testing.
no-rdeps and low popcon.  It has been declared in
https://lists.debian.org/debian-ruby/2023/02/msg00010.html.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature


Bug#1043566: RM: ruby-kitchen-docker -- ROM; unmaintained; no-rdeps; low popcon

2023-08-12 Thread HIGUCHI Daisuke (VDR dai)
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ruby-kitchen-doc...@packages.debian.org
Control: affects -1 + src:ruby-kitchen-docker

ruby-kitchen-docker is unmaintained, not in stable/testing.
no-rdeps and low popcon.  It has been declared in
https://lists.debian.org/debian-ruby/2023/02/msg00010.html.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature


Bug#1043565: RM: test-kitchen -- ROM; FTBFS; unmaintained; no-rdeps; low popcon

2023-08-12 Thread HIGUCHI Daisuke (VDR dai)
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: test-kitc...@packages.debian.org
Control: affects -1 + src:test-kitchen

test-kitchen is affected by RC bug #1019683 that it FTBFS with ruby3.1 and
newer, and is not in stable/testing.  It does not follow new upstream release
since 2018 (unstable: 1.23.2 - upstream: 3.5.0).  No rdeps and low popcon.
It has been declared in
https://lists.debian.org/debian-ruby/2023/02/msg00010.html.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature


Bug#922662: xboxdrv: some systemd unit

2023-08-12 Thread cacatoes

Hello,

I myself tried to put some glue, it works but I realized it could have 
been better to do it another way.


Method 1 : several instances of xboxdrv started with udev+systemd 
(that's what I did)
Method 2 : xboxdrv as a daemon managed by systemd (maybe a better 
option)


Method 1:

At first I got inspired by this: 
https://github.com/phantom-voltage/xboxdrv-udev-rules
But prefered not to use a shell script and directly manage xboxdrv 
through systemd.


Attached are the files doing the job for me.

Steps to use:
1) Write udev rules with identifiers for your devices
2) Write a .xboxdrv file for each unique controller
3) Copy all files (a template systemd unit, a udev rules file, xboxdrv 
configs) in their dirs.

4) # systemctl daemon-reload
   # systemctl reload udev
5) It's ready.

Pros/cons:
+ simple to implement
- write udev rules manually (xboxdrv could manage this itself)
- not so generic, and have to edit files in various parts for each new 
controller


Method 2:

Check arch package, I hadn't the opportunity to dig into it, but maybe 
running xboxdrv as a daemon makes it easier to handle more usecases.

https://aur.archlinux.org/packages/xboxdrv# Microsoft Xbox Series USB

[xboxdrv]
evdev=/dev/input/by-id/usb-Microsoft_Controller_#-event-joystick

mimic-xpad=true

#detach-kernel-driver=true
#evdev-grab=true
#dpad-as-button=true
#silent=true
#evdev-debug=true

[evdev-absmap]
ABS_X   = x1
ABS_Y   = y1
ABS_RX  = y2
ABS_RY  = x2
ABS_Z   = lt
ABS_RZ  = rt
ABS_HAT0X = dpad_x
ABS_HAT0Y = dpad_y

[axismap]
-Y1=Y1

[evdev-keymap]
BTN_A=a
BTN_B=b
BTN_X=x
BTN_Y=y
BTN_TL=lb
BTN_TR=rb
BTN_SELECT=Back
BTN_START=Start

# EOF #
### Udev rules for gamepads ###

# Add the two rules (plugged/unplugged) for each gametype model you own. 
# You don't need to add new rules if you own several gamepads of the same model.
#
# Each unique gamepad is handled by its own instance of the xboxdrv systemd 
unit.
#
# We try to identify each unique gamepad with this combination of attributes:
# $attr{idVendor}-$attr{idProduct}-$attr{serial}
#
# For this to work, you need to provide a xboxdrv config for each unique 
gamepad you own.

## Gamepads ##

# Microsoft Xbox Series Controller S|X

KERNEL=="event*", SUBSYSTEM=="input", ATTRS{idVendor}=="045e", 
ATTRS{idProduct}=="0b12", 
SYMLINK+="input/$attr{idVendor}-$attr{idProduct}-$attr{serial}", ACTION=="add", 
RUN+="/usr/bin/systemctl start 
xboxdrv@$attr{idVendor}-$attr{idProduct}-$attr{serial}"
KERNEL=="event*", SUBSYSTEM=="input", ATTRS{idVendor}=="045e", 
ATTRS{idProduct}=="0b12", ACTION=="remove", RUN+="/usr/bin/systemctl stop 
xboxdrv@$attr{idVendor}-$attr{idProduct}-$attr{serial}" 

# Logitec Rumblepad 2

KERNEL=="event*", SUBSYSTEM=="input", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c218", 
SYMLINK+="input/$attr{idVendor}-$attr{idProduct}-$attr{serial}", ACTION=="add", 
RUN+="/usr/bin/systemctl start 
xboxdrv@$attr{idVendor}-$attr{idProduct}-$attr{serial}"
KERNEL=="event*", SUBSYSTEM=="input", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c218", ACTION=="remove", RUN+="/usr/bin/systemctl stop 
xboxdrv@$attr{idVendor}-$attr{idProduct}-$attr{serial}"
[Unit]
Description=A Xbox/Xbox360 userspace gamepad driver

[Service]
Type=simple
User=root
ExecStart=/usr/bin/xboxdrv -c /etc/xboxdrv/%i.xboxdrv

# Or use a PID?
ExecStop=pkill --signal 1 -f "/usr/bin/xboxdrv -c /etc/xboxdrv/%i.xboxdrv"

[Install]
WantedBy=multi-user.target


Bug#1043563: RM: golang-github-hashicorp-terraform-json -- ROM; no longer needed

2023-08-12 Thread Thorsten Alteholz

Package: ftp.debian.org
Severity: normal

This package is no longer needed. The most probable user is not distributable 
by Debian.
There have been no reverse dependencies uploaded yet.

   Thorsten



Bug#1043562: RM: golang-github-hashicorp-go-tfe -- ROM; no longer needed

2023-08-12 Thread Thorsten Alteholz

Package: ftp.debian.org
Severity: normal

This package is no longer needed. The most probable user is not distributable 
by Debian.
There have been no reverse dependencies uploaded yet.

   Thorsten



Bug#1043561: RM: golang-github-hashicorp-go-slug -- ROM; no longer needed

2023-08-12 Thread Thorsten Alteholz

Package: ftp.debian.org
Severity: normal

This package is no longer needed. The most probable user is not distributable 
by Debian.
The only reverse depdendency shall be removed as well.

   Thorsten



Bug#1043560: RM: golang-github-hashicorp-go-gcp-common -- ROM; no longer needed

2023-08-12 Thread Thorsten Alteholz

Package: ftp.debian.org
Severity: normal

This package is no longer needed. The most probable user is not distributable 
by Debian.
There have been no reverse dependencies uploaded yet.

   Thorsten



Bug#1043559: gnome-calculator: open display blank window

2023-08-12 Thread michiaki ookawa
Package: gnome-calculator
Version: 1:45~beta-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

This version only show blank window with Gtk-CRITICAL error:

michiaki@debian$ gnome-calculator   
[~]

(gnome-calculator:14244): Gtk-CRITICAL **: 09:44:14.560: Error building 
template class 'MathWindow' for an instance of type 'MathWindow': .:0:0 Invalid 
object type 'AdwToolbarView'

** (gnome-calculator:14244): CRITICAL **: 09:44:14.568: 
math_converter_set_equation: assertion 'self != NULL' failed

** (gnome-calculator:14244): CRITICAL **: 09:44:14.568: 
math_converter_set_category: assertion 'self != NULL' failed

** (gnome-calculator:14244): CRITICAL **: 09:44:14.568: 
math_converter_set_conversion: assertion 'self != NULL' failed

(gnome-calculator:14244): Gtk-CRITICAL **: 09:44:14.568: gtk_grid_attach: 
assertion 'GTK_IS_GRID (grid)' failed

(gnome-calculator:14244): Gtk-CRITICAL **: 09:44:14.572: 
gtk_grid_attach_next_to: assertion 'GTK_IS_GRID (grid)' failed

(gnome-calculator:14244): Gtk-CRITICAL **: 09:44:14.572: 
gtk_menu_button_set_label: assertion 'GTK_IS_MENU_BUTTON (menu_button)' failed

(gnome-calculator:14244): Gtk-CRITICAL **: 09:44:14.572: gtk_widget_hide: 
assertion 'GTK_IS_WIDGET (widget)' failed

** (gnome-calculator:14244): CRITICAL **: 09:44:14.572: 
history_view_set_serializer: assertion 'self != NULL' failed

(gnome-calculator:14244): Gtk-CRITICAL **: 09:44:14.587: 
gtk_menu_button_set_label: assertion 'GTK_IS_MENU_BUTTON (menu_button)' failed

michiaki@debian$


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

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

Versions of packages gnome-calculator depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libadwaita-1-0   1.3.4-1
ii  libc62.37-7
ii  libgee-0.8-2 0.20.6-1
ii  libglib2.0-0 2.77.1-2
ii  libgtk-4-1   4.10.5+ds-3
ii  libgtksourceview-5-0 5.8.0-2
ii  libmpc3  1.3.1-1
ii  libmpfr6 4.2.0-1
ii  libsoup-3.0-03.4.2-4
ii  libxml2  2.9.14+dfsg-1.3

Versions of packages gnome-calculator recommends:
ii  gvfs  1.51.90-1
ii  yelp  42.2-1

gnome-calculator suggests no packages.

-- no debconf information



Bug#856421: RFA: gnokii -- fc4f45003af70b9edaaa93fd24a289b6

2023-08-12 Thread Bastian Germann

Control: retitle -1 ITA: gnokii -- Datasuite for mobile phone management

I intend to adopt the package.



Bug#1028111: r-cran-clock: autopkgtest failure on 32bit

2023-08-12 Thread Dirk Eddelbuettel


The 'bug fix' applied to the _previous_ version of CRAN package clock, namely
a somewhat 'wild' sed patching of a single ie

# Ignore single test for i386 architecture.  This is a workaround for bug 
#1024828 of r-cran-igraph
if [ "$hostarch" = "i386" -o "$hostarch" = "armel" -o "$hostarch" = "armhf" ] ; 
then
  sed -i -e '152d' -e '151d' testthat/test-posixt.R
fi

now creates a syntax error on these very architectures (as the upstream file
presumably changed).  Here is the corresponding part of one of the logs
(armel at 
https://ci.debian.net/data/autopkgtest/testing/armel/r/r-cran-clock/36601943/log.gz)
 

 80s > library(testthat)
 80s > library(clock)
 80s > 
 80s > test_check("clock")
132s Error in parse(con, n = -1, srcfile = srcfile, encoding = "UTF-8") : 
132s   test-posixt.R:1372:0: unexpected end of input
132s 1370:   })
132s 1371: })
132s  ^
132s Calls: test_check ... doTryCatch -> lapply -> FUN -> source_file -> parse
132s Execution halted
133s autopkgtest [08:19:23]: test run-unit-test: ---]
133s autopkgtest [08:19:23]: test run-unit-test:  - - - - - - - - - - results - 
- - - - - - - - -
133s run-unit-testFAIL non-zero exit status 1

Obviously if we ambush upstream code and corrupt then tests we impose will
fail.

This has fairly large repurcussions across other packages include some of mine.

If nobody else steps up I plan to address this by no longer 'hot-fix
patching' (and thereby corrupting) test-posixt.R but (at least for now)
simply skipping tests of test-posixt.t.  The regular maintainers may find
time to investigate what parts of the test file work for armel, armhf, i386.

Dirk





-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Bug#1043558: (no subject)

2023-08-12 Thread Alma Madeleine

Correction:


… and plugging in the keyboard again.


→

… and disconnecting the keyboard.



Bug#684128: src:debian-installer: allow use of binary units in disk partitioner

2023-08-12 Thread Holger Wansing
Hi,

Justin B Rye  wrote (Fri, 28 Jul 2023 10:04:09 
+0100):
> Holger Wansing wrote:
> > Thorsten Glaser :
> >> Could this information (valid unit sufficēs) be added to the dialogue
> >> where the size is entered? Screen space should suffice.
> [...]
> > CC'ing debian-l10n-english for template review (three identical additions
> > in two packages).

I found there is another template, which needs to be changed for this.

Patch attached (especially for review on l10n-english).


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/partman-lvm.templates b/debian/partman-lvm.templates
index 509d9a7..63219c0 100644
--- a/debian/partman-lvm.templates
+++ b/debian/partman-lvm.templates
@@ -376,8 +376,9 @@ Type: string
 # :sl3:
 _Description: Logical volume size:
  Please enter the size of the new logical volume. The size may be
- entered in the following formats: 10K (Kilobytes), 10M (Megabytes),
- 10G (Gigabytes), 10T (Terabytes). The default unit is Megabytes.
+ entered in the following formats: 10KB (Kilobytes), 10KiB (Kibibytes), 10MB
+ (Megabytes), 10MiB (Mebibytes), 10GB (Gigabytes), 10GiB (Gibibytes), 10TB
+ (Terabytes), 10TiB (Tebibytes). The default unit is Megabytes.
 
 Template: partman-lvm/lvcreate_error
 Type: error


Bug#1043558: (no subject)

2023-08-12 Thread Alma Madeleine
Here's a part of the journal between suspend and plugging in the 
keyboard again.Aug 12 21:33:08 AnonymizedPC kernel: PM: suspend entry (deep)
Aug 12 23:12:24 AnonymizedPC kernel: Filesystems sync: 0.030 seconds
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/nvdec/scrubber.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/acr/bl.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/acr/ucode_ahesasc.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/acr/ucode_asb.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/acr/unload_bl.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/acr/ucode_unload.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/gr/fecs_bl.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/gr/fecs_inst.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/gr/fecs_data.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/gr/fecs_sig.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/gr/gpccs_bl.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/gr/gpccs_inst.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/gr/gpccs_data.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/gr/gpccs_sig.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/gr/sw_nonctx.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/gr/sw_ctx.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/gr/sw_bundle_init.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/gr/sw_method_init.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/sec2/sig.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/sec2/image.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware nvidia/tu116/sec2/desc.bin
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware iwlwifi-cc-a0-72.ucode
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware regulatory.db
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware regulatory.db.p7s
Aug 12 23:12:24 AnonymizedPC kernel: (NULL device *): firmware: direct-loading firmware v4l-cx23885-avcore-01.fw
Aug 12 23:12:24 AnonymizedPC kernel: Freezing user space processes
Aug 12 23:12:24 AnonymizedPC kernel: Freezing user space processes completed (elapsed 0.011 seconds)
Aug 12 23:12:24 AnonymizedPC kernel: OOM killer disabled.
Aug 12 23:12:24 AnonymizedPC kernel: Freezing remaining freezable tasks
Aug 12 23:12:24 AnonymizedPC kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
Aug 12 23:12:24 AnonymizedPC kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Aug 12 23:12:24 AnonymizedPC kernel: serial 00:04: disabled
Aug 12 23:12:24 AnonymizedPC kernel: serial 00:03: disabled
Aug 12 23:12:24 AnonymizedPC kernel: sd 1:0:0:0: [sda] Synchronizing SCSI cache
Aug 12 23:12:24 AnonymizedPC kernel: sd 1:0:0:0: [sda] Stopping disk
Aug 12 23:12:24 AnonymizedPC kernel: ACPI: EC: interrupt blocked
Aug 12 23:12:24 AnonymizedPC kernel: ACPI: PM: Preparing to enter system sleep state S3
Aug 12 23:12:24 AnonymizedPC kernel: ACPI: EC: event blocked
Aug 12 23:12:24 AnonymizedPC kernel: ACPI: EC: EC stopped
Aug 12 23:12:24 AnonymizedPC kernel: ACPI: PM: Saving platform NVS memory
Aug 12 23:12:24 AnonymizedPC kernel: Disabling non-boot CPUs ...
Aug 12 23:12:24 AnonymizedPC kernel: smpboot: CPU 1 is now offline
Aug 12 23:12:24 AnonymizedPC kernel: smpboot: CPU 2 is now offline
Aug 12 23:12:24 AnonymizedPC kernel: smpboot: CPU 3 is now offline
Aug 12 23:12:24 AnonymizedPC kernel: smpboot: CPU 4 is now offline
Aug 12 23:12:24 AnonymizedPC kernel: smpboot: CPU 5 is now offline
Aug 12 23:12:24 AnonymizedPC kernel: smpboot: CPU 6 is now offline
Aug 12 23:12:24 AnonymizedPC kernel: smpboot: CPU 7 is now offline
Aug 12 23:12:24 AnonymizedPC kernel: smpboot: CPU 8 is now offline
Aug 12 23:12:24 AnonymizedPC kernel: smpboot: CPU 9 is now offline
Aug 12 23:12:24 AnonymizedPC kernel: smpboot: CPU 10 is now offline
Aug 12 23:12:24 

Bug#1042376: digikam crashes with "Illegal instruction"

2023-08-12 Thread Steven Robbins
On Sun, 30 Jul 2023 07:27:51 +0200 Detlef Matthiessen 
 
wrote:
> 
>Hi Steve,
> 
>I've got:
> 
> Program received signal SIGILL, Illegal instruction.
> 0x76cc20d3 in operator* (m1=..., m2=...) at 
> /usr/include/x86_64-linux-gnu/qt5/
QtGui/qmatrix4x4.h:642
> Downloading source file /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h
> 642 /usr/include/x86_64-linux-gnu/qt5/QtGui/qmatrix4x4.h: Directory not 
> empty.
> 
>HTH, Detlef

There must be more than this?  Normally a backtrace shows a number of stack 
frames.  
Did you type "bt" in the gdb propmpt after the crash?

Example:
(gdb) bt 
#0  0x747199ef in __GI___poll (fds=0x607d36a0, nfds=13, 
timeout=4978) at ../
sysdeps/unix/sysv/linux/poll.c:29 
#1  0x7fffe5918517 in g_main_context_poll_unlocked (priority=, 
n_fds=13, fds=0x607d36a0, timeout=, context=0x7fff48000ec0) 
at 
../../../glib/gmain.c:4653 
#2  g_main_context_iterate_unlocked (context=context@entry=0x7fff48000ec0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/
gmain.c:4344 
#3  0x7fffe5918bac in g_main_context_iteration (context=0x7fff48000ec0, 
may_block=1) at ../../../glib/gmain.c:4414 
#4  0x74f1c8d6 in 
QEventDispatcherGlib::processEvents(QFlags) 
(this=0x55c298c0, flags=...) at kernel/qeventdispatcher_glib.cpp:423 
#5  0x74ec1b7b in 
QEventLoop::exec(QFlags) 
(this=this@entry=0x7fffd690, flags=..., flags@entry=...) 
   at ../../include/QtCore/../../src/corelib/global/qflags.h:69 
#6  0x74eca020 in QCoreApplication::exec() () at 
../../include/QtCore/../../src/
corelib/global/qflags.h:121 
#7  0x7533258c in QGuiApplication::exec() () at 
kernel/qguiapplication.cpp:1863 
#8  0x75b62ca5 in QApplication::exec() () at 
kernel/qapplication.cpp:2832 
#9  0xa0e6 in main(int, char**) (argc=, 
argv=) at ./core/app/main/main.cpp:478



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


Bug#1043558: keyboard doesn't respond after waking up

2023-08-12 Thread Alma Madeleine

Package: linux-image-6.1.0-11-amd64
Version: 6.1.38-4
Control: affects -1 src:linux linux gnome

After a stationary PC suspended itself due to inactivity and then woke 
up from suspend (on mouse or key press – I can't recollect), the 
keyboard was not responsive.  It had power: the LED  was lit. 
Pressing the keys (I tried several keys, including Umsch and NumLock) 
had no visible effect whatsoever.  After physically unplugging and 
plugging in the keyboard cable again to the same place, the keyboard 
starting working.


The keyboard has “Microsoft® Natural® Ergonomic Keyboard 4000 v1.0” and 
“Model: 1048” written on its bottom, has a German layout, and is 
connected to the PC via a cable ending with a USB-A plug.


As opposed to the keyboard, the mouse, which was plugged into the 
neighbor USB-A port, was working normally.


The error happens only seldom (every couple of weeks or even months) 
after suspend due to inactivity followed by getting awake; much more 
often, the keyboard works normally.  A simple test consisting of putting 
the PC to sleep manually followed by awakening it did not cause the 
error to reoccur.


Gratefully,
Alma



Bug#1043398: filezilla 3.63.0-1+deb12u1 flagged for acceptance

2023-08-12 Thread Jonathan Wiltshire
package release.debian.org
tags 1043398 = 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: filezilla
Version: 3.63.0-1+deb12u1

Explanation: fix builds for 32-bit architectures



Bug#1043557: d-i.debian.org: permit selecting UTC as timezone in non-expert installer

2023-08-12 Thread t41qrq+5xstzbfc382u8
Package: d-i.debian.org
Severity: normal

Dear Maintainer,

When using the non-expert text installer from a netinst cd of debian bookworm 
12.1, only the timezones in the attached picture are displayed for selection.

Please make it possible to select UTC as the timezone, for any 
language/locale/region the user may have selected in previous steps of the 
installation.

UTC is available for selection in the expert text installer.

Thank you.


Bug#1043539: project: Forwarding of @debian.org mails to gmail broken

2023-08-12 Thread Mattia Rizzolo
On Sat, Aug 12, 2023 at 01:41:46PM -0700, Russ Allbery wrote:
> The problem I suspect is with email forwarding, and specifically email
> forwarding to Gmail, which has recently ramped up the amount of
> verification it does on messages.  Because of email forwarding, Gmail sees
> a message purportedly from helgefjell.de but actually delivered by
> debian.org mail servers, and has now decided to be suspicious of that.

This is the exact use case that SRS was developer for, however gmail's
documentation does not recommend that (but the situation, as you noted,
worsened, so I tried it in some other similar setups and everything is
great, so...).
My understanding is that several DSA members were opposed to using SRS
for @debian.org forwarding, but maybe it's now time?

Alternatively, I wonder if ARC nowadays is respected enough (and if
Google cares about it)... I personally don't have any system with ARC
under my care.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#1043555: flatpak: removing an app leaves empty directories on disk

2023-08-12 Thread t41ap7+4g6hxdjbgl1v8
Package: flatpak
Version: 1.14.4-1
Severity: normal

Dear Maintainer,

If you install any application from flathub, and then uninstall that 
application, it will leave an empty directory in 
/var/lib/flatpak/repo/refs/remotes/flathub/app/ with the application name. It 
should not be doing this.

Please forward this bug upstream if it is an upstream bug. Thank you.

-- Package-specific info:
Permissions of /usr/bin/bwrap:
-rwxr-xr-x 1 root root 72080 Feb 28 09:38 /usr/bin/bwrap
/etc/sysctl.d/*-bubblewrap.conf:
cat: '/etc/sysctl.d/*-bubblewrap.conf': No such file or directory
/usr/lib/sysctl.d/50-bubblewrap.conf:
# Enable unprivileged creation of new user namespaces in older Debian
# kernels.
#
# If this is not desired, copy this file to
# /etc/sysctl.d/50-bubblewrap.conf and change the value of this parameter
# to 0, then use dpkg-statoverride to make /usr/bin/bwrap setuid root.
#
# For more details see https://deb.li/bubblewrap or
# /usr/share/doc/bubblewrap/README.Debian
kernel.unprivileged_userns_clone=1
/proc/sys/kernel/unprivileged_userns_clone:
1
/proc/sys/user/max_cgroup_namespaces:
3568
/proc/sys/user/max_ipc_namespaces:
3568
/proc/sys/user/max_mnt_namespaces:
3568
/proc/sys/user/max_net_namespaces:
3568
/proc/sys/user/max_pid_namespaces:
3568
/proc/sys/user/max_time_namespaces:
3568
/proc/sys/user/max_user_namespaces:
3568
/proc/sys/user/max_uts_namespaces:
3568

-- 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-10-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flatpak depends on:
ii  adduser 3.134
ii  bubblewrap  0.8.0-2
ii  dbus [default-dbus-system-bus]  1.14.8-2~deb12u1
ii  fuse3   3.14.0-4
ii  libappstream4   0.16.1-2
ii  libarchive133.6.2-1
ii  libc6   2.36-9+deb12u1
ii  libcurl3-gnutls 7.88.1-10
ii  libdconf1   0.40.0-4
ii  libfuse3-3  3.14.0-4
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libglib2.0-02.74.6-2
ii  libgpgme11  1.18.0-3+b1
ii  libjson-glib-1.0-0  1.6.6-1
ii  libmalcontent-0-0   0.11.0-4
ii  libostree-1-1   2022.7-2
ii  libpolkit-agent-1-0 122-3
ii  libpolkit-gobject-1-0   122-3
ii  libseccomp2 2.5.4-1+b3
ii  libsystemd0 252.12-1~deb12u1
ii  libxau6 1:1.0.9-1
ii  libxml2 2.9.14+dfsg-1.3~deb12u1
ii  libzstd11.5.4+dfsg2-5
ii  xdg-dbus-proxy  0.1.4-3

Versions of packages flatpak recommends:
ii  ca-certificates  20230311
ii  desktop-file-utils   0.26-1
ii  gtk-update-icon-cache3.24.37-2
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   252.12-1~deb12u1
ii  p11-kit  0.24.1-2
ii  policykit-1  122-3
ii  polkitd  122-3
ii  shared-mime-info 2.2-1
ii  xdg-desktop-portal   1.16.0-2
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.1-1
ii  xdg-user-dirs0.18-1

Versions of packages flatpak suggests:
ii  avahi-daemon0.8-10
pn  malcontent-gui  

Versions of packages bubblewrap depends on:
ii  libc62.36-9+deb12u1
ii  libcap2  1:2.66-4
ii  libselinux1  3.4-1+b6

Versions of packages bubblewrap recommends:
ii  procps  2:4.0.2-3

-- no debconf information



Bug#1043508: Thank you

2023-08-12 Thread William Desportes

Thank you both for your quick patch and upload !
No more work to do then, yay ^^



Bug#1043553: cargo: CVE-2023-38497

2023-08-12 Thread Salvatore Bonaccorso
Source: cargo
Version: 0.66.0+ds1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:rust-cargo 0.66.0-4
Control: retitle -2 rust-cargo: CVE-2023-38497

Hi,

The following vulnerability was published for cargo.

CVE-2023-38497[0]:
| Cargo downloads the Rust project’s dependencies and compiles the
| project. Cargo prior to version 0.72.2, bundled with Rust prior to
| version 1.71.1, did not respect the umask when extracting crate
| archives on UNIX-like systems. If the user downloaded a crate
| containing files writeable by any local user, another local user
| could exploit this to change the source code compiled and executed
| by the current user. To prevent existing cached extractions from
| being exploitable, the Cargo binary version 0.72.2 included in Rust
| 1.71.1 or later will purge caches generated by older Cargo versions
| automatically. As a workaround, configure one's system to prevent
| other local users from accessing the Cargo directory, usually
| located in `~/.cargo`.


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-38497
https://www.cve.org/CVERecord?id=CVE-2023-38497
[1] https://www.openwall.com/lists/oss-security/2023/08/03/2
[2] 
https://github.com/rust-lang/wg-security-response/tree/main/patches/CVE-2023-38497
[3] https://github.com/rust-lang/cargo/security/advisories/GHSA-j3xp-wfr4-hx87

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore


Bug#1043552: links against libcurl3-nss which will be dropped in August 2023

2023-08-12 Thread Samuel Henrique
Package: llvm-toolchain-16
Tags: trixie sid
User: c...@packages.debian.org
Usertags: curl-nss-deprecation
X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org
Control: block 1038907 by -1

Hello,

Curl's upstream dropped support for NSS earlier this month:
https://curl.se/dev/deprecate.html#nss

I plan on removing libcurl4-nss-dev and libcurl3-nss in the next
couple of weeks, but this can be delayed if we spot issues (seems like
it will be straightforward for llvm though).

The llvm-toolchain packages will require minimal changes to allow for
libcurl3-nss to be dropped.

d/control lists "libcurl4-dev" as a B-D, and it turns out that the
build process is linking against libcurl3-nss in some archs.

We have two options to deal with this:
1) Explicitly chose a non-nss preferred tls backend on B-D, eg.:
"libcurl4-openssl-dev | libcurl-dev,".
2) BinNMUs after curl drops the nss packages.

The first option is better for me as the dependency can be removed
earlier and it will be less work for me, but number 2 doesn't require
any actions from you (thus why this bug is being cut late).

What would be your preferred option?

Thank you,

-- 
Samuel Henrique 



Bug#1043549: linux-image-6.4.0-1-amd64: btusb driver missing support for device "ID 05ac:821d Apple, Inc. Bluetooth USB Host Controller"

2023-08-12 Thread Kay Blaurock
Package: src:linux
Version: 6.4.4-2
Severity: normal
X-Debbugs-Cc: debian@fungoiddreams.org

Dear Maintainer,


   * What led up to the situation?

After upgrading from "bookworm" to "trixie", Bluetooth stopped working on my
MacBookPro9,1 (2012). No controller at all was found by rfkill, bluetoothctl
and GNOME Settings.

/usr/sbin/usb-devices showed that the device was not claimed by any driver:

T:  Bus=02 Lev=04 Prnt=04 Port=02 Cnt=01 Dev#=  9 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=05ac ProdID=821d Rev=01.56
S:  Manufacturer=Apple Inc.
S:  Product=Bluetooth USB Host Controller
C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)


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

I created an udev rule to add the Vendor/ProdID back to the driver:

$ cat /etc/udev/rules.d/98-applebluetooth.rules
ACTION=="add", ATTRS{idVendor}=="05ac", ATTRS{idProduct}=="821d",
RUN+="/sbin/modprobe btusb" RUN+="/bin/sh -c 'echo 05ac 821d >
/sys/bus/usb/drivers/btusb/new_id'"

Afterwards, the system was rebooted.


   * What was the outcome of this action?

With the udev rule, Bluetooth now works as expected. /usr/sbin/usb-devices now
shows the device claimed by the btusb driver:

D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=05ac ProdID=821d Rev=01.56
S:  Manufacturer=Apple Inc.
S:  Product=Bluetooth USB Host Controller
C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

If I disable the udev rule and reboot the system, Bluetooth stops working
again.

Since Bluetooth did work without issues on bookworm with linux-
image-6.1.0-11-amd64, I suspect a regression either in the Debian kernel, or
upstream.


-- Package-specific info:
** Version:
Linux version 6.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.1.0-9) 13.1.0, GNU ld (GNU Binutils for Debian) 2.40.90.20230720) #1 SMP 
PREEMPT_DYNAMIC Debian 6.4.4-2 (2023-07-30)

** Command line:
BOOT_IMAGE=/vmlinuz-6.4.0-1-amd64 root=/dev/mapper/vg--hastur-root--hastur ro 
mitigations=off video=LVDS-2:d nouveau.runpm=0 quiet splash loglevel=2

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[   17.157097] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules
[   17.157098] RAPL PMU: hw unit of domain package 2^-16 Joules
[   17.157100] RAPL PMU: hw unit of domain pp1-gpu 2^-16 Joules
[   17.157263] iTCO_vendor_support: vendor-support=0
[   17.157339] Loaded X.509 cert 'b...@debian.org: 
577e021cb980e0e820821ba7b54b4961b8b4fadf'
[   17.157473] input: applesmc as /devices/platform/applesmc.768/input/input12
[   17.157660] at24 18-0050: 256 byte spd EEPROM, read-only
[   17.158497] Loaded X.509 cert 'romain.per...@gmail.com: 
3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[   17.158729] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   17.167610] sr 1:0:0:0: Attached scsi CD-ROM sr0
[   17.167878] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db
[   17.168228] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db.p7s
[   17.168526] sdhci-pci :02:00.1: SDHCI controller found [14e4:16bc] (rev 
10)
[   17.169815] mmc0: SDHCI controller on PCI [:02:00.1] using ADMA 64-bit
[   17.175823] applesmc applesmc.768: hwmon_device_register() is deprecated. 
Please convert the driver to use hwmon_device_register_with_info().
[   17.192919] iTCO_wdt iTCO_wdt.1.auto: unable to reset NO_REBOOT flag, device 
disabled by hardware/BIOS
[   17.217573] usb 1-1.1: Found UVC 1.00 device FaceTime HD Camera (Built-in) 
(05ac:8509)
[   17.230295] tg3 :02:00.0 enp2s0f0: renamed from eth0
[   17.285936] ACPI: Smart Battery System [SBS0]: Battery Slot [BAT0] (battery 
present)
[   17.288256] snd_hda_intel :00:1b.0: 

Bug#1043551: links against libcurl3-nss which will be dropped in August 2023

2023-08-12 Thread Samuel Henrique
Package: llvm-toolchain-15
Tags: trixie sid
User: c...@packages.debian.org
Usertags: curl-nss-deprecation
X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org
Control: block 1038907 by -1

Hello,

Curl's upstream dropped support for NSS earlier this month:
https://curl.se/dev/deprecate.html#nss

I plan on removing libcurl4-nss-dev and libcurl3-nss in the next
couple of weeks, but this can be delayed if we spot issues (seems like
it will be straightforward for llvm though).

The llvm-toolchain packages will require minimal changes to allow for
libcurl3-nss to be dropped.

d/control lists "libcurl4-dev" as a B-D, and it turns out that the
build process is linking against libcurl3-nss in some archs.

We have two options to deal with this:
1) Explicitly chose a non-nss preferred tls backend on B-D, eg.:
"libcurl4-openssl-dev | libcurl-dev,".
2) BinNMUs after curl drops the nss packages.

The first option is better for me as the dependency can be removed
earlier and it will be less work for me, but number 2 doesn't require
any actions from you (thus why this bug is being cut late).

What would be your preferred option?

Thank you,

-- 
Samuel Henrique 



Bug#1043550: links against libcurl3-nss which will be dropped in August 2023

2023-08-12 Thread Samuel Henrique
Package: llvm-toolchain-14
Tags: trixie sid
User: c...@packages.debian.org
Usertags: curl-nss-deprecation
X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org
Control: block 1038907 by -1

Hello,

Curl's upstream dropped support for NSS earlier this month:
https://curl.se/dev/deprecate.html#nss

I plan on removing libcurl4-nss-dev and libcurl3-nss in the next
couple of weeks, but this can be delayed if we spot issues (seems like
it will be straightforward for llvm though).

The llvm-toolchain packages will require minimal changes to allow for
libcurl3-nss to be dropped.

d/control lists "libcurl4-dev" as a B-D, and it turns out that the
build process is linking against libcurl3-nss in some archs.

We have two options to deal with this:
1) Explicitly chose a non-nss preferred tls backend on B-D, eg.:
"libcurl4-openssl-dev | libcurl-dev,".
2) BinNMUs after curl drops the nss packages.

The first option is better for me as the dependency can be removed
earlier and it will be less work for me, but number 2 doesn't require
any actions from you (thus why this bug is being cut late).

What would be your preferred option?

Thank you,

-- 
Samuel Henrique 



Bug#1043539: project: Forwarding of @debian.org mails to gmail broken

2023-08-12 Thread Russ Allbery
Helge Kreutzmann  writes:

> It's just that I never had this problem with mails to people with
> @debian.org addresses, so either my new configuration or some other
> change, I don't know.

The problem I suspect is with email forwarding, and specifically email
forwarding to Gmail, which has recently ramped up the amount of
verification it does on messages.  Because of email forwarding, Gmail sees
a message purportedly from helgefjell.de but actually delivered by
debian.org mail servers, and has now decided to be suspicious of that.

If that's correct, you'll only have this problem with Debian developers
who forward their @debian.org addresses to Gmail.  Gmail handles some
large percentage of all email on the Internet, so this probably isn't
rare, but Debian developers are less likely to use it than random Internet
users for obvious reasons, so it doesn't surprise me you've not run into
the problem before.  (In other words, I doubt this is a problem with your
local configuration.)

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



Bug#1043548: fastdds: CVE-2023-39945 CVE-2023-39946 CVE-2023-39947

2023-08-12 Thread Salvatore Bonaccorso
Source: fastdds
Version: 2.10.1+ds-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for fastdds.

CVE-2023-39945[0]:
| eprosima Fast DDS is a C++ implementation of the Data Distribution
| Service standard of the Object Management Group. Prior to versions
| 2.11.0, 2.10.2, 2.9.2, and 2.6.5, a data submessage sent to PDP port
| raises unhandled `BadParamException` in fastcdr, which in turn
| crashes fastdds. Versions 2.11.0, 2.10.2, 2.9.2, and 2.6.5 contain a
| patch for this issue.


CVE-2023-39946[1]:
| eprosima Fast DDS is a C++ implementation of the Data Distribution
| Service standard of the Object Management Group. Prior to versions
| 2.11.1, 2.10.2, 2.9.2, and 2.6.6, heap can be overflowed by
| providing a PID_PROPERTY_LIST parameter that contains a CDR string
| with length larger than the size of actual content. In
| `eprosima::fastdds::dds::ParameterPropertyList_t::push_back_helper`,
| `memcpy` is called to first copy the octet'ized length and then to
| copy the data into `properties_.data`. At the second memcpy, both
| `data` and `size` can be controlled by anyone that sends the CDR
| string to the discovery multicast port. This can remotely crash any
| Fast-DDS process. Versions 2.11.1, 2.10.2, 2.9.2, and 2.6.6 contain
| a patch for this issue.


CVE-2023-39947[2]:
| eprosima Fast DDS is a C++ implementation of the Data Distribution
| Service standard of the Object Management Group. Prior to versions
| 2.11.1, 2.10.2, 2.9.2, and 2.6.6, even after the fix at commit
| 3492270, malformed `PID_PROPERTY_LIST` parameters cause heap
| overflow at a different program counter. This can remotely crash any
| Fast-DDS process. Versions 2.11.1, 2.10.2, 2.9.2, and 2.6.6 contain
| a patch for this issue.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-39945
https://www.cve.org/CVERecord?id=CVE-2023-39945
[1] https://security-tracker.debian.org/tracker/CVE-2023-39946
https://www.cve.org/CVERecord?id=CVE-2023-39946
[2] https://security-tracker.debian.org/tracker/CVE-2023-39947
https://www.cve.org/CVERecord?id=CVE-2023-39947

Regards,
Salvatore



Bug#1043547: build-depends on deprecated libcurl4-nss-dev, will be dropped in August 2023

2023-08-12 Thread Samuel Henrique
Package: eg25-manager
Tags: trixie sid patch
User: c...@packages.debian.org
Usertags: curl-nss-deprecation
X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org
Control: block 1038907 by -1

Hello,

This package build-depends on the NSS variant of libcurl "libcurl4-nss-dev".

Curl's upstream announced support for NSS is going to be dropped in August
2023:
https://curl.se/dev/deprecate.html#nss

Please make sure to switch your build-dependency to something else before the
due date.
You might try switching to "libcurl4-openssl-dev" and in the big majority of
the cases this won't cause any issues.

Since eg25-manager already accepts libcurl-dev as a build-dependency,
I've submitted a PR changing the preferred curl variant to be openssl:
https://salsa.debian.org/DebianOnMobile-team/eg25-manager/-/merge_requests/5

This bug is being opened late for eg25-manager as I didn't catch it
when doing the initial search for rdeps, the change will be simple for
this package due to it already accepting other backends through
"libcurl-dev".
This is only a matter of changing the prefered one and getting a build
that links against something other than the nss variant.

Thank you,

-- 
Samuel Henrique 



Bug#1043317: duck: Please drop "parked domain" test

2023-08-12 Thread gregor herrmann
On Sat, 12 Aug 2023 14:54:16 +0200, Baptiste Beauplat wrote:

> > Checking for "deprecated" (on upstream websites which document
> > functions) or "replaced (by|with)" doesn't make any sense IMO …
> > Please just remove tese tests …
> First, I agree with you, "replaced (by|with)" and "deprecated" are too
> generic not to trigger false positives. I'll be removing them from the
> list.

Excellent!
I guess that solves most of my grievances with duck.
 
> Secondly, even if, as stated by the check certainty, the suggestion is
> at most a wild-guess, I would like to keep the test as it can still be
> useful to catch deprecated projets or links that moved on to another
> page. However, I want to have a way for users to filter the checks
> based on certainty. I'll be adding an option for that both in the cli
> arguments and the configuration file. Although, I'll keep the default
> to show all checks.

Sounds good as well.
 
> Finally, the checks for obsoletes sites is currently at a certainty of
> wild-guess. I'll be bumping that to possible as, to the contrary of the
> parked test, its a list of well known deprecated sites, and virtually
> has no chance of false positive.

I guess that makes sense for well-known obsolete sites.

Thanks for maintaining and improving duck!


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature


Bug#1043545: numba: autopkgtest runs no tests

2023-08-12 Thread Paul Gevers
Source: numba
Version: 0.57.1+dfsg-1
Severity: important

Hi,

It looks like something went wrong with the last upload as I don't see
mention of dropping all tests, but the last log [1] has:

Ran 0 tests in 0.000s

So no tests were run.

[1]
https://ci.debian.net/data/autopkgtest/testing/arm64/n/numba/36688390/log.gz
https://ci.debian.net/data/autopkgtest/testing/i386/n/numba/36690497/log.gz
https://ci.debian.net/data/autopkgtest/testing/ppc64el/n/numba/36691218/log.gz



Bug#1043539: project: Forwarding of @debian.org mails to gmail broken

2023-08-12 Thread Helge Kreutzmann
Hello Russ,
Am Sat, Aug 12, 2023 at 11:31:35AM -0700 schrieb Russ Allbery:
> Helge Kreutzmann  writes:
> 
> > I don't know how it worked so far, and the error could be on my side, as
> > I recently switched my e-mail setup; however, I don't see anything I can
> > do to make DKIM/SPF point to @debian.org instead of @helgefjell.de, when
> > transferring e-mail to gmail.
> 
> The mail to which I'm resonding also comes from your @helgefjell.de
> domain, so I'm suspecting some DKIM/SPF issues there if you're using that
> same address in your original mail message.  But just in case you were

Yes, this is my primary e-mail address

> trying to send from your @debian.org address, one option is to send all of
> your outgoing mail that is from your debian.org address through the
> debian.org mail servers.  See:
> 
> https://dsa.debian.org/user/mail-submit/
> 
> I don't think this is the direct answer to your original question, but I
> suspect it would work around the problem.

Thanks for taking care, but I don't have an @debian.org address.

Greetings

 Helge

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


signature.asc
Description: PGP signature


Bug#1043539: project: Forwarding of @debian.org mails to gmail broken

2023-08-12 Thread Helge Kreutzmann
Hello Adam,
Am Sat, Aug 12, 2023 at 06:11:43PM +0100 schrieb Adam D. Barratt:
> On Sat, 2023-08-12 at 17:08 +, Helge Kreutzmann wrote:
> > Directly gmail accepts it.
> > 
> 
> I'm not sure why the sigh, but in any case your direct mail presumably
> succeeds because it passes the SPF check. I was simply clarifying that
> the DKIM check would fail in both cases.

Well, I did have trouble sending directly to gmail accounts, which now
seems to work. Now the next e-mail problem arises, which I need to see
how much I can configure it to work. That's the sigh.

It's just that I never had this problem with mails to people with
@debian.org addresses, so either my new configuration or some other
change, I don't know.

I hope this explains it a little.

Greetings

Helge

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


signature.asc
Description: PGP signature


Bug#1043546: tracker.debian.org: tracker.d.o displaying inconsistent information

2023-08-12 Thread Samuel Henrique
Package: tracker.debian.org
X-Debbugs-Cc: samuel...@debian.org, e...@kiyuko.org, guilherme@gmail.com
Severity: important

>From the thread on d-devel named "tracker.d.o displaying inconsistent
information":
On Sat, 12 Aug 2023 at 16:19, Andrea Bolognani  wrote:
>
> Hi,
>
> if you look at the tracker.d.o page for libvirt[1] you'll see that it
> displays inconsistent information.
>
> Specifically, the "news" sections mentions the recent (2023-08-08)
> upload of 9.6.0-1[2], but the "action needed" section still claims
> that a new upstream version is available; the vcswatch message is
> consistent with this. A security issue is also mentioned as still
> open in sid, while in reality the recent upload addressed it and the
> security tracker[3] correctly reports this.
>
> Further down, in the "testing migrations" section, the excuses
> reported are for the *9.5.0-2* version, which is an earlier
> (2023-07-25) upload. Looking at the current excuses[4] correctly
> refer to the 9.6.0-1 version, where migration is apparently held up
> because of gnutls28.
>
> There are more inconsistencies, but you get the point. I'm pretty
> sure everything will go back to normal given enough time, but it
> looks like the particular set of circumstances around the libvirt
> package have fallen through the cracks of tracker.d.o's logic and it
> could be interesting to investigate them while the issue is still
> manifesting itself.
>
> Cheers!
>
>
> [1] https://tracker.debian.org/pkg/libvirt
> [2] 
> https://tracker.debian.org/news/1451405/accepted-libvirt-960-1-source-into-unstable/
> [3] https://security-tracker.debian.org/tracker/source-package/libvirt
> [4] https://qa.debian.org/excuses.php?package=libvirt
> --
> Andrea Bolognani 
> Resistance is futile, you will be garbage collected.

Then my reply:
I've noticed issues for other packages[0][1][2][3] and they might all
be related.
grequests has been accepted 3 days ago and its tracker page is missing data.
nmap's migration counter is stuck at 0: "Too young, only 0 of 5 days old".
licenseutils and dd-opentracing-cpp both have RC bugs that don't show
up on tracker, they likely have already been picked by the autoremoval
tool (and might have a removal date set).

And noticed just now: both curl and nmap's debci results are not
up-to-date on tracker.

[0] https://tracker.debian.org/pkg/grequests
[1] https://tracker.debian.org/pkg/nmap
[2] https://tracker.debian.org/pkg/licenseutils
[3] https://tracker.debian.org/pkg/dd-opentracing-cpp

I believe there's something wrong with tracker's interface.

Cheers,
-- 
Samuel Henrique 



Bug#1043543: autopkgtest: /usr/share/autopkgtest/lib/__pycache__ is not managed

2023-08-12 Thread Alexandre Detiste
Le sam. 12 août 2023 à 20:16, Paul Gevers  a écrit :
>
> Call me innocent, but I'm not even seeing cache files on my system for
> the recent python. When are these files created?
>
> Paul

I think I just ran autopkgtest once, as root, on this day at 2am...
I think I should sleep more.

So they are created anytime a user with write access to
/usr/share/autopkgtest/lib
run autopkgtest, which means root.

dh_python3 would add the calls to py3compile/py3clean,
but might have other side effects for your package that have to be
backportable to oldstable(?not sure) so you might consider calling
py3{compile/clean} directly.

Not having the .pyc files at all induce a tiny performance drop.

Another attempt right now:

$ ls -l /usr/share/autopkgtest/lib/__pycache__/*310*.pyc --full-time
-rw-r--r-- 1 root root  4276 2022-11-03 02:34:17.512478073 +0100
/usr/share/autopkgtest/lib/__pycache__/adt_binaries.cpython-310.pyc
-rw-r--r-- 1 root root  2940 2022-11-03 02:34:17.412477486 +0100
/usr/share/autopkgtest/lib/__pycache__/adtlog.cpython-310.pyc
-rw-r--r-- 1 root root 40030 2022-11-03 02:34:17.488477932 +0100
/usr/share/autopkgtest/lib/__pycache__/adt_testbed.cpython-310.pyc
-rw-r--r-- 1 root root 12270 2022-11-03 02:34:17.520478120 +0100
/usr/share/autopkgtest/lib/__pycache__/autopkgtest_args.cpython-310.pyc
-rw-r--r-- 1 root root 17628 2022-11-03 02:34:17.428477580 +0100
/usr/share/autopkgtest/lib/__pycache__/testdesc.cpython-310.pyc
-rw-r--r-- 1 root root 21171 2022-11-03 02:34:17.508478050 +0100
/usr/share/autopkgtest/lib/__pycache__/VirtSubproc.cpython-310.pyc

Original timestamps, that don't match any release date or migration to testing
or the time of day when unattended-upgrades run:

tchet@brix ~/git/cruft-ng $ ls -l
/usr/share/autopkgtest/lib/__pycache__/*311*.pyc --full-time
-rw-r--r-- 1 root root  7748 2023-08-12 20:52:27.131803347 +0200
/usr/share/autopkgtest/lib/__pycache__/adt_binaries.cpython-311.pyc
-rw-r--r-- 1 root root  5248 2023-08-12 20:52:27.067803064 +0200
/usr/share/autopkgtest/lib/__pycache__/adtlog.cpython-311.pyc
-rw-r--r-- 1 root root 79617 2023-08-12 20:52:27.179803560 +0200
/usr/share/autopkgtest/lib/__pycache__/adt_testbed.cpython-311.pyc
-rw-r--r-- 1 root root 21495 2023-08-12 20:52:27.215803720 +0200
/usr/share/autopkgtest/lib/__pycache__/autopkgtest_args.cpython-311.pyc
-rw-r--r-- 1 root root 31364 2023-08-12 20:52:27.087803152 +0200
/usr/share/autopkgtest/lib/__pycache__/testdesc.cpython-311.pyc
-rw-r--r-- 1 root root 41735 2023-08-12 20:52:27.203803667 +0200
/usr/share/autopkgtest/lib/__pycache__/VirtSubproc.cpython-311.pyc

Some minimal package that do the right thing:

$ cat /var/lib/dpkg/info/python3-six.postinst
# Automatically added by dh_python3
if command -v py3compile >/dev/null 2>&1; then
py3compile -p python3-six
fi
# End automatically added section

$ cat /var/lib/dpkg/info/python3-six.prerm
# Automatically added by dh_python3
if command -v py3clean >/dev/null 2>&1; then
py3clean -p python3-six
fi
# End automatically added section



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

2023-08-12 Thread Hans-J. Ullrich
Package: libkscreenlocker5
Version: 5.27.5-2
Followup-For: Bug #894892

Dear Maintainer,

tried with a fresh user, but no success. Verified and confirm, that "loginctl 
unlock-session XX" as normal user is unlockung the session. So it looks like 
this command might not be sent correctly from KDE.

Tested on two computers, both running debian bookworm, actual packages, same 
package status.

Both computers got this issue. NOT tested on my 32-bit system yet. 

I will tell more, if I got news.

Thanks for any help.

Best regards

Hans

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

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

Versions of packages libkscreenlocker5 depends on:
ii  kio5.103.0-1
ii  kpackagetool5  5.103.0-1
ii  libc6  2.36-9+deb12u1
ii  libkf5configcore5  5.103.0-2
ii  libkf5configgui5   5.103.0-2
ii  libkf5configqml5   5.103.0-2
ii  libkf5coreaddons5  5.103.0-1
ii  libkf5crash5   5.103.0-1
ii  libkf5declarative5 5.103.0-1
ii  libkf5globalaccel-bin  5.103.0-1
ii  libkf5globalaccel5 5.103.0-1
ii  libkf5i18n55.103.0-1
ii  libkf5idletime55.103.0-2
ii  libkf5kiocore5 5.103.0-1
ii  libkf5notifications5   5.103.0-1
ii  libkf5package5 5.103.0-1
ii  libkf5quickaddons5 5.103.0-1
ii  libkf5screendpms8  4:5.27.5-2
ii  libkf5waylandclient5   4:5.103.0-1
ii  libkf5windowsystem55.103.0-1
ii  libkf5xmlgui5  5.103.0-1
ii  liblayershellqtinterface5  5.27.5-2
ii  libpam0g   1.5.2-6
ii  libqt5core5a   5.15.8+dfsg-11
ii  libqt5dbus55.15.8+dfsg-11
ii  libqt5gui5 5.15.8+dfsg-11
ii  libqt5network5 5.15.8+dfsg-11
ii  libqt5qml5 5.15.8+dfsg-3
ii  libqt5quick5   5.15.8+dfsg-3
ii  libqt5widgets5 5.15.8+dfsg-11
ii  libqt5x11extras5   5.15.8-2
ii  libstdc++6 12.2.0-14
ii  libwayland-client0 1.21.0-1
ii  libwayland-server0 1.21.0-1
ii  libx11-6   2:1.8.4-2+deb12u1
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb11.15-1
ii  libxi6 2:1.8-1+b1
ii  psmisc 23.6-1

Versions of packages libkscreenlocker5 recommends:
ii  kde-config-screenlocker  5.27.5-2

libkscreenlocker5 suggests no packages.

-- debconf-show failed



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

2023-08-12 Thread Paul Gevers

Hi,

On 12-08-2023 16:31, Carsten Schoenert wrote:

Am 12.08.23 um 15:40 schrieb Paul Gevers:


I'm trying to do that, but it's a fight.


I successfully imported my key again, and as you can see with this 
message, it's both signed and sent with firefox. So I confirm that the 
work around works in my case.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1043539: project: Forwarding of @debian.org mails to gmail broken

2023-08-12 Thread Russ Allbery
Helge Kreutzmann  writes:

> I don't know how it worked so far, and the error could be on my side, as
> I recently switched my e-mail setup; however, I don't see anything I can
> do to make DKIM/SPF point to @debian.org instead of @helgefjell.de, when
> transferring e-mail to gmail.

The mail to which I'm resonding also comes from your @helgefjell.de
domain, so I'm suspecting some DKIM/SPF issues there if you're using that
same address in your original mail message.  But just in case you were
trying to send from your @debian.org address, one option is to send all of
your outgoing mail that is from your debian.org address through the
debian.org mail servers.  See:

https://dsa.debian.org/user/mail-submit/

I don't think this is the direct answer to your original question, but I
suspect it would work around the problem.

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



Bug#1043543: autopkgtest: /usr/share/autopkgtest/lib/__pycache__ is not managed

2023-08-12 Thread Paul Gevers

Hi,

On 12-08-2023 19:42, Alexandre Detiste wrote:

I have got old, stale, python3.10 cache files from autopkgtest on my system.


Call me innocent, but I'm not even seeing cache files on my system for 
the recent python. When are these files created?


Paul


Bug#1043543: Acknowledgement (autopkgtest: /usr/share/autopkgtest/lib/__pycache__ is not managed)

2023-08-12 Thread Alexandre Detiste
Sorry to spam, but cruft needs the full filenames in the BTS
to build a greylist of files. (along came a spider)

/usr/share/autopkgtest/lib/__pycache__/VirtSubproc.cpython-310.pyc
/usr/share/autopkgtest/lib/__pycache__/adt_binaries.cpython-310.pyc
/usr/share/autopkgtest/lib/__pycache__/adt_testbed.cpython-310.pyc
/usr/share/autopkgtest/lib/__pycache__/adtlog.cpython-310.pyc
/usr/share/autopkgtest/lib/__pycache__/autopkgtest_args.cpython-310.pyc
/usr/share/autopkgtest/lib/__pycache__/testdesc.cpython-310.pyc



Bug#1043544: qemu kvm rtl8139 interface breaks with linux-image-5.10.0-24-amd64

2023-08-12 Thread Jamin Hoggard
Package: linux-image-amd64
Version: linux-image-5.10.0-24-amd64

Upon updating a server hosting qemu-system-x86_64 / kvm virtual
machines (VMs) from linux-image-5.10.0-23-amd64 to
linux-image-5.10.0-24-amd64 and rebooting, all VM OSes saw the rtl8139
network interface as unplugged (and the network link down).  Trying to
change the interface state via the QEMU monitor command "set_link
 off" then "set_link  on" runs, but the VM OS still sees
the interface as unplugged.  Rebooting the host OS or VMs had no
effect.

The rtl8139 interfaces for the VMs work fine booting using earlier
kernel versions.

Server info:
CPU: AMD EPYC 7282 16-Core Processor
microcode: microcode updated early to new patch_level=0x0830107a

The same problem was not observed on an Intel server using virtio
network interfaces with the same kernel update.

I suspect the problem may be caused by the patches for INCEPTION
because the EPYC 7282 processor is affected by that (and Zenbleed),
but that may be incorrect.



Bug#1043543: autopkgtest: /usr/share/autopkgtest/lib/__pycache__ is not managed

2023-08-12 Thread Alexandre Detiste
Package: autopkgtest
Version: 5.30
Severity: minor
User: cruft...@packages.debian.org
Usertags: cruft

Hi,

I have got old, stale, python3.10 cache files from autopkgtest on my system.


I think that simply using some modern DebHelper plugin
would ensure that the .pyc files are correctly generated on postinst
and correctly removed in post rm.

To clean-up the past I suggest a
"rm -f /usr/share/autopkgtest/lib/__pycache__/*-cpython-310.pyc"
in preinst/postinst.

Greetings,



$ ls /usr/share/autopkgtest/lib/__pycache__ -l
total 108
-rw-r--r-- 1 root root  4276  3 nov  2022 adt_binaries.cpython-310.pyc
-rw-r--r-- 1 root root  2940  3 nov  2022 adtlog.cpython-310.pyc
-rw-r--r-- 1 root root 40030  3 nov  2022 adt_testbed.cpython-310.pyc
-rw-r--r-- 1 root root 12270  3 nov  2022 autopkgtest_args.cpython-310.pyc
-rw-r--r-- 1 root root 17628  3 nov  2022 testdesc.cpython-310.pyc
-rw-r--r-- 1 root root 21171  3 nov  2022 VirtSubproc.cpython-310.pyc
$ py3versions -s
python3.11



https://www.debian.org/doc/packaging-manuals/python-policy

> 4.7. Modules Byte-Compilation
>
> If a binary package provides any binary-independent modules (foo.py files),
> the corresponding byte-compiled modules (foo.pyc files)
> must not ship in the package.
> Instead, they should be generated in the package’s post-install script,
> and removed in the package’s pre-remove script.


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

Kernel: Linux 6.4.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autopkgtest depends on:
ii  apt-utils   2.6.1
ii  libdpkg-perl1.21.22
ii  mawk1.3.4.20230730-1
ii  procps  2:4.0.3-1
ii  python3 3.11.4-5
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
pn  autodep8  
ii  fakeroot  1.32.1-1

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
pn  lxc  
pn  lxd  
pn  ovmf 
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.5
pn  qemu-efi-aarch64 
pn  qemu-efi-arm 
pn  qemu-system  
pn  qemu-utils   
ii  schroot  1.6.13-3+b2
ii  util-linux   2.39.1-3
pn  vmdb2
pn  zerofree 

-- no debconf information


Bug#1043542: waybar: FTBFS on mips64el (test fails due to UTC time not available)

2023-08-12 Thread Diederik de Haas
On Sat, 12 Aug 2023 19:24:16 +0200 Bastian Germann  wrote:
> Source: waybar
> Version: 0.9.20-2
> Severity: serious
> 
> The build fails on mips64el due to:
> 
> test: waybar
> start time:   15:11:25
> duration: 0.02s
> result:   killed by signal 6 SIGABRT
> command:  MALLOC_PERTURB_=25 
> /<>/obj-mips64el-linux-gnuabi64/test/waybar_test
> --- stderr 
> ---
> terminate called after throwing an instance of 'std::runtime_error'
>what():  UTC not found in timezone database

Isn't that caused by https://bugs.debian.org/1043250 ?

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


Bug#1043542: waybar: FTBFS on mips64el (test fails due to UTC time not available)

2023-08-12 Thread Bastian Germann

Source: waybar
Version: 0.9.20-2
Severity: serious

The build fails on mips64el due to:

test: waybar
start time:   15:11:25
duration: 0.02s
result:   killed by signal 6 SIGABRT
command:  MALLOC_PERTURB_=25 
/<>/obj-mips64el-linux-gnuabi64/test/waybar_test
--- stderr 
---

terminate called after throwing an instance of 'std::runtime_error'
  what():  UTC not found in timezone database



Bug#1043539: project: Forwarding of @debian.org mails to gmail broken

2023-08-12 Thread Adam D. Barratt
On Sat, 2023-08-12 at 17:08 +, Helge Kreutzmann wrote:
> Hello Adam,
> Am Sat, Aug 12, 2023 at 05:35:52PM +0100 schrieb Adam D. Barratt:
> > On Sat, 2023-08-12 at 15:54 +, Helge Kreutzmann wrote:
[...]
> > > 550-5.7.26 This mail is unauthenticated, which poses a
> > > security
> > > risk to the
> > > 550-5.7.26 sender and Gmail users, and has been blocked. The
> > > sender must
> > > 550-5.7.26 authenticate with at least one of SPF or DKIM. For
> > > this message,
> > > 550-5.7.26 DKIM checks did not pass and SPF check for
> > > [helgefjell.de] did not
> > > 
[...]
> > > 550-5.7.26  
> > > https://support.google.com/mail/answer/81126#authentication for
> > > 550 5.7.26 instructions on setting up authentication. v26-
> > > 20020aa7d65a00b005231f55294dsi4996663edr.385 - gsmtp
> > > 
> > > The IP 82.195.75.114 resolves to 
> > > 114.75.195.82.in-addr.arpa is an alias for 114.64-
> > > 26.75.195.82.in-
> > > addr.arpa.
> > > 114.64-26.75.195.82.in-addr.arpa domain name pointer
> > > mailly.debian.org.
> > > 
> > > And of course, SPF/DKIM checks for my domain (helgefjell.de) fail
> > > for this IP, which is @debian.org.
> > > 
> > 
> > The DKIM signature warning has nothing to do with the forwarding,
> > or the involvement of debian.org at all. The reason that check
> > fails is that your mail has no DKIM signature, so obviously can't
> > have a valid one. Signing your mail would probably make gmail a lot
> > happier with it in general. (As a side note, the BTS breaks many
> > common DKIM signature strategies, but that's a different issue.)
> 
> Sigh. 
> 
> Directly gmail accepts it.
> 

I'm not sure why the sigh, but in any case your direct mail presumably
succeeds because it passes the SPF check. I was simply clarifying that
the DKIM check would fail in both cases.

Regards,

Adam



Bug#1043539: project: Forwarding of @debian.org mails to gmail broken

2023-08-12 Thread Helge Kreutzmann
Hello Adam,
Am Sat, Aug 12, 2023 at 05:35:52PM +0100 schrieb Adam D. Barratt:
> On Sat, 2023-08-12 at 15:54 +, Helge Kreutzmann wrote:
> > If I try to mail e.g. Marcos Fouces , this no
> > longer works. I get the following error message:
> > 
> 
> Contacting DSA is generally a better way to ask about infrastructure
> things than filing bugs on high-level pseudo-packages.

Thanks, then I know this for the future. 

> > This message was created automatically by mail delivery software.
> > 
> > A message that you sent could not be delivered to one or more of its
> > recipients. This is a permanent error. The following address(es)
> > failed:
> > 
> >   marcos.fou...@gmail.com
> > host gmail-smtp-in.l.google.com [173.194.79.26]
> > SMTP error from remote mail server after pipelined end of data:
> > 550-5.7.26 This mail is unauthenticated, which poses a security
> > risk to the
> > 550-5.7.26 sender and Gmail users, and has been blocked. The
> > sender must
> > 550-5.7.26 authenticate with at least one of SPF or DKIM. For
> > this message,
> > 550-5.7.26 DKIM checks did not pass and SPF check for
> > [helgefjell.de] did not
> > 550-5.7.26 pass with ip: [82.195.75.114]. The sender should visit
> > 550-5.7.26  
> > https://support.google.com/mail/answer/81126#authentication for
> > 550 5.7.26 instructions on setting up authentication. v26-
> > 20020aa7d65a00b005231f55294dsi4996663edr.385 - gsmtp
> > 
> > The IP 82.195.75.114 resolves to 
> > 114.75.195.82.in-addr.arpa is an alias for 114.64-26.75.195.82.in-
> > addr.arpa.
> > 114.64-26.75.195.82.in-addr.arpa domain name pointer
> > mailly.debian.org.
> > 
> > And of course, SPF/DKIM checks for my domain (helgefjell.de) fail for
> > this IP, which is @debian.org.
> > 
> 
> The DKIM signature warning has nothing to do with the forwarding, or
> the involvement of debian.org at all. The reason that check fails is
> that your mail has no DKIM signature, so obviously can't have a valid
> one. Signing your mail would probably make gmail a lot happier with it
> in general. (As a side note, the BTS breaks many common DKIM signature
> strategies, but that's a different issue.)

Sigh. 

Directly gmail accepts it.

> The general issue is being worked on, as time and resources allow.

Thanks a lot!

Greetings

 Helge

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


signature.asc
Description: PGP signature


Bug#1043541: src:gcc-sh-elf: fails to migrate to testing for too long: unresolved RC issue

2023-08-12 Thread Paul Gevers

Source: gcc-sh-elf
Version: 6
Severity: serious
Control: close -1 7
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1040960

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:gcc-sh-elf has been trying to migrate for 
32 days [2]. Hence, I am filing this bug. The version in unstable is 
affected by 1040960.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=gcc-sh-elf



Bug#1043270: autofs 5.1.7-1+deb11u2 flagged for acceptance

2023-08-12 Thread Jonathan Wiltshire
package release.debian.org
tags 1043270 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: autofs
Version: 5.1.7-1+deb11u2

Explanation: fix regression determining reachability on dual-stack hosts



Bug#1043398: closed by Bastian Germann (Re: Bug#1043398: bookworm-pu: package filezilla/3.63.0-1+deb12u1)

2023-08-12 Thread Bastian Germann

Am 12.08.23 um 18:52 schrieb Jonathan Wiltshire:
Don't close release tracking bugs please; that will happen when the 
package is actually released.


Oh, I am sorry. Actually, I wanted to close the RFS.



Bug#1043422: nco 5.1.4-1+deb12u1 flagged for acceptance

2023-08-12 Thread Jonathan Wiltshire
package release.debian.org
tags 1043422 = 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: nco
Version: 5.1.4-1+deb12u1

Explanation: re-enable udunits2 support



Bug#1043229: open-ath9k-htc-firmware 1.4.0-108-gd856466+dfsg1-1.3+deb12u1 flagged for acceptance

2023-08-12 Thread Jonathan Wiltshire
package release.debian.org
tags 1043229 = 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: open-ath9k-htc-firmware
Version: 1.4.0-108-gd856466+dfsg1-1.3+deb12u1

Explanation: load correct firmware



Bug#1043398: closed by Bastian Germann (Re: Bug#1043398: bookworm-pu: package filezilla/3.63.0-1+deb12u1)

2023-08-12 Thread Jonathan Wiltshire
Control: reopen -1

On Sat, Aug 12, 2023 at 03:00:03PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the release.debian.org package:
> 
> #1043398: bookworm-pu: package filezilla/3.63.0-1+deb12u1
> 
> It has been closed by Bastian Germann .

Don't close release tracking bugs please; that will happen when the package
is actually released.



-- 
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#1043540: ITP: python-mapclassify -- Classification Schemes for Choropleth Maps

2023-08-12 Thread Josenilson Ferreira da Silva
Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-mapclassify
  Version : 2.6.0
  Upstream Contact: PySAL Developers 
* URL : https://github.com/pysal/mapclassify
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Classification Schemes for Choropleth Maps

 Module needed to run the tests package "spopt that is under ITP: #1023521
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023521



Bug#1043539: project: Forwarding of @debian.org mails to gmail broken

2023-08-12 Thread Adam D. Barratt
Hi,

On Sat, 2023-08-12 at 15:54 +, Helge Kreutzmann wrote:
> If I try to mail e.g. Marcos Fouces , this no
> longer works. I get the following error message:
> 

Contacting DSA is generally a better way to ask about infrastructure
things than filing bugs on high-level pseudo-packages.

> This message was created automatically by mail delivery software.
> 
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es)
> failed:
> 
>   marcos.fou...@gmail.com
> host gmail-smtp-in.l.google.com [173.194.79.26]
> SMTP error from remote mail server after pipelined end of data:
> 550-5.7.26 This mail is unauthenticated, which poses a security
> risk to the
> 550-5.7.26 sender and Gmail users, and has been blocked. The
> sender must
> 550-5.7.26 authenticate with at least one of SPF or DKIM. For
> this message,
> 550-5.7.26 DKIM checks did not pass and SPF check for
> [helgefjell.de] did not
> 550-5.7.26 pass with ip: [82.195.75.114]. The sender should visit
> 550-5.7.26  
> https://support.google.com/mail/answer/81126#authentication for
> 550 5.7.26 instructions on setting up authentication. v26-
> 20020aa7d65a00b005231f55294dsi4996663edr.385 - gsmtp
> 
> The IP 82.195.75.114 resolves to 
> 114.75.195.82.in-addr.arpa is an alias for 114.64-26.75.195.82.in-
> addr.arpa.
> 114.64-26.75.195.82.in-addr.arpa domain name pointer
> mailly.debian.org.
> 
> And of course, SPF/DKIM checks for my domain (helgefjell.de) fail for
> this IP, which is @debian.org.
> 

The DKIM signature warning has nothing to do with the forwarding, or
the involvement of debian.org at all. The reason that check fails is
that your mail has no DKIM signature, so obviously can't have a valid
one. Signing your mail would probably make gmail a lot happier with it
in general. (As a side note, the BTS breaks many common DKIM signature
strategies, but that's a different issue.)

The general issue is being worked on, as time and resources allow.

Regards,

Adam
(part of, but not on behalf of, DSA)



Bug#1043539: project: Forwarding of @debian.org mails to gmail broken

2023-08-12 Thread Helge Kreutzmann
Package: project
Severity: important

If I try to mail e.g. Marcos Fouces , this no
longer works. I get the following error message:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  marcos.fou...@gmail.com
host gmail-smtp-in.l.google.com [173.194.79.26]
SMTP error from remote mail server after pipelined end of data:
550-5.7.26 This mail is unauthenticated, which poses a security risk to the
550-5.7.26 sender and Gmail users, and has been blocked. The sender must
550-5.7.26 authenticate with at least one of SPF or DKIM. For this message,
550-5.7.26 DKIM checks did not pass and SPF check for [helgefjell.de] did 
not
550-5.7.26 pass with ip: [82.195.75.114]. The sender should visit
550-5.7.26  https://support.google.com/mail/answer/81126#authentication for
550 5.7.26 instructions on setting up authentication. 
v26-20020aa7d65a00b005231f55294dsi4996663edr.385 - gsmtp

The IP 82.195.75.114 resolves to 
114.75.195.82.in-addr.arpa is an alias for 114.64-26.75.195.82.in-addr.arpa.
114.64-26.75.195.82.in-addr.arpa domain name pointer mailly.debian.org.

And of course, SPF/DKIM checks for my domain (helgefjell.de) fail for
this IP, which is @debian.org.

I don't know how it worked so far, and the error could be on my side, as I 
recently switched my e-mail setup; however, I don't see anything I can
do to make DKIM/SPF point to @debian.org instead of @helgefjell.de,
when transferring e-mail to gmail.

Greetings

 Helge

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


signature.asc
Description: PGP signature


Bug#919587: bringing back Imapsync

2023-08-12 Thread J. Fernando LAGRANGE

Hello,

Is there someone getting this beautiful software to Debian ?

If not, I volunteer to contribute.


Some more context on my part:
We use IMAPSync at work and I have built [1] a repo with it last year.

Now that Debian 12 is out, it has been decided that it was not worth 
maintaining a server only for this package, so we will remove such 
server. :'-(


(For now it is available in http://deb.probesys.com ; beware: no SSL !)


[1] With code available in salsa, build was pretty straightforward:

mkdir imapsync-build && cd imapsync-build
gbp clone https://salsa.debian.org/RAPS/imapsync.git
cd imapsync
git branch upstream
gbp import-orig 
https://imapsync.lamiral.info/dist/old_releases/1.945/imapsync-1.945.tgz

[version to indicate: 1.945+dfsg1 ]
gbp pq import
gbp buildpackage


Regards,
--
J. Fernando Lagrange
PROBESYS - Spécialistes OpenSource


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1043538: RFS: odr-dabmux/4.4.1-1 -- Digital Audio Broadcasting multiplexer compliant to ETSI EN 300 401

2023-08-12 Thread Robin Alexander
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a 
sponsor for my package "odr-dabmux": * Package name : odr-dabmux Version : 
4.4.1-1 Upstream contact : Matthias P. Braendli  * URL : 
https://www.opendigitalradio.org/Mmbtools * License : FSFAP, GPL-3.0+, BSL-1.0, 
Expat, Apache-2.0, GPL-2.0+, LGPL-2.1, GPL-3.0+ with autoconf exception * Vcs : 
https://salsa.debian.org/ralex/odr-dabmux Section : hamradio The source builds 
the following binary packages: odr-dabmux - Digital Audio Broadcasting 
multiplexer compliant to ETSI EN 300 401 To access further information about 
this package, please visit the following URL: 
https://mentors.debian.net/package/odr-dabmux/ Alternatively, you can download 
the package with 'dget' using this command: dget -x 
https://mentors.debian.net/debian/pool/main/o/odr-dabmux/odr-dabmux_4.4.1-1.dsc 
Changes since the last upload: odr-dabmux (4.4.1-1) unstable; urgency=low . * 
New upstream version 4.4.1 Regards, -- Robin Alexander

Bug#1043537: RM: ruby-ferret -- RoQA; FTBFS; incompatible with ruby3.0; upstream dead

2023-08-12 Thread Chris Hofstaedtler
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: pkg-ruby-extras-maintain...@lists.alioth.debian.org

Dear ftpmasters,

please remove ruby-ferret. It FTBFS with ruby3.0 and newer, and is not
in stable/testing.
#996227 about the FTBFS is open since October 2021, and there was
already discussion about removing ruby-ferret.

No rdeps exist.

Thanks,
Chris



Bug#1043536: shadow:[INTL:fr] updated French man page translation

2023-08-12 Thread bubub
Package: shadow
Version:4.13
Severity: wishlist
Tags: patch l10n

Dear mainteners,
Hello, please find the updated french translation for shadow attached,
proofread by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind regards,
have a nice day,

bubu

fr.po.xz
Description: application/xz


Bug#1010873: RFP: emailrelay -- SMTP email proxy and relay server

2023-08-12 Thread Sergey Ponomarev
Please take a look at the EmailRelay again
http://emailrelay.sourceforge.net/.
With latest version 2.5 it can act as a full MTA and deliver mail directly.
This makes it a great alternative to Postfix.
But unlike Postfix it supports Windows and is small and easier to configure.
This makes it extremely valuable especially as a good option for
self-hosting.

I created an Ubuntu PPA
https://code.launchpad.net/~stokito/+archive/ubuntu/emailrelay

It builds debs for amd64 and also for arm64 and Raspberry Pi (armhf).
The build works great without any problems.


Bug#1043535: src:tpm2-tss: fails to migrate to testing for too long: unresolved RC issue

2023-08-12 Thread Paul Gevers

Source: tpm2-tss
Version: 3.2.1-3
Severity: serious
Control: close -1 4.0.1-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1040521

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:tpm2-tss has been trying to migrate for 36 
days [2]. Hence, I am filing this bug. The version in unstable fails to 
build on s390x as reported in bug 1040521.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=tpm2-tss



Bug#967530: hoz: depends on deprecated GTK 2

2023-08-12 Thread Bastian Germann

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru hoz-1.65/debian/changelog hoz-1.65/debian/changelog
--- hoz-1.65/debian/changelog   2018-10-17 09:47:43.0 +
+++ hoz-1.65/debian/changelog   2023-08-12 11:17:35.0 +
@@ -1,3 +1,13 @@
+hoz (1.65-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove hoz-gui. Closes: #967530
+  * Remove explicit quilt (patches are part of the source format).
+  * Remove non-existing homepage.
+  * Clean hoz.1.
+
+ -- Bastian Germann   Sat, 12 Aug 2023 11:17:35 +
+
 hoz (1.65-3) unstable; urgency=medium
 
   * Fixed partsize miscalculation. Closes: #499318
diff -Nru hoz-1.65/debian/control hoz-1.65/debian/control
--- hoz-1.65/debian/control 2018-10-17 09:47:43.0 +
+++ hoz-1.65/debian/control 2023-08-12 11:17:35.0 +
@@ -2,9 +2,8 @@
 Section: utils
 Priority: optional
 Maintainer: Miriam Ruiz 
-Build-Depends: debhelper, quilt, gettext, help2man, libgtk2.0-dev
+Build-Depends: debhelper, gettext, help2man
 Standards-Version: 4.2.1.2
-Homepage: http://hoz.sourceforge.net/
 
 Package: hoz
 Architecture: any
@@ -12,12 +11,3 @@
 Description: file splitter that uses the hacha file format
  HOZ is a file splitter, which uses the same file format as the popular
  'Hacha' program.
-
-Package: hoz-gui
-Architecture: any
-Depends: hoz (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
-Description: file splitter that uses the hacha file format
- HOZ is a file splitter, which uses the same file format as the popular
- 'Hacha' program.
- .
- This package includes the GUI interface for the program.
diff -Nru hoz-1.65/debian/ghoz.xpm hoz-1.65/debian/ghoz.xpm
--- hoz-1.65/debian/ghoz.xpm2018-10-17 09:47:31.0 +
+++ hoz-1.65/debian/ghoz.xpm1970-01-01 00:00:00.0 +
@@ -1,39 +0,0 @@
-/* XPM */
-static char *hoz[]={
-"32 32 4 1",
-". c None",
-"# c #00",
-"b c #80",
-"a c #c0c0c0",
-"",
-"..###...",
-"##aaa##.",
-"...#a###aaa###..",
-"..###...#a#.",
-".#a#",
-"..#a#...",
-"...#a#..",
-"...##...#a#.",
-".##aa#..#a#.",
-"...##aa..#a#",
-"..##.#a#.#a#",
-".#aaa##...##.#a#",
-".#aa#...#aa#",
-"#aaa#...#aa#",
-"#aaa#..#aaa#",
-"#aaa#.##",
-"#aaa###.",
-"##..##..",
-".##aa#..#aaa#...",
-"...#aa###bb#aa##",
-"##aaa#..",
-".##a##b.",
-"..###bb.",
-"..bb#bbb",
-"....",
-"b...",
-"...bb.bbb...",
-"..b.",
-".b..",
-"....",
-""};
diff -Nru hoz-1.65/debian/h2m/hoz.1 hoz-1.65/debian/h2m/hoz.1
--- hoz-1.65/debian/h2m/hoz.1   2018-10-17 09:47:43.0 +
+++ hoz-1.65/debian/h2m/hoz.1   1970-01-01 00:00:00.0 +
@@ -1,44 +0,0 @@
-.\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.47.4.
-.TH HOZ "1" "October 2018" "hoz 1.65" "User Commands"
-.SH NAME
-hoz \- file splitter that uses the hacha file format
-.SH SYNOPSIS
-.B hoz [-pvf] [-c size[K|M]] [-o outpath] inputfname
-.TP
-.B ghoz
-.SH DESCRIPTION
-HOZ is a file splitter, which uses the same file format as the popular 'Hacha' 
program.
-.SH OPTIONS
-.TP
-\fB\-c\fR   \fB\-\-cut\fR
-cut (file\->pieces)
-.TP
-\fB\-p\fR   \fB\-\-paste\fR
-paste (pieces\->file)
-.TP
-\fB\-v\fR   \fB\-\-verbose\fR
-verbose output
-.TP
-\fB\-f\fR   \fB\-\-force\fR
-force overwrite of file when pasting
-.TP
-\fB\-o\fR   \fB\-\-outpath\fR
-specify an output directory
-.TP
-\fB\-h\fR   \fB\-\-help\fR
-print this help, then exit
-.TP
-\fB\-\-version\fR
-print hoz program version number, then exit
-.SH USAGE
-There are two basic operations: cut and paste. Cut will 'split' a file in
-pieces. The size of each piece is passed as an option. Each piece will have a
-numeric extension, starting with 0. So for instance if you 'cut' a file called 
'foo.iso',
-the pieces will be named 'foo.iso.0', 'foo.iso.1' and so on.
-
-Paste will 'merge' these pieces and generate and exact copy of the original
-file.
-
-ghoz is the graphical version of hoz, which uses a GTK GUI interface.
-.SH "SEE ALSO"
-You can find more information at http://hoz.sourceforge.net/
diff -Nru hoz-1.65/debian/hoz-gui.links hoz-1.65/debian/hoz-gui.links
--- hoz-1.65/debian/hoz-gui.links   2018-10-17 09:47:31.0 +
+++ hoz-1.65/debian/hoz-gui.links   1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@

Bug#1043534: RM: tuxcmd-modules -- RoQA; orphaned

2023-08-12 Thread Bastian Germann

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

Please remove tuxcmd-modules. It is unmaintained upstream (last release in 
2009) and orphaned.
Please only remove if tuxcmd is also removed.



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

2023-08-12 Thread Carsten Schoenert

Hi again,

Am 12.08.23 um 15:40 schrieb Paul Gevers:


I'm trying to do that, but it's a fight.


another try would be to use the upstream precompiled binaries.


https://download-origin.cdn.mozilla.net/pub/thunderbird/releases/115.1.0/linux-x86_64/


Just extract to somewhere and start the thunderbird binary, it will pick 
up the profile automatically.


If the issue is quite the same I suggest to open a upstream issue in the 
Bugzilla system.



https://bugzilla.mozilla.org/home


--
Regards
Carsten



Bug#1043533: ITP: python-coincidence -- Helper functions for pytest

2023-08-12 Thread Josenilson Ferreira da Silva
Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-coincidence
  Version : 0.6.5
  Upstream Contact: Dominic Davis-Foste 
* URL : https://github.com/python-coincidence/coincidence
* License : MIT/Expat
  Programming Lang: Python
  Description : Helper functions for pytest

 package needed to run the tests of these packages:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020324
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026963
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026975



Bug#1043532: r-bioc-rhdf5: autopkgtest fails on s390x: 64-bit integer attributes are not read correctly

2023-08-12 Thread Paul Gevers

Source: r-bioc-rhdf5
Version: 2.42.0+dfsg-1  
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails on s390x (our 
only big endian architecture). Can you please investigate the situation 
and fix it? I copied some of the output at the bottom of this report. I 
strongly suspect the failure is due to endianess, but I'm not sure if 
it's only a test failure, or if the package won't work on big endian 
systems.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

115s ── Failure ('test_h5writeAttributes.R:96:5'): Adding attribute to 
dataset ──

115s attr_back$int_attr[1] inherits from `'NULL'` not `'character'`.
115s ── Failure ('test_h5writeAttributes.R:97:5'): Adding attribute to 
dataset ──

115s attr_back$numeric_attr[1] inherits from `'NULL'` not `'character'`.
115s ── Failure ('test_h5writeAttributes.R:130:5'): Checking other 
string options when adding attributes ──

115s `attr_back` has length 0, not length 4.
115s ── Failure ('test_h5writeAttributes.R:133:5'): Checking other 
string options when adding attributes ──

115s sort(expected) not identical to sort(names(attr_back)).
115s Types not compatible: character is not NULL
115s ── Failure ('test_h5writeAttributes.R:134:5'): Checking other 
string options when adding attributes ──
115s unname(unlist(attr_back[expected])) not identical to c("blah", 
"blah2", "blah3", "blah4").

115s target is NULL, current is character
115s ── Failure ('test_h5writeAttributes.R:149:5'): Overwrite exisiting 
attribute ───

115s attr_list$char_attr[1] not identical to "new_character".
115s target is NULL, current is character
115s
115s [ FAIL 38 | WARN 0 | SKIP 2 | PASS 974 ]


Bug#1043531: r-bioc-basilisk: autopkgtest fails except on amd64 and arm64

2023-08-12 Thread Paul Gevers

Source: r-bioc-basilisk
Version: 1.12.1+ds-2
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails everywhere 
except on amd64 and arm64. Can you please investigate the situation and 
fix it (or if that's not possible, don't test on the failing 
architectures)? I copied some of the output at the bottom of this 
report. Looking at the script name in the error message, it seems that 
the test fails to locate the right upstream script and picks the amd64 
version.


amd64: 
https://repo.anaconda.com/miniconda/Miniconda3-py38_4.12.0-Linux-x86_64.sh
arm64: 
https://repo.anaconda.com/miniconda/Miniconda3-py38_4.12.0-Linux-aarch64.sh


armel, armhf, i386, ppc64el and s390x download the amd64 version.

More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul



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

2023-08-12 Thread Jonathan Wiltshire
On Sat, Aug 12, 2023 at 10:57:56AM +0200, Otto Kekäläinen wrote:
> Hi!
> 
> > That is the correct interpretation, but you missed the second half:
> >
> > > > You have the wrong version there though.
> >
> > That is a reference to:
> >
> > On Mon, Jul 24, 2023 at 10:09:30AM -0700, Otto Kekäläinen wrote:
> > > On Mon, 24 Jul 2023 at 09:33, Jonathan Wiltshire  wrote:
> > > > We also have a lack of dbgsym packages, probably because of the 
> > > > maintainer
> > > > upload of amd64 and all. I'd quite like to fix the second lintian 
> > > > warning
> > > > at least; if you uploaded again now with the more conventional version 
> > > > of
> > > > 1:10.11.4-1~deb12u1 do you have to go through NEW again or could you 
> > > > make
> > > > it a source-only upload?
> 
> I still don't understand - do you mean the 'version' as in contents of
> the package, or 'version' as in version string 1:10.11.4-1~deb12u1
> should be something else?
> 
> Please advice and I will reupload this weekend.

I'm just looking for a source upload of the agreed changes with a version
string of something conventional like 1:10.11.4-1~deb12u1, targetting
bookworm.

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#1043269: autofs 5.1.8-2+deb12u2 flagged for acceptance

2023-08-12 Thread Jonathan Wiltshire
package release.debian.org
tags 1043269 = 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: autofs
Version: 5.1.8-2+deb12u2

Explanation: fix regression determining reachability on dual-stack hosts



Bug#1042795: mgba 0.10.1+dfsg-1+deb12u1 flagged for acceptance

2023-08-12 Thread Jonathan Wiltshire
package release.debian.org
tags 1042795 = 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: mgba
Version: 0.10.1+dfsg-1+deb12u1

Explanation: fix broken audio in libretro core; fix crash on hardware incapable 
of OpenGL 3.2



Bug#1043530: Please ship uasyncio and mip

2023-08-12 Thread Faidon Liambotis
Source: micropython
Version: 1.19.1+ds-1
Severity: normal

uasyncio is extremely useful in MicroPython programs in my experience,
as it allows for concurrency in environments where there may be
otherwise limited (no threads etc.). It's been supported by MicroPython
for a while, and I see in upstream's git master that it's has been
recently renamed to "asyncio", as it's considered close enough to
CPython.

While the upstream Unix port enables (u)asyncio by default, the Debian
MicroPython builds do not ship with it. I also checked with 1.20.0+ds-1,
as found in salsa.

I believe this is because this is enabled by
  ports/unix/variants/standard/manifest.py
Manifets are disabled in the Debian builds by building with
FROZEN_MANIFEST=.

Removing FROZEN_MANIFEST= from d/rules resulted in the build system
complaining about the omission of micropython-lib. Extracting the
official 1.20 micropython-lib tarball to lib/micropython-lib, however,
made the build work:
   MicroPython v1.20.0+ds-1 on 2023-08-07; linux [GCC 13.2.0] version
   Use Ctrl-D to exit, Ctrl-E for paste mode
   >>> import uasyncio
   >>>

So the solution here is a bit more involved: it requires shipping
micropython-lib, for example leveraging multiple tarball support and
gbp-import-orig's component support.

On that matter, the build above also enabled "mip", the new package
manager and flagship feature of v1.20:
   >>> import mip
   >>>
(There are some mbedTLS DEBUG messages being emitted when fetching from
e.g. GitHub, that I haven't tracked down yet, but that's getting a
little offtopic.)

Given the deviation from the upstream default, and how core these
features are, I'm marking this as "normal", rather than "wishlist". But
up to you :)

Thanks for your work in maintaining MicroPython!

Best,
Faidon



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

2023-08-12 Thread Paul Gevers

Hi,

Moving to bug 1043138.

On 12-08-2023 08:14, Carsten Schoenert wrote:

Am 10.08.23 um 21:57 schrieb Paul Gevers:
There is #1043138 which was about a similar problem, seems there the 
issue could be solved by re-importing the secret key. Alexis (Reply #20) 
could solve his issue too by a re-import.


I'm trying to do that, but it's a fight.

The failure message is rather unspecific: "Sending of the message 
failed."


Open the JS console might bring more clue what probably might be go wrong.

Crtl + Shift + j


For the record:

mimeEncrypt.js: caught exception: Error
Message: 'failure in finishCryptoEncapsulation, exitCode: -1'
File:chrome://openpgp/content/modules/mimeEncrypt.jsm
Line:537
Stack: 
finishCryptoEncapsulation@chrome://openpgp/content/modules/mimeEncrypt.jsm:537:15

createMessageFile@resource:///modules/MimeMessage.jsm:90:27


Error: failure in finishCryptoEncapsulation, exitCode: -1 
mimeEncrypt.jsm:537:15
mailnews.send: NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript 
Error: "failure in finishCryptoEncapsulation, exitCode: -1" {file: 
"chrome://openpgp/content/modules/mimeEncrypt.jsm" line: 
537}]'[JavaScript Error: "failure in finishCryptoEncapsulation, 
exitCode: -1" {file: "chrome://openpgp/content/modules/mimeEncrypt.jsm" 
line: 537}]' when calling method: 
[nsIMsgComposeSecure::finishCryptoEncapsulation]

createMessageFile resource:///modules/MimeMessage.jsm:90
MessageSend.jsm:137:32
mailnews.send: Sending failed; , exitCode=2153185313, originalMsgURI= 
MessageSend.jsm:362:32

Error: rnp_op_sign_add_signature failed RNP.jsm:3535:19
mailnews.smtp:
error { target: TCPSocket, isTrusted: true, name: "NetworkTimeoutError", 
message: "Network", errorCode: 2152398862, srcElement: TCPSocket, 
currentTarget: TCPSocket, eventPhase: 2, bubbles: false, cancelable: 
false, … }

SmtpClient.jsm:434:17

Paul


Bug#1043528: RM: tuxcmd -- RoQA; depends on gtk2; orphaned; alternative exists

2023-08-12 Thread Salvatore Bonaccorso
Hi,

On Sat, Aug 12, 2023 at 03:19:05PM +0200, Bastian Germann wrote:
> Package: ftp.debian.org
> Severity: normal
> User: ftp.debian@packages.debian.org
> Usertags: remove
> Control: affects -1 + src:tuxcmd
> 
> Please remove tuxcmd. It is unmaintained upstream (last release in 2009) and
> orphaned, and depends on gtk2. With doublecmd, there is a good replacement
> that is still maintained.

Feeling nostalgic about it, this was almost my ever first package
which entered Debian :)

Agree on the removal, note though that if you remove src:tuxcmd then
please do as well remove the suggested tuxcmd-modules one, the later
does not make sense to keep in the archive either if tuxcmd
disappears.

Regards,
Salvatore



Bug#1043529: src:giac: fails to migrate to testing for too long: FTBFS

2023-08-12 Thread Paul Gevers

Source: giac
Version: 1.9.0.35+dfsg2-1.1
Severity: serious
Control: close -1 1.9.0.57+dfsg2-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1040889

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:giac has been trying to migrate for 32 
days [2]. Hence, I am filing this bug. The version in unstable fails to 
build from source as reported in 1040889.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=giac



Bug#1043528: RM: tuxcmd -- RoQA; depends on gtk2; orphaned; alternative exists

2023-08-12 Thread Bastian Germann

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

Please remove tuxcmd. It is unmaintained upstream (last release in 2009) 
and orphaned, and depends on gtk2. With doublecmd, there is a good 
replacement that is still maintained.




Bug#967356: fyre: depends on deprecated GTK 2

2023-08-12 Thread Bastian Germann

Hi Stephen,

Is it worth to keep such an ancient program as fyre in Debian?
It might be time to drop it.

Thanks for your consideration,
Bastian



Bug#1043527: valgrind: a lot of files in /usr/libexec/ are .xml files that don't belong there

2023-08-12 Thread Alexandre Detiste
Package: valgrind
Version: 1:3.19.0-1
Severity: minor

libexec is meant for binary programs,

the way Valgrind is packaged makes it a tiny
bit more complicated to audit the system,
thus marking this "minor".

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html

/usr/libexec/valgrind/s390-vx.xml
/usr/libexec/valgrind/s390x-core64-valgrind-s1.xml
/usr/libexec/valgrind/s390x-core64-valgrind-s2.xml
/usr/libexec/valgrind/s390x-core64.xml
/usr/libexec/valgrind/s390x-generic-valgrind.xml
/usr/libexec/valgrind/s390x-generic.xml
/usr/libexec/valgrind/s390x-linux64-valgrind-s1.xml
/usr/libexec/valgrind/s390x-linux64-valgrind-s2.xml
/usr/libexec/valgrind/s390x-linux64.xml
/usr/libexec/valgrind/s390x-vx-linux-valgrind.xml
/usr/libexec/valgrind/s390x-vx-linux.xml
$ find /usr/libexec/ -type f ! -executable | sort

Greetings,


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

Kernel: Linux 6.4.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages valgrind depends on:
ii  libc6  2.37-7
ii  libc6-dbg  2.37-7

Versions of packages valgrind recommends:
ii  gdb   13.2-1
ii  valgrind-dbg  1:3.19.0-1

Versions of packages valgrind suggests:
pn  alleyoop  
pn  kcachegrind   
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information



Bug#967706: pommed: depends on deprecated GTK 2

2023-08-12 Thread Bastian Germann
Please just drop gpomme. The rest of the packages seem to be working 
without it.




Bug#1043317: duck: Please drop "parked domain" test

2023-08-12 Thread Baptiste Beauplat
Hi Gregor,

On Wed, 2023-08-09 at 03:21 +0200, gregor herrmann wrote:
> I like duck and run it after each package build.
> Unfortunately typically I get output from the wild-guess check for
> some strings on websites where duck tells me that the upstream
> homepage or the Debian BTS or a well-known license is a "parked
> domain of for sale", and this test is almost always a false positive.
> 
> Current example, package rex:
> 
> I: debian/copyright:62: URL:
> https://www.apache.org/licenses/LICENSE-2.0: INFORMATION
> (Certainty:wild-guess)
>    Curl:0 HTTP:200 No error 
>    Website seems to be outdated, is probably a parked domain or for
> sale. Please update your links!
>    Matching regular expression(s):
>     m/\breplaced with\b/i
> 
> I: debian/control: Homepage: https://www.rexify.org/: INFORMATION
> (Certainty:wild-guess)
>    Curl:0 HTTP:200 No error 
>    Website seems to be outdated, is probably a parked domain or for
> sale. Please update your links!
>    Matching regular expression(s):
>     m/\breplace .* with\b/i
> 
> I: debian/upstream/metadata:URL: https://github.com/RexOps/Rex.git:
> INFORMATION (Certainty:wild-guess)
>    Curl:0 HTTP:200 No error 
>    Website seems to be outdated, is probably a parked domain or for
> sale. Please update your links!
>    Matching regular expression(s):
>     m/\breplace .* with\b/i
> 
> I: debian/upstream/metadata:URL: https://github.com/RexOps/Rex:
> INFORMATION (Certainty:wild-guess)
>    Curl:0 HTTP:200 No error 
>    Website seems to be outdated, is probably a parked domain or for
> sale. Please update your links!
>    Matching regular expression(s):
>     m/\breplace .* with\b/i
> 
> 
> Checking for "deprecated" (on upstream websites which document
> functions) or "replaced (by|with)" doesn't make any sense IMO …
> Please just remove tese tests …

There are a couple of different points I'd like to address in order to
fix this issue.

First, I agree with you, "replaced (by|with)" and "deprecated" are too
generic not to trigger false positives. I'll be removing them from the
list.

Secondly, even if, as stated by the check certainty, the suggestion is
at most a wild-guess, I would like to keep the test as it can still be
useful to catch deprecated projets or links that moved on to another
page. However, I want to have a way for users to filter the checks
based on certainty. I'll be adding an option for that both in the cli
arguments and the configuration file. Although, I'll keep the default
to show all checks.

Finally, the checks for obsoletes sites is currently at a certainty of
wild-guess. I'll be bumping that to possible as, to the contrary of the
parked test, its a list of well known deprecated sites, and virtually
has no chance of false positive.

Best,
-- 
Baptiste Beauplat



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


Bug#1043526: rust-h2: Please update to v0.3.17

2023-08-12 Thread Jonas Smedegaard
Source: rust-h2
Version: 0.3.13-2
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.3.17.

Raising severity and tagging as security-related, as the delta contains
several important-looking bugfixes including a fix to CVE-2023-26964.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTXghYACgkQLHwxRsGg
ASH48xAAnsa4WH4zQP4kJXOJPpGx8vCWPPdeiG+/AMxxYrUlQ3Am2WT3FJMPqhgt
qngTi3H64SWTLDp1l5LJPaMoGTnbFisNvwqOQgZk7HP4LWHnJOtDAEp0NG+d3Qkw
xhZmyVF0lCchZJyVCon2slA53BojChh1gSVmA0UCuBm41/MH2w9JYzPe7FT3bDPb
1AxsNShuddg4Xsl1e3J3/uIFkfdhejlpJZXvHsvSNA3OpaKjsxYb7ybDnsMtyAP1
2bk7wvshMiCG9+ByLckiIXWlfD8mhoZO9isQn02cKOiPgUxQwW2lribM8tUeKQE8
lL/e4RI034C07sGNYiLWiiT9SnduKHJ/bDG7iHTHW6BO47zP2lHGv1wNk9sl/ys2
907Jase3Aj7m/Vo1IsKGe5pXyHErY1kQdcG8h9xrNRimB5ueMkRCIbo/gpVJIrTH
9FSzjRwEJi52rKUBXipRjqr5XINj3Ui1olIY/sv9fBrLQOWw86xjYBNL/xlIex0+
+3EQtyBdsA1hkBidomCDwFwSg066ExFtCm78Em9p9Efk/aVNuk0UEUBbGZi3uRfe
CaoRQIo524EtERSJxhgaacPoQDDA4NePnjs6M+8Q1ijeOLn6FONINmarvqHtdvMg
78/pnAEskPJw3VOTj20Ur18phdtbaBvP1Alje3Q3rzotY+90xBk=
=p1Fs
-END PGP SIGNATURE-



Bug#967259: depends on gtk2

2023-08-12 Thread Bastian Germann

Peter, I see you are packaging the new version 3.
This is not ported to gtk3 either.
I suggest to make the package a transitional package to grimripper.



Bug#1041693: borgbackup: missing fuse3 dependency

2023-08-12 Thread root
Package: borgbackup
Version: 1.2.4-2
Followup-For: Bug #1041693
Control: severity -1 important
Control: reopen -1

Dear Maintainer,

borgbackup is missing a Recommends for fuse3 now. When I install
borgbackup on a fresh system, I get "fuse: device not found, try 'modprobe 
fuse' first"

Severity set to important because it breaks the functionality of the
package on some systems but not all systems, depending on whether fuse3
is already installed or not.

Please add the fuse3 recommends.

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages borgbackup depends on:
ii  libacl12.3.1-3
ii  libc6  2.37-6
ii  liblz4-1   1.9.4-1
ii  libssl33.0.10-1
ii  libxxhash0 0.8.1-1
ii  libzstd1   1.5.5+dfsg2-1
ii  python33.11.4-5+b1
ii  python3-msgpack1.0.3-2+b1
ii  python3-packaging  23.1-1
ii  python3-pkg-resources  68.0.0-2

Versions of packages borgbackup recommends:
ii  python3-pyfuse3  3.2.1-2+b2

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- no debconf information



Bug#1043525: RM: sweep -- RoQA; depends on gtk2; orphaned

2023-08-12 Thread Bastian Germann

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

Please remove sweep. It is unmaintained upstream (last release in 2008) 
and orphaned, and depends on gtk2.




Bug#1043524: RM: spacezero -- RoQA; depends on gtk2; unmaintained; low popcon

2023-08-12 Thread Bastian Germann

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

Please remove spacezero. It is unmaintained in Debian (several not 
imported upstream releases, crash bug reports) and depends on gtk2.

It has a low popcon and the Maintainer/Uploaders all appear to be absent.



Bug#967679: packeth: depends on deprecated GTK 2

2023-08-12 Thread Bastian Germann
Please consider updating to the latest version 2.1 and only building the 
cli tool.




Bug#1043516: rust-hyper: Please update to v0.14.26

2023-08-12 Thread Jonas Smedegaard
Control: severity -1 important

Quoting Jonas Smedegaard (2023-08-12 13:34:06)
> Please update to (at least) newer upstream release v0.14.26.

Raising severity, as the delta contains several important-looking
bugfixes.

 - Jonas

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

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

signature.asc
Description: signature


Bug#1039455: please remove obsolete dependency on python3-six

2023-08-12 Thread Alexandre Detiste
This was confusing because the upstream repository was in a ... confusing state.

I got it sorted out:

https://github.com/OSGeo/grass/commit/e2d4fbabe5c04b38387333c13cb219975576ef71

It was fun.


This will be in the next release.

Le sam. 12 août 2023 à 14:09, Debian Bug Tracking System
 a écrit :
> Processing commands for cont...@bugs.debian.org:
> > unarchive 1039455
> Bug #1039455 {Done: Sebastiaan Couwenberg } [grass-core] 
> grass-core: please remove obsolete dependency on python3-six



Bug#1043523: RM: bitmeter -- RoQA; unmaintained; depends on gtk2

2023-08-12 Thread Bastian Germann

Source: bitmeter
Severity: serious
Version: 1.2-4
X-Debbugs-Cc: d...@jones.dk

bitmeter does not seem to be used a lot anymore. I intend to file a RM 
bug. If you have any reasons to keep it in Debian please voice them 
here. To get people's attention, I am filing as a serious bug and will 
reassign to the FTP team when the package is autoremoved from testing.




Bug#1043374: bindgen

2023-08-12 Thread Matthias Geiger

Hi Andreas,

I will update bindgen to the latest version in debian as the newer cargo 
needs this.


It's affecting ~25 crates, so far they all built fine with just a patch 
bumping the bindgen dependency to 0.66.


You can follow the progress here: 
https://salsa.debian.org/rust-team/debcargo-conf/-/issues/50



best,

Matthias



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#967508: gvidm: depends on deprecated GTK 2

2023-08-12 Thread Bastian Germann

Hi Matteo,

Please consider removing the entire package. Upstream does not provide 
any changes since years and it is seldomly used.


Thanks,
Bastian



Bug#1043522: blhc: Please allow -std=gnu++20 inside bin/blhc:L1114 regex exception

2023-08-12 Thread Marco Mattiolo

Package: blhc
X-Debbugs-Cc: marco.matti...@hotmail.it
Severity: normal

Dear Maintainer,

while building an app (Calindori, calendar for Plasma mobile) to be 
included in Debian, I found what I think is an issue with blhc: in [1] 
it is found


|/usr/lib/ccache/c++ -std=gnu++20 -dM -E -c 
/usr/share/cmake-3.27/Modules/CMakeCXXCompilerABI.cpp|


|that is supposed to fit with regex in bin/bhlc:L1114|

|next if $line =~ m{^\s*/usr/(bin|lib)/(ccache/)?c\+\+ -dM -E -c 
/usr/share/cmake-\S+/Modules/CMakeCXXCompilerABI\.cpp};|


|but the additional "||-std=gnu++20" is found, which causes the 
exception regex not to be triggered: could you please change the 
mentioned line in bin/blhc to allow for optional arguments between 
"/usr/lib/ccache/c++" and "-dM"?|


|As and additional info, blhc output with reported errors is found at [2].|

|Thank you for maintaining blhc, kind regards|

|Marco|

[1] https://salsa.debian.org/tiol/calindori/-/jobs/4543371#L2180

[2] https://salsa.debian.org/tiol/calindori/-/jobs/4543380



Bug#967299: cwiid: depends on deprecated GTK 2

2023-08-12 Thread Bastian Germann

Please drop the binary package wmgui to get rid of GTK 2.
It is by far not as often used as the library.



Bug#1038105: upgrade-reports: resume from suspend/hibernate broken by upgrade from bullseye to bookworm

2023-08-12 Thread Madcollector
Could this be related to 
https://bugzilla.kernel.org/show_bug.cgi?id=200039 ?


Add a similar problem after upgrading to bookworm. I fixed it by 
disabling bluetooth.




  1   2   >