Bug#1035779: linux-image-5.10.0-22: kvm/qemu kernel null pointer dereference, VM doesn't start

[Jared Epp]

Package: src:linux
Version: 5.10.178-3
Severity: normal
X-Debbugs-Cc: jared...@pm.me

Dear Maintainer,

After I updated my Debian 11 host kernel to 5.10.0-22, my VM guest (Windows 10 
using KVM / qemu / libvirt) no longer boots and there's a kernel null pointer 
dereference along with a call trace, etc. in the system log. If I reboot and 
choose 5.10.0-21 in grub, the VM works as expected and there's no error in the 
log.

Below, reportbug included part of the kernel log but it missed part of the 
problem so I pasted that in, I hope that's okay. If you need any other 
information let me know.

Thanks

Jared Epp

-- Package-specific info:
** Version:
Linux version 5.10.0-22-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.178-3 (2023-04-22)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-22-amd64 root=/dev/mapper/panthro--vg-root ro quiet 
mem_sleep_default=s2idle default_hugepagesz=1G hugepages=8

** Tainted: D (128)
 * kernel died recently, i.e. there was an OOPS or BUG

** Kernel log:
[   51.576266] BUG: kernel NULL pointer dereference, address: 
[   51.576269] #PF: supervisor read access in kernel mode
[   51.576270] #PF: error_code(0x) - not-present page
[   51.576271] PGD 0 P4D 0 
[   51.576273] Oops:  [#1] SMP NOPTI
[   51.576275] CPU: 6 PID: 2209 Comm: CPU 0/KVM Not tainted 5.10.0-22-amd64 #1 
Debian 5.10.178-3
[   51.576276] Hardware name: ASUS System Product Name/CROSSHAIR VI HERO, BIOS 
8701 02/08/2023
[   51.576280] RIP: 0010:find_first_bit+0x19/0x40
[   51.576281] Code: 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc cc cc cc 49 89 
f0 48 85 f6 74 28 31 c0 eb 0d 48 83 c0 40 48 83 c7 08 4c 39 c0 73 17 <48> 8b 17 
48 85 d2 74 eb f3 48 0f bc d2 48 01 d0 49 39 c0 4c 0f 47
[   51.576282] RSP: 0018:a99ac3a23a30 EFLAGS: 00010246
[   51.576283] RAX:  RBX: a99ac38a5000 RCX: 
[   51.576283] RDX:  RSI: 0120 RDI: 
[   51.576284] RBP:  R08: 0120 R09: 94e2c1ae72a8
[   51.576284] R10: 000f R11:  R12: 94e2c1ae72a8
[   51.576285] R13: 0323 R14: 0003 R15: 0006
[   51.576286] FS:  (0053) GS:94e89e98(002b) 
knlGS:f8033f006000
[   51.576286] CS:  0010 DS:  ES:  CR0: 80050033
[   51.576287] CR2:  CR3: 00018e4ee000 CR4: 00750ee0
[   51.576287] PKRU: 5554
[   51.576288] Call Trace:
[   51.576307]  kvm_make_vcpus_request_mask+0x38/0xf0 [kvm]
[   51.576319]  kvm_hv_flush_tlb+0x147/0x370 [kvm]
[   51.576328]  ? kvm_page_track_is_active+0x12/0x50 [kvm]
[   51.576336]  ? make_spte+0x146/0x260 [kvm]
[   51.576344]  ? mmu_spte_update+0x11/0x1c0 [kvm]
[   51.576351]  ? set_spte+0xee/0x140 [kvm]
[   51.576358]  ? mmu_set_spte+0x327/0x4a0 [kvm]
[   51.576365]  ? kvm_release_pfn_clean+0x22/0x40 [kvm]
[   51.576372]  ? direct_page_fault+0x223/0xa20 [kvm]
[   51.576374]  ? svm_get_segment+0x18/0x100 [kvm_amd]
[   51.576382]  ? kvm_get_cs_db_l_bits+0x35/0x70 [kvm]
[   51.576383]  ? svm_get_segment+0x18/0x100 [kvm_amd]
[   51.576390]  ? kvm_get_cs_db_l_bits+0x35/0x70 [kvm]
[   51.576398]  kvm_hv_hypercall+0x176/0x580 [kvm]
[   51.576401]  ? get_cpu_vendor+0x40/0xa0
[   51.576403]  ? native_load_tr_desc+0x67/0x70
[   51.576411]  kvm_arch_vcpu_ioctl_run+0xbe8/0x1740 [kvm]
[   51.576419]  kvm_vcpu_ioctl+0x21e/0x5b0 [kvm]
[   51.576422]  __x64_sys_ioctl+0x8b/0xc0
[   51.576424]  do_syscall_64+0x33/0x80
[   51.576426]  entry_SYSCALL_64_after_hwframe+0x61/0xc6
[   51.576428] RIP: 0033:0x7fad816f2237
[   51.576429] Code: 00 00 00 48 8b 05 59 cc 0d 00 64 c7 00 26 00 00 00 48 c7 
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 29 cc 0d 00 f7 d8 64 89 01 48
[   51.576429] RSP: 002b:7fad7ce65508 EFLAGS: 0246 ORIG_RAX: 
0010
[   51.576430] RAX: ffda RBX: ae80 RCX: 7fad816f2237
[   51.576431] RDX:  RSI: ae80 RDI: 001c
[   51.576431] RBP: 55a3e17511c0 R08: 55a3df109848 R09: 55a3df5335c0
[   51.576432] R10:  R11: 0246 R12: 
[   51.576432] R13: 55a3df54fbc0 R14: 7fad7ce657c0 R15: 00802000
[   51.576434] Modules linked in: xt_nat veth nft_chain_nat xt_MASQUERADE 
nf_nat nf_conntrack_netlink xfrm_user xfrm_algo br_netfilter vhost_net vhost 
vhost_iotlb tap tun bridge stp llc overlay ip6t_REJECT nf_reject_ipv6 xt_hl 
ip6_tables ip6t_rt ipt_REJECT nf_reject_ipv4 xt_multiport nft_limit 
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi 
snd_hda_intel nls_ascii snd_intel_dspcfg nls_cp437 soundwire_intel vfat 
soundwire_generic_allocation fat snd_soc_core snd_compress soundwire_cadence 
snd_hda_codec edac_mce_amd xt_limit xt_addrtype kvm_amd 

Bug#1035650: elpa-org version older than built-in Org in bookworm

[Max Nikulin]

On 09/05/2023 05:00, Nicholas D Steeves wrote:

It's what at least two users want


Intention of my bug report is to ensure that it was a conscious decision 
to keep a bit outdated Org version. I hope, only a small part of users 
will really notice the difference with built-in version. I consider 
Org-9.6 as desired, but unrealistic, a dummy package as a compromise.



Release notes can
advise the former to remove elpa-org, but we shouldn't advise
elpa-org-contrib users to use 'equivs' to make emacs Provide a virtual
elpa-org.


If you are against equivs then elpa-org dependency must be dropped from 
elpa-org-contrib. Unfortunately the latter requires a change of a 
package in testing.



You're describing the "dummy package" approach.  I was advocating for
the "virtual package" approach (with version-qualified Provides <- this
is key)


There is a minor issue with the dummy package approach. Some (I hope 
rare) users may try to install emacs-27 from bullseye and dummy elpa-org 
(if it would be uploaded to bookworm at all of course) getting Org 
version (emacs built-in) significantly less than they may expect from 
the version of the elpa-org Debian package.


The following consideration are mostly concerning trixie, but still 
might affect current decision.


Adding Org version to emacs-el "Provides" is a reasonable idea since 
org-contrib, at least formally, does not require latest Org release, 
however it is possible that Package-Requires inside the .el file was not 
up to date. So likely org-contrib may be run with built-in Org.


However I think "elpa-org" is a bit confusing name for virtual package. 
Something like emacs-pkg-org in both emacs-el and elpa-org may be better.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033400#25

suggests to not ship Org in the emacs-el Debian package. Certainly it is 
possible to split built-in Org into a separate package and to add it to 
"Recommends" of emacs-el. However it increases maintenance cost while 
benefits are not clear to me. Perhaps it is better to discuss splitting 
in #1033400.


I think, users who relies on latest Org features and fixes, stick to 
other methods than elpa-org Debian package (and sometimes are bitten by 
e.g. package.el bugs). It is another reason to respect Debian release 
policy, but be more carefully with updates in future.

Bug#1035704: proj: reproducible-builds: timezone-dependent timestamps in .gsb/.gtx files

[Sebastiaan Couwenberg]

On 5/9/23 05:47, Sebastiaan Couwenberg wrote:

On 5/8/23 22:43, Vagrant Cascadian wrote:

On 2023-05-08, Sebastiaan Couwenberg wrote:

On 5/8/23 02:07, Vagrant Cascadian wrote:

The attached patch fixes this by not touching these files during the
build process.


  From shar(1):

"
    -m, --no-timestamp
   do not restore modification times.

   Avoid generating 'touch' commands to restore the file
   modification dates when unpacking files from the archive.

   When file modification times are not preserved, project build
   programs like "make" will see built files older than the 
files

   they get built from.  This is why, when this option is not
   used, a special effort is made to restore timestamps.
"

That should be used when generating the archives instead of your patch
to not have the mtimes touched when unpacking the archives.


Is it actually a problem to allow dpkg to normalize the timestamps on
these files rather than forcefully setting them to ... a value from a
shar archive? It is perhaps a naive question; I really do not know.


Where does dpkg normalize the timestamps?

shar sets the timestamps when the archive is unpacked before the package 
built starts.


Some of the files in the diffoscope-results are only installed in 
proj-data and not used otherwise during the build.


  * BETA2007.gsb is used in test/gie/DHDN_ETRS89.gie

  * CHENYX06.gsb/CHENYX06_etrs.gsb/CHENYX06a.gsb are only installed

  * egm96_15.gtx is used in test/gie/deformation.gie,
    test/gie/more_builtins.gie, test/gie/4D-API_cs2cs-style.gie, and
    test/cli/testdatumfile

  * ntf_r93.gsb is used in test/gie/more_builtins.gie,
    test/gie/4D-API_cs2cs-style.gie, and test/cli/testdatumfile

  * nzgd2kgrid0005.gsb is used in unit tests


But the diffoscope-results only show a few of the files from the shar
archives with different mtimes, and all of them get touched when
unpacking the archive just before the configure target is executed.


Well, I too was perplexed why other files were not affected, but it is
consistently those .gsb and .gtx files, and the submitted patch allows
to consistently build reproducibly in the dozens of times I've build
it...



shar actually makes the timestamps reproducible by always using the
mtime recorded in the archive instead of the time the files were 
unpacked.


Something else is likely changing the mtime after the files are
unpacked. Some of these grids are used by the testsuite for example.


I will try to look into it further, but without really being familiar
with the proj codebase (or even what proj itself does)... any additional
very specific suggestions where to look next would definitely be
appreciated!  :)


CMake's configure_file() is used to copy the .gsb & .gtx files from 
CMAKE_CURRENT_SOURCE_DIR to CMAKE_CURRENT_BINARY_DIR, that might be 
touching the mtimes too. See: data/CMakeLists.txt


Seeing how the mtimes are off by two hours, this could be the difference 
between UTC and CEST. The latter was in effect when the archives were 
created:


 $ grep "Made on" debian/datumgrids*.shar
 debian/datumgrids-ch.shar:# Made on 2018-02-26 22:27 CET by .
 debian/datumgrids.shar:# Made on 2018-09-15 20:13 CEST by .

But why does it only affect the binary GSB & GTX files, and not also the 
binary ntv1_can.dat file or text files like README.DATUMGRID and the 
init files (the ones without extensions)?


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1035704: proj: reproducible-builds: timezone-dependent timestamps in .gsb/.gtx files

[Sebastiaan Couwenberg]

On 5/8/23 22:43, Vagrant Cascadian wrote:

On 2023-05-08, Sebastiaan Couwenberg wrote:

On 5/8/23 02:07, Vagrant Cascadian wrote:

The attached patch fixes this by not touching these files during the
build process.


  From shar(1):

"
-m, --no-timestamp
   do not restore modification times.

   Avoid generating 'touch' commands to restore the file
   modification dates when unpacking files from the archive.

   When file modification times are not preserved, project build
   programs like "make" will see built files older than the files
   they get built from.  This is why, when this option is not
   used, a special effort is made to restore timestamps.
"

That should be used when generating the archives instead of your patch
to not have the mtimes touched when unpacking the archives.


Is it actually a problem to allow dpkg to normalize the timestamps on
these files rather than forcefully setting them to ... a value from a
shar archive? It is perhaps a naive question; I really do not know.


Where does dpkg normalize the timestamps?

shar sets the timestamps when the archive is unpacked before the package 
built starts.


Some of the files in the diffoscope-results are only installed in 
proj-data and not used otherwise during the build.


 * BETA2007.gsb is used in test/gie/DHDN_ETRS89.gie

 * CHENYX06.gsb/CHENYX06_etrs.gsb/CHENYX06a.gsb are only installed

 * egm96_15.gtx is used in test/gie/deformation.gie,
   test/gie/more_builtins.gie, test/gie/4D-API_cs2cs-style.gie, and
   test/cli/testdatumfile

 * ntf_r93.gsb is used in test/gie/more_builtins.gie,
   test/gie/4D-API_cs2cs-style.gie, and test/cli/testdatumfile

 * nzgd2kgrid0005.gsb is used in unit tests


But the diffoscope-results only show a few of the files from the shar
archives with different mtimes, and all of them get touched when
unpacking the archive just before the configure target is executed.


Well, I too was perplexed why other files were not affected, but it is
consistently those .gsb and .gtx files, and the submitted patch allows
to consistently build reproducibly in the dozens of times I've build
it...



shar actually makes the timestamps reproducible by always using the
mtime recorded in the archive instead of the time the files were unpacked.

Something else is likely changing the mtime after the files are
unpacked. Some of these grids are used by the testsuite for example.


I will try to look into it further, but without really being familiar
with the proj codebase (or even what proj itself does)... any additional
very specific suggestions where to look next would definitely be
appreciated!  :)


CMake's configure_file() is used to copy the .gsb & .gtx files from 
CMAKE_CURRENT_SOURCE_DIR to CMAKE_CURRENT_BINARY_DIR, that might be 
touching the mtimes too. See: data/CMakeLists.txt


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1035778: Add gcc-12.3 to testing

[Bjarni Ingi Gislason]

Package: gcc-12
Version: 12.2.0-14
Severity: normal

Dear Maintainer,

   * What led up to the situation?

  The gcc-12.2 shows a compilation error with "linux-source" (6.1.8-1,
6.1.12-1, 6.1.20-1, 6.1.25-1)

  Bug for version 6.1.25-1:

In file included from ./include/linux/kobject.h:20,
 from ./include/linux/module.h:21,
 from drivers/scsi/scsi_scan.c:29:
./include/linux/sysfs.h:297:43: internal compiler error: Illegal instruction
  297 |   const char *name);
  |   ^
0x7f297a4bff8f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [scripts/Makefile.build:255: drivers/scsi/scsi_scan.o] Error 1
make[2]: *** [scripts/Makefile.build:505: drivers/scsi] Error 2
make[1]: *** [scripts/Makefile.build:505: drivers] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:2037: .] Error 2

  gcc-11.3 does not show such an error.


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

Kernel: Linux 6.1.25-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gcc-12 depends on:
ii  binutils   2.40-2
ii  cpp-12 12.2.0-14
ii  gcc-12-base12.2.0-14
ii  libc6  2.36-9
ii  libcc1-0   12.2.0-14
ii  libgcc-12-dev  12.2.0-14
ii  libgcc-s1  12.2.0-14
ii  libgmp10   2:6.2.1+dfsg1-1.1
ii  libisl23   0.25-1
ii  libmpc31.3.1-1
ii  libmpfr6   4.2.0-1
ii  libstdc++6 12.2.0-14
ii  libzstd1   1.5.4+dfsg2-5
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages gcc-12 recommends:
ii  libc6-dev  2.36-9

Versions of packages gcc-12 suggests:
ii  gcc-12-doc   12.2.0-1
pn  gcc-12-locales   
pn  gcc-12-multilib  

-- no debconf information

Bug#1035042: wpewebkit: ftbfs riscv64 Error: open CFI at the end of file; missing .cfi_endproc directive

[sun min]

Hi，

My sbuild chroot is deployed within Windows Subsystem Linux, I have 16GB 
physical memory.

Yes I suspect it is related to the memory issue and checked the 
debian/patches/reduce-memory-overheads.patch.
Besides, I also tried to modify Debian/rules  and declared  
EXTRA_CMAKE_ARGUMENTS += -DUSE_LD_GOLD=OFF, but I still failed  to build.

I think this failure  is related to my personal build env, now that the buildd 
for riscv64 can pass , this bug can be closed ,thank you!


Best wishes,
--
sun min


From: Alberto Garcia 
Sent: Tuesday, May 9, 2023 2:12
To: sun min
Cc: 1035...@bugs.debian.org
Subject: Re: Bug#1035042: wpewebkit: ftbfs riscv64 Error: open CFI at the end 
of file; missing .cfi_endproc directive

On Mon, May 01, 2023 at 05:18:39AM +, sun min wrote:
> I get the package source with below command:
> dget http://deb.debian.org/debian/pool/main/w/wpewebkit/wpewebkit_2.38.6-1.dsc

I have seen people reporting the same bug when building other projects
and it seems that this could be hardware or memory related... how much
RAM do you have to build WebKit?

Berto

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Luca Boccassi]

On Sun, 18 Sep 2022 20:52:23 -0700 Russ Allbery  wrote:
> Ansgar  writes:
> 
> > I would like to recommend packages to use tmpfiles.d(5) to manage
> > creating directories in locations such as /var or /etc instead of
> > maintainer scripts.
> 
> > It could also be used to create trivial files below /var that
should be
> > recreated if deleted by accident (such as atd's sequence number
which is
> > currently created by the maintainer script).
> 
> Hi all,
> 
> Here's where I think we currently are with this proposal:
> 
> * There should no longer be any blocker to adding a dependency on
>   systemd-tmpfiles since systemd-standalone-tmpfiles exists.
> 
> * So far as I can tell, dh_installtmpfiles adds the correct stanza to
the
>   postinst script for a service to run systemd-tmpfiles after the
package
>   has installed its tmpfiles.d fragment.  I believe that addresses
>   creating these files on installation on systems without any init
system?
>   (Obviously if tmpfs file systems are subsequently reset on such a
>   system, there is nothing in place to recreate these tmp files, but
I
>   think that's expected and not something we can address?)
> 
> * Guillem plans to add support to dpkg to register these files
properly as
>   package-associated files and also handle creation of the files. 
This is
>   great, and I am 100% in favor of it.  I don't think that blocks
this
>   change; to the contrary, I think this change is a good incremental
step
>   towards that world, since it moves temporary file creation out of
>   maintainer scripts into a declarative syntax.  dpkg can then either
>   consume the same syntax or packages can later convert that syntax
to
>   whatever dpkg uses, depending on how the dpkg implementation works,
>   which will be a simple and easy-to-detect migration that Lintian
can
>   diagnose.
> 
> Therefore, I don't see anything blocking adopting this as a policy
now,
> and it seems like an obviously good idea to me.
> 
> Am I missing something?  If not, I think the next step is for someone
to
> propose wording.

I've done an initial attempt to define the wording, although I'm sure
it will need quite a few changes. Attached as a patch, and also
available on Salsa:

https://salsa.debian.org/bluca/policy/-/commits/tmpfiles

Happy to move/reword/change/enhance as required.

> In order to handle installations that have no init system, I think we
may
> have to require that the dependency be listed as:
> 
> systemd-standalone-tmpfiles | systemd-tmpfiles
> 
> to avoid trying to install systemd into an init-free chroot.  Maybe I
have
> that wrong?  Currently, dh_installtmpfiles doesn't add a dependency
at
> all, probably because it assumes that the package will use a fallback
to
> create the files in cases without an init system?  Either way, we
should
> address this in the Policy wording, and then encode that in
> dh_installtmpfiles if needed.

For now I've kept only a mention of the 'systemd-tmpfiles' virtual
package. As maintainers we would really prefer if the 'main'
implementation is pulled in whenever possible. When a minimal
installation is desired (ie, a minbase), it is possible to manually
specify the -standalone variant.

This was a controversial point last year, see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017441

We could even decide that no dependency is added at all by dh, and
instead the build tool needs to decide if it's building an image where
tmpfiles snippets need to be ran, and if so pull in the preferred
alternative.

-- 
Kind regards,
Luca Boccassi
From  Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
Date: Tue, 9 May 2023 01:38:13 +0100
Subject: [PATCH] Define tmpfiles.d interface and usage

---
 locales/ja/LC_MESSAGES/ch-files.po|  97 --
 .../ja/LC_MESSAGES/ch-maintainerscripts.po| 293 ++
 policy/ch-files.rst   |  39 +++
 policy/ch-maintainerscripts.rst   |   6 +
 4 files changed, 288 insertions(+), 147 deletions(-)

diff --git a/locales/ja/LC_MESSAGES/ch-files.po b/locales/ja/LC_MESSAGES/ch-files.po
index c241418..ec9d329 100644
--- a/locales/ja/LC_MESSAGES/ch-files.po
+++ b/locales/ja/LC_MESSAGES/ch-files.po
@@ -10,7 +10,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: Debian Policy Manual 4.1.6.0\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2021-08-17 20:06-0700\n"
+"POT-Creation-Date: 2023-05-09 01:31+0100\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME \n"
 "Language-Team: LANGUAGE \n"
@@ -963,7 +963,60 @@ msgid ""
 " to ASCII when it is possible to do so."
 msgstr ""
 
-#: ../../ch-files.rst:726
+#: ../../ch-files.rst:728
+msgid "tmpfiles.d"
+msgstr ""
+
+#: ../../ch-files.rst:730
+msgid ""
+"Packages might need additional files or directories to implement their "
+"functionality. Directories that are located under ``/var/`` or ``/etc/``,"
+" and files that are located under ``/var/``, should not be created "

Bug#1035777: RM: gkrellmitime -- RoQA; orphaned; depends on gtk2; low popcon

[Bastian Germann]

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

Please remove gkrellmitime. The package is orphaned and its upstream is no 
longer developed.
It depends on gtk2, has a low popcon and no reverse dependencies.

Bug#1035776: RM: ebview -- RoQA; orphaned; depends on gtk2; low popcon

[Bastian Germann]

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

Please remove ebview. The package is orphaned and its upstream is no longer 
developed.
It depends on gtk2, has a low popcon and no reverse dependencies.

Bug#1035775: python-prettylog: Dead upstream?

[Stefano Rivera]

Source: python-prettylog
Version: 0.1.0-4
Severity: normal

I see no upstream git activity since 2019. And they ignored the
maintainers query about missing git tags.
https://github.com/mosquito/prettylog/issues/2

Time to think about migrating packages off it and removing it from the
archive?

Stefano

Bug#1035774: RM: dbmix -- RoQA; orphaned; RC-buggy; depends on gtk2; low popcon

[Bastian Germann]

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

Please remove dbmix. The package is orphaned, has RC bugs, and its upstream is 
no longer developed.
It depends on gtk2, has a low popcon and no reverse dependencies.

Bug#1010515: kup-backup: Incorrect homepage URL

[Diederik de Haas]

On Tuesday, 3 May 2022 11:58:49 CEST Diederik de Haas wrote:
> The package lists https://apps.kde.org/fr/kup/ as homepage, but that
> gives a 404. I guess it should be https://apps.kde.org/kbackup/.

Correction: https://apps.kde.org/kup/

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

Bug#1035772:

[Bastian Germann]

With 
https://invent.kde.org/multimedia/kmplayer/-/commit/6b01d442146d58d940a2bf919da5767867406120
(unreleased), this dependency was removed.

Bug#1035772: kmplayer: FTBFS: Could NOT find KF5 (missing: KDELibs4Support)

[Bastian Germann]

Source: kmplayer
Severity: serious
Version: 1:0.12.0b-3

Even with #997118 fixed, the build fails with:

CMake Error at 
/usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find KF5 (missing: KDELibs4Support) (found version "5.103.0")
Call Stack (most recent call first):
  /usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:600 
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/ECM/find-modules/FindKF5.cmake:93 
(find_package_handle_standard_args)
  CMakeLists.txt:30 (find_package)


-- Configuring incomplete, errors occurred!

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Mon, 08 May 2023 14:14:30 -0700 Russ Allbery  wrote:
> Guillem Jover  writes:
> > On Mon, 2023-05-08 at 08:48:49 -0700, Russ Allbery wrote:
> 
> >> […] I suspect Policy should say something stronger and more
general,
> >> namely that no package in Debian should divert a file from another
> >> package unless this is arranged cooperatively between the packages
to
> >> solve some specific (unusual) problem.
> 
> > ,--- §3.9 ---
> > You should not use "dpkg-divert" on a file belonging to another
> > package without consulting the maintainer of that package first.
When
> > adding or removing diversions, package maintainer scripts must
provide
> > the "--package" flag to "dpkg-divert" and must not use "--local".
> > `---
> 
> Oh, thank you!  I had completely forgotten that we said something
about
> this under maintainer scripts.
> 
> That doesn't entirely cover this case (because systemd and udev may
not be
> "that package" in this sense), but it covers much of the general
case.

Would you like me to reword/move the new snippet?

-- 
Kind regards,
Luca Boccassi


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

Bug#983357: How are other distros handling this ?

[zithro]

Hi all,

in an effort to solve this bug the quickest way possible, I want to 
share some pointers (and some time !).


First, it can affect not only "upstream" Debian but also Debian-based 
distros. I personaly had the problem trying to use Kali as a HVM domU. 
Although Chuck's fix worked on Kali, I dunno which distros may fail without.
But from memory, looking for solutions to the bug, I only found posts 
about Debian.


From what I read, understood, and guessed :
- it appears to be a kernel+udev+Xen bug,
- it has nothing to do with Debian itself,
- all distros using Xen are also using upstream Xen virtual KB

So I'm wondering :
- how can this bug only affect Debian and Debian-based distros but not 
others like Suse, fedora, etc ?

- If I'm right, how are other distros handling this bug ?
- How is the "Debian cloud installer" handling this bug ?
- If the problem can't be solved "at its roots", can't we just apply the 
(harmless) workaround in the installer ?


We should really speed up the fix before the Full Freeze.
I can help for testing and reporting stuff, but I'm a noob in packaging.


Thanks all, have a nice day,

zithro / Cyril REBERT


PS: off-topic remarks.
I'm a regular Debian user since a dozen years, and Debian+Xen since 5 
years, as dom0s and domUs. I recently joined the Debian Xen team.
I want to say this is one of the most critical and obscure bug -I- 
encountered on a Debian stable installer.


It's obvious but I'll state it nonetheless : it's really not a good 
"publicity" for Debian. Note I'm pointing no finger at anyone as I 
really don't care for it, I only care for a resolution.
We don't really know how much users turned their backs on Debian because 
of this bug : "Deb does not work, but distro X works, let's just use the 
one that works OOTB".

But maybe this bug is only affecting a handful of users ?

Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script

[James McCoy]

On Wed, Apr 26, 2023 at 02:50:47PM +0200, Raphael Hertzog wrote:
> Executing the script as default open action is IMO a very bad idea
> because what you get by email is largely to not be trusted so I would
> suggest that kitty be modified to not execute scripts in its URL
> launcher mode (or that it gets some interactive confirmation from the
> user before executing it).

Upstream has added support for prompting if a file is executable[0].
However, the current upstream version of kitty has rewritten all of its
kittens in go, so the changes aren't trivially backported.

For bookworm, I'm going to stop installing kitty-open.desktop, by default.
Install, I will ship it under /usr/share/doc/kitty/examples and add a
note to README.Debian about it.

[0]: 
https://github.com/kovidgoyal/kitty/commit/537cabca710f64b838d3b8b1dc986db596fb29d4

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1035771: libkf5kdelibs4support5: kcm_ssl.desktop and kcm_ssl.so files are in different packages

[Anton K.]

Package: libkf5kdelibs4support5
Version: 5.103.0-1
Severity: normal
X-Debbugs-Cc: anton.khval...@gmail.com

Dear Maintainer,

Here's the concise description of the situation (to which I found a temporal
fix, see below):
 - "SSL Preferences" entry in the System Settings does not work, reporting
"Could not load plugin from kcm_ssl: The shared library was not found"
 - kcm_ssl.so file is missing at /usr/lib/x86_64-linux-
gnu/qt5/plugins/kcm_ssl.so
 - kcm_ssl.desktop file is present (because so is the "SSL Preference" entry)

Steps to reproduce:
 - open System Settings > SSL Preferences

Observed outcome:
 - Grey area with the message "Could not load plugin from kcm_ssl: The shared
library was not found".
 - similar behavior upon executing "kcmshell5 kcm_ssl" in terminal


Intended outcome:
 - SSL Preferences displaying SSL certificates

Temporal fix:
 - install recommended libkf5kdelibs4support5-bin package.


It seems like libkf5kdelibs4support5 is not packaged properly. It recommends
libkf5kdelibs4support5-bin, but this latter package is required for certain
entries in the system settings to work (as SSL certificates in my case), as it
provides *.so files. However, the *.desktop files for those entries are already
contained in some other package.

Sincerely yours,
Anton


-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libkf5kdelibs4support5 depends on:
ii  kio 5.103.0-1
ii  libc6   2.36-9
ii  libice6 2:1.0.10-1
ii  libkf5auth5 5.103.0-1
ii  libkf5codecs5   5.103.0-1
ii  libkf5completion5   5.103.0-1
ii  libkf5configcore5   5.103.0-2
ii  libkf5configgui55.103.0-2
ii  libkf5configwidgets55.103.0-1
ii  libkf5coreaddons5   5.103.0-1
ii  libkf5crash55.103.0-1
ii  libkf5globalaccel-bin   5.103.0-1
ii  libkf5globalaccel5  5.103.0-1
ii  libkf5guiaddons55.103.0-1
ii  libkf5i18n5 5.103.0-1
ii  libkf5iconthemes5   5.103.0-1
ii  libkf5jobwidgets5   5.103.0-1
ii  libkf5kdelibs4support-data  5.103.0-1
ii  libkf5kiocore5  5.103.0-1
ii  libkf5kiofilewidgets5   5.103.0-1
ii  libkf5kiowidgets5   5.103.0-1
ii  libkf5notifications55.103.0-1
ii  libkf5parts55.103.0-1
ii  libkf5service-bin   5.103.0-1
ii  libkf5service5  5.103.0-1
ii  libkf5solid55.103.0-1
ii  libkf5textwidgets5  5.103.0-1
ii  libkf5widgetsaddons55.103.0-1
ii  libkf5windowsystem5 5.103.0-1
ii  libkf5xmlgui5   5.103.0-1
ii  libqt5core5a5.15.8+dfsg-7
ii  libqt5dbus5 5.15.8+dfsg-7
ii  libqt5gui5  5.15.8+dfsg-7
ii  libqt5network5  5.15.8+dfsg-7
ii  libqt5printsupport5 5.15.8+dfsg-7
ii  libqt5svg5  5.15.8-2
ii  libqt5widgets5  5.15.8+dfsg-7
ii  libqt5x11extras55.15.8-2
ii  libsm6  2:1.2.3-1
ii  libstdc++6  12.2.0-14
ii  libx11-62:1.8.4-2
ii  libxcb1 1.15-1

Versions of packages libkf5kdelibs4support5 recommends:
ii  libkf5kdelibs4support5-bin  5.103.0-1

libkf5kdelibs4support5 suggests no packages.

-- no debconf information

Bug#1004844: games-finest: Consider adding endless-sky

[Dave Vasilevsky]

Makes sense! That's being worked on in bug 944757

On Sat, May 6, 2023 at 5:52 PM Markus Koschany  wrote:

> Hi,
>
> thanks for the suggestion!
>
> On Wed, 02 Feb 2022 03:58:43 -0500 Dave Vasilevsky 
> wrote:
> > Package: games-finest
> > Version: 4
> > Severity: wishlist
> > X-Debbugs-Cc: d...@vasilevsky.ca
> >
> > Hi,
> >
> > Thanks for all your work maintaining debian-games.
> >
> > It's been a few years since we've added anything new to games-finest,
> and I
> > think endless-sky would be a great choice.
>
> [...]
>
> endless-sky looks really good and seems to be a fun game. However there
> haven't
> been any Debian uploads from the maintainer in almost six years and
> several new
> versions of endless-sky have been released since then. If we can fix this
> situation, then I would include it in games-finest. At the moment that
> would be
> premature.
>
> Regards,
>
> Markus
>

Bug#1033953: unblock: gimp-help/2.10.34-1

[Jordi Mallach]

Hi Paul,

El dl. 08 de 05 de 2023 a les 22:12 +0200, en/na Paul Gevers va
escriure:
> Control: tags -1 confirmed moreinfo
> 
> Hi Jordi
> 
> On 04-05-2023 14:02, Jordi Mallach wrote:
> > I honestly thought you were more interested in the packaging
> > changes
> > than the upstream diff, sorry.
> 
> Understood, but we always ask for the full debdiff (which you can
> filter 
> if you tell us which filter you applied and why).

Yeah, sorry, I should have done this from the beginning, but it was
such a long diff that it didn't sound entirely reasonable. ️

> 
> > The diff is huge because there are a lot of new translations, and
> > many
> > documentation additions. As I said in my original message, this
> > documentation update was due years ago and it finally captures the
> > real
> > state of the GIMP version we shipped in bullseye and will ship in
> > bookworm.
> 
> That's what I suspected yes.
> 
> As this is a documentation only source package, you can go ahead.
> Please 
> remove the moreinfo tag once it happens and don't wait too long
> please.

Thank you,

The package is now uploaded (2.10.34-2).


Jordi
-- 
Jordi Mallach 
Debian Project

Bug#1035650: elpa-org version older than built-in Org in bookworm

[Nicholas D Steeves]

tldr: Dear team, are there any objections to making a team upload using
the dummy package approach?  It's what at least two users want, and it
guards against harming relations with upstream Emacs.  The existing
state of things is between useless, embarrassing, and harmful, so let's
fix this.

Sean Whitton  writes:

> Hello,
>
> On Sun 07 May 2023 at 04:42PM -04, Nicholas D Steeves wrote:
>
>> Is there a practical argument against adding versioned Provides to
>> either emacs-common or emacs-el (as appropriate)?  Something like
>>
> I believe that changes of this nature are not appropriate at this stage
> of the freeze.  I wish we had done something about this sooner, but
> elpa-org is undermaintained.
>

With a potential harm argument ("not appropriate"), shouldn't one also
consider the social cost of doing nothing?  With users, as well as to
our rapport with upstream?  See below.

> I don't think we should kick it out, because having a slightly older Org
> seems less bad than also kicking out the rdeps, on balance.
>

Another way of articulating the problem:

(without elpa-org installed) M-x org-version
  Org mode version 9.5.5 (release_9.5.5 @ /usr/share/emacs/28.2/lisp/org/)

(with elpa-org installed) M-x org-version
  Org mode version 9.5.2 (9.5.2 @ /usr/share/emacs/site-lisp/elpa/org-9.5.2/)

Elpa-org shadows the built-in copy.  9.5.3's bug fixes appear to
indicate that 9.5.2 may be unusable for users of Org's
bibliography-related functions, and of course there are a number of
other bug fixes between 9.5.2 and 9.5.5.  Is it really conscionable to
/disable/ bug fixes that Emacs 25 provides in built-in Org-mode?  Is it
really conscionable to do this to upstream?  When we ask them to
accommodate us for native-comp-related things, shouldn't we also
demonstrate that we support their work in other areas of Emacs?

All users who have elpa-org installed in bullseye will be affected when
upgrading, as well as all elpa-org-contrib users.  Release notes can
advise the former to remove elpa-org, but we shouldn't advise
elpa-org-contrib users to use 'equivs' to make emacs Provide a virtual
elpa-org.

Maxim Nikulin  writes:

> On 07/05/2023 20:34, David Bremner wrote:
>> Maxim Nikulin writes:
>
> I am against *removing* elpa-org from bookworm. I have a hope that it is 
> possible to submit *empty* elpa-org package and it still can be accepted 
> to bookworm. No dependencies will be broken, users will get a few more 
> fixes from built-in Org shipped in emacs-el. If a newer Org appear later 
> in next Debian releases (or in backports) users will get it.
>

You're describing the "dummy package" approach.  I was advocating for
the "virtual package" approach (with version-qualified Provides <- this
is key), but yes, either approach works :) Some people find empty
packages ugly/cruft so I prefer to avoid them when possible, but it
sounds like this isn't consensus for this approach at this time.  Thus,
yes, now I agree with you!

> Almost unrelated to bookworm (and so having less priority) issue: coming 
> Emacs-29 will have built-in Org-9.6 and difference between versions will 
> be substantial. Benefits of empty elpa-org in comparison to outdated Org 
> will be more important.
>

Agreed!

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1035770: RM: gerstensaft -- RoQA; orphaned; depends on gtk2; low popcon

[Bastian Germann]

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

Please remove gerstensaft. The package is orphaned and its upstream is no 
longer developed.
It depends on gtk2, has a low popcon and no reverse dependencies.

Bug#1035769: unblock: kernel-handbook/1.0.21

[Ben Hutchings]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: kernel-handb...@packages.debian.org, 
debian-ker...@lists.debian.org
Control: affects -1 + src:kernel-handbook

Please unblock package kernel-handbook

[ Reason ]
The current debian-kernel-handbook package has some outdated and
confusing information and instructions that cause people to waste time
when trying to rebuild linux source packages.

[ Impact ]
Wasting users' time and computing resources.

[ Tests ]
This package contains documentation in HTML pages.  I have re-read
them and tested the new instructions.

[ Risks ]
This package contains documentation in HTML pages.  If the new
instructions are wrong, that would also waste resources.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]

unblock kernel-handbook/1.0.21
diff -Nru kernel-handbook-1.0.20/chapter-common-tasks.dbk 
kernel-handbook-1.0.21/chapter-common-tasks.dbk
--- kernel-handbook-1.0.20/chapter-common-tasks.dbk 2022-07-18 
19:37:14.0 +0200
+++ kernel-handbook-1.0.21/chapter-common-tasks.dbk 2023-05-08 
23:05:29.0 +0200
@@ -5,8 +5,7 @@
 Common kernel-related tasks
 Obtaining the Debian kernel 
source
 
-To get the Debian kernel source at the current maximum patchlevel, it is
-sufficient to install the latest
+To get the Debian kernel source, it is sufficient to install the latest
 linux-source-version package and 
unpack
 the source, for example:
 
@@ -20,18 +19,266 @@
 
 
 
+Building a custom kernel from Debian 
kernel source
+
+This section describes the simplest possible procedure to build a custom kernel
+the "Debian way".  It is assumed that user is somewhat familiar with kernel
+configuration and build process.  If that's not the case, it is recommended to
+consult the kernel documentation and many excellent online resources dedicated
+to it.
+
+
+The easiest way to build a custom kernel (the kernel with the configuration
+different from the one used in the official packages) from the Debian kernel
+source is to use the linux-source package and the
+make bindeb-pkg target.  First, prepare the kernel tree:
+
+
+# apt-get install linux-source-4.3
+$ tar xaf 
/usr/src/linux-source-4.3.tar.xz
+$ cd linux-source-4.3
+
+
+The kernel now needs to be configured, that is you have to set the kernel
+options and select the drivers which are going to be included, either as
+built-in, or as external modules.
+
+
+It is possible to reuse an old configuration file by placing it as a
+.config file in the top-level directory.
+Alternately, you can use the default configuration for the
+architecture (make defconfig) or generate a
+configuration based on the running kernel and the currently loaded
+modules (make localmodconfig).
+
+
+If you reuse a Debian kernel config file, you may need to disable
+module signing (scripts/config --disable
+MODULE_SIG) or enable signing with an ephemeral key
+(scripts/config --set-str MODULE_SIG_KEY
+certs/signing_key.pem).  The build will use less time and
+disk space (see ) if debug information
+is disabled (scripts/config --disable DEBUG_INFO).
+Debuginfo is only needed if you plan to use binary object tools like
+crash, kgdb, and SystemTap on the kernel.
+
+
+The kernel build infrastructure offers a number of targets, which
+invoke different configuration frontends.  For example, one can use
+console-based menu configuration by invoking the command
+
+
+$ make nconfig
+
+
+Instead of nconfig one can use oldconfig
+(text-based line-by-line configuration frontend) or xconfig
+(graphical configuration frontend).  Note that different frontends may require 
different additional
+libraries and utilities to be installed to function properly.  For example, the
+nconfig frontend requires the ncurses
+library, which is provided by the libncurses-dev package.
+
+
+After the configuration process is finished, the new or updated kernel
+configuration will be stored in .config file in the
+top-level directory.  The build is started using the commands
+
+
+$ make clean
+$ make bindeb-pkg
+
+
+As a result of the build, a custom kernel package
+linux-image-3.2.19_3.2.19-1_i386.deb (name will reflect 
the
+version of the kernel and build number) will be created in the directory one
+level above the top of the tree.  It may be installed using
+dpkg just as any other package:
+
+
+# dpkg -i 
../linux-image-3.2.19_3.2.19-1_i386.deb
+
+
+This command will unpack the kernel, generate the initrd if necessary (see
+ for details), and configure the bootloader to 
make
+the newly installed kernel the default one.  If this command completed without
+any problems, you can reboot using the
+
+
+# shutdown -r now
+
+
+command to boot the new kernel.
+
+
+For much more information about bootloaders and their configuration please
+check their documentation.  For GRUB this 

Bug#995854: freebirth: crashes at startup

[Bastian Germann]

Control: severity -1 grave

I can confirm this. This makes the package unusable.

Bug#1000029: PCRE to PCRE2 migration

[Daniel Spiljar]

On Sat, 2023-05-06 at 14:21 +0530, Abhijith PA wrote:
> Hello Daniel,
> 
> As you might know, pcre project is obselete now[1]. pcre will not fix 
> any bugs or do release in future. projects are moved to pcre2[2].
> 
> I was wondering mboxgrep have any plans to port migrate to pcre2.
> 
> Regards
> Abhijith
> 
> [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=129
> [2] - https://php.watch/versions/7.3/pcre2

Hello Abhijith,

I knew pcre was obsolete, but wasn't aware of that not even bugfixes
are made.

Thank you for the heads-up! I added this to the TODO list, and will
inform you as soon as I'm done with porting.

Best regards,
Daniel

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Russ Allbery]

Guillem Jover  writes:
> On Mon, 2023-05-08 at 08:48:49 -0700, Russ Allbery wrote:

>> […] I suspect Policy should say something stronger and more general,
>> namely that no package in Debian should divert a file from another
>> package unless this is arranged cooperatively between the packages to
>> solve some specific (unusual) problem.

> ,--- §3.9 ---
> You should not use "dpkg-divert" on a file belonging to another
> package without consulting the maintainer of that package first. When
> adding or removing diversions, package maintainer scripts must provide
> the "--package" flag to "dpkg-divert" and must not use "--local".
> `---

Oh, thank you!  I had completely forgotten that we said something about
this under maintainer scripts.

That doesn't entirely cover this case (because systemd and udev may not be
"that package" in this sense), but it covers much of the general case.

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

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Guillem Jover]

On Mon, 2023-05-08 at 08:48:49 -0700, Russ Allbery wrote:
> […] I suspect Policy should say something stronger and more general,
> namely that no package in Debian should divert a file from another package
> unless this is arranged cooperatively between the packages to solve some
> specific (unusual) problem.

,--- §3.9 ---
You should not use "dpkg-divert" on a file belonging to another
package without consulting the maintainer of that package first. When
adding or removing diversions, package maintainer scripts must provide
the "--package" flag to "dpkg-divert" and must not use "--local".
`---

> To me, this feels similar to the case of one
> package modifying the configuration files of another package, where we
> explicitly prohibit one package modifying the configuration of another
> package except through an interface provided by the package whose
> configuration is being modified.

,--- §10.7.4 ---
If the configuration file cannot be shared as described above, the
packages must be marked as conflicting with each other. Two packages
that specify the same file as a "conffile" must conflict. This is an
instance of the general rule about not sharing files. Neither
alternatives nor diversions are likely to be appropriate in this case;
in particular, "dpkg" does not handle diverted "conffile"s well.
`---

Regards,
Guillem

Bug#940960: ITP: linenoise -- Minimal replacement for readline

[Jeremy Sowden]

On 2023-05-01, at 04:09:16 +0800, Blair Noctis wrote:
> It's been a few years since this ITP was filed. Do you still plan to
> package it?  I'm packaging osquery which depends on this. Happy to
> help ;)

Thanks for the offer. :) I've cloned the osquery repo and it appears to
use the C++ Linenoise NG fork:

  https://github.com/arangodb/linenoise-ng

not the C original:

  https://github.com/antirez/linenoise

which is what I started packaging.  The reason that I stopped work on it
was that linenoise is intended to be used by adding the sources to the
code-base of the application that wants the functionality.  I created a
PR to add support for building it as a shared library:

  https://github.com/antirez/linenoise/pull/174

and there has been no response (mind you, there are a lot of open PR's
going back years), so I wasn't sure whether it was worth adding to
Debian.

I've had a quick look at the linenoise-ng repo and it appears to be
API-compatible with the original and has a [c]make file, so it may be a
better candidate for packaging -- particularly now that you have
provided a use-case for it.  I'll take a closer look and see how much of
my work can be salvaged.

J.


signature.asc
Description: PGP signature

Bug#1035767: gxmms2: Non-working maintainer address

[Bastian Germann]

Source: gxmms2
Version: 0.7.1-3
Severity: serious
Justification: Policy 3.3
X-Debbugs-Cc: bdr...@debian.org
X-Debbugs-Cc: and...@0x63.nu

Mail delivery failed: returning message to sender

This message was created automatically by mail delivery software.

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

  r...@debian.org
Unrouteable address


Reporting-MTA: dns; mitropoulos.debian.org

Action: failed
Final-Recipient: rfc822;r...@debian.org
Status: 5.0.0

Bug#1035766: {sse3,sse4.2}-support: copyright file missing after upgrade (policy 12.5)

[Andreas Beckmann]

Package: sse4.2-support,sse3-support
Version: 15
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

a test with piuparts revealed that your package misses the copyright
file after an upgrade, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.

This was observed on the following upgrade paths:

  bullseye -> bookworm

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

0m42.0s ERROR: WARN: Inadequate results from running adequate!
  sse4.2-support: missing-copyright-file /usr/share/doc/sse4.2-support/copyright

  MISSING COPYRIGHT FILE: /usr/share/doc/sse4.2-support/copyright
  # ls -lad /usr/share/doc/sse4.2-support
  drwxr-xr-x 2 root root 40 May  3 12:07 /usr/share/doc/sse4.2-support
  # ls -la /usr/share/doc/sse4.2-support/
  total 0
  drwxr-xr-x   2 root root   40 May  3 12:07 .
  drwxr-xr-x 113 root root 2300 May  3 12:07 ..

0m39.1s ERROR: WARN: Inadequate results from running adequate!
  sse3-support: missing-copyright-file /usr/share/doc/sse3-support/copyright

  MISSING COPYRIGHT FILE: /usr/share/doc/sse3-support/copyright
  # ls -lad /usr/share/doc/sse3-support
  drwxr-xr-x 2 root root 40 May  3 13:55 /usr/share/doc/sse3-support
  # ls -la /usr/share/doc/sse3-support/
  total 0
  drwxr-xr-x   2 root root   40 May  3 13:55 .
  drwxr-xr-x 113 root root 2300 May  3 13:55 ..


Additional info may be available here:
https://wiki.debian.org/MissingCopyrightFile

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


cheers,

Andreas


sse4.2-support_15.log.gz
Description: application/gzip

Bug#1035765: python-rlp-doc: copyright file missing after upgrade (policy 12.5)

[Andreas Beckmann]

Package: python-rlp-doc
Version: 0.5.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

a test with piuparts revealed that your package misses the copyright
file after an upgrade, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.

This was observed on the following upgrade paths:

  bullseye -> bookworm

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

0m46.7s ERROR: WARN: Inadequate results from running adequate!
  python-rlp-doc: missing-copyright-file /usr/share/doc/python-rlp-doc/copyright

  MISSING COPYRIGHT FILE: /usr/share/doc/python-rlp-doc/copyright
  # ls -lad /usr/share/doc/python-rlp-doc
  drwxr-xr-x 2 root root 40 May  3 13:13 /usr/share/doc/python-rlp-doc
  # ls -la /usr/share/doc/python-rlp-doc/
  total 0
  drwxr-xr-x   2 root root   40 May  3 13:13 .
  drwxr-xr-x 127 root root 2620 May  3 13:13 ..


Additional info may be available here:
https://wiki.debian.org/MissingCopyrightFile

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


cheers,

Andreas


python-rlp-doc_0.5.1-3.log.gz
Description: application/gzip

Bug#1035764: libtsm-dev: copyright file missing after upgrade (policy 12.5)

[Andreas Beckmann]

Package: libtsm-dev
Version: 4.0.2-0.3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

a test with piuparts revealed that your package misses the copyright
file after an upgrade, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.

This was observed on the following upgrade paths:

  bullseye -> bookworm

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

  MISSING COPYRIGHT FILE: /usr/share/doc/libtsm-dev/copyright
  # ls -lad /usr/share/doc/libtsm-dev
  drwxr-xr-x 2 root root 40 May  3 14:43 /usr/share/doc/libtsm-dev
  # ls -la /usr/share/doc/libtsm-dev/
  total 0
  drwxr-xr-x   2 root root   40 May  3 14:43 .
  drwxr-xr-x 114 root root 2320 May  3 14:43 ..


Additional info may be available here:
https://wiki.debian.org/MissingCopyrightFile

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


cheers,

Andreas


libtsm-dev_4.0.2-0.3.log.gz
Description: application/gzip

Bug#967516: gxmms2: depends on deprecated GTK 2

[Bastian Germann]

There was a steady decline of gxmms2 usage.
xmms2 will not be part of bookworm, so this might be a good time to get rid of 
gxmms2.

Bug#1035094: udev: /dev/serial/by-id/ symlinks not created anymore for USB devices

[Antoine Sirinelli]

I was affected by the same bug after a Bullseye update to version 11.7:
no more /dev/serial/by-id/* symlinks.

I confirm that the fix in https://github.com/systemd/systemd/pull/25246
solved the issue.

Antoine


On Sat, Apr 29, 2023 at 03:50:43PM +0200, Felix Geyer wrote:
> Package: udev
> Version: 247.3-7+deb11u2
> Tags: bullseye
> 
> Since udev 247.3-7+deb11u2 /dev/serial/by-id/* symlinks are not created
> anymore for USB serial devices.
> This is a regression from backporting 
> udev-always-create-device-symlinks-for-USB-disks.patch
> 
> It was fixed upstream by https://github.com/systemd/systemd/pull/25246
> 
> The diff doesn't apply cleanly because we don't have
> https://github.com/systemd/systemd-stable/commit/451ba55fecd8b494add2001b3ca3c1915c8fd655
> 
> Apply this commit and the PR fixes the issue for me.
> 
> Felix
> 


signature.asc
Description: PGP signature

Bug#1035704: proj: reproducible-builds: timezone-dependent timestamps in .gsb/.gtx files

[Vagrant Cascadian]

On 2023-05-08, Sebastiaan Couwenberg wrote:
> On 5/8/23 02:07, Vagrant Cascadian wrote:
>> The attached patch fixes this by not touching these files during the
>> build process.
>
>  From shar(1):
>
> "
>-m, --no-timestamp
>   do not restore modification times.
>
>   Avoid generating 'touch' commands to restore the file
>   modification dates when unpacking files from the archive.
>
>   When file modification times are not preserved, project build
>   programs like "make" will see built files older than the files
>   they get built from.  This is why, when this option is not
>   used, a special effort is made to restore timestamps.
> "
>
> That should be used when generating the archives instead of your patch 
> to not have the mtimes touched when unpacking the archives.

Is it actually a problem to allow dpkg to normalize the timestamps on
these files rather than forcefully setting them to ... a value from a
shar archive? It is perhaps a naive question; I really do not know.


> But the diffoscope-results only show a few of the files from the shar 
> archives with different mtimes, and all of them get touched when 
> unpacking the archive just before the configure target is executed.

Well, I too was perplexed why other files were not affected, but it is
consistently those .gsb and .gtx files, and the submitted patch allows
to consistently build reproducibly in the dozens of times I've build
it...


> shar actually makes the timestamps reproducible by always using the 
> mtime recorded in the archive instead of the time the files were unpacked.
>
> Something else is likely changing the mtime after the files are 
> unpacked. Some of these grids are used by the testsuite for example.

I will try to look into it further, but without really being familiar
with the proj codebase (or even what proj itself does)... any additional
very specific suggestions where to look next would definitely be
appreciated!  :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1035383: unblock (pre-approval): brial/1.2.11-2.1

[Paul Gevers]

Control: tags -1 confirmed moreinfo

Hi,

[I was hoping another Release Team member would shim in, but alas. 
Please read till the end.]


On 02-05-2023 16:11, plugwash wrote:

Elbrus replied to my bug report, challangeing why I had filed it as rc, I
explained my position and he seemed somewhat but not totally convinced.


Although I agree with you on the normal approach, I explicitly note here 
that this source builds *multiple* arch specific binaries and only one 
fails to install on several architectures where it builds fine. Manually 
maintaining a list of architectures is a PITA.



I would like to ask for a release team ruling on this bug. If the release agree
it is rc and should be fixed, I am happy to make an upload doing so. On the
other hand if the release team decide that it is not rc and should not be fixed
at this stage in the release process I'm happy to abide by that descision.


I think we have a way forward, because it's claimed that the binary 
python3-brial should be removed in the not too distant future, so this 
architecture hard-coding is a temporary solution. (However, there are 
two reverse dependencies of the package, so that will need to be solved 
in trixie). Having said that, I want to hear other opinions for the 
general case.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable

[Paul Gevers]

Hi Tobias,

On Sat,  6 May 2023 10:24:41 + Tobias Hansen  wrote:


Note that we could also just remove python3-sage and the autopkgtest.


I assume you mean python3-brial here.


Nothing in Debian depends on it


Not true (and it's too late in the freeze to do that [1]):
paul@mulciber ~ $ reverse-depends python3-brial
Reverse-Recommends
==
* science-mathematics-dev
* singular-data

Paul
PS: please cc me on reply, I'm not subscribed to this bug.

[1] https://release.debian.org/testing/freeze_policy.html#appropriate


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035094: udev: /dev/serial/by-id/ symlinks not created anymore for USB devices

[Kevin Hilman]

I think it's the same root cause, but I also noticed that the
ID_SERIAL_SHORT attribute has disappeared from `udevadm info` for USB
serial adapters.   ID_USB_SERIAL_SHORT is present, but ID_SERIAL_SHORT
is gone, which has broken some udev rules which use ID_SERIAL_SHORT
for matching.

Bug#1035085: Bookworm RC2 grub-installer/os-prober quirks

[Pascal Hambourg]

On 29/04/2023 at 11:22, I wrote:
1) In expert install (or low priority), the new os-prober dialog 
displayed by grub-installer lists only unsupported OS but not supported OS.

(Patch attached)

2) "efi" os-prober type is considered unsupported.
In EFI mode, os-prober detects EFI boot loaders such as Windows Boot 
Manager with type "efi". GRUB can add menu entries for these boot 
loaders so this type should be in the supported list instead of the 
unsupported list. (AFAICS it does not matter much because the supported 
OS list is used only when installing GRUB for legacy boot and not EFI 
boot.)

(Patch attached)


Another one:

If the installer was booted in EFI mode but detected existing operating 
systems already installed using "BIOS compatibility mode" and the user 
chose to not force UEFI installation, update-grub executed in the target 
chroot still behaves in EFI mode: it detects and adds entries for EFI 
boot loaders  and UEFI firmware settings to the GRUB menu and ignores 
legacy boot loaders. It should do the opposite, even though running 
update-grub again after booting the installed system will fix the GRUB menu.

(Patch attached)

I tested the 3 patches together with BIOS boot, EFI boot + installation, 
EFI boot + BIOS installation.From 5adc3dd8bf3118f40018bc3447a9f60684f1343e Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Sun, 30 Apr 2023 09:06:52 +0200
Subject: [PATCH 3/3] Do no run EFI probes in target chroot if ignore_uefi is
 set

If partman-efi set /var/lib/partman/ignore_uefi, we do not want
os-prober to skip legacy probes and perform EFI probes, so create
ignore_uefi in /target. We also do not want grub 30_uefi-firmware
to probe UEFI firmware settings, so do not mount efivarfs (only
needed when installing grub-efi).
---
 debian/postinst | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/debian/postinst b/debian/postinst
index 85714195..1ff3f851 100755
--- a/debian/postinst
+++ b/debian/postinst
@@ -43,6 +43,16 @@ mountvirtfs () {
 # target. Maybe /proc too?
 mountvirtfs proc /target/proc
 mountvirtfs sysfs /target/sys
-mountvirtfs efivarfs /target/sys/firmware/efi/efivars
+
+if [ -e /var/lib/partman/ignore_uefi ]; then
+	# prevent os-prober EFI probes in target chroot
+	mkdir -p /target/var/lib/partman
+	touch /target/var/lib/partman/ignore_uefi
+else
+	mountvirtfs efivarfs /target/sys/firmware/efi/efivars
+fi
 
 grub-installer /target
+
+rm -f /target/var/lib/partman/ignore_uefi
+rmdir /target/var/lib/partman 2>/dev/null || true
-- 
2.30.2

Bug#1033953: unblock: gimp-help/2.10.34-1

[Paul Gevers]

Control: tags -1 confirmed moreinfo

Hi Jordi

On 04-05-2023 14:02, Jordi Mallach wrote:

I honestly thought you were more interested in the packaging changes
than the upstream diff, sorry.


Understood, but we always ask for the full debdiff (which you can filter 
if you tell us which filter you applied and why).



The diff is huge because there are a lot of new translations, and many
documentation additions. As I said in my original message, this
documentation update was due years ago and it finally captures the real
state of the GIMP version we shipped in bullseye and will ship in
bookworm.


That's what I suspected yes.

As this is a documentation only source package, you can go ahead. Please 
remove the moreinfo tag once it happens and don't wait too long please.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035761: grub2: French translation

[Baptiste Jammet]

Package: grub2
Version: N/A
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the french debconf template translation, 
proofread by the debian-l10n-french mailing list contributors.

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

Thanks for maintaining grub2.

Baptiste


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

Kernel: Linux 5.10.0-21-amd64 (SMP w/2 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
# translation of fr.po to French
# Translation of grub2 debconf templates to French
# Copyright (C) 2008-2010 Debian French l10n 

# This file is distributed under the same license as the grub2 package.
#
# Christian Perrier , 2007, 2008, 2009, 2010, 2011, 2014.
# Baptiste Jammet , 2017, 2023.
msgid ""
msgstr ""
"Project-Id-Version: fr\n"
"Report-Msgid-Bugs-To: gr...@packages.debian.org\n"
"POT-Creation-Date: 2023-04-23 20:27+\n"
"PO-Revision-Date: 2023-04-26 19:30+0200\n"
"Last-Translator: Baptiste Jammet \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 20.12.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid "Chainload from menu.lst?"
msgstr "Faut-il enchaîner le chargement depuis menu.lst ?"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid "GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub."
msgstr "Une installation ancienne de GRUB a été détectée dans /boot/grub."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"In order to replace the Legacy version of GRUB in your system, it is "
"recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image "
"from your existing GRUB Legacy setup. This step can be automatically "
"performed now."
msgstr ""
"Afin de remplacer cette installation, il est recommandé de modifier /boot/"
"grub/menu.lst pour charger GRUB 2 depuis l'installation standard de GRUB "
"(« chainload »). Veuillez choisir si vous souhaitez effectuer cette "
"modification."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"It's recommended that you accept chainloading GRUB 2 from menu.lst, and "
"verify that the new GRUB 2 setup works before it is written to the MBR "
"(Master Boot Record)."
msgstr ""
"Il est recommandé de choisir cette option pour pouvoir confirmer le bon "
"fonctionnement de GRUB 2 avant de l'installer directement sur le secteur "
"d'amorçage (MBR : « Master Boot Record »)."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"Whatever your decision, you can replace the old MBR image with GRUB 2 later "
"by issuing the following command as root:"
msgstr ""
"Quel que soit votre choix, vous pourrez, plus tard, remplacer l'ancien "
"secteur d'amorçage par GRUB 2 avec la commande suivante, exécutée avec les "
"privilèges du superutilisateur :"

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid "GRUB install devices:"
msgstr "Périphériques sur lesquels installer GRUB :"

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid ""
"The grub-pc package is being upgraded. This menu allows you to select which "
"devices you'd like grub-install to be automatically run for, if any."
msgstr ""
"Le paquet grub-pc est en cours de mise à jour. Ce menu permet de choisir "
"pour quels périphériques vous souhaitez exécuter la commande grub-install "
"automatiquement."

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid ""
"Running grub-install automatically is recommended in most situations, to "
"prevent the installed GRUB core image from getting out of sync with GRUB "
"modules or grub.cfg."
msgstr ""
"Il est en général recommandé d'exécuter grub-install automatiquement, afin "
"d'éviter la situation où l'image de GRUB est désynchronisée avec les modules "
"de GRUB ou le fichier grub.cfg."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid ""
"If you're unsure which drive is designated as boot drive by your BIOS, it is "
"often a good idea to install GRUB to all of them."
msgstr ""
"Si vous n'avez pas la certitude du périphérique utilisé comme périphérique "
"d'amorçage par le BIOS, il est en général conseillé d'installer GRUB sur "
"l'ensemble des périphériques."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid ""
"Note: it is possible to 

Bug#1035760: ITP: rshim-user-space -- Userspace (fuse) host driver for Mellanox BlueField devices

[dann frazier]

Package: wnpp
Severity: wishlist
Owner: dann frazier 
X-Debbugs-Cc: debian-de...@lists.debian.org, Liming Sun , 
Taihsiang Ho 

* Package name: rshim-user-space
  Version : 2.0.7
  Upstream Contact: Mellanox Technologies 
* URL : https://github.com/Mellanox/rshim-user-space
* License : GPL
  Programming Lang: C
  Description : Userspace (fuse) host driver for Mellanox BlueField devices

This is a userspace driver that provides host access to BlueField PCIe
devices. It can be used to push boot streams (usually to flash a new OS
image), access a virtual console, provide a virtual network interface
connecting the BlueField device and its host, and a debug interface.

I work with BlueField PCIe devices as part of my day job. These devices run
a full Linux distribution, and this driver is required to manage them from
the host OS. I plan to maintain it as part of a small (1-3) person team,
where I will likely be the only member who is a DD. We plan to use salsa
for hosting.

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Russ Allbery]

Sean Whitton  writes:
> On Mon 08 May 2023 at 08:48AM -07, Russ Allbery wrote:

>> In other words, dpkg-divert is primarily for local administrators,
>> non-Policy-compliant local packages that are doing unusual things, and
>> the occasional rare problem that requires special coordination between
>> packages, not something that Debian packages should be doing to other
>> packages without explicit coordination.

>> The rule about systemd and udev files doesn't entirely fall out of that
>> statement,

> Hmm, could you explain why?

It didn't fall out of the above statement because the systemd unit file
may not be shipped with the systemd package, but by some other random
package, so you could have an explicit coordination with the package that
provides the unit file but still be doing something that the systemd
maintainers don't want to support.

I think it does fall out of the somewhat squishier statement that you
shouldn't use diversions when there's some other available mechanism to
accomplish the same goal.

> I don't mean to dismiss the significant impact on the systemd
> maintainers that's being claimed, but specifically calling out udev and
> systemd configuration files seems strangely specific, for Policy, to me.

I think they're a special case of the general rule that if there's some
mechanism other than diversions to do what you want, you should use it
instead, but it's such a common special case that we should call it out
explicitly, particularly since a lot of people right now don't seem to
know about masking or drop-ins.  So in other words, I think I basically
agree with this, but I think it's worth spending some words on systemd and
udev, more as a communication strategy than anything else.

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

Bug#1035024: unblock: nvidia-cudnn/8.7.0.84~cuda11.8+1 (pre-approval)

[Paul Gevers]

Hi Mo,

On 08-05-2023 00:55, M. Zhou wrote:

On Sun, 2023-05-07 at 22:03 +0200, Paul Gevers wrote:

On 27-04-2023 21:31, M. Zhou wrote:

4. debconf template default choice is changed to "I Agree".
  This package is in non-free section. Only by setting the debconf default 
choice
  to "I Agree", can we correctly build pytorch-cuda in sbuild without the 
cuDNN
  libraries not downloaded but the bin:nvidia-cudnn package installed.


Are we legally allowed to do this? If so, why even ask the question?


According to the upstream license and the package content, the URL points
to a distributable tarball depending on the user's agreement.
The debconf questions shows the full license texts and asks the
user whether to accept the terms. These terms, was deemed problematic
by ftp-masters if we directly upload the binary blobs into the archive.


I may not have phrased my question correctly. What I mean is that if a 
user installs the package in a non-interactive way, do you believe they 
agreed with the license? If not, is it OK to install the package even if 
the user didn't agree with it? If the answer is, the user must accept 
the license, then I believe that the default can't be to accept it. If 
it's acceptable to install without the user seeing the license and 
accepting it, then why even ask the question?



At least, building the reverse dependency pytorch-cuda via sbuild, where
the binary blobs will be pulled and linked against, is legal according to
the license. Uploading the binary form of pytorch-cuda is ok as well.


That's nice already.


Other binary distributions like ArchLinux, Anaconda, and even PyTorch
upstream have been redistributing the cuDNN binaries for years though.


I have no idea if and how they would ask for license agreements.


Although I hate dealing with annoying non-free license texts, I think
it not safe to remove the debconf question prompt, because the license
seems to pose even more restrictions than its dependency CUDA devkit.


I conclude from this part that it's NOT ok to skip the debconf question 
which is what happens if the user runs the install with non-interactive 
debconf.



PS wasn't an autopkgtest feasible such that this didn't need to be on
our radar? (too late for that now, but still)


It looks like I have to refresh my memory, I thought autopkgtest won't
be run for non-free packages.


Right. It was recently pointed out to me that the ci.d.n infrastructure 
failed to support that (always, or since last year), but the migration 
software of the Release Team always has supported it. That was a bug, 
not by design. It's fixed now.



Writing the test scripts are easy, but I think
that's not needed if I can get a manual removal or refusal.


Indeed, because we're too close to the full freeze to help you; you'll 
need an unblock anyways.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035759: RFA: sniproxy -- Transparent TLS and HTTP layer 4 proxy with SNI support

[Jan Dittberner]

Package: wnpp
Severity: normal
X-Debbugs-Cc: snipr...@packages.debian.org
Control: affects -1 + src:sniproxy

I request an adopter for the sniproxy package.

The package description is:
 Proxies incoming HTTP and TLS connections based on the hostname contained in
 the initial request of the TCP session. This enables HTTPS name-based virtual
 hosting to separate backend servers without installing the private key on the
 proxy machine.

Bug#1035757: unblock: org-mode/9.5.2+dfsh-5

[Paul Gevers]

Control: tags -1 moreinfo

Hi,

I haven't thought this trough, but it immediately triggered questions:

On 08-05-2023 20:46, Sean Whitton wrote:

A number of Emacs addon packages which have their own source packages also
have versions shipped in src:emacs's binary packages (upstream calls these
"core" ELPA packages).  We have them separately packaged mainly because of how
Emacs's release cadence does not line up well with Debian's.  So having them
separately packaged means we can ship newer versions of the addons even if
we're having to ship an older version of Emacs.

This scheme requires, however, that we don't allow it to ever transpire that
the version in src:emacs is newer than the version in the separate source
package, because Emacs prefers to load the separately installed version to the
bundled version, even when the latter has a higher version number.
Unfortunately, src:org-mode is undermaintained, and so precisely that
situation has arisen in bookworm.

We can resolve this by temporarily changing bin:elpa-org as described above,
for bookworm, and then populating it again after the freeze.


What's the plan for the future? Is this a one-off exercise or do you 
intent to pull this trick more often?


IIRC other ecosystems (like ruby) have the main package also (versioned) 
Provides these add-ons, such that when packages Depend on it, the main 
package can provide it without needing the add-on. That way, you could 
prevent shipping the package in a stable release when it's behind and 
have a newer version if it's available. Has such a scheme been 
considered? If yes, what's the drawback?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035106: grimripper

[Peter B]

I'm happy to have co-maintainers, but with less than a dozen packages in my list
I would hope to be able to keep it in good shape.

Bug#1035742: lintian-brush: excessive dependencies

[Jelmer Vernooij]

reassign 1035742 python3-launchpadlib
thanks

On Mon, May 08, 2023 at 06:18:33PM +0300, Martin-Éric Racine wrote:
> On Mon, May 8, 2023 at 6:11 PM Jelmer Vernooij  wrote:
> > On Mon, May 08, 2023 at 05:56:47PM +0300, Martin-Éric Racine wrote:
> > > lintian-brush currently Depends on or Recommends packages that pull a 
> > > large part of GNOME.
> > >
> > > This is excessive, especialy for a CLI tool. Please demote some of these 
> > > to mere Suggests.
> >
> > Thanks for the bug report.
> >
> > Can you be more specific - which packages is it pulling in that are
> > unexpected? lintian-brush has a Suggests on gnome-pkg-tools, but none of 
> > its hard
> > dependencies/recommends should (transitively) depend on GNOME.
> 
> python3-launchpadlib pulls everything and the kitchen sink:
> 
> $ LC_ALL=C sudo apt-get install --option
> Debug::pkgDepCache::AutoInstall=true lintian-brush
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
>Installing python3-breezy:i386 as Depends of lintian-brush:i386
> Installing python3-configobj:i386 as Depends of python3-breezy:i386
> Installing python3-fastbencode:i386 as Depends of python3-breezy:i386
> Installing python3-merge3:i386 as Depends of python3-breezy:i386
> Installing python3-dulwich:i386 as Depends of python3-breezy:i386
>   Installing python3-fastimport:i386 as Recommends of python3-dulwich:i386
> Installing python3-patiencediff:i386 as Depends of python3-breezy:i386
> Installing python3-launchpadlib:i386 as Recommends of python3-breezy:i386
>   Installing python3-lazr.restfulclient:i386 as Depends of
> python3-launchpadlib:i386
> Installing python3-lazr.uri:i386 as Depends of
> python3-lazr.restfulclient:i386
> Installing python3-wadllib:i386 as Depends of
> python3-lazr.restfulclient:i386
> Installing python3-oauthlib:i386 as Depends of
> python3-lazr.restfulclient:i386
>   Installing python3-blinker:i386 as Depends of python3-oauthlib:i386
>   Installing python3-jwt:i386 as Depends of python3-oauthlib:i386
>   Installing python3-keyring:i386 as Recommends of 
> python3-launchpadlib:i386
> Installing python3-jaraco.classes:i386 as Depends of
> python3-keyring:i386
> Installing python3-jeepney:i386 as Depends of python3-keyring:i386
> Installing python3-secretstorage:i386 as Depends of 
> python3-keyring:i386
>   Installing gnome-keyring:i386 as Recommends of
> python3-secretstorage:i386
> Installing dconf-gsettings-backend:i386 as Depends of
> gnome-keyring:i386
>   Installing dconf-service:i386 as Depends of
> dconf-gsettings-backend:i386
> Installing libdconf1:i386 as Depends of dconf-service:i386
> Installing libgck-1-0:i386 as Depends of gnome-keyring:i386
> Installing libgcr-base-3-1:i386 as Depends of gnome-keyring:i386
> Installing gcr:i386 as Depends of gnome-keyring:i386
>   Installing libgcr-ui-3-1:i386 as Depends of gcr:i386
> Installing libcairo2:i386 as Depends of libgcr-ui-3-1:i386
>   Installing libpixman-1-0:i386 as Depends of libcairo2:i386
>   Installing libxcb-render0:i386 as Depends of libcairo2:i386
>   Installing libxcb-shm0:i386 as Depends of libcairo2:i386
>   Installing libxrender1:i386 as Depends of libcairo2:i386
> Installing libgdk-pixbuf-2.0-0:i386 as Depends of
> libgcr-ui-3-1:i386
>   Installing libgdk-pixbuf2.0-common:i386 as Depends
> of libgdk-pixbuf-2.0-0:i386
>   Installing libgdk-pixbuf2.0-bin:i386 as Recommends
> of libgdk-pixbuf-2.0-0:i386
> Installing libgtk-3-0:i386 as Depends of libgcr-ui-3-1:i386
>   Installing adwaita-icon-theme:i386 as Depends of
> libgtk-3-0:i386
> Installing hicolor-icon-theme:i386 as Depends of
> adwaita-icon-theme:i386
> Installing gtk-update-icon-cache:i386 as Depends
> of adwaita-icon-theme:i386
> Installing librsvg2-common:i386 as Recommends of
> adwaita-icon-theme:i386
>   Installing librsvg2-2:i386 as Depends of
> librsvg2-common:i386
> Installing libcairo-gobject2:i386 as Depends
> of librsvg2-2:i386
> Installing libpango-1.0-0:i386 as Depends of
> librsvg2-2:i386
>   Installing fontconfig:i386 as Depends of
> libpango-1.0-0:i386
>   Installing libharfbuzz0b:i386 as Depends of
> libpango-1.0-0:i386
> Installing libgraphite2-3:i386 as Depends
> of libharfbuzz0b:i386
> Installing libpangocairo-1.0-0:i386 as Depends
> of librsvg2-2:i386
>   Installing libpangoft2-1.0-0:i386 as Depends
> of libpangocairo-1.0-0:i386
>   

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Mon, 8 May 2023 at 20:00, Sean Whitton  wrote:
>
> Hello,
>
> On Mon 08 May 2023 at 08:48AM -07, Russ Allbery wrote:
>
> > In other words, dpkg-divert is primarily for local administrators,
> > non-Policy-compliant local packages that are doing unusual things, and the
> > occasional rare problem that requires special coordination between
> > packages, not something that Debian packages should be doing to other
> > packages without explicit coordination.
> >
> > The rule about systemd and udev files doesn't entirely fall out of that
> > statement,
>
> Hmm, could you explain why?
>
> > so we can still include a specific statement about them, noting that
> > drop-ins and masking make dpkg-divert unnecessary (and those
> > facilities produce better tool behavior) and therefore it should not
> > be used.
> >
> > So, ideally, the way I'd prefer to move forward is for us to add a new
> > section to the main Policy manual on diversions (probably 10.11), document
> > that this is primarily a tool for local administrators and local packages
> > to override the behavior of Debian, and that its use between Debian
> > packages should be rare, should involve coordination between the packages,
> > and should only be used to solve problems that cannot be handled through
> > other facilities such as alternatives or package-specific tools like
> > systemd's support for drop-ins and masking.  And then explicitly call out
> > systemd and udev configuration as cases where dpkg-divert should not be
> > used, alongside conffiles and critical system files.
>
> I don't mean to dismiss the significant impact on the systemd
> maintainers that's being claimed, but specifically calling out udev and
> systemd configuration files seems strangely specific, for Policy, to me.
>
> The general prohibition seems justified, and then I would be inclined to
> use the systemd and udev configuration files case as an example, which
> explains and justifies the existence of the rule.  So instead of
>
> [don't use dpkg-divert on other packages's files]  In particular,
> packages should not divert systemd and udev configuration files.
> Doing so leads to confusing command output.
>
> it seems more natural to me to do something like
>
> [don't use dpkg-divert on other packages's files]  For example,
> diverting another package's systemd units or udev configuration
> files can result in confusing command output.
>
> If this was a mistake that maintainers seemed to habitually make, the
> former would make sense, but so far I think we have just one or a few
> concrete examples, and so the correct thing to do seems to me to be to
> add normative language for only the general case.

Hi,

The specific difference, for which I think an explicit call out is
needed, is because these config files are shipped by some packages but
are not used _by_ them, they are consumed by systemd (or udev, or
kmod, etc). Specifically, if package A ships a.service, and package B
overrides it, even if the maintainers of A and B agree, that's still
not good enough for me, as they are really affecting systemd, which is
the consumer and the provider of the interface they are using, and
ultimately the first port of call for bug reports. This is especially
true for udev.

So in my latest revision of the patch, the general rule is as
requested by Russ and as you mention it, but there is an explicit,
stricter rule to cover this case, which is important to me. Policy
calls out core component software in many places, such as dpkg, and
systemd is already mentioned in other parts of the policy, so it did
not seem too far-fetched to me.

I am of course open to re-wording, adjustments, etc as deemed necessary.

Changeset at: https://salsa.debian.org/bluca/policy/-/tree/systemd_overrides

Kind regards,
Luca Boccassi

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Sean Whitton]

Hello,

On Mon 08 May 2023 at 08:48AM -07, Russ Allbery wrote:

> In other words, dpkg-divert is primarily for local administrators,
> non-Policy-compliant local packages that are doing unusual things, and the
> occasional rare problem that requires special coordination between
> packages, not something that Debian packages should be doing to other
> packages without explicit coordination.
>
> The rule about systemd and udev files doesn't entirely fall out of that
> statement,

Hmm, could you explain why?

> so we can still include a specific statement about them, noting that
> drop-ins and masking make dpkg-divert unnecessary (and those
> facilities produce better tool behavior) and therefore it should not
> be used.
>
> So, ideally, the way I'd prefer to move forward is for us to add a new
> section to the main Policy manual on diversions (probably 10.11), document
> that this is primarily a tool for local administrators and local packages
> to override the behavior of Debian, and that its use between Debian
> packages should be rare, should involve coordination between the packages,
> and should only be used to solve problems that cannot be handled through
> other facilities such as alternatives or package-specific tools like
> systemd's support for drop-ins and masking.  And then explicitly call out
> systemd and udev configuration as cases where dpkg-divert should not be
> used, alongside conffiles and critical system files.

I don't mean to dismiss the significant impact on the systemd
maintainers that's being claimed, but specifically calling out udev and
systemd configuration files seems strangely specific, for Policy, to me.

The general prohibition seems justified, and then I would be inclined to
use the systemd and udev configuration files case as an example, which
explains and justifies the existence of the rule.  So instead of

[don't use dpkg-divert on other packages's files]  In particular,
packages should not divert systemd and udev configuration files.
Doing so leads to confusing command output.

it seems more natural to me to do something like

[don't use dpkg-divert on other packages's files]  For example,
diverting another package's systemd units or udev configuration
files can result in confusing command output.

If this was a mistake that maintainers seemed to habitually make, the
former would make sense, but so far I think we have just one or a few
concrete examples, and so the correct thing to do seems to me to be to
add normative language for only the general case.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1034694: gnome-core: Cannot install due to pipewire-audio dependency

[Witold Baryluk]

Package: gnome-core
Version: 1:43+1
Followup-For: Bug #1034694
X-Debbugs-Cc: witold.bary...@gmail.com

Here:

root@debian:~# sudo apt -V --simulate remove pulseaudio
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
   bind9-host (1:9.18.12-1)
   bind9-libs (1:9.18.12-1)
   libfstrm0 (0.6.1-1)
   libjemalloc2 (5.3.0-1)
   libmaxminddb0 (1.7.1-1)
   libprotobuf-c1 (1.4.1-1+b1)
   libuv1 (1.44.2-1)
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
   liblua5.3-0 (5.3.6-2)
   libpipewire-0.3-modules (0.3.65-3)
   libwireplumber-0.4-0 (0.4.13-1)
   pipewire (0.3.65-3)
   pipewire-bin (0.3.65-3)
   pipewire-pulse (0.3.65-3)
   wireplumber (0.4.13-1)
Suggested packages:
   libspa-0.2-bluetooth (0.3.65-3)
   wireplumber-doc (0.4.13-1)
The following packages will be REMOVED:
   libcanberra-pulse (0.30-10)
   pulseaudio (16.1+dfsg1-2+b1)
The following NEW packages will be installed:
   liblua5.3-0 (5.3.6-2)
   libpipewire-0.3-modules (0.3.65-3)
   libwireplumber-0.4-0 (0.4.13-1)
   pipewire (0.3.65-3)
   pipewire-bin (0.3.65-3)
   pipewire-pulse (0.3.65-3)
   wireplumber (0.4.13-1)
0 upgraded, 7 newly installed, 2 to remove and 0 not upgraded.
Remv libcanberra-pulse [0.30-10]
Remv pulseaudio [16.1+dfsg1-2+b1]
Inst liblua5.3-0 (5.3.6-2 Debian:testing [amd64])
Inst libpipewire-0.3-modules (0.3.65-3 Debian:testing [amd64])
Inst libwireplumber-0.4-0 (0.4.13-1 Debian:testing [amd64])
Inst pipewire-bin (0.3.65-3 Debian:testing [amd64])
Inst pipewire (0.3.65-3 Debian:testing [amd64])
Inst pipewire-pulse (0.3.65-3 Debian:testing [amd64])
Inst wireplumber (0.4.13-1 Debian:testing [amd64])
Conf liblua5.3-0 (5.3.6-2 Debian:testing [amd64])
Conf libpipewire-0.3-modules (0.3.65-3 Debian:testing [amd64])
Conf libwireplumber-0.4-0 (0.4.13-1 Debian:testing [amd64])
Conf pipewire-bin (0.3.65-3 Debian:testing [amd64])
Conf pipewire (0.3.65-3 Debian:testing [amd64])
Conf pipewire-pulse (0.3.65-3 Debian:testing [amd64])
Conf wireplumber (0.4.13-1 Debian:testing [amd64])
root@debian:~# 


Regards,
Witold

Bug#1035758: backupninja: Config defaults leads to node-exporter error

[Olivier Berger]

Package: backupninja
Version: 1.2.2-1
Severity: minor
Tags: upstream

Dear Maintainer,

With the default config in backupninja.conf, and prometheus-node-exporter isn't 
installed, an error is reported at the end of backups like:
Error: /var/lib/prometheus/node-exporter does not exist!

I believe that the default value isn't suitable:
reportprom = false

Instead, it should be:
reportprom = 

if I interpret 
https://0xacab.org/liberate/backupninja/-/blob/8f81c85274cd7a21d4bff819bf800b300a7488d2/src/backupninja.in#L609
 correctly.

Hope this is correct.

Best regards,

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable'), (100, 'bullseye-fasttrack'), (100, 
'bullseye-backports-staging')
Architecture: amd64 (x86_64)

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

Versions of packages backupninja depends on:
ii  bash5.2.15-2+b2
ii  dialog  1.3-20230209-1
ii  gawk1:5.2.1-2
ii  mawk1.3.4.20200120-3.1

Versions of packages backupninja recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20220412cvs-1
ii  mailutils [mailx]  1:3.15-4

Versions of packages backupninja suggests:
ii  borgbackup 1.2.4-1
ii  bzip2  1.0.8-5+b1
ii  debconf-utils  1.5.82
pn  duplicity  
ii  fdisk  2.38.1-5+b1
ii  genisoimage9:1.1.11-3.4
ii  hwinfo 21.82-1
ii  mdadm  4.2-5
ii  rdiff-backup   2.2.2-1
pn  restic 
ii  rsync  3.2.7-1
pn  subversion 
ii  trickle1.07-12
ii  util-linux 2.38.1-5+b1
pn  wodim  

-- Configuration Files:
/etc/backupninja.conf changed:
loglevel = 4
reportprom = 
reportemail = root
reportsuccess = yes
reportinfo = no
reportwarning = yes
reportspace = no
reporthost =
reportuser = ninja
reportdirectory = /var/lib/backupninja/reports
admingroup = root
logfile = /var/log/backupninja.log
configdirectory = /etc/backup.d
scriptdirectory = /usr/share/backupninja
libdirectory = /usr/lib/backupninja
usecolors = yes
when = everyday at 01:00


-- debconf-show failed

-- 
Olivier BERGER
https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#1035757: unblock: org-mode/9.5.2+dfsh-5

[Sean Whitton]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 1033...@bugs.debian.org, 1035...@bugs.debian.org, 
em...@packages.debian.org

We (the Debian Emacsen team) would like to modify bin:elpa-org in bookworm to
1. install no files outside of /usr/share/doc; and
2. newly hard-depend on bin:emacs.
A debdiff doesn't seem very useful for review purposes in this case, so I'm
not attaching one, but one of us can prepare one if wanted.

Nothing has been uploaded yet.

(Thank you to bug reporter Maxim Nikulin for suggesting shipping an empty 
package.)

[ Reason ]
A number of Emacs addon packages which have their own source packages also
have versions shipped in src:emacs's binary packages (upstream calls these
"core" ELPA packages).  We have them separately packaged mainly because of how
Emacs's release cadence does not line up well with Debian's.  So having them
separately packaged means we can ship newer versions of the addons even if
we're having to ship an older version of Emacs.

This scheme requires, however, that we don't allow it to ever transpire that
the version in src:emacs is newer than the version in the separate source
package, because Emacs prefers to load the separately installed version to the
bundled version, even when the latter has a higher version number.
Unfortunately, src:org-mode is undermaintained, and so precisely that
situation has arisen in bookworm.

We can resolve this by temporarily changing bin:elpa-org as described above,
for bookworm, and then populating it again after the freeze.

[ Impact ]
If a user installs one of elpa-org's rdeps, such as elpa-org-contrib, then
currently this has the effect of *downgrading* the version of Org-mode that
Emacs will actually load.  This could break all kinds of other things the user
has installed, or their own Emacs Lisp code.  It also creates confusion,
because outside of Debian, you have to try extra hard to create a situation in
which you have an older version of Org-mode loaded than the one that ships
with Emacs.  So users might report bugs to upstreams that are caused only by
this strange situation in Debian.

[ Tests ]
The test would be to 'apt-get install elpa-org-contrib', start Emacs, and use
'M-x org-version' to confirm that you get version 9.5.5.  We'd want to run
all possible piuparts tests too.

[ Risks ]
This might expose bugs in other leaf packages that turn out not to be
compatible with the newer Org-mode.  However, that's preferable to the current
situation.

The emacsen-common scripts might not like the situation in which a package
suddenly ships nothing.  piuparts testing would reveal whether this is
actually a problem.  I'm sorry that this hasn't been done yet: I don't myself
have time to do anything other than write up this unblock request, and I
thought it would be appropriate to ask for your opinion on the basic idea
before doing anything else.

unblock org-mode/9.5.2+dfsh-5

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Mon, 8 May 2023 at 18:31, Russ Allbery  wrote:
>
> Sam Hartman  writes:
>
> > In cases where the change being made is permitted by policy, I think you
> > have made a compelling case to vastly prefer the native systemd and udev
> > mechanisms to dpkg-divert.  I don't think that your case is strong
> > enough to forbid dpkg-divert.
>
> > As far as I can tell reading your reasoning, dpkg-divert *works fine*.
> > It just gives surprising results to someone coming from the systemd
> > universe.
>
> I think (and please correct me, Luca, if I'm wrong) that Luca is trying to
> declare, on behalf of the systemd maintainers, that this method of
> disabling a systemd configuration file is unsupported and may not work.
> To me that does warrant a Policy "should not" even if in specific
> situations it works currently, because it implies that this approach is
> fragile and may well stop working or cause bugs in the future with no
> further notification (since that's essentially the definition of
> unsupported).
>
> Also, even apart from that, I personally would support a Policy "should
> not" for using diversions in any case where another mechanism is available
> that solves the same problem.  Diversions are a low-level tool with a lot
> of sharp edges and should be used very carefully and avoided when there is
> some other approach available.

Yes, that is precisely what I meant.

I have applied your suggestions and added a 10.10 chapter that has a
generic 'should' rule, and a more strict 'must' rule for systemd
files. I am pushing to the same branch, if you prefer me to attach
directly to the mail too let me know and I can do that, otherwise the
branch is on Salsa:

https://salsa.debian.org/bluca/policy/-/tree/systemd_overrides

I kept the wording for the dpkg-divert appendix too, because people
are bound to find it when googling, so as long as it's there I think
it should mention this too. Once it gets removed/reworked it can go.

On request from Marco, the kmod maintainer, I've also added the same
constraint for modprobe.d/ files, for exactly the same reason, as kmod
supports overrides, drop-ins and so on. I've kept it as a separate
commit on top of the other changes, given I am not involved with kmod
directly.

Kind regards,
Luca Boccassi

Bug#1035756: ITP: node-regexp-match-indices -- Node.js polyfill/shim for the RegExp Match Indices proposal

[Yadd]

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

* Package name: node-regexp-match-indices
  Version : 1.0.2
  Upstream Contact: Ron Buckton 
* URL : https://npmjs.com/package/regexp-match-indices
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Node.js polyfill/shim for the RegExp Match Indices proposal

node-regexp-tree implementation is a replacement for RegExp.prototype.exec
that approximates the behavior of the proposal.
See proposal at https://github.com/tc39/proposal-regexp-match-indices

This package is a dependency of JupyterLab. It'll be maintained under JS
Team umbrella.

Bug#1035055: AW: EXTERNAL - Bug#1035055: ITP: firmware-imx -- Firmware binary blobs needed on NXP i.MX platforms

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Traut Manuel LCPF-CH (2023-05-08 15:25:06)
> The current version can be found here:
> https://salsa.debian.org/manut/firmware-imx/
> 
> I also need it for adding imx8mm support to u-boot. On which target are you 
> working?

the MNT Reform 2 open source laptop which is based on the IMX8MQ SoM. Support
for it was added to u-boot here:

https://source.denx.de/u-boot/u-boot/-/commit/ebe2e0c309470249ffb09480d39c2dea9e64871c

> >Do you plan to upload this to non-free-firmware?
> 
> Yes, but did not so far.
> Currently the .bin is part of the debian git. Did not find a way to write a 
> valid watch file for a webpage that denies indexing.

Indeed there is no HTML listing. Is the file linked from any other place?

> Any help on the package is welcome - even uploading it, since I am no DD.

Okay. I can upload this.

But are we allowed to distribute these? Reading the copyright file,
distribution only seems to be allowed by those in the "Software Content
Register".

On which basis does the license allow us to redistribute it?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1034111: Data point: WLAN stable after bluetooth removal

[Steinar Bang]

I removed bluetooth support from the laptop on April 10 2023, and WLAN
provided by the Mediatek 7921 chip has been working flawlessly since
then for, at the time of writing, 28 days, with numerous suspends and
resumes. 

To me this strongly indicates that using bluetooth was the problem,
especially since it seems to be provided by the Mediatek 7921 chip as
well.

Note that I'm also running the Mx Master mouse, using the provided USB
plug instead of using bluetooth.  That also works flawlessly.

(Nevertheless: I have other bluetooth devices so it would be nice to get
bluetooth on this laptop, that doesn't make WiFi stop working)

I removed bluetooth support by removing all packages with "blue" in
their name, with the exception of libbluetooth3 (I initially uninstalled
that as well, but that pulled out network-manager as well, so I had to
put it back in).

These are the packages I "apt remove"'d:

apt remove bluez bluez-obexd gnome gnome-bluetooth gnome-core 
pulseaudio-module-bluetooth task-gnome-desktop \
 qml-module-org-kde-bluezqt:amd64 libkf5bluezqt6:amd64 libkf5bluezqt-data 
libgnome-bluetooth13:amd64 gir1.2-gnomebluetooth-1.0:amd64

Bug#1034111: The driver for the Mediatek 7921 chip

[Steinar Bang]

I think this is the driver for the WiFi part of the Mediatek 7921 chip:
 
https://github.com/torvalds/linux/tree/master/drivers/net/wireless/mediatek/mt76/mt7921

No idea if this also is the home of the bluetooth driver, but I suspect
it is, because I couldn't find any mention of the 7921 chip elsewhere.

Bug#1035042: wpewebkit: ftbfs riscv64 Error: open CFI at the end of file; missing .cfi_endproc directive

[Alberto Garcia]

On Mon, May 01, 2023 at 05:18:39AM +, sun min wrote:
> I get the package source with below command:
> dget http://deb.debian.org/debian/pool/main/w/wpewebkit/wpewebkit_2.38.6-1.dsc

I have seen people reporting the same bug when building other projects
and it seems that this could be hardware or memory related... how much
RAM do you have to build WebKit?

Berto

Bug#1035755: RM: gbase -- RoQA; orphaned; depends on gtk2; low popcon

[Bastian Germann]

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

Please remove gbase. The package is orphaned and has long-standing RC bugs.
It depends on gtk2, has a low popcon and no reverse dependencies. Alternatives 
are available.

Bug#1035754: openssh-server: PermitEmptyPasswords=yes causes login to take 2-4s by enabling PAM password check

[Zachary Vance]

Package: openssh-server
Version: 1:8.4p1-5+deb11u1
Severity: normal
X-Debbugs-Cc: z...@za3k.com

Dear Maintainer,

* What led up to the situation?
Enable the following options in sshd_config:

PermitEmptyPasswords yes
PasswordAuthentication no # Also the default. Confirming order doesn't 
matter.

Log in using an ssh key. 

* What was the outcome of this action?
This takes 2000-4000ms on my server. I suspect the slowness is from PAM 
checking passwords somehow.

The relevant log lines from the server:

May 08 13:53:48 germinate sshd[2561718]: debug1: Forked child 3847417.
May 08 13:53:48 germinate sshd[3847417]: debug1: Set 
/proc/self/oom_score_adj to 0
May 08 13:53:48 germinate sshd[3847417]: debug1: rexec start in 5 out 5 
newsock 5 pipe 7 sock 8
May 08 13:53:48 germinate sshd[3847417]: debug1: inetd sockets after 
dupping: 4, 4
May 08 13:53:48 germinate sshd[3847417]: Connection from 192.168.1.100 
port 54350 on 192.168.1.17 port 22 rdomain ""
May 08 13:53:48 germinate sshd[3847417]: debug1: Local version string 
SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1
May 08 13:53:48 germinate sshd[3847417]: debug1: Remote protocol 
version 2.0, remote software version OpenSSH_9.3
May 08 13:53:48 germinate sshd[3847417]: debug1: match: OpenSSH_9.3 pat 
OpenSSH* compat 0x0400
May 08 13:53:48 germinate sshd[3847417]: debug1: permanently_set_uid: 
106/65534 [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: list_hostkey_types: 
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: SSH2_MSG_KEXINIT sent 
[preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: SSH2_MSG_KEXINIT 
received [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: kex: algorithm: 
curve25519-sha256 [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: kex: host key 
algorithm: ecdsa-sha2-nistp256 [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: kex: client->server 
cipher: chacha20-poly1...@openssh.com MAC:  compression: none 
[preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: kex: server->client 
cipher: chacha20-poly1...@openssh.com MAC:  compression: none 
[preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: expecting 
SSH2_MSG_KEX_ECDH_INIT [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: rekey out after 
134217728 blocks [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: SSH2_MSG_NEWKEYS sent 
[preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: Sending 
SSH2_MSG_EXT_INFO [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: expecting 
SSH2_MSG_NEWKEYS [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: SSH2_MSG_NEWKEYS 
received [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: rekey in after 
134217728 blocks [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: KEX done [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: userauth-request for 
user zachary service ssh-connection method none [preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: attempt 0 failures 0 
[preauth]
May 08 13:53:48 germinate sshd[3847417]: debug1: user zachary matched 
'User zachary' at line 133
May 08 13:53:48 germinate sshd[3847417]: debug1: PAM: initializing for 
"zachary"
May 08 13:53:48 germinate sshd[3847417]: debug1: PAM: setting PAM_RHOST 
to "192.168.1.100"
May 08 13:53:48 germinate sshd[3847417]: debug1: PAM: setting PAM_TTY 
to "ssh"
May 08 13:53:48 germinate sshd[3847417]: pam_unix(sshd:auth): 
authentication failure; logname= uid=0 euid=0 tty=ssh ruser= 
rhost=192.168.1.100  user=zachary
May 08 13:53:50 germinate sshd[3847417]: debug1: PAM: password 
authentication failed for zachary: Authentication failure
May 08 13:53:50 germinate sshd[3847417]: Failed none for zachary from 
192.168.1.100 port 54350 ssh2
May 08 13:53:51 germinate sshd[3847417]: debug1: userauth-request for 
user zachary service ssh-connection method publickey [preauth]
May 08 13:53:51 germinate sshd[3847417]: debug1: attempt 1 failures 0 
[preauth]
May 08 13:53:51 germinate sshd[3847417]: debug1: userauth_pubkey: test 
pkalg rsa-sha2-512 pkblob RSA 
SHA256:Zt8jjAh4Z8iQ1+219IV7eNmSnQ154QbBoJ947jVEDDk [preauth]
May 08 13:53:51 germinate sshd[3847417]: debug1: temporarily_use_uid: 
1000/1000 (e=0/0)
May 08 13:53:51 germinate sshd[3847417]: debug1: trying public key file 
/home/zachary/.ssh/authorized_keys
May 08 13:53:51 germinate sshd[3847417]: debug1: fd 5 clearing 
O_NONBLOCK
May 08 13:53:51 germinate sshd[3847417]: debug1: 
/home/zachary/.ssh/authorized_keys:1: matching key found: RSA 
SHA256:Zt8jjAh4Z8iQ1+219IV7eNmSnQ154QbBoJ947jVEDDk
May 08 13:53:51 

Bug#1035753: O: gbase -- small numeric base converter

[Bastian Germann]

Package: wnpp

gbase is obviously not maintained anymore (long-standing, trivial RC bugs) and 
so I orphan it.

Bug#967626: mate-equake-applet: depends on deprecated GTK 2

[Bastian Germann]

I am uploading a NMU to fix this. The debdiff is attached.diff -Nru mate-equake-applet-1.3.8.2/debian/changelog 
mate-equake-applet-1.3.8.2/debian/changelog
--- mate-equake-applet-1.3.8.2/debian/changelog 2018-05-05 04:10:14.0 
+0200
+++ mate-equake-applet-1.3.8.2/debian/changelog 2023-05-08 19:44:08.0 
+0200
@@ -1,3 +1,12 @@
+mate-equake-applet (1.3.8.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Fix lintian: build-depends-on-obsolete-package
+  * Represent the actual gtk3 build dependency that is also available via
+libmate-panel-applet-dev (Closes: #967626)
+
+ -- Bastian Germann   Mon, 08 May 2023 19:44:08 +0200
+
 mate-equake-applet (1.3.8.2-1) unstable; urgency=low
 
   * New upstream release (Closes: #849267)
diff -Nru mate-equake-applet-1.3.8.2/debian/control 
mate-equake-applet-1.3.8.2/debian/control
--- mate-equake-applet-1.3.8.2/debian/control   2017-03-05 15:06:20.0 
+0100
+++ mate-equake-applet-1.3.8.2/debian/control   2023-05-08 19:44:08.0 
+0200
@@ -9,11 +9,11 @@
libcurl4-gnutls-dev,
libatk1.0-dev,
libcairo2-dev,
-   libfontconfig1-dev,
-   libfreetype6-dev,
-   libgdk-pixbuf2.0-dev,
+   libfontconfig-dev,
+   libfreetype-dev,
+   libgdk-pixbuf-2.0-dev,
libglib2.0-dev,
-   libgtk2.0-dev,
+   libgtk-3-dev,
libpango1.0-dev,
 Standards-Version: 3.9.8
 Homepage: https://www.e-quake.org

Bug#1035752: RM: xfce4-equake-plugin -- RoQA; orphaned; depends on gtk2; low popcon

[Bastian Germann]

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

Please remove xfce4-equake-plugin. The package is orphaned and has a 
long-standing RC bug.
It depends on gtk2, has a low popcon and no reverse dependencies. Alternatives 
are available.

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Russ Allbery]

Sam Hartman  writes:

> In cases where the change being made is permitted by policy, I think you
> have made a compelling case to vastly prefer the native systemd and udev
> mechanisms to dpkg-divert.  I don't think that your case is strong
> enough to forbid dpkg-divert.

> As far as I can tell reading your reasoning, dpkg-divert *works fine*.
> It just gives surprising results to someone coming from the systemd
> universe.

I think (and please correct me, Luca, if I'm wrong) that Luca is trying to
declare, on behalf of the systemd maintainers, that this method of
disabling a systemd configuration file is unsupported and may not work.
To me that does warrant a Policy "should not" even if in specific
situations it works currently, because it implies that this approach is
fragile and may well stop working or cause bugs in the future with no
further notification (since that's essentially the definition of
unsupported).

Also, even apart from that, I personally would support a Policy "should
not" for using diversions in any case where another mechanism is available
that solves the same problem.  Diversions are a low-level tool with a lot
of sharp edges and should be used very carefully and avoided when there is
some other approach available.

> But consider a package that diverts several resources, several of them
> systemd and several of them not systemd.  The maintainer might
> legitimately want to use the same mechanism for all the
> overriding/masking so that systemd resources and non-systemd resources
> were handled the same.

I'm not really convinced by this the way that I would be if we were
talking about alternatives.  With alternatives, the slave links mean that
managing a group of similar changes together is important, but dpkg-divert
has no equivalent and every diversion already has to be maintained
separately.  Given that, I think the burden of asking people to use
masking instead of diversion for systemd configuration files is a fairly
minor request, so I weigh the problems on the systemd side higher than
what feels like a modest convenience.

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

Bug#1035751: O: xfce4-equake-plugin -- Xfce panel plugin which monitors earthquakes

[Bastian Germann]

Package: wnpp

xfce4-equake-plugin is obviously not maintained anymore.
The RC bug #978237 was not fixed for 2.5 years, which is why the last release 
containing it was buster.

Bug#1035750: RM: bitstormlite -- RoQA; orphaned; depends on gtk2; low popcon

[Bastian Germann]

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

Please remove bitstormlite. The package is orphaned and its last upstream 
version was published 2007.
It depends on gtk2, has a low popcon and no reverse dependencies. Alternatives 
are available.

Bug#1035749: related bug

[Carter Smithhart]

https://gitlab.gnome.org/GNOME/mutter/-/issues/2723 another related or
possible dup upstream bug

Bug#1035749: Related bug

[Carter Smithhart]

It also may be https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2012100

Bug#1035749: mutter: gnome-shell crashed with SIGSEGV in meta_wayland_compositor_get_context()

[Carter]

Package: mutter
Version: 44.0-2ubuntu4
Severity: important

Dear Maintainer,

After upgrading my ubuntu system to 23.04, any time I pull a tab off of a 
firefox browser,
I risk the chance of X11 crashing. I generally hit this issue 6+ times a day.
To minimize this, I attempt to not move tabs around, but this has been a part 
of my browser
usage for years.

Using coredumpctl, I'm seeing the same callstack as
https://gitlab.gnome.org/GNOME/mutter/-/issues/2708

There's a downstream ubuntu bug:
https://launchpad.net/bugs/2012230

I asked when ubuntu would incorporate the fix here: 
https://answers.launchpad.net/ubuntu/+source/mutter/+question/706514

It was suggested I write a debian bug because ubuntu incorporates mutter 
updates from debian.

The mutter fix "wayland: Set compositor when creating 
MetaWaylandDataSourceXWayland" is
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2956 and merged to main 
April 12 2023.

I can see "wayland: Set compositor when creating MetaWaylandDataSourceXWayland" 
in 44.1.
https://gitlab.gnome.org/GNOME/mutter/-/commits/44.1?search=

I believe this is the ubuntu bump to 44.1 when that's available (fix made on 
April 25 2023):
https://git.launchpad.net/mutter/commit/?id=28a6447ff060ae1fbac8f20a13908d6e230eddc2


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

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

Versions of packages mutter depends on: ii adwaita-icon-theme 41.0-1ubuntu1 ii 
gnome-settings-daemon-common 44.0-1ubuntu1 ii gsettings-desktop-schemas 
44.0-1ubuntu1 ii libc6 
2.37-0ubuntu2 ii libgles2 1.6.0-1 ii libglib2.0-0 2.76.1-1 ii libmutter-12-0 
44.0-2ubuntu4 ii 
libwayland-client0 1.21.0-1 ii mutter-common 44.0-2ubuntu4 ii zenity 3.44.0-1

mutter recommends no packages.

Versions of packages mutter suggests: ii gnome-control-center 1:44.0-1ubuntu5 
ii xdg-user-dirs 0.18-1

-- no debconf information

Bug#1035744: memtest86+: new upstream version

[Felix Zielcke]

Am Montag, dem 08.05.2023 um 17:44 +0200 schrieb Fabio Fantoni:
> Il 08/05/2023 17:22, Christoph Anton Mitterer ha scritto:
> > Package: memtest86+
> > Version: 6.10-4
> > Severity: wishlist
> > 
> > Hey.
> > 
> > 6.20 is out :-)
> > 
> > Cheers,
> > Chris.
> 
> Hi, Felix Zielcke already uploaded 6.20-1 into experimental, the new 
> version for bookworm is too late, there is the "hard freeze" and I 
> suppose Felix uploaded to experimental instead unstable to make
> possible 
> an urgent fixes upload for bookworm if will be needed, even if I
> suppose 
> there is very low probability to spot RC bugs on 6.10-4
> 

Correct.
I don't think either we need another upload for bookform.
But better be safe. And also the freeze policy says to avoid uploads to
unstable which aren't meant for bookworm

Bug#1035627: libpcsclite-dev: Multiarch doesn't work for libpcsclite-dev (needed by current wine git)

[Ludovic Rousseau]

Le 08/05/2023 à 13:27, Patrick Hibbs a écrit :

Hello,

Yes, I have. That works for wine's 64bit build, but wine's 32bit build will not 
recognize it.


I just installed a new Debian 11 (stable) system amd64 with multiarch for i386.
I have no problem installing libpcsclite-dev for both amd64 and i386.

$ LANG=C dpkg -l libpcsc*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---===>
ii  libpcsclite-dev:amd64 1.9.1-1  amd64Middleware to access a smar>
ii  libpcsclite-dev:i386  1.9.1-1  i386 Middleware to access a smar>
ii  libpcsclite1:amd641.9.1-1  amd64Middleware to access a smar>
ii  libpcsclite1:i386 1.9.1-1  i386 Middleware to access a smar>

I am also able to build a sample PC/SC code for i386 on this system:
$ /usr/bin/i586-linux-gnu-gcc `pkg-config libpcsclite --cflags`sample.c  
`pkg-config libpcsclite --libs` -o sample

$ file sample
sample: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux.so.2, 
BuildID[sha1]=435a71bbacb507f1e61c30ca3943da130490796c, for GNU/Linux 3.2.0, 
not stripped

$ ldd sample
linux-gate.so.1 (0xf7fa2000)
libpcsclite.so.1 => /lib/i386-linux-gnu/libpcsclite.so.1 (0xf7f83000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7d9b000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7d79000)
/lib/ld-linux.so.2 (0xf7fa4000)

I guess the problem is because libpcsclite-dev declares:
Recommends: python3

Use:
$ apt install --no-install-recommends libpcsclite-dev:i386

Bye

--
Dr. Ludovic Rousseau

Bug#999485: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices

[James Addison]

Package: firmware-brcm80211
Followup-For: Bug #999485
X-Debbugs-Cc: gw...@gwolf.org, didi.deb...@cknow.org, 1023...@bugs.debian.org

Dear Maintainer,

> There is now a license available for the brcmfmac43456 firmware: it's included
> in the relevant RPF package metadata, in the usual copyright file:
>
> https://archive.raspberrypi.org/debian/pool/main/f/firmware-nonfree/firmware-nonfree_20221012-1~bpo11+1+rpt1.debian.tar.xz

I've prepared a patch locally that attempts to include this license for
distribution with Debian.

It does the following:

  * Adds a new entry to the debian/copyright file that adds the updated license
and mentions the download origin (similar to the existing entry).  The file
pattern is specific to the 43456-class firmware files.

  * Moves the LICENSE file to LICENSE.Broadcom as a disambiguation.

  * Adds a LICENSE.Synaptics file, matching the contents of debian/copyright.

And some notes:

  * Although this is an updated license, I've confirmed that the firmware file
*contents* have *not* changed the raspi-firmware-1.20220830+ds upload
(before the license was available).  The content hashes stay the same, at:

c5bc73bfee9085c2ba1e5f52bc811cabae81cd16df2d1e866aa646ee7fe83534  
brcmfmac43456-sdio.bin.base64
08f7ed881894d41f1e50ed0446fb9868c1019b92f8ad582e6cc361577a3e57a6  
brcmfmac43456-sdio.clm_blob.base64
44e0bb322dc1f39a4b0a89f30ffdd28bc93f7d7aaf534d06d229fe56f6198194  
brcmfmac43456-sdio.txt

  * I've placed the copyright year for Synaptics as Y2020, the year that the
acquisition of Broadcom by Synaptics took place.

If that approach sounds sensible (or not!) please let me know and I can adjust
it and/or upload the patch here/elsewhere.

Bug#1035747: ITP: cevomapgen -- External Map Generator for C-Evo

[Peter Blackman]

Package: wnpp
Severity: wishlist
Owner: Peter 
X-Debbugs-Cc: debian-de...@lists.debian.org, pe...@pblackman.plus.com

* Package name    : cevomapgen
  Version : 26
  Upstream Contact: 
* URL : https://sourceforge.net/projects/cevomapgen/
* License : GPL3+
  Programming Lang: Lazarus/FPC
  Description : External Map Generator for C-Evo

Generates more varied maps than the in-game generator,
with greater control, and allows much faster generation of
novel or extreme worlds than using the map editor.

Intended for use with c-evo-dh and other versions of C-evo


Regards,
Peter

Bug#1035734: Acknowledgement (Does not search for terms in latin1 encoding anymore)

[Axel Beckert]

Hi,

Klaus Ethgen wrote:
> I found the bug.

Great. Sorry for my just sent reply then. Saw your second mail only
after sending it.

> The bug is in the color code.

Oh, ok, that's probably my code then, yes.

> The replacement of $SEARCH in the new display function can never match
> for latin1 chars as it is still UTF-8. So either use the original search
> string here or convert it back to local locale.

Ok, will have a closer look. Don't see the right place for a fix on a
first glance.

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

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Mon, 8 May 2023 at 16:48, Russ Allbery  wrote:
>
> I think your X-Debbugs-Cc was syntactically invalid and thus didn't work.
> I manually added in the other addresses in this reply.

Thanks - email is hard!

> Luca Boccassi  writes:
>
> > It has come to my attention that there is one package in Debian using
> > dpkg-divert to mask a systemd configuration file (an udev rule).
> > Speaking as one of the maintainers, both upstream and downstream, I find
> > this greatly undesirable for several reasons that I will outline
> > later. Hence I would like to propose explicitly mentioning that
> > dpkg-divert must not be used for systemd configuration files (units,
> > rules, etc), and instead the supported workflow (drop-ins, masking, etc)
> > must be used, both by packages and administrators. This is already
> > standard practice, and again there is only one instance that needs
> > correcting as far as I understand, and I have already provided a bug and
> > a MR for that [1][2]. So the impact of this policy change should be
> > minimal, and it's mostly to ensure more such instances are accidentally
> > added in the future.
>
> > I have a draft policy update, that adds a paragraph to the dpkg-divert
> > section of the policy. It is attached here, and also available on Salsa
> > on my fork [3].
>
> The part of Policy that you edited with this patch is basically
> unmaintained and should ideally be removed in favor of actual Policy.  (I
> had started looking at that a long time ago and then never finished.)  All
> of those appendices from the old packaging manual predate better
> documentation maintained elsewhere (such as in the dpkg package) and are
> ambiguous with regards to whether they set requirements for Debian
> packages, document things for local administrators, or something else.
> The Policy manual warns that they may not be normative, and people often
> don't think to read them (for good reason).
>
> In the case of diversions, while I certainly agree with your proposed
> rule, I suspect Policy should say something stronger and more general,
> namely that no package in Debian should divert a file from another package
> unless this is arranged cooperatively between the packages to solve some
> specific (unusual) problem.  To me, this feels similar to the case of one
> package modifying the configuration files of another package, where we
> explicitly prohibit one package modifying the configuration of another
> package except through an interface provided by the package whose
> configuration is being modified.

I'd like this to go a step further - rules, units and so on can (and
must!) be shipped by other packages, not just from src:systemd.
But as I mentioned in the other reply, bugs come to the systemd bug
tracker most often, and make our lives more difficult, even if it's a
third package that ships the configuration.
So, I'd very much want to make the rule stronger for this use case,
and forbid it even if the respective maintainers agree between
themselves that package A's unit should be diverted by package B's,
because ultimately both A and B are feeding configuration into
systemd/udev/etc, and this is just not a supported mechanism to apply
such changes.

> In other words, dpkg-divert is primarily for local administrators,
> non-Policy-compliant local packages that are doing unusual things, and the
> occasional rare problem that requires special coordination between
> packages, not something that Debian packages should be doing to other
> packages without explicit coordination.
>
> The rule about systemd and udev files doesn't entirely fall out of that
> statement, so we can still include a specific statement about them, noting
> that drop-ins and masking make dpkg-divert unnecessary (and those
> facilities produce better tool behavior) and therefore it should not be
> used.
>
> So, ideally, the way I'd prefer to move forward is for us to add a new
> section to the main Policy manual on diversions (probably 10.11), document
> that this is primarily a tool for local administrators and local packages
> to override the behavior of Debian, and that its use between Debian
> packages should be rare, should involve coordination between the packages,
> and should only be used to solve problems that cannot be handled through
> other facilities such as alternatives or package-specific tools like
> systemd's support for drop-ins and masking.  And then explicitly call out
> systemd and udev configuration as cases where dpkg-divert should not be
> used, alongside conffiles and critical system files.

Ok, I can look at adding 10.11 - I very naively searched for existing
paragraphs mentioning diverts and found the one I extended, I did not
realize it was not proper part of Policy, thanks for the pointer.

Kind regards,
Luca Boccassi

Bug#1035746: Unblock: libswe

[Stanislas Marquis]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: jald...@debian.org, s...@astrorigin.com

Hello,

I am requesting a review and unblock for package 'libswe' [1].

The new version fixes the following bug: #1034930 [2].
A file was moved from one package to another, and some information
(Breaks+Replaces) in the d/control file was missing...

You can find the related source debdiff in attachment.

Thanks for attention.

[1] https://tracker.debian.org/pkg/libswe
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034930
diff -Nru libswe-2.10.03/debian/changelog libswe-2.10.03/debian/changelog
--- libswe-2.10.03/debian/changelog 2023-02-06 07:19:48.0 +0100
+++ libswe-2.10.03/debian/changelog 2023-04-30 19:01:56.0 +0200
@@ -1,3 +1,11 @@
+libswe (2.10.03-3) unstable; urgency=medium
+
+  * Apply multi-arch hints: swetest drop Multi-Arch: same
+  * Remove gitignore file, use .git/info/exclude instead
+  * Add Replaces+Breaks to swetest (closes: #1034930)
+
+ -- Stanislas Marquis   Sun, 30 Apr 2023 19:01:56 +0200
+
 libswe (2.10.03-2) unstable; urgency=medium

   * Acknowledge NMU by Paul Gevers
diff -Nru libswe-2.10.03/debian/control libswe-2.10.03/debian/control
--- libswe-2.10.03/debian/control   2022-12-19 09:42:23.0 +0100
+++ libswe-2.10.03/debian/control   2023-04-30 19:01:56.0 +0200
@@ -81,11 +81,14 @@
 Package: swetest
 Section: misc
 Architecture: any
-Multi-Arch: same
 Depends:
  libswe2.0 (>= ${binary:Version}),
  ${shlibs
:Depends},
  ${misc:Depends},
+Replaces:
+ libswe-dev (<< 2.10.03),
+Breaks:
+ libswe-dev (<< 2.10.03),
 Suggests:
  libswe-doc (= ${binary:Version}),
  swe-data (>= 4.0-2022),


signature.asc
Description: OpenPGP digital signature

Bug#1035734: Does not search for terms in latin1 encoding anymore

[Axel Beckert]

Control: tag -1 + moreinfo

Hi Mowgli,

Klaus Ethgen wrote:
> I usually have latin1-Encoding everywhere. The output of translate is
> good but the input does not allow latin1-umlauts like ä, ö, ü, ... I can
> input them but they always returns nothing.

Interesting, thanks for the bug report.

> Older versions worked well but I cannot say, when the incompatibility
> was implemented. At least version 0.6 worked well.

Can you check which Debian package of 0.6? All recent (non-comment)
UTF-8 related changes I see in the git log seemed to have been in
0.6-6 and 0.6-7. Which actually were long ago (2005).

Just a thought: Could it be that this change in Debian's locales could
have caused some unexpected side effect on already configured
non-UTF-8 locales?

  locales (2.31-14) unstable; urgency=low

* Starting with locales 2.31-14, non UTF-8 locales are deprecated and not
  offered anymore in the debconf dialog, except for the ones already
  configured. Nevertheless users of non UTF-8 locales are encouraged to
  switch their system to an UTF-8 locale.

  Please note that iconv still supports conversion to and from non UTF-8
  charset. For instance reading a file using an ISO-8859-15 charset can be
  done with: iconv --from-code=ISO-8859-15 foobar.txt

   -- Aurelien Jarno   Tue, 17 Aug 2021 16:27:59 +0200 

> The strange thing is, that I see no reason for the bug. Even when I do
> `bash -x /usr/bin/translate ...` it DOES iconv my input. But if I just
> do `/usr/bin/translate ...`, it doesn't. This bug is a full riddle for
> me.
[…]
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set

Or could this LC_CTYPE with C.UTF-8 be the reason? Because this would
likely cause $UTF8 to be set in the script:

  UTF8=0
  if locale 2>&1 | grep -E -q "UTF-8?$"; then
  UTF8=1
  fi

Actually I just now noticed a typo in that regexp. It likely should be
"UTF-?8$" and not "UTF-8?$" (i.e. the dash is optional, not the digit
eight). That typo is now fixed in git. (I though don't think that this
typo caused your issue. It could have caused issues the other way
around: Not properly detected UTF-8 locales.)

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

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Mon, 8 May 2023 at 16:39, Sam Hartman  wrote:
>
> > "Luca" == Luca Boccassi  writes:
>
> Luca> It has come to my attention that there is one package in
> Luca> Debian using dpkg-divert to mask a systemd configuration file
> Luca> (an udev rule).  Speaking as one of the maintainers, both
> Luca> upstream and downstream, I find this greatly undesirable for
> Luca> several reasons that I will outline later. Hence I would like
> Luca> to propose explicitly mentioning that dpkg- divert must not be
> Luca> used for systemd configuration files (units, rules, etc), and
> Luca> instead the supported workflow (drop-ins, masking, etc) must
> Luca> be used, both by packages and administrators.
>
> First, I thought there was already a prohibition about one package
> mucking with another package's configuration.
> In many cases it sounds like it's already against policy for one package
> to change the default systemd or udev configuration--at least for
> packages in the archive.
> (I am skepticle that amazon-ec2-utils complies with policy in general).
>
>
> In cases where the change being made is permitted by policy, I think you
> have made a compelling case to vastly prefer the native systemd and udev
> mechanisms to dpkg-divert.
> I don't think that your case is strong enough to forbid dpkg-divert.
>
> As far as I can tell reading your reasoning, dpkg-divert *works fine*.
> It just gives surprising results to someone coming from the systemd
> universe.
>
> But consider a package that diverts several resources, several of them
> systemd and several of them not systemd.
> The maintainer might legitimately want to use the same mechanism for all
> the overriding/masking  so that systemd resources and non-systemd
> resources were handled the same.
>
> There's a real trade off there, and we generally leave those to
> maintainers.
>
> So, I'd support policy advice (ENCOURAGED) rather than policy
> requirements (MUST) in this case.
>
> I do think that if a maintainer violates this advice without a good
> reason, important is a more appropriate bug severity than wishlist, but
> unfortunately we don't have a good way to specify that in policy
> language.
>
> I would not support policy recommendation language (RECOMMENDED/SHOULD)
> because that has a connotation that failing to follow the recommendation
> is always a bug, and I don't think that's true here.

The problem is that when there are udev/systemd bugs they get directed
to the systemd team, not to the package shipping a divert, because
diverts are essentially invisible to normal users. It is already very
difficult and very time consuming to support these packages,
especially udev because we are essentially dealing with the
intersection of an infinite combination of hardware and software, and
anything that makes our lives harder is detrimental to the project at
large. If there was a significant, or even any benefit at all, then it
could be discussed, but I fail to see any. I do not find the
theoretical point about multiple diversions very compelling - we use
different mechanisms for different things all the time, but more
importantly such a case simply has never surfaced in the 10 past years
or so since we ship systemd by default, and longer since we ship udev.

Moreover, as upstream developer, I can guarantee you that masking via
diversion like this is NOT supported, and there could be more bugs
lurking, and we categorically do not intend to support or help with
such cases. I have no intention to spend any time investigating
whether such bugs exist and document them. Therefore, given there is
only one case in the whole distro so impact is minimal, the best
option to me seems to flat out forbid it, so that we never get into
that bad situation in the first place.

Kind regards,
Luca Boccassi

Bug#1035745: unblock: dash/0.5.12-4 (preapproval)

[Luca Boccassi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-debbugs-CC: andrew.shad...@collabora.co.uk

Dear Release Team,

Filing this on request of the dash maintainer. We have recently
implemented a much needed cleanup that removes an unnecessary diversion
on /bin/sh, that makes the essential set nice and clean and diversion-
free, so that it can be set up without complex machinery.

This cleanup has been uploaded last week to experimental with
dash/0.5.12-3. We have tested it and cannot see any issues with it. The
autopkgtest has been enhanced to cover the case, and a new job testing
the downgrade/upgrade paths has been added to Salsa CI.

Given it simplifies an essential package, it is my opinion that it
would be beneficial to ship this in Bookworm, hence we are filing this
book to gather your feedback.

There is one ulterior advantage: in case we decide to finish the
usrmerge transition in Trixie via diverts, this is a necessary fix for
that to work, so having this in place already in Bookworm would make
things easier on that too, in case we go down that path. [1]

dash ticket: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989632

Debdiff from current bookworm to the version in experimental attached.
Note that 0.5.12-4 does not exist yet as this is a pre-approval
request, but it would be a changelog-only upload. The only changes in
the debdiff are in the maintainer scripts to drop the diversion, and in
the added autopkgtest to cover it.

[1] https://lists.debian.org/debian-devel/2023/04/msg8.html

-- 
Kind regards,
Luca Boccassi
diff -Nru dash-0.5.12/debian/changelog dash-0.5.12/debian/changelog
--- dash-0.5.12/debian/changelog	2023-01-05 13:20:48.0 +
+++ dash-0.5.12/debian/changelog	2023-04-30 14:53:24.0 +0100
@@ -1,3 +1,19 @@
+dash (0.5.12-3) experimental; urgency=medium
+
+  [ Andrej Shadura ]
+  * Fix bug number in the patch description
+
+  [ Helmut Grohne ]
+  * dash.postinst: Remove upgrade path from pre-sarge ash. (Closes:
+#989419)
+  * Remove unnecessary diversion in case /bin/sh points to dash. (Closes:
+#989632)
+
+  [ Luca Boccassi ]
+  * dash.postinst: remove unused function
+
+ -- Andrej Shadura   Sun, 30 Apr 2023 15:53:24 +0200
+
 dash (0.5.12-2) unstable; urgency=medium
 
   * Fix the changelog entry.
diff -Nru dash-0.5.12/debian/dash.postinst dash-0.5.12/debian/dash.postinst
--- dash-0.5.12/debian/dash.postinst	2023-01-05 13:20:48.0 +
+++ dash-0.5.12/debian/dash.postinst	2023-04-30 14:53:24.0 +0100
@@ -33,7 +33,7 @@
 	diverter=$(dpkg-divert --listpackage $dfile)
 	truename=$(dpkg-divert --truename $dfile)
 
-	if [ "$diverter" = dash ]; then
+	if [ -z "$diverter" ]; then
 		# good.
 		return
 	fi
@@ -43,9 +43,9 @@
 		return
 	fi
 
-	if [ -n "$diverter" ] && [ "$diverter" != bash ]; then
-		# Let dpkg-divert error out; we are not taking
-		# over the diversion, unless we added it
+	if [ "$diverter" != bash ]; then
+		# Let dpkg-divert error out; we are not removing the
+		# diversion, unless we added it
 		# ourselves on behalf of bash.
 		dpkg-divert --package dash --no-rename --remove $dfile
 		echo "This should never be reached"
@@ -53,7 +53,6 @@
 	fi
 
 	dpkg-divert --package bash --no-rename --remove $dfile
-	dpkg-divert --package dash --no-rename --divert $distrib --add $dfile
 	# remove the old equivalent of $distrib, if it existed.
 	if [ -n "$DPKG_ROOT$truename" ]; then
 	   rm -f "$DPKG_ROOT$truename"
@@ -61,62 +60,23 @@
 	replace_with_link $dfile $ltarget $distrib
 }
 
-unclaim_binsh() {
+drop_obsolete_diversion() {
 	dfile=$1 ltarget=$2 distrib=${3:-$dfile.distrib}
-	diverter=$(dpkg-divert --listpackage $dfile)
-	truename=$(dpkg-divert --truename $dfile)
+	diverter=$(dpkg-divert --listpackage "$dfile")
+	truename=$(dpkg-divert --truename "$dfile")
+	actualtarget=$(readlink "$dfile")
 
-	if [ "$diverter" != dash ]; then
-		# good.
+	if [ "$diverter" != dash ] || [ "$truename" != "$distrib" ] || [ "$actualtarget" != "$ltarget" ]; then
+		# Not our diversion or a non-trivial one.
 		return
 	fi
-
-	# Donate the diversion and sh symlink to the bash package.
-	ltarget=$(echo $ltarget | sed s/dash/bash/)
-	dpkg-divert --package dash --no-rename --remove $dfile
-	dpkg-divert --package bash --no-rename --divert $distrib --add $dfile
-	if [ -n "$truename" ]; then
-		rm -f "$truename"
-	fi
-	replace_with_link $dfile $ltarget $distrib
-}
-
-initial_binsh_setup() {
-	dfile=$1 ltarget=$2 distrib=${3:-$dfile.distrib} ashfile=$4
-	diverter=$(dpkg-divert --listpackage $dfile)
-	truename=$(dpkg-divert --truename $dfile)
-
-	if [ -z "$diverter" ]; then
-		# good.
-		return
-	fi
-
-	if [ "$diverter" = ash ]; then
-		dpkg-divert --package ash --no-rename --remove $dfile
-		dpkg-divert --package dash --no-rename --divert $distrib --add $dfile
-
-		if [ "$truename" != "$distrib" ] && [ -e "$truename" ]; then
-			mv "$truename" "$distrib"
-		fi
-		replace_with_link $dfile $ltarget
-		

Bug#1035744: memtest86+: new upstream version

[Fabio Fantoni]

Il 08/05/2023 17:22, Christoph Anton Mitterer ha scritto:

Package: memtest86+
Version: 6.10-4
Severity: wishlist

Hey.

6.20 is out :-)

Cheers,
Chris.


Hi, Felix Zielcke already uploaded 6.20-1 into experimental, the new 
version for bookworm is too late, there is the "hard freeze" and I 
suppose Felix uploaded to experimental instead unstable to make possible 
an urgent fixes upload for bookworm if will be needed, even if I suppose 
there is very low probability to spot RC bugs on 6.10-4




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Russ Allbery]

I think your X-Debbugs-Cc was syntactically invalid and thus didn't work.
I manually added in the other addresses in this reply.

Luca Boccassi  writes:

> It has come to my attention that there is one package in Debian using
> dpkg-divert to mask a systemd configuration file (an udev rule).
> Speaking as one of the maintainers, both upstream and downstream, I find
> this greatly undesirable for several reasons that I will outline
> later. Hence I would like to propose explicitly mentioning that
> dpkg-divert must not be used for systemd configuration files (units,
> rules, etc), and instead the supported workflow (drop-ins, masking, etc)
> must be used, both by packages and administrators. This is already
> standard practice, and again there is only one instance that needs
> correcting as far as I understand, and I have already provided a bug and
> a MR for that [1][2]. So the impact of this policy change should be
> minimal, and it's mostly to ensure more such instances are accidentally
> added in the future.

> I have a draft policy update, that adds a paragraph to the dpkg-divert
> section of the policy. It is attached here, and also available on Salsa
> on my fork [3].

The part of Policy that you edited with this patch is basically
unmaintained and should ideally be removed in favor of actual Policy.  (I
had started looking at that a long time ago and then never finished.)  All
of those appendices from the old packaging manual predate better
documentation maintained elsewhere (such as in the dpkg package) and are
ambiguous with regards to whether they set requirements for Debian
packages, document things for local administrators, or something else.
The Policy manual warns that they may not be normative, and people often
don't think to read them (for good reason).

In the case of diversions, while I certainly agree with your proposed
rule, I suspect Policy should say something stronger and more general,
namely that no package in Debian should divert a file from another package
unless this is arranged cooperatively between the packages to solve some
specific (unusual) problem.  To me, this feels similar to the case of one
package modifying the configuration files of another package, where we
explicitly prohibit one package modifying the configuration of another
package except through an interface provided by the package whose
configuration is being modified.

In other words, dpkg-divert is primarily for local administrators,
non-Policy-compliant local packages that are doing unusual things, and the
occasional rare problem that requires special coordination between
packages, not something that Debian packages should be doing to other
packages without explicit coordination.

The rule about systemd and udev files doesn't entirely fall out of that
statement, so we can still include a specific statement about them, noting
that drop-ins and masking make dpkg-divert unnecessary (and those
facilities produce better tool behavior) and therefore it should not be
used.

So, ideally, the way I'd prefer to move forward is for us to add a new
section to the main Policy manual on diversions (probably 10.11), document
that this is primarily a tool for local administrators and local packages
to override the behavior of Debian, and that its use between Debian
packages should be rare, should involve coordination between the packages,
and should only be used to solve problems that cannot be handled through
other facilities such as alternatives or package-specific tools like
systemd's support for drop-ins and masking.  And then explicitly call out
systemd and udev configuration as cases where dpkg-divert should not be
used, alongside conffiles and critical system files.

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

Bug#1035106: grimripper

[Peter B]

Hi Matthias,

I'd rather not remove asunder just yet. If I receive a bug report on grimripper,
the first thing I would want to do is run asunder alongside it to compare.

Also, until grimripper is uploaded we won't know for sure if it will build on 
all architectures,
and until I get access to a Salsa repository, how the CI will go.

I actually prefer the look of asunder and am therefore more likely to continue 
to use it over grimripper.
(I realise this is subjective)

Regards,
Peter

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> It has come to my attention that there is one package in
Luca> Debian using dpkg-divert to mask a systemd configuration file
Luca> (an udev rule).  Speaking as one of the maintainers, both
Luca> upstream and downstream, I find this greatly undesirable for
Luca> several reasons that I will outline later. Hence I would like
Luca> to propose explicitly mentioning that dpkg- divert must not be
Luca> used for systemd configuration files (units, rules, etc), and
Luca> instead the supported workflow (drop-ins, masking, etc) must
Luca> be used, both by packages and administrators.

First, I thought there was already a prohibition about one package
mucking with another package's configuration.
In many cases it sounds like it's already against policy for one package
to change the default systemd or udev configuration--at least for
packages in the archive.
(I am skepticle that amazon-ec2-utils complies with policy in general).


In cases where the change being made is permitted by policy, I think you
have made a compelling case to vastly prefer the native systemd and udev
mechanisms to dpkg-divert.
I don't think that your case is strong enough to forbid dpkg-divert.

As far as I can tell reading your reasoning, dpkg-divert *works fine*.
It just gives surprising results to someone coming from the systemd
universe.

But consider a package that diverts several resources, several of them
systemd and several of them not systemd.
The maintainer might legitimately want to use the same mechanism for all
the overriding/masking  so that systemd resources and non-systemd
resources were handled the same.

There's a real trade off there, and we generally leave those to
maintainers.

So, I'd support policy advice (ENCOURAGED) rather than policy
requirements (MUST) in this case.

I do think that if a maintainer violates this advice without a good
reason, important is a more appropriate bug severity than wishlist, but
unfortunately we don't have a good way to specify that in policy
language.

I would not support policy recommendation language (RECOMMENDED/SHOULD)
because that has a connotation that failing to follow the recommendation
is always a bug, and I don't think that's true here.

--Sam

Bug#1035598: /var/lib/dpkg/info/kanboard.postinst: 24: lighty-enable-mod: not found

[Philip Carinhas]

Kanboard uses a varitey of databases and webservers.
None of those dependencies should block installation.

-Phil 

-- 
.--,
| Fortuitous Technologies  -  DevOps, Design & Development |
| A Stitch in Design Saves Nine -  http://fortuitous.com   |
| Philip Carinhas, CEO * p...@fortuitous.com * 512-351-7783 |
 `-'


signature.asc
Description: PGP signature

Bug#1035744: memtest86+: new upstream version

[Christoph Anton Mitterer]

Package: memtest86+
Version: 6.10-4
Severity: wishlist

Hey.

6.20 is out :-)

Cheers,
Chris.

Bug#1035742: lintian-brush: excessive dependencies

[Martin-Éric Racine]

On Mon, May 8, 2023 at 6:11 PM Jelmer Vernooij  wrote:
> On Mon, May 08, 2023 at 05:56:47PM +0300, Martin-Éric Racine wrote:
> > lintian-brush currently Depends on or Recommends packages that pull a large 
> > part of GNOME.
> >
> > This is excessive, especialy for a CLI tool. Please demote some of these to 
> > mere Suggests.
>
> Thanks for the bug report.
>
> Can you be more specific - which packages is it pulling in that are
> unexpected? lintian-brush has a Suggests on gnome-pkg-tools, but none of its 
> hard
> dependencies/recommends should (transitively) depend on GNOME.

python3-launchpadlib pulls everything and the kitchen sink:

$ LC_ALL=C sudo apt-get install --option
Debug::pkgDepCache::AutoInstall=true lintian-brush
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
   Installing python3-breezy:i386 as Depends of lintian-brush:i386
Installing python3-configobj:i386 as Depends of python3-breezy:i386
Installing python3-fastbencode:i386 as Depends of python3-breezy:i386
Installing python3-merge3:i386 as Depends of python3-breezy:i386
Installing python3-dulwich:i386 as Depends of python3-breezy:i386
  Installing python3-fastimport:i386 as Recommends of python3-dulwich:i386
Installing python3-patiencediff:i386 as Depends of python3-breezy:i386
Installing python3-launchpadlib:i386 as Recommends of python3-breezy:i386
  Installing python3-lazr.restfulclient:i386 as Depends of
python3-launchpadlib:i386
Installing python3-lazr.uri:i386 as Depends of
python3-lazr.restfulclient:i386
Installing python3-wadllib:i386 as Depends of
python3-lazr.restfulclient:i386
Installing python3-oauthlib:i386 as Depends of
python3-lazr.restfulclient:i386
  Installing python3-blinker:i386 as Depends of python3-oauthlib:i386
  Installing python3-jwt:i386 as Depends of python3-oauthlib:i386
  Installing python3-keyring:i386 as Recommends of python3-launchpadlib:i386
Installing python3-jaraco.classes:i386 as Depends of
python3-keyring:i386
Installing python3-jeepney:i386 as Depends of python3-keyring:i386
Installing python3-secretstorage:i386 as Depends of python3-keyring:i386
  Installing gnome-keyring:i386 as Recommends of
python3-secretstorage:i386
Installing dconf-gsettings-backend:i386 as Depends of
gnome-keyring:i386
  Installing dconf-service:i386 as Depends of
dconf-gsettings-backend:i386
Installing libdconf1:i386 as Depends of dconf-service:i386
Installing libgck-1-0:i386 as Depends of gnome-keyring:i386
Installing libgcr-base-3-1:i386 as Depends of gnome-keyring:i386
Installing gcr:i386 as Depends of gnome-keyring:i386
  Installing libgcr-ui-3-1:i386 as Depends of gcr:i386
Installing libcairo2:i386 as Depends of libgcr-ui-3-1:i386
  Installing libpixman-1-0:i386 as Depends of libcairo2:i386
  Installing libxcb-render0:i386 as Depends of libcairo2:i386
  Installing libxcb-shm0:i386 as Depends of libcairo2:i386
  Installing libxrender1:i386 as Depends of libcairo2:i386
Installing libgdk-pixbuf-2.0-0:i386 as Depends of
libgcr-ui-3-1:i386
  Installing libgdk-pixbuf2.0-common:i386 as Depends
of libgdk-pixbuf-2.0-0:i386
  Installing libgdk-pixbuf2.0-bin:i386 as Recommends
of libgdk-pixbuf-2.0-0:i386
Installing libgtk-3-0:i386 as Depends of libgcr-ui-3-1:i386
  Installing adwaita-icon-theme:i386 as Depends of
libgtk-3-0:i386
Installing hicolor-icon-theme:i386 as Depends of
adwaita-icon-theme:i386
Installing gtk-update-icon-cache:i386 as Depends
of adwaita-icon-theme:i386
Installing librsvg2-common:i386 as Recommends of
adwaita-icon-theme:i386
  Installing librsvg2-2:i386 as Depends of
librsvg2-common:i386
Installing libcairo-gobject2:i386 as Depends
of librsvg2-2:i386
Installing libpango-1.0-0:i386 as Depends of
librsvg2-2:i386
  Installing fontconfig:i386 as Depends of
libpango-1.0-0:i386
  Installing libharfbuzz0b:i386 as Depends of
libpango-1.0-0:i386
Installing libgraphite2-3:i386 as Depends
of libharfbuzz0b:i386
Installing libpangocairo-1.0-0:i386 as Depends
of librsvg2-2:i386
  Installing libpangoft2-1.0-0:i386 as Depends
of libpangocairo-1.0-0:i386
  Installing libatk-bridge2.0-0:i386 as Depends of
libgtk-3-0:i386
Installing libatk1.0-0:i386 as Depends of
libatk-bridge2.0-0:i386
  Installing at-spi2-common:i386 as Depends of
libatk1.0-0:i386
Installing libatspi2.0-0:i386 as Depends of

Bug#1029843: Missing symlinks for RPi 4 (to brcmfmac43455-sdio.raspberrypi,4-model-b.txt)

[James Addison]

On Mon, 8 May 2023 at 14:57, Diederik de Haas  wrote:
>
> On Monday, 8 May 2023 14:08:14 CEST James Addison wrote:
> > On Mon, 1 May 2023 11:18:03 +0100, James Addison  
> > wrote:
> > > > Diederik de Haas  (2023-04-30):
> > > > > And that's exactly what happens or will happen. Even though the RPi4
> > > > > filename doesn't contain spaces, there are several in the `brcm`
> > > > > directory that do. I didn't check other directories, but I'd expect
> > > > > that filenames with a space is NOT an anomaly.
> > >
> > > Since more files with that pattern are appearing upstream in
> > > linux-firmware.. yes, slightly reluctantly it does seem that this will
> > > be needed.
> >
> > FWIW: After learn the root cause of the spaces-in-filenames problem for
> > packages derived from linux-firmware.git -- that is, the contents of the
> > 'WHENCE' file in linux-firmware.git -- in fact the RPi4 is the only
> > affected[1] firmware currently.
>
> Triggered by your statement, I did a VERY crude search for spaces
> in "File: " or "Link: " lines in the WHENCE file:
>
> diederik@bagend:~/dev/kernel.org/linux-firmware$ grep -E "^Link: .* .* -> .*" 
> WHENCE
> Link: brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ 4\ 
> Model\ B.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt
> Link: brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ 
> Compute\ Module\ 4.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt
> Link: nvidia/gm206/acr/bl.bin  -> ../../gm200/acr/bl.bin
> diederik@bagend:~/dev/kernel.org/linux-firmware$ grep -E "^File: .* .*" WHENCE
> File: "brcm/brcmfmac43241b4-sdio.Intel Corp.-VALLEYVIEW C0 PLATFORM.txt"
> File: "brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-TF103CE.txt"
> File: "brcm/brcmfmac43430a0-sdio.ONDA-V80 PLUS.txt"
> File: "brcm/brcmfmac43455-sdio.MINIX-NEO Z83-4.txt"
> File: "brcm/brcmfmac4356-pcie.Intel Corporation-CHERRYVIEW D1 PLATFORM.txt"
> File: "brcm/brcmfmac4356-pcie.Xiaomi Inc-Mipad2.txt"

Ah, okie doke.  Thanks for catching those.

> The last "Link: " line can be ignored due to being too crude ...
> but it does appear that it ONLY exists in the `brcm` directory ...
>
> > (that surprised me, but does seem to be the case.  I'm writing to counteract
> > any sense that the proposed patch[2] could affect and fix many firmwares.
> > it won't, at least not today)
> >
> > [2] -
> > https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/65
>
> https://lore.kernel.org/linux-firmware/20230301-fixes-and-compression-v2-0-e2b71974e...@gmail.com/
> seems related as f.e. 1 patch deals with the inconsistent " " vs "\ ".
>
> While I was inclined based on my findings above to mark it as an anomaly,
> that patch set seems to indicate that the spaces won't be removed in
> the future, just that its use would probably more consistent.

Ok, thanks again; perhaps it's worthwhile waiting a little longer for
upstream to decide on the preferred line format(s) they'll accept.

Bug#1035742: lintian-brush: excessive dependencies

[Jelmer Vernooij]

Hi Martin-Éric,

On Mon, May 08, 2023 at 05:56:47PM +0300, Martin-Éric Racine wrote:
> lintian-brush currently Depends on or Recommends packages that pull a large 
> part of GNOME.
> 
> This is excessive, especialy for a CLI tool. Please demote some of these to 
> mere Suggests.

Thanks for the bug report.

Can you be more specific - which packages is it pulling in that are
unexpected? lintian-brush has a Suggests on gnome-pkg-tools, but none of its 
hard
dependencies/recommends should (transitively) depend on GNOME.

Jelmer

Bug#1035743: ITP: node-vscode-ws-jsonrpc -- Node.js module to implement jsonrpc client-server communication over WebSocket

[Yadd]

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

* Package name: node-vscode-ws-jsonrpc
  Version : 3.0.0
  Upstream Contact: https://github.com/TypeFox/monaco-languageclient/issues
* URL : https://github.com/TypeFox/monaco-languageclient
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js module to implement jsonrpc client-server 
communication over WebSocket

node-vscode-ws-jsonrpc is a module designed to implement communication
between a jsonrpc client and server over WebSocket.

It's a dependency fo JupyterLab. It'll be maintained under JS Team
umbrella.

Bug#1035592: Info received (Bug#1035592: openbox: Openbox does not present a desktop)

[Mateusz Łukasik]

Control: severity -1 normal

Bug#1035742: lintian-brush: excessive dependencies

[Martin-Éric Racine]

Package: lintian-brush
Version: 0.147
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

lintian-brush currently Depends on or Recommends packages that pull a large 
part of GNOME.

This is excessive, especialy for a CLI tool. Please demote some of these to 
mere Suggests.

Thanks!

Martin-Éric

- -- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (900, 'unstable')
Architecture: i386 (x86_64)

Kernel: Linux 5.10.0-22-amd64 (SMP w/4 CPU threads)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages lintian-brush depends on:
ii  devscripts   2.23.4
ii  python3  3.11.2-1+b1
pn  python3-asyncpg  
pn  python3-breezy   
ii  python3-debian   0.1.49
pn  python3-debmutate
ii  python3-distro-info  1.5
pn  python3-dulwich  
pn  python3-iniparse 
pn  python3-iso8601  
pn  python3-levenshtein  
pn  python3-pyinotify
pn  python3-ruamel.yaml  
pn  python3-semver   
pn  python3-tomlkit  
pn  python3-tqdm 
pn  python3-upstream-ontologist  

Versions of packages lintian-brush recommends:
ii  debhelper  13.11.4
pn  decopy 
pn  dos2unix   
ii  gpg2.2.40-1.1
ii  lintian2.116.3
pn  ognibuild  
ii  python3-bs44.11.2-2
ii  python3-debianbts  4.0.1
pn  python3-docutils   
ii  python3-lxml   4.9.2-1+b1
pn  python3-markdown   

Versions of packages lintian-brush suggests:
pn  brz-debian 
ii  git-buildpackage   0.9.30
pn  gnome-pkg-tools
ii  po-debconf 1.0.21+nmu1
pn  postgresql-common  

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmRZDawACgkQrh+Cd8S0
17ZnQg/8C9WOCIKjQQ0rKZNyYmxl4d4/3SmrpWIQ0KZMZWKshw78uDVGA5S/J9mI
4yyoCQclBGGNmpxDg7IrqVHguABNO6/ddEcq/hBKNlt7d6Myj6Kwr0ImcZGAP0w1
4OtwBMHP6tAIJ4btwjLM8C2oXv0xf5s/TfM2h1EouGhutNi5AWLxI8S7VXvPNj9M
zdeSK+FqM7mtjBJdjYL20fo812CAe8/DzUaW2a/Y1ffEf8mflJvPrTKPEkidV+3G
sTcMUWMZWBkWKfzCDIlUvaea/edNnY0rz9R8ngURTqgcNHON5DbDwratg/8EyKAC
iyOHs3GGVcTID8tOnfEJ0SYfFwl2p92ErBnTKXCN8VBOdoG37+KS2likmIgcvl2z
wJI9+vGHn/feauF3MVRYU6+HOAjojYffZq+XawsccPocUPaU6UqDuZJ8530gHuQj
vRsD1oUbA4BEJ2yTr1RZV0KFQ++tAyPdSpjTe/X9ug5ds3te+Q9vVSyTmy/TI3aE
e9GuzpdFH5eoZr5hV60m+n6BKgXT3/hOjZEC66xJ8981YHyv+BrIIjWOISR3Nr/x
CdApCuK4g3akV+4nubedKbwOsntyeT7ELqHQ+7KsEgVio7tOzDIbsr/cAs05fOFg
33bqPNdC0C4jkIsexhCczo2h+VYiGcxPm42ceNRX/B0wrfoaVdc=
=U5fo
-END PGP SIGNATURE-

Bug#1035740: watchdog: After removing the watchdog package from the system, systemd shows the wd_keepalive service as failed.

[Javier Miqueleiz (ethereal)]

Package: watchdog
Severity: normal
X-Debbugs-Cc: jav...@miqueleiz.com


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

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

Versions of packages watchdog depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9
ii  sysvinit-utils [lsb-base]  3.06-4
ii  udev   252.6-1

watchdog recommends no packages.

watchdog suggests no packages.
--


Steps to reproduce:
--
# Make a clean install of Debian 12

# Update the system to the latest packages available
apt update && apt upgrade

# Install watchdog
apt install watchdog

# Check for failed systemd units
systemctl list-units --state=failed
  UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

# Remove watchdog from the system
apt purge watchdog
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  watchdog*
0 upgraded, 0 newly installed, 1 to remove and 2 not upgraded.
After this operation, 234 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 168525 files and directories currently installed.)
Removing watchdog (5.16-1+b2) ...
Processing triggers for man-db (2.11.2-2) ...
(Reading database ... 168497 files and directories currently installed.)
Purging configuration files for watchdog (5.16-1+b2) ...

# Check systemd status
systemctl is-system-running
degraded

# Check for failed systemd units
systemctl list-units --state=failed
  UNIT LOAD  ACTIVE SUBDESCRIPTION 
● wd_keepalive.service not-found failed failed wd_keepalive.service

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB= The low-level unit activation state, values depend on unit type.
1 loaded units listed.
--


--
#In order the return systemd to the normal "running" status, the 
wd_keepalive.service must be reset:
systemctl reset-failed wd_keepalive.service

# Now everything looks fine again
systemctl is-system-running
running


Expected results:
I think the package removing process should go more smoothly. Leaving systemd 
status as "degraded" can be problematic, especially if there is some monitoring 
software checking system status.

Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script

[James McCoy]

On Sat, May 06, 2023 at 04:07:56PM +0200, Gabriel Corona wrote:
> Hi,
> 
> > In the mean time, it's probably a good idea to drop
> > "application/x-sh;application/x-shellscript" from the list of supported
> > mime type to limit the risk. (I assume that even with "text/plain" and a
> > .sh file extension or a shebang, kitty might still decide to execute the
> > script... so the issue is not entirely fixed, but it reduces the number
> > of
> > cases where "kitty +open" is invoked on shell scripts)
> 
> Indeed, you can use a file with MIME type such as text/ascii or
> x-scheme-handler/kitty and a .tool file extension and it will be executed
> through kitty.
> 
> Affected software include: mail clients (mutt, Thunderbird [3,4]), browsers
> (Firefox [1,2]), PDF viewers (Okular [5]).
> 
> [1] https://www.gabriel.urdhr.fr/img/kitty-firefox1.png
> [2] https://www.gabriel.urdhr.fr/img/kitty-firefox2.png
> [3] https://www.gabriel.urdhr.fr/img/kitty-thunderbird1.png
> [4] https://www.gabriel.urdhr.fr/img/kitty-thunderbird2.png

The above examples prompt the user, so they're making an explicit
choice.  That's less of an issue.

> > Or it's the users responsibility to configure their system to
> > view shell files rather than execute them, if they are in the habit of
> > clicking exe's attached to emails or otherwise clicking untrusted shell
> > scripts.
> 
> Or it is our responsibility to ship with a secure by default configuration?

I'm leaning towards shipping kitty-open.desktop under
/usr/share/doc/kitty/examples and adding a note to README.Debian about
how to install it and the implications.  I've not used this particular
functionality of Kitty, so I'm not sure how this will change the usual
user experience.

However, I think this is a safer default and provides more information
to the user.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1035706: ITP: plume-util-java -- Plume-lib utility libraries for Java

[Gabriel Collado Rodríguez]

Ok, good 郎郎郎郎郎郎郎郎郎郎郎

El lun, 8 may 2023 3:09, Olek Wojnar  escribió:

> Package: wnpp
> Severity: wishlist
> Owner: Olek Wojnar 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: plume-util-java
>   Version : 1.1.0
>   Upstream Author : Michael Ernst 
> * URL : https://github.com/plume-lib/plume-util
> * License : MIT
>   Programming Lang: Java
>   Description : Plume-lib utility libraries for Java
>
>  Various Java utility libraries from the plume-lib project. These include:
>  collections and iterators, text processing, math, random selection,
>  determinism and immutability, utility interfaces, and the JVM runtime
> system.
>
> This package is needed to build the full Checker Framework package which is
> in turn needed for Bazel version 5.
>
>

Bug#1035734: Acknowledgement (Does not search for terms in latin1 encoding anymore)

[Klaus Ethgen]

Hoi Axel,

I found the bug. The bug is in the color code.

The replacement of $SEARCH in the new display function can never match
for latin1 chars as it is still UTF-8. So either use the original search
string here or convert it back to local locale.

Gruß
   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#1029843: Missing symlinks for RPi 4 (to brcmfmac43455-sdio.raspberrypi,4-model-b.txt)

[Diederik de Haas]

On Monday, 8 May 2023 14:08:14 CEST James Addison wrote:
> On Mon, 1 May 2023 11:18:03 +0100, James Addison  wrote:
> > > Diederik de Haas  (2023-04-30):
> > > > And that's exactly what happens or will happen. Even though the RPi4
> > > > filename doesn't contain spaces, there are several in the `brcm`
> > > > directory that do. I didn't check other directories, but I'd expect
> > > > that filenames with a space is NOT an anomaly.
> > 
> > Since more files with that pattern are appearing upstream in
> > linux-firmware.. yes, slightly reluctantly it does seem that this will
> > be needed.
> 
> FWIW: After learn the root cause of the spaces-in-filenames problem for
> packages derived from linux-firmware.git -- that is, the contents of the
> 'WHENCE' file in linux-firmware.git -- in fact the RPi4 is the only
> affected[1] firmware currently.

Triggered by your statement, I did a VERY crude search for spaces
in "File: " or "Link: " lines in the WHENCE file:

diederik@bagend:~/dev/kernel.org/linux-firmware$ grep -E "^Link: .* .* -> .*" 
WHENCE 
Link: brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ 4\ 
Model\ B.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt
Link: brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ Compute\ 
Module\ 4.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt
Link: nvidia/gm206/acr/bl.bin  -> ../../gm200/acr/bl.bin
diederik@bagend:~/dev/kernel.org/linux-firmware$ grep -E "^File: .* .*" WHENCE 
File: "brcm/brcmfmac43241b4-sdio.Intel Corp.-VALLEYVIEW C0 PLATFORM.txt"
File: "brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-TF103CE.txt"
File: "brcm/brcmfmac43430a0-sdio.ONDA-V80 PLUS.txt"
File: "brcm/brcmfmac43455-sdio.MINIX-NEO Z83-4.txt"
File: "brcm/brcmfmac4356-pcie.Intel Corporation-CHERRYVIEW D1 PLATFORM.txt"
File: "brcm/brcmfmac4356-pcie.Xiaomi Inc-Mipad2.txt"

The last "Link: " line can be ignored due to being too crude ...
but it does appear that it ONLY exists in the `brcm` directory ...

> (that surprised me, but does seem to be the case.  I'm writing to counteract
> any sense that the proposed patch[2] could affect and fix many firmwares. 
> it won't, at least not today)
> 
> [2] -
> https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/65

https://lore.kernel.org/linux-firmware/20230301-fixes-and-compression-v2-0-e2b71974e...@gmail.com/
seems related as f.e. 1 patch deals with the inconsistent " " vs "\ ".

While I was inclined based on my findings above to mark it as an anomaly,
that patch set seems to indicate that the spaces won't be removed in
the future, just that its use would probably more consistent.

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

Bug#1035739: securefs: Autopkg test-failure

[Heinrich Schuchardt]

Package: securefs
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
X-Debbugs-Cc: heinrich.schucha...@canonical.com

Dear Maintainer,

Autopkgtests fail. This is fixed for amd64, arm64, ppc64el with this
patch.

  * Set SECUREFS_BINARY in debian/test/control (LP: #2018707).

Thanks for considering the patch.


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

Kernel: Linux 6.2.0-21-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru securefs-0.13.1+ds/debian/tests/control 
securefs-0.13.1+ds/debian/tests/control
--- securefs-0.13.1+ds/debian/tests/control 2023-01-27 03:31:37.0 
+0100
+++ securefs-0.13.1+ds/debian/tests/control 2023-05-08 07:14:48.0 
+0200
@@ -1,4 +1,4 @@
-Test-Command: cd obj-x86_64-linux-gnu && python3 ../test/simple_test.py
+Test-Command: cd obj-`dpkg-architecture -q DEB_BUILD_GNU_TYPE` && 
SECUREFS_BINARY=`pwd`/securefs python3 ../test/simple_test.py
 Depends: fuse,
  libcrypto++-dev,
  libfuse-dev,
@@ -7,6 +7,6 @@
  python3
 Restrictions: build-needed, isolation-machine, allow-stderr
 
-Test-Command: cd obj-x86_64-linux-gnu && ./securefs_test
+Test-Command: cd obj-`dpkg-architecture -q DEB_BUILD_GNU_TYPE` && 
./securefs_test
 Depends: fuse, libcrypto++-dev, libfuse-dev, libjsoncpp-dev, libutf8proc-dev
 Restrictions: build-needed, allow-stderr

Bug#1035106: grimripper

[matthias . geiger1024]

Hi all.

I actually had this on my to-do list, since I regularly use asunder and was 
involved in the new upstream for a bit.

First of all, thanks for your work on the package, Peter. 

A few comments:
Since asunder is not getting any updates and it relies upon the very much 
deprecated GTK2 that package can safely go imho (also since the dev didn't see 
the necessity to upgrade to GTK3, see #967259 and 
https://littlesvr.ca/bugs/show_bug.cgi?id=59 ). (Note that GTK2 has been 
superseded in 2011 ! )

 Grimripper should have a breaks/replaces then, so asunder can be removed for 
trixie and be replaced by it. 

Imho you don't need to take over asunder then since a newer version is present.
I'd maintain it either under the Multimedia or gnome umbrella. 

I didn't have time to take a proper look at the package yet, I will do so on 
the weekend.

Gusnan: I planned on co-maintaining it (myself), but now someone picked it up 
:) . Maybe you want to be a comaintainer ?

regards,

---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1035738: O: csmash -- table tennis simulation game

[Bastian Germann]

Package: wnpp

The last csmash upload by the Maintainer was in 2005, so I am orphaning this 
package now.
It had 9 Non-maintainer uploads since.