Bug#1013163: solvespace: autopkgtest regression on s390x: The model does not contain any surfaces to export.

[Paul Gevers]

Hi Ryan,

It seems you were addressing me in your reply below. Please be aware 
that the BTS doesn't forward messages to bugs to the submitter unless 
they are subscribed explicitly. If you want reply from the submitter, 
always include them in CC.


On Thu, 30 Jun 2022 15:23:32 -0500 Ryan Pavlik  
wrote:

I'm having trouble reproducing this locally in a Docker container
using qemu on sid: it seems to work here. Similarly a Bookworm docker
in qemu into which I installed the sid package also seems to test OK.
(Ran the full autopkgtest suite in it, and while it did appear to fail
an assertion elsewhere in the tests, it didn't break the test suite?)
I'm not sure what would cause this failure.

Can these tests be re-run?


That happens automatically once a day. The history shows more than 20 
retries already.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016398: src:solvespace: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: solvespace
Version: 3.0.rc2+repack1-3
Severity: serious
Control: close -1 3.1+ds1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1013163

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:solvespace has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package has an 
autopkgtest regression that I reported earlier in bug 1013163.


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 bookworm, 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/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=solvespace



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016397: src:gradle: fails to migrate to testing for too long: unresolved RC bugs

[Paul Gevers]

Source: gradle
Version: 4.4.1-13
Severity: serious
Control: close -1 4.4.1-14
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1012214 1013545

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:gradle has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package has two unresolved 
RC bugs at this  moment.


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 bookworm, 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/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=gradle



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015169: RFS: mir-eval/0.7-1 [ITP] -- Common metrics for common audio/music processing tasks

[Nilson Silva]

Control: tags -1 - moreinfo

Hello!

package completed.

https://salsa.debian.org/debian/mir-eval
[https://salsa.debian.org/assets/twitter_card-570ddb06edf56a2312253c5872489847a0f385112ddbcd71ccfa1570febab5d2.jpg]
Debian / mir-eval · GitLab 
Forked from Josenilson Ferreira da SIlva / mir-evalJosenilson Ferreira da SIlva 
/ mir-eval
salsa.debian.org





De: Nilson Silva 
Enviado: sexta-feira, 22 de julho de 2022 07:26
Para: Bastian Germann ; 1015...@bugs.debian.org 
<1015...@bugs.debian.org>
Assunto: RE: Bug#1015169: RFS: mir-eval/0.7-1 [ITP] -- Common metrics for 
common audio/music processing tasks

Control: tags -1 - moreinfo


Hi! Bastian!


put this parameter:
dh_auto_test || real

with it the tests are executed and the ones with errors are skipped.

https://salsa.debian.org/debian/mir-eval/


Nilson F. Silva



De: Bastian Germann 
Enviado: quinta-feira, 21 de julho de 2022 23:13
Para: Nilson Silva ; 1015...@bugs.debian.org 
<1015...@bugs.debian.org>
Assunto: Re: Bug#1015169: RFS: mir-eval/0.7-1 [ITP] -- Common metrics for 
common audio/music processing tasks

Control: tags -1 moreinfo

Disabling all of the tests is a bit of an overkill. Please only disable the 
ones that need those deprecated classes.
It should be enough to disable test_display and mpl_ic.

Bug#1016265: libkiwix: FTBFS: version.h:29:2: error: #warning The C++ ABI version of compiler you are using does not exactly match [-Werror=cpp]

[Kunal Mehta]

forcemerge 1012981 1016265
thanks


On 7/29/22 12:21, Lucas Nussbaum wrote:

/usr/include/xapian/version.h:29:2: error: #warning The C++ ABI version of 
compiler you are using does not exactly match [-Werror=cpp]
29 | #warning The C++ ABI version of compiler you are using does not 
exactly match
   |  ^~~


This has been fixed in experimental after being originally reported as 
#1012981.


Thanks,
-- Kunal

Bug#1016396: squeekboard: fails to build on ppc64el

[Jeremy Bicha]

Source: squeekboard
Version: 1.18.0-1
Severity: serious
Tags: ftbfs
X-Debbugs-CC: aferra...@debian.org

squeekboard no longer builds from source on ppc64el.

Thank you,
Jeremy Bicha

Bug#1016395: linux-image-5.18.0-2-amd64: kernel 5.18: rtw_8821ce wireless fails to suspend/wake from suspend

[Linas Vepstas]

Package: src:linux
Version: 5.18.5-1
Severity: important
X-Debbugs-Cc: linasveps...@gmail.com

Dear Maintainer,

The rtw88_8821ce driver for the 
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac 
PCIe Wireless Network Adapter
on a laptop I bought today (but mfg'd in November 2021 ?) fails to
suspend/wake from suspend.  A long series of kernel OOPS's are included
below.  This is reproducible. (Done it three times)

Device works fine before suspend.  Only a reboot recovers this;
rmmod and modprobe are not enough to get it working again.

Note this device uses non-free firmware.

Scattered reports on the net suggest that maybe earlier kernel versions
do not have this problem?

--linas


-- Package-specific info:
** Version:
Linux version 5.18.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.3.0-3) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.50.20220615) #1 SMP 
PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.18.0-2-amd64 
root=UUID=987a8efa-6ffc-4bf6-8d03-f43dcb6e4151 ro quiet

** Not tainted

** Kernel log:

This is a laptop, putting into suspend by closing lid.
The suspend is at 33048.573534 --- note some suspicious error msgs before
then.

[3.912319] rtw_8821ce :01:00.0: enabling device ( -> 0003)
[3.918964] rtw_8821ce :01:00.0: firmware: direct-loading firmware 
rtw88/rtw8821c_fw.bin
[3.918979] rtw_8821ce :01:00.0: Firmware version 24.8.0, H2C version 12
[4.368100] rtw_8821ce :01:00.0 wlp1s0: renamed from wlan0
[   12.151395] rtw_8821ce :01:00.0: failed to get tx report from firmware
[  514.791809] rtw_8821ce :01:00.0: firmware failed to leave lps state
...

[21213.519011] rtw_8821ce :01:00.0: firmware failed to leave lps state
[21793.408457] perf: interrupt took too long (6188 > 6162), lowering 
kernel.perf_event_max_sample_rate to 32250
[26749.458031] rtw_8821ce :01:00.0: failed to send h2c command
[27127.576483] rtw_8821ce :01:00.0: firmware failed to leave lps state
[28034.603458] rtw_8821ce :01:00.0: firmware failed to leave lps state
[28073.612147] rtw_8821ce :01:00.0: firmware failed to leave lps state
[29830.598585] rtw_8821ce :01:00.0: firmware failed to leave lps state
[31893.497061] rtw_8821ce :01:00.0: firmware failed to leave lps state
[33048.573534] wlp1s0: deauthenticating from 90:8d:78:5a:e1:84 by local choice 
(Reason: 3=DEAUTH_LEAVING)
[33050.414628] PM: suspend entry (deep)
[33050.420528] Filesystems sync: 0.005 seconds
[33050.421388] (NULL device *): firmware: direct-loading firmware regulatory.db
[33050.421394] (NULL device *): firmware: direct-loading firmware 
regulatory.db.p7s
[33050.421801] (NULL device *): firmware: direct-loading firmware 
rtl_bt/rtl8821c_config.bin
[33050.421805] (NULL device *): firmware: direct-loading firmware 
rtl_bt/rtl8821c_fw.bin
[33050.421871] (NULL device *): firmware: direct-loading firmware 
i915/glk_dmc_ver1_04.bin
[33050.421966] Freezing user space processes ... (elapsed 0.005 seconds) done.
[33050.427036] OOM killer disabled.
[33050.427038] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[33050.428406] printk: Suspending console(s) (use no_console_suspend to debug)
[33050.588987] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[33050.596238] sd 0:0:0:0: [sda] Stopping disk
[33050.957882] ACPI: EC: interrupt blocked
[33050.997205] ACPI: PM: Preparing to enter system sleep state S3
[33050.998189] ACPI: EC: event blocked
[33050.998191] ACPI: EC: EC stopped
[33050.998191] ACPI: PM: Saving platform NVS memory
[33050.998219] Disabling non-boot CPUs ...
[33051.57] smpboot: CPU 1 is now offline
[33051.003448] smpboot: CPU 2 is now offline
[33051.006212] smpboot: CPU 3 is now offline
[33051.009018] unchecked MSR access error: WRMSR to 0x122 (tried to write 
0x8dbc0244) at rIP: 0xa9c70984 (native_write_msr+0x4/0x20)
[33051.009039] Call Trace:
[33051.009044]  
[33051.009046]  restore_processor_state+0x279/0x2c0
[33051.009060]  x86_acpi_suspend_lowlevel+0x11c/0x160
[33051.009067]  acpi_suspend_enter+0x48/0x1e0
[33051.009072]  ? _raw_spin_lock_irqsave+0x24/0x50
[33051.009079]  suspend_devices_and_enter+0x6cf/0x7c0
[33051.009087]  pm_suspend.cold+0x2fb/0x342
[33051.009093]  state_store+0x71/0xd0
[33051.009098]  kernfs_fop_write_iter+0x119/0x1b0
[33051.009106]  new_sync_write+0x106/0x190
[33051.009115]  vfs_write+0x209/0x290
[33051.009118]  ksys_write+0x5f/0xe0
[33051.009122]  do_syscall_64+0x38/0xc0
[33051.009127]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[33051.009132] RIP: 0033:0x7f5dea911453
[33051.009139] Code: 8b 15 01 3a 0e 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb 
b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 
f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
[33051.009143] RSP: 002b:7ffd435b9758 EFLAGS: 0246 ORIG_RAX: 
0001
[33051.009147] RAX: ffda RBX: 0004 RCX: 

Bug#1016394: column_family.cc:1494: rocksdb::ColumnFamilySet::~ColumnFamilySet(): Assertion `last_ref' failed.

[Linas Vepstas]

Package: librocksdb-dev
Version: 7.2.2-5
Severity: normal
X-Debbugs-Cc: linasveps...@gmail.com

Dear Maintainer,

Software that I maintain is generating the error message
```
./db/column_family.cc:1494: rocksdb::ColumnFamilySet::~ColumnFamilySet(): 
Assertion `last_ref' failed.
```
when closing a rocks DB (by running the C++ destructor for the open
RockDB handle).  Some notes:

1) My system works great on Debian stable and multiple Ubuntu releases.
   (They're Rocks version 6 I think...)

2) I don't use ColumnFamilies. I don't use anything fancy in Rocks, just
   plain-old simple stuff.

3) Searching the net, it seems like lots of major users (ceph, mariadb)
   hit this bug in 2019. There's a claim that it was a Rocks bug, and
   it seems it was fixed in 2019, but I have not found the patch.

   There seem to have been no reports of this in 2021 or 2022. 

I'm certain this is an issue with RocksDB, and not the way that I am
using it.

I cannot think of any additional details that I can provide that would
be relevant. My package that si affected by this is
https://github.com/opencog/atomspace-rocks -- two unit tests fail,
hitting the above bug. The bug reproduces reliably.

I think the bug is benign, in that it only happens when shutting down, 
and I assume there is no data corruption as the result of it, but ...
I dunno.

-- linas


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

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

Versions of packages librocksdb-dev depends on:
ii  libbz2-dev 1.0.8-5
ii  libgflags-dev  2.2.2-2
ii  liblz4-dev 1.9.3-2
ii  librocksdb7.2  7.2.2-5
ii  libsnappy-dev  1.1.9-2
ii  libzstd-dev1.5.2+dfsg-1
ii  zlib1g-dev 1:1.2.11.dfsg-4

librocksdb-dev recommends no packages.

librocksdb-dev suggests no packages.

-- no debconf information

Bug#1016393: transition: libkiwix

[Kunal Mehta]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lego...@debian.org

Hi,

I would like to upgrade libkiwix from v10 to v11. The two reverse
dependencies are kiwix and kiwix-tools. All three packages look
good in experimental (still waiting on mips builds, but usually that's
not a problem).

Ben file:

title = "libkiwix";
is_affected = .depends ~ "libkiwix10" | .depends ~ "libkiwix11";
is_good = .depends ~ "libkiwix11";
is_bad = .depends ~ "libkiwix10";

Thanks,
-- Kunal

Bug#1013035: sgt-puzzles: ftbfs with GCC-12

[Ben Hutchings]

On Fri, 2022-07-29 at 10:04 +0100, Simon Tatham wrote:
> Ben Hutchings  wrote:
> > I should patch out the use of -Werror in this package though.
> 
> FWIW, I've already done this upstream. Since commit 79a5378 I've
> completely reworked the build system (it's now a unified cmake setup
> rather than my own horrible mkfiles.pl cruft feeding into autotools),
> and removed the default -Werror. And a test build with gcc 12 worked
> fine for me just now with the current upstream code.

Thanks for the reminder to update, and I appreciate the move to CMake.
I've now uploaded version 20220613.387d323.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#575848: RM: dh-kpatches -- RoQA; unmaintained

[Chris Hofstaedtler]

Control: tags -1 + moreinfo

* Bastian Germann :
> dh-kpatches was not available in several releases and FTBFS.
> I think we can get rid of it.

This needs to be taken care of, one way or another:

Checking reverse dependencies...
# Broken Build-Depends:
blcr: dh-kpatches

Dependency problem found.

C.

Bug#1016392: ukui-wallpapers: Incorrect upstream monitoring

[Boyuan Yang]

Source: ukui-wallpapers
Version: 20.04.3-1.1
Severity: minor
Tags: sid bookworm

Dear Debian ukui-wallpapers package maintainer,

Currently your debian/watch script cannot correctly monitor new upstream
release. According to https://github.com/ukui/ukui-wallpapers/tags , the
latest release should be 20.04.4. Please consider fixing it. Thanks!

Best,
Boyuan Yang


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

Bug#1016363: More info about the fvwm deadlock with libx11-6 1.8.1

[Max Bell]

Assuming this issue effects only one app is defective. Fix the broken
compatibly with legacy code as this solves it for all programs. And
does not require rewriting an unknown number of apps, that probably
don't have maintainers to fix things, to keep working vs. being
rendered unusable.

On 7/30/22, Jed Davis  wrote:
> FVWM's problem here appears to be that it calls XCheckIfEvent with a
> callback that ends up trying to call XFlush; XCheckIfEvent holds the display
> lock while calling the callback and XFlush also locks the display, causing a
> self-deadlock.  I provoked this by iconifying a window with a key bind, and
> in this case it seems to have something to do with the resulting expose
> events (see stack below).  This reentrancy may not be ideal behavior on
> FVWM's part, but this is code which has (seemingly) worked for a long time.
>
> I also came up with a different workaround: instead of rebuilding libx11, I
> rebuilt FVWM with the following definition added:
>
> Status XInitThreads(void)
> {
> return 0;
> }
>
> The executable precedes its libraries in the symbol search path, so this
> turns off X11 thread safety entirely, but only for fvwm; it doesn't appear
> to use threading, either directly or indirectly, and I'm assuming that
> situation isn't likely to change in the immediate future.  This isn't a
> great solution, but it works for me for now.
>
> If it helps, here's the interesting part of the stack trace from the
> deadlock:
>
> #3  0x7f01a975a968 in _XLockDisplay (dpy=0x55ca735f4090) at
> ../../src/locking.c:466
> #4  0x7f01a974e5c2 in XFlush (dpy=0x55ca735f4090) at
> ../../src/Flush.c:38
> #5  0x55ca7248be1b in dispatch_event (e=0x55ca736ec2f8) at
> events.c:4105
> #6  0x55ca7248c0cc in _pred_weed_handle_expose (display=,
> event=, arg=) at events.c:266
> #7  0x55ca724ff3b9 in _fev_pred_weed_if (display=,
> event=0x55ca736ec2f8, arg=0x7ffebc6870a0 "\260\300Hr\312U") at FEvent.c:176
> #8  0x55ca724ff43f in _fev_pred_check_peek (display=,
> event=0x55ca736ec2f8, arg=0x7ffebc686fb0 "p\363Or\312U") at FEvent.c:144
> #9  0x7f01a97489aa in XCheckIfEvent (dpy=0x55ca735f4090,
> event=event@entry=0x7ffebc686ef0, predicate=predicate@entry=0x55ca724ff420
> <_fev_pred_check_peek>, arg=arg@entry=0x7ffebc686fb0 "p\363Or\312U") at
> ../../src/ChkIfEv.c:59
> #10 0x55ca724ffdc0 in FCheckPeekIfEvent (display=,
> event_return=event_return@entry=0x7ffebc6870e0,
> predicate=predicate@entry=0x55ca724ff370 <_fev_pred_weed_if>,
> arg=arg@entry=0x7ffebc6870a0 "\260\300Hr\312U") at FEvent.c:590
> #11 0x55ca724fff17 in FWeedIfEvents (display=,
> weed_predicate=weed_predicate@entry=0x55ca7248c0b0
> <_pred_weed_handle_expose>, arg=arg@entry=0x0) at FEvent.c:527
> #12 0x55ca7248cfba in handle_all_expose () at events.c:4545
> #13 0x55ca724be911 in __raise_or_lower_window (t=t@entry=0x55ca7361c250,
> mode=mode@entry=SM_RAISE, allow_recursion=allow_recursion@entry=1,
> is_new_window=is_new_window@entry=0,
> is_client_request=is_client_request@entry=0) at stack.c:1141
>
> --Jed
>
>

Bug#1008342: pngnq: diff for NMU version 1.1+ds-1.1

[Boyuan Yang]

Control: tags 1008342 + patch
Control: tags 1008342 + pending

Dear maintainer,

I've prepared an NMU for pngnq (versioned as 1.1+ds-1.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru pngnq-1.1+ds/debian/changelog pngnq-1.1+ds/debian/changelog
--- pngnq-1.1+ds/debian/changelog   2022-03-08 01:50:27.0 -0500
+++ pngnq-1.1+ds/debian/changelog   2022-07-30 20:17:57.0 -0400
@@ -1,3 +1,12 @@
+pngnq (1.1+ds-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Add missing build-dep pkg-config. (Closes: #1008342)
+  * debian/patches/0005-configure.ac-Fix-grammar-error.patch: Add patch
+to fix grammar error in configure.ac.
+
+ -- Boyuan Yang   Sat, 30 Jul 2022 20:17:57 -0400
+
 pngnq (1.1+ds-1) unstable; urgency=medium
 
   [ Boyuan Yang ]
diff -Nru pngnq-1.1+ds/debian/control pngnq-1.1+ds/debian/control
--- pngnq-1.1+ds/debian/control 2022-03-08 01:50:27.0 -0500
+++ pngnq-1.1+ds/debian/control 2022-07-30 20:16:04.0 -0400
@@ -6,6 +6,7 @@
 Build-Depends:
  debhelper-compat (= 13),
  libpng-dev,
+ pkg-config,
  zlib1g-dev,
 Standards-Version: 4.6.0
 Vcs-Git: https://salsa.debian.org/debian-phototools-team/pngnq.git
diff -Nru pngnq-1.1+ds/debian/patches/0005-configure.ac-Fix-grammar-
error.patch pngnq-1.1+ds/debian/patches/0005-configure.ac-Fix-grammar-
error.patch
--- pngnq-1.1+ds/debian/patches/0005-configure.ac-Fix-grammar-
error.patch 1969-12-31 19:00:00.0 -0500
+++ pngnq-1.1+ds/debian/patches/0005-configure.ac-Fix-grammar-
error.patch 2022-07-30 20:17:57.0 -0400
@@ -0,0 +1,21 @@
+From: Boyuan Yang 
+Date: Sat, 30 Jul 2022 20:20:35 -0400
+Subject: configure.ac: Fix grammar error
+
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index a70a73c..358bbe5 100644
+--- a/configure.ac
 b/configure.ac
+@@ -1,7 +1,7 @@
+ # Autoconf for pngnq
+ 
+ AC_INIT([pngnq],[1.1], [stuart.co...@gmail.com])
+-AM_INIT_AUTOMAKE[-Wall -Werror]
++AM_INIT_AUTOMAKE([-Wall -Werror])
+ AC_COPYRIGHT([Copyright 2008-2011, Stuart Coyle])
+ 
+ # check for progs
diff -Nru pngnq-1.1+ds/debian/patches/series pngnq-
1.1+ds/debian/patches/series
--- pngnq-1.1+ds/debian/patches/series  2022-03-08 01:50:27.0 -0500
+++ pngnq-1.1+ds/debian/patches/series  2022-07-30 20:17:57.0 -0400
@@ -2,3 +2,4 @@
 pngnq-1.1.patch
 pngnq.1.patch
 freegetopt_removed.patch
+0005-configure.ac-Fix-grammar-error.patch


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

Bug#1015263: libidn2-0: Depends sgml-base

[Chris Hofstaedtler]

Control: reassign -1 debhelper
Control: found -1 13.7
Control: affects -1 libidn2-0

Hi Niels,

* Simon Josefsson :
> Thorsten Glaser  writes:
> 
> > A new dependency on sgml-base was introduced to the shared library
> > package, and it’s not documented in the changelog. This raises red
> > flags.
> 
> Hi.  Thanks for the report.  Indeed, this looks strange, and there is no
> modification of the libidn2/debian/ files that would explain this.  It
> seems sgml-base is added via the 'Depends: ${misc:Depends},
> ${shlibs:Depends}' and/or 'Pre-Depends: ${misc:Pre-Depends}' clauses, so
> I guess something changed in 'dh' to cause this new behaviour.  Any
> ideas?

https://salsa.debian.org/debian/debhelper/-/commit/99892be481c1dd06d9866854a2c14e6a70ae12b7
looks suspicious, as it rewrites the addsubstvar function, which is
used by dh_installcatalogs. Indeed if I remove the addsubstvar call
with remove=1 from dh_installcatalogs, sgml-base no longer shows up
in misc:Depends of libidn2-0.

Judging by the current list of `apt-cache rdepends sgml-base`, this
problem has already spread quite a bit.

I think this is a bug in debhelper, and maybe it could be "fixed"
twice:

dh_installcatalogs is not supposed to be idempotent, so the
addsubstvar to "remove the dependency" could just go away?

Then, addsubstvar could maybe also lose its "remove" argument? A
quick codesearch search didn't find me any callers using that, apart
from dh_installcatalogs.

But this is all me typing into a bug report without knowing anything
about debhelper API :-)

Best,
Chris

Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module

[Forest]

Control: found -1 5.10.127-2
Control: notfound -1 5.18.14-1
Control: tags -1 - moreinfo

On Sat, 30 Jul 2022 00:19:25 +0200, Diederik de Haas wrote:

>Is this problem still present with a recent 5.10 or (better yet) the 5.18.14 
>kernel from Unstable?

It is still present in recent 5.10 kernels.

5.18.14-1 from unstable hasn't shown the failure in about a dozen boots.
That's encouraging.  I haven't done a bisect, but some relatively recent
commits (e.g. aec3f415) mention dwmac-rk.  Perhaps one of those fixed it?

Bug#982459: mdadm examine corrupts host ext4

[Chris Hofstaedtler]

Hi Håkan,

* Håkan T Johansson  [220730 23:43]:
> I have now tried with the mdadm 4.2~rc2-2 installed in both the chroot
> environment (tried only that first), and also the host system.
> Unfortunately, the host / fs is still affected when running
> 'update-initramfs -u', when /dev is not mounted.
[..]

> is kind of readable, though, then I'm lost.

I can't see a difference that should matter from userspace.

I have stared a bit at the kernel code... there have been quite some
changes and fixes in this area. Which kernel version were you
running when testing this?

Could you retry on something >= 5.9? I.e. some version with patch
08fc1ab6d748ab1a690fd483f41e2938984ce353.

Thanks,
Chris

Bug#1015263: libidn2-0: Depends sgml-base

[Thorsten Glaser]

Hi Simon,

>I guess something changed in 'dh' to cause this new behaviour.  Any
>ideas?

good guess but no idea, I don’t follow dh development closely. Best
to ask that team then?

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1016374: twitter-bootstrap4 4.5.2+dfsg1-8~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1016374 = 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: twitter-bootstrap4
Version: 4.5.2+dfsg1-8~deb11u1

Explanation: actually install CSS map files

Bug#1016391: bullseye-pu: libhttp-daemon-perl/6.12-1+deb11u1

[Thorsten Alteholz]

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


The attached debdiff for libhttp-daemon-perl fixes CVE-2022-31081 in 
Bullseye. This CVE has been marked as no-dsa by the security team.


The patch is accompanied by a new test and should not create any issue.
It had been used to fix unstable and will be used for Buster, Jessie as well.


  Thorstendiff -Nru libhttp-daemon-perl-6.12/debian/changelog 
libhttp-daemon-perl-6.12/debian/changelog
--- libhttp-daemon-perl-6.12/debian/changelog   2020-06-06 03:12:55.0 
+0200
+++ libhttp-daemon-perl-6.12/debian/changelog   2022-07-26 20:08:59.0 
+0200
@@ -1,3 +1,11 @@
+libhttp-daemon-perl (6.12-1+deb11u1) bullseye; urgency=high
+
+  * Non-maintainer upload by the ELTS Team.
+  * CVE-2022-31081 (Closes: #1014808)
+improved Content-Length: handling in HTTP-header
+
+ -- Thorsten Alteholz   Tue, 26 Jul 2022 20:08:59 +0200
+
 libhttp-daemon-perl (6.12-1) unstable; urgency=medium
 
   * Import upstream version 6.12.
diff -Nru libhttp-daemon-perl-6.12/debian/patches/CVE-2022-31081-1.patch 
libhttp-daemon-perl-6.12/debian/patches/CVE-2022-31081-1.patch
--- libhttp-daemon-perl-6.12/debian/patches/CVE-2022-31081-1.patch  
1970-01-01 01:00:00.0 +0100
+++ libhttp-daemon-perl-6.12/debian/patches/CVE-2022-31081-1.patch  
2022-07-26 20:08:59.0 +0200
@@ -0,0 +1,48 @@
+commit e84475de51d6fd7b29354a997413472a99db70b2
+Author: Theo van Hoesel 
+Date:   Thu Jun 16 08:28:30 2022 +
+
+Fix Content-Length ', '-separated string issues
+
+After a security issue, we ensure we comply to
+RFC-7230 -- HTTP/1.1 Message Syntax and Routing
+- section 3.3.2 -- Content-Length
+- section 3.3.3 -- Message Body Length
+
+diff --git a/lib/HTTP/Daemon.pm b/lib/HTTP/Daemon.pm
+index c0cdf76..a5112b3 100644
+--- a/lib/HTTP/Daemon.pm
 b/lib/HTTP/Daemon.pm
+@@ -288,6 +288,32 @@ READ_HEADER:
+ }
+ elsif ($ct_len) {
+ 
++# After a security issue, we ensure we comply to
++# RFC-7230 -- HTTP/1.1 Message Syntax and Routing
++# section 3.3.2 -- Content-Length
++# section 3.3.3 -- Message Body Length
++
++# split and clean up Content-Length ', ' separated string
++my @vals = map {my $str = $_; $str =~ s/^\s+//; $str =~ s/\s+$//; 
$str }
++split ',', $ct_len;
++# check that they are all numbers (RFC: Content-Length = 1*DIGIT)
++my @nums = grep { /^[0-9]+$/} @vals;
++unless (@vals == @nums) {
++$self->send_error(400);
++$self->reason("Content-Length value must be a unsigned integer");
++return;
++}
++# check they are all the same
++my $ct_len = shift @nums;
++foreach (@nums) {
++next if $_ == $ct_len;
++$self->send_error(400);
++$self->reason("Content-Length values are not the same");
++return;
++}
++# ensure we have now a fixed header, with only 1 value
++$r->header('Content-Length' => $ct_len);
++
+ # Plain body specified by "Content-Length"
+ my $missing = $ct_len - length($buf);
+ while ($missing > 0) {
diff -Nru libhttp-daemon-perl-6.12/debian/patches/CVE-2022-31081-2.patch 
libhttp-daemon-perl-6.12/debian/patches/CVE-2022-31081-2.patch
--- libhttp-daemon-perl-6.12/debian/patches/CVE-2022-31081-2.patch  
1970-01-01 01:00:00.0 +0100
+++ libhttp-daemon-perl-6.12/debian/patches/CVE-2022-31081-2.patch  
2022-07-26 20:08:59.0 +0200
@@ -0,0 +1,33 @@
+commit 8dc5269d59e2d5d9eb1647d82c449ccd880f7fd0
+Author: Theo van Hoesel 
+Date:   Tue Jun 21 20:00:47 2022 +
+
+Include reason in response body content
+
+diff --git a/lib/HTTP/Daemon.pm b/lib/HTTP/Daemon.pm
+index a5112b3..2d022ae 100644
+--- a/lib/HTTP/Daemon.pm
 b/lib/HTTP/Daemon.pm
+@@ -299,16 +299,18 @@ READ_HEADER:
+ # check that they are all numbers (RFC: Content-Length = 1*DIGIT)
+ my @nums = grep { /^[0-9]+$/} @vals;
+ unless (@vals == @nums) {
+-$self->send_error(400);
+-$self->reason("Content-Length value must be a unsigned integer");
++my $reason = "Content-Length value must be an unsigned integer";
++$self->send_error(400, $reason);
++$self->reason($reason);
+ return;
+ }
+ # check they are all the same
+ my $ct_len = shift @nums;
+ foreach (@nums) {
+ next if $_ == $ct_len;
+-$self->send_error(400);
+-$self->reason("Content-Length values are not the same");
++my $reason = "Content-Length values are not the same";
++$self->send_error(400, $reason);
++$self->reason($reason);
+ return;
+ }
+ # ensure we have now a fixed header, with only 1 value
diff -Nru 

Bug#1016390: ITP: progressbar2 -- Text progress bar library for Python

[Sandro Tosi]

> * Package name: progressbar2
>   Version : 4.0.0
>   Upstream Author : Rick van Hattem (Wolph) 
> * URL : https://github.com/WoLpH/python-progressbar
> * License : BSD-3-clause
>   Programming Lang: Python
>   Description : Text progress bar library for Python
>
>   A text progress bar is typically used to display the progress of a long
>   running operation, providing a visual cue that processing is underway.
>   .
>   The ProgressBar class manages the current progress, and the format of the
>   line is given by a number of widgets. A widget is an object that may display
>   differently depending on the state of the progress bar.

what's the plan regarding the current python3-progressbar package?

> I plan to maintain this package as part of the Python modules team.

this name is obsolete, it's now Debian Python Team

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

Bug#1016389: RFP: choose -- human-friendly and fast alternative to cut and (sometimes) awk

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: choose
  Version : 1.3.4
  Upstream Author : Ryan Geary
* URL : https://github.com/theryangeary/choose
* License : GPL-3.0
  Programming Lang: Rust
  Description : human-friendly and fast alternative to cut and (sometimes) 
awk

This is choose, a human-friendly and fast alternative to cut and (sometimes)
awk.
.
Features:
- terse field selection syntax similar to Python's list slices
- negative indexing from end of line
- optional start/end index
- zero-indexed
- reverse ranges
- slightly faster than cut for sufficiently long inputs, much faster than awk
- regular expression field separators using Rust's regex syntax

Bug#1010122: scamper: diff for NMU version 20211212-1.1

[Boyuan Yang]

Control: tags 1010122 + patch
Control: tags 1010122 + pending

Dear maintainer,

I've prepared an NMU for scamper (versioned as 20211212-1.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru scamper-20211212/debian/changelog scamper-
20211212/debian/changelog
--- scamper-20211212/debian/changelog   2022-01-20 08:45:28.0 -0500
+++ scamper-20211212/debian/changelog   2022-07-30 17:26:40.0 -0400
@@ -1,3 +1,11 @@
+scamper (20211212-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Avoid hardcoding arch triplet to prevent
+FTBFS. (Closes: #1010122)
+
+ -- Boyuan Yang   Sat, 30 Jul 2022 17:26:40 -0400
+
 scamper (20211212-1) unstable; urgency=medium
 
   * Update watch file with new location
diff -Nru scamper-20211212/debian/rules scamper-20211212/debian/rules
--- scamper-20211212/debian/rules   2022-01-20 08:45:28.0 -0500
+++ scamper-20211212/debian/rules   2022-07-30 17:26:37.0 -0400
@@ -24,6 +24,6 @@
rm debian/tmp/usr/bin/sc_warts2csv
rm debian/tmp/usr/share/man/man1/sc_wartsfix.1
rm debian/tmp/usr/share/man/man1/sc_warts2csv.1
-   rm debian/tmp/usr/lib/x86_64-linux-gnu/libscamperfile.la
+   rm debian/tmp/usr/lib/*/libscamperfile.la
rm debian/tmp/usr/share/man/man5/warts.5
rm debian/tmp/usr/share/man/man3/libscamperfile.3


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

Bug#1016371: transition: lerc

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-07-30 15:02:41 +0200, Antonio Valentino wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> 
> For the Debian GIS team I'd like to transition to LERC 4.0.0.
> 
> The only reverse dependency is tiff and it rebuilds successfully
> with LERC 4.0.0 form experimental.
> 
> Transition:
> 
>   liblerc3 (3.0+ds-1) -> liblerc4 (4.0.0+ds-1~exp2)
> 
> 
> The status of the most recent rebuilds is as follows.
> 
>  tiff(4.4.0-3)   OK

Please go ahead.

Cheers

> 
> 
> Ben file:
> 
> title = "lerc";
> is_affected = .depends ~ "liblerc3" | .depends ~ "liblerc4";
> is_good = .depends ~ "liblerc4";
> is_bad = .depends ~ "liblerc3";
> 

-- 
Sebastian Ramacher

Bug#1016363: More info about the fvwm deadlock with libx11-6 1.8.1

[Jed Davis]

FVWM's problem here appears to be that it calls XCheckIfEvent with a callback 
that ends up trying to call XFlush; XCheckIfEvent holds the display lock while 
calling the callback and XFlush also locks the display, causing a 
self-deadlock.  I provoked this by iconifying a window with a key bind, and in 
this case it seems to have something to do with the resulting expose events 
(see stack below).  This reentrancy may not be ideal behavior on FVWM's part, 
but this is code which has (seemingly) worked for a long time.

I also came up with a different workaround: instead of rebuilding libx11, I 
rebuilt FVWM with the following definition added:

Status XInitThreads(void)
{
return 0;
}

The executable precedes its libraries in the symbol search path, so this turns 
off X11 thread safety entirely, but only for fvwm; it doesn't appear to use 
threading, either directly or indirectly, and I'm assuming that situation isn't 
likely to change in the immediate future.  This isn't a great solution, but it 
works for me for now.

If it helps, here's the interesting part of the stack trace from the deadlock: 

#3  0x7f01a975a968 in _XLockDisplay (dpy=0x55ca735f4090) at 
../../src/locking.c:466
#4  0x7f01a974e5c2 in XFlush (dpy=0x55ca735f4090) at ../../src/Flush.c:38
#5  0x55ca7248be1b in dispatch_event (e=0x55ca736ec2f8) at events.c:4105
#6  0x55ca7248c0cc in _pred_weed_handle_expose (display=, 
event=, arg=) at events.c:266
#7  0x55ca724ff3b9 in _fev_pred_weed_if (display=, 
event=0x55ca736ec2f8, arg=0x7ffebc6870a0 "\260\300Hr\312U") at FEvent.c:176
#8  0x55ca724ff43f in _fev_pred_check_peek (display=, 
event=0x55ca736ec2f8, arg=0x7ffebc686fb0 "p\363Or\312U") at FEvent.c:144
#9  0x7f01a97489aa in XCheckIfEvent (dpy=0x55ca735f4090, 
event=event@entry=0x7ffebc686ef0, predicate=predicate@entry=0x55ca724ff420 
<_fev_pred_check_peek>, arg=arg@entry=0x7ffebc686fb0 "p\363Or\312U") at 
../../src/ChkIfEv.c:59
#10 0x55ca724ffdc0 in FCheckPeekIfEvent (display=, 
event_return=event_return@entry=0x7ffebc6870e0, 
predicate=predicate@entry=0x55ca724ff370 <_fev_pred_weed_if>, 
arg=arg@entry=0x7ffebc6870a0 "\260\300Hr\312U") at FEvent.c:590
#11 0x55ca724fff17 in FWeedIfEvents (display=, 
weed_predicate=weed_predicate@entry=0x55ca7248c0b0 <_pred_weed_handle_expose>, 
arg=arg@entry=0x0) at FEvent.c:527
#12 0x55ca7248cfba in handle_all_expose () at events.c:4545
#13 0x55ca724be911 in __raise_or_lower_window (t=t@entry=0x55ca7361c250, 
mode=mode@entry=SM_RAISE, allow_recursion=allow_recursion@entry=1, 
is_new_window=is_new_window@entry=0, 
is_client_request=is_client_request@entry=0) at stack.c:1141

--Jed

Bug#1016372: uuid-runtime: post-install script gives warnings which seem incorrect

[Diederik de Haas]

Hi,

On zaterdag 30 juli 2022 16:46:57 CEST Chris Hofstaedtler wrote:
> * Diederik de Haas  [220730 15:12]:
> > adduser: Warning: The home dir /run/uuidd you specified can't be accessed:
> > No such file or directory Adding system user `uuidd' (UID 113) ...
> > Adding new user `uuidd' (UID 113) with group `uuidd' ...
> 
> Right. Not sure if we can suppress the warning.

>From https://wiki.debian.org/ReleaseGoals/RunDirectory:
"/run is a new cross-distribution location for the storage of transient
state files [...] which does not require preserving across reboots."

My first thought was that /run/ was possibly an inappropriate directory for
a home directory, till I found others do it too (and also remember a warning
wrt pulseaudio about using /var/run instead of /run).

I can create a directory in /run as root, so it doesn't seem to be a permission
issue. Maybe it's a check within 'adduser' which generates the warning
and prevents the creation of /run/uuidd ?

Looking for other (system) user accounts with also a homedir in /run/ and found:
https://salsa.debian.org/pulseaudio-team/pulseaudio/-/blob/master/debian/pulseaudio.postinst

It uses a '--quiet' parameter, which may suppress the warning?

> uuidd.socket listens on /run/uuidd/request, so thats automatically
> created by systemd.
> 
> The warning is only shown on first install, as the user then
> remains on the system, even if uuid-runtime is purged. One way of
> fixing this would probably be switching to DynamicUser.

Not (very) knowledgeable about systemd, so can't comment on that.
But if it can work also outside systemd, I'd prefer it.

I'm fine if you want to close the bug as it is minor indeed :-)

Cheers,
  Diederik

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

Bug#1016387: Traces

[Dan Jacobson]

Package: gpxviewer
Version: 1.1.0-4
Severity: wishlist

Cannot see tracepoints.

Bug#1016298: clapper: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test returned exit code 1

[Johannes Schauer Marin Rodrigues]

Hi Lucas,

Quoting Lucas Nussbaum (2022-07-29 20:18:41)
> During a rebuild of all packages in sid, your package failed to build on
> amd64.

thanks a lot for your bug report!

> > command:  MALLOC_PERTURB_=84 /usr/bin/appstream-util validate-relax 
> > /<>/data/com.github.rafostar.Clapper.metainfo.xml
> > --- stdout 
> > ---
> > /<>/data/com.github.rafostar.Clapper.metainfo.xml: FAILED:
> > • url-not-found :  failed to connect: SSL handshake 
> > failed 
> > [https://raw.githubusercontent.com/wiki/Rafostar/clapper/media/screenshot-windowed.png]
> > • url-not-found :  failed to connect: SSL handshake 
> > failed 
> > [https://raw.githubusercontent.com/wiki/Rafostar/clapper/media/screenshot-fullscreen.png]
> > • url-not-found :  failed to connect: SSL handshake 
> > failed 
> > [https://raw.githubusercontent.com/wiki/Rafostar/clapper/media/screenshot-floating.png]
> > • url-not-found :  failed to connect: SSL handshake 
> > failed 
> > [https://raw.githubusercontent.com/wiki/Rafostar/clapper/media/screenshot-mobile.png]
> > --- stderr 
> > ---
> > Validation of files failed
> > ==

This is now fixed in git and I'll do an upload soon:

https://salsa.debian.org/gnome-team/clapper/-/commit/a5e207f51fa37592bb3c8bbb64d71edbf19a88f7

What I don't understand is, why this wasn't discovered by the autobuilders. Do
the buildds allow network access during the builds? I thought they did not. Do
you have an idea?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1016365: WebKitNetworkProcess messages logged

[Paul Gevers]

Hi,

On 30-07-2022 18:27, Camaleón wrote:

It looks wrong indeed, but it also doesn't happen on my system.


Try by setting «Open links in Lifea's window» and click on a feed to
load. This way I always get the above mesages.


This doesn't show any messages in my journal.


Not sure if this helps. Should you need more info kindy ask.


I'll forward the bug to upstream, with the note that I can't reproduce. 
Let's see if they have smart ideas.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016351: dovecot: CVE-2022-30550

[Moritz Mühlenhoff]

Am Fri, Jul 29, 2022 at 02:52:32PM -0700 schrieb Noah Meyerhans:
> My inclination is that this won't need a DSA and can wait for a bullseye 
> point release,

Agreed! Marking it as such in the Debian Security Tracker.

Cheers,
Moritz

Bug#976805: Progress?

[Dima Kogan]

Hi. Is this coming along? What needs to happen to get this into the
repos? Do you need help?

Thanks!

Bug#1016384: further information

[acc]

the actual name of the package missing in the dependency list is
"python3-pyqt5.qtwebengine"
Installing it solved the problem on my System.

Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1

[Jérémy Lal]

Le sam. 30 juil. 2022 à 19:24, Dominique Dumont  a
écrit :

> On Saturday, 30 July 2022 17:25:29 CEST you wrote:
> > libuv1 maintainer: please avoid uploading new versions when nodejs is
> > in transition...
>
> I package libuv1 because it's a dependency of moarvm.
>
> I don't follow nodejs releases, so I was not aware of on-going transition
> and
> I did not expect problems because only the minor version number was
> increased.
>
> On the other hand, I have no problem with delaying uploads of libuv1
> provided
> someone warns me of issues in other packages.



libuv1 is a library, you're supposed to manage the transition:
https://wiki.debian.org/Teams/ReleaseTeam/Transitions

In particular, rebuild all reverse build dependencies and check they won't
break is highly desirable.
There are tools and services in debian to do that (though honestly it's not
so easy to setup).

Reverse Build-depends in main:
--

ardour
bind9
cmake
csound-plugins
dnsjit
dnswire
dqlite
driftnet
forked-daapd
getdns
golang-github-evanw-esbuild
h2o
haxe
hddemux
janus
kamailio
knot-resolver
libstorj
libwebsockets
lua-luv
lua-nvim
macaulay2
moarvm
mosquitto
neovim
netdata
node-expat
node-fbjs
node-grunt-sass
node-iconv
node-jasmine
node-leveldown
node-modern-syslog
node-nan
node-node-sass
node-nouislider
node-opencv
node-pause
node-pre-gyp
node-re2
node-react
node-rollup-plugin-sass
node-shiny-server
node-sqlite3
node-websocket
node-ws
node-zx
nodejs
npm
nqp
ocaml-luv
passenger
pcp
polybar
python-gevent
r-cran-fs
r-cran-httpuv
r-cran-v8
radare2
radare2-cutter
raft
rakudo
rtpengine
select2.js
siridb-server
swupdate
tensorpipe
ttyd
uvloop

Found a total of 69 reverse build-depend(s) for libuv1-dev.


Jérémy

Bug#1016386: RFS: scid/1:4.7.4+dfsg1-2 -- chess database with play and training functionality

[Jose G. López]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: scid
   Version : 1:4.7.4+dfsg1-2
   Upstream Author : Fulvio Benini 
 * URL : http://scid.sf.net
 * License : Tklib, GPL-2.0
 * Vcs : https://salsa.debian.org/josgalo-guest/scid
   Section : games

The source builds the following binary packages:

  scid - chess database with play and training functionality
  scid-data - data files for scid, the chess database application

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/scid/scid_4.7.4+dfsg1-2.dsc

Changes since the last upload:

 scid (1:4.7.4+dfsg1-2) unstable; urgency=medium
 .
   * debian/rules:
 - Pass OPTIMIZE variable without '-march=native' value
   to avoid build failures. Removed by mistake.

P.D: The version in unstable (1:4.7.4+dfsg1-1) is not migrating to testing due 
to build failures.
My mistake, I removed an important variable, sorry.

Thanks and regards,


pgpJUob7ucoZM.pgp
Description: PGP signature

Bug#864423: Software RAID is not activated at boot time

[Chris Hofstaedtler]

Hi debian-boot,

* László Böszörményi (GCS)  [220730 15:34]:
> On Sat, Jul 30, 2022 at 1:50 PM Chris Hofstaedtler  wrote:
> > whats the status of dmraid? Do you have dmraid hardware or is this
> > merely on life-support?
>  Please note dmraid upstream is dead for more than ten years. I might
> find an old i386 hardware that needs it.
> But yes, it's only on life-support.

[..]

> > I'm wondering if we should remove dmraid support from the d-i as a
> > first step. AFAICT Intel Software RAID is supported by mdraid, not
> > sure if the other RAID platforms are still sold.
>  Sounds like a good idea. This will show users early Debian doesn't
> plan to ship it anymore.

I was digging around in the d-i code, and it appears for dmraid to
be invoked, one has to boot with disk-detect/dmraid/enable. 

I have opened merge requests to remove the dmraid/sataraid code from
d-i. The changes look like low risk to me, but obviously I have no
idea. For the lack of a build environment I also didn't test them.

Given d-i does nothing with dmraid unless the boot flag is present,
I want to ask if dmraid could also stop shipping its udeb, if thats
ok with debian-boot?

Thanks,
Chris

Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1

[Dominique Dumont]

On Saturday, 30 July 2022 17:25:29 CEST you wrote:
> libuv1 maintainer: please avoid uploading new versions when nodejs is
> in transition...

I package libuv1 because it's a dependency of moarvm.

I don't follow nodejs releases, so I was not aware of on-going transition and 
I did not expect problems because only the minor version number was increased. 

On the other hand, I have no problem with delaying uploads of libuv1 provided 
someone warns me of issues in other packages.

All the best

Bug#1016385: asn1c-doc: trying to overwrite '/usr/share/doc/asn1c/BUGS', which is also in package asn1c 0.9.28+dfsg-3

[Jakub Wilk]

Package: asn1c-doc
Version: 0.9.28+dfsg-4
Severity: serious

Upgrading the package failed:

  Unpacking asn1c-doc (0.9.28+dfsg-4) over (0.9.28+dfsg-3) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-wSkNUL/03-asn1c-doc_0.9.28+dfsg-4_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/asn1c/BUGS', which is also in package 
asn1c 0.9.28+dfsg-3

--
Jakub Wilk

Bug#1016384: pampi: Not all dependencies listed in package

[Stefan Pasteiner]

Package: pampi
Version: 1.1+dfsg1-5
Severity: grave
Tags: ftbfs
Justification: renders package unusable
X-Debbugs-Cc: a...@pasteiner.eu




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

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

Versions of packages pampi depends on:
ii  fonts-katex 0.13.11+~cs6.0.0-3
ii  fonts-opendyslexic  20160623-4
ii  fonts-sil-andika6.101-2
ii  hovercraft  2.7-3
ii  jsxgraph1.4.5+dfsg1-1
ii  libjs-bootstrap 3.4.1+dfsg-2
ii  libjs-c30.4.11+dfsg-4
ii  libjs-impress   1.1.0-2
ii  libjs-katex 0.13.11+~cs6.0.0-3
ii  libjs-marked4.0.17+ds+~4.0.3-1
ii  macaulay2-common1.20+ds-7
ii  pandoc  2.9.2.1-3+b2
ii  python3 3.10.5-3

pampi recommends no packages.

pampi suggests no packages.

-- no debconf information

Running the programm Fails with a python Traceback Stating:
Traceback (most recent call last):
  File "/usr/share/pampi/pampi.pyw", line 64, in 
import main
  File "/usr/share/pampi/libs/main.py", line 39, in 
import utils_webengine
  File "/usr/share/pampi/libs/utils_webengine.py", line 53, in 
from PyQt5.QtWebKitWidgets import QWebView as QWebEngineView
ModuleNotFoundError: No module named 'PyQt5.QtWebKitWidgets'

This can possible resolved by installing python3-pyqt5-qtwebengine 
adding this pakages to the dependencylist should solve this problem for 
everyone installing the pakage in the future.

Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.

[Yukiharu YABUKI]

Hi,

Ok, I'll install lxterminal(lxterm)

My default terminal is uxterm.

I go over this issue with uxterm and lxterm.

Both of these terminal do not change between 
"日本語 - anthy" and "日本語 - japanese".

I found one more strange behavior.

odd number I did `ibus-daemon -rxd` It works fine.
but even number I did `ibus-daemon -rxd` does not
accept ctrl+j.

It's time to learn how to use debuginfod. ...
I need to help how to setup and debug. 

I'll try to ask mailling list.

When I reboot my desktop machine, I do `reboot` command.

On Sat, 30 Jul 2022 01:30:41 +0900
Osamu Aoki  wrote:


> 
> So you are still suffering ... Strange.
> 
> Do you have the same issue with any GTK program?  Say lxterminal ?
> 
> If program using ibus/anthy is GTK, it doesn't access such daemon.  It access 
> library
> instead.  So the symptom reported is strange.
> 
> Are you suffering this problem with rxvt or xterm?
> 
> Please double check if your power-down is the real one (not sleep button) by 
> shutting
> down system from the virtual Linux console command line (ALT-CTRL-F3 etc.) 
> with "sudo
> shutdown -h now" or similar.
> 
> Osamu


--
Yukiharu YABUKI 

Bug#1016134: mu4e: /usr/share/doc/mu4e/changelog.gz is not useful

[Martin]

Thanks for your bug report!

On 2022-07-27 12:46, Dima Kogan wrote:
> But NEWS.org isn't shipped in the documentation. It should be shipped in
> the docs instead of the changelog file. The related "maildir-utils"
> package has the same problem.

https://packages.debian.org/sid/amd64/maildir-utils/filelist lists the
file, so it is only missing in mu4e. I guess, I'll add a symlink.

Cheers

Bug#1016365: WebKitNetworkProcess messages logged

[Camaleón]

El 2022-07-30 a las 16:09 +0200, Paul Gevers escribió:

> Control: tags -1 moreinfo unreproducible
> 
> Hi Camaleón,
> 
> On 30-07-2022 10:10, Camaleón wrote:
> > When openning Liferea it logs these lines under /var/log/mesages, dmesg,
> > journatlctl:
> > 
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 1   0x7fea3c64a34f
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 2   0x7fea3c4ff9ba
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 3   0x7fea3c7c7e8b
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 4   0x7fea3c7c817a
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 5   0x7fea3c7c845a
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 6   0x7fea3adcbd30
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 7   0x7fea3ae2cc66
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 8   0x7fea3ae2c0da
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 9   0x7fea3789dd6f 
> > g_main_context_dispatch
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 10  0x7fea3789e118
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 11  0x7fea3789e40b 
> > g_main_loop_run
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 12  0x7fea3ae2c6b6 
> > WTF::RunLoop::run()
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 13  0x7fea3c79bff6
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 14  0x7fea3728cd0a 
> > __libc_start_main
> > Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 15  0x40106a
> > 
> > Note sure if this ir normal or expected, but to my eyes looks like a
> > trace or some kind of error.
> 
> It looks wrong indeed, but it also doesn't happen on my system.

Try by setting «Open links in Lifea's window» and click on a feed to 
load. This way I always get the above mesages.
 
> > I experience no visible/noticeable errors on the application and this
> > log is also visible on Debian tetsing.
> 
> Is there anything special on you system? You say it also visible on Debian
> testing, does that mean you experience it on two systems?

Nothing special, I think. 
Yes, the messages are visible in Debian Bullseye (installed on my main 
system) and also in Debian testing (installed on a netbook I use for 
tetsing purposes).
 
> Can you maybe try to start liferea from the command line and see if you can
> capture more of the output and the context? If that works, it might be good
> if we can try to get a backtrace, but honestly I don't have much experience
> there so we'd need to figure out how to do that.

1. On Debian testing:

testing@netbook:~$ liferea
libGL error: MESA-LOADER: failed to open i915: 
/usr/lib/dri/i915_dri.so: no se puede abrir el fichero del objeto 
compartido: No existe el fichero o el directorio (search paths 
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix 
_dri)
libGL error: failed to load driver: i915 

The file DOES NOT exist in this system.

On testing I can reproduce the messages when I set to use Liferea's 
browser and click a feed to open.

2. On Debian stable:

sm01@stt008:~$ liferea

(liferea:11886): dbind-WARNING **: 18:09:49.038: AT-SPI: Error 
retrieving accessibility bus address: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was 
not provided by any .service files
Could not determine the accessibility bus address

(liferea:11886): Gtk-CRITICAL **: 18:09:51.101: 
gtk_tree_model_filter_get_path: assertion 'GTK_TREE_MODEL_FILTER 
(model)->priv->stamp == iter->stamp' failed
sys:1: Warning: g_hash_table_insert_internal: assertion 'hash_table != 
NULL' failed
sys:1: Warning: g_hash_table_lookup: assertion 'hash_table != NULL' 
failed

Here the messages are logged everytime I click on a feed, despite the 
feeds opens in Firefox (external browser) or Liferea's internal browser.

What seems triggering the messages is cliking on the feeds and load the 
full page.

Not sure if this helps. Should you need more info kindy ask.

Greetings,

-- 
Camaleón 

Bug#1016287: closed by Paul Gevers (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)

[Yadd]

On 30/07/2022 16:45, Paul Gevers wrote:

Control: reopen -1
Control: retitle -1 britney recursive installability test in autopkgtest

Hi Yadd,

On 30-07-2022 15:58, Yadd wrote:
Node.js isn't available on armel, and the consequence will be to not 
fix some CVEs/BTS during freeze. Hope none of them will appear...


For those we have unblock requests and the normal process to get 
packages into testing during the freeze. The autopkgtest process wasn't 
designed to change that.


Maybe Britney could not consider autopkgtest as failing when a build 
dependency is missing in one arch (at least for arch=all) ?


Why *build* dependencies?

britney takes dependencies into account and doesn't schedule the jobs if 
all binaries are uninstallable. However, looking at your example, there 
might be an issue that it doesn't resolve that recursively during the 
policy phase of britney. (There's also a problem for britney that 
involves source packages that build both arch:all and arch:any binaries, 
which it fundamentally can't always resolve correctly, I thought we were 
in that case here). Let's see if I can come up with a reproducer in our 
test suite.


Thanks!

Most of node-* package build depends on nodejs but are usable without 
it. See libjs-bootstrap4 for example


Again, what do build dependencies have to do with the problem? If they 
don't need nodejs to run, they shouldn't have a dependency on them and 
everything is fine. You'll recall that I recently stripped the unneeded 
nodejs dependency from all node-d3-* packages. Now they are installable 
on armel.


Paul


By "build dependencies", I meant "test dependencies" (Build-Depends 
contains often both). All JS test framework needs nodejs (mocha, jest, 
tape,...) and all node-d3-* autopkgtests will fail with armel.


Cheers,
Yadd

Bug#1016305: nodejs: FTBFS: make[2]: *** [Makefile:504: test-ci-js] Error 1

[Jérémy Lal]

Source: nodejs
Version: 18.6.0+dfsg-3
Followup-For: Bug #1016305
X-Debbugs-Cc: lib...@packages.debian.org

The two actually failing tests are:
parallel/test-socket-write-after-fin-error
parallel/test-tls-streamwrap-buffersize

Those failures are regressions caused by recent upload of libuv1 1.44.2.

Upstream nodejs already knows this but they are still
figuring out how to fix one of the failures.

libuv1 maintainer: please avoid uploading new versions when nodejs is
in transition...


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

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

Bug#1016382: afterstep: Typo disables DEB_LDFLAGS_MAINT_APPEND

[Boyuan Yang]

Source: afterstep
Severity: normal
Version: 2.2.12-15
X-Debbugs-CC: rob...@debian.org

Dear Debian afterstep package maintainer,

A typo of DEB_LDFLAGS_MAINT_APPEND made this configuration useless:

https://sources.debian.org/src/afterstep/2.2.12-15/debian/rules/?hl=7#L7

We should use DEB_LDFLAGS_MAINT_APPEND, but the code uses
DEB_LDLAGS_MAINT_APPEND. Please fix it.

Thanks,
Boyuan Yang


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

Bug#1016381: nodejs: regexp crash on ppc64el

[Jérémy Lal]

Package: nodejs
Version: 18.6.0+dfsg-3
Severity: important
Control: affects -1 node-babel7
Control: forwarded -1 https://github.com/nodejs/node/issues/44055

Some very long regular expressions can make nodejs (actually, libv8)
crash on ppc64el.

This typically happens when typescript compiles node-babel7.

See upstream bug report for more info.




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

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 nodejs depends on:
ii  libc6   2.33-8
ii  libnode108  18.6.0+dfsg-3

Versions of packages nodejs recommends:
ii  ca-certificates  20211016
ii  nodejs-doc   18.6.0+dfsg-3

Versions of packages nodejs suggests:
ii  npm  8.15.1~ds1-1

-- no debconf information

Bug#1016380: python3-sure: Hardcoded dependency on python3.9

[Boyuan Yang]

Package: python3-sure
Severity: serious
Version: 2.0.0-1
X-Debbugs-CC: z...@debian.org

Dear Debian python-sure package maintainer,

Your package has a hard dependency on python3.9, which blocks the ongoing
pytho3.10-only transition
https://release.debian.org/transitions/html/python3.10-only.html :

-> % apt show python3-sure
Package: python3-sure
Version: 2.0.0-1
Priority: optional
Section: python
Source: python-sure
Maintainer: Debian OpenStack 
Installed-Size: 101 kB
Depends: python3-nose, python3-rednose, python3-six, python3-mock,
python3.9:any, python3:any
Homepage: https://github.com/gabrielfalcao/sure

Please consider fixing this issue.

Thanks,
Boyuan Yang


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

Bug#888141: python3-sure: Newer version available

[Boyuan Yang]

Control: tags 888141 +bookworm  +sid
Control: fixed 888141 2.0.0-1
Control: close 888141

The new version is already present in Debian Testing and Unstable.

Thanks,
Boyuan Yang


On Tue, 23 Jan 2018 17:36:10 +0100 Matthias Urlichs 
wrote:
> Package: python3-sure
> Version: 1.2.5-4
> Severity: wishlist
> 
> current httpretty depends on sure==1.2.24
> 
> -- System Information:
> Debian Release: 9.3
>   APT prefers stable
>   APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (550,
'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armhf
> 
> Kernel: Linux 4.14.0-2-amd64 (SMP w/16 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages python3-sure depends on:
> ii  dpkg 1.18.24
> ii  python3  3.6.4-1
> ii  python3-nose 1.3.7-2
> ii  python3-rednose  0.4.1-2
> ii  python3-six  1.10.0-3
> 
> python3-sure recommends no packages.
> 
> python3-sure suggests no packages.
> 
> -- no debconf information
> 
> 



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

Bug#1016372: uuid-runtime: post-install script gives warnings which seem incorrect

[Chris Hofstaedtler]

Hi,

thanks for the report.

* Diederik de Haas  [220730 15:12]:
[..]
> adduser: Warning: The home dir /run/uuidd you specified can't be accessed: No 
> such file or directory
> Adding system user `uuidd' (UID 113) ...
> Adding new user `uuidd' (UID 113) with group `uuidd' ...

Right. Not sure if we can suppress the warning.

[..]

> First adduser warns about a non-existing dir, /run/uuidd and then it
> mentions not creating /run/uuidd.
> 
> But that is/seems inconsistent with what `ls` tells me:
> 
> root@cs21:~# ls -lhd /run/uuidd/
> drwxr-xr-x 2 root root 60 Jul 30 14:57 /run/uuidd/

uuidd.socket listens on /run/uuidd/request, so thats automatically
created by systemd.

The warning is only shown on first install, as the user then
remains on the system, even if uuid-runtime is purged. One way of
fixing this would probably be switching to DynamicUser.

Chris

Bug#1016287: closed by Paul Gevers (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)

[Paul Gevers]

Control: reopen -1
Control: retitle -1 britney recursive installability test in autopkgtest

Hi Yadd,

On 30-07-2022 15:58, Yadd wrote:
Node.js isn't available on armel, and the consequence will be to not fix 
some CVEs/BTS during freeze. Hope none of them will appear...


For those we have unblock requests and the normal process to get 
packages into testing during the freeze. The autopkgtest process wasn't 
designed to change that.


Maybe Britney could not consider autopkgtest as failing when a build 
dependency is missing in one arch (at least for arch=all) ?


Why *build* dependencies?

britney takes dependencies into account and doesn't schedule the jobs if 
all binaries are uninstallable. However, looking at your example, there 
might be an issue that it doesn't resolve that recursively during the 
policy phase of britney. (There's also a problem for britney that 
involves source packages that build both arch:all and arch:any binaries, 
which it fundamentally can't always resolve correctly, I thought we were 
in that case here). Let's see if I can come up with a reproducer in our 
test suite.


Most of 
node-* package build depends on nodejs but are usable without it. See 
libjs-bootstrap4 for example


Again, what do build dependencies have to do with the problem? If they 
don't need nodejs to run, they shouldn't have a dependency on them and 
everything is fine. You'll recall that I recently stripped the unneeded 
nodejs dependency from all node-d3-* packages. Now they are installable 
on armel.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013929: src:goffice: FTBFS on mips64el

[Ludovic Rousseau]

Hello,

I am the Debian maintainer of the package grisbi that depends on 
libgoffice-0.10-10


I see no update on this bug since 3 weeks.

It looks like the fix is proposed upstream at 
https://gitlab.gnome.org/GNOME/goffice/-/issues/59#note_1495045


Dmitry, do you need help?

Thanks

--
Dr. Ludovic Rousseau

Bug#1016379: nfft: soname changes without package renaming and library transition

[Adrian Bunk]

Package: libnfft3-double2
Version: 3.5.3-1
Severity: serious
Control: affects -1 src:pynfft python3-pynfft yorick-ynfft libnfft3-long2 
libnfft3-single2

https://ci.debian.net/data/autopkgtest/testing/arm64/p/pynfft/24167703/log.gz

...
ERROR: Failure: ImportError (libnfft3_threads.so.2: cannot open shared object 
file: No such file or directory)
...


Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/libnfft3.so.2.0.0
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/libnfft3_threads.so.2.0.0
lrwxrwxrwx  root/root   /usr/lib/x86_64-linux-gnu/libnfft3.so.2 -> 
libnfft3.so.2.0.0
lrwxrwxrwx  root/root   /usr/lib/x86_64-linux-gnu/libnfft3_threads.so.2 -> 
libnfft3_threads.so.2.0.0

Files in second .deb but not in first
-
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/libnfft3.so.4.0.3
-rw-r--r--  root/root   /usr/lib/x86_64-linux-gnu/libnfft3_threads.so.4.0.3
lrwxrwxrwx  root/root   /usr/lib/x86_64-linux-gnu/libnfft3.so.4 -> 
libnfft3.so.4.0.3
lrwxrwxrwx  root/root   /usr/lib/x86_64-linux-gnu/libnfft3_threads.so.4 -> 
libnfft3_threads.so.4.0.3


The same problem is present in libnfft3-long2 and libnfft3-single2.

Bug#1014675: Apparently not fixed on the 102.1 (aka ESR branch).

[Eric Valette]

See:

https://bugzilla.mozilla.org/show_bug.cgi?id=1745033#c59

Bug#1016378: nfft: binary-all FTBFS

[Adrian Bunk]

Source: nfft
Version: 3.5.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=nfft=all=3.5.3-1=1659084565=0

...
   dh_install -i
dh_install: warning: Cannot find (any matches for) "usr/share/doc/nfft/html" 
(tried in ., debian/tmp)

dh_install: warning: libnfft3-doc missing files: usr/share/doc/nfft/html
dh_install: error: missing files, aborting
make: *** [debian/rules:37: binary-indep] Error 25

Bug#1016377: nfft builds with -march=native

[Adrian Bunk]

Source: nfft
Version: 3.5.3-1
Severity: serious

nfft builds with -march=native, which makes the package only
run on hardware compatible with whatever buildd happened to
build the package.

Bug#1016376: openjdk-19 should not be in stable releases

[Adrian Bunk]

Source: openjdk-19
Version: 19~32ea-1
Severity: serious

openjdk-19 should not be in stable releases,
this bug should keep it out of testing.

Bug#1016375: openjdk-18 should not be in stable releases

[Adrian Bunk]

Source: openjdk-18
Version: 18.0.2+9-2
Severity: serious

openjdk-18 should not be in stable releases,
this bug should keep it out of testing.

Bug#1016365: WebKitNetworkProcess messages logged

[Paul Gevers]

Control: tags -1 moreinfo unreproducible

Hi Camaleón,

On 30-07-2022 10:10, Camaleón wrote:

When openning Liferea it logs these lines under /var/log/mesages, dmesg,
journatlctl:

Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 1   0x7fea3c64a34f
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 2   0x7fea3c4ff9ba
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 3   0x7fea3c7c7e8b
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 4   0x7fea3c7c817a
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 5   0x7fea3c7c845a
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 6   0x7fea3adcbd30
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 7   0x7fea3ae2cc66
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 8   0x7fea3ae2c0da
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 9   0x7fea3789dd6f 
g_main_context_dispatch
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 10  0x7fea3789e118
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 11  0x7fea3789e40b 
g_main_loop_run
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 12  0x7fea3ae2c6b6 
WTF::RunLoop::run()
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 13  0x7fea3c79bff6
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 14  0x7fea3728cd0a 
__libc_start_main
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 15  0x40106a

Note sure if this ir normal or expected, but to my eyes looks like a
trace or some kind of error.


It looks wrong indeed, but it also doesn't happen on my system.


I experience no visible/noticeable errors on the application and this
log is also visible on Debian tetsing.


Is there anything special on you system? You say it also visible on 
Debian testing, does that mean you experience it on two systems?


Can you maybe try to start liferea from the command line and see if you 
can capture more of the output and the context? If that works, it might 
be good if we can try to get a backtrace, but honestly I don't have much 
experience there so we'd need to figure out how to do that.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016287: closed by Paul Gevers (Re: Bug#1016287: release.debian.org: autopkgtest 2 to 5 days since addition of armel)

[Yadd]

> Hi Jérémy,
>
> On 29-07-2022 19:36, Jérémy Lal wrote:
> > when a package pass all autopkgtests it can migrate in 2 days,
> > however if it depends on an architecture that reports "Not a
> > regression",
> > it seems that the bonus is lost and the package must wait 5 days.
>
> That's by design.
>
> > The problem is that it happens when a package depends on a package
> > that is not available in a given architecture.
>
> Unfortunately, that's indeed the price of that design. As we're
> supposed
> to try and support all architectures equally well, I decided that's
> acceptable.
>
> Paul
[...]
> Hi Jérémy.
>
> On 29-07-2022 22:17, Jérémy Lal wrote:
> > I don't see how artificially adding migration days will improve
> > debian quality in any way.
>
> We're not adding days, we're just not giving the bounty for success on
> all architectures where we run autopkgtests, which was the rule for
> the bounty.
>
> Paul

Hi,

this is not just a matter of bounty, but the key to upload during freeze.

Node.js isn't available on armel, and the consequence will be to not fix 
some CVEs/BTS during freeze. Hope none of them will appear...


Maybe Britney could not consider autopkgtest as failing when a build 
dependency is missing in one arch (at least for arch=all) ? Most of 
node-* package build depends on nodejs but are usable without it. See 
libjs-bootstrap4 for example

Bug#995859: assimp: autopkgtests failing for 32bit archs

[Paul Gevers]

Control: severity -1 important
Control: user debian...@lists.debian.org
Control: usertag -1 timeout
Control: found -1 5.2.4~ds0-1 5.1.3~ds0-1

Hi IOhannes,

On Thu, 07 Oct 2021 09:31:01 +0200 
=?utf-8?q?IOhannes_m_zm=C3=B6lnig_=28Debian/GNU=29?= 
 wrote:

It seems that the autopkg tests fail on all 32-bit archs (they always
did, so there is no regression):

| ARCH| state || kernel-arch |
|-|---||-|
| amd64   | pass  ||   amd64 |
| arm64   | pass  ||   arm64 |
| ppc64el | pass  || ppc64el |
| armel   | fail  ||   arm64 |
| armhf   | fail  ||   arm64 |
| i386| fail  ||   amd64 |


On armel/armhf/i386, the test fails with a segfault when trying to open
'/usr/share/assimp/models/COB/dwarf.cob'

Also note, that for all failing tests there is an architecture mismatch
between the user-space and the kernel.


It got worse with version 5.1.3~ds0-1 where the test started to time out 
on those architectures after 2 hours and 47 minutes.


As this is causing unnecessary strain on our infrastructure, I'm going 
to add them to our rejectlist on these architectures.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015270: transition: nodejs

[Jérémy Lal]

Le sam. 30 juil. 2022 à 15:42, Paul Gevers  a écrit :

> Hi Jérémy,
>
> On 29-07-2022 22:47, Jérémy Lal wrote:
> > All seems to be well on its way, with the exception of the
> autopkgtest
> > failure of node-babel7 on ppc64el. Did you already have a look at
> that?
> >
> > I can file the bug against node-babel7 if you want.
> >
> >
> > v8 clearly crashes on ppc64el here while executing tsc, so it's not a
> > node-babel7 bug.
>
> If I understand you correctly, v8 is some internal thing of nodejs and
> the issue needs to be fixed there.


That's right.


> Did you already report the issue
> upstream? Do you need help from the ppc64el porters? Will you handle this?
>

Not yet but yes, I'm currently working on it - good news is that it
reproduces on plummer.d.o.

Jérémy

Bug#1016374: bullseye-pu: twitter-bootstrap4/4.5.2+dfsg1-8~deb11u1

[Mattia Rizzolo]

Package: release.debian.org
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Dear SRM,

See attached a debdiff that I just uploaded so to fix
https://bugs.debian.org/991939 in stable.

This is a plain backport of the bugfix-only -8 revision, leading to a
.deb that is pretty much identical to the -8 .deb; compared to the -7
currently in stable it's only adding the missing file.

-- 
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  `-
diffstat for twitter-bootstrap4-4.5.2+dfsg1 twitter-bootstrap4-4.5.2+dfsg1

 changelog |   13 +
 rules |1 +
 2 files changed, 14 insertions(+)

diff -Nru twitter-bootstrap4-4.5.2+dfsg1/debian/changelog 
twitter-bootstrap4-4.5.2+dfsg1/debian/changelog
--- twitter-bootstrap4-4.5.2+dfsg1/debian/changelog 2021-07-30 
06:53:34.0 +0200
+++ twitter-bootstrap4-4.5.2+dfsg1/debian/changelog 2022-07-30 
15:39:25.0 +0200
@@ -1,3 +1,16 @@
+twitter-bootstrap4 (4.5.2+dfsg1-8~deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Backport the fix for #991939 to bullseye.
+
+ -- Mattia Rizzolo   Sat, 30 Jul 2022 15:39:25 +0200
+
+twitter-bootstrap4 (4.5.2+dfsg1-8) unstable; urgency=medium
+
+  * Add missing .map files (Closes: #991939)
+
+ -- Yadd   Sat, 07 Aug 2021 07:07:47 +0200
+
 twitter-bootstrap4 (4.5.2+dfsg1-7) unstable; urgency=medium
 
   [ Pirate Praveen ]
diff -Nru twitter-bootstrap4-4.5.2+dfsg1/debian/rules 
twitter-bootstrap4-4.5.2+dfsg1/debian/rules
--- twitter-bootstrap4-4.5.2+dfsg1/debian/rules 2021-07-30 06:53:34.0 
+0200
+++ twitter-bootstrap4-4.5.2+dfsg1/debian/rules 2022-07-30 15:39:11.0 
+0200
@@ -12,6 +12,7 @@
sassc --sourcemap=auto scss/bootstrap-reboot.scss 
dist/tmp/bootstrap-reboot.css
node debian/postcss.js
cp -v dist/tmp/*.css dist/css/
+   cp -v dist/tmp/*.css.map dist/css/
sassc --sourcemap=auto --style compressed dist/tmp/bootstrap.css 
dist/css/bootstrap.min.css
sassc --sourcemap=auto --style compressed dist/tmp/bootstrap-grid.css 
dist/css/bootstrap-grid.min.css
sassc --sourcemap=auto --style compressed dist/tmp/bootstrap-reboot.css 
dist/css/bootstrap-reboot.min.css


signature.asc
Description: PGP signature

Bug#1016373: deviceinfo: ftbfs on risc64 arch("error: some symbols or patterns disappeared in the symbols file")

[Bo YU]

Source: deviceinfo
Version: 0.1.0-7
Severity: normal
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear deviceinfo Maintainer,

The deviceinfo package has a ftbfs issue on riscv64 arch due to missing
symbols: 

```
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libdeviceinfo0/DEBIAN/symbols doesn't match 
completely debian/libdeviceinfo0.symbols
--- debian/libdeviceinfo0.symbols (libdeviceinfo0_0.1.0-7_riscv64)
+++ dpkg-gensymbolsBu3PxE   2022-07-30 00:40:26.269866954 +
@@ -53,7 +53,8 @@
  _ZN4YAML4NodeixIA8_cEES0_RKT_@Base 0.1.0
  (arch=!mips64el)_ZN4YAML4NodeixIA9_cEES0_RKT_@Base 0.1.0
  
(optional=templinst)_ZN4YAML4NodeixINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcES0_RKT_@Base
 0.1.0
-#MISSING: 0.1.0# 
(optional=templinst|subst)_ZN4YAML4NodeixI{size_t}EES0_RKT_@Base 0.1.0
+ _ZN4YAML4NodeixImEES0_RKT_@Base 0.1.0-7
+#MISSING: 0.1.0-7# 
(optional=templinst|subst)_ZN4YAML4NodeixI{size_t}EES0_RKT_@Base 0.1.0
  _ZN4YAML6detail14iterator_valueC1ERKNS_4NodeE@Base 0.1.0
  _ZN4YAML6detail14iterator_valueC2ERKNS_4NodeE@Base 0.1.0
  _ZN4YAML6detail14iterator_valueD1Ev@Base 0.1.0
@@ -62,7 +63,8 @@
  (arch=mips64el)_ZN4YAML6detail4node14add_dependencyERS1_@Base 0.1.0
 #MISSING: 0.1.0# (optional=templinst|arch=alpha hppa hurd-i386 
ia64)_ZN4YAML6detail4node3getINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcERS1_RKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0
  _ZN4YAML6detail4node6equalsEPKcSt10shared_ptrINS0_13memory_holderEE@Base 0.1.0
-#MISSING: 0.1.0# (optional=templinst|arch=!alpha !hppa !hurd-i386 
!ia64|subst)_ZN4YAML6detail9node_data15convert_to_nodeI{size_t}EERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0
+ 
_ZN4YAML6detail9node_data15convert_to_nodeImEERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0-7
+#MISSING: 0.1.0-7# (optional=templinst|arch=!alpha !hppa !hurd-i386 
!ia64|subst)_ZN4YAML6detail9node_data15convert_to_nodeI{size_t}EERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0
  
_ZN4YAML6detail9node_data3getIA11_cEERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0
  
_ZN4YAML6detail9node_data3getIA13_cEERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0
  
_ZN4YAML6detail9node_data3getIA5_cEERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0
@@ -70,7 +72,8 @@
  
_ZN4YAML6detail9node_data3getIA8_cEERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0
  
_ZN4YAML6detail9node_data3getIA9_cEERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0
  
(optional=templinst)_ZN4YAML6detail9node_data3getINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0
-#MISSING: 0.1.0# 
(optional=templinst|subst)_ZN4YAML6detail9node_data3getI{size_t}EERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0
+ 
_ZN4YAML6detail9node_data3getImEERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0-7
+#MISSING: 0.1.0-7# 
(optional=templinst|subst)_ZN4YAML6detail9node_data3getI{size_t}EERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE@Base
 0.1.0
  
(optional=templinst)_ZN4YAML7convertISt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EEE6decodeERKNS_4NodeERS9_@Base
 0.1.0
 #MISSING: 0.1.0# (optional=templinst|arch=armel 
armhf)_ZN4YAML7convertIjE6decodeERKNS_4NodeERj@Base 0.1.0
  _ZN4YAML8ErrorMsg22BAD_SUBSCRIPT_WITH_KEYB5cxx11EPKc@Base 0.1.0
@@ -162,72 +165,72 @@
  (optional=templinst|arch=!armel 
!riscv64)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_releaseEv@Base
 0.1.0
  (optional=templinst|arch=!armel 
!riscv64)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE15_M_add_ref_copyEv@Base
 0.1.0
  (optional=templinst|arch=amd64 arm64 ia64 mips64el ppc64 
s390x)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE24_M_release_last_use_coldEv@Base
 0.1.0
- 
(optional=templinst|arch=riscv64)_ZNSt23_Sp_counted_ptr_inplaceI6ConfigSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE10_M_destroyEv@Base
 0.1.0
- 
(optional=templinst|arch=riscv64)_ZNSt23_Sp_counted_ptr_inplaceI6ConfigSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE10_M_disposeEv@Base
 0.1.0
- 
(optional=templinst|arch=riscv64)_ZNSt23_Sp_counted_ptr_inplaceI6ConfigSaIS0_ELN9__gnu_cxx12_Lock_policyE1EE14_M_get_deleterERKSt9type_info@Base
 0.1.0
- 
(optional=templinst|arch=riscv64)_ZNSt23_Sp_counted_ptr_inplaceI6ConfigSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED0Ev@Base
 0.1.0
- 
(optional=templinst|arch=riscv64)_ZNSt23_Sp_counted_ptr_inplaceI6ConfigSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED1Ev@Base
 0.1.0
- 
(optional=templinst|arch=riscv64)_ZNSt23_Sp_counted_ptr_inplaceI6ConfigSaIS0_ELN9__gnu_cxx12_Lock_policyE1EED2Ev@Base
 0.1.0
+#MISSING: 0.1.0-7# 

Bug#1015270: transition: nodejs

[Paul Gevers]

Hi Jérémy,

On 29-07-2022 22:47, Jérémy Lal wrote:

All seems to be well on its way, with the exception of the autopkgtest
failure of node-babel7 on ppc64el. Did you already have a look at that?

I can file the bug against node-babel7 if you want.


v8 clearly crashes on ppc64el here while executing tsc, so it's not a 
node-babel7 bug.


If I understand you correctly, v8 is some internal thing of nodejs and 
the issue needs to be fixed there. Did you already report the issue 
upstream? Do you need help from the ppc64el porters? Will you handle this?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#864423: Software RAID is not activated at boot time

[GCS]

Hi all,

On Sat, Jul 30, 2022 at 1:50 PM Chris Hofstaedtler  wrote:
> whats the status of dmraid? Do you have dmraid hardware or is this
> merely on life-support?
 Please note dmraid upstream is dead for more than ten years. I might
find an old i386 hardware that needs it.
But yes, it's only on life-support.

> * Paul Gevers :
> > What would you say about this? Even if d-i would not need it anymore, we
> > would need work to drop the dependency chain via
> > libblockdev/udisks2/gnome-control-center.
 Do these have real use of dmraid, tested from time to time at least?

> I'm wondering if we should remove dmraid support from the d-i as a
> first step. AFAICT Intel Software RAID is supported by mdraid, not
> sure if the other RAID platforms are still sold.
 Sounds like a good idea. This will show users early Debian doesn't
plan to ship it anymore.

> If its gone from di-i, at least no new installs can spring into
> existence "by accident", i.e. where mdraid would have been the
> better choice.
 Exactly.

Regards,
Laszlo/GCS

Bug#1016372: uuid-runtime: post-install script gives warnings which seem incorrect

[Diederik de Haas]

Package: uuid-runtime
Version: 2.38-6
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I just installed uuid-runtime on a Rock64 device (arm64) and got several
warnings/info messages which seem incorrect to me.

root@cs21:~# aptitude install uuid-runtime
The following NEW packages will be installed:
  uuid-runtime
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 108 kB of archives. After unpacking 334 kB will be used.
Get: 1 http://deb.debian.org/debian bookworm/main arm64 uuid-runtime arm64 
2.38-6 [108 kB]
Fetched 108 kB in 0s (526 kB/s)
Selecting previously unselected package uuid-runtime.
(Reading database ... 47358 files and directories currently installed.)
Preparing to unpack .../uuid-runtime_2.38-6_arm64.deb ...
Unpacking uuid-runtime (2.38-6) ...
Setting up uuid-runtime (2.38-6) ...
Adding group `uuidd' (GID 120) ...
Done.
adduser: Warning: The home dir /run/uuidd you specified can't be accessed: No 
such file or directory
Adding system user `uuidd' (UID 113) ...
Adding new user `uuidd' (UID 113) with group `uuidd' ...
Not creating home directory `/run/uuidd'.
Created symlink /etc/systemd/system/sockets.target.wants/uuidd.socket → 
/lib/systemd/system/uuidd.socket.
uuidd.service is a disabled or a static unit, not starting it.


First adduser warns about a non-existing dir, /run/uuidd and then it
mentions not creating /run/uuidd.

But that is/seems inconsistent with what `ls` tells me:

root@cs21:~# ls -lhd /run/uuidd/
drwxr-xr-x 2 root root 60 Jul 30 14:57 /run/uuidd/




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

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

Versions of packages uuid-runtime depends on:
ii  adduser  3.123
ii  init-system-helpers  1.64
ii  libc62.33-8
ii  libsmartcols12.38-6
ii  libsystemd0  251.3-1
ii  libuuid1 2.38-6

uuid-runtime recommends no packages.

uuid-runtime suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYuUtNgAKCRDXblvOeH7b
bm7vAQD1G1O7ZumkFKy2c2eJzNKAqoMgyu36fMSD5he7Fo/8qQEAuWaLMzP2mCjA
UlvVMNRb1yg+cb/zdL5YdsVxZFRYkQA=
=L3yL
-END PGP SIGNATURE-

Bug#924139: www.debian.org: migrate from python to python3

[Laura Arjona Reina]

Hello

thanks everybody for the work and sorry to get to this so late.

I think that currently our Python2 code is in these files:

Webwml repo:

./english/mirror/timestamps/archive_mirror_check.py
./english/mirror/timestamps/mirror_check.py

Cron repo:

/urlcheck/test.py
/urlcheck/urlcheck.py

I'll try to apply the patch 
[0002-Python-scripts-modify-to-use-Python3-syntax.patch] that Carsten 
provided and do some tests, and that would cover the webwml repo.


For the cron repo, I tried to pass the 2to3 tool and follow the 
instructions but had some issues and couldn't complete the migration. 
I'll do another try during this weekend and post here my results, but if 
anybody is familiarised with Python coding, any help is appreciated.


Kind regards

--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#1016371: transition: lerc

[Antonio Valentino]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition


For the Debian GIS team I'd like to transition to LERC 4.0.0.

The only reverse dependency is tiff and it rebuilds successfully
with LERC 4.0.0 form experimental.

Transition:

  liblerc3 (3.0+ds-1) -> liblerc4 (4.0.0+ds-1~exp2)


The status of the most recent rebuilds is as follows.

 tiff(4.4.0-3)   OK


Ben file:

title = "lerc";
is_affected = .depends ~ "liblerc3" | .depends ~ "liblerc4";
is_good = .depends ~ "liblerc4";
is_bad = .depends ~ "liblerc3";

Bug#1013493: python-django-jsonfield: FTBFS: ImportError: cannot import name 'ugettext_lazy' from 'django.utils.translation' (/usr/lib/python3/dist-packages/django/utils/translation/__init__.py)

[Raphael Hertzog]

Hello,

On Fri, 24 Jun 2022, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks but I will not fix this bug. Intsead I have asked to remove
this package from unstable since it has been superseded by a native
field provided by Django:
https://docs.djangoproject.com/en/3.2/ref/models/fields/#jsonfield

Removal bug: https://bugs.debian.org/1016370

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1016370: RM: python-django-jsonfield -- ROM; Abandoned upstream, replaced by native Django field

[Raphaël Hertzog]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: hert...@debian.org

Hello,

please remove python-django-jsonfield from unstable. Django 3.2 already
provides a generic JSONField similar to what's provided in
python-django-jsonfield:
https://docs.djangoproject.com/en/3.2/ref/models/fields/#jsonfield

Given this, python-django-jsonfield is no longer maintained upstream
and should replaced by the above field.

Everybody should switch to the Django native field.

There are no reverse dependencies in unstable.

Thank you,
  Raphaël Hertzog.

Bug#1016369: IO::Handle ->error does not work, always saying "fine"

[Ian Jackson]

Package: perl
Version: 5.34.0-4
Severity: grave

To reproduce

perl -MIO::Handle -e 'open X, "<", "." or die $!; $_ = ; printf "%s %s 
%s\n", X->error(), $!;'
perl -MIO::Handle -e 'open X, ">", "/dev/full" or die $!; print X 1; flush 
X; printf "%s %s %s\n", X->error(), $!; close X'

Expected output

-1 Bad file descriptor
-1 No space left on device

Actual output

0 Bad file descriptor
0 No space left on device

This is quite alarming.  I think it makes it in fact impossible to
read files fully reliably in Perl.  "use autodie" does not seem to help.

And scripts might reasonably have expected that they could defer error
handling by testing error() rather than each call (as one can in C).

I think this used to work, but, evidently, only in the distant past,
since my jessie chroot doesn't get this right either.

Justification for the severity:

Can cause data loss: if a file is opened but unreadable for any
reason, the program will process the part (if any) that will is
readable and then 

Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#864423: Software RAID is not activated at boot time

[Chris Hofstaedtler]

Hi Laszlo,

whats the status of dmraid? Do you have dmraid hardware or is this
merely on life-support?

* Paul Gevers :
> What would you say about this? Even if d-i would not need it anymore, we
> would need work to drop the dependency chain via
> libblockdev/udisks2/gnome-control-center.

I'm wondering if we should remove dmraid support from the d-i as a
first step. AFAICT Intel Software RAID is supported by mdraid, not
sure if the other RAID platforms are still sold.
If its gone from di-i, at least no new installs can spring into
existence "by accident", i.e. where mdraid would have been the
better choice.

What do you, Laszlo and d-boot, think?

Chris

Bug#1015974: Should gnat-gps be removed?

[Ludovic Brenta]

severity 1015974 normal
retitle 1015974 gnat-gps: new version available using python 3
thanks

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

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

-- 
Ludovic Brenta.

Bug#1016363: libx11-6 1.8.1 also breaks notion

[Göran Weinholt]

Hello,

The libx11 commit "global: call XInitThreads() from the library's
constructor" identified in this issue is also breaking notion.

notion 4.0.2+dfsg-6 with libx11-6 2:1.8.1-1 crashes with this message:

  notion: tpp.c:82: __pthread_tpp_change_priority: Assertion `new_prio == -1 || 
(new_prio >= fifo_min_prio && new_prio <= fifo_max_prio)' failed.

I rebuilt libx11 with the new --disable-thread-safety-constructor flag
and then notion started working again.

-- 
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK

Bug#1016368: lintian: Check ancient versions in dpkg-maintscript-helper invocations

[Gioele Barabucci]

Package: lintian
Severity: wishlist

Dear lintian maintainers,

could you please extend `MaintainerScripts/AncientVersion.pm` to check 
for old package versions in debhelper-generated invocations of 
`dpkg-maintscript-helper` in maintscripts?


Several packages carry outdated dpkg-maintscript-helper invocations 
referring to versions older than oldstable.


For example, `colord.maintscript` contains

rm_conffile /etc/bash_completion.d/colormgr-completion.bash 1.0.3-1~
rm_conffile /etc/colord.conf 1.2.12-1~ colord
rm_conffile /etc/dbus-1/[...]ColorManager.conf 1.4.3-4~
rm_conffile /etc/dbus-1/[...]colord-sane.conf 1.0.3-1~

Out of these four lines, three refer to versions older that 1.4.3-4, the 
version of `colord` in oldstable (Debian 10).


Regards,

--
Gioele Barabucci

Bug#1014911: Not fixed with 102.1

[Eric Valette]

Still missing end to end security in all accounts.

--eric

Bug#1016366: Fix the typo for bug 1016366

[Su, Bao Cheng]

Sorry, the last paragraph should be:

```
# nmcli connection show eno1-old | grep times
connection.timestamp:   1659162980
# nmcli connection show eno1-new | grep times
connection.timestamp:   1659162980
```

Bug#1016367: gnome-shell: trouble with dual VGA devices

[Patrice Duroux]

Package: gnome-shell
Version: 42.3.1-2
Severity: normal

Dear Maintainer,

My Debian Sid system has the following VGA devices:
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-H GT2 [UHD
Graphics 630] (rev 02)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Lexa
XT [Radeon PRO WX 3200]

Here is attached the coredumpctl with some dbgsym packages installed.

This happens each first session after a boot is started and I am having a
similar trouble also using tty,
a king of graphical devices reset.

So it is not due to GNOME Shell but it has a bad effect on it.

Regards,
Patrice


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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gir1.2-accountsservice-1.0   22.08.8-1
ii  gir1.2-adw-1 1.2~alpha-1
ii  gir1.2-atk-1.0   2.38.0-1
ii  gir1.2-atspi-2.0 2.44.1-1
ii  gir1.2-freedesktop   1.72.0-1+b1
ii  gir1.2-gcr-3 3.41.1-1
ii  gir1.2-gdesktopenums-3.0 42.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.8+dfsg-2
ii  gir1.2-gdm-1.0   42.0-1
ii  gir1.2-geoclue-2.0   2.6.0-1
ii  gir1.2-glib-2.0  1.72.0-1+b1
ii  gir1.2-gnomebluetooth-3.042.2-1
ii  gir1.2-gnomedesktop-3.0  42.3-1
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.20.3-1
ii  gir1.2-gtk-3.0   3.24.34-1
ii  gir1.2-gtk-4.0   4.6.6+ds-1
ii  gir1.2-gweather-4.0  4.0.0-2
ii  gir1.2-ibus-1.0  1.5.26-4
ii  gir1.2-mutter-10 42.3-2
ii  gir1.2-nm-1.01.38.2-1
ii  gir1.2-nma-1.0   1.8.40-1
ii  gir1.2-pango-1.0 1.50.7+ds-1
ii  gir1.2-polkit-1.00.105-33
ii  gir1.2-rsvg-2.0  2.54.4+dfsg-1
ii  gir1.2-soup-2.4  2.74.2-3
ii  gir1.2-upowerglib-1.00.99.20-1
ii  gir1.2-webkit2-4.0   2.36.4-1
ii  gnome-backgrounds42.0-1
ii  gnome-settings-daemon42.2-1
ii  gnome-shell-common   42.3.1-2
ii  gsettings-desktop-schemas42.0-1
ii  gstreamer1.0-pipewire0.3.56-1
ii  libatk-bridge2.0-0   2.38.0-4
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-8
ii  libcairo21.16.0-6
ii  libecal-2.0-13.44.3-2
ii  libedataserver-1.2-263.44.3-2
ii  libgcr-base-3-1  3.41.1-1
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-2
ii  libgirepository-1.0-11.72.0-1+b1
ii  libgjs0g 1.72.0-4
ii  libgles2 1.4.0-1
ii  libglib2.0-0 2.72.3-1
ii  libglib2.0-bin   2.72.3-1
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-1942.3-1
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.34-1
ii  libgtk-4-1   4.6.6+ds-1
ii  libical3 3.0.14-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-10-0   42.3-2
ii  libnm0   1.38.2-1
ii  libpango-1.0-0   1.50.7+ds-1
ii  libpangocairo-1.0-0  1.50.7+ds-1
ii  libpolkit-agent-1-0  0.105-33
ii  libpolkit-gobject-1-00.105-33
ii  libpulse-mainloop-glib0  15.0+dfsg1-4+b1
ii  libpulse015.0+dfsg1-4+b1
ii  libsecret-1-00.20.5-2
ii  libsystemd0  251.3-1
ii  libwayland-server0   1.21.0-1
ii  libx11-6   

Bug#1016366: network-manager: Activated connection becomes de-activated after reboot

[Su, Bao Cheng]

Package: network-manager
Version: 1.30.6-1+deb11u1
Severity: normal
X-Debbugs-Cc: baocheng...@siemens.com

If you have multiple connections for one interface, when using nmtui ->
`Activate a connection` to switch to another connection, it succeeds
without problems. However, if you reboot the system, sometimes the
activated connection becomes de-activate and the old connection becomes
activate again.

This happens more frequently if reboot is immediately after the activating.
If waiting for some minutes, this issue may not happen.

BTW, if using `nmcli` to dump the timestamp of the connection, both of the 
old and the new connection have the same timestamp right after switching
using `nmtui`:

```
# nmcli connection show eno1-old | grep times
connection.timestamp:   1659162980
# nmcli connection show eno1-old | grep times
connection.timestamp:   1659162980
```

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads)
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 network-manager depends on:
ii  adduser  3.118
ii  dbus 1.12.20-2
ii  libaudit11:3.0-2
ii  libbluetooth35.55-3.1
ii  libc62.31-13+deb11u3
ii  libcurl3-gnutls  7.74.0-1.3+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgnutls30  3.7.1-5+deb11u1
ii  libjansson4  2.13.1-1.1
ii  libmm-glib0  1.14.12-0.2
ii  libndp0  1.6-1+b1
ii  libnewt0.52  0.52.21-4+b3
ii  libnm0   1.30.6-1+deb11u1
ii  libpsl5  0.21.0-1.2
ii  libreadline8 8.1-1
ii  libselinux1  3.1-3
ii  libsystemd0  247.3-7
ii  libteamdctl0 1.31-1
ii  libudev1 247.3-7
ii  libuuid1 2.36.1-8+deb11u1
ii  policykit-1  0.105-31+deb11u1
ii  udev 247.3-7
ii  wpasupplicant2:2.9.0-21

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  iptables 1.8.7-1
ii  libpam-systemd   247.3-7
ii  modemmanager 1.14.12-0.2
ii  ppp  2.4.9-1+1
ii  wireless-regdb   2022.04.08-2~deb11u1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.3
pn  libteam-utils

-- no debconf information

Bug#1016365: WebKitNetworkProcess messages logged

[Camaleón]

Package: liferea
Version: 1.13.5-3
Severity: normal

Hello,

When openning Liferea it logs these lines under /var/log/mesages, dmesg, 
journatlctl:

Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 1   0x7fea3c64a34f
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 2   0x7fea3c4ff9ba
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 3   0x7fea3c7c7e8b
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 4   0x7fea3c7c817a
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 5   0x7fea3c7c845a
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 6   0x7fea3adcbd30
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 7   0x7fea3ae2cc66
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 8   0x7fea3ae2c0da
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 9   0x7fea3789dd6f 
g_main_context_dispatch
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 10  0x7fea3789e118
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 11  0x7fea3789e40b 
g_main_loop_run
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 12  0x7fea3ae2c6b6 
WTF::RunLoop::run()
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 13  0x7fea3c79bff6
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 14  0x7fea3728cd0a 
__libc_start_main
Jul 29 18:02:51 stt008 WebKitNetworkProcess[26567]: 15  0x40106a

Note sure if this ir normal or expected, but to my eyes looks like a 
trace or some kind of error.

I experience no visible/noticeable errors on the application and this 
log is also visible on Debian tetsing.

Greetings,

-- 
Camaleón

Bug#1016277: qbs: FTBFS: ERROR: /usr/bin/ld: unrecognized option '-Wl,-s'

[Dmitry Shachnev]

Control: fixed -1 qbs/1.23.0-1
Control: close -1
Control: merge 1013020 -1

On Fri, Jul 29, 2022 at 06:24:03PM +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > 3: ERROR: /usr/bin/ld: unrecognized option '-Wl,-s'
> > 3: /usr/bin/ld: use the --help option for usage information
> > 3: collect2: error: ld returned 1 exit status

No, the relevant part is this:

> dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
> file: see diff output below

So it is the same bug as #1013020, which is fixed in experimental.

I hope I will upload it to unstable soon, but I need to find a workaround
for #1016041.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#972785: zeromq3: Include cmake files for cppzmq

[GCS]

On Fri, Jul 29, 2022 at 10:48 PM Stephan Lachnit
 wrote:
> To do the migration, I would first put cppzmq in NEW (after your ok), and 
> after it has been accepted in NEW you would upload the new version of 
> zeromq3. Overall I think the transition will be less painful than patching 
> build systems downstream (and annoying Debian users that write software using 
> the CMake files).
 OK, ping me when I can remove the mentioned headers from src:zeromq3
and I will do the upload.

Cheers,
Laszlo/GCS

Bug#1016364: lintian: spelling-error-in-binary should be more precise

[Mattia Rizzolo]

On Sat, Jul 30, 2022 at 08:30:13AM +0300, Martin-Éric Racine wrote:
> When building dhcpcd5 version 9.4.1-4 against Stable, Lintian 2.104.0 reports 
> the following:
> 
> I: dhcpcd-base: spelling-error-in-binary usr/sbin/dhcpcd addres address
> 
> $ grep -rw addres
> $
> 
> i.e. not found.
> 
> Lintian really needs to quote the whole stanza where typos are spotted, 
> otherwise, it's like looking for a needle in a hay stack.

Those "spelling error in binary" checks use `strings` on the final
binary, so there isn't really much to see often.

% strings dhcpcd|grep -E 'addres\b'
Duplicate addres

In your case at most you could get this much.

Note that strings can also "leak" from statically linked/inlined functions.


I tried a quick codesearch.d.n lookup, but I couldn't spot a string like
that.


-- 
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#1016363: Acknowledgement (libx11 v1.8.1 does fail in a subtle way withj modale dialogs)

[Klaus Ethgen]

For your info, with gentoo I bisected the version and found the broken
patch to be afcdb6fb0045c6186aa83d9298f327a7ec1b2cb9.

Regards
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1014675: This bug is not resolved 102.1

[Kamil Jońca]

I just installed thunderbird 102.1 - bug still exists. It should be reopen.
KJ
-- 
http://wolnelektury.pl/wesprzyj/teraz/

Bug#1013950: libvte-2.91-0: Add gtk4 vte library versions

[Willem van den Akker]

On Fri, 2022-07-29 at 17:24 -0400, Jeremy Bicha wrote:
> On Mon, Jun 27, 2022 at 5:09 PM Willem van den Akker
>  wrote:
> > I am migrating one of my packages to gtk4. For this application
> > libvte-2.91-dev
> > is needed. However there is no gtk4 version in the repository.
> 
> What package are you converting?
> 
> I'll upload the gtk4 version now, but it will need to make it through
> Debian's NEW queue before it will be available.
> 
> Thank you,
> Jeremy Bicha

Hi,

I am porting gtkterm [1] to gtk4. 
For now I build my own gtk4 vte-lib from the source.

Greetings,
Willem

[1] https://tracker.debian.org/pkg/gtkterm