Bug#1031850: gcc-13: Change "loongarch64-linux-gnuf64" into "loongarch64-linux-gnu"

[zhangdandan]

Package: gcc-13
Version: 13-20230215
Severity: wishlist
Tags: patch
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear gcc maintainers,

We have recently decided to use "loongarch64-linux-gnu" as the value of 
the multiarch tuple for the Debian loong64 port [1].
We are very sorry for all the trouble around the loong64 port's 
multiarch tuple definitions.


Please see the upstream LoongArch gcc's latest change [2][3] and 
LoongArch Toolchain Conventions [4].
The LoongArch LP64D ABI multiarch tuple has been changed from 
"loongarch64-linux-gnuf64" to "loongarch64-linux-gnu".


We are notifying people upfront about this change.
We may explain if you are uncertain about any details.

In addition I added LoongArch64's multiarch changes in personal 
rebootstrap project [5] (as a reference).


[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028654#30
[2]: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612272.html
[3]: https://github.com/gcc-mirror/gcc/commit/017849d9d88f02
[4]: 
https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html#_gnu_target_triplets_and_multiarch_specifiers
[5]: 
https://salsa.debian.org/zhangdandan/rebootstrap/-/commit/0930e4b1493421cea77b688b53eb834033cad618#f201da200aae3ddf67aa94717afd6ebc5ce93c94_876_914



Thanks,
Dandan Zhang

Bug#46598: Hola

[maximo avendaño caniu]

Su Microsoft 365 necesita una actualización de servicio hoy para mantener un 
buen servicio de correo electrónico. Para activar esta actualización, haga clic 
en VER/014327 para continuar.

Servicio de mesa

Bug#1031849: Mention actual GitHub URL in copyright

[Dan Jacobson]

Package: libgeo-inverse-perl
Version: 0.07-1
File: /usr/share/doc/libgeo-inverse-perl/copyright

$ dlocate -L libgeo-inverse-perl|xargs zgrep -i github
/usr/share/doc/libgeo-inverse-perl/CONTRIBUTING.md:Fork repository on GitHub 
and submit a pull request.
/usr/share/doc/libgeo-inverse-perl/changelog.gz:  - Added GitHub repository
/usr/share/man/man3/Geo::Inverse.3pm.gz:Please open an issue on GitHub
/usr/share/perl5/Geo/Inverse.pm:Please open an issue on GitHub

Somewhere the actual GitHub URL should please be mentioned, e.g., in the
copyright file.

Above it says he "added the GitHub repository", but no exact URL is
given. OK, maybe I'll also remind him about that. No I won't, as we
are supposed to tell him on GitHub, but try as I might, I really can't
find it. So... I give up!

Bug#1031800: mmdebstrap: --keyring doesn't work properly

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-02-24 06:31:03)
> > I also think I found the source of your problem. I reproduced your issue
> > locally like this:
> >
> > sq key generate --userid "" --export juliet.key.pgp
> > sq key extract-cert --output juliet.cert.pgp juliet.key.pgp
> > apt-ftparchive release . > Release
> > sq sign --signer-key juliet.key.pgp --cleartext-signature 
> > --output=InRelease Release
> > mmdebstrap --keyring=/home/josch/repo/ --variant=apt unstable /dev/null 
> > http://deb.debian.org/debian "deb copy:///home/josch/repo ./"
> > [...]
> > I: running apt-get update...
> > done
> > Get:1 copy:/home/josch/repo ./ InRelease [1190 B]
> > Get:2 http://deb.debian.org/debian unstable InRelease [180 kB]
> > Err:1 copy:/home/josch/repo ./ InRelease
> >   The following signatures couldn't be verified because the public key is 
> > not available: NO_PUBKEY FC8F3FACCD368D66
> > Get:3 http://deb.debian.org/debian unstable/main arm64 Packages [9282 kB]
> > Reading package lists...
> > W: GPG error: copy:/home/josch/repo ./ InRelease: The following signatures 
> > couldn't be verified because the public key is not available: NO_PUBKEY 
> > FC8F3FACCD368D66
> > E: The repository 'copy:/home/josch/repo ./ InRelease' is not signed.
> >
> >
> > This is your problem, right?
> 
> This looks exactly like my problem, yes.
> 
> 
> > mv juliet.cert.pgp juliet.cert.asc
> >
> > The clue can be found in the man page of apt-key:
> >
> >Alternatively, if all systems which should be using the created 
> > keyring
> >have at least apt version >= 1.4 installed, you can use the ASCII
> >armored format with the "asc" extension instead which can be created
> >with gpg --armor --export.
> >
> > Can you confirm that you also had a ASCII armored key stored with the .gpg
> > extension instead of .asc and that changing the extension makes apt happy?
> 
> Doesn't work for me. I exported the public key both in binary and ascii
> formats, put them both in the keys/ directory (given to --keyring), and
> I get the same error as before. The keys are there:
> 
>   $ file keys/KEY.{asc,gpg}
> 
>   keys/KEY.asc: PGP public key block Public-Key (old)
>   keys/KEY.gpg: OpenPGP Public Key Version 4, Created Wed Feb 22 22:07:13 
> 2023, RSA (Encrypt or Sign, 4096 bits); User ID; Signature; OpenPGP 
> Certificate
> 
> And once again, I can confirm that the keys are right because copying
> them (or just one) to /etc/apt/trusted.gpg.d/ makes it happy. Is there
> no way to ask apt for diagnostics? Should I reassign this bug report to apt?

There may be some apt debugging options for this but one usually has to read
the apt sources to find the name of those options. Since you are able to
reproduce your problem without mmdebstrap but with apt only using the script
above, this problem is definitely not due to mmdebstrap but is either an apt
problem or a problem of how you try using apt. Either way, I think it's best to
get the apt maintainers involved.

The weirdest thing about your bug is that copying your key to
/etc/apt/trusted.gpg.d/ makes it work for you because when you changed the
location of Dir::Etc::TrustedParts it just pointed to a different directory.
Apt should not treat keys differently just because the path to them looks
different...

Thanks!

cheers, josch

Bug#1017436: meson: deprecation warning when cross-compiling: foo_args in the [properties] section of the machine file is deprecated

[Helmut Grohne]

Hi Jussi,

On Sun, Aug 28, 2022 at 10:57:00PM +0300, Jussi Pakkanen wrote:
> The first step would be to change the default packaging rules to stop
> using debcrossgen. This is now possible since there is a new enough
> Meson version in unstable. What's the correct way of getting that
> default changed?

I think you know, but let's include the answer here for clarity: You
change debcrossgen to become a wrapper of env2mfile. However doing so
requires that env2mfile actually works and last time you attempted this,
env2mfile was so horribly broken that I had to upload an emergency
reversion. So please retry after having verified that env2mfile actually
works well enough to support some use cases and preferrably also fixes
some of the bugs we reported such as this one, #895636, #1019413 and
#1023744.

And yeah, I know it's always the wrong time. When you read this mail
Debian is in freeze or meson is in freeze or both. I'm not asking to do
this now, but maybe letting such bugs rot for four years is not the best
answer either. The current process of pinging you until there is a
convenient time does not work well.

Helmut

Bug#1031848: Need fallback mirrors for VideoLAN download

[Daniel Richard G.]

Package: libdvd-pkg
Version: 1.4.3-1-1

The VideoLAN download site has been fairly robust over time, but today I
encountered this:

# dpkg-reconfigure libdvd-pkg
libdvd-pkg: Downloading orig source...
I: libdvdcss_1.4.3
/usr/bin/wget --tries=3 --timeout=40 --read-timeout=40 --continue -O 
libdvdcss_1.4.3.orig.tar.bz2 \
  
https://download.videolan.org/pub/libdvdcss/1.4.3/libdvdcss-1.4.3.tar.bz2 \
|| /usr/bin/uscan --noconf --verbose --rename 
--destdir=/usr/src/libdvd-pkg --check-dirname-level=0 --force-download 
--download-current-version /usr/share/libdvd-pkg/debian
--2023-02-23 23:25:59--  
https://download.videolan.org/pub/libdvdcss/1.4.3/libdvdcss-1.4.3.tar.bz2
Resolving download.videolan.org (download.videolan.org)... 213.36.253.2, 
2a01:e0d:1:3:58bf:fa02:c0de:5
Connecting to download.videolan.org 
(download.videolan.org)|213.36.253.2|:443... failed: Connection timed out.
Connecting to download.videolan.org 
(download.videolan.org)|2a01:e0d:1:3:58bf:fa02:c0de:5|:443... failed: Network 
is unreachable.
/bin/sh: 3: /usr/bin/uscan: not found
make: *** [/usr/share/libdvd-pkg/debian/rules:24: get-orig-source] Error 127


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1031800: mmdebstrap: --keyring doesn't work properly

[Dima Kogan]

Johannes Schauer Marin Rodrigues  writes:

> you were now able to reproduce the problem without mmdebstrap but with
> plain apt. This suggests that your problem is not an mmdebstrap
> problem.

OK. Good to know.


>> And I have another related question. I can workaround this by copying my keys
>> to /etc/apt/trusted.gpg.d/ on the host. This makes mmdebstrap happy, but the
>> resulting chroot doesn't have my keys in ITS /etc/apt/trusted.gpg.d. So an
>> "apt update" inside the chroot has the same problem as before: complaining
>> that my repo is unverifiable. The docs aren't clear on whether those keys are
>> supposed to be copied or not. Are they? If not, am I supposed to do that
>> manually via an mmdebstrap hook?
>
> mmdebstrap will not automatically copy the keys it needs to some location into
> the chroot. If your chroot needs extra key material for later "apt update" 
> runs
> it's up to you to copy the keys into the chroot at a location you like.

Thanks.




> I also think I found the source of your problem. I reproduced your issue
> locally like this:
>
> sq key generate --userid "" --export juliet.key.pgp
> sq key extract-cert --output juliet.cert.pgp juliet.key.pgp
> apt-ftparchive release . > Release
> sq sign --signer-key juliet.key.pgp --cleartext-signature --output=InRelease 
> Release
> mmdebstrap --keyring=/home/josch/repo/ --variant=apt unstable /dev/null 
> http://deb.debian.org/debian "deb copy:///home/josch/repo ./"
> [...]
> I: running apt-get update...
> done
> Get:1 copy:/home/josch/repo ./ InRelease [1190 B]
> Get:2 http://deb.debian.org/debian unstable InRelease [180 kB]
> Err:1 copy:/home/josch/repo ./ InRelease
>   The following signatures couldn't be verified because the public key is not 
> available: NO_PUBKEY FC8F3FACCD368D66
> Get:3 http://deb.debian.org/debian unstable/main arm64 Packages [9282 kB]
> Reading package lists...
> W: GPG error: copy:/home/josch/repo ./ InRelease: The following signatures 
> couldn't be verified because the public key is not available: NO_PUBKEY 
> FC8F3FACCD368D66
> E: The repository 'copy:/home/josch/repo ./ InRelease' is not signed.
>
>
> This is your problem, right?

This looks exactly like my problem, yes.


> mv juliet.cert.pgp juliet.cert.asc
>
> The clue can be found in the man page of apt-key:
>
>Alternatively, if all systems which should be using the created keyring
>have at least apt version >= 1.4 installed, you can use the ASCII
>armored format with the "asc" extension instead which can be created
>with gpg --armor --export.
>
> Can you confirm that you also had a ASCII armored key stored with the .gpg
> extension instead of .asc and that changing the extension makes apt happy?

Doesn't work for me. I exported the public key both in binary and ascii
formats, put them both in the keys/ directory (given to --keyring), and
I get the same error as before. The keys are there:

  $ file keys/KEY.{asc,gpg}

  keys/KEY.asc: PGP public key block Public-Key (old)
  keys/KEY.gpg: OpenPGP Public Key Version 4, Created Wed Feb 22 22:07:13 2023, 
RSA (Encrypt or Sign, 4096 bits); User ID; Signature; OpenPGP Certificate

And once again, I can confirm that the keys are right because copying
them (or just one) to /etc/apt/trusted.gpg.d/ makes it happy. Is there
no way to ask apt for diagnostics? Should I reassign this bug report to
apt?

Thanks

Bug#1031847: gnome-shell: Gnome crashes when laptop connected to ThinkPad Universal Thunderbolt 4 Dock (40B0), Oh no! Something has gone wrong error appears.

[Kuba]

Package: gnome-shell
Version: 43.3-1
Severity: important
X-Debbugs-Cc: lxk...@wp.pl

Bug is described here: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6162
and if I understand correctly, it is diagnosed as some dependency issue.

The crash occures every time both when the system is powered on connected to
the dock (the moment login screen is beginning to be displayed), and also when
dock is connected to the system which is already loged in.

same happens with version 43.2-2

logs:

2023-02-24T05:10:57.774 66659682 - kernel[-] INFO thunderbolt 0-3: new device
found, vendor=0x108 device=0x2031
2023-02-24T05:10:57.774 66659753 - kernel[-] INFO thunderbolt 0-3: Lenovo
ThinkPad Thunderbolt 4 Dock
2023-02-24T05:11:01.867 70753222 user@1000.service -[2534] WARNING
g_hash_table_steal_extended: assertion 'hash_table != NULL' failed
2023-02-24T05:11:01.870 70755611 user@1000.service -[2534] STATS Created gbm
renderer for '/dev/dri/card1'
2023-02-24T05:11:01.870 70755697 user@1000.service -[2534] WARNING Secondary
GPU initialization failed (Failed to create gbm_surface: Operation not
permitted). Falling back to GPU-less mode instead, so the secondary monitor may
be slow to update.
2023-02-24T05:11:02.074 70960398 user@1000.service gnome-shell[2534] INFO
free(): double free detected in tcache 2
2023-02-24T05:11:02.074 70960398 user@1000.service gnome-shell[2534] INFO
malloc_consolidate(): unaligned fastbin chunk detected
2023-02-24T05:11:02.112 70998396 init.scope systemd[1] INFO Created slice
system-systemd\x2dcoredump.slice - Slice /system/systemd-coredump.
2023-02-24T05:11:02.140 71026377 init.scope systemd[1] INFO Started systemd-
coredump@0-4996-0.service - Process Core Dump (PID 4996/UID 0).
2023-02-24T05:11:02.908 71794339 systemd-coredump@0-4996-0.service systemd-
coredump[5000] CRITICAL null
2023-02-24T05:11:02.949 71834655 user@1000.service gnome-shell[3080] INFO (EE)
failed to read Wayland events: Connection reset by peer
...


$ sudo coredumpctl list
TIME  PID  UID  GID SIG COREFILE EXE
SIZE
Fri 2023-02-24 05:11:02 CET  2534 1000 1000 SIGABRT present  /usr/bin/gnome-
shell 17.9M
Fri 2023-02-24 05:11:06 CET  5136  113  122 SIGABRT present  /usr/bin/gnome-
shell 11.9M
Fri 2023-02-24 05:11:14 CET  5716  113  122 SIGABRT present  /usr/bin/gnome-
shell 12.0M
Fri 2023-02-24 05:11:16 CET  6190  113  122 SIGABRT present  /usr/bin/gnome-
shell 11.8M


$ sudo DEBUGINFOD_URLS="https://debuginfod.debian.net; coredumpctl debug -r
2534
   PID: 2534 (gnome-shell)
   UID: 1000 (doubleloop)
   GID: 1000 (doubleloop)
Signal: 6 (ABRT)
 Timestamp: Fri 2023-02-24 05:11:02 CET (3min 13s ago)
  Command Line: /usr/bin/gnome-shell
Executable: /usr/bin/gnome-shell
 Control Group:
/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@wayland.service
  Unit: user@1000.service
 User Unit: org.gnome.Shell@wayland.service
 Slice: user-1000.slice
 Owner UID: 1000 (doubleloop)
   Boot ID: 7639b4595d8145d49b41c42e90656ad2
Machine ID: ae7bc147e6524501b468de6ed742a1a0
  Hostname: floydP1d
   Storage: /var/lib/systemd/coredump/core.gnome-
shell.1000.7639b4595d8145d49b41c42e90656ad2.2534.167721186200.zst (present)
  Size on Disk: 17.9M
   Message: Process 2534 (gnome-shell) of user 1000 dumped core.

Module libnss_mymachines.so.2 from deb systemd-252.5-2.amd64
Module libnss_myhostname.so.2 from deb systemd-252.5-2.amd64
Module libudev.so.1 from deb systemd-252.5-2.amd64
Module libsystemd.so.0 from deb systemd-252.5-2.amd64
Stack trace of thread 2534:
#0  0x7f6e31aa9ccc __pthread_kill_implementation (libc.so.6
+ 0x8accc)
#1  0x7f6e31a5aef2 __GI_raise (libc.so.6 + 0x3bef2)
#2  0x7f6e31a45472 __GI_abort (libc.so.6 + 0x26472)
#3  0x7f6e31a9e2d0 __libc_message (libc.so.6 + 0x7f2d0)
#4  0x7f6e31ab364a malloc_printerr (libc.so.6 + 0x9464a)
#5  0x7f6e31ab40ac malloc_consolidate (libc.so.6 + 0x950ac)
#6  0x7f6e31ab66b8 _int_malloc (libc.so.6 + 0x976b8)
#7  0x7f6e31ab7799 __GI___libc_malloc (libc.so.6 + 0x98799)
#8  0x7f6e31a9476c __GI__IO_file_doallocate (libc.so.6 +
0x7576c)
#9  0x7f6e31aa1f50 __GI__IO_doallocbuf (libc.so.6 +
0x82f50)
#10 0x7f6e31aa1318 _IO_new_file_overflow (libc.so.6 +
0x82318)
#11 0x7f6e31aa04de _IO_new_file_xsputn (libc.so.6 +
0x814de)
#12 0x7f6e31a954a9 __GI__IO_fputs (libc.so.6 + 0x764a9)
#13 0x7f6e32b45325 n/a (libglib-2.0.so.0 + 0x5b325)
#14 0x7f6e32b47de2 g_printerr (libglib-2.0.so.0 + 0x5dde2)
#15 

Bug#1031846: installation-reports: Same as bug #1031806 Install completes successfully after reboot no /home /Documents etc folders

[Jason]

Package: installation-reports
Severity: important
X-Debbugs-Cc: mtx_li...@hotmail.com

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: 
https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/debian-bookworm-DI-alpha2-amd64-netinst.iso
Date: 

Machine: Lenovo Thinkpad Edge E420
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [o ]
Detect network card:[o ]
Configure network:  [o ]
Detect media:   [o ]
Load installer modules: [o ]
Clock/timezone setup:   [o ]
User/password setup:[o ]
Detect hard drives: [o ]
Partition hard drives:  [o ]
Install base system:[o ]
Install tasks:  [o ]
Install boot loader:[o ]
Overall install:[o ]

Comments/Problems: None of the folders /Documents /Pictures /Videos /Downloads 
etc are present




Please make sure that any installation logs that you think would
be useful are attached to this report. (You can find them in the
installer system in /var/log/ and later on the installed system
under /var/log/installer.) Please compress large files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230217"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux e420debian 6.1.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.8-1 
(2023-01-29) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core 
Processor Family DRAM Controller [8086:0104] (rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd 
Generation Core Processor Family PCI Express Root Port [8086:0101] (rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd 
Generation Core Processor Family Integrated Graphics Controller [8086:0116] 
(rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:21e3]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 6 
Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 
Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series 
Chipset Family High Definition Audio Controller [8086:1c20] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b4)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 2 [8086:1c12] (rev b4)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 3 [8086:1c14] (rev b4)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 4 [8086:1c16] (rev b4)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.7 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 8 [8086:1c1e] (rev b4)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 
Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation HM65 Express Chipset 
LPC Controller [8086:1c49] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 
Series 

Bug#1020192: Remove cycle-quotes from Debian? (was: Re: Bug#1020192: cycle-quotes: FTBFS: make: *** [debian/rules:4: build] Error 25)

[Sergio Durigan Junior]

On Sunday, October 02 2022, David Bremner wrote:

> Lucas Nussbaum  writes:
>
>> Source: cycle-quotes
>> Version: 0.1-4
>> Severity: serious
>> Justification: FTBFS
>> Tags: bookworm sid ftbfs
>> User: lu...@debian.org
>> Usertags: ftbfs-20220917 ftbfs-bookworm
>>
>> Hi,
>>
>> During a rebuild of all packages in sid, your package failed to build
>> on amd64.
>>
>
> this seems unrelated to native compilation. It probably needs an
> upstream fix for emacs 28. Unfortunately upstream seems dead / static.

Agreed.  I'm thinking about filing an RM bug against cycle-quotes; its
last release happened 4 years ago (although there are some non-useful
new commits on https://github.com/emacsmirror/cycle-quotes), it fails to
build with Emacs 28, has been blocked for 790 days, and doesn't have any
reverse-dependencies.

Thoughts?

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1031845: matrix-synapse: Missing requirement python3-icu 2.10.2 from bullseye-backports

[Timmy]

Package: matrix-synapse
Version: 1.74.0-1~bpo11+2
Severity: important
X-Debbugs-Cc: timmylovesgames...@mailbox.org

Dear Maintainer,

Bullseye-backports version depends on python3-icu >=2.10.2. However, only an
older version is available, causing the matrix-synapse service to hang on start 
up.

Another user found that removing python3-icu from the system allows synapse
to start. But I have no idea the impact of running the program w/o this 
dependency nor what functionality may be missing. 



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

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

Versions of packages matrix-synapse depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  libc6  2.31-13+deb11u5
ii  libgcc-s1  10.2.1-6
ii  libjs-jquery   3.5.1+dfsg+~3.5.5-7
ii  libpython3-stdlib  3.9.2-3
ii  lsb-base   11.1.0
ii  python33.9.2-3
ii  python3-attr   20.3.0-1
ii  python3-bcrypt 3.1.7-4
ii  python3-bleach 3.2.1-2.1
ii  python3-canonicaljson  1.6.2-1~bpo11+1
ii  python3-cryptography   3.3.2-1
ii  python3-distutils  3.9.2-1
ii  python3-frozendict 1.2-3~bpo11+1
ii  python3-ijson  3.1.4-1
ii  python3-jinja2 3.0.3-1~bpo11+1
ii  python3-jsonschema 3.2.0-3
ii  python3-lxml   4.6.3+dfsg-0.1+deb11u1
ii  python3-matrix-common  1.3.0-2
ii  python3-msgpack1.0.0-6+b1
ii  python3-netaddr0.7.19-5
ii  python3-openssl20.0.1-1
ii  python3-packaging  20.9-2
ii  python3-phonenumbers   8.12.1-1
ii  python3-pil8.1.2+dfsg-0.3+deb11u1
ii  python3-prometheus-client  0.9.0-1
ii  python3-psycopg2   2.8.6-2
ii  python3-pyasn1 0.4.8-1
ii  python3-pyasn1-modules 0.2.1-1
ii  python3-pydantic   1.7.4-1
ii  python3-pymacaroons0.13.0-4
ii  python3-service-identity   18.1.0-6
ii  python3-signedjson 1.1.1-2
ii  python3-sortedcontainers   2.1.0-2
ii  python3-systemd234-3+b4
ii  python3-treq   18.6.0-0.2
ii  python3-twisted20.3.0-7+deb11u1
ii  python3-typing-extensions  3.10.0.2-1~bpo11+1
ii  python3-unpaddedbase64 2.1.0-2~bpo11+1
ii  python3-yaml   5.3.1-5

Versions of packages matrix-synapse recommends:
ii  matrix-synapse-ldap3  0.1.4+git20201015+a3c7a9f-1
ii  python3-pympler   0.9+dfsg1-2

Versions of packages matrix-synapse suggests:
pn  python3-authlib  
pn  python3-jwt  

-- Configuration Files:
/etc/matrix-synapse/homeserver.yaml changed [not included]

-- debconf information excluded

Bug#961147: libcolor-calc-perl: broken by new libgraphics-colornames-perl

[Mason James]

On 24/02/23 1:53 pm, gregor herrmann wrote:

On Wed, 25 May 2022 11:34:20 +0200, gregor herrmann wrote:


On Mon, 21 Feb 2022 21:18:10 +, Damyan Ivanov wrote:

-=| intrigeri, 22.05.2020 08:47:25 +0200 |=-

Niko Tyni (2020-05-21):

libcolor-calc-perl has just one reverse dependency AFAICS:
libcgi-application-plugin-authentication-perl.

I took a quick look.

Me too, a longer one :)

…

Then I read your comments about removal :)

The last rdep is gone, so I guess we can just RM libcolor-calc-perl?


Or we can salvage it, as mtj has added another patch, which makes the
tests pass.

Not sure if it's woth it; if yes we probably should 1) merge the two
patches and 2) upload quickly.


i'm happy to merge the patches today

Bug#1031800: mmdebstrap: --keyring doesn't work properly

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-02-23 18:55:01)
> I just ran your script up to the "apt update", having the shell substitute $1
> <- "bookworm" and $2 <- "DIRECTORY_FOR_CHROOT", and adding my new repo:
> 
>   mkdir -p "$2/etc/apt" "$2/var/cache" "$2/var/lib"
>   cat << END > "$2/apt.conf"
>   Apt::Architecture "$(dpkg --print-architecture)";
>   Apt::Architectures "$(dpkg --print-architecture)";
>   Dir "$(cd "$2" && pwd)";
>   Dir::Etc::Trusted "$(eval "$(apt-config shell v Dir::Etc::Trusted/f)"; 
> printf "$v")";
>   Dir::Etc::TrustedParts "$(eval "$(apt-config shell v 
> Dir::Etc::TrustedParts/d)"; printf "$v")";
>   END
>   echo "deb http://deb.debian.org/debian/ $1 main" >  
> "$2/etc/apt/sources.list"
>   echo "deb http://MYREPO $1 main" >> 
> "$2/etc/apt/sources.list"
> 
> After I do this, DIRECTORY_FOR_CHROOT/apt.conf contains:
> 
>   Apt::Architecture "amd64";
>   Apt::Architectures "amd64";
>   Dir "/home/dima/cadre/packaging/bookworm2-tst";
>   Dir::Etc::Trusted "/etc/apt/trusted.gpg";
>   Dir::Etc::TrustedParts "/etc/apt/trusted.gpg.d/";
> 
> Note that the Trusted keys are in the host, NOT in the chroot, so
> naturally the "apt update" complains about the missing keys. If I change
> the last line to
> 
>   Dir::Etc::TrustedParts "MY_KEYRING_DIRECTORY";
> 
> then "apt update" still complains. And once again sysdig tells me that
> it IS actually finding and using my keys. Suggestions?

you were now able to reproduce the problem without mmdebstrap but with plain
apt. This suggests that your problem is not an mmdebstrap problem.

> And I have another related question. I can workaround this by copying my keys
> to /etc/apt/trusted.gpg.d/ on the host. This makes mmdebstrap happy, but the
> resulting chroot doesn't have my keys in ITS /etc/apt/trusted.gpg.d. So an
> "apt update" inside the chroot has the same problem as before: complaining
> that my repo is unverifiable. The docs aren't clear on whether those keys are
> supposed to be copied or not. Are they? If not, am I supposed to do that
> manually via an mmdebstrap hook?

mmdebstrap will not automatically copy the keys it needs to some location into
the chroot. If your chroot needs extra key material for later "apt update" runs
it's up to you to copy the keys into the chroot at a location you like.

I also think I found the source of your problem. I reproduced your issue
locally like this:

sq key generate --userid "" --export juliet.key.pgp
sq key extract-cert --output juliet.cert.pgp juliet.key.pgp
apt-ftparchive release . > Release
sq sign --signer-key juliet.key.pgp --cleartext-signature --output=InRelease 
Release
mmdebstrap --keyring=/home/josch/repo/ --variant=apt unstable /dev/null 
http://deb.debian.org/debian "deb copy:///home/josch/repo ./"
[...]
I: running apt-get update...
done
Get:1 copy:/home/josch/repo ./ InRelease [1190 B]
Get:2 http://deb.debian.org/debian unstable InRelease [180 kB]
Err:1 copy:/home/josch/repo ./ InRelease
  The following signatures couldn't be verified because the public key is not 
available: NO_PUBKEY FC8F3FACCD368D66
Get:3 http://deb.debian.org/debian unstable/main arm64 Packages [9282 kB]
Reading package lists...
W: GPG error: copy:/home/josch/repo ./ InRelease: The following signatures 
couldn't be verified because the public key is not available: NO_PUBKEY 
FC8F3FACCD368D66
E: The repository 'copy:/home/josch/repo ./ InRelease' is not signed.


This is your problem, right? To fix it, I did this:

mv juliet.cert.pgp juliet.cert.asc

The clue can be found in the man page of apt-key:

   Alternatively, if all systems which should be using the created keyring
   have at least apt version >= 1.4 installed, you can use the ASCII
   armored format with the "asc" extension instead which can be created
   with gpg --armor --export.

Can you confirm that you also had a ASCII armored key stored with the .gpg
extension instead of .asc and that changing the extension makes apt happy?

Thanks!

cheers, josch

Bug#1031844: RFS: libfilezilla/0.41.1-1 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : libfilezilla
   Version  : 0.41.1-1
   Upstream contact : Tim Kosse 
 * URL  : https://lib.filezilla-project.org/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/debian/libfilezilla
   Section  : libs

The source builds the following binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla-common - build high-performing platform-independent programs 
(translations)
  libfilezilla35 - build high-performing platform-independent programs (runtime 
lib)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.41.1-1.dsc

Changes since the last upload:

 libfilezilla (0.41.1-1) experimental; urgency=medium
 .
   * New upstream version 0.41.1
   * Soname bump rename package to libfilezilla35

Regards

Phil

--

*** Playing the game for the games own sake. ***

Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1031843: src:argparse-manpage: new upstream version available

[Daniel Kahn Gillmor]

Package: src:argparse-manpage
Version: 1.2.2
Severity: wishlist

Upstream has released version 4 of argparse-manpage.  It would be great
to have this available in debian.

Note also that in upstream commit
eac5fcdd371708603b09c7270d8bfa0b19140ec0 (just after version 4) a
reproducibility fix was added.  it might be good to pull this in too, to
ensure that packages that use argparse-manpage during build can still
build reproducibly.

Thanks for maintaining argparse-manpage in debian!

  --dkg


signature.asc
Description: PGP signature

Bug#1031275: [PATCH v3 1/6] man2/: use IEC or ISO multiples to clarify long numeric digit strings

[Alex Colomar]

Hi Rob,

On 2/22/23 23:18, Rob Landley wrote:

16LL on 32 bit systems, but from an "explain what the number is" perspective it
neatly avoids needing to specify a base or units. :)


Right.


What's "fetch"?


A pop culture reference: https://www.youtube.com/watch?v=Pubd-spHN-0


:p


(Part of the reason is kibybyte/mebibyte/gibibyte are
minor tongue twisters, they're physically harder to say, so nobody does.)


I rarely talk about this stuff; more often, I write about it.  When I
write, the shorthand MiB is nice (I never write mebibyte).


I always read that TLA as "Men in Black", but I know what you mean.

$ wtf is TLA
TLA: three letter acronym
true love always

:)



I say "binary megabytes"


That's valid, I think.  And if it's not, everyone would understand.

> the same way I say "degrees celsius".



The GNU coding standards for writing C programs are horrible.  But they
have very nice things in their standards.  Their standardization of
Makefile targets and variables is quite nice, and I try to follow it
closely.


Hence cmake and ninja and so on.


Uhh, no, thanks!




(Still there in Documentation/process/coding-style.rst.)

GNU has nothing to do with Linux, and never did. Stallman has a history of
taking credit for other people's work:


I never said so. GNU is a set of userspace programs, Linux is a kernel,
and GNU/Linux is the entire OS (or more precisely a relatively important
part of it).


A busybox system isn't gnu, which means alpine linux isn't. Android using toybox
with a "no GPL in userspace policy" and built with llvm to avoid even the FSF's
compiler isn't gnu. So Linux on phones, and one of the standard docker distros,
actively _avoid_ using gnu. (These days, "systemd/linux" is probably at least as
accurate as "gnu/linux".


Yeah, any of them is fine IMO.  I write from a GNU/Linux distro, but I 
admit that I should have maybe said "most programs in Unix-like systems 
these days use IEC prefixes".



I type that from devuan...)


Me too :)


I CCed GNU coreutils so that they feel alluded and maybe improve their
utils :)


I'm still on that mailing list until they merge cut -DF.


What would that do?



You've taken over from Michael Kerrisk then? I should inform
https://www.openwall.com/lists/musl/2022/11/30/2#:~:text=biggest%20problem and
friends...


I guess many should already know.  But yes, feel free to inform.


Since 2020, I comaintained the project with Michael, and now I'm the
only maintainer of the project.  To be more precise, let's quote the README:

Maintainers
 Alejandro Colomar 

   2020 - present (5.09 - HEAD)
 Michael Kerrisk  
   2004 - 2021 (2.00 - 5.13)
 Andries Brouwer  
   1995 - 2004(1.6  - 1.70)
 Rik Faith 
   1993 - 1995(1.0  - 1.5)


Good to know. (I just randomly stopped getting the emailed updates...)

Ah, there you are on https://www.kernel.org/doc/man-pages/maintaining.html


Yep :)



Or you can say Kelvin ;)


And when the weather reports start giving temperatures in kelvin... they would
still say "degrees", wouldn't they? It's 267 degrees in Minneapolis today...


To be pedantic, and quoting the SI brochure v9: "* The unit name “degree
kelvin” was changed to “kelvin” in 1967 by the 13th CGPM (Resolution 3,
see p. 169)."

So you should say kelvins, not degrees kelvin.


Page 163 (49 in the PDF).



Gigabytes can be in base 10 or base 2. They're still gigabytes.


In colloquial texts, or more appropriately in colloquial talking,
degrees (without specifying), tons (same), or "megs", are fine, but for
a manual, where we want precision (especially since we do mix decimal
and binary multipliers often), I would strongly avoid misusing terms.


*shrug* If you're maintainer, it's your call. I've said my piece.


"They'll google it" is the modern version of "they'll read the documentation".
They will not, you're just delegating blame.


I can't imagine someone reading MiB in a manual page and not searching
what that means (unless the reader doesn't care about that specific value).


It's _possible_ the man page maintainer is not, in isolation, a fully rounded
representative sample on this issue?


It's possible, but I have my doubts in this case.

By chance, I was having a look at a computer that had RedHat Openshift 
open, and the system resources usage view used IEC multipliers (men in 
black units).


`free -h` also uses them.  The top(1) manual page also uses "kibibytes" 
and other such expanded words.





Rob

P.S. Maybe this is a generational thing? Are the kids saying "kibibyte" in high
school these days?


I don't think so.  Teachers usually don't 

Bug#1031842: xdg-desktop-portal-gnome: 44 appears incompatible with GNOME Shell 43

[Jeremy Bícha]

Source: xdg-desktop-portal-gnome
Version: 44~beta-1
Severity: serious
Tags: trixie

It appears that xdg-desktop-portal-gnome 44 is incompatible with
mutter/gnome-shell 43.

https://launchpad.net/ubuntu/+source/xdg-desktop-portal-gnome/44~beta-1ubuntu1

GNOME Shell 43 uses libmutter-11-0 ; GNOME Shell 44 uses libmutter-12-0

Therefore, would it be correct to set an unversioned
Breaks: libmutter-11-0

Thank you,
Jeremy Bícha

Bug#961147: libcolor-calc-perl: broken by new libgraphics-colornames-perl

[gregor herrmann]

On Wed, 25 May 2022 11:34:20 +0200, gregor herrmann wrote:

> On Mon, 21 Feb 2022 21:18:10 +, Damyan Ivanov wrote:
> > -=| intrigeri, 22.05.2020 08:47:25 +0200 |=-
> > > Niko Tyni (2020-05-21):
> > > > libcolor-calc-perl has just one reverse dependency AFAICS:
> > > > libcgi-application-plugin-authentication-perl.
> > > I took a quick look.
> > Me too, a longer one :)
> …
> > Then I read your comments about removal :)
> The last rdep is gone, so I guess we can just RM libcolor-calc-perl?

Or we can salvage it, as mtj has added another patch, which makes the
tests pass.

Not sure if it's woth it; if yes we probably should 1) merge the two
patches and 2) upload quickly.


Cheers,
gregor


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


signature.asc
Description: Digital Signature

Bug#1031828: debootstrap: Please document --usr-merge option in --help output

[Santiago Vila]

severity 1031828 normal
tags 1031828 - patch
retitle 1031828 debootstrap: Please document --usr-merge option in --help output
thanks

El 24/2/23 a las 0:12, Luca Boccassi escribió:

Please see:

https://lists.debian.org/debian-ctte/2022/09/msg5.html


Ok, did read, but also too long, and that was before the changes
made on 2022-11.

I don't use debootstrap every day. Instead, I usually upgrade already
existing chroots from the bookworm of yesterday to the bookworm
of today. As a result, my chroots were naturally upgraded to usr-merge.

If this is not supposed to happen, I would ideally like to see it documented
somewhere (but I could agree that debootstrap is not to blame for that).

So, if the buildds are still running non-usr-merged chroot, can you at least
document the --usr-merge option which already exists? It will certainly be
needed when creating chroots for trixie from bookworm, so I would say it
should be documented (I guess that would be a one line change).

I'm retitling the bug accordingly.

Thanks.

Bug#1031841: RM: rdist -- RoQA; non-free software in main; orphaned; no rdeps

[Bastian Germann]

Package: ftp.debian.org

The rdist package contains non-free software, which is documented in #962065.
It is orphand and nobody cared to update it for several years.

Bug#962065: rdist: Non-free license

[Bastian Germann]

The 7.0 alpha version has been relicensed but this license still occurs in at 
least one file (missing/strcasecmp.c).

Bug#1031775: yt-dlp prompts for the user to download PhantomJS

[Unit 193]

Howdy,

On Wed, 22 Feb 2023, Daniel Kahn Gillmor wrote:


Package: yt-dlp
Version: 2023.01.06-1
Severity: minor

using yt-dlp to fetch a local copy of a youtube URL like so:

   $ yt-dlp https://youtu.be/XXX

i see this warning:

-
[youtube] XXX: Downloading player 11e3a4ec
WARNING: [youtube] XXX: nsig extraction failed: You may experience 
throttling for some formats
Install PhantomJS to workaround the issue. Please download it from 
https://phantomjs.org/download.html
-


This is just noting that it works, but some formats may get throttled with 
the hardcoded python js scraper and that use of an actual parser (which 
yt-dlp supports) could make matters a little better there.



If PhantomJS is DFSG-free (i haven't checked), then it should be put in
debian, and yt-dlp should Recommend: it at least.  Then this warning
should be patched to say "apt install phantomjs" instead.


It is, or I presume so since it was in Debian.  It was removed in #962061 
with the deprecation of python2.  Since it seems rather inactive upstream 
(no commits since 2020) and the python2 issue still stands[0], I wouldn't 
imagine someone would want to re-introduce it.  But there's nothing 
preventing anyone from doing so either.



[0]: https://github.com/ariya/phantomjs/issues/15414


If it is not DFSG-free, it seems inappropriate for a debian package to
directly encourage the user to download non-free software in the course
of basic operations.


Well it could still be useful as a hint for those that run into 
throttling, or the inability to fetch the video, that yt-dlp works with 
that too.


However since I most often use yt-dlp with sites other than YouTube, or 
use mpv's support for yt-dlp, I don't see the message as much and don't 
find it as much of a nuisance as others might.




Thanks for maintaining yt-dlp in debian!  It is a very useful tool for
those of us who don't want to be connected to the Internet at all times.


Glad you find a use for it.

~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#998889: libcommoncpp2: Remove in bookworm?

[Bastian Germann]

Control: severity -1 normal
Control: retitle -1 RM: libcommoncpp2 -- RoQA; orphaned; RC-buggy; better 
alternative available
Control: reassign -1 ftp.debian.org

Yes, the package should be gone from unstable as well.

Bug#1031840: geogebra: FTBFS with librhino-java

[Markus Koschany]

Package: geogebra
Version: 4.0.34.0+dfsg1-9
Severity: important
X-Debbugs-Cc: a...@debian.org

Hi,

the Debian Java team currently "fixes" a FTBFS in geogebra by applying
this patch in src:rhino.

https://salsa.debian.org/java-team/rhino/-/blob/master/debian/patches/public_getSourcePositionFromStack.patch

However this should be addressed in geogebra instead. We can't support
old API forever.

Regards,

Markus

Bug#1031770: Info received (Bug#1031770: Info received (kontact: cannot show existing messages and will not retrieve new ones))

[Paul Boddie]

Hello again,

I also found the applicable upstream KDE bug:

"Akonadi fails with Mariadb 10.6.3"
https://bugs.kde.org/show_bug.cgi?id=439769

Meanwhile, applying the fix suggested for Qt 5.15 in a slightly modified form 
seems to prevent the error I experienced from occurring.

With the modified libqt5sql5-mysql package installed, I have managed to start 
Kontact, view stored messages (after some messing around with akonadiconsole, 
due to earlier troubleshooting attempts), and this message will have been sent 
from Kontact.

I conclude, then, that the upstream fix needs backporting to Qt 5.11.3 for 
Debian.

Paul

Bug#1026431: Remove scalc for bookworm?

[Bastian Germann]

Control: retitle -1 RM: scalc -- RoQA; orphaned; no reverse deps
Control: severity -1 normal
Control: reassign -1 ftp.debian.org

Please remove scalc from the archive. There is no real use of it and popcon is 
very low.

Bug#1031839: network devices do not work after kernel upgrade

[Thorsten Alteholz]

Package: linux-image-amd64
Version: 6.1.8-1
Severity: important

Hi,

upgrading from kernel 5.18.5-1 to 6.1.8-1 (and 6.1.12-1) network devices using 
driver module ixgbe stop working.
The devices are recognized and can be configured but "ip a" shows "no-carrier" 
for them.
With kernel 5.18.5-1 everthing works fine.

  Thorsten

Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')

[Hilmar Preuße]

On 2/23/23 14:28, James Addison wrote:

On Thu, 23 Feb 2023 at 12:53, James Addison  wrote:


Hi,


   pass: texlive-base (2022.20220605-1) unstable; urgency=low
   fail: texlive-base (2022.20220923-2) unstable; urgency=medium

It should be possible to look at the differences between those (and
maybe the related packages such as texlive-latex-base) to find further
clues.  I'm going to start on that fairly soon.


Ok, it turns out that the problem was a compatibility-break between v2
and v3 of the base doc.sty file.  Fortunately the texlive-latex-base
package ships the previous (v2, feynmf-compatible) version of that
file along with v3.


This seems to be just a temporary solution, as the TL upstream people,
will stop providing the old doc.sty at any time in the future. You may
lower the severity, but not close the issue.

Hilmar
--
Testmail

Bug#1031828: debootstrap: The buildd profile does not enable usr-merge by default on bookworm and later

[Luca Boccassi]

On Thu, 23 Feb 2023 at 22:53, Santiago Vila  wrote:
>
> El 23/2/23 a las 22:26, Luca Boccassi escribió:
> > On Thu, 23 Feb 2023 at 20:50, Santiago Vila  wrote:
> >> The buildds already did the switch several months ago.
> >
> > Wait, what?  Specific changes were made to debootstrap in order to
> > allow the buildd machines to stay un-merged, as the CTTE wanted,
>
> Can you elaborate on that? What you say sounds as something that
> could be said two years ago before the release of bullseye, i.e.
> newly installed systems have usr-merge by default but we keep
> building packages on not usr-merged chroots.
>
> > When did the switch happen, and how?
>
> I believe it was sometime in 2022-11, but I can't tell for sure. I believe it
> happened because I sometimes monitor debian-bugs-rc and at some point bugs
> about packages which FTBFS on usr-merged systems became serious.
>
> Sorry not to be more precise. I hope somebody who knows better can answer.
>
> ( In case it's confirmed that the buildds are already using usr-merge for 
> bookworm
> and sid, would you agree that the debootstrap program in bookworm should do 
> the
> same by default? )

Please see:

https://lists.debian.org/debian-ctte/2022/09/msg5.html

Bug#1031836: nvi: refuses to start with read-only rootfs (/var/tmp)

[Boyuan Yang]

Control: severity 1031836 wishlist

Hi,

在 2023-02-23星期四的 23:31 +0100，наб写道：
> Package: nvi
> Version: 1.81.6-16
> Severity: normal
> 
> Dear Maintainer,
> 
> -- >8 --
> # vi /etc/snmp/snmpd.conf
> ex/vi: Error: /var/tmp/vi.recover: Read-only file system
> ex/vi: Modifications not recoverable if the session fails
> ex/vi: Error: /var/tmp/vi.recover/vi.pL7kw0: No such file or directory
> -- >8 --
> 
> This is fatal. /No one/ can edit /anything/, it seems,
> until /var/tmp is made writable (be it by remounting / rw,
> or, indeed mounting tmpfs on /var/tmp).
> 
> This should be a non-fatal warning.

According to FHS and Linux common practice [1][2], /var/tmp/ should be
world-writable in a sane environment. Supporting a non-standard environment
should be in wishlist. You are welcome to provide a patch to Debian or
forward the patch to upstream. Please note that the upstream of nvi may not
be active now [3], but giving it a try is always harmless.

Thanks,
Boyuan Yang


[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.html
[2]
https://www.redhat.com/en/blog/polyinstantiating-tmp-and-vartmp-directories
[3] likely to be https://repo.or.cz/nvi.git


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

Bug#1031828: debootstrap: The buildd profile does not enable usr-merge by default on bookworm and later

[Santiago Vila]

El 23/2/23 a las 22:26, Luca Boccassi escribió:

On Thu, 23 Feb 2023 at 20:50, Santiago Vila  wrote:

The buildds already did the switch several months ago.


Wait, what?  Specific changes were made to debootstrap in order to
allow the buildd machines to stay un-merged, as the CTTE wanted,


Can you elaborate on that? What you say sounds as something that
could be said two years ago before the release of bullseye, i.e.
newly installed systems have usr-merge by default but we keep
building packages on not usr-merged chroots.


When did the switch happen, and how?


I believe it was sometime in 2022-11, but I can't tell for sure. I believe it
happened because I sometimes monitor debian-bugs-rc and at some point bugs
about packages which FTBFS on usr-merged systems became serious.

Sorry not to be more precise. I hope somebody who knows better can answer.

( In case it's confirmed that the buildds are already using usr-merge for 
bookworm
and sid, would you agree that the debootstrap program in bookworm should do the
same by default? )

Thanks.

Bug#1031838: qemu-guest-agent: /dev/virtio-ports/org.qemu.guest_agent.0 symlink not created due to missing comma in udev rule

[Christian Schneider]

Package: qemu-guest-agent
Version: 1:5.2+dfsg-11+deb11u2
Severity: important
Tags: patch

Hi, while setting up a fresh Debian VM in a Proxmox cluster, service qemu-
guest-agent isn't starting. In the journal the following messages are 
recorded:

systemd[1]: qemu-guest-agent.service: Job qemu-guest-agent.service/start 
failed with result 'dependency'.
systemd[1]: dev-virtio\x2dports-org.qemu.guest_agent.0.device: Job dev-
virtio\x2dports-org.qemu.guest_agent.0.device/start failed with result 
'timeout'.

It's waiting for a symlink /dev/virtio-ports/org.qemu.guest_agent.0 to show 
up, but there is not even the /dev/virtio-ports directory.
On the other hand the link target /dev/vport1p1 was created properly.

Long story short: I think there is just a comma missing between 
'TAG+="systemd"' and 'ENV{SYSTEMD_WANTS}="qemu-guest-agent.service"' in
/lib/udev/rules.d/60-qemu-guest-agent.rules.

Might this report be useful...

Best regards, Christian


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

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

Versions of packages qemu-guest-agent depends on:
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u5
ii  libglib2.0-0 2.66.8-1
ii  libudev1 247.3-7+deb11u1
ii  liburing10.7-3
ii  lsb-base 11.1.0

qemu-guest-agent recommends no packages.
diff --git a/debian/changelog b/debian/changelog
index 2b0d69a586..8832becc8d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+qemu (1:7.2+dfsg-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * fix d/qemu-guest-agent.udev
+
+ -- Christian Schneider   Thu, 23 Feb 2023 21:55:28 +
+
 qemu (1:7.2+dfsg-4) unstable; urgency=medium
 
   * block-fix-detect-zeroes-with-BDRV_REQ_REGISTERED_BUF.patch:
diff --git a/debian/qemu-guest-agent.udev b/debian/qemu-guest-agent.udev
index 8a290abbd3..47097057e3 100644
--- a/debian/qemu-guest-agent.udev
+++ b/debian/qemu-guest-agent.udev
@@ -1,2 +1,2 @@
 SUBSYSTEM=="virtio-ports", ATTR{name}=="org.qemu.guest_agent.0", \
-  TAG+="systemd" ENV{SYSTEMD_WANTS}="qemu-guest-agent.service"
+  TAG+="systemd", ENV{SYSTEMD_WANTS}="qemu-guest-agent.service"

Bug#1031837: uxterm: -e option does not set title

[Sam Watkins]

Package: xterm
Version: 378-1
Severity: minor
Tags: patch

The -e option of uxterm does not set the title of the window, it is overridden
to be "uxterm". This is not consistent with xterm, which does set the title.
The attached patch fixes this, with the side-effect that the title will default
to "xterm" rather than "uxterm" when the -e option is not used.


diff --git a/uxterm b/uxterm
index 25c6f5f..fefecee 100755
--- a/uxterm
+++ b/uxterm
@@ -146,4 +146,4 @@ fi
 # for testing:
 #test -f ./xterm && XTERM_PROGRAM=./xterm
 
-exec "$XTERM_PROGRAM" -class UXTerm -title "$whoami" -u8 "$@"
+exec "$XTERM_PROGRAM" -class UXTerm -u8 "$@"



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

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

Versions of packages xterm depends on:
ii  libc6   2.36-8
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-4
ii  libice6 2:1.0.10-1
ii  libtinfo6   6.4-2
ii  libutempter01.2.1-2
ii  libx11-62:1.8.3-3
ii  libxaw7 2:1.0.14-1
ii  libxext62:1.3.4-1+b1
ii  libxft2 2.3.6-1
ii  libxinerama12:1.1.4-3
ii  libxmu6 2:1.1.3-3
ii  libxpm4 1:3.5.12-1.1
ii  libxt6  1:1.2.1-1
ii  xbitmaps1.1.1-2.2

Versions of packages xterm recommends:
ii  x11-utils  7.7+5

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information
diff --git a/uxterm b/uxterm
index 25c6f5f..fefecee 100755
--- a/uxterm
+++ b/uxterm
@@ -146,4 +146,4 @@ fi
 # for testing:
 #test -f ./xterm && XTERM_PROGRAM=./xterm
 
-exec "$XTERM_PROGRAM" -class UXTerm -title "$whoami" -u8 "$@"
+exec "$XTERM_PROGRAM" -class UXTerm -u8 "$@"

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Luca Boccassi]

On Thu, 23 Feb 2023 11:12:00 -0700 Sam Hartman 
wrote:
> > "Sean" == Sean Whitton  writes:
> 
> Sean> Hello,
> Sean> On Wed 22 Feb 2023 at 09:55AM +01, Sebastian Ramacher
wrote:
> 
> >> Unless I am missing something, having dh_installsystemd look
at
> >> the service files in /usr/lib is the only viable solution for
> >> bullseye -> bookworm. We could fix individual packages that
> >> didn't include those files in bullseye, but for all the others
we
> >> are unable to move the files from /usr/lib to /lib.
> 
> Sean> You're saying we can't move them in that case because the
TC
> Sean> resolution says no moving /usr/lib->/lib ?  Or some other
> Sean> reason?  I thought we only said that files couldn't move in
> Sean> the other direction.
> 
> Well, there is the underlying technical issue that made the TC
> resolution reasonable.
> Moving paths between  aliased locations plus replaces will always
> produce behavior that is predictable and potentially bad with the
> current dpkg.
> It's independent on whether it's /usr/lib or /lib on source or
> destination.
> 
> I agree with the analysis and believe that having dh_installsystemd
look
> in /usr/lib/systemd is the option least likely to create breakage.

If those files have always been shipped in /usr then yes, I agree we
should leave them there. We might have a problem if they were in /lib
in bullseye though, but am I correct in understanding that this is not
the case for any of the highlighted packages?

-- 
Kind regards,
Luca Boccassi


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

Bug#1031836: nvi: refuses to start with read-only rootfs (/var/tmp)

[наб]

Package: nvi
Version: 1.81.6-16
Severity: normal

Dear Maintainer,

-- >8 --
# vi /etc/snmp/snmpd.conf
ex/vi: Error: /var/tmp/vi.recover: Read-only file system
ex/vi: Modifications not recoverable if the session fails
ex/vi: Error: /var/tmp/vi.recover/vi.pL7kw0: No such file or directory
-- >8 --

This is fatal. /No one/ can edit /anything/, it seems,
until /var/tmp is made writable (be it by remounting / rw,
or, indeed mounting tmpfs on /var/tmp).

This should be a non-fatal warning.

наб

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 nvi depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-8
ii  libdb5.3 5.3.28+dfsg2-1
ii  libncursesw6 6.4-2
ii  libtinfo66.4-2

Versions of packages nvi recommends:
ii  nvi-doc  1.81.6-17

nvi suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1031744: httpdirfs: usage of ubsan might introduce vulnerabilities

[Adrian Bunk]

On Thu, Feb 23, 2023 at 01:49:49AM +, Fufu Fang wrote:
> Hi Adrian,
> I have pushed a commit to Github which removes the usage of UBSAN. I am
> happy to go with this method. 
> 
> Do let me know if you prefer ASAN to be added alongside UBSAN, rather
> than simply removing UBSAN.

Enabling ASAN makes it even worse, so this was correct.

> Best wishes,
> Fufu

Thanks
Adrian

Bug#1031835: quilt will create spurious files from certain patches on push/pop

[Lee Garrett]

Package: quilt
Version: 0.67+really0.66-1
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

some patches imported by quilt may be patch series, which create a file in one
diff, but remove it again in another. In those cases quilt will correctly keep
the file from existing on `quilt push`. However, on `quilt pop` the spurious
file will be created. I have a minimal reproducer here:

---8<--8<--8<--8<--8<--8<--8<--8<--8<--8<---

23:01:22 [randall@batou:~/tmp] $ find
.
./tmp.patch
23:01:23 [randall@batou:~/tmp] $ cat tmp.patch 
--- /dev/null
+++ b/spurious_file
@@ -0,0 +1 @@
+some content here
--- a/spurious_file
+++ /dev/null
@@ -1 +0,0 @@
-some content here
23:01:28 [randall@batou:~/tmp] $ quilt import tmp.patch 
Importing patch tmp.patch (stored as tmp.patch)
23:01:32 [randall@batou:~/tmp] $ quilt push; quilt pop
Applying patch tmp.patch
patching file spurious_file
patching file spurious_file

Now at patch tmp.patch
Removing patch tmp.patch
Restoring spurious_file

No patches applied
23:01:39 [randall@batou:~/tmp] $ find
.
./.pc
./.pc/.version
./.pc/.quilt_series
./.pc/.quilt_patches
./spurious_file
./tmp.patch
./debian
./debian/patches
./debian/patches/tmp.patch
./debian/patches/series
23:01:43 [randall@batou:~/tmp] $ cat spurious_file 
some content here
23:01:48 [randall@batou:~/tmp] $ rm spurious_file 
23:03:07 [randall@batou:~/tmp] $ quilt push --refresh; quilt pop
Applying patch tmp.patch
patching file spurious_file
patching file spurious_file
Refreshed patch tmp.patch

Now at patch tmp.patch
Removing patch tmp.patch
Restoring spurious_file

No patches applied
23:03:23 [randall@batou:~/tmp] $ cat spurious_file 
some content here

---8<--8<--8<--8<--8<--8<--8<--8<--8<--8<---

As you can see above, "spurious_file" is created after `quilt push; quilt pop`,
even though it shouldn't exist (it's created on "pop"). This even persists when
refreshing the patch, where it should at least drop both diffs completely.

I've set the severity to important, as it breaks with the user's expectation,
and potentially could cause spurious files ending up in source packages that
shouldn't.

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

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

Versions of packages quilt depends on:
ii  bsdextrautils   2.38.1-4
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  ed  1.19-1
ii  gettext 0.21-11
ii  patch   2.7.6-7
ii  perl5.36.0-7
ii  sensible-utils  0.0.17+nmu1

Versions of packages quilt recommends:
ii  less  590-1.1

Versions of packages quilt suggests:
pn  default-mta | mail-transport-agent  
ii  graphviz2.42.2-7+b3
pn  procmail

-- no debconf information

Bug#1029829: Server connections refused after applying update?

[Barry Trent]

I applied this update to my one remaining buster machine and now it is 
refusing to connect to my bullseye-based amanda backup server.


amcheck and the amanda server are both reporting "Connection refused" 
when accessing the updated buster machine.


--
Barry A. Trent
952-829-5864, x109
barry.tr...@atcorp.com



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1028313: isc-dhcp 4.4.1-2.3+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1028313 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: isc-dhcp
Version: 4.4.1-2.3+deb11u2

Explanation: fix IPv6 address lifetime handling

Bug#1031828: debootstrap: The buildd profile does not enable usr-merge by default on bookworm and later

[Luca Boccassi]

On Thu, 23 Feb 2023 at 20:50, Santiago Vila  wrote:
>
> El 23/2/23 a las 21:38, Luca Boccassi escribió:
> > It's too soon for this. I think the right time will be the first point
> > release of Bookworm - at that point we can get the buildds to switch
> > too. But the release should be built in the current default as per
> > CTTE's instructions.
>
> The buildds already did the switch several months ago.

Wait, what?  Specific changes were made to debootstrap in order to
allow the buildd machines to stay un-merged, as the CTTE wanted, until
after bookworm's release. When did the switch happen, and how?

Bug#1031783: command-not-found 20.10.1-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1031783 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: command-not-found
Version: 20.10.1-1+deb11u1

Explanation: add new non-free-firmware component, fixing upgrades to bookworm

Bug#1031635: snakeyaml 1.28-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1031635 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: snakeyaml
Version: 1.28-1+deb11u1

Explanation: fix denial of service issues [CVE-2022-25857 CVE-2022-38749 
CVE-2022-38750 CVE-2022-38751]

Bug#1030987: vagrant 2.2.14+dfsg-2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1030987 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: vagrant
Version: 2.2.14+dfsg-2

Explanation: add support for VirtualBox 7.0

Bug#1030888: ncurses 6.2+20201114-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1030888 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: ncurses
Version: 6.2+20201114-2+deb11u1

Explanation: guard against corrupt terminfo data [CVE-2022-29458]; fix tic 
crash on very long tc/use clauses

Bug#1030851: symfony 4.4.19+dfsg-2+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1030851 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: symfony
Version: 4.4.19+dfsg-2+deb11u2

Explanation: remove private headers before storing responses with HttpCache 
[CVE-2022-24894]; remove CSRF tokens from storage on successful login 
[CVE-2022-24895]

Bug#1029121: lxc 4.0.6-2+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1029121 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: lxc
Version: 4.0.6-2+deb11u2

Explanation: fix file existence oracle [CVE-2022-47952]

Bug#1028395: exiv2 0.27.3-3+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1028395 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: exiv2
Version: 0.27.3-3+deb11u2

Explanation: security fixes [CVE-2021-29458 CVE-2021-29463 CVE-2021-29464 
CVE-2021-29470 CVE-2021-29473 CVE-2021-29623 CVE-2021-32815 CVE-2021-34334 
CVE-2021-34335 CVE-2021-3482 CVE-2021-37615 CVE-2021-37616 CVE-2021-37618 
CVE-2021-37619 CVE-2021-37620 CVE-2021-37621 CVE-2021-37622 CVE-2021-37623]

Bug#1027264: traceroute 2.1.0-2+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1027264 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: traceroute
Version: 2.1.0-2+deb11u1

Explanation: interpret v4mapped-IPv6 addresses as IPv4

Bug#1031834: nodejs: CVE-2023-23918 CVE-2023-23919 CVE-2023-23920

[Salvatore Bonaccorso]

Source: nodejs
Version: 18.13.0+dfsg1-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for nodejs.

CVE-2023-23918[0]:
| A privilege escalation vulnerability exists in Node.js 19.6.1,
| 18.14.1, 16.19.1 and 14.21.3 that made it possible to
| bypass the experimental Permissions
| (https://nodejs.org/api/permissions.html) feature in Node.js and
| access non authorized modules by using process.mainModule.require().
| This only affects users who had enabled the experimental permissions
| option with --experimental-policy.


CVE-2023-23919[1]:
| A cryptographic vulnerability exists in Node.js 19.2.0,
| 18.14.1, 16.19.1, 14.21.3 that in some cases did does not
| clear the OpenSSL error stack after operations that may set it. This
| may lead to false positive errors during subsequent cryptographic
| operations that happen to be on the same thread. This in turn could be
| used to cause a denial of service.


CVE-2023-23920[2]:
| An untrusted search path vulnerability exists in Node.js. 19.6.1,
| 18.14.1, 16.19.1, and 14.21.3 that could allow an attacker
| to search and potentially load ICU data when running with elevated
| privileges.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-23918
https://www.cve.org/CVERecord?id=CVE-2023-23918
[1] https://security-tracker.debian.org/tracker/CVE-2023-23919
https://www.cve.org/CVERecord?id=CVE-2023-23919
[2] https://security-tracker.debian.org/tracker/CVE-2023-23920
https://www.cve.org/CVERecord?id=CVE-2023-23920

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1031828: debootstrap: The buildd profile does not enable usr-merge by default on bookworm and later

[Santiago Vila]

El 23/2/23 a las 21:38, Luca Boccassi escribió:

It's too soon for this. I think the right time will be the first point
release of Bookworm - at that point we can get the buildds to switch
too. But the release should be built in the current default as per
CTTE's instructions.


The buildds already did the switch several months ago.

Thanks.

Bug#1031382: Re: Bug#1031382: RFS: libkysdk-base/1.0.1-1 [ITP] -- Kylin SDK basic library

[Boyuan Yang]

Hi,

在 2023-02-22星期三的 17:25 +0800，Kevin Duan写道：
> HI!
> 
> Thanks for the heads up, I have fixed this issue in the latest version and
> have also uploaded the latest to mentors.
> URL: https://mentors.debian.net/package/libkysdk-base/
> Version:        1.0.1-3
> 
> Thanks！
> KevinDuan


Several issues that need fix:

* Since your package has not entered Debian officially, please do not
increase the revision number. In your next source package provided, please
still use 1.0.1-1 as version number, not 1.0.1-4. Please only increase
revision numbers after your package is officially accepted into Debian
archive.

* For packages that only contains development headers (*-dev), they do not
include shared library files. As a result, the dependency substitution
${shlibs:Depends} is absolutely not needed. Please drop these lines from
debian/control file. However: please do not delete ${shlibs:Depends}
substitution from packages that actually contains shared library file.

* Compared with your previous 1.0.1-1 upload, the current packaging will
directly place header files under /usr/include/ instead of placing them
under subdirectories. While this behavior does not directly conflict with
packaging policy, I will have to let you know that your packaging is likely
to be problematic, buggy and will cause issues in the futures. For example
in the future libkysdk-system packaging
at https://mentors.debian.net/package/libkysdk-system/, some file (e.g.,
src/systeminfo/libkysisinfo.c) will look for header in , not /usr/include/cstring-extension.h. This means
that libkysdk-system will break when being built in the future. Please,
carefully review your packaging decision again; if you are sure that current
packaging is acceptable, I can upload it as-is. Otherwise I recommend you to
review the decision on header file path.

Thanks,
Boyuan Yang


> 在2023年02月22 06时34分，"Boyuan Yang"写道：
> > 
> > Control: tags -1 +moreinfo
> > 
> > Indeed, please fix the error listed below before we can proceed.
> > 
> > Thanks,
> > Boyuan Yang
> > 
> > On Thu, 16 Feb 2023 19:55:44 +0100 Adam Borowski 
> > wrote:
> > > On Thu, Feb 16, 2023 at 11:05:42AM +0800, kevin wrote:
> > > >   * Package name : libkysdk-base
> > > >     Version  : 1.0.1-1
> > > 
> > > >   libkysdk-base (1.0.1-1) unstable; urgency=medium
> > > >   .
> > > >     * Initial release. (Closes: #1031344)
> > > 
> > > Hi!
> > > Alas, the package fails to build:
> > > 
> > > .
> > > dh_missing: warning: etc/kysdk/kysdk-base/kylog-rotate-default exists
> > > in
> > debian/tmp but is not installed to anywhere (related file:
> > "src/log/kylog-
> > rotate-default")
> > > dh_missing: warning: usr/include/kysdk/kysdk-base/libkylog.h exists in
> > debian/tmp but is not installed to anywhere (related file:
> > "src/log/libkylog.h")
> > > dh_missing: warning: usr/include/kysdk/kysdk-base/listdata.h exists in
> > debian/tmp but is not installed to anywhere (related file:
> > "src/utils/data-
> > structure/linklist/listdata.h")
> > > dh_missing: warning: usr/include/kysdk/kysdk-base/skip_linklist.h
> > > exists
> > in debian/tmp but is not installed to anywhere (related file:
> > "src/utils/data-structure/linklist/skip_linklist/skip_linklist.h")
> > > dh_missing: error: missing files, aborting
> > > 
> > >    While detecting missing files, dh_missing noted some files with
> > > a
> > similar name to those
> > >    that were missing.  This error /might/ be resolved by replacing
> > references to the
> > >    missing files with the similarly named ones that dh_missing
> > > found -
> > assuming the content
> > >    is identical.
> > > 
> > >    As an example, you might want to replace:
> > >     * src/log/kylog-rotate-default
> > >    with:
> > >     * etc/kysdk/kysdk-base/kylog-rotate-default
> > >    in a file in debian/ or as argument to one of the dh_* tools
> > > called
> > from debian/rules.
> > >    (Note it is possible the paths are not used verbatim but
> > > instead
> > directories 
> > >    containing or globs matching them are used instead)
> > > 
> > >    Alternatively, add the missing file to debian/not-installed if
> > > it
> > cannot and should not
> > >    be used.
> > > 
> > >    The following debhelper tools have reported what they installed
> > (with files per package)
> > >     * dh_install: libkysdk-base (0), libkysdk-base-dev (1),
> > > libkysdk-
> > config (2), libkysdk-config-dev (3), libkysdk-log (5), libkysdk-log-dev
> > (3),
> > libkysdk-timer (2), libkysdk-timer-dev (3), libkysdk-utils (4),
> > libkysdk-
> > utils-dev (9)
> > >     * dh_installdocs: libkysdk-base (0), libkysdk-base-dev (0),
> > libkysdk-config (0), libkysdk-config-dev (0), libkysdk-log (0),
> > libkysdk-
> > log-dev (0), libkysdk-timer (0), libkysdk-timer-dev (0), libkysdk-utils
> > (0),
> > libkysdk-utils-dev (0)
> > >    If the missing files are installed by another tool, please file
> > > a
> > bug against it.
> > >   

Bug#998105: chainer is still not supported (requires a cfg file as work-around)

[Sven Geuer]

Hi BiT Dev,

thank you for the detailled reply.

More inline below ...

On Thu, 2023-02-23 at 01:53 +0100, BiT dev wrote:
> On Tue, 21 Feb 2023 20:40:21 +0100 Sven Geuer 
> wrote:
> 
> > I still need to pin python3-keyring to use
> > keyring.backends.SecretService.
> 
> What do you mean with "pin"? Installing an old version of python3-
> keyring (without the chainer) by pinning the ("old") DEB package
> (version)?

With "pin" I meant configuring python3-keyring per

  ~/.config/python_keyring/keyringrc.cfg:

[backend]
default-keyring=keyring.backends.SecretService.Keyring

More below ...

> 
> > Unfortunately BiT version 1.3.3 still fails with a version of
> > python3-
> > keyring offering keyring.backends.chainer.
> > [...]
> 
> TLDR:
> -
> 
> "chainer" is new and a "meta keyring" that decides internally which
> actually installed
> keyring will be used using some heuristics.
> 
> "chainer" is not supported by BiT since the heuristics may choose
> another keyring in the future for any reason
> and the wrong keyring is used then (which does not contain the stored
> credentials for BiT).
> 
> To solve (work around) this problem add a keyring config file to
> specify ("pin") which keyring you want
> to use instead of chainer, see these instructions here:
> 
> https://github.com/bit-team/backintime#non-working-password-safe-and-bit-forgets-passwords-keyring-backend-issues
> 
> -> Just use your prefered keyring in the config file:
> 
>     default-keyring=keyring.backends.SecretService.Keyring
> 
> 
> 
> In full length:
> ---
> 
> To really use a a keyring two things must be installed:
> 
> 1. A supported keyring software (debian package)
> 2. A python library that has a "driver" to enable the keyring of 1.
> for python
> 
> The BiT logs show that "secret service" is installed (satisfies above
> number 1.):
> 
> >    DEBUG: [common/tools.py:862 keyringSupported] Available keyring
> > backends:
> ...
> >    DEBUG: [common/tools.py:865 keyringSupported]
> > keyring.backends.SecretService.Keyring (priority: 5)
> 
> The BiT logs also show that above number 2. is satisfied
> ("python3-secretstorage" is installed together with "python3-keyring"
> AFAIR since it has a "depends" relationship):
> 
> >    DEBUG: [common/tools.py:899 keyringSupported] Available
> > supported backends:
> >  [,  > 'keyring.backends.kwallet.DBusKeyring'>]
> 
> Since newer "python3-keyring" versions use "chainer" by default now
> (which is not supported by BiT) no keyring is available in BiT:
> 
> > DEBUG: [common/tools.py:905 keyringSupported] No appropriate
> > keyring found. 'keyring.backends.chainer' can't be used with
> > BackInTime
> 
> 

I understand this all very well. The current situation just does not
deem user friendly to me. I am afraid the average user is unable to
detect what the problem is and how to fix it, especially as things
worked out of the box before python3-keyring 23.2.0-1 was introduced.

> 
> Outlook:
> --
> 
> I think I should add a link to above "known issues" section to the
> debug output.
> 
> How the chainer issue could be fixed is described quite well in this
> feature request (add a GUI to select the keyring):
> 
> https://github.com/bit-team/backintime/issues/1330
> 

This may help, although it still requires sufficient insight on the
part of the user.

Would it be feasible to probe the supported backends for already stored
BiT credentials and choose the matching backend automatically?

Love to hear what you think.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#1031828: debootstrap: The buildd profile does not enable usr-merge by default on bookworm and later

[Luca Boccassi]

On Thu, 23 Feb 2023 20:00:42 +0100 Santiago Vila 
wrote:
> Package: debootstrap
> Version: 1.0.128+nmu2
> Severity: important
> Tags: patch
> 
> Dear maintainer:
> 
> Because Debian has decided that bookworm will have
> usr-merge by default even for building packages,
> I would expect usr-merge to be enabled by default
> in all cases, including when using the buildd profile.
> 
> Currently, such thing does not happen.
> 
> I think the attached patch would fix this
> (but I've not tested it).
> 
> A better approach would be to select --usr-merge
> in the buildd profile when appropriate (i.e. bookworm
> and above). (How feasible would this be?)
> 
> I am aware that the proposed patch (but not the "better approach")
> may force some people to do some things differently.
> 
> However, let's compare the two scenarios:
> 
> A) If the patch is applied, then once that bookworm becomes stable:
> 
> - Those who want to build packages for stable the official way
> do not have to do anything special. I think this is the category
> of users that should be better supported.
> 
> - Those still running bullseye who want to build packages for
> bullseye (using debootstrap from bullseye) do not have to do
> anything special.
> 
> - Only people who want to build packages for bullseye from
> bookworm would have to add --no-usr-merge by hand, and only
> when using the buildd profile. I think this is a special case
> and having to add an option by hand for such special case would
> not be a big deal.
> 
> B) If the patch is not applied, then once that bookworm becomes
stable:
> 
> - Those who want to build packages for stable the official way
> should add --usr-merge by hand when calling debootstrap.
> 
> This option is *undocumented* in "debootstrap --help" (!).
> 
> Also, failure to add the --usr-merge option may result in packages
> being misbuilt, or even failing to build at all. And this would
> happen when building packages from stable to be installed in a
> stable system.
> 
> - Those still running bullseye who want to build packages for
> bullseye (using debootstrap from bullseye) do not have to do
> anything special.
> 
> - Those who want to build packages for bullseye from bookworm
> would not have to do anything special.

It's too soon for this. I think the right time will be the first point
release of Bookworm - at that point we can get the buildds to switch
too. But the release should be built in the current default as per
CTTE's instructions.

-- 
Kind regards,
Luca Boccassi


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

Bug#1031525: Upload through -security possible

[Salvatore Bonaccorso]

Hi Gregor,

On Thu, Feb 23, 2023 at 09:21:37PM +0100, Gregor Jasny wrote:
> Hello,
> 
> It look like the clearance for -proposed takes some time (#1031652). Would
> it be possible to upload through -security even without a DSA?

No, every update trough security requires a security advisory in
general. Can you elaborate why an update trough the next bullseye
point release does not seem sufficient? Are the actual users of the
interface impacted? (Note I'm referring here to
https://github.com/c-ares/c-ares/pull/497#issuecomment-1350307964). Do
you think anything was wrong in the assessment which want a
re-evaluation of the severity?

Thanks in advance for clarification on it.

Regards,
Salvatore

Bug#1029523: ruby-net-http-persistent want Ruby (~> 2.1)

[Paul Gevers]

Hi,

On Tue, 24 Jan 2023 00:21:06 +0530 Pirate Praveen 
 wrote:
  net-http-persistent (~> 3.0, >= 3.0.0) was resolved to 3.1.0, 
which depends on

Ruby (~> 2.1)


This doesn't seem to be an issue on reproducible builds [1] when 
building ruby-faraday. Does that make sense?


Paul

[1] https://tests.reproducible-builds.org/debian/history/ruby-faraday.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#902866: flameshot: Will not run, exits with error "Could not connect to display"

[Hendrik Jäger]

Hi Prescott

Do you still have this issue?

> I just realized the issue, although it doesn't seem to be related to 
> flameshot directly. The program runs as a D-BUS service, and for some reason 
> the DISPLAY environment variable isn't being set.

This sounds like this bug needs to be reassigned to some other package.
I’m thinking your (dbus) environment is not initialized correctly when starting 
your X-session. How do you start it?
Do you use some Display Manager, like xdm, gdm, etc.?
How do you select to start bspwm: via a menu in your DM, after logging into 
your DM, from your ~/.xsession, ~/.xinitrc, etc.?

Please report back so proper steps can be taken.

Cheers

henk

On Mon, 20 Aug 2018 14:59:39 + Prescott Hidalgo-Monroy 
 wrote:
> Hi,
> 
> I just realized the issue, although it doesn't seem to be related to 
> flameshot directly. The program runs as a D-BUS service, and for some reason 
> the DISPLAY environment variable isn't being set. The issue is resolved by 
> running
> 
> dbus-update-activation-environment DISPLAY XAUTHORITY
> 
> I had to do the same with systemd and implement a DISPLAY set in my startup 
> script in order for dunst to work as a non-root user. These issues didn't 
> come up under Stretch, so I'm not sure what changed when upgrading to Testing.
> 
> 
> Regards,
> Prescott Hidalgo-Monroy
> 
> ‐‐‐ Original Message ‐‐‐
> On July 3, 2018 9:05 PM, Boyuan Yang <073p...@gmail.com> wrote:
> 
> > Control: tag -1 + help
> > 
> 
> > 在 2018年7月4日星期三 CST 上午12:41:49，Prescott Hidalgo-Monroy 写道：
> > 
> 
> > > Just tried with the bspwm version in the Buster repos, still have the same
> > > issue and error messages.
> > > Regards,
> > > Prescott HM
> > 
> 
> > Hi,
> > 
> 
> > Unfortunately I couldn't reproduce your problem on all major DEs and some 
> > WMs.
> > I am not able to test bspwm at this moment. I'd suggest that you report this
> > problem to upstream http://github.com/lupoDharkael/flameshot meanwhile.
> > 
> 
> > ---
> > 
> 
> > Regards,
> > Boyuan Yang
> > 
> 
> > > ‐‐‐ Original Message ‐‐‐
> > > On July 2, 2018 12:18 PM, Prescott Hidalgo-Monroy  > 
> 
> > monroy.com> wrote:
> > 
> 
> > > > Using git upstream bspwm v0.9.5-5-g229b6fd, and it's all local use.
> > > > I might try the bspwm version from the repos as well, it's on v0.9.5-1.
> > > > Regards,
> > > > Prescott
> > > > ‐‐‐ Original Message ‐‐‐
> > > > On July 2, 2018 10:10 AM, Boyuan Yang 073p...@gmail.com wrote:
> > > > 
> 
> > > > > Control: severity -1 important
> > > > > Control: tag -1 + moreinfo
> > > > > 在 2018年7月2日星期一 CST 下午10:33:29，Prescott 写道：

Bug#1031525: Upload through -security possible

[Gregor Jasny]

Hello,

It look like the clearance for -proposed takes some time (#1031652). 
Would it be possible to upload through -security even without a DSA?


Thanks,
Gregor

Bug#1031827: rsyslog: please mention changes that affect log parsing in NEWS.Debian

[Michael Biebl]

Hi Simon

Am 23.02.23 um 18:44 schrieb Simon McVittie:

Package: rsyslog
Version: 8.2302.0-1
Severity: wishlist

According to
https://lists.debian.org/debian-backports/2023/02/msg8.html
it seems that people might be (rightly or wrongly) relying on the old
timestamp format, and the ability to read messages from /var/log/messages.

I think it would be more obvious that these are intentional changes if
there was a NEWS entry for the bullseye -> bookworm (and therefore
bullseye -> bullseye-backports) upgrade.


Yeah, makes sense. I already debated whether to include a NEWS entry 
when making the upload (to unstable).


I also debated whether to revert the changes for bpo, but decided 
against it.


Do you think I can copy the changelog from [1] or does it have too 
much/little detail?


Regards,
Michael


[1] 
https://tracker.debian.org/news/1379692/accepted-rsyslog-822100-3-source-into-unstable/




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030297: pytango: FTBFS: = 364 failed, 689 passed, 26 xfailed, 2 warnings, 40 errors in 176.40s (0:02:56) =

[Helmut Grohne]

Control: forwarded -1 https://gitlab.com/tango-controls/pytango/-/issues/450

Hi,

On Fri, Feb 03, 2023 at 08:40:38PM +0200, Adrian Bunk wrote:
> Control: retitle -1 pytango FTBFS on IPV6-only buildds
> 
> This is FTBFS on IPV6-only buildds:
> https://buildd.debian.org/status/logs.php?pkg=pytango=all
> https://buildd.debian.org/status/logs.php?pkg=pytango=9.3.6-2%2B
> 
> Several error messages in lines like
>   >   self.host, self.port = args
>   E   ValueError: too many values to unpack (expected 2)
> confirm that it is related to that.

Thank you for the pre-diagnosis. This is fully accurate, but the issue
is deeper. It also isn't the first IPv6-only FTBFS for pytango. The
earlier one was #1014179 and pytango actually carries a patch for it.
Unfortunately, the patch does not work at all. The patch also isn't
upstream, but upstream has an issue for it and seems responsive. Let's
keep the technical discussion at the upstream tracker.

In essence though, it seems that cpptango does not work with IPv6 at
all. This isn't super convenient, but unworkable either. However, it
seems that it requires a non-loopback IP address and that's something we
don't have on all buildds. It also seems to work when the hostname
resolves to the loopback address, but that's also not the case on
buildds.

Helmut

Bug#1031833: runit fails to install: useradd: not found

[Helmut Grohne]

Package: sysuser-helper
Version: 2.1.2-54
Severity: serious
Justification: makes runit fail to install
Control: affects -1 + runit

runit fails to install in unstable. An easy reproducer is this:

$ mmdebstrap --variant=essential --include runit sid /dev/null
...
Setting up runit (2.1.2-54) ...
/lib/sysuser-helper/sysuser-helper: 19: useradd: not found
dpkg: error processing package runit (--configure):
 installed runit package post-installation script subprocess returned error 
exit status 127
Errors were encountered while processing:
 runit
E: Sub-process env returned an error code (1)
E: setup failed: E: apt-get -o Dir::Bin::dpkg=env -o 
DPkg::Options::=--unset=TMPDIR -o DPkg::Options::=dpkg -o 
DPkg::Chroot-Directory=/tmp/mmdebstrap.ZhieYGlyAI -d
I: main() received signal PIPE: waiting for setup...
I: removing tempdir /tmp/mmdebstrap.ZhieYGlyAI...
E: mmdebstrap failed to run
$

I think the failure actually is with sysuser-helper, which misses a
dependency on passwd. passwd used to be pseudo-essential but no longer
is. As such sysuser-helper must depend on it explicitly.

Helmut

Bug#1031832: python3-vispy: import fails: AttributeError: module 'numpy' has no attribute 'bool'

[s3v]

Package: python3-vispy
Severity: serious


Dear Maintainer,

This import fails in a Sid chroot:

>>> from vispy.plot import Fig
/usr/lib/python3/dist-packages/vispy/gloo/program.py:113: FutureWarning: In the 
future `np.bool` will be defined as the corresponding NumPy scalar.
 'bvec2':    (np.bool,    2),
Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib/python3/dist-packages/vispy/plot/__init__.py", line 34, in 

   from .fig import Fig  # noqa
   
 File "/usr/lib/python3/dist-packages/vispy/plot/fig.py", line 5, in 
   from ..scene import SceneCanvas
 File "/usr/lib/python3/dist-packages/vispy/scene/__init__.py", line 33, in 

   from .visuals import *  # noqa
   ^^
 File "/usr/lib/python3/dist-packages/vispy/scene/visuals.py", line 18, in 

   from .. import visuals
 File "/usr/lib/python3/dist-packages/vispy/visuals/__init__.py", line 14, in 

   from .axis import AxisVisual  # noqa
   
 File "/usr/lib/python3/dist-packages/vispy/visuals/axis.py", line 11, in 

   from .visual import CompoundVisual
 File "/usr/lib/python3/dist-packages/vispy/visuals/visual.py", line 90, in 

   from .. import gloo
 File "/usr/lib/python3/dist-packages/vispy/gloo/__init__.py", line 54, in 

   from .program import Program  # noqa
   
 File "/usr/lib/python3/dist-packages/vispy/gloo/program.py", line 74, in 

   class Program(GLObject):
 File "/usr/lib/python3/dist-packages/vispy/gloo/program.py", line 113, in 
Program
   'bvec2':    (np.bool,    2),
^^^
 File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 305, in 
__getattr__
   raise AttributeError(__former_attrs__[attr])
AttributeError: module 'numpy' has no attribute 'bool'.
`np.bool` was a deprecated alias for the builtin `bool`. To avoid this error in 
existing code, use `bool` by itself. Doing this will not modify any behavior
and is safe. If you specifically wanted the numpy scalar type, use `np.bool_` 
here.
The aliases was originally deprecated in NumPy 1.20; for more details and 
guidance see the original release note at:
   https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations. Did you 
mean: 'bool_'?

Kind Regards

Bug#1017871: Please help to reproduce (Was: shiny-server: server-function don't run)

[Nilesh Patra]

Hi Sebastian,

I've propagated a (ugly) hack in sockjs and also updated shiny-server to
a new version and just uploaded. I was able to run your example locally.

Could you please install "1.5.20.1002-1" of shiny-server and check if that 
works for you?
I'd appreciate early feedback as we (debian) are currently in
soft-freeze and making any changes will become progressively harder
until new debian (bookworm) release.

Looking forward to hear from you.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1031626: marked as done (gdb-doc: Keep new version out of testing until gdb migrates)

[Sven Joachim]

Control: reopen -1

On 2023-02-23 19:09 +, Debian Bug Tracking System wrote:

> From: Adrian Bunk 
> Subject: gdb-doc: Keep new version out of testing until gdb migrates
> To: Debian Bug Tracking System 
> Date: Sun, 19 Feb 2023 15:46:01 +0200 (4 days, 5 hours, 33 minutes ago)
> Message-ID: <167681436181.973107.11105752777461364991.reportbug@localhost>
> X-Mailer: reportbug 7.10.3+deb11u1
>
> Package: gdb-doc
> Version: 13.0.91.20230210-0.2
> Severity: serious
> Control: block -1 by 1031625
>
> This bug exists to keep the new version of gdb-doc out of testing
> until gdb migrates, it can be closed at the same time as #1031625.
> --
> Source: gdb-doc
> Binary: gdb-doc
> Architecture: source all
> Version: 13.1-1
> Distribution: unstable
> Urgency: high
> Maintainer: Héctor Orón Martínez 
> Changed-By: Héctor Orón Martínez 
> Description:
>  gdb-doc- The GNU Debugger Documentation
> Closes: 1031626
> Changes:
>  gdb-doc (13.1-1) unstable; urgency=high
>  .
>* New upstream version 13.1
>  (Closes: #1031626)

Thanks for the update of gdb-doc, but it still should not migrate to
testing while gdb is kept out there by both #1031745 and a manual block
request by the release team.

Please keep this bug open until gdb 13.1 migrates.

Cheers,
   Sven

Bug#1031831: ITP: plover-stroke -- Stroke handling helper library for Plover

[Boyuan Yang]

Package: wnpp
Severity: wishlist
Owner: Boyuan Yang 

* Package name: plover-stroke
  Version : 1.1.0
  Upstream Author : Benoit Pierre 
* URL : https://github.com/openstenoproject/plover
* License : GPL-2.0-or-later
  Programming Lang: Python
  Description : Stroke handling helper library for Plover

 This package provides a stroke handling helper library for
 working with steno stroke. It is a dependency for plover
 software.

This package is the build-dependency for package plover.
I intend to maintain this package as part of the Debian Python Team.
Packaging work will be stored at
https://salsa.debian.org/python-team/packages/plover-stroke .

Thanks,
Boyuan Yang


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

Bug#1031830: freecad: update some links in d/control and freecad(1)

[Patrice Duroux]

Source: freecad
Version: 0.20.2+dfsg1-4
Severity: wishlist

Dear Maintainer,

According to 'curl --no-progress-meter -LI https://freecadweb.org/', I suggest
the attached patch
which also modify freecad(1) where the link for the bugs is as now suggested
here:
https://tracker.freecad.org/

Thanks,
Patrice


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

Kernel: Linux 6.1.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/control b/debian/control
index 2d4ec35a..d6a1e547 100644
--- a/debian/control
+++ b/debian/control
@@ -68,7 +68,7 @@ Build-Depends-Indep: doxygen
 Standards-Version: 4.6.1
 Vcs-Browser: https://salsa.debian.org/science-team/freecad
 Vcs-Git: https://salsa.debian.org/science-team/freecad.git
-Homepage: https://freecadweb.org/
+Homepage: https://freecad.org/
 Rules-Requires-Root: no
 
 Package: freecad
diff --git a/debian/freecad.1 b/debian/freecad.1
index e038b81c..fb351ce4 100644
--- a/debian/freecad.1
+++ b/debian/freecad.1
@@ -84,8 +84,8 @@ Test case - or 0 for all.
 \fB\-u, \-\-user\-cfg\fR \fIarg\fR
 User config file to load/save user settings.
 .SH SEE ALSO
-To get more information about \fBFreeCAD\fR, please visit 
\fIhttps://freecadweb.org\fR
+To get more information about \fBFreeCAD\fR, please visit 
\fIhttps://freecad.org\fR
 .SH BUGS
-To report a bug, please visit \fIhttps://freecadweb.org/tracker\fR
+To report a bug, please visit \fIhttps://github.com/FreeCAD/FreeCAD/issue\fR
 .SH AUTHOR
 This manual page was written by Werner Mayer and Salman Mohammadi 
.

Bug#1031809: Bump webp-pixbuf-loader version to 0.1.2 as it contains important bugfixes

[Andrey Rakhmatullin]

Disclaimer: I'm not a maintainer for this package.

Versions 0.1.0 to 0.1.2 clearly say "PRE-RELEASE: Complete rewrite" and
have a "Pre-release" label, so it would be questionable to upload them to
sid outside a freeze. It's definitely impossible to upload them to
sid/testing during one, unless the maintainer and the release team agree
otherwise. I've initially lowered the severity of this report to important
as an RC severity wasn't justified but on a closer look this looks like a
wishlist or even not something that can be done at all.

Bug#1031829: gawk: please make the build reproducible

[Chris Lamb]

Source: gawk
Version: 1:5.2.1-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
gawk could not be built reproducibly.

This is because the gawkbug script contained the contents of the CFLAGS
environment variable, and this can contain the full build path via/by
embedding -ffile-prefix-map.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2023-02-23 10:40:16.745966821 -0800
--- b/debian/rules  2023-02-23 10:58:04.377850011 -0800
@@ -34,6 +34,8 @@
rm -f debian/gawk/usr/bin/awk
# Remove fake info files (see README.source).
rm -rf debian/gawk/usr/share/info
+   # Make gawkbug reproducible
+   sed -i -e 's@$(CURDIR)@/build/dir@g' debian/gawk/usr/bin/gawkbug
 
 override_dh_auto_clean:
dh_auto_clean

Bug#1031042: Acknowledgement (bullseye-pu: package mariadb-10.5 10.5.19-0+deb11u1)

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2023-02-17 at 08:00 -0800, Otto Kekäläinen wrote:
> Can I proceed to upload MariaDB 10.5.19 to proposed stable updates?

A week's a little early for a personal poke...

FWIW the original request never made it to debian-release, most likely
due to the size of the attachments.

Please go ahead.

Regards,

Adam

Bug#1031124: unblock: mariadb/1:10.11.1-4

[Paul Gevers]

Hi Otto,

On 23-02-2023 17:08, Otto Kekäläinen wrote:

What does apt upgrade -o Debug::pkgDepCache::Marker=1 -o
Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgProblemResolver=1
yield?

In this situation we need to debug what versions apt is seeing and how
it is resolving them [1].


paul@mulciber ~ $ sudo apt upgrade -o Debug::pkgDepCache::Marker=1 -o 
Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgProblemResolver=1

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
   Delayed Removing: mariadb-server-10.6:amd64 as upgrade is not an 
option for mariadb-server:amd64 (1:10.11.2-1)
   Delayed Removing: mariadb-server-10.6:amd64 as upgrade is not an 
option for mariadb-server:amd64 (1:10.11.2-1)
  MarkInstall mariadb-server:amd64 < 1:10.6.11-2 -> 1:10.11.2-1 @ii umU 
Ib > FU=0

  Installing mariadb-client:amd64 as Depends of mariadb-server:amd64
 Delayed Removing: mariadb-client-10.6:amd64 as upgrade is not an 
option for mariadb-client:amd64 (1:10.11.2-1)
 Delayed Removing: mariadb-client-10.6:amd64 as upgrade is not an 
option for mariadb-client:amd64 (1:10.11.2-1)
 Delayed Removing: mariadb-client-core-10.6:amd64 as upgrade is not 
an option for mariadb-client:amd64 (1:10.11.2-1)
 Delayed Removing: mariadb-server-10.6:amd64 as upgrade is not an 
option for mariadb-client:amd64 (1:10.11.2-1)

MarkInstall mariadb-client:amd64 < none -> 1:10.11.2-1 @un uN Ib > FU=0
Installing mariadb-client-core:amd64 as Depends of mariadb-client:amd64
   Delayed Removing: mariadb-client-core-10.6:amd64 as upgrade is 
not an option for mariadb-client-core:amd64 (1:10.11.2-1)
   Delayed Removing: mariadb-client-core-10.6:amd64 as upgrade is 
not an option for mariadb-client-core:amd64 (1:10.11.2-1)
   Delayed Removing: mariadb-server-core-10.6:amd64 as upgrade is 
not an option for mariadb-client-core:amd64 (1:10.11.2-1)
  MarkInstall mariadb-client-core:amd64 < none -> 1:10.11.2-1 @un 
uN Ib > FU=0
  MarkDelete mariadb-client-core-10.6:amd64 < 1:10.6.11-2 @ii mK Ib 
> FU=0

  MarkDelete mariadb-server-core-10.6:amd64 < 1:10.6.11-2 @ii mK > FU=0
Installing libdbd-mariadb-perl:amd64 as Recommends of 
mariadb-client:amd64
  MarkInstall libdbd-mariadb-perl:amd64 < none -> 1.22-1+b1 @un umN 
> FU=0

MarkDelete mariadb-client-10.6:amd64 < 1:10.6.11-2 @ii mK NPb Ib > FU=0
MarkDelete mariadb-server-10.6:amd64 < 1:10.6.11-2 @ii mK Ib > FU=0
  Installing mariadb-server-core:amd64 as Depends of mariadb-server:amd64
MarkInstall mariadb-server-core:amd64 < none -> 1:10.11.2-1 @un uN 
> FU=0

  new important dependency: mariadb-plugin-provider-bzip2:amd64
  Installing mariadb-plugin-provider-bzip2:amd64 as Recommends of 
mariadb-server:amd64
MarkInstall mariadb-plugin-provider-bzip2:amd64 < none -> 
1:10.11.2-1 @un uN > FU=0

  new important dependency: mariadb-plugin-provider-lz4:amd64
  Installing mariadb-plugin-provider-lz4:amd64 as Recommends of 
mariadb-server:amd64
MarkInstall mariadb-plugin-provider-lz4:amd64 < none -> 1:10.11.2-1 
@un uN > FU=0

  new important dependency: mariadb-plugin-provider-lzma:amd64
  Installing mariadb-plugin-provider-lzma:amd64 as Recommends of 
mariadb-server:amd64
MarkInstall mariadb-plugin-provider-lzma:amd64 < none -> 
1:10.11.2-1 @un uN > FU=0

  new important dependency: mariadb-plugin-provider-lzo:amd64
  Installing mariadb-plugin-provider-lzo:amd64 as Recommends of 
mariadb-server:amd64
MarkInstall mariadb-plugin-provider-lzo:amd64 < none -> 1:10.11.2-1 
@un uN > FU=0

  new important dependency: mariadb-plugin-provider-snappy:amd64
  Installing mariadb-plugin-provider-snappy:amd64 as Recommends of 
mariadb-server:amd64
MarkInstall mariadb-plugin-provider-snappy:amd64 < none -> 
1:10.11.2-1 @un uN > FU=0

  new important dependency: pv:amd64
  Installing pv:amd64 as Recommends of mariadb-server:amd64
MarkInstall pv:amd64 < none -> 1.6.20-1 @un uN > FU=0
  MarkKeep mariadb-server-core-10.6:amd64 < 1:10.6.11-2 @ii mR > FU=0
  MarkKeep mariadb-client-10.6:amd64 < 1:10.6.11-2 @ii mR NPb > FU=0
  MarkKeep mariadb-server-10.6:amd64 < 1:10.6.11-2 @ii mR > FU=0
  MarkKeep mariadb-client-core-10.6:amd64 < 1:10.6.11-2 @ii mR > FU=0
Entering ResolveByKeep
  Dependencies are not satisfied for mariadb-server-core:amd64 < none 
-> 1:10.11.2-1 @un uN Ib >

Keeping package mariadb-server-core:amd64
  MarkKeep mariadb-server-core:amd64 < none -> 1:10.11.2-1 @un uN Ib > FU=0
  Dependencies are not satisfied for mariadb-server:amd64 < 1:10.6.11-2 
-> 1:10.11.2-1 @ii umU Ib >

Keeping package mariadb-server:amd64
  MarkKeep mariadb-server:amd64 < 1:10.6.11-2 -> 1:10.11.2-1 @ii umU Ib 
> FU=0
  Dependencies are not satisfied for 
mariadb-plugin-provider-bzip2:amd64 < none -> 1:10.11.2-1 @un uN Ib >

Keeping package mariadb-plugin-provider-bzip2:amd64
  MarkKeep mariadb-plugin-provider-bzip2:amd64 < none -> 1:10.11.2-1 
@un uN Ib > FU=0
  Dependencies are not satisfied for 

Bug#1031828: debootstrap: The buildd profile does not enable usr-merge by default on bookworm and later

[Santiago Vila]

Package: debootstrap
Version: 1.0.128+nmu2
Severity: important
Tags: patch

Dear maintainer:

Because Debian has decided that bookworm will have
usr-merge by default even for building packages,
I would expect usr-merge to be enabled by default
in all cases, including when using the buildd profile.

Currently, such thing does not happen.

I think the attached patch would fix this
(but I've not tested it).

A better approach would be to select --usr-merge
in the buildd profile when appropriate (i.e. bookworm
and above). (How feasible would this be?)

I am aware that the proposed patch (but not the "better approach")
may force some people to do some things differently.

However, let's compare the two scenarios:

A) If the patch is applied, then once that bookworm becomes stable:

- Those who want to build packages for stable the official way
do not have to do anything special. I think this is the category
of users that should be better supported.

- Those still running bullseye who want to build packages for
bullseye (using debootstrap from bullseye) do not have to do
anything special.

- Only people who want to build packages for bullseye from
bookworm would have to add --no-usr-merge by hand, and only
when using the buildd profile. I think this is a special case
and having to add an option by hand for such special case would
not be a big deal.

B) If the patch is not applied, then once that bookworm becomes stable:

- Those who want to build packages for stable the official way
should add --usr-merge by hand when calling debootstrap.

This option is *undocumented* in "debootstrap --help" (!).

Also, failure to add the --usr-merge option may result in packages
being misbuilt, or even failing to build at all. And this would
happen when building packages from stable to be installed in a
stable system.

- Those still running bullseye who want to build packages for
bullseye (using debootstrap from bullseye) do not have to do
anything special.

- Those who want to build packages for bullseye from bookworm
would not have to do anything special.


In summary: I think A is better default than B for bookworm, and
I believe it would be ok to change debootstrap default behaviour
before the release.


In either case, if debootstrap behaviour is not going to change
for bookworm, then option --usr-merge should be much better
documented, both in --help output and maybe in Release Notes.

Thanks.--- a/functions
+++ b/functions
@@ -1367,7 +1367,7 @@ setup_dselect_method () {
 # either installs the RTLD in a directory different from /lib or builds
 # multilib library packages.
 setup_merged_usr() {
-   if doing_variant buildd && [ -z "$MERGED_USR" ]; then
+   if [ -z "$MERGED_USR" ]; then
MERGED_USR="no"
fi
 

Bug#1031639: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[James Valleroy]

On Sun, 19 Feb 2023 19:01:22 +0100 Paul Gevers  wrote:


> On 2023-02-15 21:04:36 +0100, Sebastian Ramacher wrote:
> > 
> > On 2023-02-14 01:01:38 +0100, Daniel Leidert wrote:
> > > 
> > > This problem breaks e.g. vmdb2. I can no longer create a Bullseye

> > > system image with vmdb2 on Sid, because the grub-install step in the
> > > Bullseye chroot now fails, because the created filesystem (created with
> > > e2fsprogs on Sid) cannot be recognized by grub. I have to downgrade
> > > e2fsprogs to the version in Testing to get the build going again. It
> > > also means that a Bookworm system can never be used to format and
> > > debootstrap a Bullseye or Buster system that requires a grub
> > > installation.
> > > 
> > > I guess that the fix applied to grub2 in Sid would have to be applied

> > > to grub2 in Bullseye as well (and basically to any grub2 package in any
> > > Debian or Ubuntu or Raspbian release supported by debootstrap).
> > > 
> > > This situation is really messy. It breaks basically all my image builds

> > > with vmdb2.
> > 
> > Regardless of the outcome of #1031325, this issue will need to be fixed

> > in vmdb2 eventually. vmdb2, similar to other bootstraping tools, has to
> > account for the feature and disable it if necessary for older
> > distributions.
> > 
> > Cloning and reassign to vmdb2.
> 
> Based on more feedback from #10313225, I am also cloning and reassigning

> this issue to fai and grml-debootstrap. Dear maintainers, please check
> whether this issue is relevant for your packages.

The same appears to apply for debos and freedom-maker. Dear maintainers, 
please check whether this issue is relevant for your packages.


Control: severity -1 normal

The images built by freedom-maker have btrfs root partition by default, which 
are not affected by e2fsprogs. Although freedom-maker includes code to support 
ext4 root partition, to actually build an image using ext4 requires patching 
the source code of freedom-maker. If one modifies freedom-maker in this way, 
then there will be an error if building a bullseye image on a bookworm host:

2023-02-23 13:08:25,297 - ERROR - Target failed - virtualbox-amd64-ext4
Traceback (most recent call last):
  File "", line 198, in _run_module_as_main
  File "", line 88, in _run_code
  File "/home/james/salsa/freedombox-team/freedom-maker/freedommaker/__main__.py", 
line 13, in 
Application().run()
  File 
"/home/james/salsa/freedombox-team/freedom-maker/freedommaker/application.py", 
line 57, in run
builder.build()
  File 
"/home/james/salsa/freedombox-team/freedom-maker/freedommaker/builders/vm.py", 
line 21, in build
self.make_image()
  File 
"/home/james/salsa/freedombox-team/freedom-maker/freedommaker/builder.py", line 
106, in make_image
self._get_builder_backend().make_image()
  File 
"/home/james/salsa/freedombox-team/freedom-maker/freedommaker/internal.py", 
line 43, in make_image
self._install_boot_loader()
  File 
"/home/james/salsa/freedombox-team/freedom-maker/freedommaker/internal.py", 
line 352, in _install_boot_loader
library.install_grub(self.state)
  File 
"/home/james/salsa/freedombox-team/freedom-maker/freedommaker/library.py", line 
476, in install_grub
run_in_chroot(state, ['grub-install', device] + args)
  File 
"/home/james/salsa/freedombox-team/freedom-maker/freedommaker/library.py", line 
49, in run_in_chroot
return run(*args, **kwargs)
   
  File 
"/home/james/salsa/freedombox-team/freedom-maker/freedommaker/library.py", line 
43, in run
return cliapp.runcmd(*args, **kwargs)
   ^^
  File "/usr/lib/python3/dist-packages/cliapp/runcmd.py", line 64, in runcmd
raise cliapp.AppException(msg)
cliapp.app.AppException: Command failed: chroot /tmp/tmpxa690dib grub-install 
/dev/loop0
b''
b'Installing for i386-pc platform.\ngrub-install: error: unknown filesystem.\n'

Building a bookworm image that uses ext4 does not have this error.

In addition, it's not clear to me that there is a requirement for freedom-maker 
in bookworm to build bullseye images.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031786: logcheck: Filtering not working with entries from journald

[Helge Kreutzmann]

Hello Richard,
On Thu, Feb 23, 2023 at 12:14:08AM +, Richard Lewis wrote:
> On Wed, 22 Feb 2023, 17:51 Helge Kreutzmann,  wrote:
> 
> > Package: logcheck
> > Version: 1.4.1
> > Severity: grave
> > Justification: renders package unusable
> >
> > The change for #1025719 broke logcheck massively.
> >
> > I've extensivly tuned logcheck files which nicely filter out lots of
> > messages (see statistics at the end).
> >
> > Now I see them all again (only those comming from the journal).
> >
> > I don't see any information what I should do for migration.
> >
> 
> sorry about that.
> 
> i agree there is a bug in the documentation - we should add a NEWS.Debian
> entry - my fault i simply forgot. But this is hardly a grave bug.

A NEWS.Debian is definitely needed.

>  It is trivial to disable checking of the journal. just edit
> 
> /etc/logcheck/logcheck.logfiles.d/journal.logfiles
> 
> and add a # before the word  "journal".

This I was not aware of. Since the time format for syslog and journal
differ, I added the following local rule:
root@twentytwo:/etc/logcheck/ignore.d.server# cat lr_journal_out
^Jan
^Feb
…

> this will take effect on the next run of logcheck. This is also documented
> in that file --- as a heavy logcheck user i would recommend reading new
> config files when installing a new version. (We dont plan more changes for
> bookworm but in the longer-term there could be some changes to make
> logcheck more efficient)

So far, new config files changed little, and I usually read them after
they are in operation for a few days. But in the end, many are so
outdated, I hardley rely on them anymore.

For many programs I'm informed about the changed config during
upgrades, for "journal.logfiles" I did not have a chance to review it
- probably I did not modify this in the past. If I would have been
shown the file, I probably would have seen this entry.

However, I did check the files in /usr/share/doc/logcheck after
installing, but I did not find any information relevant to this there.

> HOWEVER,  you might want to consider adjusting to this in the long-term -
> if your log messages are different in the journal and syslog then not
> checking the journal means you are by definition not being informed of
> things. That would rather seem to defeat the point of monitoring the log
> messges. But it is of course up to you.

This is the best course of action. But this should be a controlled
situation. If I imagine running a dist-upgrade from bullseye lots of
programs need adjustments - having huge log files during logcheck does
not help at all. (And in a larger setup, this might be unfeasible to
do on the spot).

So if you add the NEWs entry, pointing people how to (temporarily)
disable journal logging, this would be a very good step, something
like:

Note that logcheck by default now also checks the systemd journal. If
you have local rules, this might cause lots of extra (unwanted) lines
to be shown if the patterns do not match.

This logging can be controlled by the setting "journal" in
/etc/logcheck/logcheck.logfiles.d/journal.logfiles

> But given debian has demoted syslog logcheck does need to "move with the
> times" and support systemd by default - we will not force anyone to adapt,
> but we cant predict what settings work for you.

I do see your rationale.

> > by courier to the journal:
> > Feb 22 16:37:40 meinfjell courierd[401638]: Installing uucp
> >
> > In syslog this is:
> > syslog:2023-02-22T14:37:40.491690+00:00 meinfjell courierd: Installing uucp
> >
> > I have the following in
> > /etc/logcheck/ignore.d.server:
> > meinfjell courierd: Initializing uucp
> 
> 
> Is this a typo?
> 
> this rule is not going to filter that message regardless of whether it is
> in the journal or syslog. one says initiailizing one says installing
> (Maybe courier changed its logging? )

No, the second one I manually picked and I was too fast, sorry.

> I also note you have the "new" timestamp format for syslog- that's an
> rsyslog change and nothing to do with logcheck. I believe you can revert
> that change quite easily as well.

This one caught me by suprise a few months back and caused me to adapt
my rules in a hurry back then - nothing I would like to repeat.

> As you can see, the message from the journal is slightly different
> > than from syslog, breaking tons of rules.
> >
> 
> 
> that sounds like a bug in courier. As above you can choose to only check
> one source of messages. Most programs put the same messages in both in my
> experience.

Courier is just one example, there are more. But given we are working
on a solution to this bug, I don't think we need to analyze other
programs logs.

And yes, as I understand it all logging first goes to the journal and
next to syslog, thus they are doubled.

> > For statistics:
> > On my local system, I have 11396 lines of rules, on my server system
> > currently 2721 (I'm in the processing of setting this up, so this will
> > grow).
> >
> 
> wow! but yes, 

Bug#1031800: mmdebstrap: --keyring doesn't work properly

[Dima Kogan]

Hi josch. Thanks for replying!

I just ran your script up to the "apt update", having the shell
substitute $1 <- "bookworm" and $2 <- "DIRECTORY_FOR_CHROOT", and adding
my new repo:

  mkdir -p "$2/etc/apt" "$2/var/cache" "$2/var/lib"
  cat << END > "$2/apt.conf"
  Apt::Architecture "$(dpkg --print-architecture)";
  Apt::Architectures "$(dpkg --print-architecture)";
  Dir "$(cd "$2" && pwd)";
  Dir::Etc::Trusted "$(eval "$(apt-config shell v Dir::Etc::Trusted/f)"; printf 
"$v")";
  Dir::Etc::TrustedParts "$(eval "$(apt-config shell v 
Dir::Etc::TrustedParts/d)"; printf "$v")";
  END
  echo "deb http://deb.debian.org/debian/ $1 main" >  "$2/etc/apt/sources.list"
  echo "deb http://MYREPO $1 main" >> "$2/etc/apt/sources.list"

After I do this, DIRECTORY_FOR_CHROOT/apt.conf contains:

  Apt::Architecture "amd64";
  Apt::Architectures "amd64";
  Dir "/home/dima/cadre/packaging/bookworm2-tst";
  Dir::Etc::Trusted "/etc/apt/trusted.gpg";
  Dir::Etc::TrustedParts "/etc/apt/trusted.gpg.d/";

Note that the Trusted keys are in the host, NOT in the chroot, so
naturally the "apt update" complains about the missing keys. If I change
the last line to

  Dir::Etc::TrustedParts "MY_KEYRING_DIRECTORY";

then "apt update" still complains. And once again sysdig tells me that
it IS actually finding and using my keys. Suggestions?


And I have another related question. I can workaround this by copying my
keys to /etc/apt/trusted.gpg.d/ on the host. This makes mmdebstrap
happy, but the resulting chroot doesn't have my keys in ITS
/etc/apt/trusted.gpg.d. So an "apt update" inside the chroot has the
same problem as before: complaining that my repo is unverifiable. The
docs aren't clear on whether those keys are supposed to be copied or
not. Are they? If not, am I supposed to do that manually via an
mmdebstrap hook?

Thanks

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> Hello,
Sean> On Wed 22 Feb 2023 at 09:55AM +01, Sebastian Ramacher wrote:

>> Unless I am missing something, having dh_installsystemd look at
>> the service files in /usr/lib is the only viable solution for
>> bullseye -> bookworm. We could fix individual packages that
>> didn't include those files in bullseye, but for all the others we
>> are unable to move the files from /usr/lib to /lib.

Sean> You're saying we can't move them in that case because the TC
Sean> resolution says no moving /usr/lib->/lib ?  Or some other
Sean> reason?  I thought we only said that files couldn't move in
Sean> the other direction.

Well, there is the underlying technical issue that made the TC
resolution reasonable.
Moving paths between  aliased locations plus replaces will always
produce behavior that is predictable and potentially bad with the
current dpkg.
It's independent on whether it's /usr/lib or /lib on source or
destination.

I agree with the analysis and believe that having dh_installsystemd look
in /usr/lib/systemd is the option least likely to create breakage.

Bug#1031647: git-annex: Bogus build dependency whitelist results in FTBFS on m68k

[Sean Whitton]

control: tag -1 + pending

Hello,

On Thu 23 Feb 2023 at 12:27PM -04, Joey Hess wrote:

> Sean Whitton wrote:
>> Joey, do you know why d/control restricts these build deps as it does?
>
> IIRC some of those deps are or were not available on some architectures
> like m68k. And the deps used to be gated behind the webapp build flag,
> so it would still build on those architectures without them installed.
>
> (I don't know how to get rmadison to display what packages are available
> on m68k? If those deps are avilable now, you could make git-annex use
> them.)
>
> Unfortunately, commit 78440ca37d75039d5eadd52eafbcd1751daba70a moved
> those build dependencies from behind that build flag. See commit for
> details; for some reason a new version of cabal changed its
> behavior in a way that seemed buggy, and that was the only workaround
> I could come up with at the time.
>
> One way you could get git-annex to build on arches where those build
> deps are not available would be to remove those build deps from the cabal
> file when building on those arches, and turning off the Assistant build
> flag.
>
> I think I have a better way though. The attached patch seems to work
> around that cabal problem in a way that will keep git-annex building
> when those deps are not installd. It should be in the next release of
> git-annex.

Thank you very much for the information and for the patch.

Given our freeze, I can add m68k to the list of architectures for those
build-deps, but I don't think we should apply Joey's patch for now.  But
let's let 10.20230126 migrate to testing first.  I've committed the
change to git; please remind me if I don't upload it a couple of days
from now.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1031379: Works on my machine

[Helge Kreutzmann]

Hello,
I'm also using it on amd64 and it works without any noticable
problems.

I would first check if the TV card works at all. I initially had some
problems, but these are not related to kaffeine.

So I suggest to downgrade this bug and tag it +moreinfo.

Greetings

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


signature.asc
Description: PGP signature

Bug#1031824: (no subject)

[Ted To]

May be related to 
.  Works on a Void 
Linux installation which has libsoup 3.2.0_2 instead of the Bookworm 
version 3.2.2-1.

Bug#1031827: rsyslog: please mention changes that affect log parsing in NEWS.Debian

[Simon McVittie]

Package: rsyslog
Version: 8.2302.0-1
Severity: wishlist

According to
https://lists.debian.org/debian-backports/2023/02/msg8.html
it seems that people might be (rightly or wrongly) relying on the old
timestamp format, and the ability to read messages from /var/log/messages.

I think it would be more obvious that these are intentional changes if
there was a NEWS entry for the bullseye -> bookworm (and therefore
bullseye -> bullseye-backports) upgrade.

smcv

Bug#801065: Documenting how to not fail postinst on service fails to start

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:

Wouter> On Wed, Feb 15, 2023 at 02:38:10PM -0500, Marvin Renich wrote:
>> > > > - the service fails to start in the postinst.
>> 
>> This implies that "the service is running" is part of "the
>> service is configured", which is where I disagree.

Wouter> What Steve said is that if

Wouter> - The service fails to start, *AND* - The service was
Wouter> previously running (or this is a new install)

Wouter> *THEN*

I think I disagree with Steve that postinst should fail on a new
install.

I think that failing postinst on a failed restart during upgrade is more
commonly the correct answer than ignoring the issue.
I also agree that it should be RECOMMENDED that if the restart fails
that be flagged to the admin somehow.

But in the case of krb5 and I think a few other services, there is not a
good way to detect at install time *whether* the service is sufficiently
configured to run from a systemd unit.  I could for example include a
ConditionPathExists on the Kerberos database.  That's wrong though
because in an LDAP deployment there will be no such database.

--Sam

Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single

[Sean Whitton]

Hello,

On Thu 23 Feb 2023 at 12:42AM GMT, Ian Jackson wrote:

> Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as 
> implying --quilt=single"):
>> I'm reluctant to introduce something else like this when we already have
>> the git-debpush tags thing.  Hmm -- is there some reason why dgit
>> couldn't put information in those tags in the same way?
>
> Well, I'm a bit confused right now, but: I think a potential problem
> is that if the branch format is converted without making a tag, things
> can go wrong.  I'm not sure precisely how we avoided this with
> git-debpush; part of the answer might be that git-debpush always works
> in split brain mode.

Okay, yeah, I guess we would have thought about having dgit do it at the
time and concluded that we couldn't.

>> Right, but the pile of Emacs addons I maintain using dgit-maint-merge(7)
>> will never hit any of those behaviours.  So it's a high cost to impose
>> on someone in a position such as mine.
>
> Hmmm.  I am very reluctant to recommend a practice which will induce
> other tools to corrupt data.  Note that the corruption might be
> experienced by downstreams (ie, people outside Debian) who are trying
> to use dgit to manipulate packages from Debian.
>
> Whereas inventing a dropping in debian/source/ seems straightforward
> and precisely correct.  It's a description of the maintenance/update
> practice that generated the tree you're working with, and (by
> implication) how updates to it should be made.

You might want to allow non-dgit users to use 'dpkg-source --commit',
though, if you think the bugs aren't going to arise for your package, or
are optimistic that dpkg will be fixed soon, and don't want to change
up the workflow later.

I think that we can come up with a wording that gives people enough
information to make an appropriate choice for their package, and, as you
prefer, leans in favour of not having single-debian-patch in d/s/o.

> Is there anything stopping us inventing an "unofficial"
> debian/source/options entry ?
> ... tested it ...
> It causes these messages:
> dpkg-source: info: using options from dgit/debian/source/options: --wombat
> dpkg-source: warning: --wombat is not a valid option for 
> Dpkg::Source::Package::V1
> which is probably too annoying.

Yeah.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1031539: [Pkg-utopia-maintainers] Bug#1031539: network-manager: NM since 1.42.0-1 overwrites pre-existing dns-search entries

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

Am 18.02.23 um 02:05 schrieb Christoph Anton Mitterer:

Package: network-manager
Version: 1.42.0-1
Severity: normal

Hey.

Just wanted to file this as a bug against ifupdown, but while writing I found 
out
that actually the upgrade from 1.40.10-1 to 1.42.0-1 causes this:

Ssince around the 10th of Feburary (and I've updated NM on the 11th) my 
dns-search
doesn't get added to resolvconf anymore.

Since years I have in /etc/network/interfaces:
iface lo inet loopback
dns-search  scientia.org
tried this setup with 1.40.10 but can *not* confirm that scientia.org is 
added to /etc/resolv.conf this way.


And from the log you sent, it seems you use systemd-resolved.
So you have an interesting mix/setup of managed=true, NM and resolved 
which is probably something you need to debug locally or provide 
step-by-step instructions in a minimal environment how this can be 
reproduced.


Maybe it helps, if you remove some of the involved components, like 
resolved/resolvconf


Michael





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031826: tty clock speed not being set properly in debian kernel on iBase hardware

[Mike Linn]

Package: linux-image-5.10.0-21-amd64

Version: 5.10.162-1


"stty -F /dev/ttyS0 110" returns

"stty: /dev/ttyS0: unable to perform all requested operations"

Attempted to set baud rate on ttyS device to 110 and received error message

I expect the baud rate to be set correctly.

This has been tested with several iterations of the linux-image-5.10.0
kernel including but not limited to linux-image-5.10.0-8-amd64 and
linux-image-5.10.0-14-amd64 as well as the backports kernel version
5.19.0-0.deb11.2-amd64 kernel

This issue does not occur when using the ubuntu 5.15 kernel or
Slacware 15.0 5.15 kernel on the same hardware.

libc version is Version: 2.31-13+deb11u5

dmidecode and lspci output attached.
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
77 structures occupying 2875 bytes.
Table at 0x000ECD10.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 4.6.5
Release Date: 09/30/2021
Address: 0xF
Runtime Size: 64 kB
ROM Size: 4 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer:   
Product Name:   
Version:   
Serial Number:   
UUID: 03000200-0400-0500-0006-000700080009
Wake-up Type: Power Switch
SKU Number:   
Family:   

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer:   
Product Name:   
Version:   
Serial Number:   
Asset Tag:   
Features:
Board is a hosting board
Board is replaceable
Location In Chassis:   
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0

Handle 0x0003, DMI type 3, 25 bytes
Chassis Information
Manufacturer:   
Type: Desktop
Lock: Not Present
Version:   
Serial Number:   
Asset Tag:   
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 1
 (0)
SKU Number:   

Handle 0x0004, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J1A1
Internal Connector Type: None
External Reference Designator: PS2Mouse
External Connector Type: PS/2
Port Type: Mouse Port

Handle 0x0005, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J1A1
Internal Connector Type: None
External Reference Designator: Keyboard
External Connector Type: PS/2
Port Type: Keyboard Port

Handle 0x0006, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2A1
Internal Connector Type: None
External Reference Designator: TV Out
External Connector Type: Mini Centronics Type-14
Port Type: Other

Handle 0x0007, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2A2A
Internal Connector Type: None
External Reference Designator: COM A
External Connector Type: DB-9 male
Port Type: Serial Port 16550A Compatible

Handle 0x0008, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2A2B
Internal Connector Type: None
External Reference Designator: Video
External Connector Type: DB-15 female
Port Type: Video Port

Handle 0x0009, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: 

Bug#1031825: [Pkg-nagios-devel] Bug#1031825: icinga-php-library: Creation of dynamic property is deprecated in PHP 8.2

[Frederik Himpe]

Sebastiaan Couwenberg schreef op 2023-02-23 17:59:


 skip_validation is not a documented resource option:

  
https://icinga.com/docs/icinga-web/latest/doc/04-Resources/#configuration


 You likely have this in /etc/icingaweb2/resources.ini though, can you
confirm that?


Yes:
my icingadb resource has:
skip_validation = "0"

This was set by the icingaweg2 setup: there is an option "Skip 
validation" which ignores any errors if it cannot connect to the 
database. Some screenshots with this option are here: 
https://github.com/Icinga/icingaweb2/issues/4291


Anyway, I temporarily used this option during the setup but I don't need 
this any more so I removed it. The errors are gone now and everything 
works as expected.


--
Frederik Himpe 
Vrije Universiteit Brussel

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sean Whitton]

Hello,

On Wed 22 Feb 2023 at 09:55AM +01, Sebastian Ramacher wrote:

> Unless I am missing something, having dh_installsystemd look at the
> service files in /usr/lib is the only viable solution for bullseye ->
> bookworm. We could fix individual packages that didn't include those
> files in bullseye, but for all the others we are unable to move the
> files from /usr/lib to /lib.

You're saying we can't move them in that case because the TC resolution
says no moving /usr/lib->/lib ?  Or some other reason?
I thought we only said that files couldn't move in the other direction.

Are there any of the 35 packages that did in fact ship them in /usr in
bullseye?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1031825: [Pkg-nagios-devel] Bug#1031825: icinga-php-library: Creation of dynamic property is deprecated in PHP 8.2

[Sebastiaan Couwenberg]

Hi Frederik,

Resending with correct Reply-To header.

On 2/23/23 17:55, Frederik Himpe wrote:

Sebastiaan Couwenberg schreef op 2023-02-23 17:45:

On 2/23/23 17:05, Frederik wrote:
I'm using Debian Bookworm with icinga-php-library 0.10.1-1 and PHP 
8.2. When I log in in icingaweb2, I see three times this message in 
the left sidebar between the search bar in the menu:
Deprecated: Creation of dynamic property 
ipl\Sql\Config::$skip_validation is deprecated in 
/usr/share/icinga-php/ipl/vendor/ipl/sql/src/Config.php on line 32


Are you using icinga2-ido-mysql by chance?

I cannot reproduce the issue with icinga2-ido-pgsql


No, I'm not using any of the icinga2-ido-* packages, I am using icingadb 
with icingadb-web instead.


What about my other question?

"
 skip_validation is not a documented resource option:

  https://icinga.com/docs/icinga-web/latest/doc/04-Resources/#configuration

 You likely have this in /etc/icingaweb2/resources.ini though, can you 
confirm that?


 Please remove or comment out the setting if you do.
"

Please check /etc/icingaweb2/resources.ini.

Kind Regards,

Bas

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

Bug#1031825: [Pkg-nagios-devel] Bug#1031825: icinga-php-library: Creation of dynamic property is deprecated in PHP 8.2

[Frederik Himpe]

(Sorry for the double post, sending this to the bug report too.)

Sebastiaan Couwenberg schreef op 2023-02-23 17:45:

Control: tags -1 moreinfo

Hi Frederik,

On 2/23/23 17:05, Frederik wrote:
I'm using Debian Bookworm with icinga-php-library 0.10.1-1 and PHP 
8.2. When I log in in icingaweb2, I see three times this message in 
the left sidebar between the search bar in the menu:
Deprecated: Creation of dynamic property 
ipl\Sql\Config::$skip_validation is deprecated in 
/usr/share/icinga-php/ipl/vendor/ipl/sql/src/Config.php on line 32


Are you using icinga2-ido-mysql by chance?

I cannot reproduce the issue with icinga2-ido-pgsql


No, I'm not using any of the icinga2-ido-* packages, I am using icingadb 
with icingadb-web instead.


--
Frederik Himpe 
Vrije Universiteit Brussel

Bug#1031825: [Pkg-nagios-devel] Bug#1031825: icinga-php-library: Creation of dynamic property is deprecated in PHP 8.2

[Sebastiaan Couwenberg]

Control: tags -1 moreinfo

Hi Frederik,

On 2/23/23 17:05, Frederik wrote:

I'm using Debian Bookworm with icinga-php-library 0.10.1-1 and PHP 8.2. When I 
log in in icingaweb2, I see three times this message in the left sidebar 
between the search bar in the menu:
Deprecated: Creation of dynamic property ipl\Sql\Config::$skip_validation is 
deprecated in /usr/share/icinga-php/ipl/vendor/ipl/sql/src/Config.php on line 32


Are you using icinga2-ido-mysql by chance?

I cannot reproduce the issue with icinga2-ido-pgsql, that setup was used 
to develop the PHP 8.2 changes are discussed in the upstream issue:


 https://github.com/Icinga/icingaweb2/issues/4918

skip_validation is not a documented resource option:

 https://icinga.com/docs/icinga-web/latest/doc/04-Resources/#configuration

You likely have this in /etc/icingaweb2/resources.ini though, can you 
confirm that?


Please remove or comment out the setting if you do.

Kind Regards,

Bas

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

Bug#1031647: git-annex: Bogus build dependency whitelist results in FTBFS on m68k

[Joey Hess]

Sean Whitton wrote:
> Joey, do you know why d/control restricts these build deps as it does?

IIRC some of those deps are or were not available on some architectures
like m68k. And the deps used to be gated behind the webapp build flag,
so it would still build on those architectures without them installed.

(I don't know how to get rmadison to display what packages are available 
on m68k? If those deps are avilable now, you could make git-annex use
them.)

Unfortunately, commit 78440ca37d75039d5eadd52eafbcd1751daba70a moved
those build dependencies from behind that build flag. See commit for
details; for some reason a new version of cabal changed its
behavior in a way that seemed buggy, and that was the only workaround
I could come up with at the time.

One way you could get git-annex to build on arches where those build
deps are not available would be to remove those build deps from the cabal 
file when building on those arches, and turning off the Assistant build
flag.

I think I have a better way though. The attached patch seems to work
around that cabal problem in a way that will keep git-annex building
when those deps are not installd. It should be in the next release of
git-annex.

-- 
see shy jo
From f24f96e0186a61ef5940ce97de2713413989b63c Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Thu, 23 Feb 2023 10:35:19 -0400
Subject: [PATCH] move webapp build deps under Assistant build flag

git-annex.cabal: Move webapp build deps under the Assistant build flag so
git-annex can be built again without yesod etc installed.

Commit 78440ca37d75039d5eadd52eafbcd1751daba70a got rid of the webapp build
flag to work around what was apparently a cabal bug. It moved the webapp
build deps to the main build-depends list. But that prevents building
git-annex when yesod etc are not installed.

Putting them under the Assistant build flag seems to not tickle that cabal
bug, and lets git-annex build automatically with the assistant disabled
when the webapp build deps are not installed.

I hypotehesize that the problem may have involved build-depends nested
behind two build flags. Also, cabal clean may need to be run in order
for cabal to find the right solution after this change, when building in
a directory where cabal configure had been run before.

Also moved 3 modules that are needed to build git-annex w/o the assistant
out from under the Assistant build flag.

Sponsored-by: Brock Spratlen on Patreon
---
 CHANGELOG   |  2 ++
 git-annex.cabal | 37 +++--
 2 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/CHANGELOG b/CHANGELOG
index a9dfdf469b..b833a04e23 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -6,6 +6,8 @@ git-annex (10.20230215) UNRELEASED; urgency=medium
   * info: Fix reversion in last release involving handling of unsupported
 input by continuing to handle any other inputs, before exiting nonzero
 at the end.
+  * git-annex.cabal: Move webapp build deps under the Assistant build flag
+so git-annex can be built again without yesod etc installed.
 
  -- Joey Hess   Tue, 14 Feb 2023 14:11:11 -0400
 
diff --git a/git-annex.cabal b/git-annex.cabal
index d3e0193005..349bda66bb 100644
--- a/git-annex.cabal
+++ b/git-annex.cabal
@@ -377,21 +377,7 @@ Executable git-annex
aws (>= 0.20),
DAV (>= 1.0),
network (>= 3.0.0.0),
-   network-bsd,
-   mountpoints,
-   yesod (>= 1.4.3), 
-   yesod-static (>= 1.5.1),
-   yesod-form (>= 1.4.8),
-   yesod-core (>= 1.6.0),
-   path-pieces (>= 0.2.1),
-   warp (>= 3.2.8),
-   warp-tls (>= 3.2.2),
-   wai,
-   wai-extra,
-   blaze-builder,
-   clientsession,
-   template-haskell,
-   shakespeare (>= 2.0.11)
+   network-bsd
   CC-Options: -Wall
   GHC-Options: -Wall -fno-warn-tabs  -Wincomplete-uni-patterns
   Default-Language: Haskell2010
@@ -432,6 +418,21 @@ Executable git-annex
   
   if flag(Assistant) && ! os(solaris) && ! os(gnu)
 CPP-Options: -DWITH_ASSISTANT -DWITH_WEBAPP
+Build-Depends:
+  mountpoints,
+  yesod (>= 1.4.3), 
+  yesod-static (>= 1.5.1),
+  yesod-form (>= 1.4.8),
+  yesod-core (>= 1.6.0),
+  path-pieces (>= 0.2.1),
+  warp (>= 3.2.8),
+  warp-tls (>= 3.2.2),
+  wai,
+  wai-extra,
+  blaze-builder,
+  clientsession,
+  template-haskell,
+  shakespeare (>= 2.0.11)
 Other-Modules:
   Assistant
   Assistant.Alert
@@ -447,8 +448,6 @@ Executable git-annex
   Assistant.Fsck
   Assistant.Gpg
   Assistant.Install
-  Assistant.Install.AutoStart
-  Assistant.Install.Menu
   Assistant.MakeRemote
   Assistant.MakeRepo
   Assistant.Monad
@@ -540,7 +539,6 @@ Executable git-annex
   Command.Watch
   Command.WebApp
   Utility.Mounts
-  Utility.OSX
   Utility.Yesod
   Utility.WebApp
 
@@ -673,6 +671,8 @@ Executable git-annex
 Annex.WorkerPool
 Annex.WorkTree
 Annex.YoutubeDl
+Assistant.Install.AutoStart
+Assistant.Install.Menu
 Backend
 

Bug#1031647: git-annex: Bogus build dependency whitelist results in FTBFS on m68k

[John Paul Adrian Glaubitz]

Hi Joey!

On Thu, 2023-02-23 at 12:27 -0400, Joey Hess wrote:
> Sean Whitton wrote:
> > Joey, do you know why d/control restricts these build deps as it does?
> 
> IIRC some of those deps are or were not available on some architectures
> like m68k. And the deps used to be gated behind the webapp build flag,
> so it would still build on those architectures without them installed.

FWIW, adding m68k to the architecture list makes the package build fine.

So, either way, I think m68k should be enabled to use all the possible build
dependencies and doesn't need any limitation.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#801065: Documenting how to not fail postinst on service fails to start

[Wouter Verhelst]

On Wed, Feb 15, 2023 at 02:38:10PM -0500, Marvin Renich wrote:
> > > >  - the service fails to start in the postinst.
> 
> This implies that "the service is running" is part of "the service is
> configured", which is where I disagree.

What Steve said is that if

- The service fails to start, *AND*
- The service was previously running (or this is a new install)

*THEN*

this is something that should make postinst fail.

The two preconditions are linked, and should not be looked at
separately.

If the service was *not* previously running, then that is a different
situation.

But if the service was previously running and now a restart fails, then
obviously[1] this is a problem with the upgrade that should be looked at
by the admin, which means it must be flagged to the admin somehow.

As I mentioned in the TC discussion, one can reasonably debate what the
best way is to flag such problems, but I think it's not reasonable to
say "let's just push it under the mat, it doesn't matter".

We currently only have one sure way of telling the admin that there is a
problem, and that is "fail postinst".

As such, I think any suggestion that we ignore a restart failure of a
service that was running before the dpkg run should be accompanied by a
plan on *how* to flag this failure to the admin in a way that the admin
will know that things failed. In the absence of that, the status quo of
"postinst should fail on a restart of a service" should probably be
retained.

[1] barring extreme corner cases of the style "the admin made broken
changes but forgot to try a restart"

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1031698: RFS: dhcpdump/1.8-5 [QA] -- Parse DHCP packets from tcpdump

[Jpaulo]

Thank you for the considerations made in my review and excellent work
with your review. I learned a lot from your work.

waiting for a sponsor to upload.


On Tue, Feb 21, 2023 at 2:22 AM Boian Bonev  wrote:

> Hi,
>
> First thing to change (after the missing binary) is the description - the
> tool
> no longer executes and parses tcpdump's output, instead it uses libpcap
> directly to get the packets. The man page needs the same correction.
>
> The build completely ignores the default hardening and optimization flags.
> This
> breaks both cross and reproducible builds.
>
> tcpdump should be removed from Depends.
>
> Isn't it better to depend on libpcap-dev? (libpcap0.7-dev isn't in any
> supported release)
>
> Current standards are 4.6.2.
>
> d/copyright may benefit from a DEP5 conversion.
>
> Now I see that there are 3 open bugs, maybe at least two or even all can be
> fixed by this upload?
>
> I have several patches for this tool hanging around since 2013, I did try
> to
> send them to upstream back then but they either got lost or ignored. All of
> them are fixing behavioral bugs.
>
> I think it is a good idea to add these patches while doing the QA upload. I
> need to add the proper headers and will post after an ACK.
>
> --
> With best regards,
> b.
>

Bug#1031804: nvtop: Crashes on multi-gpu system while using PRIME with chromium/chrome

[Jesse Rhodes]

I took a second look this morning now that the meeting is over, and
I've determined that it only crashes if chromium or google-chrome is
being run with the PRIME environment variables.

nvidia-smi output as well as temp sensor data indicated that the
nvidia gpu was being used for chrome as I had hoped, but something
about this prevents nvtop from working.

chrome prints the following to the console after being launched with
the aforementioned env vars:

MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to open amdgpu: /usr/lib/dri/amdgpu_dri.so: cannot
open shared object file: Permission denied (search paths
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix
_dri)
failed to load driver: amdgpu
MESA-LOADER: failed to open zink: /usr/lib/dri/zink_dri.so: cannot
open shared object file: Permission denied (search paths
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix
_dri)
failed to load driver: zink
MESA-LOADER: failed to open kms_swrast:
/usr/lib/dri/kms_swrast_dri.so: cannot open shared object file:
Permission denied (search paths
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix
_dri)
failed to load driver: kms_swrast
MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot
open shared object file: Permission denied (search paths
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix
_dri)
failed to load swrast driver

But otherwise works as expected.

sney

Bug#1029092: Don't update mysql-defaults in Debian testing/Bookworm too early

[Otto Kekäläinen]

> On Tue, 17 Jan 2023 08:00:00 -0800 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?=
>  wrote:
> > This severity 'serious' bug should prevent the migration
> > automatically. Close this bug when migration is free to proceed.
>
> I believe this has happened now. Do you think it should solve that issue
> I was seeing?

Potentially, but I need more info.

This mysql-defaults definitely needs to migrate for the full
repository view to be correct/complete. I was planning to do it 1-2
days after mariadb has migrated.

Bug#1031770: Info received (kontact: cannot show existing messages and will not retrieve new ones)

[Paul Boddie]

Hello again,

I looked at the packaging repository for libmariadb3 and found the 
following commit importing the upstream sources for 10.3.38:


https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/773fb3e04ffae2b4868876be632fb7244329e7c3

Looking at the diff, I found the following change to 
libmariadb/libmariadb/mariadb_lib.c:


@@ -3879,7 +3881,7 @@ int STDCALL mysql_set_server_option(MYSQL *mysql,

 ulong STDCALL mysql_get_client_version(void)
 {
-  return MARIADB_VERSION_ID;
+  return MARIADB_PACKAGE_VERSION_ID;
 }

 ulong STDCALL mysql_hex_string(char *to, const char *from, unsigned 
long len)


This appears to be what the Qt bug report is describing:

"MariaDB 10.6 changed the mysql_get_client_version output to return the 
library version (30200 as of 10.6.3) instead of the server version"


https://bugreports.qt.io/browse/QTBUG-95071

So, it seems that the changes to MariaDB 10.6 have leaked into 10.3, 
thus causing this issue.


Paul

Bug#1030882: RFS: dbus-c++/0.9.0-11 [QA] -- C++ API for D-Bus

[Thomas Uhle]

On Thu, 23 Feb 2023, Bastian Germann wrote:


Thanks for the QA work!


Thank you for that and your support!

Bug#1029092: Don't update mysql-defaults in Debian testing/Bookworm too early

[Paul Gevers]

Hi Otto,

On Tue, 17 Jan 2023 08:00:00 -0800 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= 
 wrote:

This severity 'serious' bug should prevent the migration
automatically. Close this bug when migration is free to proceed.


I believe this has happened now. Do you think it should solve that issue 
I was seeing?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031825: icinga-php-library: Creation of dynamic property is deprecated in PHP 8.2

[Frederik]

Package: icinga-php-library
Version: 0.10.1-1
Severity: normal
Tags: upstream

Dear Maintainer,

I'm using Debian Bookworm with icinga-php-library 0.10.1-1 and PHP 8.2. When I 
log in in icingaweb2, I see three times this message in the left sidebar 
between the search bar in the menu:
Deprecated: Creation of dynamic property ipl\Sql\Config::$skip_validation is 
deprecated in /usr/share/icinga-php/ipl/vendor/ipl/sql/src/Config.php on line 32

Upstream report: https://github.com/Icinga/ipl-sql/issues/69

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'stable-security'), (700, 'stable'), 
(650, 'proposed-updates'), (200, 'unstable'), (160, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages icinga-php-library depends on:
ii  icinga-php-thirdparty0.11.0-2
ii  php-intl 2:8.2+93
ii  php8.2-cgi [php-json]8.2.2-3
ii  php8.2-cli [php-json]8.2.2-3
ii  php8.2-common [php-pdo]  8.2.2-3
ii  php8.2-fpm [php-json]8.2.2-3
ii  php8.2-intl [php-intl]   8.2.2-3

icinga-php-library recommends no packages.

icinga-php-library suggests no packages.

-- no debconf information

Bug#1031124: unblock: mariadb/1:10.11.1-4

[Otto Kekäläinen]

> On my daily updated system, I today saw this:
> The following NEW packages will be installed:
>libdbd-mariadb-perl
> The following packages have been kept back:
>mariadb-server
> The following packages will be upgraded:
>chromium chromium-common chromium-driver chromium-sandbox
> glib-networking glib-networking-common glib-networking-services
> ibus-data imagemagick imagemagick-6-common imagemagick-6-doc
>imagemagick-6.q16 klibc-utils libgraph-perl libibus-1.0-5 libklibc
> liblzma-dev liblzma5 libmagickcore-6.q16-6 libmagickcore-6.q16-6-extra
> libmagickwand-6.q16-6 libmariadb3 libyuv0
>libzstd-dev libzstd1 mariadb-common mercurial mercurial-common
> r-cran-survival xz-utils zstd
> 31 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
>
> I've not accepted the change to help you debug the situation, but
> apparently the upgrade path for the new unversioned src:mariadb isn't ideal.
>
> Can I help you with more information?

What does apt upgrade -o Debug::pkgDepCache::Marker=1 -o
Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgProblemResolver=1
yield?

In this situation we need to debug what versions apt is seeing and how
it is resolving them [1].

To be able to investigate, fix and validate that a fix is correct, I
probably need a reproducible test case we can add to our Salsa-CI [2].

[1] 
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/README.Contributor#L274-347
[2] https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines/502070

Bug#1031656: Acknowledgement (MariaDB autopkgtest upstream test suite fails on disk / data corruption on ppc64el)

[Paul Gevers]

Hi Otto,

On 22-02-2023 08:25, Otto Kekäläinen wrote:

A fresh run today passed, proving the Debian autopkgtest host
hardware/kernel/overload theory is likely the cause.


I don't think a pass proves anything in that respect. I've seen so many 
tests being flaky because they assume things that aren't always true 
(like being the only thing running, or having race conditions that get 
exposed on certain hardware or setups).


Regarding "overload"; in my opinion a database server like MariaDB 
should be resilient against a heavily loaded server. No data corruption 
should occur under load. I'm wondering what it means if a loaded system 
could cause your tests to fail. Could it be that the *test* is sensitive 
to a loaded system (e.g. race conditions) and that a failure isn't 
representing the actual MariaDB server?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031587: [request-tracker-maintainers] Bug#1031587: Handling of the request-tracker4 -> request-tracker5 transition in bookworm

[Paul Gevers]

Control: tags -1 moreinfo

Hi,

On 20-02-2023 13:09, Dominic Hargreaves wrote:

If the release team would be willing to grant an exception to the policy
to get this done, we can get this wrapped up inside a week I expect.


Can you please confirm that everything is ready to do this? I.e. there 
is no "this should work but we haven't tested it" cases. If yes, then 
please upload the packages that involve new binaries to experimental and 
when those are passed NEW, ping this bug. If no surprises pop up, we'll 
grant an exception, but we want everything fully ready before doing so.


Paul


OpenPGP_signature
Description: OpenPGP digital signature